Project Management
Metrics
Introduction
• Pressman identifies the key elements of
software project management as:
–
–
–
–
–
–
beginning a software project
measures and metrics
estimation
risk analysis
scheduling
tracking and control
Beginning a Software Project
– Before a project can be planned, objectives and
scope should be established, alternative
solutions should be considered, and technical
and management constraints should be
identified.
– Without this information, it is impossible to
define reasonable (and accurate) estimates of
the cost, a realistic breakdown of project tasks,
or a manageable project schedule that provides
meaningful indication of progress.
Project Objectives and Scope
• The software developer and customer must
meet to define project objectives and scope.
– Objectives identify the overall goals of the
project without considering how these goals
will be achieved.
– Scope identifies the primary functions that
software is to accomplish, and more
importantly, attempts to bound these functions
in a quantitative manner.
Statement of Requirements
– Ince, Sharp and Woodman (Introduction to
Software Project Management and Quality
Assurance) identify the starting point of any
project as a document which is prepared by the
customer for a system, known as the statement
of requirements.
– This is in natural language, can be a few pages
in length or a number of volumes, and is
probably couched in terms of the customer's
business.
Requirements Analysis
– Given the statement of requirements the
developer has to carry out the processes of
requirements analysis: analyse the statement
of requirements and extract and clarify the
functions and constraints.
– This involves interaction with the customer and
could be the most difficult part of the software
project.
• Requirements analysis is difficult for two
main reasons:
– "culture gap" between customer and developer
– statement of requirements may exhibit
properties which make requirements analysis
difficult; examples are:-
– functional and non-functional requirements
(constraints) are intermingled
– statement of requirements contains ambiguities
– statement of requirements contains platitudes
– statement of requirements contains design and
implementation directives
– statement of requirements is often incomplete
– functions are described at different levels of
detail
System Specification
– The aim of requirements analysis is to write
down, in an unambiguous way, what a proposed
system should do (its functions), and what the
constraints are on the developer.
– The document produced is often called the
system specification. It is the key document on
which all subsequent activities in the software
project depend.
Functional Specification
– The functional specification should be
 unambiguous
 free of design and implementation directives
 in a form which enables the developer to reason
about the properties of the system it describes
 partitioned
 free of any extraneous detail
 understandable by the customer
– A system design document also has these
properties (with the exception of the last one.)
Measures and Metrics
– In most technical endeavours, measurement and
metrics help us to understand the technical
process that is used to develop a product and
the product itself.
– The process is measured in an effort to improve
it.
– The product is measured in an effort to increase
its quality.
What to measure?
– At first, it would seem that measurement is selfevident. After all, measurement enables us to
quantify and therefore manage more effectively.
But reality can be somewhat different.
Measurement often leads to controversy and
argument.
 What are appropriate metrics for the process and the
product?
 How should the data that are collected be used?
 Is it fair to use measurements to compare people,
processes, or products?
Why measure software?
– to indicate the quality of the product
 to access the productivity of the people who
produce the product
 to assess the benefits derived from new
software engineering methods and tools
 to form a baseline for estimation
 to help justify requests for new tools or
additional training
Software Metrics
– A software metric is a numerical measure of a
product or process that is part of a software
project.
– Software metrics are useful to the project
manager because they provide clear and precise
information about the progress of a project, and
so are useful for monitoring project progress.
• "Once something can be measured, you move away
from the world of opinion towards the world of
fact."
Useful software metrics
– A truly useful software metric must be: measurable; based on facts not opinions
 independent; project team members should not be
able to alter its value without affecting the quality of
the software
 accountable; details about how and when the metric
was measured should be documented
• precise; the level of tolerance allowed when
measuring it should be known
Types of metric
• result
• predictor
– direct
– indirect
• productivity
• technical
• quality
Alternative categorisation
 size-oriented metrics, used to collect direct
measures of software engineering output and
quality
 function-oriented metrics,used to collect indirect
measures of software engineering output and
quality
 human-oriented metrics, collect information
about the manner in which people develop
software and human perceptions about
effectiveness of tools and methods.
Size-oriented Metrics
– Size-oriented software metrics are direct
measures of software and the process by which
it is developed.
– If a software organisation maintains simple
records, a table of size-oriented data can be
created.
– From the data contained in the table, a set of
simple size-oriented productivity and quality
metrics can be developed for each project.
project effort cost KLOC pgs.doc. errors people
aaa-01
24
168 12.1
365
29
3
ccc-04
62
440 27.2
1,224
86
5
fff-03
43
314 20.2
1,050
64
6
...
...
...
...
...
...
...
– Productivity
= KLOC/person-month
– Quality
= defects/KLOC
– In addition, other interesting metrics may be
computed:
– Cost
= $/LOC
– Documentation = pages of
documentation/KLO
– Averages can be computed for all projects.
LOC
– Size-oriented metrics are controversial and are not
universally accepted as the best way to measure the
process of software development. Most of the
controversy swirls around the use of lines of code as a
key measure.
– Proponents of the LOC measure claim that LOC is an
"artifact" of all software development projects that can
be easily counted, that many existing software
estimation models use LOC or KLOC as a key input,
and that a large body of literature and data predicated
on LOC already exists.
LOC
• On the other hand, opponents claim that:
– LOC measures are programming-language dependent,
– they penalise well-designed but shorter programs,
– they cannot easily accommodate nonprocedural
languages,
– their use in estimation requires a level of detail that may
be difficult to achieve (i.e., the planner must estimate
the LOC to be produced long before analysis and
design have been completed)
Function-oriented Metrics
– Function-oriented software metrics are indirect
measures of software and the process by which
it is developed. Rather than counting LOC,
function-oriented metrics focus on program
"functionality" or "utility."
– Function-oriented metrics were first proposed
by Albrecht in 1979, who suggested a
productivity measurement approach called the
function point method.
Function Points
– Function points (FPs) are derived using an
empirical relationship based on countable
measures of software's information domain and
assessments of software complexity.
– Five information domain characteristics are
determined and counts are provided in the
appropriate table location.
Domain Characteristics
•
•
•
•
•
Number of user inputs.
Number of user outputs.
Number of user inquiries.
Number of files.
Number of external interfaces.
Number of user inputs
 Each user input that provides distinct
application-oriented data to the software is
counted.
 Inputs should be distinguished from inquiries
which are counted separately.
Number of user outputs
 Each user output that provides applicationoriented information to the user is counted.
 In this context "output" refers to reports,
screens, error messages, etc.
 Individual data items within a report are not
counted separately.
Number of user inquiries
 An inquiry is defined as an online input that
results in the generation of some immediate
software response in the form of an online
output.
 Each distinct inquiry is counted.
Number of files
 Each logical master file, i.e., a logical grouping
of data that may be one part of a large database
or a separate file, is counted.
Number of external interfaces
 All machine-readable interfaces (e.g. data files
on tape or disk) that are used to transmit
information to another system are counted.
measurement
parameter
(number of ..)
user inputs
user outputs
user inquiries
files
external interfaces
count
weighting factor
simple, average,
complex
x 3, 4, 6
x 4, 5, 7
x 3, 4, 6
x 7, 10, 15
x 5, 7, 10
result
count-total
Once the above data have been collected, a complexity value
is associated with each count.
Organizations that use function point methods develop criteria for
determining whether a particular entry is simple, average, or complex.
Nonetheless, the determination of complexity is somewhat subjective.
Computing FPs
FP = count-total x [0.65 + 0.01 x SUM(Fi)]
where
 count-total is the sum of all FP entries obtained from
the table,
 Fi (i = 1 to 14) are "complexity adjustment values"
based on responses to questions noted in the following
table.
 The constant values in the above equation and the
weighting factors that are applied to information
domain counts are determined empirically.
Uses of FPs
– Once function points have been calculated, they
are used in a manner analogous to LOC as a
measure of software productivity, quality, and
other attributes:
– Productivity
= FP/personmonth
– Quality
= defects/FP
– Cost
= $/FP
– Documentation = pages of
documentation/FP
Adjustment factors
 Does the system require reliable backup and
recovery?
 Are data communications required?
 Are there distributed processing functions?.
 Is performance critical?
 Will the system run in an existing, heavily utilized
operational environment?
 Does the system require online data entry?
 Does the online data entry require the input
transaction to be built over multiple screens or
operations?
Adjustment factors
 Are the master files updated online?
 Are the inputs, outputs, files, or inquiries complex?
 Is the internal processing complex?
 Is the code designed to be reusable?
 Are conversion and installation included in the
design?
 Is the system designed for multiple installations in
different organisations?
 Is the application designed to facilitate change and
ease of use by the user?
Computing Function Points
Rate each factor on a scale of 0 to 5
•
•
•
•
•
•
0= no influence
1= incidental
2= moderate
3= average
4= significant
5= essential
Proponents claim ...
– The function point (or feature point) metric,
like LOC, is controversial.
– Proponents claim that FP is programminglanguage independent, making it ideal for
applications using conventional and
nonprocedural languages;
– they also claim that it is based on data that are
more likely to be known early in the evolution
of a project, making FP more attractive as an
estimation approach.
Opponents claim ...
– Opponents claim that the method requires some
"sleight of hand" in that computation is based in
part on subjective, rather than objective, data;
– that information domain information can be
difficult to collect after-the-fact; and
– that FP has no direct physical meaning - it's just
a number.