It was however pointed out by McClure that research content was not the only problem in preparing estimates:
McClure: (from Projection versus performance in software production)
»Before undertaking a project to produce a new software system or component, read the following statements, checking all that apply:
1. The new system will be substantially superior to its predecessor and to competitive systems.
2. The new system corrects a basic philosophical defect in the previous system.
3. The specification is not yet complete, but it will be finished before any important programming decisions are made
4. The specification is absolutely firm, unless, of course, the Acme Company signs a big order and requests some slight changes.
5. The programming team will be made up by selecting only the best programmers from other projects.
6. Because of expansion, a fresh team of programmers with applicable experience will be hired.
7. The new computer is a great machine; the programmers will love it as soon as they can get their manuals.
8. The programmers will, of course, have to share the machine with the hardware team checking out the new peripherals and the diagnostic package.
9. Interfacing this system to the rest of the software is trivial and can be easily worked out later.
10. Although the assembler (compiler, loader, file system, etc.) is not completely checked out, it will be ready long before coding is complete.
11. The debug package isn’t done but this system can easily be checked out at the console.
12. The budget is only preliminary but it’s obviously conservative.
13. The project manager may have missed his budget on his last project, but he has learned his lesson and won’t miss this time.
For each statement checked on the preceding list add ten percent to the estimated cost and one month to the estimated time. If statement six is checked, add thirty per cent and six months. The result should come much closer to the final result than the original estimate under the assumption that the original estimate was honestly made.«
The major contribution on techniques for estimating the amount of time it will take to complete a system was by Nash.
Nash: (from Some problems of management in the production of large-scale software systems)
»Consider one of the most difficult problems facing producers of large software systems, namely, estimating the time required for completion. Suppose we could establish 100 equal teams to implement the same system, in as nearly equal conditions as could be achieved. Then the times actually required by the various teams would follow some distribution, which might be similar to that in figure 8. Even if we had such data to draw on, it is still no simple task to estimate a completion date for the same project thereafter. A sound approach would be to use the most likely time at the outset, but to take a progressively more conservative view as the development proceeded. The spread of the distribution curve would reduce as the end-point was approached as in figure 9, and at the point where a commitment should be made, a 90% probability would be more reasonable.
However in practice no such data exists and we have to rely on experience and judgement to assess the likely nature of such distributions. How, then, can commitments be made with any degree of certainty? There is one valuable tool available in the later parts of a development cycle, namely Test Status. In any large-scale software production, extensive testing is necessary, which normally takes the form of a large number of care