Page 233 -

204 PART TWO MANAGING SOFTWARE PROJECTS

FIGURE 8.2
Defect Development step
amplification Defects Detection
model
Errors passed through
Errors from Percent
previous step efficiency
Amplified errors 1 : x Errors passed
for error
detection to next step
Newly generated errors

8.4.2 Defect Amplification and Removal
A defect amplification model [IBM81] can be used to illustrate the generation and
detection of errors during the preliminary design, detail design, and coding steps
of the software engineering process. The model is illustrated schematically in Fig-
“Some maladies, as ure 8.2. A box represents a software development step. During the step, errors may
doctors say, at their be inadvertently generated. Review may fail to uncover newly generated errors and
beginning are easy
to cure but difficult errors from previous steps, resulting in some number of errors that are passed through.
to recognize . . . but In some cases, errors passed through from previous steps are amplified (amplifica-
in the course of time tion factor, x) by current work. The box subdivisions represent each of these charac-
when they have not teristics and the percent of efficiency for detecting errors, a function of the thoroughness
at first been
recognized and of the review.
treated, become Figure 8.3 illustrates a hypothetical example of defect amplification for a software
easy to recognize development process in which no reviews are conducted. Referring to the figure, each
but difficult to cure.” test step is assumed to uncover and correct 50 percent of all incoming errors with-
Niccolo Machiavelli out introducing any new errors (an optimistic assumption). Ten preliminary design
defects are amplified to 94 errors before testing commences. Twelve latent errors are
released to the field. Figure 8.4 considers the same conditions except that design and
code reviews are conducted as part of each development step. In this case, ten ini-
tial preliminary design errors are amplified to 24 errors before testing commences.
Only three latent errors exist. Recalling the relative costs associated with the dis-
covery and correction of errors, overall cost (with and without review for our hypo-
thetical example) can be established. The number of errors uncovered during each
of the steps noted in Figures 8.3 and 8.4 is multiplied by the cost to remove an error
(1.5 cost units for design, 6.5 cost units before test, 15 cost units during test, and 67
cost units after release). Using these data, the total cost for development and main-
tenance when reviews are conducted is 783 cost units. When no reviews are con-
ducted, total cost is 2177 units—nearly three times more costly.
To conduct reviews, a software engineer must expend time and effort and the
development organization must spend money. However, the results of the preceding
example leave little doubt that we can pay now or pay much more later. Formal tech-