Chapter 23

• Product Metrics

Slide Set to accompany

Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 1
2009). Slides copyright 2009 by Roger Pressman.
McCall’s Triangle of Quality
Maintainability Portability
Flexibility Reusability
Testability Interoperability

PRODUCT REVISION PRODUCT TRANSITION

PRODUCT OPERATION
Correctness Usability Efficiency
Reliability Integrity
These slides are designed to accompany Software
Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2
2009). Slides copyright 2009 by Roger Pressman.
A Comment

McCall’s quality factors w ere proposed in the early 1970s.

They are as valid tod ay as they w ere in that tim e. It’s likely
that softw are built to conform to these factors w ill exhibit
high quality w ell into the 21st century, even if there are
d ramatic changes in technology.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 3
2009). Slides copyright 2009 by Roger Pressman.
 Measures, Metrics and Indicators
• A measure provides a quantitative indication of the extent, amount,
dimension, capacity, or size of some attribute of a product or process
• The IEEE glossary defines a metric as “a quantitative measure of the
degree to which a system, component, or process possesses a given
attribute.”
• An indicator is a metric or combination of metrics that provide insight
into the software process, a software project, or the product itself

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 4
2009). Slides copyright 2009 by Roger Pressman.
Measurement Principles
• The objectives of measurement should be established before
data collection begins;
• Each technical metric should be defined in an unambiguous
manner;
• Metrics should be derived based on a theory that is valid for the
domain of application (e.g., metrics for design should draw upon
basic design concepts and principles and attempt to provide an
indication of the presence of an attribute that is deemed
desirable);
• Metrics should be tailored to best accommodate specific
products and processes [Bas84]

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 5
2009). Slides copyright 2009 by Roger Pressman.
Measurement Process
• Formulation. The derivation of software measures and metrics
appropriate for the representation of the software that is being
considered.
• Collection. The mechanism used to accumulate data required to derive
the formulated metrics.
• Analysis. The computation of metrics and the application of
mathematical tools.
• Interpretation. The evaluation of metrics results in an effort to gain
insight into the quality of the representation.
• Feedback. Recommendations derived from the interpretation of
product metrics transmitted to the software team.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 6
2009). Slides copyright 2009 by Roger Pressman.
Goal-Oriented Software Measurement
• The Goal/Question/Metric Paradigm
• (1) establish an explicit measurement goal that is specific to the process
activity or product characteristic that is to be assessed
• (2) define a set of questions that must be answered in order to achieve the
goal, and
• (3) identify well-formulated metrics that help to answer these questions.
• Goal definition template
• Analyze {the name of activity or attribute to be measured}
• for the purpose of {the overall objective of the analysis}
• with respect to {the aspect of the activity or attribute that is considered}
• from the viewpoint of {the people who have an interest in the measurement}
• in the context of {the environment in which the measurement takes place}.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 7
2009). Slides copyright 2009 by Roger Pressman.
Metrics Attributes
• Simple and computable. It should be relatively easy to learn how to derive the
metric, and its computation should not demand inordinate effort or time
• Empirically and intuitively persuasive. The metric should satisfy the engineer’s
intuitive notions about the product attribute under consideration
• Consistent and objective. The metric should always yield results that are
unambiguous.
• Consistent in its use of units and dimensions. The mathematical computation
of the metric should use measures that do not lead to bizarre combinations of
unit.
• Programming language independent. Metrics should be based on the analysis
model, the design model, or the structure of the program itself.
• Effective mechanism for quality feedback. That is, the metric should provide a
software engineer with information that can lead to a higher quality end
product

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 8
2009). Slides copyright 2009 by Roger Pressman.
 Collection and Analysis Principles
• Whenever possible, data collection and analysis should be
automated;
• Valid statistical techniques should be applied to establish relationship
between internal product attributes and external quality
characteristics
• Interpretative guidelines and recommendations should be
established for each metric

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 9
2009). Slides copyright 2009 by Roger Pressman.
 Metrics for the Requirements Model
• Function-based metrics: use the function point as a normalizing
factor or as a measure of the “size” of the specification
• Specification metrics: used as an indication of quality by measuring
number of requirements by type

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 10
2009). Slides copyright 2009 by Roger Pressman.
 Function-Based Metrics
• The function point metric (FP), first proposed by Albrecht [ALB79], can be used effectively
as a means for measuring the functionality delivered by a system.
• Function points are derived using an empirical relationship based on countable (direct)
measures of software's information domain and assessments of software complexity
• Information domain values are defined in the following manner:
• number of external inputs (EIs)
• number of external outputs (EOs)
• number of external inquiries (EQs)
• number of internal logical files (ILFs)
• Number of external interface files (EIFs)

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 11
2009). Slides copyright 2009 by Roger Pressman.
Function Points

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 12
2009). Slides copyright 2009 by Roger Pressman.
 Architectural Design Metrics
• Architectural design metrics
• Structural complexity = g(fan-out)
• Data complexity = f(input & output variables, fan-out)
• System complexity = h(structural & data complexity)

• Morphology metrics: a function of the number of modules and the

number of interfaces between modules
• DSQI metric(Design structure Quality Index)

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 13
2009). Slides copyright 2009 by Roger Pressman.
Metrics for OO Design-I
• Whitmire [Whi97] describes nine distinct and measurable characteristics
of an OO design:
• Size
• Size is defined in terms of four views: population, volume, length, and functionality
• Complexity
• How classes of an OO design are interrelated to one another
• Coupling
• The physical connections between elements of the OO design
• Sufficiency
• “the degree to which an abstraction possesses the features required of it, or the
degree to which a design component possesses features in its abstraction, from the
point of view of the current application.”
• Completeness
• An indirect implication about the degree to which the abstraction or design
component can be reused

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 14
2009). Slides copyright 2009 by Roger Pressman.
 Metrics for OO Design-II
• Cohesion
• The degree to which all operations working together to achieve a single, well-defined
purpose
• Primitiveness
• Applied to both operations and classes, the degree to which an operation is atomic
• Similarity
• The degree to which two or more classes are similar in terms of their structure, function,
behavior, or purpose
• Volatility
• Measures the likelihood that a change will occur

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 15
2009). Slides copyright 2009 by Roger Pressman.
Distinguishing Characteristics

Berard [Ber95] argues that the following characteristics

require that special OO metrics be developed:

• Localization—the way in which information is concentrated in a

program
• Encapsulation—the packaging of data and processing
• Information hiding—the way in which information about operational
details is hidden by a secure interface
• Inheritance—the manner in which the responsibilities of one class
are propagated to another
• Abstraction—the mechanism that allows a design to focus on
essential details

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 16
2009). Slides copyright 2009 by Roger Pressman.
Class-Oriented Metrics
Proposed by Chidamber and Kemerer [Chi94]:

• weighted methods per class

• depth of the inheritance tree
• number of children
• coupling between object classes
• response for a class
• lack of cohesion in methods

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 17
2009). Slides copyright 2009 by Roger Pressman.
 Object Oriented Metrics
Terminologies
S.No Term Meaning/purpose
1 Object Object is an entity able to save a state (information)
and offers a number of operations (behavior) to
either examine or affect this state.
2 Message A request that an object makes of another object to
perform an operation.
3 Class A set of objects that share a common structure and
common behavior manifested by a set of methods;
the set serves as a template from which object can
be created.
4 Method an operation upon an object, defined as part of the
declaration of a class.
5 Attribute Defines the structural properties of a class and
unique within a class.
6 Operation An action performed by or on an object, available
to all instances of class, need not be unique.
18
 Object Oriented Metrics
Terminologies

S.No Term Meaning/purpose

7 Instantiation The process of creating an instance of the object
and binding or adding the specific data.
8 Inheritance A relationship among classes, where in an object
in a class acquires characteristics from one or
more other classes.
9 Cohesion The degree to which the methods within a class
are related to one another.
10 Coupling Object A is coupled to object B, if and only if A
sends a message to B.

19
 Object Oriented Metrics

• Measuring on class level

– coupling
– inheritance
– methods
– attributes
– cohesion
• Measuring on system level

20
 Object Oriented Metrics

Size Metrics:
 Number of Methods per Class (NOM)

 Number of Attributes per Class (NOA)

• Weighted Number Methods in a Class (WMC)

– Methods implemented within a class or the sum of the
complexities of all methods

21
 Object Oriented Metrics
Coupling Metrics:
• Response for a Class (RFC )
– Number of methods (internal and external) in a class.

 Data Abstraction Coupling(DAC)

- Number of Abstract Data Types in a class.

 Coupling between Objects (CBO)

– Number of other classes to which it is coupled.

22
 Object Oriented Metrics

• Message Passing Coupling (MPC)

– Number of send statements defined in a class.

• Coupling Factor (CF)

– Ratio of actual number of coupling in the system to
the max. possible coupling.

23
 Object Oriented Metrics
Cohesion Metrics:
 LCOM: Lack of cohesion in methods
– Consider a class C1 with n methods M1, M2…., Mn. Let (Ij)
= set of all instance variables used by method Mi. There
are n such sets {I1},…….{In}. Let
P  {( Ii , I j ) | Ii  I j  0} and Q  {( (Ii , I j ) | Ii  I j  0}
If all n {( I1},.........(In)}sets are 0 then P=0

LCOM | P | - | Q |, if | P |  | Q |
 0 otherwise

24
 Object Oriented Metrics

• Tight Class Cohesion (TCC)

_ Percentage of pairs of public methods of the class
with common attribute usage.
• Loose Class Cohesion (LCC)
– Same as TCC except that this metric also
consider indirectly connected methods.
• Information based Cohesion (ICH)
– Number of invocations of other methods of the same
class, weighted by the number of parameters of the
invoked method.

25
 Object Oriented Metrics

Inheritance Metrics:

• DIT - Depth of inheritance tree

• NOC - Number of children

– only immediate subclasses are counted.

26
 Object Oriented Metrics

Inheritance Metrics:
• AIF- Attribute Inheritance Factor
– Ratio of the sum of inherited attributes in all classes of the
system to the total number of attributes for all classes.


TC
A d (Ci )
AIF  i 1


TC
i 1
Aa(Ci )
Aa(Ci )  Ai(Ci )  Ad (Ci )

TC= total number of classes

Ad (Ci) = number of attribute declared in a class
Ai (Ci) = number of attribute inherited in a class
27
 Object Oriented Metrics

Inheritance Metrics:
• MIF- Method Inheritance Factor
– Ratio of the sum of inherited methods in all classes of the
system to the total number of methods for all classes.


TC
Mi(Ci)
MIF  i 1


TC
i 1
Ma(Ci)

Ma(Ci)  Mi(Ci)  Md(Ci)

TC= total number of classes
Md(Ci)= the number of methods declared in a class
Mi(Ci)= the number of methods inherited in a class
28
Class-Oriented Metrics
The M OOD M etrics Suite [Har98b]:

• Method inheritance factor

• Coupling factor

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 29
2009). Slides copyright 2009 by Roger Pressman.
Operation-Oriented Metrics

Proposed by Lorenz and Kidd [Lor94]:

Class Size : The overall class size can be determined using

the following measures:
• The total number of operations (both inherited and
private instance operations) that are encapsulated
within the class.
• The number of attributes (both inherited and private
instance attributes) that are encapsulated by the class

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 30
2009). Slides copyright 2009 by Roger Pressman.
Component-Level Design Metrics

• Cohesion metrics: a function of data objects and the

locus of their definition
• Coupling metrics: a function of input and output
parameters, global variables, and modules called
• Complexity metrics: hundreds have been proposed
(e.g., cyclomatic complexity)

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 31
2009). Slides copyright 2009 by Roger Pressman.
Interface Design Metrics
• Layout appropriateness: a function of layout entities, the
geographic position and the “cost” of making transitions
among entities

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 32
2009). Slides copyright 2009 by Roger Pressman.
Design Metrics for WebApps

• Does the u ser interface prom ote u sability?

• Are the aesthetics of the WebApp appropriate for the application
d om ain and pleasing to the u ser?
• Is the content d esigned in a m anner that im parts the m ost
inform ation w ith the least effort?
• Is navigation efficient and straightforw ard ?
• H as the WebApp architectu re been d esigned to accom m od ate the
special goals and objectives of WebApp u sers, the stru ctu re of
content and fu nctionality, and the flow of navigation requ ired to
u se the system effectively?
• Are com ponents d esigned in a m anner that red u ces proced u ral
com plexity and enhances the correctness, reliability and
perform ance?

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 33
2009). Slides copyright 2009 by Roger Pressman.
 Code Metrics
• Halstead’s Software Science: a comprehensive collection of metrics
all predicated on the number (count and occurrence) of operators
and operands within a component or program
• It should be noted that Halstead’s “laws” have generated substantial
controversy, and many believe that the underlying theory has flaws.
However, experimental verification for selected programming languages has
been performed (e.g. [FEL89]).

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 34
2009). Slides copyright 2009 by Roger Pressman.
 Metrics for Testing
• Testing effort can also be estimated using metrics derived from
Halstead measures
• Binder [Bin94] suggests a broad array of design metrics that have a
direct influence on the “testability” of an OO system.
• Lack of cohesion in methods (LCOM).
• Percent public and protected (PAP).
• Public access to data members (PAD).
• Number of root classes (NOR).
• Fan-in (FIN).
• Number of children (NOC) and depth of the inheritance tree (DIT).

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 35
2009). Slides copyright 2009 by Roger Pressman.
 Maintenance Metrics
• IEEE Std . 982.1-1988 [IEE94] su ggests a software maturity index
(SMI) that provid es an ind ication of the stability of a softw are
prod u ct (based on changes that occu r for each release of the
prod u ct). The follow ing inform ation is d eterm ined :
• M T = the nu m ber of m od u les in the current release
• Fc = the nu m ber of m od u les in the current release that have been changed
• Fa = the nu m ber of m od u les in the current release that have been ad d ed
• Fd = the nu mber of m od u les from the p reced ing release that w ere d eleted
in the current release
• The softw are m atu rity ind ex is com pu ted in the follow ing m anner:
• SMI = [M T - (Fa + Fc + Fd)]/ M T
• As SMI approaches 1.0, the prod u ct begins to stabilize.

These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 36
2009). Slides copyright 2009 by Roger Pressman.