Why estimate?

1
Estimation

• Why estimate?
• What to estimate?
• When to estimate?
• How not to estimate?
• How to estimate?

2
Why Estimate?

• At the beginning of a project customers usually
  want to know
• How much?
• How long?
• Programmers dont like death march projects.
• Good estimates lead to realistic project plans.

3
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?
4
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.

5
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).

6
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
7
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

8
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

9
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

10
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

11
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.

12
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.

13
Cone of uncertainty
14
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 cant
  sell that to my boss. We know 10 months is
  acceptable so we will settle for 10 months.

15
How to Estimate?

• Techniques for estimating size, effort and
  duration
• Analogy
• Expert judgement
• Parametric (algorithmic) models

16
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.

17
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.

18
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

19
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.

20
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.

21
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.

22
Estimation Guidelines

• Dont 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.