Chair of Software Engineering

Software Engineering
Prof. Dr. Bertrand Meyer
March 2007 – June 2007

Lecturer: Hermann Lehner (http://sct.inf.ethz.ch/h)

Slides: Based on KSE06 – With kind permission of Peter Müller

Lecture 6: Estimation Techniques

Why estimations?

Project Price Change

selection (bids) requests

Costs

Based on estimations
Duration
Schedule Resources Hiring
Milestones

Resource
allocation
Estimations in software projects

ƒ Mostly
personnel cost
Costs (effort)
ƒ Travel, training
ƒ Hardware,
software
Duration is Effort
essentially effort /
resources

Schedule Resources
Overview

Estimation Techniques
Empirical Estimations
Algorithmical Estimations
Estimation Process
Estimation Exercise

ƒ How many passenger planes does Lufthansa have?

¾ Not counting regional subsidiaries

ƒ How can we approach this problem systematically?

Overview

Estimation Techniques
Empirical Estimations
Algorithmical Estimations
Estimation Process
Empirical estimation: Expert judgment

ƒ Estimate is based on experience and historical data

ƒ Involve experts in
¾ Development techniques
¾ Application domain

ƒ Most common technique in practice

Top-down estimation

ƒ Estimation by analogy
¾ Comparison with similar projects
¾ Analysis of differences
¾ Typical example: SAP introduction

Pros Cons
ƒ Quicker and less ƒ Underestimation of
expensive than other difficult technical
methods problems likely
ƒ Can be done early in the ƒ No detailed justification
project of estimate
ƒ Be aware of scalability
problems!
Top-down estimation: Delphi method

Step 1: Each expert submits

ƒ Estimate
ƒ Justification

Step 3: Each expert

submits
ƒ New estimate
ƒ Justification of
deviation from average
of previous estimates

ƒ More accurate than ordinary expert judgment

¾ Eliminates outliers
ƒ More expensive to produce
Top-down estimation: Typical figures

ƒ Typical figures for software development

¾ Analysis 20%
Analysis
¾ Design 40% Test
¾ Implementation 15%
¾ Test 25% Design
Implementation

ƒ Very helpful to validate estimations

Bottom-up estimation

ƒ Estimation by decomposition
¾ Estimating the effort for individual work packages
¾ Cost and accuracy depend on size of the work
packages
Pros Cons
ƒ See “cons” of top-down ƒ Underestimation because
estimation effort does not grow
linearly (due to
complexity, etc.)
ƒ Underestimation of
integration effort
ƒ Requires initial system
design
Program evaluation and review technique

ƒ Goal: Manage probabilities with simple statistics

ƒ Approach: Ask several experts for three estimates
¾ Optimistic, Likely (mode), and Pessimistic
ƒ Important formulas
¾ Mean M=(O+4×L+P)/6
¾ Deviation V = ( P – O ) / 6
ƒ Assumptions
¾ Project effort is normally distributed
(more than 20 work packages)
¾ Work package efforts are statistically independent
(ignores single underlying cause of delay)
Overview

Estimation Techniques
Empirical Estimations
Algorithmical Estimations
Estimation Process
Algorithmic estimation of software

ƒ Basic cost model

Effort = A × SizeB × m(X)

Size: Some measurement of the software size

A: Constant factor that depends on
Organizational practices
Type of software
B: Usually lies between 1 and 1.5
X: Vector of cost factors
m: Adjustment multiplier
Cost models

Effort = A × SizeB × m(X)

ƒ Cost models
¾ Define a way to determine the size
¾ Define cost factors X
¾ Provide defaults for parameters A, B, m
(based on hundreds of projects)

ƒ Important examples
¾ Function point analysis
¾ Constructive cost model (COCOMO)
Measuring size: Lines of code

ƒ Software size can be measured in lines of source code

¾ Most commonly used metric

ƒ Difficult in early phases of the project (before design

is known)
¾ Reuse, make-or-buy decisions

ƒ Influenced heavily by choice of programming language

ƒ Should only be used indirectly
Function point analysis

ƒ Size is estimated based on requirements

Inputs
Internal files
Inquiries
Function
External files
Outputs
Functions

ƒ Inputs
¾ Forms, dialogs, messages, XML documents
ƒ Outputs
¾ Web pages, reports, graphs, messages, XML
documents
ƒ Inquiries (input/output combinations)
¾ Simple web inputs, generally producing a single output
ƒ Logical internal files (controlled by the program)
¾ Tables, views or files in database
ƒ External files (controlled by other programs)
¾ Tables or files used from other systems or databases
Complexity of functions
Factor Simple Average Complex
Inputs 3 4 6
Outputs 4 5 7
Inquiries 3 4 6
Ext. files 7 10 15
Int. files 5 7 10

ƒ Determine
complexity of Input Simple Average Complex
each function Data 1-5 6-10 >10
ƒ Weight each elements
function Checking Formal Formal, Formal, logical,
according to logical requires DB access
complexity
Cost factors

Data communications Rate each element from 0 – 5

Distributed processing ¾ 0: no influence
Performance
Heavy use ¾ 1: insignificant influence
Transaction rate ¾ 2: moderate influence
Online data entry ¾ 3: average influence
Complex interface
¾ 4: significant influence
Online data update
Complex processing ¾ 5: strong influence
Reusability Technical complexity factor
Installation ease
¾ TCF = 0.65 + 0.01 × sum
Operational ease
Multiple sites ¾ Varies between 0.65 and 1.35
Facilitate change
Function point computation

Adjusted function points: FP = UFP × TCF

Determining effort and size

ƒ Empirical value for effort

Effort = FP 1.4 / 150
¾ Or use a table
ƒ Empirical value for size
ƒ Huge differences in productivity
¾ Factor 10-20 between individual programmers
¾ Factor 4 between companies
Observation about software size

ƒ Consider a project that requires 10 Web pages,

15 reports, and 20 database tables
¾ 315 function points, if each item is medium complexity
ƒ How many lines of C code would it have?
¾ About 32,000 lines
ƒ What if you used Excel?
¾ About 2,000 lines

ƒ Why do you think there are so many spreadsheets out

there?
Function point analysis: Discussion

Pros Cons
ƒ Based on requirements ƒ Estimation of overall
(instead of code size) effort (not per phase)
ƒ Can be applied in early ƒ Tailored towards
project phases functional decomposition
ƒ Can be calibrated (for (rather than OO)
company, project type) ƒ Tailored towards
ƒ Counting standards by information systems
“International Function ƒ Needs calibration to
Points User Group” produce reliable results
ƒ Technology-independent
Estimation techniques: Discussion

Empirical studies
Empirical Estimation Algorithmic Estimation
ƒ Accurate if experts
¾ Do not show are ƒ Very
that uncalibrated accurateestimation
algorithmic if model is
experienced
is, in general, more accurate calibrated
ƒ Experts can be strongly ƒ Calibration is very
¾ Show that algorithmic estimation is more accurate
biased (over-optimism) difficult and expensive
than experts who do not have important domain
knowledge ƒ Estimation is expensive
Other estimation strategies

Parkinson’s Law Pricing to win

ƒ Work expands to fill the ƒ Cost is estimated to
time available whatever the customer is
- Gold plating willing to spend
ƒ Effort is determined by ƒ Common strategy to win
available resources projects
ƒ Important for team ƒ Features are negotiated
management later, constrained by
agreed costs
ƒ Costs are fixed, not
requirements
Overview

Estimation Techniques
Empirical Estimations
Algorithmical Estimations
Estimation Process
Estimate types

Rough order of Budgetary Definitive

magnitude

-25 / +75% -10 / +25% -5 / +10%

Initial estimates Decision making, Project plan,

response to proposals
proposals

ƒ Refine your estimates at each project stage

¾ Requirements document, system design, detailed
design, working code
Estimating process

Determine Select Estimators,

Establish
project strategy and type of validation,
objectives
details plan historic data

Why? Accuracy?
Audience? Generate
effort
estimate
Duration = √Effort
Duration = 3.0 × Effort1/3
Determine
(Effort in person months, Document
team size and
Duration in months) assumptions
duration
Effort = Duration × Team Size

Validate and
Document
Different method, review finalize
Estimation tips
• Avoid off-the-cuff
estimates
• Allow time for the
estimate, and plan it
• Use historic data
• Use developer-based
estimates
• Estimate by walkthrough
• Estimate by categories
¾ e.g. easy, medium, hard
• Estimate at a low level
of detail
• Don’t omit common tasks
(management; use
checklists)
• Use different
techniques and compare
the results
• Change estimation
practices as the project
progresses
From effort to costs

ƒ Direct costs: Costs incurred for the benefit

of a specific project
¾ Salaries of project staff
¾ Equipment bought specifically for the project
¾ Travel expenses
ƒ Indirect costs: Costs incurred for the joint benefit over
multiple projects (“overhead”)
¾ Accounting, quality assurance department
¾ Line management
¾ Rooms, electricity, heating
Unit costs

ƒ Projects have to budget for

¾ Direct costs
¾ A certain share of indirect costs
ƒ Budgets are usually determined by using unit costs
¾ Unit cost: Price per unit of a resource
¾ Loaded rate: Including indirect costs
¾ Unloaded rate: Without indirect costs
ƒ Examples
¾ Loaded day rate for senior IT consultant: CHF 3.500
¾ Loaded day rate for internal developer: CHF 1.200
From costs to prices

ƒ The price is often based on the costs

and a margin
ƒ Price = Costs / ( 1 - Margin )
ƒ Example
¾ Costs = CHF 1.000.000
¾ Margin = 5%
¾ Price = CHF 1.052.632
ƒ Price is influenced by
¾ Market situation
¾ Business strategy
BACKUP