Chapter 14: The Grady Experience

Above all else, the goal of analysis is human understanding of systems and their problem domains.

In a recent study [1], Grady identified cost components of software development across the whole lifecycle, including maintenance and functionality enhancements. The cost percentages assigned to the different components stem from a combination of educated guesses and empirical data obtained from inside and outside of Hewlett-Packard:

Component Percentage
Program understanding 27%
Requirements analysis 24%
Design 18%
Implementation 18%
Testing 13%

Grady estimates that 27% of the total cost must be attributed to ``program understanding''. This is a separate component from requirements analysis, design, implementation, and testing. It represents the efforts of analyzing what existing artifacts are all about before remedial actions can be taken in the case of bug fixes, or, in other cases, before functionality extensions can be performed.

One may wonder why the program understanding component absorbs such a large fraction of costs. A glimpse of an explanation may be found in another set of data presented in [1]. Each of the four other components were further split into two categories: Work, the effort spent during the first time in the cycle; and Rework, the accumulated efforts from all the other iterations.

The following table demonstrates that rework plus program understanding accounts for 60% of costs. These contribute little to the implementation efforts. Assuming that code size correlates with coding effort, the code grows as a result of rework by about 1/4.

Component Work Rework
Requirements analysis 7% 17%
Design 7% 11%
Implementation 14% 4%
Testing 12% 1%

We conjecture that the key to the substantial program understanding component resides in the initial efforts. The initial analysis, design and implementation efforts have the ratio 1:1:2. We surmise that implementations start before the task is sufficiently understood and before a reasonable design has been constructed. Once an initial implementation has been obtained, the damage is done. The analysis and design outputs are insufficient guides for maintaining and enhancing the system.

Grady's account of the cost components is somewhat tentative. Still we recommend that the reader go back to the beginning of Part I.

References

1
B. Grady. An investment model for software process improvement. Technical report, Hewlett-Packard Corporate Engineering, February 1992.

Next: Chapter 15



Doug Lea
Wed May 10 07:54:18 EDT 1995