Software Project Estimation: Part 2

Back to Part 1

Step 7: Determination of Impact of Risk

The purpose of this step is to identify the software project risks, to assess their impact on the cost estimate, and to revise the estimates based on the impacts. Project risks affect all aspects of a software project: the organization, the personnel, the technology etc. One can distinguish between two types of risks:

Direct risks - The risk over which a project has a large degree of control.
Indirect risks - The risk over which a project has little or no control.

It is important to take risks into account when estimating project cost and duration in order to obtain realistic estimates. This is particularly crucial at the early stages of a project when risk is typically at its highest. However, risks are inherently unpredictable. Risks that were not even considered may suddenly emerge and have a serious impact.

Responsible Persons: Software manager, cognizant engineers, and software estimators.

The outputs of step 7 are:

• Detailed software project risk list.
• Assumptions made to revise estimates.
• Methods used to revise estimates.
• Revised size, effort, schedule, and cost estimates for risk.

Step 8: Validate and Reconcile the Estimate via Models and Analogy

In this step, validation and reconciliation of the estimates are done through Models and Analogy.

1. First, in addition to the main estimate which we have developed in the preceding steps, obtain a second estimate, using one of the following:
   • Alternate Estimate: Have a second person or team, with similar software experience, generate independent estimates.
   • Historical Analogies: Through historical data compare the estimates with previous experience such as size, effort, and cost of similar software; size versus functions; size versus effort and cost (development productivity); technology versus effort and cost.
   • Model-Based Estimates: Model based estimates are done by the use of models which we will discuss after these steps.
      
2. Secondly, have the responsible people for this step who are able to compare the main estimates with the second estimates, resolve the differences, and refine the estimates until a consensus estimate is reached. The lowest estimates should be given special scrutiny, as experience has demonstrated that estimates are usually low. For specific information on validating and reconciling estimates with models.

Responsible Persons: Software manager, cognizant engineers, and software estimators.

The outputs of step 8 are:

• Assumptions made to validate the estimates.
• Methods used to validate the estimates.
• Validated and revised size, effort, schedule, and cost estimates with improved accuracy.

Step 9: Review and Approve the Estimates

In this step just take a review of the above size, effort, schedule, and cost estimates and compare with the project budget and schedule and approve software size effort, schedule, and cost estimates to obtain project and line management approval.
The software manager, software estimators, line management, and project management approve the software estimates after the review is complete and problems have been resolved. Remember that costs cannot be reduced without reducing functionality.

Responsible Persons: The above personnel, software engineer with experience on similar project, line and project management.

The outputs of step 9 are:

• Problems found with the estimates.
• Reviewed, revised, and approved size, effort, schedule, cost estimates, and assumptions.
• Work Agreements, if necessary.

Step 10: Track, Report, and Maintain the Estimates

To check the accuracy of the software estimates over time, and provide the estimates to save for use in future software project estimates is the main purpose of this step.

1. Track the estimates to identify when, how much, and why the project may be overrunning or under-running the estimates.
2. Document changes between the current and past estimates and budgets.
3. In order to improve estimation and planning, archive software estimation and actual data each time an estimate is updated and approved, usually at each major milestone. It is recommended that the following data be archived:

Project contextual and supporting information

• Project name
• Software organization
• Platform
• Language
• Estimation method(s) and assumptions
• Date(s) of approved estimate(s)

Estimated and actual size, effort, cost, and cost of procurements by WBS work element

Planned and actual schedule dates of major milestones and reviews

Identified risks and their estimated and actual impacts.

Responsible Persons: Software manager, software engineers and software estimators.

The outputs of this step are as follows:

• Updated tracking comparisons of actual and estimated data.
• Evaluation of the comparisons.
• Updated size, effort, schedule, cost estimates, and risk assessment.
• Archived software data, including estimates and actuals.

When the process of estimation is complete, the first thing we are interested to know is: how accurate the estimates are to reality? But we don't get the answer at this stage because our project is incomplete. There is always some uncertainty associated with all estimation techniques.

Some Reasons:

Reasons that make the task of cost estimation difficult:

• Sufficient time is not allocated for planning.
• Software cost estimation is often done hurriedly, without an appreciation for the actual effort required and is far from real issues.
• Lack of experience, especially for large projects.
• An estimator uses the extrapolation technique to estimate, while ignores the non-linear aspects of software development process.

Reasons for poor and inaccurate estimation:

• Requirements are imprecise and also, change frequently.
• Different from past projects handled.
• Not having enough information about past projects.
• Estimates are forced to be based on available resources.

Problems with estimates:

• Schedule is estimated often, by skipping the size estimation which is of more relevance to the management.
• Estimating size is the most difficult step which has a bearing on all other estimates.
• Even good estimates are only projections and subject to various risks.
• Less importance given to collection and analysis of historical data of past development projects which is the best input to estimate a new project.
• Project managers often underestimate the schedule because management and customers often hesitate to accept a prudent realistic schedule.

Project Estimation Guidelines:

• Data should be documented and preserve, related to organization's past projects.
• There must be sufficient time for project estimation especially for bigger projects.
• Prepare realistic developer-based estimate.
• Use software estimation tools.
• Re-estimate the project during the life cycle of development process.
• Analyse past mistakes in the estimation of projects.

Models For Estimation Based on Bayesian Belief Networks

According to "Bayesian Belief Networks" there are 4 sub-models which are used to model the relationships between quality, effort, schedule and scope for software development and testing separately. The sub-models are:

The estimation models are based on the following relationship: 

                              E = f (vi)
E = different project estimates like effort, cost, schedule etc.
vi = directly observable parameter like LOC, function points.

Component Estimation Model: It contains variables related to component development activities which cover defect introduction, development effort, duration estimation and resources allocation. In a large project a software system may consist of a number of components, which are designed and implemented by different development teams, or even different organizations or software vendors. Therefore, component development can be regarded as a main part in the development phase. And it is also highly related to defect introduction. Here we simplify the structure by hiding several internal nodes.

Test Effectiveness Estimation Model: In software development, the most important defect removal activity after component development is the test. Test effectiveness, the percentage of faults that were exposed through test execution, is the most important metric for handling the number of defects. Here is a model for Test effectiveness estimation.

Continue to Part 3