|
The state of Minnesota has compiled a list of problem areas for anyone attempting to replace defective embedded chips. The list of ways to deal with these problems is not comforting.
Anyone who thinks 15 billion chips, give or take a few billion, will be easy to test is not being realistic.
* * * * * * *
With an existing system in operation, there is a limited window available for installation and commissioning.
The current system may be old, not well understood, and/or poorly documented.
Replacement parts may not be available; a lot of computer software in use is over ten years old.
Training on the new system will require time and resources; both of which may be limited.
Risk management issues arise for those applications whose replacement is scheduled to be completed prior to the year 2000, but which has the potential to be delayed or even canceled.
The business risk arises from the lead times necessary to perform the conversion after the project fails to meet Year 2000 deadlines. Custom-developed applications may have inadequate date handlers. Changing or recreating source code can be costly and time-consuming.
Packaged software needs to be replaced with Year 2000 compliant upgrades or other replacement products.
Data might be lost during the conversion due to fields being modified. A "make" approach may require many new tools for the programming staff, including:
* Impact analysis systems.
* Change management or version control tools.
* Rapid change and replace utilities.
* Testing tools.
Dependencies, such as operating systems, database management systems, compilers, interfaces, etc., need to be Year 2000 compliant.
Interface dependencies introduce complexities when integrating the new system into the existing environment.
|