Software Quality Metrics- An Example!

A definition of software quality metrics is - A measure of some property of a piece of software or its specifications.

Basically, as applied to the software product, a software metric measures (or quantifies) a characteristic of the software. Some common software metrics are:-

•Source lines of code.
•Cyclomatic complexity, is used to measure code complexity.
•Function point analysis (FPA), is used to measure the size (functions) of software.
•Bugs per lines of code.
•Code coverage, measures the code lines that are executed for a given set of software tests.
•Cohesion, measures how well the source code in a given module work together to provide a single function.
•Coupling, measures how well two software components are data related, i.e. how independent they are.

The above list is only a small set of software metrics, the important points to note are:-

•They are all measurable, that is they can be quantified.
•They are all related to one or more software quality characteristics.

The last point, related to software characteristics, is important for software process improvement. Metrics, for both process and software, tell us to what extent a desired characteristic is present in our processes or our software systems. Maintainability is a desired characteristic of a software component and is referenced in all the main software quality models (including the ISO 9126). One good measure of maintainability would be time required to fix a fault. This gives us a handle on maintainability but another measure that would relate more to the cause of poor maintainability would be code complexity. A method for measuring code complexity was developed by Thomas McCabe and with this method a quantitative assessment of any piece of code can be made. Code complexity can be specified and can be known by measurement, whereas time to repair can only be measured after the software is in support. Both time to repair and code complexity are software metrics and can both be applied to software process improvement.

We now see the importance of measurement (metrics) for the SDLC and SPI. It is metrics that indicate the value of the standards, processes, and procedures that SQA assures are being implemented correctly within a software project. SQA also collects relevant software metrics to provide input into a SPI (such as a CMMi continuous improvement initiative). This exercise of constantly measuring the outcome, then looking for a causal relationship to standards, procedures and processes makes SQA and SPI pragmatic disciplines.

Following section tries to pull the ideas of quality metrics, quality characteristics, SPI, SQC and SQA together with some examples by way of clarifying the definition of these terms.

The Software Assurance Technology Center (SATC), NASA, Software Quality Model includes Metrics

The table below cross references Goals, Attributes (software characteristics) and Metrics. This table is taken from the Software Assurance Technology Center (SATC) at NASA.

The relationship with Goals lends itself to giving examples of how this could be used in CMMi. If you look at the other quality models they have a focus on what comes under the Product (Code) Quality goal of the SATC model.

The reason SQA.net prefers the SATC quality model is:-


•The standard, including the new ISO 9126-1, quality models describe only the system behavioral characteristics.
•The SATC model includes goals for processes, (i.e. Requirements, Implementation and Testing).
•The SATC model can be used to reference all the CMMi, for example Requirements management (which includes traceability).
•If desired the SATC model can be expanded to accommadate grater risk mitigation in the specified goal areas, or other goal areas can be created.
•Demonstrating the relationship of metrics to quality characteristics and SPI (CMMI) is well served by the SATC quality model.

If you need to do this work in practice, you will need to select a single reference point for the Software Quality Model, then research the best metric for evaluating the characteristic. The importance of being able to break down a model of characteristics into measurable components indicates why these models all have a hierarchal form.