Software Metrics, 3rd Edition

87

Chapter 3

A Goal-Based Framework

for Software Measurement

C

   ’ essential role in good soware

engineering practice, and Chapter 2 shows how to apply a general

theory of measurement to soware. In this chapter, we present a concep-

tual framework for diverse soware measurement activities that you can

apply to an organization’s soware 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 soware products, processes, and soware 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 soware mea-

surement activity is identifying the entities and attributes that we want to

measure. Soware entities can be classied as follows:

88 ◾ Software Metrics

• Processes: Soware-related activities.

• Products: Artifacts, deliverables, or documents that result from a

process activity.

• 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 conguration 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 dierence between internal and external attributes,

consider a set of soware modules. Without actually executing the code,

we can determine several important internal attributes: its size (perhaps