Lesson 3: Estimation
Software Project Management
* 1
Software Project Management
Review
*
stakeholder
Project manager
team of software engineers
Business analysts or requirements analysts
◦ Designers and architects
◦ Programmers
◦ Testers
2
Software Project Management
* Vision and Scope Document
1. Problem Statement
a) Project background
b) Stakeholders
c) Users
d) Risks
e) Assumptions
2. Vision of the Solution
a) Vision statement
b) List of features
c) Scope of phased release (optional)
d) Features that will not be developed
3
Software Project Management
What is estimation?
*
The project manager must set expectations
about the time required to complete the software
among the stakeholders, the team, and the
organization’s management.
If those expectations are not realistic from the
beginning of the project, the stakeholders will
not trust the team or the project manager.
4
Software Project Management
Some problems with estimating
7:55:17 PM
Subjective nature of much of estimating
Lots of guesswork - difficult to produce evidence
Political pressures
Managers may wish make estimates low to win
support for a project proposal
Changing technologies
these bring uncertainties can be a ‘learning curve’
Projects differ
Experience on one project may apply to another
5
Software Project Management
Elements of a Sound Estimate
*
To generate a sound estimate, a project manager must
have:
A work breakdown structure (WBS), or a list of tasks
which, if completed, will produce the final product
An effort estimate for each task
A list of assumptions which were necessary for
making the estimate
Consensus among the project team that the estimate
is accurate
6
Software Project Management
7
Software Project Management
Work Breakdown Structure
*
Define project scope by listing all of major
sub-projects or deliverables on a project
The decomposition of a WBS
Represent unique work
Clearly defined duration or a total effort
Discrete enough
Responsibility can be assigned to a person or
group
8
Software Project Management
WBS
*
WBS family tree diagram
Tracking cost
8/80 rule
No work package should be fewer than 8
labor hours or more than 80 labor hours
9
Software Project Management
Assumptions Make Estimates More Accurate
*
Team members make assumptions about the work to be
done in order to deal with incomplete information
Any time an estimate must be based on a decision that has not
yet been made, team members can assume the answer for the
sake of the estimate
Assumptions must be written down so that if they prove to be
incorrect and cause the estimate to be inaccurate, everyone
understands what happened
Assumptions bring the team together very early on in the project
so they can make progress on important decisions that will affect
development
10
Software Project Management
Effort Estimation Models
*
A software estimation model defines the project characteristics
whose values (or their estimates) it needs and the ways these values
are used to compute the effort.
the estimation model will require values of characteristics that can be
measured at that stage.
The size of the software is the predominant factor in determining how
much effort is needed to build it.
Many models have been proposed that use this top-down approach
to estimation,
COCOMO model being the most famous.
Models using function points (instead of LOC) as size units have also been built.
you can accommodate other factors that affect the effort by refining the
estimates based on these factors.
11
Software Project Management
In the bottom-up approach, on the other hand, you
obtain the estimates first for parts of the project and
then for the overall estimate.
The bottom-up approach lends itself to direct
estimation of effort; once the project is partitioned into
smaller tasks, it is possible to directly estimate the
effort required for them.
a key advantage of this approach is that it does not
require explicit size estimates for the software.
Instead, it requires a list of project tasks.
12
Software Project Management
Both the top-down and the bottom-up approaches
require information about the project: size (for top-
down approaches) and a list of tasks (for bottom-up
approaches).
In many ways, these approaches are complementary.
Both types of estimates are more accurate if more
information about the project is available or as the
project proceeds.
For example, estimating the size is much more difficult when
very high level requirements are given but becomes
considerably easier when design is finished, and even easier
and more accurate when13code is developed.
Software Project Management
The Bottom-up Estimation Approach
*
14
Software Project Management
The Bottom-up Estimation Approach
*
1. Identify programs in the system and classify them as simple, medium, or complex
(S/M/C).
2. If a project-specific baseline exists, get the average build effort for S/M/C programs
from the baseline.
3. If a project-specific baseline does not exist, use project type, technology, language, and
other attributes to look for similar projects in the process database. Use data from these
projects to define the build effort of S/M/C programs.
4. If no similar project exists in the process database and no project-specific baseline
exists, use the average build effort for S/M/C programs from the general process capability
baseline.
5. Use project-specific factors to refine the build effort for S/M/C programs.
6. Get the total build effort using the build effort of S/M/C programs and the counts for
them.
7. Using the effort distribution given in the capability baseline or for similar projects given in
the process database, estimate the effort for other tasks and the total effort.
8. Refine the estimates based on project-specific factors.
15
Software Project Management
*
Top-Down Estimation
16
Software Project Management
Top-Down Estimation
*
1. Get the estimate of the total size of the software in function points.
2. Using the productivity data from the project-specific capability
baseline, from the general process capability baseline, or from
similar projects, fix the productivity level for the project.
3. Obtain the overall effort estimate from the productivity and size
estimates.
4. Use effort distribution data from the process capability baselines
or similar projects to estimate the effort for the various phases.
5. Refine the estimates, taking project-specific factors into
consideration.
17
Software Project Management
Wideband Delphi
*
Wideband Delphi is a process that a team
can use to generate an estimate
The project manager chooses an estimation
team, and gains consensus among that team
on the results
Wideband Delphi is a repeatable estimation
process because it consists of a
straightforward set of steps that can be
performed the same way each time
18
Software Project Management
The Wideband Delphi Process
*
Step 1: Choose the team
The project manager selects the estimation
team and a moderator. The team should
consist of 3 to 7 project team members.
• The moderator should be familiar with the Delphi
process, but should not have a stake in the
outcome of the session if possible.
• If possible, the project manager should not be the
moderator because he should ideally be part of the
estimation team.
19
Software Project Management
The Wideband Delphi Process
*
Step 2: Kickoff Meeting
The project manager must make sure that each team
member understands the Delphi process, has read
the vision and scope document and any other
documentation, and is familiar with the project
background and needs.
The team brainstorms and writes down assumptions.
The team generates a WBS with 10-20 tasks.
The team agrees on a unit of estimation.
20
Software Project Management
The Wideband Delphi Process
*
Step 3: Individual Preparation
Each team member independently generates
a set of preparation results.
For each task, the team member writes down
an estimate for the effort required to complete
the task, and any additional assumptions he
needed to make in order to generate the
estimate.
21
Software Project Management
The Wideband Delphi Process
*
Step 4: Estimation Session
During the estimation session, the team comes to a
consensus on the effort required for each task in the
WBS.
Each team member fills out an estimation form which
contains his estimates.
The rest of the estimation session is divided into
rounds during which each estimation team member
revises her estimates based on a group discussion.
Individual numbers are not discussed.
22
Software Project Management
The Wideband Delphi Process
Step 4: Estimation Session (continued)
The moderator collects the estimation
forms and plots the sum of the effort from
each form on a line:
23 *
Software Project Management
The Wideband Delphi Process
Step 4: Estimation Session (continued)
The team resolves any issues or disagreements that are brought up.
• Individual estimate times are not discussed. These disagreements are
usually about the tasks themselves. Disagreements are often resolved by
adding assumptions.
The estimators all revise their individual estimates. The moderator
updates the plot with the new total:
*
24
Software Project Management
The Wideband Delphi Process
*
Step 4: Estimation Session (continued):
The moderator leads the team through several rounds of
estimates to gain consensus on the estimates. The estimation
session continues until the estimates converge or the team is
unwilling to revise estimates.
Step 5: Assemble Tasks
The project manager works with the team to collect the estimates
from the team members at the end of the meeting and compiles
the final task list, estimates and assumptions.
Step 6: Review Results
The project manager reviews the final task list with the
estimation team.
25
Software Project Management
Other Estimation Techniques
*
PROBE, or Proxy Based Estimating
PROBE is based on the idea that if an engineer is building a component similar
to one he built previously, then it will take about the same effort as it did in the
past.
Individual engineers use a database to maintain a history of the effort they have
put into their past projects.
A formula based on linear regression is used to calculate the estimate for each
task from this history.
COCOMO II
In Constructive Cost Model, or COCOMO, projects are summarized using a set
of variables that must be provided as input for a model that is based on the
results of a large number of projects across the industry.
The output of the model is a set of size and effort estimates that can be
developed into a project schedule.
26
Software Project Management
Other Estimation Techniques
*
The Planning Game
The Planning Game is the software project planning method
from Extreme Programming (XP), a lightweight development
methodology developed by Kent Beck in the 1990s at Chrysler.
It is a full planning process that combines estimation with
identifying the scope of the project and the tasks required to
complete the software.
The Planning Game is highly iterative. The scope is established
by having Development and Business work together to
interactively write “user stories” written on index cards to
describe the scope. Each story is given an estimate of 1, 2 or 3
weeks. This process is repeated continuously throughout the
project.
27
Software Project Management
Actual versus estimated effort
*
28
Software Project Management
*
ACIC
ACIC Corporation is a multibillion-dollar financial institution. To
keep up with the times, several years ago it started slowly Web-
enabling its applications, and it wanted to start an on-line service for
opening and tracking accounts. Because Infosys had successfully
built some e-services for ACIC earlier in a project called Synergy
(name changed), ACIC employed Infosys to analyze the problem.
This work was executed in time and material (T&M) mode—that is,
the customer paid for the effort spent by Infosys in doing the
analysis. Based on the analysis output, Infosys made a successful
bid for the Web project, giving rise to the ACIC case study. The
project successfully released the new service in time, and the
software has been in operation without any problem.
29
Software Project Management
CASE STUDY: Effort Estimate of the ACIC Project
*
30
Software Project Management
Build Effort for the ACIC Project
*
31
Software Project Management
Estimated Effort for the ACIC Project
*
32
Software Project Management
Distribution of Effort by Iterations in the ACIC Project
*
33
Software Project Management
Case study
*
34