Why estimate? - PowerPoint PPT Presentation

1 / 22
About This Presentation
Title:

Why estimate?

Description:

Estimation Why estimate? What to estimate? When to estimate? How not to estimate? How to estimate? – PowerPoint PPT presentation

Number of Views:56
Avg rating:3.0/5.0
Slides: 23
Provided by: sce2UmkcE
Category:

less

Transcript and Presenter's Notes

Title: 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.
Write a Comment
User Comments (0)
About PowerShow.com