metrics for code, testing and maintenance.
Ashikul Islam, 24387
University of Applied Sciences. [email protected]
In this paper, I show the knowledge of software quality
product metrics of code, testing and maintenance. Software product metrics are
used to measure the attributes those have been used to build the software
Keywords: Measurement, Metrics, KLOC, Cohesion, Maturity
Measurement is the key of any engineering process.
It is required to measure the understanding of the attributes used for the
product or system. “It is impossible to manage without measurement” (DeMarco, 1982).
The act of obtaining measure provides a quantitative indication of size of some
product or process attribute; E.g., number of errors. Software engineers can
get actual insights how the product should be designed and constructed. Some
metrics can easily be measure while some are measured indirectly. The goals of
software metrics are to reduce cost, overtime, workloads and identify how to
improve the product. For better productivity, software engineers use metrics to
prioritize, track and solve any kind of issues during the building of the
software. The sooner the problems are detected, the easier and less cost it
takes to troubleshoot them.
Software product metrics have been important over
a decade for it for the decision makings throughout the software development
process. The first step to measure the metrics are to represent the data that
is collected. Then the metrics are analyzed and computed. At the last stage,
modification and verification are performed through requirements, design,
source code, testing and maintenance.
Software quality metrics
Software quality metrics are classified into three
“Software quality metrics should be simple and
computable, empirical and intuitively persuasive, consistent and objective,
consistent in the use of units and dimensions, independent of programming
language and effective mechanism for quality feedback” (Ejiogu, 1991).
2.1 Direct Metrics
Software quality is a multidimensional concept. For every software
product, there are few metrics which are essential and inevitable. Understanding
is the most important metric. Any new user who is using the software product
should gain the basic understandings of the features in minimum time. A new
user must learn how to perform the basic functions of the software. Operation
time of software must be minimum for the new users to perform any operations.
The product is communicativeness only when the human factor is working well
like there is minimum number of negative feedbacks from the users. But it is
never easy to build software with such comprehensive measurements. There are
always some challenges, difficulties in the process of building a product.
Complexity measurement is a consistent metrics for the software engineers as
there can arise complexities in every step.
2.2 Quality factors
According to McCall, software quality factors are mainly into three
divisions. They are
These three factors relate more to the quality of the delivered product
rather than product in development process. In the product revision part, there
are maintainability, flexibility and testability. Maintainability ensures if
the product can be fixed, testability ensures if it can be tested and
flexibility ensures if it can be changed to another version of this product or
completely into new product. In the product operation part, there are
correctness, reliability, efficiency, integrity, usability. Correctness ensures
if the product is what the customer wants. Reliability ensures if the product
is working perfectly all the time. Efficiency ensures that it takes minimum
time to solve intended problems. Integrity ensures the security part while
usability ensures if the product is running. In the transition part, there are
portability, reusability and interoperability. The portability part ensures if
the product can be used on another different machine, reusability ensures if
any part of this product can be reused and interoperability ensures if the
product interfaces with different system.
Fig. McCall’s Software Quality Factors.
Software product metrics
Based on IEEE Computer Society definition, “The
application of a systematic, disciplined, quantifiable approach to the
development, operation and maintenance of software; that is, the application
engineering to software.” (IEEE 610.12). But product metrics for software may
be imperfect. It helps to find out catastrophic defects potential solutions for
those problems. Product metrics assessed the quality of the product while it is
engineered. To accomplish the perfect measurement, few certain rules are
Software product metrics have some attributes which
are needed to be measured properly in order to build a. A metric must have
mathematical properties. It should measure a factor independently to other
factors. Here are some product metrics factors
Total numbers of defects throughout
the building process and their types.
Documentation page numbers.
Source code line numbers before and after
Avg. module complexity.
Avg. module size.
Unit testing bug numbers.
Integration testing bug numbers.
Validation testing bug numbers.
Software product metrics for source code
Maurice Halstead proposed measurement of metrics
for source code. Using complete program length, minimum algorithm volume, actual
volume, program level, language level and some other features, the length and
N = n1log2n1
V = Nlog2(n1
n1 = distinct
n2 = distinct
N1 = operator
N2 = operand
software product metrics for testing
Analysis, design, code metrics must be measured
before starting testing metrics. There are two types of metrics for testing.
Breadth of testing: Total number of
requirements that have been tested.
Depth of testing: percentage of
independent basis paths covered by testing versus total number of basis paths
in the program.
Maurice Halstead measurements illustrate how to estimate
testing efforts. Using the definitions for program volume V and program level
PL, Halstead efforts e can be measured as
PL=1 / (n1/2) x
Metrics for object-oriented testing differs to
normal testing. For object-oriented, there are lack of cohesion methods,
percent public and protected, public access to data members, number of root
classes, fan-in, and number of children and depth of inheritance tree.
Software product Metrics for maintenance
For stable software product, Software Maturity
Index (SMI) by IEE Std. 982.1-2005IEEE05 is the best suggestion. If SMI=1.0, then the software is stable.
SMI correlates the mean time to produce stable software.
Software Maturity Index
number of modules in the current release
Fc = number
of modules in the current release that have been changed
Fa = number
of modules in the current release that have been added
Fd = number
of modules from the preceding release that were deleted in the current release
SMI = MT – (Fc + Fa + Fd) / MT
Software quality metrics ensures the quality of
the product before it is built. Halstead provides
an intriguing set of metrics at the source code level. Using the number of
operators and operands present in the code, software science provides a variety
of metrics that can be used to assess program quality. Few product metrics have
been proposed for direct use in software testing and maintenance. However, many
other product metrics can be used to guide the testing process and as a
mechanism for assessing the maintainability of a computer program. A wide
variety of OO metrics have been proposed to assess
the testability of an OO system.
Roger S. Pressman, Bruce R. Maxim, “Software engineering- a
practitioner’s approach” 8th edition, 2015.
K. Naik and P. Tripathy: “Software Testing and Quality Assurance”,
Ian Sommerville, Software Engineering, 8th edition, 2006.
Aditya P. Mathur,”Foundations of Software Testing”, Pearson Education,
D. Galin, “Software Quality Assurance: From Theory to Implementation”,
Pearson Education, 2004
David Gustafson, “Theory and Problems of Software Engineering”, Schaum’s
Outline Series, McGRAW-HILL,