|
This analysis by a programmer involved in y2k analysis indicates why y2k is a systemic problem, and why testing eats up 50% of a repair team's resources.
This is from Westergaard's site.
* * * * * * * * *
With physical things, it is quite easy to determine where "The Battleship" ends and "The Aircraft Carrier" begins. Not so with software systems.
Software systems have been put into place over long periods of time. While they may have begun life several decades ago as freestanding systems with clearly defined edges, what happens over time is that subsystems are slapped on the periphery. Interfaces are added between previously freestanding systems. Boundaries become blurred.
After an amazingly short period of time, it becomes virtually impossible to know precisely where one system begins and another ends. What is even more difficult to understand is how processing in one system affects processing in another system.
It is entirely probable that due to incomplete historical knowledge, analysts will assume that system A just feeds system B. What is missed is that data that comes from A can pass untouched through B and then trigger something in system C. The connection between A and C can be easily obscured, unless you happen to know about them.
In the real world, of course, it's more likely that data from system A moves passively through systems B through Y and then triggers something in system Z. The chances of the owners of A and Z recognizing their co-dependency is very slim. Now do we understand why testing is expected to consume 50%+ of Y2K project efforts?
|