Cost Estimation by niusheng

VIEWS: 260 PAGES: 19

									Cost Estimation
                Problem
•   Our ability to realistically plan and schedule
    projects depends on our ability to estimate
    project costs and development efforts
•   In order to come up with a reliable cost
    estimate, we need to have a firm grasp on the
    requirements, as well as our approach to
    meeting them
•   Typically costs need to be estimated before
    these are fully understood
Estimating uncertainty




                    Boehm
                      1981
        What are project
            costs?
•   For most software projects, costs are:
    •   Hardware Costs
    •   Travel & Training costs
    •   Effort costs
        What are effort costs?
• Effort costs typically largest of the 3 types
  of costs, and the most difficult to estimate.

• Effort costs include:
  – Developer hours
  – Heating, power, space
  – Support staff; accountants, administrators, cleaners,
    management
  – Networking and communication infrastructure
  – Central facilities such as rec room & library
  – Social security and employee benefits
 Effort cost estimation - Overhead
• Everything other than salaries

• OSU example:
  – 45% for benefits
  – 46% for “indirect” costs (space, infrastructure etc)
    calculated on top of everything else


  $1,000 +benefits ($450) + infrastructure ($667)
= $2,117
        Software cost estimation –
             Boehm (1981)
• Algorithmic cost modeling
   – Base estimate on project size (lines of code)
• Expert judgment
   – Ask others
• Estimation by analogy
   – Cost based on experience with similar projects
• Parkinson’s Law
   – Project time will expand to fill time available
• Pricing to win
   – Cost will be whatever customer is willing to pay
• Top-down estimation
   – Estimation based on function/object points
• Bottom-up estimation
   – Estimation based on components
Aggravating & mitigating factors
•   Market opportunity
•   Uncertainty/risks
•   Contractual terms
•   Requirements volatility
•   Financial health
•   Opportunity costs
                 Cost drivers
• Software reliability      • Performance requirements
• Size of application       • Memory constraints
  database                  • Volatility of virtual machine
• Complexity                • Environment
• Analyst capability        • Turnaround time
• Software engineering      • Use of software tools
  capability                • Application of software
• Applications experience     engineering methods
• Virtual machine           • Required development
  experience                  schedule
• Programming language
  expertise
         Productivity metrics
• Lines of code
  – Simple, but not very meaningful metric
  – Easy to pad, affected by prog language
  – How to count revisions/debugging etc?
• Function points
  – Amount of useful code produced
    (goals/requirements met)
  – Less volatile, more meaningful, not perfect
                 Function points
Function points are computed by first calculating an
  unadjusted function point count (UFC). Counts are made
  for the following categories (Fenton, 1997):
   – External inputs – those items provided by the user that describe
     distinct application-oriented data (such as file names and menu
     selections)
   – External outputs – those items provided to the user that
     generate distinct application-oriented data (such as reports and
     messages, rather than the individual components of these)
   – External inquiries – interactive inputs requiring a response
   – External files – machine-readable interfaces to other systems
   – Internal files – logical master files in the system

Each of these is then assessed for complexity and given a
  weighting from 3 (for simple external inputs) to 15 (for
  complex internal files).
 Unadjusted Function Point Count
             (UFC)
                   Weighting Factor
Item               Simple      Average       Complex
External inputs    3           4             6
External outputs   4           5             7
External inquiries 3           4             6
External files     7           10            15
Internal files     5           7             10

Each count is multiplied by its corresponding complexity
weight and the results are summed to provide the UFC
                 Object points
Similar to function points (used to estimate
  projects based heavily on reuse, scripting
  and adaptation of existing tools)

• Number of screens (simple x1, complex x2, difficult
  x3)
• Number of reports (simple x2, complex x5, difficult x8)
• Number of custom modules written in languages like
  Java/C x10
  Function points -> Lines of code
200-300 LOC/Function
  point in assembly


Multiplication factor by
 language


Programmer
  productivity?
            COCOMO II Model
• Supports spiral model of development
• Supports component composition, reuse, customization
• 4 sub-models:
   – Application composition model – assumes system written with
     components, used for prototypes, development using scripts,
     db’s etc (object points)
   – Early design model – After requirements, used during early
     stages of design (function points)
   – Reuse model – Integrating and adapting reusable components
     (LOC)
   – Post architecture model – More accurate method, once
     architecture has been designed (LOC)
 Application composition model
Used primarily to estimate cost of
 prototyping efforts

PM = (Application points x(1-%reuse/100)/ productivity


Productivity estimates from 4-50 object
  points/month, depending on experience
  and the availability/maturity of tools
          Early Design Model
Used once requirements are agreed to get
 going on an architectural design

PM=2.94 x Size^B x M

B=1.05-1.20
M=Proj characteristics
            Reuse model
• PM = (LOC needing to be adjusted X
         % auto-generated)/productivity

Productivity ~ 2,400 LOC/Month
     Post-Architectural
•
          Model
    Organic projects - relatively small, simple projects with
    small teams and good application experience to less than
    rigid requirements. (A=2.4, B=1.05)
•   Semi-detached projects - intermediate (in size and
    complexity) projects with mixed experience teams and a
    mix of requirements. (A=3.0, B=1.12)

•   Embedded projects - software projects that must be
    developed within a set of tight hardware, software, and
    operational constraints. (A=3.6, B=1.20)



                 PM=A x Size^B x M

								
To top