Cost Estimation: Overview by HC120911034713


									                Cost Estimation
• What is estimated?
   – resources (humans, components, tools)
   – cost (person-months)
   – schedule (months)
• Why?
   –   Personnel allocation
   –   Contract bids
   –   Go/No-Go decisions
   –   Make vs Buy decisions
• “Men do not equal months” (Brooks)
• Consider
  – calendar time vs number of people
  – total effort vs number of people
  – total effort vs calendar time allowed?
• “Adding people to a late project usually
  makes it later” (Brooks)
• Note: people requirements usually uneven
      Software pricing factors
Factor                     Des cripti on
Market opportunity         A development organisat ion may quot e a low price
                           because it wishes t o move int o a new segment of t he
                           soft ware market. Accept ing a low profit on             one
                           project may give the opportunityof more profit lat er.
                           The experience gained may allow new products t o be
Cost est imate uncertainty If an organisat ion is unsure of it s cost est imate, it
                           may increase it s price by some cont ingency over and
                           above it s normal profit .
Contractual terms          A cust omer may be willing t o allow the developer t o
                           ret ain ownership of t he source code and reuse it        in
                           ot her projects. The price charged may t hen be less
                           t han if t he soft ware source code is handed over t o the
                           cust omer.
Requirements volat ility   If the requirement s are likely to change, an
                           organisation may lower its price to win a cont ract .
                           After t he cont ract is awarded, high prices may be
                           charged for changes t o the requirement s.
Financial health           Developers in financial difficulty may lower t heir
                           price t o gain a cont ract . It is bett er t o make a small
                           profit or break even t han t o go out of business.
• Difficulties
   –   “outside” pressure
   –   lack of historical info
   –   poor specifications
   –   moving target
   –   unstable environment
• “a software cost estimation approach is doing well
  if it can estimate costs within 20%, 70% of the
  time, on its own turf” - Boehm 1981
• Cost of under estimation
  – lose $$
  – pressure/stress/hangovers/domino
• Cost of over estimation
  – tie up resources
  – miss out on other projects
• Cost of no estimation
  – no historical data or experience is gained
• Determine Scope
  - function       - performance
  - constraints    - interfaces
  - reliability
• Determine (estimate) resources
  - people         - software       - environment
• Reliable historical information
• Reality?
  – Parkinson’s Law
  – Pricing to win
• Expert judgment by analogy
  – Decomposition
  – Delphi
• Algorithmic Models …
             Algorithmic Models
• Simple formulas
  – usually a function of size estimate
• Allows calibration
• Outputs vary, even within a model
  - effort    - time   - stages
• COCOMO in 1981 was the classic model
Constructive Cost Model, B. Boehm, 1981
•   Basic Model
    1. Estimate KDSI
    2. Select product's Development Mode (straightforward,
       embedded, etc.)
    3. Calculate Person-Months as F(KDSI, DM)
    4. Calculate Dev. Time as F(PM, DM)
•   Intermediate
    – Rank project and process on 15 categories (reliability,
      programmer's capabilities) to obtain ‘effort multipliers’
    – Can analyze tradeoffs
•   Advanced - Involves subsystems and subtasks.
              COCOMO 81 Basic
   Project             Formula                     Description
Simple        PM = 2.4 (KDSI )1.05  M   Well-understood applications
                                         developed by small teams.
Moderate      PM = 3.0 (KDSI )1.12  M   More complex projects where
                                         team members may have limited
                                         experience of related systems.
Embedded      PM = 3.6 (KDSI )1.20  M   Complex projects where the
                                         software is part of a strongly
                                         coupled complex of hardware,
                                         software, regulations and
                                         operational procedures.
        COCOMO 81 Intermediate
 Take the nominal effort and multiply by 15 effort multipliers:

Cost Drivers              VLow   Low      Nomnl High       VHigh EHigh
Required reliability      0.75   0.88     1.00    1.15     1.40

Database size                    0.94     1.00    1.08     1.16

Product complexity        0.70   0.85     1.00    1.15     1.30   1.65

Execution time                            1.00    1.11     1.30   1.66
Analyst capabilities      1.46   1.19     1.00    0.86     0.71

Applications experience   1.29   1.13     1.00    0.91     0.82

Language experience       1.14   1.07     1.00    0.95

Tool use                  1.24   1.10     1.00    0.91     0.83
                  Lines of code
•   What's a line of code?
    – The measure was first proposed when programs were
       typed on cards with one line per card.
    – How does this correspond to statements as in Java
       which can span several lines or where there can be
       several statements on one line?
    – Do you include comments, data declarations, library
    – Is this really what you want to base “productivity”
                Function points
•   Includes external inputs/outputs, user interactions,
    external interfaces, files used by the system
•   Function point count modified by complexity of the
•   FPs can be used to estimate LOC depending on the
    average number of LOC per FP for a given language
     – LOC = AVC * number of function points
     – AVC is a language-dependent factor varying from
         200-300 for assemble language to 2-40 for a 4GL
•   FPs are very subjective. They depend on the estimator.
     – Automatic function-point counting is impossible
                   Object points
•   Object points are an alternative function-related measure
    to function points when 4Gls or similar languages are
    used for development
•   Object points are NOT the same as object classes
•    The number of object points in a program is a weighted
    estimate of
     – The number of separate screens that are displayed
     – The number of reports that are produced by the
     – The number of 3GL modules that must be developed
         to supplement the 4GL code
       Object point estimation
• Object points are easier to estimate from a
  specification than function points as they
  are simply concerned with screens, reports
  and 3GL modules
• They can therefore be estimated at an early
  point in the development process. At this
  stage, it is very difficult to estimate the
  number of lines of code in a system
         COCOMO II (1996)
• Hierarchy
  – analysis stage model
  – design stage model
  – post architecture model
• Sizing options
  – LOC
  – function points
  – object points (don’t worry about this)
               COCOMO 2 levels
•   COCOMO 2 is a 3 level model that allows increasingly
    detailed estimates to be prepared as development progresses
•   Early prototyping level
     – Estimates based on object points and a simple formula is
         used for effort estimation
•   Early design level
     – Estimates based on function points that are then translated
         to LOC
•   Post-architecture level
     – Estimates based on lines of source code
            Estimate uncertainty


  x                                         Code
        Feasibility Requirements   Design          Delivery



To top