Page 134 -

CHAPTER 4 SOFTWARE PROCESS AND PROJECT METRICS 105

• Effort (person-hours) required to make the change, W change .
• Time required (hours or days) to make the change, t change .
• Errors uncovered during work to make change, E change .
• Defects uncovered after change is released to the customer base, D change .
Once these measures have been collected for a number of change requests, it is pos-
sible to compute the total elapsed time from change request to implementation of
the change and the percentage of elapsed time absorbed by initial queuing, evalua-
tion and change assignment, and change implementation. Similarly, the percentage
of effort required for evaluation and implementation can be determined. These met-
rics can be assessed in the context of quality data, E change and D change . The percent-
ages provide insight into where the change request process slows down and may
lead to process improvement steps to reduce t queue , W eval , t eval , W change , and/or
E change . In addition, the defect removal efficiency can be computed as
DRE = E change / (E change + D change )

DRE can be compared to elapsed time and total effort to determine the impact of
quality assurance activities on the time and effort required to make a change.
For small groups, the cost of collecting measures and computing metrics ranges
from 3 to 8 percent of project budget during the learning phase and then drops to less
than 1 percent of project budget after software engineers and project managers have
become familiar with the metrics program [GRA99]. These costs can show a sub-
stantial return on investment if the insights derived from metrics data lead to mean-
ingful process improvement for the software organization.

4.9 ESTABLISHING A SOFTWARE METRICS PROGRAM
The Software Engineering Institute has developed a comprehensive guidebook [PAR96]
for establishing a “goal-driven” software metrics program. The guidebook suggests
the following steps:

1. Identify your business goals.
WebRef 2. Identify what you want to know or learn.
A Guidebook for Goal-
Driven Software 3. Identify your subgoals.
Measurement can be 4. Identify the entities and attributes related to your subgoals.
downloaded from
www.sei.cmu.edu 5. Formalize your measurement goals.
6. Identify quantifiable questions and the related indicators that you will use to
help you achieve your measurement goals.
7. Identify the data elements that you will collect to construct the indicators that
help answer your questions.
8. Define the measures to be used, and make these definitions operational.