|
Comment: |
This document goes into the details of what it takes to test a system. It was prepared by a firm that provides y2k services, Tech-Beamers. Testing takes over 60% of the time and money devoted to a y2k repair project.
To assess whether a y2k repair project will be completed on time, find out when the project was begun. Calculate the number of months from the beginning until December 31, 1999. Then multiply this figure by 0.4. Add this figure -- the number of months needed until the date that testing must begin -- to the start date. This will give you the cut-off date when the preliminary phase of the project must be completed, with all the time remaining devoted to testing, fixing, re-testing, fixing, and completion.
You will find that virtually no large system repair is on schedule, i.e., the public relations hand-out's promise: "We will be ready for testing on December 31, 1998."
* * * * * * * * *
"Industry consultants and users report that testing of the applications for the Year 2000 will be more than 60% of the project's time and expense. However, many corporations do not have project experience with testing of this order of magnitude. The results will often be significant cost over-runs and missed commitments that could lead to failure of many migration projects.
"Why is testing so difficult? The reason is that the number of conditions that can be tested is unbounded (infinite). As a result, testing is often done in a haphazard and arbitrary way. Though programmers are directed to build quality into their applications, there is little or no instruction or methodology provided on how this is to be accomplished. Some advocates of high re-use through "object programming" assert that they have the answer. Perhaps someday object oriented programming will significantly shorten the development cycle, and will greatly reduce the amount of testing required. However, the Year 2000 migration team is faced with a challenge that will not yield a single ideal solution. They must deal with "the facts on the ground." The logic of the application can not be determined by examining individuals' claims, but on the behavior of executing programs. Most of the programmers who wrote the application have likely moved on to new assignments, many left the company long ago. There may be knowledge of some applications. Typically, limited to the enterprise's "critical applications" which are run daily. However, there are likely hundreds more that are run on demand, or infrequently. Furthermore, for many programs, the source code is missing or not up to date. Decompiling, disassembling and translation is at best, a semi-automatic process. There is no fully automated way to make applications year 2000 compliant."
|