Cost Estimation in Software Development Projects


A Project Management Approach to Using Simulation for Cost Estimation on Large, Complex Software Development Projects

Misc. Quotes from the Article:

"The ability to obtain an accurate estimate of an entire project prior to its start is, unfortunately, unrealistic. And yet cost and
schedule estimates are necessary as management commits to funding such projects or bidding on a job (Mizell & Malone, 2007)."

"The tool will illustrate the difficulties management faces in forecasting budgets at the beginning of a project and may
encourage more realistic approaches to budgetary planning, including phased funding (Mizell & Malone, 2007)."

"Planning requires that an estimate be developed at a time in the project when the values of key parameters such as product
size and staff capabilities are unknown. This makes it unrealistic to expect an accurate estimate (Mizell & Malone, 2007)."

"Often….the initial (and highly uncertain) estimate becomes the official estimate for the entire project and is used to judge whether the
project is successful (Mizel & Malone, 2007)."

"Expert judgment approaches rely on experience on past projects and published industry averages. Average data does
not tell the whole story, and although past projects may seem similar, they will not have the same development costs, since
estimates based on past experience do not account for changes in environments, politics, or organizations (Abdel-Hamid
and Madnick, 1991)."

"Adequate management reserves and phased funding should be considered to account for uncertainty, especially
for larger and more complex software development projects (Mizel & Malone, 2007)."

"A recent government watchdog analysis showed that a majority of 27 recent projects were found to have costs tbat were
very different from the initial estimates, some by as much as 94% (Asaravala, 2004)."

"The project faced many of the following common problems that make software development cost estimation especially difficult;
costs and schedules are pre-delermined by an outside source, the software development process is not fully understood or
analyzed, requirements are not well-defined and are prone to changes, new projects are almost always different from past ones,
and software practitioners do not collect enough data for past projects {Agarwal and Kumar, 2001)."

Recommended Approach from the Article:

1. Utilize Software Development Process Model

A graphical representation of a software development lifecycle process is useful when educating decision-makers on the inherent complexity that makes large, complex software development projects so difficult. The model allows for the user to understand the (low of work that needs to be accomplished and to analyze the impact of things such as rework through
graphic display of the software product moving through the lifecycle steps.

2. Capture Uncertainty for Key Parameters by Using Probability Distributions

Three key parameters that greatly affect the cost and schedule of a software development project are size of the product, productivity of project personnel and defect rates. It is possihle to find average values tor productivity and defect rates in the literature, but it is important to point out that these parameters are subject to many influences that can greatly vary the value of the parameters throughout the course of a project. A great deal of uncertainty exists when trying to estimate values for these very important parameters before a project begins and early in the project; therefore, the use of probability distributions will allow for developing range estimates that consider the uncertainty that exists before a project begins. It is desirable to have data from similar projects and environments for
developing data distributions in order to obtain credibility for using tbe data as inputs to the simulation model. If adequate data is not available, the parameters for reasonable distributions can be estimated.

3. Run Model and Obtain Confidence Intervals for Effort and Schedule

Calculate confidence intervals for the two primary estimation parameters of effort and duration. When presenting the data, the lop half of the confidence interval should be focused on in order to deter the desire to accept the lower bound of tbe interval in order to meet the lowest possible cost and schedule. This will take into account other factors tbat may not be accounted for and will remind decision makers that all will never go as planned and that Murphy's Law is alive and well when it comes to large, software
development projects.

4. Compare Model Results with Other Estimating Techniques

Ideally, estimates developed with other techniques should fall within the upper half-width of the confidence interval in order to allow for those unplanned and unfavorable events that will occur
during the course of every big project.

5. Use Model Results to Debate Unrealistic Budgets

If a budget is set with values that do not fall within the confidence intervals produced by the simulation model, then the model should be used as a tool for debate. The key input parameters can be varied to show the impacts of such variation. The model should he run with animation so that decision makers can visualize the process and reasons for its complexity.

6. Update Model vi/ith Actual Project Data as Project Evolves

Actual project data can be used as inputs to the model as the project evolves. The model can be u.sed to analyze effort and schedule to complete based on actual project values to date. The
model can also be used to study problem areas and ibe effects of potential solutions.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License