EEE492.17 Software Estimation Techniques

1
EEE492.17Software Estimation Techniques
Royal Military College of Canada Electrical and
Computer Engineering
RefHvV 7.1-2

• Dr. Terry Shepard
• shepard_at_rmc.ca
• 1-613-541-6000 ext. 6031

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
Wideband Delphi (group consensus technique)
Step 1 Step 2 Step 3 Step 4 Step 5 Step 6

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

11
Initial Estimate in SLOC
2000
0
1000
. . .
After multiple rounds, estimates tend to converge
Round 4 Estimate in SLOC
2000
0
1000
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
12
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.

13
An aside

• a simple rule of thumb

personal best size estimate
x 20
estimate
number of years of experience on similar projects
SWAG
14
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

15
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

16
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

17
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.

18
Summary
19
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
20
Next ClassEstimating Size Function Points
or What are we estimating anyway?
21
Questions?