Page 127 -

98 PART TWO MANAGING SOFTWARE PROJECTS

4.5.3 Defect Removal Efficiency
A quality metric that provides benefit at both the project and process level is defect
removal efficiency (DRE). In essence, DRE is a measure of the filtering ability of qual-
ity assurance and control activities as they are applied throughout all process frame-
work activities.
When considered for a project as a whole, DRE is defined in the following
manner:
? What is DRE = E/(E + D) (4-4)
defect
removal efficiency?
where E is the number of errors found before delivery of the software to the end-user
and D is the number of defects found after delivery.
The ideal value for DRE is 1. That is, no defects are found in the software. Realis-
tically, D will be greater than 0, but the value of DRE can still approach 1. As E increases
(for a given value of D), the overall value of DRE begins to approach 1. In fact, as E
increases, it is likely that the final value of D will decrease (errors are filtered out before
they become defects). If used as a metric that provides an indicator of the filtering abil-
ity of quality control and assurance activities, DRE encourages a software project team
to institute techniques for finding as many errors as possible before delivery.
DRE can also be used within the project to assess a team’s ability to find errors
before they are passed to the next framework activity or software engineering task.
For example, the requirements analysis task produces an analysis model that can be
Use DRE as a measure reviewed to find and correct errors. Those errors that are not found during the review
of the efficacy of your of the analysis model are passed on to the design task (where they may or may not
early SQA activities. If be found). When used in this context, we redefine DRE as
DRE is low during
analysis and design, DRE = E /(E + E i+1 ) (4-5)
i
i
i
spend some time
improving the way you where E is the number of errors found during software engineering activity i and
i
conduct formal E i+1 is the number of errors found during software engineering activity i+1 that are
technical reviews.
traceable to errors that were not discovered in software engineering activity i.
A quality objective for a software team (or an individual software engineer) is to
achieve DRE that approaches 1. That is, errors should be filtered out before they are
i
passed on to the next activity.
4.6 INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS

The majority of software developers still do not measure, and sadly, most have little
desire to begin. As we noted earlier in this chapter, the problem is cultural. Attempt-
ing to collect measures where none had been collected in the past often precipitates
resistance. "Why do we need to do this?" asks a harried project manager. "I don't see
the point," complains an overworked practitioner.
In this section, we consider some arguments for software metrics and present an
approach for instituting a metrics collection program within a software engineering