Chapter Outline
— Software Metrics: What and Why ?
— 1. How to measure the size of a software?
— 2. How much will it cost to develop a software?
— 3. How many bugs can we expect?
— 4. When can we stop testing?
— 5. When can we release the software?
— 6. What is the complexity of a module?
— 7. What is the module strength and coupling?
1 2
Technical Metrics
D Are NOT absolute (hence they are open to debate)
D Provide us with a systematic way to assess quality
D Provide insight into product quality on-the-spot rather
than after-the-fact
3 4
Chapter Outline
— 8. What is the reliability at the time of release?
— 9. Which test technique is more effective?
— 10. Are we testing hard or are we testing smart?
— 11. Do we have a strong program or a week test suite?
Definitions
— Pressman explained as “A measure provides a quantitative
— indication of the extent, amount, dimension, capacity, or size of
some attribute of the product or process”.
— Measurement is the act of determine a measure The metric is a
quantitative measure of the degree to which a system, component,
or process possesses a given attribute.
— Fenton defined measurement as “ it is the process by which
numbers or symbols are assigned to attributes of entities in the
real world in such a way as to describe them according to clearly
defined rules”.
 Categories of Metrics Project metrics
— Product metrics: describe the characteristics of the — describe the project characteristics and execution.
product such as size, complexity, design features, performance, Examples are :
efficiency, reliability, portability, etc. — number of software developers
— Process metrics: describe the effectiveness and quality of — staffing pattern over the life cycle of the software
the processes that produce the software product. Examples are: — cost and schedule
— effort required in the process
— productivity
— time to produce the product
— effectiveness of defect removal during development
— number of defects found during testing

5 6

Software Quality McCall’s Software Quality Factors

D Software requirements are the foundation from which
quality is measured.
Maintainability Portability
D Specified standards define a set of development criteria Flexibility Reusability
that guide the manner in which software is engineered. Testability Interoperability
D There is a set of implicit requirements that often goes
unmentioned. Product Revision Product Transition
D Software quality is a complex mix of factors that will
vary across different applications and the customers who
request them. Product Operation
Correctness Reliability Usability Integrity Efficiency

Fq = å c i ´ mi

7 8
 McCall’s Quality Parameters
— Correctness.The extent to which a program satisfies its specification
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. It should be
noted that other, more complete definitions of reliability
have been proposed

9 10

HP’s FURPS Transition to a Quantitative View

D Previous slides described qualitative factors for the
DFunctionality - evaluate the feature set and capabilities of the measurement of software quality
program D Everyday quality measurements
DUsability - aesthetics, consistency, documentation D gymnastics, wine tasting, talent contests
D side by side comparisons
DReliability - frequency and severity of failures D quality judged by an expert in the field
DPerformance - processing speed, response time, resource D Quantitative metrics don’t explicitly measure quality, but
consumption, throughput, efficiency some manifestation of quality
DSupportability - maintainability testability, compatibility,
ease of installation

11 12
 The Challenge of Technical Metrics
D Each quality measurement takes a different view of what
quality is and what attributes in a system lead to
complexity.
D The goal is to develop measures of different program
attributes to use as indicators of quality.
D Unfortunately, a scientific methodology of realizing this
goal has not been achieved.
Measurement Principles
D Formulation - derivation of software metrics appropriate for
the software being considered
D Collection - accumulating data required to derive the
formulated metrics
D Analysis - computation of metrics and application of
mathematical tools
D Interpretation - evaluation of metrics in an effort to gain
insight into the quality of the system
D Feedback - recommendations derived from the interpretation
of metrics

13 14

Attributes of Effective Software Metrics Function Based Metrics

D Simple and computable D The Function Point (FP) metric can be used as a means for
predicting the size of a system (derived from the analysis
D Empirically and intuitively persuasive
model).
D Consistent and objective D number of user inputs
D Consistent in units and dimensions D number of user outputs
D number of user inquiries
D Programming language independent
D number of files
D Effective mechanism for quality feedback D number of external interfaces

15 16
 Function Point Metric The Bang Metric
D Used to predict the application size based on the analysis
model.
Weighting Factor
MEASUREMENT PARAMETER count simple average complex total D The software engineer first evaluates a set of primitives
number of user inputs 3 x 3 4 6 =9
number of user outputs 2 x 4 5 7 =8 unsubdividable at the analysis level.
number of user inquiries 2 x 3 4 6 =6 D With the evaluation of these primitives, software can be
number of files 1 x 7 10 15 =7
number of external interfaces 4 x 5 7 10 = 20 defined as either function-strong or data-strong.
count - total 50 D Once the Bang metric is computed, past history must be
used to predict software size and effort.
Overall implemented size can be estimated from the projected FP value
FP = count-total ´ (0.65 + 0.01 ´ S Fi)

17 18

Different Primitives in Bang Metric Additional primitives

— Modified manual function primitives (FuPM). Functions
— Functional primitives (FuP). The number of
that lie outside the system boundary but must be modified to
transformations (bubbles) that appear at the lowest level of a
data flow diagram accommodate the new system.
— Data elements (DE). The number of attributes of a data — Input data elements (DEI).
object, data elements are not composite data and appear within — Output data elements. (DEO).
the data dictionary. — Retained data elements. (DER).
— Objects (OB). The number of data objects
— Data tokens (TCi).
— Relationships (RE). The number of connections between
data objects — Relationship connections (REi). The relationships that
connect the ith object in the data model to other objects
— States (ST). The number of user observable states in the
state transition diagram
— Transitions (TR). The number of state transitions in the
state transition diagram

19 20
 Algorithm
set initial value of bang = 0;
do while functional primitives remain to be evaluated
Compute token-count around the boundary of primitive i
Compute corrected FuP increment (CFuPI)
Allocate primitive to class
Assess class and note assessed weight
Multiply CFuPI by the assessed weight
bang = bang + weighted CFuPI
enddo
Metrics for Requirements Quality
D Requirements quality metrics - completeness, correctness,
understandability, verifiability, consistency, achievability,
traceability, modifiability, precision, and reusability - design metric
for each.
D E.g., let nr = nf + nnf , where
D nr = number of requirements
D nf = number of functional requirements
D nnf = number of nonfunctional requirements

21 22

Metrics for Requirements Quality High-Level Design Metrics

D Specificity (lack of ambiguity)
D Structural Complexity
D Q = nui/nr 2
D S(i) = f out(i)
D nui - number of requirements for which all reviewers had
D fout(i) = fan-out of module i
identical interpretations
D For completeness, D Data Complexity
D Q = nu/(ni´ ns) D D(i) = v(i)/[fout(i) +1]
D nu = number of unique function requirements D v(i) = # of input and output variables to and from module i
D ni = number of inputs specified D System Complexity
D ns = number of states specified
D C(i) = S(i) + D(i)

23 24
 High-Level Design Metrics (Cont.) Morphology Metrics

D Morphology Metrics a
D size = n + a
D n = number of modules b c d e
D a = number of arcs (lines of control)
f g i j k l
D arc-to-node ratio, r = a/n
D depth = longest path from the root to a leaf
h m n p q r
D width = maximum number of nodes at any level

size depth width arc-to node ratio

25 26

AF Design Structure Quality Index
— S1 = total number of modules
— S2 = # modules dependent upon correct data source or
produces data used, excl. control
— S3 = # modules dependent upon prior processing
— S4 = total number of database items
— S5 = # unique database items
— S6 = # of database segments
— S7 = # modules with single entry & exit
Air Force Design Structure Quality Index
— D1 = 1 if arch design method used, else 0
— D2 = 1 - (S2/S1) -- module independence
— D3 = 1 - (S3/S1) -- independence of prior processing
— D4 = 1 - (S5/S4) -- database size
— D5 = 1 - (S6/S4) -- DB compartmentalization
— D6 = 1 - (S7/S1) -- Module entrance/exit

27 28
 AF Design Structure Quality Index Component-Level Design Metrics
D Cohesion Metrics
— DSQI = åwiDi, where the wi are weights totaling 1 which D Coupling Metrics
give the relative importance D data and control flow coupling
— The closer this is to one, the higher the quality. D global coupling
— This is best used on a comparison basis, i.e., with previous D environmental coupling
successful projects. D Complexity Metrics
— If the value is too low, more design work should be done. D Cyclomatic complexity
D Experience shows that if this > 10, it is very difficult to test

29 30

Cohesion Metrics Coupling Metrics

— Data slice - data values within the module that affect the module
location at which a backward trace began.
— Data tokens - Variables defined for a module
— Glue Tokens - The set of tokens lying on multiple data slices
— Superglue tokens - The set of tokens on all slices
— Stickiness - of a glue token is proportional to number of data
slices that it binds
— Strong Functional Cohesion
SFC(i) = SG(i)/tokens(i)
D Data and control flow coupling
D di = number of input data parameters
D ci = number of input control parameters
D d0 = number of output data parameters
D c0 = number of output control parameters
D Global coupling
D gd = number of global variables used as data
D gc = number of global variables used as control
D Environmental coupling
D w = number of modules called (fan-out)
D r = number of modules calling the module under consideration (fan-in)
D Module Coupling: mc = 1/ (di + 2*ci + d0 + 2*c0 + gd + 2*gc + w + r)
D mc = 1/(1 + 0 + 1 + 0 + 0 + 0 + 1 + 0) = .33 (Low Coupling)
D mc = 1/(5 + 2*5 + 5 + 2*5 + 10 + 0 + 3 + 4) = .02 (High Coupling)

31 32
 Interface Design Metrics Metrics for Source Code
D Software Science Primitives
D Layout Entities - graphic icons, text, menus, windows, . D n1 = the number of distinct operators
D Layout Appropriateness D n2 = the number of distinct operands
D absolute and relative position of each layout entity
D frequency used
D N1 = the total number of operator occurrences
D cost of transition from one entity to another D N2 = the total number of operand occurrences
D LA = 100 x [(cost of LA-optimal layout) /
(cost of proposed layout)]
D Final GUI design should be based on user feedback on GUI
prototypes Length: N = n1log2n1 + n2log2n2
Volume: V = Nlog2(n1 + n2)
33 34

Metrics for Source Code (Cont.) Metrics for Testing

SUBROUTINE SORT (X,N)
1
OPERATOR
END OF STATEMENT
COUNT
7
D Analysis, design, and code metrics guide the design and
DIMENSION X(N)
IF (N.LT.2) RETURN
2
3 =
ARRAY SUBSCRIPT 6
5
execution of test cases.
DO 20 I=2,N
DO 10 J=1,I
4
5
IF( )
DO
2
2
D Metrics for Testing Completeness
IF (X(I).GE.X(J) GO TO 10
6 , 2
SAVE = X(I)
X(I) = X(J) 7 END OF PROGRAM 1 D Breadth of Testing - total number of requirements that have been
X(J) = SAVE 8
9
.LT.
.GE.
1
1
tested
10 CONTINUE
20 CONTINUE 10 GO TO 10 1
D Depth of Testing - percentage of independent basis paths covered
RETURN n1 = 10 N1 = 28
END n2 = 7 N2 = 22 by testing versus total number of basis paths in the program.
D Fault profiles used to prioritize and categorize errors uncovered.

35 36
 Metrics for Maintenance
D Software Maturity Index (SMI)
D MT = number of modules in the current release
D Fc = number of modules in the current release that have
been changed
D Fa = number of modules in the current release that have
been added
D Fd = number of modules from the preceding release that
were deleted in the current release
Summary
D Software metrics provide a quantitative way to asses the
quality of product attributes.
D A software metric needs to be simple, computable,
persuasive, consistent, and objective.
D The function point and bang metrics provide quantitative
means for evaluating the analysis model.
D Metrics for design consider high-level, component level,
and interface design issues.

SMI = [MT - (Fc + Fa + Fd)] / MT

37 38

Summary
D Interface design metrics provide an indication of layout
appropriateness for a GUI.
D Using the number of operators and operands present in
the code provides a variety of metrics to assess program
quality.
D Using the metrics as a comparison with known successful
or unsuccessful projects is better than treating them as
absolute quantities.

39