The Steps in Estimating

The Steps in Estimating

Generally, the steps in the software effort and cost estimation process are shown in "The SEI CMM and Estimating"  Figure (b). We'll look at these next.

Step 1. Establish Cost-Estimation Objectives

●  Understand how the estimates will be used. Will they be used to bid on a fixed-price contract? For external funding requests?

●  Tailor estimating objectives to decision-making information:

   - Absolute estimates are essential for labor or resource planning.
   - Relative estimates may be used for either/or decisions.
   - Liberal versus conservative estimates heightens decision confidence.

●  Re-examine estimation objectives as the process proceeds, and modify them where appropriate. Estimates will change as more project knowledge is gained.

Step 2. Develop a Plan for Estimation Activities; Plan for Resources

●  A plan sets accurate expectations for the cost and value of the estimation process.

●  View the estimation activities as a "miniproject". Estimation, like all other software activities, serves better when more effort is put into it (you get what you pay for). An estimate produced in 30 minutes will not be as accurate as one built upon individual developer's estimates of component parts of the system based on a carefully constructed WBS. The miniplan contains an early set of notes on the why, what, when, who, where, how, and how much of your estimating activity.

Step 3. Clarify Software Requirements

●  Pin down the requirements to the extent required to meet your estimating objectives.

●  Make the software specifications as specific and clear as possible, preferably quantifiable. Each specification must be testable so that a clear pass/fail test is defined for determining whether the developed software will satisfy the specification.

●  When you can't clarify, document any assumptions.

Step 4. Explore as Much Detail as Feasible

●  Remain consistent with estimating objectives.

●  The more detail is explored, the better technical understanding there will be and the more accurate the estimates will be.

●  The more pieces of software we estimate, the more the law of large numbers reduces estimate variance.

●  The more we think through all the software functions, the less likely we will miss the costs of the less obvious functions.

Step 5. Use Several Independent Techniques

●  No one method is better than others in all aspects.

●  Strengths and weaknesses of various methods are complementary.

●  A combination of techniques helps avoid the weaknesses of any single method.

Step 6. Compare, Understand, and Iterate Estimates

●  Each person has a unique experience, role, and set of incentives (optimist/pessimist phenomenon).

●  The use of multiple independent estimation techniques allows investigation into why estimates may differ, frequently an enlightening activity. Iterations converge into realistic estimates.

●  Pareto's Law phenomenon applies: Eighty percent of the cost is contained in 20 percent of the components. Examine and iterate these components in greater detail.

Step 7. Review Estimate Accuracy

●  Calibrate estimation techniques and models.

●  As with size estimation, several models are available for estimating effort. Most of them are based on philosophies that are basically mathematical, experiential, or based on regression.

Given that software estimates are imperfect, comparison of estimates with actuals provides an improved basis for management of the remainder of a given project or for future ones. Software projects are unpredictable and frequently are rescoped. The project manager re-estimates to reflect major changes. In software, unlike many other industries, the same product is never built twice. In addition to estimates taking into account the differences between a new project's specifications and previous ones, the differences in the development and delivery environment must also be taken into account - and with the fast-paced changes in technology, there may be no historical data upon which to base the new environment.

Some of the most extensively used models for determining effort (and, therefore, cost) are the Delphi method, which is nonautomated and used for estimating effort in exactly the same way that it is used for estimating size (refer to "Software Size and Reuse Estimating"), a regression-based model (we will look at COCOMO), a mathematical model (we will look at SLIM), and empirical models. This section will focus on the regression model and the mathematical model, and the formulas and tools that support them. No discussion of software sizing and estimating would be complete without mention of an empirical model from Software Productivity Research (SPR), a wholly owned subsidiary of Artemis Management Systems and a leader in software estimation and planning. Led by software development luminary Capers Jones, SPR provides a tool, SPR KnowledgePLAN®, for software estimation and planning. It includes a project wizard that simplifies the process of developing estimates, a sizing wizard that walks users through the sizing process, a goals wizard that helps users identify and achieve key project goals, and templates that help the user quick-start a project. The name most commonly associated with COCOMO is Dr. Barry Boehm. Lawrence Putnam, Sr., is associated with Quantitative Software Measurement (QSM, product is SLIM), and Capers Jones is associated with SPR (KnowledgePLAN®). Each of these experts is considered to be among the top problem solvers in the software estimation and measurement field, has published multiple full-length texts and articles, and has collected data from thousands of software projects.


software effort, cost estimation, software estimates, software projects
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
© Copyright 2018 SPMInfoBlog.
Designed by TechPlus