UNIT-V

Process and Project Metrics

- Introduction
- Metrics in the Process Domain
- Metrics in the Project Domain
 What are Metrics?
 Software process and project metrics are quantitative
measures
 They are a management tool
 They offer insight into the effectiveness of the software
process and the projects that are conducted using the
process as a framework
 Basic quality and productivity data are collected
 These data are analyzed, compared against past averages,
and assessed
 The goal is to determine whether quality and
productivity improvements have occurred
 The data can also be used to pinpoint problem areas
 Remedies can then be developed and the software process
can be improved
2
 Uses of Measurement

• Can be applied to the software process with the intent of

improving it on a continuous basis
• Can be used throughout a software project to assist in
estimation, quality control, productivity assessment, and
project control
• Can be used to help assess the quality of software work
products and to assist in tactical decision making as a project
proceeds

3
 Reasons to Measure
• To characterize in order to
– Gain an understanding of processes, products, resources, and
environments
– Establish baselines for comparisons with future assessments
• To evaluate in order to
– Determine status with respect to
• To predict in order to
plans
– Gain understanding of relationships among processes and products
– Build models of these relationships
• To improve in order to
– Identify roadblocks, root causes, inefficiencies, and other opportunities
for improving product quality and process performance

4
 Metrics in the Process Domain
• Process metrics are collected across all projects and over
long periods of time
• They are used for making strategic decisions
• The intent is to provide a set of process indicators that
lead to long- term software process improvement
•
The only way to know how/where to improve any
–
process
– is to
– Measure specific attributes of the process
Develop a set of meaningful metrics based on
these attributes
Use the metrics to provide indicators that will
lead to a strategy for improvement

8
 Metrics in the Process Domain
(continued)
• We measure the effectiveness of a process by deriving a set of metrics
based on outcomes of the process such as
1. Errors uncovered before release of the
software
2. Defects delivered to and reported by the
end users
3. Work products delivered
4. Human effort expended
5. Calendar time expended
Conformance to the
schedule
6. Time and effort to
complete each generic 6
 Metrics in the Project Domain
• Project metrics enable a software project manager to

• Assess the status of an

ongoing project Track
potential risks
• Uncover problem areas before their
status becomes critical Adjust work
flow or tasks
• Evaluate the project team’s ability to control
quality of software work products
7
 Use of Project
Metrics
•
The first application of project metrics occurs during estimation
– Metrics from past projects are used as a basis for
• estimating time and effort
As a project proceeds, the amount of time and effort expended
• are compared to original estimates

As technical work commences, other project metrics become

important
– Production rates are measured (represented in terms of
models created, review hours, function points, and
delivered source lines of code)
– Error uncovered during each generic framework activity
(i.e, communication, planning, modeling, construction,
deployment) are measured 8
 Use of Project
Metrics
(continued)
• Project metrics are used to

– Minimize the development schedule by making

the adjustments necessary to avoid delays and
• mitigate potential problems and risks
– Assess product quality on an ongoing basis and,
when necessary, to modify the technical approach
– to improve quality

9
 Categories of Software Measurement
• Two categories of software measurement
– Direct measures
Software
• process (cost, effort, etc.)
•
Software product (lines of code produced,
– execution speed, defects reported over time, etc.)
Indirect measures of the
• Software product (functionality, quality,
complexity, efficiency, reliability,
maintainability, etc.)
Project metrics can be consolidated to create process
metrics for an organization
10
 Size-oriented Metrics
• Derived by normalizing quality and/or productivity measures by
considering the size of the software produced
• Thousand lines of code (KLOC) are often chosen as the normalization
value
• Metrics include
– Errors per KLOC - Errors per person-month
– Defects per KLOC - KLOC per person-month
– Dollars per - Dollars per page of documentation
– KLOCof documentation per KLOC
Pages

(More on next slide)

11
 Size-oriented Metrics
(continued)

• Size-oriented metrics are not universally accepted as the best way to

measure the software process
• Opponents argue that KLOC measurements
– Are dependent on the programming language
– Penalize well-designed but short programs
– Cannot easily accommodate nonprocedural languages
– Require a level of detail that may be difficult to achieve

12
 Function-oriented
Metrics
•Function-oriented metrics use a measure of the functionality
delivered by the application as a normalization value
•Most widely used metric of this type is the function point:

FP = count total * [0.65 + 0.01 * sum (value adj.

factors)]

13
 LOC Per Function Point
Language Average Median Low High
Ada 154 -- 104 205
Assembler 337 315 91 694
C 162 109 33 704
C++ 66 53 29 178
COBOL 77 77 14 400
Java 55 53 9 214
PL/1 78 67 22 263
Visual Basic 47 42 16 158

www.qsm.com/?q=resources/function-point-languages-table/index.html

14
 Metrics for Software Quality
• Correctness

– This is the number of defects per KLOC, where a defect is a

verified lack of conformance to requirements
– Defects are those problems reported by a program user after
the program is released for general use
•
Maintainability
– This describes the ease with which a program can be corrected if an error is
–
found, adapted if the environment changes, or enhanced if the customer has
changed requirements
Mean time to change (MTTC) : the time to analyze, design, implement, test, and
distribute a change to all users

• Maintainable programs on average have a lower MTTC

15
 Defect Removal Efficiency
• It is a measure of the filtering ability of QA activities as
they are applied throughout all process framework
activities
– It indicates the percentage of software errors found
before software release
It is defined as DRE = E / (E + D)
– E is the number of errors found before delivery of the
software to the end user
– D is the number of defects found after delivery
• As D increases, DRE decreases (i.e., becomes a smaller and
smaller fraction)
• The ideal value of DRE is 1, which means no defects are
found after delivery
• DRE encourages a software team to institute techniques for
finding as many errors as possible before delivery
16
 Arguments for Software
Metrics
• Most software developers do not measure, and most have little desire
to begin
• Establishing a successful company-wide software metrics program can
be a multi-year effort
• But if we do not measure, there is no real way of determining whether
we are improving
• Measurement is used to establish a process baseline from which
improvements can be assessed
• Software metrics help people to develop better project estimates,
produce higher-quality systems, and get products out the door on time

17
 Establishing a Metrics Baseline
• By establishing a metrics baseline, benefits can be obtained at the
software process, product, and project levels
• The same metrics can serve many masters
• The baseline consists of data collected from past projects
• Baseline data must have the following attributes
– Data must be reasonably accurate (guesses should be avoided)
– Data should be collected for as many projects as possible
– Measures must be consistent (e.g., a line of code must be interpreted
consistently across all projects)
– Past applications should be similar to the work that is to be
• After data is collected and metrics are computed, the metrics should be
estimated
evaluated and applied during estimation, technical work, project
control, and process improvement

18
Software Metrics Baseline Process
Software
Engineering
Process

Measures
Software Data
Project Collection

Metrics
Metrics
Computation
Software
Product
Indicators
Metrics
Evaluation

19