Year 2000 Compliance Certification

Product: ____________________________

Certificates issued with reference to the Y2000 Certification Standard Document.

Date: ____________________

Prepared for Head: IT Planning

by_______________________

Filename: D:\MyFiles\Y2k Certification.wpd

Table of Contents

Product Level Compliance 1

Product Functions 1

Test Plan 1

Test Environment 3

Function Test Data 3

Execution of Function Tests 3

Documentation of Test Results 4

Solutions / Recommendations after rectifying unsatisfactory test results 4

Formulation of Year 2000 Practices and Procedures 4

Product Test Results Sign-off 5

Formulation of Year 2000 Conversion Recommendation 5

Product Compliance Certificate 5

Configuration Level Compliance 7

Configuration Level Permutations 7

Test Environments per Configuration Permutations 7

Product Function Tests 7

Test Results per Permutation 8

Solutions / Recommendations after rectifying unsatisfactory test results 8

Formulation of Year 2000 Practices and Procedures 8

Product Compliance Certificate 9

Formulation of Year 2000 Conversion Recommendation 9

Appendixes

Product Level

Product Functions "A"

Test Plan "B"

Test Environment "C"

Function Test Data "D"

Execution of Function Tests "E"

Documentation of Test Results "F"

Solutions / Recommendations after test results "G"

Formulation of Year 2000 Practices and Procedures "H"

Product Test Results Sign-off "I"

Formulation of Year 2000 Conversion Recommendation "J"

Product Compliance Certificate "K"

Configuration Level

Configuration Level Permutations "L"

Test Environments per Configuration Permutations "M"

Product Function Tests "N"

Test Results per Permutation "O"

Solutions / Recommendations after test results "P"

Formulation of Year 2000 Practices and Procedures "Q"

Product Compliance Certificates per Permutation "R"

Formulation of Year 2000 Conversion Recommendation "S"

Year 2000: Certification File Reference Structure "T"

Year 2000 Compliance Checklist "U"

Product Level Compliance

Product Functions

Attached the Product Functions as per Appendix "A."

Product level testing must be done within the context of it's business functions rather than the context of it's construction (programs, tables, etc.). In the application environment, using only the the item level test plan, will not suffice.

The end users or system support staff are normally in a good position to compile a list of business functions. The creator of a product may also perform this function, though it is advisable to involve end users or support staff. In the case of externally supplied products, the supplier should be involved, where possible. Existing documentation should at least be consulted.

The issue is whether every function in the product should be tested. It is a matter of risk versus cost and the following can serve as a guideline:

• At least every function that involves date processing should be tested.
• If supplier Y2000 certificates were supplied during the impact study or well documented reference material exist, tests may be scaled down to involve critical functions only.
• Where functions exist that are never or hardly ever used, they may be given less attention. These cases must however be cleared with other users of the product.

Test Plan

Attached the Test Plan as per Appendix "B."

The test plan is compiled based on the guidelines described as part of the quality record. It involves the detailed definition of:

• Test environments.
• Test conditions and expected outcomes.
• Test data requirements.
• Test schedules.

The conditions to be tested for must at least include:

• Dates before and after the century change.
• Dates rolling over from one to the next century.
• Date stamps in one century recognized in the next century.
• Forward calculations of dates.
• Backward calculations of dates.
• Sorting dates created before and after the century change.
• Data selection based on dates created before and after the century change.
• Reporting of dates.
• Screen display of dates.
• Dates as part of numbering structures.
• Dates as part of interface files to and from external parties.
• Leap year calculations in the years 2000, 2001 and 2004.
• Process cycle and automatic function testing.
• Period end testing.
• Expiration testing.
• Day of the week testing.

If time constraints exist, test conditions should be prioritized, based on the classification system used when errors were classified.

The requirements for the test environment must consider at least the following:

• Disk space requirements.
• Copying of data from live environments.
• Hardware/Operating System clock requirements.
• Swapping of environments.
• Test schedules.
• Development Environment, Operating System and utility program versions that must be present for each test condition.
• Multiple servers with the expected exchange of transactions between them.

Note that the test environment defined here is more detailed than the one negotiated for during the project planning phase. The updated and refined requirements must be passed on to the supplier of the test environment. Furthermore, the supplier of the test environment should be given enough time to prepare the environment, to tie in with requirements of other certification projects.

Test Environment

Attached the description of the Test Environment as per Appendix "C."

The test environment is created based on the specifications in the test plan and negotiations done during the project planning phase. The test conditions will drive the requirements of the test environment.

Function Test Data

Attached the list of Static and Transaction Data as per Appendix "D."

Item level test data is created in accordance with the requirements of the test plan. It will typically take two forms, being:

Static data - Data that must be present for a test condition to be tested. Such data may be copied from live environments, but will invariably, at least in part, be generated automatically or manually to suite the specific condition. It is important that the creation of the static data be repeatable for every condition being tested.

Transaction data - Transaction data is generated for the purposes of the duration of a specific test condition and may not be needed for certain test conditions. Generation tools may be used to generate the data. Interface files from other applications may be seen as one or more transactions. Note that, for the Year 2000, the intention of transaction data is to prove functionality, not to do load testing. The latter is therefore excluded from this standard.

Execution of Function Tests

Attached the summary of test conditions and sign off by an independent tester as per Appendix "E."

Test conditions are executed in accordance with the preparation in earlier steps. For product level testing the tests must be carried out by an independent tester. Independent for this purpose mean:

• The person was not involved in compiling the test plan.
• The person was not involved in making changes to the product at item level certification.
• It may be the same person that contributed in the identification of product functions.

If time constraints exist, the sequencing of test conditions, must take into account the priorities assigned to each condition.

Documentation of Test Results

Documentation of the test results by an independent tester as per Appendix "F."

The test results for each condition must be documented by the independent tester. Each tested condition must be signed off by both the independent tester and the project member responsible for testing.

Y2000 conversion procedures are initiated at this stage and formulated in later steps.

Solutions / Recommendations after rectifying unsatisfactory test results

Documentation of solutions and recommendations as per Appendix "G."

Errors are rectified re-executed and the test results documented until every test condition gives the desired result.

Formulation of Year 2000 Practices and Procedures

Documentation of Year 2000 Practices and Procedures as per Appendix "H."

Y2000 conversion procedures are formulated based on the results of the testing exercise. A year 2000 conversion procedure is a set of instructions to be followed by support personnel or end users to ensure a smooth century change-over. These instructions may be executable before, during or after the century change.

These instructions should be quality assured by as many people as possible. System Support and the provinces must be involved.

Product Test Results Sign-off

Sign-off by Project Leader and independent tester as per Appendix "I."

The project leader and independent tester signs the completed test results off with reference to the conditions in the test plan. The results are also signed off by at least one senior person in the components representing the project leader and the independent tester.

Formulation of Year 2000 Conversion Recommendation

Documentation of changes to the SAPS or IS as per Appendix "J."

Cases may exist where the certification process results in changes to the SAPS or IS:

• Infrastructure

• Standards

• Organizational structure

• Specifications

• Budgets.

If so management must be formally notified.

Product Compliance Certificate

Certificate as per Appendix "K."

The compliance certificate is issued after thorough testing. It must be signed off by both the independent tester and the project member responsible for testing and authorized by the directorate head responsible for certification.

Any reservations must be clearly indicated. Reference must be made to related conversion procedures.

It is possible that a Y2000 Conversion Certificate be issued, without a formal test by the SAPS, based on documentation received from the supplier. The supplier letter must then accompany the Y2000 Compliance Certificate. It must also be original. Note that, unless clear responsibility is taken, configuration level certification cannot be based on supplier undertakings.

The project manager/leader and directorate head responsible for certification takes final responsibility for certification. If the product fails after Y2000 the project leader/manager is accountable. The supplier may be held responsibility for breach of contract or misconduct. We should however endeavour to eliminate such situations.

Configuration Level Compliance

Configuration Level Permutations

Permutations as tested attached as per Appendix "L."

Each permutation (combination) of product version, software version and hardware needs to be identified.

The number of permutations can be excessive in certain areas. Take for instance the different versions of Word Perfect, the Operating Systems it runs under, and the makes of workstations involved. A judgement call must then be made to eliminate certain permutations. The factors that influence the decision were discussed under "Determine Compliance Risk" . They are repeated here for ease of reading:

• Certificates and White Papers received from suppliers during the impact study phase. Although it is in most cases a judgement call, one should nevertheless attempt to value the information at hand, taking into account factors such as credibility of the supplier, the supplier understanding of the complexities involved in Y2000 compliance and the credibility of the source of information.
• Impact on the core business of the SAPS. One can take factors such as number of users, cost benefit, strategic value and the impact of non-compliance into account. It is important that exclusions be sanctioned by the owners of products.

Test Environments per Configuration Permutations

Documentation of Test Environments as per Appendix "M."

A test environment is created for each permutation that was selected for certification. The attributes of the test environment are determined by:

• The product level certification test plan. This plan contains the conditions to be tested.
• The requirements of the software and products to be tested.

Product Function Tests

Attached the summary of test conditions and sign off by an independent tester as per Appendix "N."

Test conditions are executed in accordance with the preparation in earlier steps. For configuration level testing the tests must be carried out by an independent tester. Independent for this purpose mean:

• The person was not involved in compiling the test plan.
• The person was not involved in making changes to the product at item level certification.
• It may be the same person that contributed in the identification of product functions.

If time constraints exist, the sequencing of test conditions, must take into account the priorities assigned to each condition.

The same test conditions, as defined by the product level test plan, are executed for each for each permutation.

Test Results per Permutation

Documentation of test results for each condition as per Appendix "O."

The test results for each condition must be documented by the independent tester. Each tested condition for each permutation must be signed off by both the independent tester and the project member responsible for testing.

Y2000 conversion procedures are initiated at this stage and formulated/consolidated in later steps.

Solutions / Recommendations after rectifying unsatisfactory test results

Documentation of solutions and recommendations as per Appendix "P."

Errors are rectified re-executed and the test results documented until every test condition gives the desired result.

Formulation of Year 2000 Practices and Procedures

Documentation of Year 2000 Practices and Procedures as per Appendix "Q."

Y2000 conversion procedures are formulated based on the results of the testing exercise. A year 2000 conversion procedure is a set of instructions to be followed by support personnel or end users to ensure a smooth century change-over. These instructions may be executable before, during or after the century change.

These instructions should be quality assured by as many people as possible. System Support and the provinces must be involved.

Product Compliance Certificate

Certificate as per Appendix "R."

The compliance certificate is issued after thorough testing. It must be signed off by both the independent tester and the project member responsible for testing and authorized by the directorate head responsible for certification.

Any reservations must be clearly indicated. Reference must be made to related conversion procedures.

It is possible that a Y2000 Conversion Certificate be issued, without a formal test by the SAPS, based on documentation received from the supplier. The supplier letter must then accompany the Y2000 Compliance Certificate. It must also be original. Note that, unless clear responsibility is taken, configuration level certification cannot be based on supplier undertakings.

The project manager/leader and directorate head responsible for certification takes final responsibility for certification. If the product fails after Y2000 the project leader/manager is accountable. The supplier may be held responsibility for breach of contract or misconduct. We should however endeavour to eliminate such situations.

Formulation of Year 2000 Conversion Recommendation

Documentation of changes to the SAPS or IS as per Appendix "S."

Cases may exist where the certification process results in changes to the SAPS or IS:

• Infrastructure

• Standards

• Organizational structure

• Specifications

• Budgets.

If so management must be formally notified.

Appendixes

Product Level

Product Functions "A"

Test Plan "B"

Test Environment "C"

Function Test Data "D"

Execution of Function Tests "E"

Documentation of Test Results "F"

Solutions / Recommendations after test results "G"

Formulation of Year 2000 Practices and Procedures "H"

Product Test Results Sign-off "I"

Formulation of Year 2000 Conversion Recommendation "J"

Product Compliance Certificate "K"

Configuration Level

Configuration Level Permutations "L"

Test Environments per Configuration Permutations "M"

Product Function Tests "N"

Test Results per Permutation "O"

Solutions / Recommendations after test results "P"

Formulation of Year 2000 Practices and Procedures "Q"

Product Compliance Certificates per Permutation "R"

Formulation of Year 2000 Conversion Recommendation "S"

Year 2000: Certification File Reference Structure "T"

Year 2000 Compliance Checklist "U"

Product Level

Product Functions

Appendix A

Appendix B

Test Environment

Appendix C

Function Test Data

Appendix D

Execution of Function Tests

Appendix E

Documentation of Test Results

Appendix F

Solutions / Recommendations after rectifying unsatisfactory test results

Appendix G

Formulation of Year 2000 Practices and Procedures

Appendix H

Product Test Results Sign-off

Appendix I

Formulation of Year 2000 Conversion Recommendation

Appendix J

Product Compliance Certificate

Appendix K

Configuration Level

Configuration Level Permutations

Appendix L

Test Environments per Configuration Permutations

Appendix M

Product Function Tests

Appendix N

Test Results per Permutation

Appendix O

Solutions / Recommendations after rectifying unsatisfactory test results

Appendix P

Formulation of Year 2000 Practices and Procedures

Appendix Q

Product Compliance Certificates per Permutation

Appendix R

Formulation of Year 2000 Conversion Recommendation

Appendix S

Year 2000: Certification File Reference Structure

Appendix T

Year 2000: Certification File Reference Structure

All documents produced as part of the of the certification process must contain a file reference number in the top right hand corner of the document.

The numbering structure must be as follows:

CHARACTERS MEANING POSSIBLE VALUES

1-4 Signifies the Year 2000 program Y2000