Process, Product and Project Metrics Product Metrics For Software Estimation For Software Projects

San Diego International Airport – Access Control System:
System transactions—over 250000 per. day.

Average processing time—less than 15. seconds.
Reliability—99.99%.
System capability—upgradeable and. expandable ...
[www.biometric.org]
Process, Product and Project Metrics

Product Metrics for Software
Estimation for Software Projects
based on
Chapter 15
Chapter 22
Chapter 23
Software Engineering: A Practitioner’s Approach, 6/e
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
McCall’s Triangle of Quality proposed in the early 1970s.
M a in ta in a b ility P o rta b ility

F le xib ility R e u sa bility
T e sta bility In te ro p e ra b ility
P R O D U C T R E V IS IO N P R O D U C T T R A N S IT IO N
P R O D U C T O P E R A T IO N
C o rre ctn e ss U sa b ility E fficie n cy
R e lia b ility In te g rity
A Good Manager Measures
process
process metrics
project metrics
measurement
product metrics
product
What do we
use as a
basis?
What’s the diff. between • size?
Process and Product metrics?
• function?
Measures, Metrics
 A measure provides a quantitative indication of the extent, amount,
dimension, capacity, or size of some attribute of a product or process
 The IEEE glossary defines a metric as “a quantitative measure of the

degree to which a system, component, or process possesses a given
attribute.”
Can you quantify user-friendliness, security, evolvability, …?
Software measurement
(Sommerville; http://www.utdallas.edu/~chung/SE3354Honors/IEEInaugural.pdf)
• Measurement of products or systems is absolutely fundamental to

the engineering process.
• I am convinced that measurement as practised in other engineering

disciplines is IMPOSSIBLE for software engineering
Not
Theseeverything thatare
courseware materials can
to bebe counted
used counts,
in conjunction and Engineering:
with Software not everything thatApproach,
A Practitioner’s counts 6/ecan beprovided
and are counted.
[Albert Einstein]
Project Estimation
Establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical
project.
So the end result gets done on time, with quality!
 Project scope must be understood (is your ADS to cover HR)?

 Elaboration (decomposition) is necessary
 task breakdown and effort estimates (how many do you have for your ADS?)
 size (e.g., FP) estimates
 Historical metrics are very helpful (if not, the first time will be hard)
 Empirical models (hopefully, statistical)
 Past (similar) project experience
 At least two different techniques should be used (WHY?)
 Uncertainty is inherent in the process (and just about everywhere in real SE
projects)
Conventional Methods:
 compute LOC/FP using estimates of information domain values
use historical data to build estimates for the project
 permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
with 5
Typical Size-Oriented Metrics
 errors per KLOC (thousand lines of code)
 defects per KLOC
 $ per LOC
 pages of documentation per KLOC
 errors per person-month
 Errors per review hour
 LOC per person-month
 $ per page of documentation
Typical Function-Oriented Metrics

 errors per FP (thousand lines of code)
 defects per FP
 $ per FP
 pages of documentation per FP
 FP per person-month
Function-Based Metrics
 The function point metric (FP), first proposed by Albrecht [ALB79], can be used
effectively(?) as a means for measuring the functionality
delivered by a system.
 FPs are derived using an empirical relationship based on

countable (direct) measures of software's information domain
and assessments of software complexity
 Information domain values are defined in the following

manner:
Function-Based Metrics
 Information domain values are defined in the following manner:
 number of external inputs (EIs) {password, panic button, activate/deactivate}
 number of external outputs (EOs) {messages, sensor status}
 number of external inquiries (EQs) {zone inquery, sensor inquery}
 number of internal logical files (ILFs) {system configuration file}
 Number of external interface files (EIFs) {test sensor, zone setting, activate/deactivate, alarm alert}
Sensors
Password Test sensor
Zone inquery Zone setting

User Sensor inquery SafeHome messages
User interaction User
Panic button function Sensor status
Activate/deactivate
Activate/deactivate
Password, Monitoring
Sensors, Alarm alert
& response
… system
System configuration data
What kind of diagram is this?
Computing Function
Points
Information Weighting factor
Domain Value Count simple average complex
External Inputs ( EIs) x3 3 4 6 =

=
External Outputs ( EOs) x3 4 5 7
External Inquiries ( EQs) x3 3 4 6 =
Internal Logical Files ( ILFs) x3 7 10 15 =
x3 5 7 10 =
External Interface Files ( EIFs)
Count total
assume simple
What would be the total function points for the safehome system?
What do we do next with the total function points for the safehome system?
LOC Approach
Function Estimated LOC
2-d geometric analysis 2300
3-d geometric analysis 5300
DBM 3350
Graphics display facilities 4950 A CAD application
Peripheral control function 2100
UI 2300
Design analysis modules 8400
Estimated LOC 33200
Historical data:
(per-month)
• Average productivity for systems of this type = 620 LOC/pm.
• Labor rate = $8000/pm, Cost/LOC =8000/620?
Based on the LOC estimate and the historical productivity data,
• estimated effort = 33200/620=54 person-months.
• total estimated project cost = 33200/620 * 8000 = $431,000
Example: FP Approach
Information Weighting factor
Domain Value Count simple average complex
External Inputs ( EIs) x3 3 4 6 =
External Outputs ( EOs) x3 4 5 7

=
External Inquiries ( EQs) x3 3 4 6 = A CAD application

Internal Logical Files ( ILFs) x3 7 10 15 =
External Interface Files ( EIFs)

x3 5 7 10 =
Count total 320
FPestimated = count-total * [0.65 + 0.01 * Sum (Fi)] --- p442 adjustment factors
= 320 * [0.65 + 0.01 * 52] = 374 (e.g., factor in reliability, performance, reusability, complexity, …)
Historical data:
• organizational average productivity = 6.5 FP/pm.
• labor rate = $8000 pm, cost per FP = ?.
Based on the FP estimate and the historical productivity data,
•These
total estimated
courseware project
materials are to be cost
used in = 374/6.5 * 8000 = $461,000
conjunction with Software Engineering: A Practitioner’sSee safehome
Approach, example
6/e and are provided
11
• estimated effort = 374/6.5 = 58 person-months.
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
Comparing LOC and FP
Programming LOC per Function point
Language avg. 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 63 53 77 -
JavaScript 58 63 42 75
Perl 60 - - -
PL/1 78 67 22 263
Powerbuilder 32 31 11 105
SAS 40 41 33 49
Sma lltalk 26 19 10 55
SQL 40 37 7 110
Visual Basic 47 42 16 158
Representative values developed by QSM
So, which would you prefer – LOC or FP?

Estimation with Use-Cases
use cases scenarios pages Êscenarios pages LOC LOC estimate
e subsystem
User interface subsystem 6 10 6 Ê 12 5 560 3,366
Engineeringsubsystem
subsystemgroup
group 10 20 8 Ê 16 8 3100 31,233
Infrastructure subsystemgroup
e subsystem group 5 6 5 Ê 10 6 1650 7,970
Total LOC estimate Ê Ê Ê Ê
stimate Ê Ê Ê Ê 42,568
Historical data:
• average productivity for systems of this type = 620 LOC/pm
• labor rate = $8000 pm,
=> cost/LOC = ?.
Based on the use-case estimate and the historical productivity data,
- total estimated project cost = = $552,000
42568/620 * 8000
- estimated effort = = 68 pm. 42568/620
The Make-Buy Decision
expected cost build = 0.30 ($380K) + 0.70

($450K)
= $429 K
expected cost reuse = ??? = $382K

expected cost =
expected
These courseware materials are to be used in conjunction with Software Engineering: costApproach,
A Practitioner’s buy 6/e and
= ??? = $267K
are provided
(path probability)
with permission by R.S. Pressman x (estimated path cost)
i & Associates, Inc., copyright © 1996, 2001,
i 2005 14
Class-Oriented Metrics
Proposed by Chidamber and Kemerer:
 methods per class
 depth of the inheritance tree Can you depict these in UML?
 number of children
 coupling between object classes
Proposed by Lorenz and Kidd [LOR94]:

 class size
 number of operations overridden by a subclass
 number of operations added by a subclass
 average number of parameters per operation
Measurement Principles
 The objectives of measurement should be established before data collection begins;
 Each technical metric should be defined in an unambiguous manner;
 Metrics should be derived based on a theory that is valid for the domain of application
 Metrics should be tailored to best accommodate specific products and processes

[BAS84]
How do you define technical metric unambiguously?
The Mythical Man-Month
 What is so mythical?
 Review The Mythical Man-Month
Omitted Slides
Defect Removal Efficiency
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.
What would be the relationship betw. DRE and reliability prediction?
Why Do We Measure?
 assess the status of an ongoing project
 track potential risks
 uncover problem areas before they go “critical,”
 adjust work flow or tasks,
 evaluate the project team’s ability to control quality of
software work products.
Process model
Process improvement
Improvement goals recommendations
Process metrics SPI

Process Measurement
 We measure the efficacy of a software process indirectly.
 That is, we derive a set of metrics based on the outcomes that can be derived
from the process.
 Outcomes include
 measures of errors uncovered before release of the software
 defects delivered to and reported by end-users
 work products delivered (productivity)
 human effort expended
 calendar time expended

 schedule conformance
 other measures.
Project Metrics
 used to minimize the development schedule by making the adjustments necessary
to avoid delays and mitigate potential problems and risks
 used to assess product quality on an ongoing basis and, when necessary, modify
the technical approach to improve quality.
 every project should measure:
 inputs—measures of the resources (e.g., people, tools) required to do the work.
 outputs—measures of the deliverables or work products created during the software
engineering process.
 results—measures that indicate the effectiveness of the deliverables.
Typical Project Metrics

 Effort/time per software engineering task
 Errors uncovered per review hour
 Scheduled vs. actual milestone dates
 Changes (number) and their characteristics
 Distribution of effort on software engineering tasks
Object-Oriented Metrics
 Number of scenario scripts (use-cases)
 Number of support classes (required to implement the system

but are not immediately related to the problem domain)
 Number of subsystems (an aggregation of classes that support

a function that is visible to the end-user of a system)
WebE Project Metrics
 Number of static Web pages (the end-user has no control over the content
displayed on the page)
 Number of dynamic Web pages (end-user actions result in customized
content displayed on the page)
 Number of internal page links (internal page links are pointers that provide a
hyperlink to some other Web page within the WebApp)
 Number of persistent data objects
 Number of external systems interfaced
 Number of static content objects
 Number of dynamic content objects
 Number of executable functions
Goal-Oriented Software Measurement
 The Goal/Question/Metric Paradigm
 (1) establish an explicit measurement goal that is specific to the process
activity or product characteristic that is to be assessed
 (2) define a set of questions that must be answered in order to achieve the
goal, and
 (3) identify well-formulated metrics that help to answer these questions.
 Goal definition template
 Analyze {the name of activity or attribute to be measured}
 for the purpose of {the overall objective of the analysis}
 with respect to {the aspect of the activity or attribute that is considered}
 from the viewpoint of {the people who have an interest in the measurement}
 in the context of {the environment in which the measurement takes place}.
Measurement Process
 Formulation. The derivation of software measures and metrics appropriate for the
representation of the software that is being considered.
 Collection. The mechanism used to accumulate data required to derive the
formulated metrics.
 Analysis. The computation of metrics and the application of mathematical tools.
 Interpretation. The evaluation of metrics results in an effort to gain insight into the
quality of the representation.
 Feedback. Recommendations derived from the interpretation of product metrics
transmitted to the software team.
Establishing a Metrics Program
 Identify your business goals.
 Identify what you want to know or learn.
 Identify your subgoals.
 Identify the entities and attributes related to your subgoals.
 Formalize your measurement goals.
 Identify quantifiable questions and the related indicators that you will use to
help you achieve your measurement goals.
 Identify the data elements that you will collect to construct the indicators that
help answer your questions.
 Define the measures to be used, and make these definitions operational.
 Identify the actions that you will take to implement the measures.
 Prepare a plan for implementing the measures.
Why Opt for FP?
 Programming language independent
 Used readily countable characteristics that are
determined early in the software process
 Does not “penalize” inventive (short) implementations
that use fewer LOC that other more clumsy versions
 Makes it easier to measure the impact of reusable
components
Omitted Slides from
Estimation for Software Projects
Project Planning Task Set
 Establish project scope
 Determine feasibility
 Analyze risks
 Define required resources
 human resources, reusable software resources
 Estimate cost and effort
 Decompose the problem
 Develop two or more estimates using size, FPs, process tasks or use-cases
 Reconcile the estimates
 Develop a project schedule
 Establish a meaningful task set
 Define a task network
 Use scheduling tools to develop a timeline chart
 Define
These courseware schedule
materials are tracking
to be used in conjunction mechanisms
with Software Engineering: A Practitioner’s Approach, 6/e and are provided
Resources
number software
tools
skills hardware
people
environment network
location resources
project
reusable
OTS
software
new
components components
full-experience part.-experience
components components
Write it Down!
Project Scope Software

Estimates Project
Risks Plan
Schedule
Control strategy
Estimation
 Estimation of resources, cost, and schedule for a
software engineering effort requires
 experience
 access to good historical information (metrics
 the courage to commit to quantitative predictions when
qualitative information is all that exists
 Estimation carries inherent risk and this risk leads to
uncertainty
To Understand Scope ...
 Understand the customers needs
 understand the business context
 understand the project boundaries
 understand the customer’s motivation
 understand the likely paths for change
 understand that ...
Even when you understand,

nothing is guaranteed!
What is Scope?
 Software scope describes
 the functions and features that are to be delivered to end-users
 the data that are input and output
 the “content” that is presented to users as a consequence of
using the software
 the performance, constraints, interfaces, and reliability that
bound the system.
 Scope is defined using one of two techniques:
 A narrative description of software scope is developed after
communication with all stakeholders.
 A set of use-cases is developed by end-users.
Process-Based Estimation
Obtained from “process framework”
framework activities
application Effort required to

functions accomplish
each framework
activity for each
application function
Functional Decomposition
Statement functional
of decomposition
Scope Perform a
Grammatical “parse”
Process-Based Estimation Example
Activity Risk Construction
CC Planning Analysis Engineering Release CE Totals
Task analysis design code test
Function
UICF 0.50 2.50 0.40 5.00 n/a 8.40

2DGA 0.75 4.00 0.60 2.00 n/a 7.35
3DGA 0.50 4.00 1.00 3.00 n/a 8.50
CGDF 0.50 3.00 1.00 1.50 n/a 6.00
DSM 0.50 3.00 0.75 1.50 n/a 5.75
PCF 0.25 2.00 0.50 1.50 n/a 4.25
DAM 0.50 2.00 0.50 2.00 n/a 5.00
Totals 0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00
% effort 1% 1% 1% 8% 45% 10% 36%
CC = customer communication CE = customer evaluation
Based on an average burdened labor rate of $8,000 per month, the

total estimated project cost is $368,000 and the estimated effort is 46
person-months.
Tool-Based Estimation
project characteristics
calibration factors
LOC/FP data
COCOMO-II
 COCOMO II is actually a hierarchy of estimation models
that address the following areas:
 Application composition model. Used during the early stages of
software engineering, when prototyping of user interfaces,
consideration of software and system interaction, assessment of
performance, and evaluation of technology maturity are paramount.
 Early design stage model. Used once requirements have been
stabilized and basic software architecture has been established.
 Post-architecture-stage model. Used during the construction of the
software.
Estimation for OO Projects-I
 Develop estimates using effort decomposition, FP analysis, and any other
method that is applicable for conventional applications.
 Using object-oriented analysis modeling (Chapter 8), develop use-cases
and determine a count.
 From the analysis model, determine the number of key classes (called
analysis classes in Chapter 8).
 Categorize the type of interface for the application and develop a multiplier
for support classes:
 Interface type Multiplier
 No GUI 2.0
 Text-based user interface 2.25
 GUI 2.5
 Complex GUI 3.0
Estimation for OO Projects-II
 Multiply the number of key classes (step 3) by the multiplier to obtain
an estimate for the number of support classes.
 Multiply the total number of classes (key + support) by the average
number of work-units per class. Lorenz and Kidd suggest 15 to 20
person-days per class.
 Cross check the class-based estimate by multiplying the average
number of work-units per use-case
Metrics for OO Design
 Whitmire [WHI97] describes nine distinct and measurable characteristics of an OO design:
 Size
 Size is defined in terms of four views: population, volume, length, and functionality
 Complexity
 How classes of an OO design are interrelated to one another
 Coupling
 The physical connections between elements of the OO design
 Sufficiency
 “the degree to which an abstraction possesses the features required of it, or the degree to which a design
component possesses features in its abstraction, from the point of view of the current application.”
 Completeness
 An indirect implication about the degree to which the abstraction or design component can be reused
 Cohesion
 The degree to which all operations working together to achieve a single, well-defined purpose
 Primitiveness
 Applied to both operations and classes, the degree to which an operation is atomic
 Similarity
 The degree to which two or more classes are similar in terms of their structure, function, behavior,
or purpose
 Volatility
 Measures the likelihood that a change will occur
Estimation for Agile Projects
 Each user scenario (a mini-use-case) is considered separately for
estimation purposes.
 The scenario is decomposed into the set of software engineering tasks that
will be required to develop it.
 Each task is estimated separately. Note: estimation can be based on
historical data, an empirical model, or “experience.”
 Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP or some
other volume-oriented measure (e.g., use-case count).
 Estimates for each task are summed to create an estimate for the scenario.
 Alternatively, the volume estimate for the scenario is translated into effort using
historical data.
 The effort estimates for all scenarios that are to be implemented for a given
software increment are summed to develop the effort estimate for the
increment.
Empirical Estimation Models
General form:
exponent
effort = tuning coefficient * size
usually derived
as person-months empirically
of effort required derived
usually LOC but
may also be
either a constant or function point
a number derived based
on complexity of project
The Software Equation
“derived from productivity data collected for over 4000
contemporary software projects”
A dynamic multivariable model
E = [LOC x B0.333/P]3 x (1/t4)

where
E = effort in person-months or person-years
t = project duration in months or years
B = “special skills factor”
P = “productivity parameter” (typical value for developing real-time embedded sw = 2000;
telecom = 10000; business application = 28000)

Process, Product and Project Metrics Product Metrics For Software Estimation For Software Projects

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Process, Product and Project Metrics Product Metrics For Software Estimation For Software Projects

Uploaded by

Copyright:

Available Formats

San Diego International Airport – Access Control System:

System transactions—over 250000 per. day.

Process, Product and Project Metrics

M a in ta in a b ility P o rta b ility

 The IEEE glossary defines a metric as “a quantitative measure of the

• Measurement of products or systems is absolutely fundamental to

• I am convinced that measurement as practised in other engineering

 Project scope must be understood (is your ADS to cover HR)?

Typical Function-Oriented Metrics

 pages of documentation per FP

 FPs are derived using an empirical relationship based on

 Information domain values are defined in the following

Zone inquery Zone setting

External Inputs ( EIs) x3 3 4 6 =

External Inquiries ( EQs) x3 3 4 6 =

Internal Logical Files ( ILFs) x3 7 10 15 =

External Inputs ( EIs) x3 3 4 6 =

External Outputs ( EOs) x3 4 5 7

External Inquiries ( EQs) x3 3 4 6 = A CAD application

External Interface Files ( EIFs)

Count total 320

Representative values developed by QSM

So, which would you prefer – LOC or FP?

expected cost build = 0.30 ($380K) + 0.70

expected cost reuse = ??? = $382K

Proposed by Lorenz and Kidd [LOR94]:

 average number of parameters per operation

 Each technical metric should be defined in an unambiguous manner;

 Metrics should be tailored to best accommodate specific products and processes

 Review The Mythical Man-Month

E is the number of errors found before delivery of

What would be the relationship betw. DRE and reliability prediction?

Process metrics SPI

 defects delivered to and reported by end-users

 work products delivered (productivity)

 human effort expended

 calendar time expended

Typical Project Metrics

 Number of support classes (required to implement the system

 Number of subsystems (an aggregation of classes that support

Project Scope Software

Even when you understand,

application Effort required to

UICF 0.50 2.50 0.40 5.00 n/a 8.40

Totals 0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00

% effort 1% 1% 1% 8% 45% 10% 36%

CC = customer communication CE = customer evaluation

Based on an average burdened labor rate of $8,000 per month, the

A dynamic multivariable model

E = [LOC x B0.333/P]3 x (1/t4)

You might also like