Product Metrics for Software
Chapter 15
Software Engineering: A Practitioner’s Approach
Roger S. Pressman
What are product metrics?
Metrics: measurable ways to design and
assess the software product
Process and project metrics apply to the
project as a whole
Project metrics focus on specific attributes
of the project
Collected as technical tasks are being
conducted
Software quality
Conformance to explicitly stated
functional and performance requirements,
explicitly documented development
standards, and implicit characteristics
that are expected of all professionally
developed software.
McCall’s quality factors
Two categories of software quality factors:
Factors that can be directly measured (bugs or
defects)
Factors that can be measured only indirectly
(usability or maintainability)
Both sets can (and should) be measured
McCall’s quality factors
McCall, Richards, and Walters group these factors
into three categories, focused on three aspects of a
software product:
Its operational characteristics
(PRODUCT OPERATION)
Its ability to undergo change
(PRODUCT REVISION)
Its adaptability to new environments
(PRODUCT TRANSITION)
McCall’s quality factors
Product Operation
Correctness:
the extent to which a program satisfies its
specifications and fulfills the customer’s
mission objectives
Reliability:
the extent to which a program can be expected
to perform its intended function with required
precision
Usability:
the amount of computing resources and code
required by the program to perform its function
Product Operation (cont.)
Integrity:
the extent to which access to software or data by
unauthorized persons can be controlled
Efficiency:
the effort required to learn, operate, prepare input for,
and interpret output of a program
Product Revision
Maintainability:
the effort required to locate and fix an error in a
program
Flexibility:
the effort required to modify an operational program
Testability:
the effort required to test a program to ensure that it
performs its intended function
Product Transition
Portability:
the effort required to transfer the program from
one hardware and/or software system to another
Reusability:
the extent to which a program (or parts or a
program) can be reused in other applications
Interoperability:
the effort required to couple one system to
another
McCall’s quality factors
It is difficult (and sometimes impossible) to
directly measure all of these quality factors
Many of McCall’s metrics can only be
measured subjectively
The metrics may be in the form of a
checklist to “grade” attributes of the
software
Clarifying definitions
Measure: within the software engineering
context, measure is a noun
A measure provides a quantitative of the extent,
amount, dimension, capacity, or size of some
attribute of a product or process.
Measurement: is the act of determining a
measure
Clarifying definitions
Metric:
“a quantitative measure of the degree to which
a system, component, or process possesses a
given attribute” -- IEEE Standard Glossary
Indicator:
a metric or combination of metrics that
provides insight into the software process,
project, or product itself.
Challenges of product metrics
Attempts to develop a single, all-
encompassing metric for software
complexity has been called a search for “the
impossible holy grail”
Of the dozens proposed, each takes a
slightly different (but valid) perspective
Challenges of product metrics
Valid metrics for evaluation of a new car:
Body design
Mechanical characteristics
Cost
Fuel economy
Performance
All valid metrics, but some may be at odds with
one another
Some metrics are subjective (“attractiveness”)
Challenges of product metrics
Challenges are cause for caution
However, these challenges are not cause to
dismiss product metrics entirely
Measurement is essential if quality is to be
achieved
Metrics for
Object-Oriented Design
Much about OO design is subjective - a
good programmer “knows” what makes
good code
To scale in size and complexity, a more
objective view can benefit both expert and
novice
Metrics for
Object-Oriented Design
Size Cohesion
Complexity Primitiveness
Coupling Similarity
Volatility
Sufficiency
Completeness
Metrics for
Object-Oriented Design
Size: defined in terms of four views:
Population: static count of OO entities such as
classes or operations
Volume: identical to population measure but
taken dynamically at a given instant in time
Length: measure of a chain of interconnected
design elements
Functionality: indirect indication of the value
delivered to the customer
Metrics for
Object-Oriented Design
Complexity
viewed in terms of structural characteristics by
examining how classes are related to one
another
Coupling
the physical connections between elements (e.g.
the number of messages passed between
objects)
Metrics for
Object-Oriented Design
Sufficiency
the degree to which a design component fully
reflects all properties of the application object it
is modeling
Completeness
like sufficiency, but the abstraction is
considered from multiple points of view, rather
than simply the current application
Metrics for
Object-Oriented Design
Cohesion
the degree to which the OO properties are part
of the problem or design domain
Primitiveness
applied to both operations and classes, the
degree to which an operation is atomic (similar
to simplicity)
Metrics for
Object-Oriented Design
Similarity
the degree to which multiple classes are similar
in terms of structure, function, behavior, or
purpose
Volatility
a measure of the likelihood that a change in
design will occur
The CK Metrics Suite
Chidamber and Kemerer have proposed six
class-based design metrics for OO systems:
Weighted methods per Coupling between
class (WMC) object classes (CBO)
Depth of the Response for a class
inheritance tree (DIT) (RFC)
Number of children Lack of cohesion in
(NOC) methods (LCOM)
The CK Metrics Suite
Depth of the Inheritance tree (DIT)
the maximum length from the node to the root
of the tree
as DIT grows, it becomes difficult to predict
behavior of a class because of the high degree
of inheritance
Positively, large DIT values imply that many
methods may be reused
The CK Metrics Suite
Number of children (NOC)
count of the subclasses immediately
subordinate to a class
as NOC grows, reuse increases
as NOC grows, abstraction can become diluted
increase in NOC means the amount of testing
will increase
The CK Metrics Suite
Coupling between object classes (CBO)
the number of collaborations listed for a class
as CBO increases, reusability of the class
decreases
high CBO values complicate modifications
in general, CBO values for each class should be
kept as low as possible
The CK Metrics Suite
Response for a class (RFC)
the number of methods that can potentially be
executed in response to a message received by
an object
as RFC increases, testing effort increases
because the test sequence grows
as RFC increases, the overall complexity of the
class increases
The CK Metrics Suite
Lack of cohesion in methods (LCOM)
measure of the number of methods within a
class that access the same instance variables
if no methods access the same attributes,
LCOM = 0
as LCOM increases, coupling between methods
(via attributes) increases, and thus class
complexity increases
