Software Process and

Project Metrics
Project Planning Objectives

The objective of Software Project Planning is to

provide a framework that enables the manager to
make reasonable estimates of resources, cost
and schedule.

The estimates are made within a little time frame at

the beginning and should be updated regularly as the
project progresses
Measurement & Metrics
... collecting metrics is too hard ...
it's too time-consuming ... it's too
political ... it won't prove anything ...

Anything that you need to

quantify can be measured in
some way that is superior to
not measuring it at all ..
Tom Gilb
Why Measurement ?
Measurements provide us a mechanism for:
Objective evaluation
Gaining an insight into the efficacy of the software process
and projects
Assisting in estimation, quality control, productivity
assessment, and project control
Improving software process on a continuous basis
Pinpointing the problem areas so that remedies can be
taken
Why do we measure ?
There are four reasons for measuring software processes,
products, and resources

 To characterize
To evaluate
 To evaluate
To predict
To improve
 To predict
 To improve

Software Engineering: A Practitioner’s Approach,

3
Role
Analysis and Assessment
By Software Managers

Collection of measures
By Software Engineers
Definitions

Measure: Provides a quantitative representation of

some attribute of a product or process.
Measurement: It is the act of determining a measure.
Metric: It relates the software measure in some way
Indicator: It is a metric or combination of metrics that
provide insight into the software process, product or
project
Indicators
Process Indicators
Provide insight into the efficacy of an existing software process
Lead to long-term s/w process improvement

Project Indicators
Assess quality of an ongoing project
Track potential risks
Uncover problem areas
Adjust tasks
Evaluate teams ability
Metric Guidelines
Use common sense and organizational sensitivity when interpreting
metric data
Provide regular feedback to the individuals and teams who collect
measures and metrics
Don’t use metric to appraise others
Work with practitioners and teams to set clear cut goals and metrics that
will be used to achieve them
Never use metrics to threaten individuals or teams
Metrics that indicate a problem area should not be considered “negative”
Don’t obsess on a single metric to the exclusion of other important
metrics
Software Measurements
Measurements can be categorized in two ways

Direct Measures – Cost and Effort Applied

e.g: LOC, execution speed, memory size etc
Indirect Measures – Abilities
e.g: functionality, quality, complexity, efficiency etc

Indirect Measures are more difficult to collect

Normalization for Metrics
Normalized data are used to evaluate the process
and the product (but never individual people)

size-oriented normalization —the line of code approach

function-oriented normalization —the function point approach

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are

8
Decomposition Techniques

“Divide and Conquer” approach

Decompose a problem and recharacterize it as a set of
smaller and more manageable problems

Software Sizing Problem:

 It is the project planner’s first major challenge

Direct measure LOC

Indirect measure FP
 If Average Productivity = 620 LOC/pm
And , Labor rate = $ 8000 per month
Then,
Cost / LOC = labor rate / prod.
= 8000/620
= $ 13

Total Project Cost = LOC est. * (cost / LOC)

= 33,200 * 13
= $ 431,600

Total Estimated Effort = LOC est. / prod.

= 33,200 / 620
= 54 person-months
Advantages
Easy to count
It is an artifact of all software development projects

Disadvantages
LOC measures are programming language dependent
Its use in estimation requires a level of detail that is
difficult to achieve early in the development process
Function-Oriented Metric
(use functionality as normalized value)

based on application functions

– inputs, outputs, files, inquiries, Interfaces

scaled by simple, average, complex

 Computing Function Points
Analyze information
domain of the Establish count for input domain and
application system interfaces
and develop counts

Weight each count by Assign level of complexity or weight

assessing complexity to each count

Assess influence of Grade significance of external factors, Fi

global factors that affect
the application
such as reuse, concurrency, OS, ...

Compute
function points FP = Count Total * [ 0.65 + 0.01 * (Fi)]
Analyzing the Information Domain
weighting factor
measurement parameter count simple avg. complex
number of user inputs X 3 4 6 =
number of user outputs X 4 5 7 =
number of user inquiries X 3 4 6 =
number of files X 7 10 15 =
number of ext.interfaces X 5 7 10 =
count-total
complexity multiplier
function points
Taking Complexity into Account

Factors are rated on a scale of 0 (not important)

to 5 (very important):

data communications on-line update

distributed functions
heavily used configuration
transaction rate
on-line data entry
end user efficiency
complex processing
installation ease
operational ease
multiple sites
facilitate change
Function-Oriented Metric
Errors per FP
Defects per FP
$ per FP
Pages of documentation per FP
FP per person-month
FP-based Example
Information Domain Value Count Weight FP Count
number of inputs 24 4 96
number of outputs 16 5 80
number of inquiries 22 4 88
number of files 4 10 40
number of external interfaces 2 7 14
count total 318
Factor Value
Backup & Recovery 4 • FP (estimated) =
Data Communications 2 count-total * [0.65 + 0.01 *
Distributed Processing 0
å Fi ]
Performance critical 4
= 318* [0.65+0.01*52]
Online Data Entry 4
= 372
…… ……
……. ……..

å fi 52
 If Average Productivity = 6.5 FP/pm
And , Labor rate = $ 8000 per month
Then,
Cost / FP = labor rate / prod.
= 8000 / 6.5
= $ 1231

 Total Project Cost = FP est. * (cost / FP)

= 372 * 1231
= $ 457932

Total Estimated Effort = FP est. / prod.

= 372 / 6.5
= 57 person-months
Advantages
they are usable in the earliest requirement phases
they are independent of programming language, product
design, or development style
there exists a large body of historical data
it is a well documented method
Disadvantages
you cannot directly count an existing product’s function
point content
without historical data, it is difficult to improve estimating
skill
function points do not reflect language, design, or style
differences
Measuring Quality
Correctness — the degree to which a program operates
according to specification
Maintainability—the degree to which a program is
amenable to change
Integrity—the degree to which a program is able to
withstand attacks to its security
Usability—the degree to which a program is easy to use