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