The Attributes of Effective Software Metrics

19.2.3 The Attributes of Effective Software Metrics

Hundreds of metrics have been proposed for computer software, but not all provide practical support to the software engineer. Some demand measurement that is too complex, others are so esoteric that few real world professionals have any hope of understanding them, and others violate the basic intuitive notions of what high- quality software really is.

Ejiogu [EJI91] defines a set of attributes that should be encompassed by effective software metrics. The derived metric and the measures that lead to it should be

• ? Simple and computable. It should be relatively easy to learn how to derive the

How should

we assess

metric, and its computation should not demand inordinate effort or time.

the quality of a • proposed Empirically and intuitively persuasive. The metric should satisfy the engineer’s

software metric?

intuitive notions about the product attribute under consideration (e.g., a met- ric that measures module cohesion should increase in value as the level of cohesion increases).

• Consistent and objective. The metric should always yield results that are unambiguous. An independent third party should be able to derive the same metric value using the same information about the software.

• Consistent in its use of units and dimensions. The mathematical computation of the metric should use measures that do not lead to bizarre combinations

Experience indicates of units. For example, multiplying people on the project teams by program- that a technical metric

will be used only if it is ming language variables in the program results in a suspicious mix of units intuitive and easy to

that are not intuitively persuasive. compute. If dozens of

• Programming language independent. Metrics should be based on the analysis “counts” have to be

made and complex model, the design model, or the structure of the program itself. They should computations are

not be dependent on the vagaries of programming language syntax or required, it’s unlikely

semantics. that the metric will be widely applied.

• An effective mechanism for high-quality feedback. That is, the metric should provide a software engineer with information that can lead to a higher- quality end product.

Although most software metrics satisfy these attributes, some commonly used met- rics may fail to satisfy one or two of them. An example is the function point (discussed

in Chapter 4 and again in this chapter). It can be argued 3 that the consistent and objective attribute fails because an independent third party may not be able to derive the same function point value as a colleague using the same information about the software. Should we therefore reject the FP measure? The answer is: “Of course not!” FP provides useful insight and therefore provides distinct value, even if it fails to sat- isfy one attribute perfectly.

19.3 M E T R I C S F O R T H E A N A LY S I S M O D E L

Technical work in software engineering begins with the creation of the analysis model. Data, functional, and

XRef

It is at this stage that requirements are derived and that a foundation for design is behavioral models are

established. Therefore, technical metrics that provide insight into the quality of the discussed in Chapters

analysis model are desirable.

11 and 12. 3 Please note that an equally vigorous counterargument can be made. Such is the nature of soft-

ware metrics.

PA R T T H R E E C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G

F I G U R E 19.3

Part of the Sensors analysis model

Test sensor

for SafeHome

Password

software

Zone inquiry

Zone setting

SafeHome

Sensor inquiry

Panic button

Activate/deactivate

Sensor status

Activate/deactivate

Alarm

Password, sensors . . .

alert

Monitoring & response

subsystem

System configuration data

Although relatively few analysis and specification metrics have appeared in the literature, it is possible to adapt metrics derived for project application (Chapter 4) for use in this context. These metrics examine the analysis model with the intent of predicting the “size” of the resultant system. It is likely that size and design complexity will be directly correlated.