Software Metrics and Models

Software metrics refers to measuring the software qualitatively and quantitatively so that we arrive at a perfect assessment of software quality and other attributes of the Software Product.

McCall’s Qualitative metrics for assessing Software Quality

The above diagram shows McCall’s software quality factors which may be used to assess software quality during product revision. Accordingly, we may apply the factors correctness, reliability, usability, integrity and efficiency quality factors for quality assessments during product operations; portability, reusability, interoperability during product transition and maintainability, flexibility and testability during product revision.

Now, as it is difficult to develop a direct measure of the quality factors, McCall introduced a set of software quality metrics m1, m2, … m_n so that the software quality factor F_q is defined as –

F_q = C₁ * M₁ + C₂ * m_{2 +} ……. + C_n * m_n

where c1, c2 …. cn are regression coefficients.

Here, the value of m₁, m₂, …. m_n is according to a grading scheme from 0 (low) to 1 (high). Thus, we arrive at the following table for assessing software quality qualitatively and subjectively (since the grading is given subjectively).

Based on findings, correctness, reliability, efficiency and reusability can be measured using below metrics –

Software Quality Factor	Graded Software Quality Metric
Correctness	Completeness, Consistency, Traceability
Reliability	Accuracy, Complexity, Consistency, Error tolerance, Modularity, Simplicity
Efficiency	Concision, Execution efficiency, Operability
Reuability	Expandability, Modularity, Self Documentation, System, independence

The above results shows that for eg:, Software reliability may be measured in terms of quality measures in dimensions such as Accuracy, Complexity, Consistency, Error tolerance, Modularity and Simplicity. While calculating the quality factor for reliability, we assign various grades to the corresponding quality metrics. Other software quality factors are measured in the similar manner.

Technical Software Metrics

Like the qualitative software metrics, we may also apply quantitative software metrics for assessing various software attributes, thus ultimately assess software. Technical software metrics aids in –

• Evaluating the analysis and design models.
• Providing an indication of complexity of procedural designs and source code.
• Facilitating the design of effective testing and maintenance.

Even though the technical software metrics doesn’t seem to address directly on software quality, the actual outcome when the various technical metrics results are joined, will help us to assess software quality.

The following are the principles associated with the formulation of technical software metrics –

• The objective 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 valid for the domain of application.
• Metrics should be tailored to best accommodate specific products and processes.
• Data collection and analysis should be automated.
• Valid statistical techniques should be applied to derive relationships between internal product attributes and external quality characteristics.

The measurement in Technical Software metrics involves the following activities –

• Formulation involves derivation of the software measures and metrics that are appropriate for the representation of software that is being considered.
• Collection involves the mechanism to accumulate data required to derive the formulated metrics.
• Analysis involves computation of metrics and the application of mathematical tools.
• Interpretation involves evaluation of metric results in an effort to gain insight into the quality of representation.
• Feedback involves reviewing the recommendations derived from the interpretation of technical metrics from team members.

The attributes of effective software metrics in general and Technical software metrics in particular are as follows –

• It should be simple and comparable.
• It should be empirically and intuitively persuasive ie. the metric should represent high and low value of the attribute measured.
• It should be consistent and objective (though software quality metrics are subjective) and should give same results when examined by different experts.
• It should be consistent in its use of units and dimensions.
• It should not depend on the syntax and semantics of a particular programming language.
• It should enable Software Engineer to get feedback towards building high quality software product.

Davis’ Technical Software Metrics

Now let us see and example for Technical Software Metrics devised by Davis and his colleagues for assessing the quality of the an analysis model and its requirements specification. i.e. specificity, completeness, correctness, understandability, verifiability, internal and external consistency, achievability, concision, traceability, modifiability, precision and reusability. According to this specification quality metrics model, high quality analysis model specifications are electronically stored, executable or are at least interpretable, annotated by relative importance and stability, versioned, organized, cross referenced and is specified at the right level of detail. Some of the quantitative measurements of this specification quality metric are as follows –

If n_f <– functional requirements, n_nf <– non-functional requirements,

then, the number of requirements in a specification is given by,

n_r = n_f + n_nf

Now, if n_ui represents the number of requirements for which all the reviewers had identical interpretations, then the specificity metric or lack of ambiguity of requirements is given by-

Q_i = n_ui + n_r (values closer to 1 shows lower level of ambiguity.

Now, if n_u is the number of unique functional requirements, if n_i is the number of inputs/stimuli and is n_s is the number of states specified, then the Completeness metric for functional requirements can be determined as Q₂ –

Q₂ = n_u / n_i * n_s; Qz gives % of necessary functions that have been specified of the system. Q_z does not address functional requirements. Now if n_c is the number of correctly validated requirements and n_nv is number of requirements that have not yet been validated, then an overall metric for Completeness can be derived as Q₃,

Q₃ = n_c / n_c + n_nv; Q₃ considers the degree to which the requirements are validated.