Transcript Project Management - School of Computing and Engineering

Estimation
• Why estimate?
• What to estimate?
• When to estimate?
• How not to estimate?
• How to estimate?
(DRAFT)
SWENET
1
Why Estimate?
• At the beginning of a project customers usually want
to know:
– How much?
– How long?
• Programmers don’t like “death march” projects.
• Good estimates lead to realistic project plans.
(DRAFT)
SWENET
2
What to Estimate?
• Estimates are usually made in the following order:
– System Size (LOC or Function points)
– Effort
– Duration
– Cost
How Long?
Size
Effort
Duration
Primary Driver
Cost
(Other)
How Much?
(DRAFT)
SWENET
3
Effort
• Effort is the amount of labor required to complete a
task.
• Effort is typically measured in terms of person months
or person hours.
• Effort is a function of developer productivity.
• Productivity = LOC or function points per month or
hour.
(DRAFT)
SWENET
4
Duration
• Duration is the amount of calendar time or clock time
to complete a project or task.
• As an analogy, you can rent a car by the mile (effort)
or period of time (duration).
(DRAFT)
SWENET
5
Effort vs. Duration
Ironing a shirt
Effort = 10 minutes
Duration = 10 minutes
Cooking a turkey
Effort = 1 hour
Duration = 3 hours
Cutting a tree with a two-person saw
Effort = 30 minutes
Duration = 15 minutes
(DRAFT)
SWENET
6
Size Estimate: Lines of Code
• Widely used, even though there are obvious
limitations:
– need a counting standard
– language dependent
– hard to visualize early in a project
– hard to understand by clients
– does not account for complexity or environmental
factors
(DRAFT)
SWENET
7
Size Estimate: Function Points -1
• Developed by Albrecht (1979) at IBM in the data
processing domain and subsequently refined and
standardised.
• Based on a user view of a system:
– external inputs - e.g. input screen
– external outputs - e.g. output screen
– external enquiries - e.g. prompt for input
– internal logical files - e.g. database
– internal interface files - e.g. shared math routines
(DRAFT)
SWENET
8
Size Estimate: Function Points -2
• Basic Function Points =
4 * EI + 5 * EO + 4 * EQ + 10 * ILF + 7 * EIF
• Each elementary function type has its own relative
weighting for complexity:
– low -25%, average, high +50%
(DRAFT)
SWENET
9
Size Estimate: Function Points -3
• There is also a Value Adjustment Factor (VAF) which
is determined by 14 general system characteristics
covering factors such as operational ease,
transaction volume, distributed data processing.
• The VAF ranges from 0.65 to 1.35
(DRAFT)
SWENET
10
Difficulties with Function Points
• Counting function points is subjective, even with
standards in place.
• Counting can not be automated (even for finished
systems, c.f. LOC).
• The factors are dated and do not account for newer
types of software systems, e.g. real-time, GUI-based.
• There are many extensions to the original function
points that attempt to address new types of system.
(DRAFT)
SWENET
11
When to Estimate?
• Estimates are made at the beginning of a project and
updated at regular intervals as new information is
gained and uncertainty reduced.
(DRAFT)
SWENET
12
Cone of uncertainty
Cost Estimation over time
10
Range of cost
4
2
1.5
1.2
0.8
1
0.67
0.5
1
0.25
SWENET
ep
ta
nc
e
Ac
c
Im
pl
em
Project Phases
(DRAFT)
en
ta
tio
n
gn
De
si
.
Re
q.
Sp
ec
Co
nc
ep
ts
0.1
13
How not to Estimate (van Vliet)
• We were given 12 months to do the job, so it will take
12 months. (Parkinson)
• We know our competitor put in a bid of $1M so we
need to schedule a bid of $0.9M. (Priced to win)
• We want our product at the trade show next year so
the software must be written and tested in the next
nine months.
• Actually the project needs one year but I can’t sell
that to my boss. We know 10 months is acceptable
so we will settle for 10 months.
(DRAFT)
SWENET
14
How to Estimate?
• Techniques for estimating size, effort and duration:
– Analogy
– Expert judgement
– Parametric (algorithmic) models
(DRAFT)
SWENET
15
Estimating by Analogy
• Identify one or more similar projects and use this project (or
parts of it) to produce an estimate for the new project.
• Estimating accuracy is often improved by partitioning a project in
parts and making estimates of each part (errors cancel out so
long as estimating is unbiased).
• Can use a database of projects from your own organisation or
from multiple organisations.
• Because effort doesn't scale linearly with size and complexity,
extrapolating from past experience works best when the old and
new systems are based on the same technology and are of
similar size and complexity.
(DRAFT)
SWENET
16
Estimating by Expert Judgment
• Have experts estimate project costs possibly with the
use of consensus techniques such as Delphi.
• Bottom-up composition approach: Costs are
estimated for work products at the lowest-levels of
the work breakdown structure and then aggregated
into estimates for the overall project.
• Top-Down decomposition approach: Costs are
estimated for the project as a whole and then divided
among the phases and components of the project.
(DRAFT)
SWENET
17
Wide-band Delphi
• Get multiple experts/stakeholders
• Share project information
• Each participant provides an estimate independently
and anonymously
• All estimates are shared and discussed
• Each participant estimates again
• Continue until or consensus, or exclude extremes
and calculate average
(DRAFT)
SWENET
18
Parametric (Algorithmic) Models
• Formulas that compute effort and duration based on
system size and other cost drivers such as capability
of developers, effectiveness of development process,
schedule constraints, etc.
• Most models are derived using regression analysis
techniques from large databases of completed
projects.
• In general the accuracy of their predictions depends
on the similarity between the projects in the database
and the project to which they are applied.
(DRAFT)
SWENET
19
COCOMO II
• COCOMO = Constructive Cost Model
• Basic formula:
Effortperson months = 2.94 * (Cost Drivers) * (KLOC)**E
• KLOC = Size estimate
• Cost Drivers = project attributes that have a linear effect
on effort. Examples: analyst capability, reliability
requirements, etc.
• E = an exponent based on non-linear project effects such
as process maturity, team cohesion, etc.
(DRAFT)
SWENET
20
COCOMO II
• Schedule estimate is a function of person
months:
DurationMonths = 3.67 * (Effortperson months)**F
• F = an exponent based on the same non-linear project
effects considered in the equation for person months.
(DRAFT)
SWENET
21
Estimation Guidelines
• Don’t confuse estimates with targets
• Apply more than one technique and compare the results
• Collect and use historical data
• Use a structured and defined process. Consistency will facilitate
the use of historical data.
• Update estimates as new information becomes available
• Let the individuals doing the work participate in the development
of the estimates. This will garner commitment.
• Be aware that programmers tend to be optimistic when
estimating.
(DRAFT)
SWENET
22