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