Software Project Management (CS615)
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:
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.
225
© Copyright Virtual University of Pakistan
Software Project Management (CS615)
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
–
–
–
–
–
•
Basic process involves:
–
–
–
–
6.2
Strategic planning
Feasibility study and/or SOW
Proposals
Vendor and sub-contractor evaluation
Project planning (iteratively)
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
226
© Copyright Virtual University of Pakistan
Software Project Management (CS615)
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.
a)
b)
c)
d)
e)
Project complexity
Project size
The degree of structural uncertainty
The availability of historical information
Risk
a) 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.
b) 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.
c) 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.
227
© Copyright Virtual University of Pakistan
Software Project Management (CS615)
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.
228
© Copyright Virtual University of Pakistan