Measurement assigns numbers or symbols to attributes of entities in the real word. To accomplish this, a measurement model encompassing a c...

Measurement assigns numbers or symbols to attributes of entities in the real word. To accomplish this, a measurement model encompassing a consistent set of rules is required. It is worthwhile to establish a fundamental framework and a set of basic principles for the measurement of technical metrics for software.

**The Challenge of Technical Metrics**

Over the past three decades, many researchers have attempted to develop a single metric that provides a comprehensive measure of software complexity. Fenton characterizes this research as a search for “the impossible holy grail.” Although dozens of complexity measures have been proposed, each takes a somewhat different view of what complexity is and what attributes of a system lead to complexity. By analogy, consider a metric for evaluating an attractive car. Some observers might emphasize body design, others might consider mechanical characteristics, still others might tout cost, or performance, or fuel economy, or the ability to recycle when the car is junked. Since any one of these characteristics may be at odds with others, it is difficult to derive a single value for “attractiveness.” The same problem occurs with computer software.

Yet there is a need to measure and control software complexity. And if a single value of this quality metric is difficult to derive, it should be possible to develop measures of different internal program attributes (e.g., effective modularity, functional independence, and other attributes ). These measures and the metrics derived from them can be used as independent indicators of the quality of analysis and design models. But here again, problems arise. Fenton notes this when he states:

The danger of attempting to find measures which characterize so many different attributes is that inevitably the measures have to satisfy conflicting aims. This is counter to the representational theory of measurement.

Although Fenton’s statement is correct, many people argue that technical measurement conducted during the early stages of the software process provides software engineers with a consistent and objective mechanism for assessing quality.

It is fair to ask, however, just how valid technical metrics are. That is, how closely aligned are technical metrics to the long-term reliability and quality of a computerbased system? Fenton addresses this question in the following way:

In spite of the intuitive connections between the internal structure of software products [technical metrics] and its external product and process attributes, there have actually been very few scientific attempts to establish specific relationships. There are a number of reasons why this is so; the most commonly cited is the impracticality of conducting relevant experiments.

**Measurement Principles**

Before we introduce a series of technical metrics that

**(1)**assist in the evaluation of the analysis and design models,

**(2)**provide an indication of the complexity of procedural designs and source code, and

**(3)**facilitate the design of more effective testing, it is important to understand basic measurement principles. Roche suggests a measurement process that can be characterized by five activities:

**• Formulation.**The derivation of software measures and metrics that are appropriate for the representation of the software that is being considered.

**• Collection.**The mechanism used to accumulate data required to derive the formulated metrics.

**• Analysis.**The computation of metrics and the application of mathematical tools.

**• Interpretation.**The evaluation of metrics results in an effort to gain insight into the quality of the representation.

**• Feedback.**Recommendations derived from the interpretation of technical metrics transmitted to the software team.

The principles that can be associated with the formulation of technical metrics are

**•**The objectives of measurement should be established before data collection begins.

**•**Each technical metric should be defined in an unambiguous manner.

**•**Metrics should be derived based on a theory that is valid for the domain of application (e.g., metrics for design should draw upon basic design concepts and principles and attempt to provide an indication of the presence of an attribute that is deemed desirable).

**•**Metrics should be tailored to best accommodate specific products and processes .

Although formulation is a critical starting point, collection and analysis are the activities that drive the measurement process. Roche suggests the following principles for these activities:

**•**Whenever possible, data collection and analysis should be automated.

**•**Valid statistical techniques should be applied to establish relationships

between internal product attributes and external quality characteristics (e.g., is the level of architectural complexity correlated with the number of defects reported in production use?).

**•**Interpretative guidelines and recommendations should be established for each metric.

In addition to these principles, the success of a metrics activity is tied to management support. Funding, training, and promotion must all be considered if a technical measurement program is to be established and sustained.

**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 highquality software really is.

Ejiogu 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 metric, and its computation should not demand inordinate effort or time.

**• Empirically and intuitively persuasive.**The metric should satisfy the engineer’s intuitive notions about the product attribute under consideration (e.g., a metric 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 of units. For example, multiplying people on the project teams by programming language variables in the program results in a suspicious mix of units that are not intuitively persuasive.

**• Programming language independent**. Metrics should be based on the analysis model, the design model, or the structure of the program itself. They should not be dependent on the vagaries of programming language syntax or semantics.

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

Although most software metrics satisfy these attributes, some commonly used metrics may fail to satisfy one or two of them. An example is the function point . It can be argued 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 satisfy one attribute perfectly.