Estimation for Software Projects

• project planning involves estimating how much time, effort, money, and resources will be required
  • project scope is determined
  • the problem is decomposed into smaller problems
  • software managers use historical project data, personal experience, and intuition, to determine estimates for each
  • final estimates are typically adjusted by taking project complexity and risk into account.
  • resulting work product is called a project management plan
    
    
• project planning objectives
  • a framework that enables a software manager to estimate resources, cost, and schedule
  • 'best case' and 'worst case' scenarios should be used to bound project outcomes
    
  • estimates should be updated as the project progresses
    
    
    
    
• estimation reliability factors depend on
  • project complexity
    
  • project size
    
  • degree of structural uncertainty
    • degree to which requirements have solidified
    • the ease with which functions can be compartmentalized
    • the hierarchical nature of the information processed
      
  • availability of historical information (metrics from previous projects!)
    
    
    
    
• project planning process
  
  
  
• software scope
  
  
  
  
  • customer communication and scope
    • determine the customer's overall goals for the proposed system and any expected benefits
    • determine the customer's perceptions concerning the nature if a good solution to the problem
    • evaluate the effectiveness of the customer meeting
      
      
  • examine feasibility
    • technical feasibility is not a good enough reason to build a product
    • business feasibility is just as important
    • the product must meet the customer's needs and not be available as an off-the-shelf purchase
      
      
• estimation of resources
  
  
  
  
  • human resources
    • number of people required, and
    • skills needed to complete the development project
      
      
  • reusable software resources
    • off-the-shelf components
    • full-experience components
    • partial-experience components
    • new components
      
      
  • environment resources
    • hardware and software required to be accessible by software team during the development process
      
      
• project estimation
  
  
  
  
• we start with the scope and utilize decomposition techniques
  
  
  
  
  • functions are refined to allow for better estimates of cost and schedule
    
    
  • problem-based estimation
    
    • using LOC decomposition focuses on software functions
    • using FP decomposition focuses on information domain characteristics
    • decomposition is essential!
    • the average productivity and labor rates come from historical metrics - they will vary by organization (and domain)
    • example for a CAD project
      
      
      
  • process-based estimation
    • this approach is frequently used
    • decomposition based on tasks required to complete the software process framework
    • again, decomposition is essential, and is done to a fairly detailed level
      
      
      
      
  • use-case estimation
    • promising, but controversial due to lack of standardization of use-cases
    • estimate LOC from use-case "size"
      
      
      
      
      
      
  • empirical estimation models
    
    
    
    
    • derived from analysis of historical software project data
      • with estimated person-months as the dependent variable
      • KLOC, FP, or object points as independent variables
    • must be calibrated locally!
      
      
    • COCOMO II is a hierarchy of estimation models that take the process phase into account
      • based on its popular predecessor: Constructive Cost Model (COCOMO) is a static estimation model
        
        
        
        
    • The Software Equation is another dynamic estimation model
      
      
      
      
      • model derived from analysis of over 4000 software projects
      • the productivity parameter reflects process maturity, level of support, skills and experience, problem complexity
      • application to the CAD project
        
        
        
        
  • estimation for object-oriented projects
    
    
    
  • estimation for agile development
    • abbreviated form of estimation useful for small fast projects and incremental development
      1. each user scenario is considered separately
      2. the scenario is decomposed into a set of engineering tasks
      3. each task is estimated separately
         1. may use historical data, empirical model, or experience
         2. scenario volume can be estimated (LOC, FP, use-case count, etc.)
      4. total scenario estimate computed
         1. sum estimates for each task
         2. translate volume estimate to effort using historical data
      5. the effort estimates for all scenarios in the increment are summed to get an increment estimate
         
         
• reconciliation
  • use more than one of these methods and compare the resulting estimates
  • causes of estimation reconciliation problems
    • project scope is not adequately understood or is misinterpreted by planner
    • productivity data used for problem-based estimation techniques is inappropriate or obsolete
  • investigate large discrepancies
  • use common sense!
    
    
• make-buy decision
  • it may be more cost effective to acquire a piece of software rather than develop it
  • as a rule outsourcing software development requires more skillful management than does in-house development of the same product
  • decision tree analysis provides a systematic way to sort through the make-buy decision
    
    
    

Notes and figures from:

• Software Engineering: A Practitioner's Approach, 6th Edition, by Roger S Pressman, R.S. Pressman & Associates, McGraw-Hill, 2005