Systems Modelling Ltd. (SML) service for certification of the facilities to support the euro changeover for business in accounting software packages.

Summary:

The software company pays a base charge plus a price per module depending on the nature of the review and the complexity - single or multi-currency, plus reasonable business travel expenses for visits.

Systems Modelling Ltd. (SML) have prepared test cases designed to highlight errors and problems expected to arise in the transitional period for single-currency software that is adapted for the euro. Multi-currency software can also be tested and certified at a lower cost than current
alternative schemes.

The tests cover the "price accordion" effects, detecting the use of inverse rates, rounding, truncation, accounting with master and detail records, and account and base conversion in the transition scenario. The
test data is created knowing what the most sensitive points are
that give rise to errors in conversion and rounding for a given base currency. For users concerned
simply with the transition from one single currency to another, the need for triangulation is not expected to be an issue.

For economy, most of the tests are done with the main national currency unit of the target market. Where the supplier has several markets, each shall be separately assessed with additional sets of test cases designed for their conversion specifics. For example, the Irish Pound is a special case is it is the only NCU heavier than the euro.

What kind of euro-compliance certification will be given?

The product will be asserted to have either passed a
review process, or to have fulfilled certification conditions. The scope of the testing shall be shown.

This is not a certification of the producer's business, their quality system or their software production process. We will not review source code ourselves; it will be sufficient for the supplier to provide evidence of their own analysis of the impact of the euro on their software and the consequent design choices taken. Development standards and other quality attributes are outside the scope. In this, we follow the guidelines of
ISO/IEC 12119:1994 - "Information Technology - Software packages - Quality requirements and testing".

We cannot perform all the tests possible to cover the entire functionality of an accounting package. Therefore we cannot certify a package as entirely correct, nor may we be described as doing so. The test cases are designed for an
acceptable level of assurance, not a formal proof of correctness.

There is no one definition of "compliance", and different approaches are valid for different companies. Therefore the suppliers must provide their own definition in a testable form. This requires public statements of what their package actually does, which shall be tested, and the user can decide if those facilities are enough. The suppliers should explain why the results are as they are. If
necessary some training or consultancy can be made available, which can include site visits, code review, and so on.

For the suppliers, it has the benefit of providing a transparent and cross-industry applicable standard that will simplify their communications to their customers. In discussions with many of them, they are not looking forward to having to create euro educational materials from scratch. Their customers are asking them for guidance, and they feel that national or accounting standards should be drawn up.

For some users it may be the first time they consider the practical scenario in such detail. Most
Small & Medium Enterprises (SME) are naïve in this and expect computers to perform perfect conversion and equivalence, and are surprised when rounding errors appear. This will force software suppliers to disclose what kind of things can happen with their converters and wrappers, so there will be fewer surprises when the real changeover dates finally loom.

It may well be that magazines and directories will seek to simplify the results presented
and state "X% of NNN packages are compliant", or "fully compliant", reducing the statements to a single box in a checklist. For example, a
1999 survey of accounting packages in a free computer magazine in Ireland had two columns "Full Euro compliant" and "Conforms to BASDA Euro Guidelines" without explaining what they meant by that distinction. To counter such representations, we should state that magazines are only permitted to list the fact that results are available and the level assessed: Review or Certification.

How do these tests differ from other certification schemes?

The original BASDA (Business & Accounting
Software Developer's Association) tests check for individual conversion and triangulation. The triangulation spreadsheet provided contain numbers are well chosen to test for
conversion. The updated specification includes coverage for the changeover of account balances.

The IBM checklist on the euro-comptables web site is a form of self-certification. They provide a detailed checklist but the web site only displays the answers to broad questions.

The German DIN national standard explicitly covers a three-year transition scenario and gives tests and results. However the actual test data used are small numbers that will not reveal some kinds of rounding error.

The French national standards authority has delegated the testing to Aquitaine Valley, who do not disclose the test process.

The main problem with self-certification is that software authors are naturally blind to their own defects. They don't know what they don't know. As an example, we tested a package from an unaccredited small supplier and found three faults:

They converted an account the wrong way

The program crashed if a certain sequence of actions was taken

Entering a euro invoice in a pound base currency could put the trial balance out by a penny.

How will the tests be supplied and publicised?

English language versions using IEP currency are available first. Localised translations of the test cases can be prepared in accordance with
needs.

The test cases and accompanying documentation will only be available under a confidentiality agreement upon payment to SML.

The results of a review could be that queries would be raised by SML as to the meaning or correctness of the results and the interpretation supplied by the company. In the event of serious defects being found requiring considerable re-work, the application could be rejected completely and be made subject to a resubmission for another review payment as specified above. An arbitrator may be required to resolve disputes as to what constitutes sufficient grounds for such a rejection. SML only issues a final statement if queries are satisfactorily resolved.

What is the Certification process?

The tests will be performed with Patrick O'Beirne of SML as an observer to verify that the tests are appropriate to their specific software. This is necessary for independent verification because an independent observer can raise other issues that could be hidden by a company following only generic tests.

The supplier submits a confidential application to SML accompanied by the
base fee and detailed system and user documentation of their product along with contact information. This pre-assessment stage is to provide a first view of the adequacy of their approach and whether it is worth while proceeding to Certification.

If SML judge that their approach is reasonable, SML sends them a copy of the test data and documentation upon receipt of the rest of the fee and a confidentiality agreement.

They then create documented test cases expressed in the specific terms of their software operations. These will be reviewed by SML and any issues clarified.

A site visit will then be arranged at the expense of the software supplier that covers initial consultation, a maximum of one day per module on site to perform the tests and resolve any queries and document the results, and the subsequent report. If issues arise that require further work for resolution, this can be arranged for a separate charge.

SML will then issue a report, specific to the version of the software tested, indicating that the results were independently observed and verified. The Certified level will also contain comments on the adequacy of the company's total customer support package including:

product documentation and usability

maintenance, upgrade and licensing policy

software upgrade version control and data conversion

training materials including advice on the numerical, trading, and accounting issues that will arise in the transition period with trading partners and base conversion.

What kinds of software products and target markets are applicable?

This is primarily intended for those who currently serve a national currency market and do not provide multi-currency facilities in the package. Their challenge is the dual handling during the transition period, and the final conversion of the accounts.

This can also apply to smaller multi-currency package producers seeking a more affordable certification scheme.

The scope should include the key modules of product pricing, sales and purchase invoicing, statements, general ledger, and payroll. Specialised applications such as point-of-sale systems can be quoted for after an initial review. Windows or web-based calculators are likely to be very common desktop tools that people will use to provide cross-checks on their accounting software, so their suppliers could be encouraged to perform just the conversion tests and submit those. (At least one well-known euro conversion calculator fails these tests in its current version.)

It is important to express the tests and results in the familiar forms of documents like price lists, invoices, payments, and statements, rather than technical software terminology.
This is so that any user may verify the claims of their supplier, and investigate alternatives if their present supplier is unable to provide the evidence they would like.

Conclusion

The proposed tests represent a realistic picture that
user managers can relate to, that satisfy the calls by small software suppliers for a standard, and allow them to publicise their readiness at a modest cost.

Definitions:

Certification: evaluation and testing of software against requirements and the awarding of a certificate of compliance.

Accreditation: The evaluation of certification bodies and testing laboratories as being competent to perform the testing and award the certificate which is then recognised by the accreditation body.

Euro compatible: The software can be used with the euro currency with no restrictions. The term does not imply the existence any conversion functions. A single currency accounting package can be termed euro compatible as long as it can process data to two decimal places with a euro indication. A font is euro compatible if it provides a recognisable euro symbol.

Euro ready: This applies to a body that is able to transact in euro. Where applied to a software package, it is taken to be the same as "euro compatible"

Both of the above are weaker than the following:

Euro compliant: The software follows the Regulation 1103/97 rules for the conversion and rounding of euro amounts to and from national currency units. There is no requirement that it be multi-currency. A single currency accounting package with an input and/or output converter can satisfy this. If an output converter is used, there must be a disclaimer regarding rounding errors. A multi-currency package that follows the regulations satisfies this.

Euro functional: This term is taken to be the same as "euro compliant"

Euro enabled: This term is taken to be the same as "euro compliant"

Because the above are self-certified by assertion, the above are weaker than the following:

Euro certified: The software has been tested to the "Advanced" specification below by an accredited body, it has met all the mandatory conditions, any nonconformity in recommended conditions is documented, and optional conditions that were not tested are listed.

Euro accredited: This term is taken to be the same as "euro certified", although strictly speaking it is the wrong term to use as "accreditation" is the recognition of testing and certification bodies.

Accreditation and Certification bodies

The essence of an accreditation body is that it should be independent, non-commercial and non-competitive so that its accreditation decisions will be free from commercial influence.
By way of comparison with ISO 9000 accreditation, most Certification Bodies (Registrars) operate in just one country and hold accreditation from that country's National Accreditation Authority (NAA).
If certified clients want to export they will need some assurance that their accredited certifications will be recognised overseas. BASDA provide education and public awareness that such a mark or logo indicates that a certification body
that has been accredited by BASDA issued the certificate.

References

This International Standard defines a set of requirements for software packages and the instructions on how to test a software package against these requirements.

Scope

The scope of the standard is to establish quality requirements for software packages and to specify how a product shall be tested against these quality requirements.

Conformity according to ISO/IEC 12119 does not say anything about the usefulness of an accounting system for a specific use in a specific environment by a specific user. It only provides confidence that the system actually does what it claims to. This is not the same as that it does what the user expects from it to suit his needs.

Evaluation based on ISO/IEC 12119 emphasises on external quality of a an accounting system. Internal quality and quality in use are not addressed.

There is no difference in level of importance of the requirements in ISO/IEC 12119, either it is either conforming or it is non-conforming.

Abstract

A software package is to be regarded as a complete and documented set of programs supplied to several users for a generic application or function. This standard applies only to software packages as offered and delivered, it does not deal with the software development process, nor with the suppliers quality system.

This International Standard requires that a software package shall have a product description and user documentation and defines requirements for such documentation and for the programs and data supplied. In particular, that all product descriptions shall be testable and correct.

The product description and user documentation are described in terms of general requirements on contents and characteristics, while the requirements for programs and data are derived from ISO/IEC 9126 quality characteristics, tailored for a software package.

ISO/IEC 12119 specifies also how to test a software package against the quality requirements and these testing instructions are related in particular to third-party testing. They include testing by inspection of documents and black box testing of programs and data. Particular attention is given to the selection of test cases, test repeatability and test reporting.

PRIVACY: Your email address is treated as
confidential and never disclosed without your explicit permission.OPT-OUT: The phone and fax numbers and email addresses at sysmod.com
provided on this web site are provided solely for one-to-one communications to
Systems Modelling Ltd. We forbid any harvesting of email addresses from this
site, or the inclusion of any sysmod.com address in any mail list without our
explicit permission. SPAM: Unsolicited bulk email to sysmod.com will be reported to
SpamCop.