To avoid circular arguments such as these I have attempted to create a metric representing the relative "work content" of each phase or layer of the solution.
Taking Karl Feilders 5 layers as a base, I would propose:
1. 5% Hardware and BIOS 2. 5% Operating System 3. 40% Application Software 4. 20% Data conversion to 4 digit years 5. 20% Interapplication/Intersystem data transferand I would add an additional
6. 10% Admin and Other
===========
100%
But this assumes that the research implicit in layers 3 and 4 has
been done.The heaviest time consumers that I have experienced are Research and Testing. It has taken me two years to do sufficient research to define adequate test procedures and do enough testing on applications to be able to make reasonable triage decisions. Testing and Research are ongoing and a moving target. One never seems to finish.
I would therefore add some further phases.
7. 40% Research
8. 50% Testing
9. 10% Training/Education
=========
100% (Giving a combined total of 200%)
So, to my mind we are underestimating the minimum amount
of work by at least 50%.Consolidating All of the above into one estimate, I get:
1. 2.5% Hardware and BIOS
2. 2.5% Operating System
3. 20% Application Software
4. 10% Data conversion to 4 digit years
5. 10% Interapplication/Intersystem data transfer
6. 5% Admin and Other
7. 20% Research
8. 25% Testing
9. 5% Training/Education
==========
100%
(Lotus) Worksheet to calculate active days
(Excel)In essence, BIOS is less than 3% of the problem, but most of the solution efforts are being placed on this one area. Many of the other issues are ignored or understated.
Admittedly layers 3 and 4 now have automated tools to assist in the process. But even if you have inventory assitance tools you still have evaluation and decision making to decide what you are going to do. And Data Sniffers tend to find, display and report on data problems but generally do not fix them.
This is my first hack at these numbers. They represent what I personally have experienced, and I invite constructive comment.
Chris Anderson 1998-08-23