Page 124 -

CHAPTER 4 SOFTWARE PROCESS AND PROJECT METRICS 95

to these questions is an emphatic “No!” The reason for this response is that many
factors influence productivity, making for "apples and oranges" comparisons that can
be easily misinterpreted.
Function points and LOC based metrics have been found to be relatively accu-
rate predictors of software development effort and cost. However, in order to use
LOC and FP for estimation (Chapter 5), a historical baseline of information must be
established.

4.5 METRICS FOR SOFTWARE QUALITY

The overriding goal of software engineering is to produce a high-quality system, appli-
cation, or product. To achieve this goal, software engineers must apply effective meth-
ods coupled with modern tools within the context of a mature software process. In
WebRef addition, a good software engineer (and good software engineering managers) must
An excellent source of measure if high quality is to be realized.
information on software The quality of a system, application, or product is only as good as the requirements
quality and related topics
(including metrics) can be that describe the problem, the design that models the solution, the code that leads
found at to an executable program, and the tests that exercise the software to uncover errors.
www.qualityworld. A good software engineer uses measurement to assess the quality of the analysis and
com
design models, the source code, and the test cases that have been created as the soft-
ware is engineered. To accomplish this real-time quality assessment, the engineer
must use technical measures (Chapters 19 and 24) to evaluate quality in objective,
rather than subjective ways.
XRef
The project manager must also evaluate quality as the project progresses. Private
A detailed discussion of
software quality metrics collected by individual software engineers are assimilated to provide project-
assurance activities is level results. Although many quality measures can be collected, the primary thrust at
presented in Chapter 8.
the project level is to measure errors and defects. Metrics derived from these mea-
sures provide an indication of the effectiveness of individual and group software qual-
ity assurance and control activities.
Metrics such as work product (e.g., requirements or design) errors per function
point, errors uncovered per review hour, and errors uncovered per testing hour pro-
vide insight into the efficacy of each of the activities implied by the metric. Error data
can also be used to compute the defect removal efficiency (DRE) for each process frame-
work activity. DRE is discussed in Section 4.5.3.

4.5.1 An Overview of Factors That Affect Quality
Over 25 years ago, McCall and Cavano [MCC78] defined a set of quality factors that
were a first step toward the development of metrics for software quality. These fac-
tors assess software from three distinct points of view: (1) product operation (using
it), (2) product revision (changing it), and (3) product transition (modifying it to work
in a different environment; i.e., "porting" it). In their work, the authors describe the