Product Metrics

Software
Engineering
Lecture # 05
Economics
SE(481)

Department of Computing
Hamdard Institute of Engineering & Technology
Hamdard University
Product Metrics

Chapter # 23

Software Engineering
A Practitioner’s Approach
7th Edition
Roger S. Pressman

Software Engineering Economic Hamdard University

 Metrics from Everyday Life

 Working and living

 Cost of utilities for the month
 Cost of groceries for the month
 Amount of monthly rent per month
 Time spent at work each Saturday for the past month
 College experience
 Grades received in class last semester
 Number of classes taken each semester
 Amount of time spent on studying and homework this week
 Number of hours of sleep last night
 Travel
 Time to drive from home to the airport
 Amount of miles traveled today
 Cost of meals and lodging for yesterday
Software Engineering Economic Hamdard University
 Why have SW Product Metrics?

 Help software engineers to better understand the attributes

of models and assess the quality of the software
 Help software engineers to gain insight into the design and
construction of the software
 Focus on specific attributes of software engineering work
products resulting from analysis, design, coding, and testing
 Provide a systematic way to assess quality based on a set of
clearly defined rules
 Provide an “on-the-spot” rather than “after-the-fact”
insight into the software development
Software Engineering Economic Hamdard University
 Metrics for
Requirement Model

Hamdard University
 Product Metrics
Metrics for Requirement Model

 Technical work in software engineering begins

with the creation of the requirements model.

 It is at this stage that requirements are derived

and a foundation for design is established.

 Therefore, product metrics that provide insight

into the quality of the analysis model are
desirable.
Software Engineering Economic Hamdard University
 Product Metrics
Metrics for Requirement Model

 Few analysis and specification metrics have appeared in

the literature, it is possible to adapt metrics that are often
used for project estimation and apply them in this
context.

 These metrics examine the requirements model with the

intent of predicting the “size” of the resultant system.

 Size is sometimes (but not always) an indicator of design

complexity and is almost always an indicator of increased
coding, integration, and testing effort.
Software Engineering Economic Hamdard University
 Metrics for Requirement Model
Introduction of Function-Based

 Function point (FP) metric can be used effectively as a

means for measuring the functionality delivered by a
system.

 Using historical data, the FP metric can then be used to

1) Estimate the cost or effort required to design, code, and
test the software
2) Predict the number of errors that will be encountered
during testing
3) Forecast the number of components and/or the number of
projected source lines in the implemented system.
Software Engineering Economic Hamdard University
 Metrics for Requirement Model
Function-Based Metrics

 Number of external inputs (EIs). Each external input originates

from a user or is transmitted from another application and
provides distinct application-oriented data or control information.
 Inputs are often used to update internal logical files (ILFs).
 Inputs should be distinguished from inquiries, which are counted
separately.

 Number of external outputs (EOs). Each external output is

derived data within the application that provides information to
the user.
 External output refers to reports, screens, error messages, etc.
 Individual data items within a report are not counted separately.

Software Engineering Economic Hamdard University

 Metrics for Requirement Model
Function-Based Metrics

 Number of external inquiries (EQs). An external inquiry is defined as

an online input that results in the generation of some immediate
software response in the form of an online output (often retrieved
from an ILF).

 Number of internal logical files (ILFs). Each internal logical file is a

logical grouping of data that resides within the application’s
boundary and is maintained via external inputs.
 Example: Tables in a relational database.

 Number of external interface files (EIFs). Each external interface file

is a logical grouping of data that resides external to the application
but provides information that may be of use to the application.
 Example: search for particular data.
Software Engineering Economic Hamdard University
Software Engineering Economic Hamdard University
 Metrics for Requirement Model
Function-Point Example
 Complete the table shown below to get the count total
 Associate a weighting factor (i.e., complexity value) with each count based on criteria
established by the software development organization

Information Weighting Factor

Domain Value Count Simple Average Complex
External Inputs _____ x 3 4 6 = _____
External Outputs _____ x 4 5 7 = _____
External Inquiries _____ x 3 4 6 = _____
Internal Logical Files _____ x 7 10 15 = _____
External Interface Files _____ x 5 7 10 = _____
Count total ________

 Evaluate and sum up the adjustment factors

(see the next 2 slides)
Software Engineering Economic Hamdard University
 Compute the number of function points (FP)
FP = UFP* [0.65 + 0.01 * sumofGSCs]

“GSCc” refers to 14 value adjustment

factors, with each ranging in value from 0
(not important) to 5 (absolutely essential)

Software Engineering Economic Hamdard University

Software Engineering Economic Hamdard University
 Suppose we have a software system with the
following components:
 External Inputs (EI): 10 inputs
 External Outputs (EO): 6 outputs
 External Inquiries (EQ): 5 inquiries
 Internal Logical Files (ILF): 4 logical files
 External Interface Files (EIF): 3 interface files

Software Engineering Economic Hamdard University

Next, we assign complexity weights based on standard values
(for simplicity, we use "Average" complexity):
•EI (Average Complexity Weight) = 4 points
•EO (Average Complexity Weight) = 5 points
•EQ (Average Complexity Weight) = 4 points
•ILF (Average Complexity Weight) = 7 points
•EIF (Average Complexity Weight) = 5 points

Software Engineering Economic Hamdard University

 Step-by-Step Calculation:
 Unadjusted Function Points (UFP):
 UFP = (EI × EI weight) + (EO × EO weight) + (EQ × EQ weight) + (ILF × ILF
weight) + (EIF × EIF weight)
 Plugging in the numbers:
 UFP=(10×4)+(6×5)+(5×4)+(4×7)+(3×5)UFP = (10 × 4) + (6 × 5) + (5 ×
4) + (4 × 7) + (3 × 5)UFP=(10×4)+(6×5)+(5×4)+(4×7)+(3×5)
UFP=40+30+20+28+15=133UFP = 40 + 30 + 20 + 28 + 15 =
133UFP=40+30+20+28+15=133
 Value Adjustment Factor (VAF): VAF is determined based on 14
general system characteristics, each rated on a scale from 0 (no
influence) to 5 (strong influence). For this example, let's assume a
VAF of 1.1 (average value).
Software Engineering Economic Hamdard University
 Metrics for
Specification Quality

Hamdard University
 Metrics for Requirement Model
Metrics for Specification Quality

 Davis and his colleagues propose a list of characteristics that can be used
to assess the quality of the requirements model and the corresponding
requirements specification:
 Specificity (lack of ambiguity),
 Completeness, correctness
 Internal & external consistency
 Understandability, verifiability
 Achievability, concision, traceability
 Modifiability, precision, reusability

 In addition, the authors note that high-quality specifications are

 Electronically stored; executable
 at least interpretable; annotated by relative importance;
 stable, versioned, organized,
 cross-referenced, specified at the right level of detail.
Software Engineering Economic Hamdard University
Metrics for Requirement Model
Metrics for Specification Quality

Suppose are nr requirements in a specification, such that

nr = nf + nnf

where
nf is the number of functional requirements
nnf is the number of non-functional requirements

Software Engineering Economic Hamdard University

Metrics for Requirement Model
Metrics for Specification Quality
To determine the specificity requirements (lack of ambiguity)
of, Davis et al. suggest a metric that is based on the consistency
of the reviewers’ interpretation of each requirement:

Q1 = nui / nr

where nui is the number of requirements for which all

reviewers had identical interpretations.

Closer the value of Q to 1, the lower is the ambiguity of the

specification.

Software Engineering Economic Hamdard University

 Metrics for Requirement Model
Metrics for Specification Quality

Completeness of functional requirements can be determined by computing the

ratio

Q2 = nu / ni x ns

where nu is the number of unique functional requirements,

ni is the number of inputs (stimuli) defined or implied by the specification, ns is
the number of states specified.

Q2 ratio measures the percentage of necessary functions that have been

specified for a system. However, it does not address nonfunctional
requirements.

Software Engineering Economic Hamdard University

Metrics for software
design

Hamdard University
 Metrics for Software Design

 Architectural design metrics focus on characteristics of the

program architecture with an emphasis on the architectural
structure and the effectiveness of modules

 These metrics are “black box” in the sense that they do not require
any knowledge of the inner workings of a particular software
component.

 Card and Glass define three software design complexity measures:

 Structural complexity
 Data complexity
 System complexity

Software Engineering Economic Hamdard University

 Metrics for Software Design
Architectural Design Metrics

 Structural complexity
 S(i) = f2out(i)
 where f2out(i) is the “fan out” of module i

 Fan-out is defined as the number of modules

immediately subordinate to module i;
 that is, the number of modules that are directly
invoked by module i.

Software Engineering Economic Hamdard University

Metrics for Software Design
Architectural Design Metrics

Data complexity provides an indication of the complexity in the internal interface for
a module i and is defined as

D(i) = V(i) / [ fout (i) +1]

where V(i) is the number of input and output variables that are passed to and from
module i.

System complexity is defined as the sum of structural and data complexity, specified

C(i) = S(i) + D(i)

As each of these complexity values increases, the overall architectural complexity of
the system also increases.

Software Engineering Economic Hamdard University

 Metrics for Software Design
Architectural Design Metrics

 Shape complexity
size = n + a
where n is the number of nodes and
a is the number of arcs
Allows different program software architectures to be
compared in a straightforward manner

 Connectivity density (i.e., the arc-to-node ratio)

r = a/n
May provide a simple indication of the coupling in the software
architecture
Software Engineering Economic Hamdard University
Metrics for Software Design
Architectural Design Metrics

Software Engineering Economic Hamdard University