Chapter 5: How to estimate software effort (3708)

Chapter 5: How to estimate software effort (3708)

1. Introduction:

   • Successful projects are delivered on time,in budget and required quality
   • Effort estimates -> affect the costs
   • Activity durations -> affect delivery time
   • Difficulties
     • Subjective nature of estimating
     • Political implications
       • Internal
     • Changing technology
     • Lack of homogeneity of project experience
     • Use existing project data can also not be correct

2. 5.2 Where are estimates done

   • At Various stages
     • Strategic planning
       • Project portfolio management
     • Feasibility study
       • Benefits of system will justify the costs
     • System specification
       • Between requirements specification and design
       • Estimates at design stage confirms feasibility
     • Evaluation of suppliers proposals
     • Project planning
       • As planning and estimating becomes more detailed, smaller components will be estimated
       • Determine staff allocations
     • Step 3 of Stepwise
       • Specific provision for high level estimates.
       • Step 5-8 is for individual activities -> each one level lower

3. 5.3 Problems with over and under estimating

   • Over estimating causes longer projects
     • Two laws
       • Parkinson's Law
         • Work expands to fill the time available
         • Staff works less hard with easy target
       • Brooke's Law
         • Effort to complete project increase disproportionately to the number of staff assigned to project
         • Additional management, coordination and communication
         • Putting more people on a late job makes it later
   • Under estimating
     • Might not be completed in time or cost
     • Affects quality due to pressure deadlines
     • Weinberg's zeroth law of reliability -> If a system doesn't have to be reliable, it can meet any other objective
   • Targets must be achievable. Increases morale and motivation
   • Estimates are not predictions -> They are managed goals

4. 5.4 Basis for software estimating

   • Need for historical data
     • Past projects and new projects might not have the same merrits
   • Measure of work
     • Difficult in the beginning as many unknowns
     • Work size is estimated due to uncertainty in eg. Skill of workers
       • Source lines of code (SLOC)
       • Thousands lines of code (KLOC)

5. 5.5 Software effort estimation techniques

   • Boehm's software effort model
     • Algorithmic models
       • Uses 'Effort Drivers' which are characteristics of the system and the implementation environment to determine effort
     • Expert judgement
       • Staff
       • Relying on a knowledgeable person
       • Combination of informal analogy and bottom-up approach
     • Analogy
       • Compare to similar completed project
         • estimator identifies other projects (Source projects) with similar traits to new project (target projects)
       • Also called 'case-based reasoning'
       • One way to compare source to target is using ANGEL software
         • Measures Euclidean distance between projects
     • Parkinson
       • Staff effort available becomes the estimate
       • Not really effort prediction method. Methods for setting scope
     • price to win
       • Estimate sufficiently low to win the contract
       • Not really effort prediction methods. Method to determine price
     • top-down
       • Overall effort of project is broken down into effort required for components
     • bottom-up
       • component tasks are identified and sized, and aggregated to overall estimate

6. 5.6 Bottom-up estimating

   • Iterative process to break components into small 1-2 week tasks
   • Better at the later stages of planning with more details
   • Top-Down approach a precursor to bottom-up
   • Procedural code -orientated approach
     • bottom-up works at the level of activities
     • Major activity is writing code at the software components level
       • How to use bottom-up on software components
         • Envisage number and type of modules in final system
           • Identify primitive functions -> eg CRUD
         • Estimate SLOC of each identified module
           • Broad structure of the system and procedures
         • Estimate work content, and the complexity and technical difficulty
           • Multiply SLOC by a factor -> subjective
         • Calculate work days effort
           • Use historical data to convert weighted SLOC to effort

7. 5.7 Top-down approach and parametric models

   • Associated with parametric or algorithmic models
     • Parameters such a KLOC and system size can be input
   • Can use the analogy of estimating the effort to rebuild a house to resemble Top-Down approach
   • Parametric models -> use formulas like
     • effort = system size * productivity rate
   • A model to forecast software development effort has two key components
     • 1 -> Method to estimate work needed
     • 2 -> Rate at which the task can be done
   • KLOC is a size driver and dev experience is a productivity driver
   • Productivity = effort/size
     • Or you can use 'least squares regression' to derive an equation in the form:
       • effort = constant1 +(size*constant2)
   • Some parametric models are focused on system/task size while COCOMO are concerned with productivity factors
   • Having calculated the effort required -> this needs to be allocated to various activities in the project

8. 5.10 Albrecht function point analysis (IFPUG)

   • Top down approach
   • Need to quantify the functional size of programs independent of programming language
     • The concept of functional points were created
       • Functional point analysis is on the basis that information systems comprise 5 major components, or 'external user types', which benefit the users
         • External input types
           • Input transactions which update internal computer files
         • External outputs types
           • Data is output to the user
             • Eg. Screen, reports
         • External inquiry types
           • transactions initiated by the user which provide information but don't update the internal file
           • Directs the system to the information required
         • Logical internal file types
           • The files used by the system. In modern terms a database, relational table/entity
         • External interface file
           • Allows for output and input that may flow between applications
         • Each external user type is identified in the application and is classified -> high, low and average complexity
           • Each complexity is multiplied by a weight to get FP score -> summed then to get overall FP for information processing size

9. 5.11 Functional points Mark 2

   • Implies a improvement on Albrecht
   • Information processing size measured in unadjusted function points (UFP) to which a technical complexity adjustment (TCA) is applied
   • Assumption that information system comprise transactions with the structure below

10. 5.12 COSMIC full function points

    • Albrecht (IFPUG) is suitable for information systems, not for real time and embedded systems
    • The COSMIC FFP was designed as an extension of IFPUG
      • Argument is that existing FP methods are good at measuring work effort in Info system-> Internal procedures are mirrored by external features
      • With embedded/real time systems the system features will be hidden -> interaction will be with hardware or other software
      • COSMIC deals with this -> decomposing the system architecture into a hierarchy of software layers
        • Layer above provide data up and request data from below
        • A single layer can contain components which engage in peer-to-peer communication
        • This determines the boundaries of the software components -> The points at which it receives input and transmits outputs
        • Inputs and outputs are aggregated into data groups -> each data group relate to the same object of interest
        • Data groups can be moved about in four ways
          • entries (E)
          • exits (X)
          • reads (R)
          • writes (W)
        • Overall FFP determined by adding all the counts of each of the four types of data movements
          • UOM -> Cfsu (COSMIC functional size unit)
    • COSMIC -> Common Software Measurement Consortium

11. 5.13 COCOMO 2 : a parametric productivity model

    • Constructive Cost Model
    • Effort -> measured in pm (person months) consisting of units of 152 hours working hours
      • Model to calc person months
        • pm -> effort in person months
        • A = 2.94
        • size -> kdsi
          • derived from FP count
        • sf -> exponent scale factor
          • b = 0.91
          • The effect of the exponent -> increase effort prediction for larger projects
          • Qualities which govern exponent drivers used to calculate scale factor
            • Precedentness (PREC)
            • Development Flexibility (FLEX)
            • Architecture/risk resolution (RESL)
            • Team Cohesion (TEAM)
            • Process Maturity (PMAT)
            • Each of the scale factors for a project is rated -> Very low, low, normal, high, very high
              • These are summed then multiplied by 0.01 and added to constant 0.91 to get overall exponent scale factor
        • In COCOMO 2 model the effort multiplier (em) adjusts the estimate to take account of productivity factors
          • Doesn't involve economies or dis-economies of scale
          • each multiplier, for an app can be given a rating of extra low to extra high
            • Value > 1 increases dev effort and <1 decreases
    • Size -> measured in kdsi ('thousands of delivered source code instructions')
    • c and k -> constants
    • Step 1: Determine system size in terms of kdsi
      • c and k determined by system classification
        • Organic
          • Small dev team, in-house environment, flexible interface requirements
        • Embedded
          • System operates in tight constraints. Changes to system are costly
        • Semi-detached
          • Combination between organic and embedded or in between the two
        • Related to system environment and technical nature of system
        • k >1 -> larger projects require disproportionately more effort than smaller ones
    • Estimates are required at different stages -> COCOMO 2 accommodates with three models at different stages
      • Application composition
        • External features of the system which the user will experience is designed
        • Prototyping will be used, small applications, using high productivity tools
      • Early design
        • Fundamental software structures are designed
        • System functional complexity affects architecture
        • FP's used to gauge basic system size
          • FP can be converted to LOC -> multiply by factor for programming language
      • Post architecture
        • Final construction, modification and tuning of system structure for final system

Images and files in the map