Spread Knowledge

CS615 - Software Project Management - Lecture Handout 29

User Rating:  / 1

Related Content: CS615 - VU Lectures, Handouts, PPT Slides, Assignments, Quizzes, Papers & Books of Software Project Management


Estimation - Concepts

Watts Humphrey in his book, Managing the Software process, has said, “If you don’t know where you are, a map won’t help.” This saying is very relevant while dealing with software project estimation. In a software project, unless you are sure
that your estimation is accurate, you cannot make much progress.

Estimation of factors such as cost, effort, risks, and resources is crucial. It gives you a fair idea of the size of the project. You can use the information about size to estimate the cost, effort, and duration of the project. This further helps plan for
resources and schedule the project.

In the early days of computing, software costs constituted a small percentage of the overall computer-based system cost. An order of magnitude error in estimates of software cost had relatively little impact.

Today, software is the most expensive element of virtually all computer-based systems. For complex, custom systems, a large increased cost estimation error can make the difference between profit and loss. Cost overrun can be disastrous for
the developer.

Software cost and effort estimation will never be an exact science. Too many variables - human, technical, environmental, political - can affect the ultimate cost of software and effort applied to develop it.

However, software project estimation can be transformed from a black art to a series of systematic steps that provide estimates with acceptable risk.

To achieve reliable cost and effort estimates, a number of options arise:

  1. Delay estimation until late in the project (obviously, we can achieve 100% accurate estimates after the project is complete!).
  2. Base estimates on similar projects that have already been completed.
  3. Use relatively simple decomposition techniques to generate project cost and effort estimates.
  4. Use one or more empirical models for software cost and effort estimation.

Unfortunately, the first option, however attractive, is not practical. Cost estimates must be provided 'up front.' However, we should recognize that the longer we wait, the more we know, and the more we know, the less likely we are to make
serious errors in our estimates.

The second option can work reasonably well, if the current project is quite similar to past efforts and other project influences (e.g., the customer, business conditions, the SEE, deadlines) are equivalent. Unfortunately, past experience has
not always been a good indicator of future results.

The remaining options are viable approaches to software project estimation.
Ideally, the techniques noted for each option should be applied in tandem; each used as a cross-check for the other.

Software project estimation is a form of problem solving, and in most cases, the problem to be solved (i.e., developing a cost and effort estimate for a software project) is too complex to be considered in one piece. For this reason, we decompose the problem, re-characterizing it as a set of smaller (and hopefully, more manageable) problems.

Following are some points related to project estimation:

  • Estimation is very difficult to do, but is often needed
  • It is created, used or refined during
    • Strategic planning
    • Feasibility study and/or SOW
    • Proposals
    • Vendor and sub-contractor evaluation
    • Project planning (iteratively)
  • Basic process involves:
    • Estimate the size of the product
    • Estimate the effort (man-months)
    • Estimate the schedule
    • NOTE: Not all of these steps are always explicitly performed

Estimation – A Critical factor

In a software project, unless you are sure that your estimation is accurate, you cannot make much progress.

Estimation of following factors are essential:

  • Cost,
  • Effort,
  • Risks
  • Resources

Estimation gives you a fair idea of the size of the project. You can use the information about size to estimate the cost, effort, and duration of the project.
This further helps plan for resources and schedule the project.

Estimation of resources, cost, and schedule for a software engineering effort requires:

  • Experience,
  • Access to good historical information
  • Courage to commit to quantitative predictions when qualitative information is all that exists

Estimation carries inherent risk and this risk leads to uncertainty.

  1. Project complexity
  2. Project size
  3. The degree of structural uncertainty
  4. The availability of historical information
  5. Risk


  1. Project complexity has a strong effect on the uncertainty, inherent in planning.
    Complexity, however, is a relative measure that is affected by familiarity with past effort. The first-time developer of a sophisticated e-commerce application might consider it to be exceedingly complex. However, a software team developing its tenth e-commerce Web site would consider such work run of the mill. A number of quantitative software complexity measures can be applied as per the need of project. Such measures are applied at the design or code level and are therefore difficult to use during Software planning (before a design and code
    exist). However, other, more subjective assessments of complexity (e.g., the function point complexity adjustment factors) can be established early in the planning process.
  2. Project size is another important factor that can affect the accuracy and efficacy of estimates. As size increases, the interdependency among various elements of the software grows rapidly. Problem decomposition, an important approach to estimating, becomes more difficult because decomposed elements may still be alarming. To paraphrase Murphy's Law: "What can go wrong will go wrong"- and if there are more things that can fail, more things will fail.
  3. The degree of structural uncertainty has an effect on estimation risk. In this context, structure refers to the degree to which requirements have been solidified, the ease with which functions can be compartmentalized and the hierarchical nature of the information that must be processed.
  4. The availability of historical information has a strong influence on estimation risk. By looking back, we can emulate things that worked and improve areas where problems arose.
  5. When comprehensive software metrics are available for past projects, estimates can be made with greater assurance, schedules can be established to avoid past difficulties, and overall risk is reduced.
  6. Risk is measured by the degree of uncertainty in the quantitative estimates established for resources, cost, and schedule. If project scope is poorly understood or project requirements are subject to change, uncertainty and risk become dangerously high.

The software planner should demand completeness of function, performance, and interface definitions (contained in a System Specification). The planner, and more important, the customer should recognize that variability in software requirements means instability in cost and schedule.