CIS210: Software Engineering and Development
Technical Metrics for Software
1. Technical Software Metrics
The technical software metrics help software engineers gain insight
into the design and construction of the software products they make.
It is necessary to apply technical software metrics in the development
process in order to achieve higher quality software products.
Technical metrics provide a basis for guiding the software engineering
process as they advice not only how to evaluate quantitatively the
software but also they give objective criteria for data design, algorithm
design, architecture design and database design.
The overall goal of software engineering is to produce a high quality
software product. In order to judge to what degree the software meets the
quality requirements technical software quality measures are defined.
Software quality can be defined as conformance to explicitly stated
functional and performance requirements, development standards, and
implicit properties that are expected from a professional software.
In this sense, three main groups of requirements can be identified:
 software requirements suggested by the user
 specified national and international standards
 unmentioned implicit requirements
2. McCall's Quality Factors
McCall defined the most complete set of factors that affect the
software quality.
These factors are objective because they focus
on the following inherent software characteristics:
 operational characteristics (product operation)
correctness
reliability
usability
integrity
efficiency
 ability to undergo change (product revision)
maintainability
flexibility
testability
 adaptability to new environments (product transition)
portability
reusability
interoperability
These factors may be used to develop a quantitative estimate
with the following expression:
Fq = c1 * m1 + c2 * m2 + ... cn * mn
where: Fq is the concrete quality factor
cn are regression coefficients
mn are the metrics that affect the corresponding quality factor
3. Effective Technical Software Metrics
Several requirements are established for judging the efficiency
of the technical software metrics.
A set of technical software metrics is effective if they possess
the following properties:
 simple and computable- the metrics should be easy to learn and use
 empirically convincing- they should satisfy the expectations of the
engineer
 consistent and objective- they should produce unambiguous results
 consistent in dimensionality- they should be mathematically
reasonable
 programming language independent
 facilitating feedback- they should provide useful information for
software improvement
4. Metrics for Software Analysis
The existing metrics can be adapted in order to get insight into the
quality of the analysis model, for example the FP metrics can be used.
4.1. Function-Point Metrics
4.2. Metrics for Specification Quality
The number of requirements in a software analysis model are:
nr = nf + nnf
where: nf is the number of functional requirements
nnf is the number of non-functional requirements
The lack of ambiguity of requirements can be assess with the consistency
of the reviewers interpretation of each requirements:
Q1 = nui / nr
where: nui is the number of requirements for which all reviewers agree
The completeness of the functional requirements can be determined
by computing the ratio:
Q 2 = n u / [ n i * ns ]
where: nu is the number of unique functional requirements
ni is the number of inputs according to the specification
ns is the number of specified system states
When the non-functional requirements are incorporated, the overall
completeness metric becomes:
Q 3 = n c / [ nc * n v ]
where: nc is the number of validated requirements
nv is the number of non-validated requirements
5. Metrics for the Design Model
There are three aspects of the software design process that should be
estimated:
 the software architecture
 the software program components
 the program interface
5.1 Architectural Design Metrics
Architectural design metrics focus on the characteristics of the software
program architecture without taking into account the internal structure.
The architectural metrics consider software programs as black-boxes.
Such architectural design metrics are:
 structural complexity- the i-th program module complexity is:
S( i ) = f2( i )
where: f( i ) is the number of modules directly invoked by i
 data complexity
D( i ) = v( i ) / ( f( i ) + 1 )
where: v( i ) is the number of input and output variables for module i
 system complexity is the sum of structural and data complexities
C( i ) = S( i ) + D( i )
Another software architecture metric contains estimates of the program
size, depth and width in a straightforward manner:
size = n + a
where: n is the number of nodes in the program data-flow diagram
a is the number of arcs, connections in the same diagram
depth- this is the longest path from the root to a leaf node
width- this is the maximum number of nodes in one particular level
The complexity density measures the connectivity of the software architecture
and provides indication for its coupling:
r=a/n
5.2 Component-Level Design Metrics
Component level metrics consider software programs as open-boxes.
Such component level metrics are:
 complexity metrics- McCabe cyclomatic complexity
 cohesion metrics- account for the functional independence, for
example by evaluating the following concepts:
- data slices- these are sequences of modules (or statements)
on the path from the program beginning to the analyzed point
- data tokens- these are the local variables in a module
- glue tokens- the tokens that belong to modules in a slice
The strong functional cohesion is a measure defined as follows:
SFC( i ) = SG ( SA( i ) ) / tokens( i )
where SG ( SA( i ) ) denotes the tokens that lie on all data slices for module i
When the ratio SFC increases toward the maximum value 1 the functional
cohesivenes of the module increases.
 coupling metrics- the module coupling indicates the degree of
linking of a module to other modules from the software program,
and to global data as well.
A module coupling indicator is defined as follows:
mc = k / M
where: k is proportionality constant
M is a factor
M = di + a*ci + d0 + b*c0 + gd + c*gc + w + r
di is number of input parameters
ci is is number of input control parameters
d0 is number of output data parameters
c0 is number of output control parameters
gd is number of global variables used as data
gc is number of global variables used as control
w is number of called modules
r is number of modules calling this module
a=b=c=2
Web Resources:
Foundations of Software Measurement
http://irb.cs.tu-berlin.de/~zuse/
Software Metric System for Module Coupling
http://ise.gmu.edu/faculty/ofut/rsrch/abstracts/mjcoupling.html