Estimating Software Projects EEE493 2001 References:HvV 7'12

1
Estimating Software Projects EEE493 2001
ReferencesHvV 7.1-2
Royal Military College of Canada Electrical and
Computer Engineering

• Major Greg Phillips
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

Major Ron Smith smith-r_at_rmc.ca 1-613-541-6000
ext. 6030
2
Estimating methods

• Parkinson
• Price to Win
• Expert Judgement
• Experience-based estimate
• Wideband Delphi-method
• Analogy
• Algorithmic Models
• Top-Down
• Bottom-Up

not recommended
3
Parkinsonian Estimation

• Parkinsons LawWork expands to fill the
  available volume
• E.g. 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

4
Price-to-Win Estimation

• Estimate the price believed necessary to win the
  contract.
• Estimate the schedule believed necessary to win
  the contract.
• People still do this because there is little
  understanding of, or trust in, legitimate
  estimates.
• Weakness
• politically motivated and usually leads to
  complete disaster

5
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 (so what does the manager do
  for their first project?)

6
Experience-based Size Estimation

• a simple rule of thumb

actual size personal best size estimate 20
number of years of experience
on similar projects
WAG
7
Wideband Delphi (a 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

2000
0
1000
design element 7 estimated size in SLOC, round 1
8
Wideband Delphi

• 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
• Based upon experience
• the estimates do 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

2000
0
1000
design element 7 estimated size in SLOC, round 4
9
Estimation by Analogy

• Reasoning by analogy with one or more completed
  projects to relate their actual costs to an
  estimate of a similar but new project.
• How does this project differ - quantify this.
• Can be done at the system level or at the
  subsystem level

10
Estimation by Analogy

• Strength
• estimate is based on actual experience
• Can be done at the system level or at the
  subsystem level
• Weakness
• Not always clear to what degree the previous
  project is representative of the constraints,
  techniques, personnel, etc. of the new project.

11
Algorithmic Models

• Algorithmic models provide one or more
  mathematical algorithms which produce an estimate
  of a function of a number of variables considered
  to be major cost drivers. ?(x1, x2,... xn)
• Cost Drivers
• lines of source code
• programmer capability
• schedule constraints
• execution time constraints
• etc.

12
Algorithmic Models

• Strength
• 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)
• after all these years and software projects,
  there is still a lack of quantitative data

13
Top-down Estimating

• An overall cost estimate for the project is
  derived from the global properties of the
  software product.
• Strength
• 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

14
Bottom-up Estimating

• The cost of each software component is estimated
  by an individual the costs are then summed to
  derive an overall cost
• May use work breakdown structure

System
Sub-system
Sub-system
Sub-system
Mod.
Mod.
Mod.
Mod.
Mod.
Mod.
Mod.
Mod.
Mod.
15
Bottom-up Estimating

• Strength
• 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.

16
What is a Good Unit of Measure?

• Consider lines of deliverable source code - LOC
• ProductivityGoods or services produced per
  unit of labour and expense
• Does moving to a higher-order language compiler
  increase productivity?

17
Supplemental References

• Boehm, W.B., The Art of Software Estimation,
  Prentice-Hall, 1981
• University of West Florida, Generic Delphi
  Estimation Process, http//www.cs.uwf.edu/wilde/g
  ump/delphi.htm

18
Next ClassEstimating Size - Function Points