Page 121 - DCAP304_DCAP515_SOFTWARE_PROJECT_MANAGEMENT

Unit 6: Effort Estimation

 Discuss the First Boot Notes
 Create the User Account

Introduction

Among the important practical problems in software engineering is software estimation – the
estimation of development schedules and the assessment of productivity and quality. Is it possible
to apply mathematical and scientific principles to software estimation, so that development
schedules, productivity, and quality might be objectively ascertained or estimated rather than
being a matter of opinion?
The debate over this question is familiar. In the case of development schedules, for example,
many programmers find it self evident that accurate and objective estimates are not possible.
One reader of an early version of this paper commented, “Software practitioners know about
poor predictability from empirical evidence. I don’t need to prove it...”
On the other hand, there are a large number of design methods, development processes, and
programming methodologies that claim or hint at objective estimation of development schedules,
project complexity, and programmer productivity.

6.1 Effort Estimation

Many People Have Referred to Estimation as a “BLACK ART.” This makes some intuitive sense:
at first glance, it might seem that estimation is a highly subjective process. One person might
take a day to do a task that might only require a few hours of another’s time. As a result, when
several people are asked to estimate how long it might take to perform a task, they will often
give widely differing answers. But when the work is actually performed, it takes a real amount
of time; any estimate that did not come close to that actual time is inaccurate.
To someone who has never estimated a project in a structured way, estimation seems little more
than attempting to predict the future. This view is reinforced when off-the-cuff estimates are
inaccurate and projects come in late. But a good formal estimation process, one that allows the
project team to reach a consensus on the estimates, can improve the accuracy of those estimates,
making it much more likely that projects will come in on time.

Notes A project manager can help the team to create successful estimates for any software
project by using sound techniques and understanding what makes estimates more accurate.

6.1.1 Elements of a Successful Estimate

A sound estimate starts with a Work Breakdown Structure (WBS). A WBS is a list of tasks that, if
completed, will produce the final product. The way the work is broken down dictates how it will
be done. There are many ways to decompose a project into tasks. The project can be broken
down by feature, by project phase (requirements tasks, design tasks, programming tasks, QA
tasks, etc.), or by some combination of the two. Ideally, the WBS should reflect the way previous
projects have been developed.

A useful rule of thumb is that any project can be broken down into between 10 and 20 tasks. For
large projects (for example, a space shuttle), those tasks will be very large (“Test the guidance
system”); for small projects (like writing a simple calculator program), the tasks are small
(“Build the arithmetic object that adds, multiplies, or divides two numbers”). The team must

LOVELY PROFESSIONAL UNIVERSITY 115