EE493'08 Estimating Software Projects

1
EE493.08Estimating Software Projects
ReferencesHvV 7.1-2
Royal Military College of Canada Electrical and
Computer Engineering

• Professor Greg Phillips
• Greg.Phillips_at_rmc.ca
• 1-613-541-6000 ext. 6656

Major JW Paul Jeff.Paul_at_rmc.ca 1-613-541-6000
ext. 6091
2
A carelessly planned project will take three
times longer to complete than expected
A carefully planned project will take only twice
as long
3
Review

• How does planning relate to estimating?

4
Review

• Which type of project is easier to estimate?

5
Estimating Methods

• How do you estimate?

6
Parkinsonian Estimation

• Parkinsons Law
• Work expands to fill the available volume
• It must be done in 18 months, and there are 10
  people available to work on it, so the job will
  take roughly 180 person-months.
• Weakness
• grossly inaccurate
• only really works when estimate leaves a margin
  of extra time and money to continue to add
  marginally useful bells and whistles
• reinforces poor software development practice

7
Price-to-Win Estimation

• Estimate
• the price believed needed to win the contract
• the schedule believed to win the contract
• Why
• lack of trust/understanding in legitimate
  estimates
• once you have the contract...
• Weakness
• politically motivated and usually leads to
  complete disaster

8
Estimation by Analogy

• Comparing this project to other similar completed
  projects
• can be done at the system or subsystem
• Strength
• estimate is based on actual experience
• Weakness
• Not always clear to what degree the previous
  project is representative of the constraints,
  techniques, personnel, etc. of the new project

9
Expert Judgement

• Consulting one or more experts
• Strengths
• expert is able to factor in differences between
  projects
• expert can consider exceptional conditions
• Weakness
• only as good as the estimator
• estimator is subject to personal motivators
• requires experience what do you do on the first
  project?

10
An aside

• a simple rule of thumb

personal best size estimate
x 20
estimate
number of years of experience on similar projects
SWAG
11
Wideband Delphi (group consensus technique)

• step 1 - have firm requirements for function and
  quality
• step 2 - produce a candidate design in enough
  detail that each individual design element is
  comprehensible.
• step 3 - each estimator produces a size estimate
  for each design element and submits them to a
  moderator
• step 4 - for each design element the moderator
  produces an unlabeled distribution plot
• step 5 - without revealing their estimates, the
  estimators explain the rationale behind them.
• step 6 - steps 3 through 5 are repeated until the
  estimate satisfactorily converges

12
Wideband Delphi
Initial Estimate in SLOC
2000
0
1000
Round 4 Estimate in SLOC
2000
0
1000
13
Wideband Delphi - results

• the estimates do tend to converge
• the converged value is typically better than the
  mean or median of the first round estimates, and
  more accurate than the best estimates of the best
  individual first round estimators

14
Algorithmic Models
Estimate f(x1, x2,... xn )

• use one or more mathematical algorithms based on
  variables which are considered to be major cost
  drivers
• lines of source code
• programmer capability
• schedule constraints
• execution time constraints
• etc.

15
Algorithmic Models

• Strengths
• objective
• no influence of personal motivators
• repeatable
• sensitivity analysis possible
• Weakness
• must be calibrated (does the new project match
  the old data?)
• difficult to handle exceptional conditions
  (exceptional personnel,
  exceptional teamwork)
• still a lack of quantitative data

16
Two Methodologies
An overall cost estimate for the project is
derived from the global properties of the
software product

• Top Down

The cost of each software component is estimated
by an individual the costs are then summed to
derive an overall cost

• Bottom Up

17
Top-down Estimating

• Strengths
• system level focus (based on experience with
  entire completed projects)
• will not miss the costs of system integration,
  developing users manuals, configuration
  management, project management, etc.
• Weakness
• may not identify low level technical problems
• may miss components (miss-identify scope)
• no detailed cost justification

18
Bottom-up Estimating

• Strengths
• earlier understanding of low level technical
  problems
• component estimates will be backed up by personal
  commitment of the individual responsible for the
  job
• detailed cost justification (other analysis is
  possible)
• Weakness
• tends to miss system level costs (these must be
  included in the work breakdown structure)
• hard to estimate system level costs until
  component costs are estimated
• hard to model incidental project activities
• reading, reviewing, meeting, fixing, etc.
• hard to model incidental non-project activities
• training, personal business, non-project
  communications, etc.

19
Summary
20
Review

• Why Estimate
• To aid in planning
• Name Some Estimating Methods
• Parkinson
• Price to Win
• Analogy
• Expert Judgement
• Experience-based estimate
• Wideband Delphi-method
• Algorithmic Models

not recommended
21
Next ClassEstimating Size Function Points
or What are we estimating anyway?
22
Questions?