Download Estimation, Concepts-Software Project Management-Lecture Notes and more Study notes Software Project Management in PDF only on Docsity!
LECTURE # 29
6. ESTIMATION
6.1 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:
- Delay estimation until late in the project (obviously, we can achieve 100% accurate estimates after the project is complete!).
- 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 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
docsity.com
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
6.2 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:
docsity.com
d) 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.
e) 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.
f) 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.
docsity.com
