Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e
copyright © 1996, 2001
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
This presentation, slides, or hardcopy may NOT be used for
short courses, industry seminars, or consulting purposes.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
1
Slide 21
Chapter 19
Technical Metrics for Software
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
2
SOFTWARE QUALITY
What is it?
Conformance to
• explicitly stated functional and performance
requirements
• Explicitly documented development standards
• Implicit characteristics that are expected of all
professionally developed standards
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
3
QUALITY FACTORS
2 broad groups:
Factors that can be directly measured
Defects per function-point
Factors that can be measured only indirectly
Eg. Usability, maintainability
McCall, Richards, & Walters propose:
Its operational characteristics
Its ability to undergo change
Its adaptability to new environment
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
4
McCall’s Triangle of Quality
Maintainability
Flexibility
Testability
PRODUCT REVISION
Portability
Reusability
Interoperability
PRODUCT TRANSITION
PRODUCT OPERATION
Correctness
Usability
Efficiency
Integrity
Reliability
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
5
A Comment
McCall’s quality factors were proposed in the
early 1970s. They are as valid today as they were
in that time. It’s likely that software built to conform
to these factors will exhibit high quality well into
the 21st century, even if there are dramatic changes
in technology.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
6
MEASUREMENT PRINCIPLES
 A measurement process can be
characterized by five activities:
1. Formulation
2. Collection
3. Analysis
4. Interpretation
5. Feedback
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
7
Formulation 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
8
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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
9
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.
 an 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
10
Analysis Metrics
Function-based metrics: use the function point as
a normalizing factor or as a measure of the “size” of
the specification
Bang metric: used to develop an indication of
software “size” by measuring characteristics of the
data, functional and behavioral models
Specification metrics: used as an indication of
quality by measuring number of requirements by type
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
11
Bang Metrics
To compute the metric, the software engineer
must evaluate a set of primitives:
 Functional Primitives (FuP)
 Data Elements (DE)
 Objects (OB)
 Relationship (RE)
 States (ST)
 Transitions (TR)
Two domains: function strong & data strong
 Based on RE/FuP
 < 0.7  function strong
 Between 0.8 & 1.4  hybrid
 > 1.5  data strong
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
12
Metrics for Specification Quality
 List of characteristics:
 Specificity (lack of ambiguity)
 Completeness
 Correctness
 Understandability
 Verifiability
 Internal & external consistency
 Achievability
 Concision
 Trace-ability
 Modifiability
 Precision
 Reusability
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
13
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)
HK metric: architectural complexity as a
function of fan-in and fan-out
 HKM = length * (fan-in + fan-out)2 for a module
 Note: HK = Henry & Kafura
Morphology metrics: a function of the number
of modules and the number of interfaces
between modules
 Size = node + arcs
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
14
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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
15
Interface Design Metrics
Layout appropriateness: a function of layout
entities, the geographic position and the
“cost” of making transitions among entities
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
16
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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
17
Testing Metrics
 Focus on the process of testing, not the technical
characteristics of the tests
 Testers must rely on analysis, design, & code metrics
to guide them in the design and execution of test cases
 Function-based metrics can be used as a predictor for overall
testing effort
 Bang Metrics can provide an indication of the number of test
cases by examining the primitives
 Architectural design metrics provide information on the ease or
difficulty associated with integration test
 Three different measures provide an indication of
testing completeness:
 Breadth of testing provides indication of completeness of test
plan
 Depth of testing indicates the percentage of independent basis
paths covered vs the total number of the basis paths
 Fault profiles used to rank and categorize errors
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
18
MAINTENANCE METRICS
Software Maturity Index (SMI)
SMI = (MT – (Fa + Fc + Fd))/MT
Where
 MT = the number of modules in the current release
 Fc = the number of modules in the current release that have
been changed
 Fa = the number of modules in the current release that have
been added
 Fd = the number of modules in the preceding release that
were deleted in the current release
As SME approaches 1.0, the product begins
to stabilize
++
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
19