Estimation - Concepts

<< ORGANIZATIONAL PLANNING, Organizational Management Tools

Decomposition Techniques, Estimation â€“ Tools >>

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

222

Software Project Management (CS615)

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:

Cost,

Effort,

223

Software Project Management (CS615)

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.

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.

224

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.

225

Table of Contents: