1. Conducting a software inventory

a. Grouped by sub-system (components)

2. Establishing the critical event horizon

a. Systems (applications) deliveries to TMOD or Projects

b. Delivery of changes

3. Identifying 2-digit year exposures

a. Locate references to date-related data and formats

b. Trace the flow of data through each reference

c. Investigate how other software applications share your data

4. Assessing the impact of each application

a. No Impact:

i. The program uses an undefined year representation that does not specifically define the exact year in all occurences.

ii. The program uses a 2-digit year representation within a program, but does not use the date in any calculations or compare functions, and/or does not output the 2-digit year in any way (program to program, database files, printer files, display files).

iii. The 2-digit year is externalized, but only to a printer file or display file.

b. Impact:

Any other situation that is NOT covered on the obove descriptions.

5. Considering implementation alternatives

a. Update

b. Replace

c. Covert (approaches)

i. Conversion to Full-Year format

Convert YY to YYYY or CYY format (where 'C' is a zero if the first two of a year are "19" and a one if the first two digits are "20").

ii. Windowing technique

Where you can determine the first two-digit year within a 100-year window that is hardcoded. For example, assuming the anchor date is 40. Then if the 2-digit year is equal to or greater than 40, the year begins with a "19." When the 2-digit year is less than 40, the year begins with "20." This provides for a 100-year window from 1940 to 2039.

iii. Encoding or compression format

This technique uses the same two digits for the year, but changes how the digits are used so that more than 100 years can be expressed. For example, an encoding format that is often considered is the use of hex values in the 2-digit year field so that 256 years could be represented.

6. Implementing and testing the solution

Requires the development of a Test Plan, Test Cases, Test Procedures, Test Scripts and a Test Database for Test Data and Test Results

a. Unit Testing

i. Allow the system date to age from December 21, 1999 to january 6, 2000

ii. Allow the system date to range from 1996 to 2050 for specific components (sub-systems)

iii. Checking leap year calculations after the date has changed to or beyond January 1, 2000

iv. Checking the invalid dates

v. Performing save operations with the system date set to the current date and performing restore operations after setting the system date back to the current date

vi. Commuication from system to system with the system date set to or beyond January 1, 2000.

b. Integration Testing

c. System Testing

d. Acceptance Testing

i. Structural Testing

a. Operations testing

b. Stress testing

c. Recovery testing

ii. Functional Testing

a. Requirements testing

b. Regression testing

c. Error handling testing

d. Manual support testing

e. Intersystem testing

f. Parallel testing

g. Sending and receiving data with other systems.

Other Issues during Testing:

i. Developing Test Data

ii. Archiving Data Tested

iii. Maintaining and Tracking Test Results