Lesson 3: Estimation
Software Project Management
02:58:18 AM 1
Software Project Management
Review
02:58:18 AM
stakeholder
Project manager
team of software engineers
Business analysts or requirements analysts
◦ Designers and architects
◦ Programmers
◦ Testers
2
Software Project Management
02:58:18 AM
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?
02:58:18 AM
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
02:58:18 AM
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
02:58:18 AM
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
02:58:18 AM
7
Software Project Management
Work Breakdown Structure
02:58:18 AM
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
02:58:18 AM
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
02:58:18 AM
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
Different Techniques
02:58:18 AM
1. Bottom-up: activity based, analytical
2. Top-down: ‘price to win’, Agile
3. Expert judgement: experience
4. Analogy: case-based, comparative
5. Algorithmic & Parametric models:
COCOMO, function points
11
Software Project Management
1. Bottom-up estimating
1. Break project into smaller and smaller
components
2. Stop when you get to what one person
can do in two/one/half week
3. Estimate costs for the lowest level
activities
4. At each higher level calculate estimate
by adding estimates for lower levels
Software Project Management
2. Top-down estimates
2a. Price To Win
Estimate
overall Produce overall
100 days estimate using effort
project
driver(s)
distribute proportions
of overall estimate to
design code test
components
30% 30% 40%
i.e. i.e. i.e. 40 days
30 30 days
days
13
Software Project Management
2b. Agile estimation
Incremental development
Break big project into smaller sections
Time boxes
Develop in time boxes = a FIXED amount of time
• For example 1 month
Produce working software at end of time box
Prioritisation
Prioritise tasks at beginning of time box
Start with high priority tasks
Deliver as much as you can within the time box
Jobs that can’t be finished go into the next time box
Software Project Management
3. Expert judgement
Asking someone who is familiar with and
knowledgeable about the application area and
the technologies to provide an estimate
Particularly appropriate where existing code is to
be modified
Research shows that experts judgement in
practice tends to be based on analogy
Software Project Management
4. Estimating by analogy
Use effort
source cases
from source as
estimate
attribute values effort
attribute values effort target case
attribute values effort attribute values ?????
attribute values effort
attribute values effort
attribute values effort Select case
with closest attribute
values
Software Project Management
5. Algorithmic/Parametric models
COCOMO (lines of code) and function
points are examples of these
Problem with COCOMO
guess algorithm estimate
but what is desired is
system algorithm estimate
characteristic
Software Project Management
Lines of Code - LOC
Standard measure of software size
Will vary according to programming language
Higher level languages produce less LOC (but it
takes longer to produce each LOC)
Exactly what do you count? Executable code,
declarations, commentary, blank lines?
May have more than one statement on a line
Software Project Management
Function Points
Language independent
Complexity factors chosen subjectively
Different people have different notions of complexity – estimates
can vary
Some authors argue that useful in practice
Can use to estimate LOC (tables)
Code size = AVC x no. function points
(AVC is a language-dependent factor varying from 200-300 for
assembly language to 2-40 for a 4GL)
Software Project Management
Algorithmic Cost Modelling
Systematic approach to estimation
Many different models – developed from empirical studies of
projects
Effort = A x SizeB x M
A is constant (type of software, org etc)
Size is code size or functionality
B is exponential – costs increase with size
M is multiplier (dependent on process, product, development
attributes etc)
Software Project Management
Effort in IT projects
Effort is the total number of time units (e.g. weeks or
months) needed to complete the task.
This may break down to effort from more than one
person, so as to take advantage of certain skills and
do jobs in parallel
However:
the more people one adds to a project the more one needs
to work so as to coordinate them and the more they
communicate so as to interact successfully, thus yielding
overheads.
Software Project Management
Effort Estimation Models
02:58:18 AM
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.
22
Software Project Management
02:58:18 AM
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.
23
Software Project Management
The Bottom-up Estimation Approach
02:58:18 AM
24
Software Project Management
02:58:18 AM
Top-Down Estimation
25
Software Project Management
Wideband Delphi
02:58:18 AM
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
26
Software Project Management
The Wideband Delphi Process
02:58:18 AM
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.
27
Software Project Management
The Wideband Delphi Process
02:58:18 AM
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.
28
Software Project Management
The Wideband Delphi Process
02:58:18 AM
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.
29
Software Project Management
The Wideband Delphi Process
02:58:18 AM
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.
30
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:
31 02:58:18 AM
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:
02:58:18 AM
32
Software Project Management
The Wideband Delphi Process
02:58:18 AM
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.
33
Software Project Management
Other Estimation Techniques
02:58:18 AM
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.
34
Software Project Management
Other Estimation Techniques
02:58:18 AM
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.
35
Software Project Management
Actual versus estimated effort
02:58:18 AM
36
Software Project Management
02:58:18 AM
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.
37
Software Project Management
CASE STUDY: Effort Estimate of the ACIC Project
02:58:18 AM
38
Software Project Management
Build Effort for the ACIC Project
02:58:18 AM
39
Software Project Management
Estimated Effort for the ACIC Project
02:58:18 AM
40
Software Project Management
Distribution of Effort by Iterations in the ACIC Project
02:58:18 AM
41
Software Project Management
Case study
02:58:18 AM
42
