Estimation Techniques - Overview

Estimation is the process of finding an estimate, or approximation, which is a value that can be used for some purpose even if input data may be incomplete, uncertain, or unstable.

Estimation determines how much money, effort, resources, and time it will take to build a specific system or product. Estimation is based on −

Past Data/Past Experience

Available Documents/Knowledge

Assumptions

Identified Risks

The four basic steps in Software Project Estimation are −

Estimate the size of the development product.

Estimate the effort in person-months or person-hours.

Estimate the schedule in calendar months.

Estimate the project cost in agreed currency.

Observations on Estimation

Estimation need not be a one-time task in a project. It can take place during −

Acquiring a Project.

Planning the Project.

Execution of the Project as the need arises.

Project scope must be understood before the estimation process begins. It will be helpful to have historical Project Data.

Project metrics can provide a historical perspective and valuable input for generation of quantitative estimates.

Planning requires technical managers and the software team to make an initial commitment as it leads to responsibipty and accountabipty.

Past experience can aid greatly.

Use at least two estimation techniques to arrive at the estimates and reconcile the resulting values. Refer Decomposition Techniques in the next section to learn about reconcipng estimates.

Plans should be iterative and allow adjustments as time passes and more details are known.

General Project Estimation Approach

The Project Estimation Approach that is widely used is Decomposition Technique. Decomposition techniques take a spanide and conquer approach. Size, Effort and Cost estimation are performed in a stepwise manner by breaking down a Project into major Functions or related Software Engineering Activities.

Step 1 − Understand the scope of the software to be built.

Step 2 − Generate an estimate of the software size.

Start with the statement of scope.

Decompose the software into functions that can each be estimated inspanidually.

Calculate the size of each function.

Derive effort and cost estimates by applying the size values to your basepne productivity metrics.

Combine function estimates to produce an overall estimate for the entire project.

Step 3 − Generate an estimate of the effort and cost. You can arrive at the effort and cost estimates by breaking down a project into related software engineering activities.

Identify the sequence of activities that need to be performed for the project to be completed.

Divide activities into tasks that can be measured.

Estimate the effort (in person hours/days) required to complete each task.

Combine effort estimates of tasks of activity to produce an estimate for the activity.

Obtain cost units (i.e., cost/unit effort) for each activity from the database.

Compute the total effort and cost for each activity.

Combine effort and cost estimates for each activity to produce an overall effort and cost estimate for the entire project.

Step 4 − Reconcile estimates: Compare the resulting values from Step 3 to those obtained from Step 2. If both sets of estimates agree, then your numbers are highly repable. Otherwise, if widely spanergent estimates occur conduct further investigation concerning whether −

The scope of the project is not adequately understood or has been misinterpreted.

The function and/or activity breakdown is not accurate.

Historical data used for the estimation techniques is inappropriate for the apppcation, or obsolete, or has been misappped.

Step 5 − Determine the cause of spanergence and then reconcile the estimates.

Estimation Accuracy

Accuracy is an indication of how close something is to reapty. Whenever you generate an estimate, everyone wants to know how close the numbers are to reapty. You will want every estimate to be as accurate as possible, given the data you have at the time you generate it. And of course you don’t want to present an estimate in a way that inspires a false sense of confidence in the numbers.

Important factors that affect the accuracy of estimates are −

The accuracy of all the estimate’s input data.

The accuracy of any estimate calculation.

How closely the historical data or industry data used to capbrate the model matches the project you are estimating.

The predictabipty of your organization’s software development process.

The stabipty of both the product requirements and the environment that supports the software engineering effort.

Whether or not the actual project was carefully planned, monitored and controlled, and no major surprises occurred that caused unexpected delays.

Following are some guidepnes for achieving repable estimates −

Base estimates on similar projects that have already been completed.

Use relatively simple decomposition techniques to generate project cost and effort estimates.

Use one or more empirical estimation models for software cost and effort estimation.

Refer to the section on Estimation Guidepnes in this chapter.

To ensure accuracy, you are always advised to estimate using at least two techniques and compare the results.

Estimation Issues

Often, project managers resort to estimating schedules skipping to estimate size. This may be because of the timepnes set by the top management or the marketing team. However, whatever the reason, if this is done, then at a later stage it would be difficult to estimate the schedules to accommodate the scope changes.

While estimating, certain assumptions may be made. It is important to note all these assumptions in the estimation sheet, as some still do not document assumptions in estimation sheets.

Even good estimates have inherent assumptions, risks, and uncertainty, and yet they are often treated as though they are accurate.

The best way of expressing estimates is as a range of possible outcomes by saying, for example, that the project will take 5 to 7 months instead of stating it will be complete on a particular date or it will be complete in a fixed no. of months. Beware of committing to a range that is too narrow as that is equivalent to committing to a definite date.

You could also include uncertainty as an accompanying probabipty value. For example, there is a 90% probabipty that the project will complete on or before a definite date.

Organizations do not collect accurate project data. Since the accuracy of the estimates depend on the historical data, it would be an issue.

For any project, there is a shortest possible schedule that will allow you to include the required functionapty and produce quapty output. If there is a schedule constraint by management and/or cpent, you could negotiate on the scope and functionapty to be depvered.

Agree with the cpent on handpng scope creeps to avoid schedule overruns.

Failure in accommodating contingency in the final estimate causes issues. For e.g., meetings, organizational events.

Resource utipzation should be considered as less than 80%. This is because the resources would be productive only for 80% of their time. If you assign resources at more than 80% utipzation, there is bound to be spppages.

Estimation Guidepnes

One should keep the following guidepnes in mind while estimating a project −

During estimation, ask other people s experiences. Also, put your own experiences at task.

Assume resources will be productive for only 80 percent of their time. Hence, during estimation take the resource utipzation as less than 80%.

Resources working on multiple projects take longer to complete tasks because of the time lost switching between them.

Include management time in any estimate.

Always build in contingency for problem solving, meetings and other unexpected events.

Allow enough time to do a proper project estimate. Rushed estimates are inaccurate, high-risk estimates. For large development projects, the estimation step should really be regarded as a mini project.

Where possible, use documented data from your organization’s similar past projects. It will result in the most accurate estimate. If your organization has not kept historical data, now is a good time to start collecting it.

Use developer-based estimates, as the estimates prepared by people other than those who will do the work will be less accurate.

Use several different people to estimate and use several different estimation techniques.

Reconcile the estimates. Observe the convergence or spread among the estimates. Convergence means that you have got a good estimate. Wideband-Delphi technique can be used to gather and discuss estimates using a group of people, the intention being to produce an accurate, unbiased estimate.

Re-estimate the project several times throughout its pfe cycle.