17.3 An Example of a Standardized Estimation Procedure for Sequential Projects


17.3 An Example of a Standardized Estimation Procedure for Sequential Projects

Table 17-3 shows an example of a standardized estimation procedure that could be used to estimate sequential software projects. This estimation procedure assumes that the organization's main priority is the software's feature set and that the main goal of estimation is to refine the accuracy of the cost and schedule estimates.

Table 17-3: Example Standardized Estimation Procedure for Sequential Projects—Emphasis on Estimating Cost and Schedule
  1. Exploratory Estimate (Approved Product Definition)

    1. Create at least one estimate using each of the following approaches:

      1. One estimator shall estimate the project bottom-up, using a work breakdown structure.

      2. One estimator shall estimate the project using standard components.

      3. One estimator shall estimate the project top-down, using estimation by analogy with similar past projects.

    2. Estimators shall use a Wideband Delphi process to converge to a single-point nominal estimate (N).

    3. Estimates must always be presented as a range from 0.5N to 2.0N (i.e., -50%, +100%).

      1. The single-point nominal developed for use in these calculations should not be presented.

      2. These estimates may not be used for budgeting or external commitments, except to approve budget for completing the Product Design stage.

  2. Budget Estimate (Product Design Complete)

    1. Create new estimates using two of the approaches from step I:

      1. Estimate the project bottom-up, using a work breakdown structure.

      2. Estimate the project using standard components.

    2. Create a function points estimate.

      1. Compute function points based on requirements specification.

      2. Calibrate estimation software using historical data from within our organization.

      3. Estimate the nominal effort and schedule using a commercial estimation software package.

    3. Iterate estimates II.A(1), II.A(2), and II.B until the estimates converge to within 5% of each other. Use the average of these estimates as the nominal, N.

    4. Compute estimate range as 0.8N to 1.25N.

      1. Budget shall be allocated based on 1.0N.

      2. Contingency budget shall be allocated as 0.25N.

      3. Additional contingency may be allocated to allow for organization's historical rate of requirements growth.

      4. Only the high end of the range (1.25N) should be published.

      5. This estimate shall not be used for external commitments.

  3. Preliminary Commitment Estimate (After Second Interim Release)

    1. Build a bottom-up estimate.

      1. Create a detailed task list.

        1. Task list shall be reviewed by the development lead, test lead, and documentation lead.

      2. Have each developer, tester, and other individual contributors estimate the effort required to implement the requirements that he or she will be responsible for.

        1. Modules shall be estimated using best case, worst case, and expected case.

        2. Module nominals should be computed using the formula [BestCase + (4 x Expected Case) + WorstCase] / 6.

      3. Add up the individual module nominals.

    2. Compare II.D to III.A(3). Compute a nominal estimate, N, using the following formula: (2 x TheHigherEstimate + TheLowerEstimate) / 3

    3. Compute estimate ranges as from 1.0 N to 1.1 N.

      1. The high end of the range (1.1N) may be published externally.

      2. External commitments may be made to 1.1N.

      3. The range 1.0N to 1.1N may be published internally.

  4. Final Commitment Estimate (After Third Interim Release)

    1. Compare estimated results to actual results from step III.

      1. Compute a revised nominal based on the following formula: RemainingEffort = PlannedRemainingEffort / (ActualEffortToDate / PlannedEffortToDate)

      2. Add any tasks that were omitted from step III.

    2. The sum of IV.A.1 and IV.A.2 may be used as the new Nominal Effort, N.

      1. The nominal (1.0N) may be published externally.

      2. External commitments may be made to 1.0N.

      3. The range 0.9N to 1.1N may be published internally.

  5. Project Shall Be Reestimated at Any Time in Response to Major Changes in Project Assumptions

    1. Changes in assumptions include but are not limited to increase in requirements, changes in definitions of major requirements, changes in staff availability, and changes in schedule targets.

  6. Project Completion

    1. Collect and archive data on actual project results for future use.

    2. Review estimate accuracy of each estimate.

      1. Analyze root causes of any major errors.

      2. Assess whether the same accuracy could be produced with less effort.

      3. Propose revisions to the standardized estimation procedure.

The estimation procedure shown in Table 17-3 illustrates all of the elements commonly found in estimation procedures:

  • Emphasizes counting and computing when possible, rather than using judgment The estimates created for the Exploratory Estimate (Estimate I in Table 17-3) call for decomposition via a work breakdown structure, estimation by analogy, and estimation using standard components. None of these approaches is terribly accurate, but each involves at least some computation rather than just pure judgment.

  • Calls for use of multiple estimation approaches and comparison of results The first three estimates (Estimates I, II, and III) call for multiple estimation approaches. More approaches are used early in the project, when computationally based approaches are not as available.

  • Communicates a plan to reestimate at predefined points in the project The plan calls for Estimates I through V, which indicates an intent to reestimate periodically. Each estimate is linked to specific milestones in the project.

  • Defines how the required estimation approach changes over the course of a project The details of each step are different, based on the improving project-generated data that becomes available later in the project. Late in the project, historical data from the same project becomes the primary basis for the estimate.

  • Contains a clear description of an estimate's inaccuracy Each of the stages in the procedure contains an expression of inaccuracy. Estimate I.C calls for a range of -50% to +100%, narrowing to ±10% in Estimate IV.B.

  • Defines when an estimate can be used as the basis for a project budget Estimate II is referred to as the "Budget Estimate." Estimate I states explicitly that it shall not be used becomes the basis for a budget.

  • Defines when an estimate can be used as the basis for internal and external commitments Estimate III is called the "Preliminary Commitment Estimate," and Estimate IV is called the "Final Commitment Estimate." Earlier estimates explicitly state that they shall not be used as the basis for external commitments.




Software Estimation. Demystifying the Black Art
Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))
ISBN: 0735605351
EAN: 2147483647
Year: 2004
Pages: 212

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net