Software Quality Metrics

Bayaswal, B. & Patton, P. (2006, August 31). Software Quality Metrics. Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software. Retrieved from

Kan, S. H. (2002, December 20). Software Quality Metrics Overview. InformIT. Retrieved from


The Bellcore Quality Assurance Engineering, Software (QAES) group for Bellcore Client Companies (BCCs) has developed and implemented a comprehensive quality assurance program that focuses on resolving the underlying problems associated with developing quality software. The objective of Bellcore's QAES's surveillance program is to develop "cooperative" relationships that cause vendors to focus on (1) implementing methods and techniques to improve control of software development (2) improving the effectiveness of the underlying process used to develop and support software, thus improving the quality (3) understanding the needs and requirements of the BCCs. This chapter discusses this approach and explores the measurements utilized whose objectives are:

.assure adequate vendor quality control

.Minimize defects

.Optimize buyer satisfaction


1. Assure adequate vendor quality control: Measures have been implemented in the surveillance program to track the accomplishment of milestone criteria. These include:

.Requirements, design, coding and unit test-phase


phase deliverable completion

number of open correction actions requests

review coverage

.test-phase measurements

test coverage as measured by structure, functions or


number of test cases executed and passed

number of trouble reports

number of open trouble reports by severity

trouble report initiation rates

product specific quality, reliability and stability

2. Minimize defects and improve the effectiveness of the software development process:

.Review of software development artifacts (e.g. requirements

specifications and code) and testing results provide

measurable evidence about the effectiveness of the

implemented software development process, that is

specific information about the type and quantity of

defects produced.

.Specific measurements used in "real time" to minimize

defects include:

average number of defects detected in modules

and subsystems by type

historical system, subsystem and module fault


number of defects detected during reviews

3. A Long term approach is the collection of comprehensive defect data. Information about defect type, its origin, the mechanism used for detection, and defect severity are required to isolate ineffective processes and detection mechanisms. Defects found during reviews and testing are classified according to the phase detected (x axis) and originated (y axis). After defect data are accumulated simple calculations will determine the percentage of total defects attributable to certain phases of the life cycle

and the effectiveness of phase defect detection efforts. For example, the percentage of total defects attributable to "requirements" is calculated as the total number of requirements defects divided by the total number of defects multiplied by 100.

4. Quality and reliability measures include:

.Number and duration of system outages due to software failure

.Number of customer trouble reports

.Customer trouble report cause analysis

.Patch statistics where a patch is defined as an interim fix

5. Buyer support measures include:

.Customer services response time

.Number of open trouble reports

.Site distribution of open fault reports

.Aging of open customer trouble reports by severity

.Time-to-correct customer trouble reports


1. Grady, R.B. "Masuring and managing software maintenance. "IEEE Software, September 1987, pp. 35-45.

2. Jones, T C Programmer Productivity, McGraw-Hill, New York, 1986.


Hon, S E "Assuring Software Quality through Measurements: A Buyer's Perspective" Journal of Systems Software. Vol 13. 1990. pp. 117-130.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License