A Goal-Based Framework
for Software Measurement
’ essential role in good soware
engineering practice, and Chapter 2 shows how to apply a general
theory of measurement to soware. In this chapter, we present a concep-
tual framework for diverse soware measurement activities that you can
apply to an organization’s soware development practices. ese practices
may include development and maintenance activities, plus experiments
and case studies that evaluate new techniques and tools.
e framework presented here is based on two principle activities: clas-
sifying the entities to be examined and using measurement goals to iden-
tify relevant metrics. We show how such a goal-based framework supports
evaluations of soware products, processes, and soware development
organizations. We also look at measurement validation: both the process
of insuring that we are measuring what we say we are, so that we satisfy
the representation condition introduced in Chapter 2, as well as demon-
strating the utility of a measure.
3.1 CLASSIFYING SOFTWARE MEASURES
As we have seen in Chapter 2, the rst obligation of any soware mea-
surement activity is identifying the entities and attributes that we want to
measure. Soware entities can be classied as follows:
88 ◾ Software Metrics
• Processes: Soware-related activities.
• Products: Artifacts, deliverables, or documents that result from a
• Resources: Entities required by a process activity.
A process is usually associated with some time scale. Process activities
have duration—they occur over time, and they may be ordered or related
in some way that depends on time, so that one activity must be completed
before another can begin. e timing can be explicit, as when design must
be complete by October 31, or implicit, as when a ow diagram shows that
design must be completed before coding can begin.
Resources and products are associated with a process. Each process
activity uses resources and products, and produces products. us, the
product of one activity may feed another activity. For example, a design
document can be the product of the design activity, which is then used as
an input to the coding activity.
Many of the examples that we use in this book relate to the development
process or maintenance process. But the concepts that we introduce apply
to any process: the reuse process, the conguration management process,
the testing process, etc. In other words, measurement activities may focus
on any process and need not be concerned with the comprehensive devel-
opment process. As we show in Section 3.2, our choice of measurements
depends on our measurement goals.
Within each class of entity, we distinguish between internal and exter-
nal attributes of a product, process, or resource:
• Internal attributes: Attributes that can be measured purely in terms
of the product, process, or resource itself. An internal attribute can
be measured by examining the product, process, or resource on its
own, without considering its behavior.
• External attributes: Attributes that can be measured only with
respect to how the product, process, or resource relates to its envi-
ronment. Here, the behavior of the process, product, or resource is
important, rather than the entity itself.
To understand the dierence between internal and external attributes,
consider a set of soware modules. Without actually executing the code,
we can determine several important internal attributes: its size (perhaps