Observations on Estimating

Observation on estimation is a leading   executive that was asked what single characteristic was most important when picking a project manager.  His response is a person with the ability to know what will go wrong previous it actually does. This might add the courage to estimate when the future is cloudy.

Cost, Estimation of resources, and schedule for software development of fort needed experience, access to good historical information and the courage to commit to quantitative measures when qualitative data are all which exist. It is this risk that leads to uncertainty and Estimation carries inherent risk.

Project complexity has a strong effect on the uncertainty which is inherent in planning.  Complexity, moreover, is relative measure which is affected by familiarity by past effort. The real time application might be perceived as exceedingly complex to a software group that has previously developed only batch applications. The similar real time application might be perceived as run-of-the-mill for a software group which has been heavily involved in high speed procedural control.  A number of quantitative software complexity measures have been proposed.  Such that measures are applied at code level or the design and are thus hard to use during software planning before a design and code exist.   However other more subjective assessments of complexity can be built early in the planning process.

Project size is another important factor which can affect by the   accuracy of estimates.   As the project size increase, the interdependency between various elements of the software grows rapidly.  The problem decomposition is an important approach to estimating to become harder because decomposed elements may still be formidable.   From the paraphrase Murphy's Law what can go wrong will go wrong and if there are more things which can fail more things will fail.

At the degree of structural uncertainty has an effect on estimation risk.  By this context structure provide to the degree to that needs have been solidified and the ease with which function can be compartmentalized and the hierarchical nature of information which must be processed.

The availability of historical data is also determines as estimation risk.  Santayana once said that those who cannot remember which past are condemned to repeat it.  By looking back we can emulate things which worked and avoid fields where problem arise.  When comprehensive software metrics are available for the past projects estimates can be made with the greater assurance schedules can be developed to avoid past difficulties and overall risk is reduced.

Risk is measured through the degree of uncertainty in the quantitative estimates which is established for cost, resources, and schedule.   If project scope is poorly understood or project needed are subject to change, uncertainty and risk will become dangerously high.   The software planner should require completeness of, performance, function and interface definitions contained in a system specification. The planner, and more   important  the  customer  should  be recognize  with the variability  in  software  needed  means instability in cost and schedule.

The project manager should not become obsessive about their estimation. Modern software engineering approaches example evolutionary process models   take an iterative view of development.  In these approaches it is possible to revisit the estimate as more information is known and revise it when the customer makes changes to needed.