Size Estimation EEE493 2000

1
Size Estimation EEE493 2000
Royal Military College of Canada Electrical and
Computer Engineering

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

Dr. Scott Knight knight-s_at_rmc.ca 1-613-541-6000
ext. 6190
2
Refs

• 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
• Capers Jones, What are Function Points,
  www.spr.com/library/0funcmet.htm

3
Review

• What are the project variables available for us
  to manipulate?
• What is a work breakdown structure?

4
Project variables
5
The Work Breakdown Structure

• framework for relating product structure and
  software process
• traditionally structured around modules
• but can be structured by tasks instead
• as many layers as necessary typically lt6

System
Sub-system
Sub-system
Sub-system
Mod.
Mod.
Mod.
Mod.
Mod.
Mod.
Mod.
Mod.
Mod.
6
Estimating methods

• Expert Judgement
• Algorithmic Models
• Analogy
• Parkinson
• Price to Win
• Top-Down
• Bottom-Up

7
Algorithmic Models

• Algorithmic models provide one or more
  mathematical algorithms which produce an estimate
  a 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.

8
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)

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

10
Delphi a group consensus technique

• To eliminate the bias of a single expert - obtain
  the estimates from more than one expert
• How do we combine them to form a single estimate?
• mean
• median
• group meeting

11
Delphi

• Avoids the drawbacks of group meetings
• strong personalities
• political considerations

12
Delphi

• Steps
• Coordinator presents each expert with a
  specification and a form upon which to record
  estimates, and the rationale behind the estimate.
• Experts fill out forms anonymously. They may ask
  questions of the coordinator, but should not
  discuss the situation with each other.
• Coordinator prepares a summary of the experts
  responses on a form requesting another iteration
  of the experts estimate.
• Experts fill out forms, again anonymously, and
  the process is iterated for as many rounds as
  appropriate.
• No group discussion is to take place during the
  entire process.

13
Delphi Experiment

• Rand Corp.
• Actual development 489 person-months
• 4 groups
• 2 Delphi
• 2 half day group meeting

14
Delphi Experiment
15
Delphi weakness

• The written feedback in the standard Delphi
  technique does not provide a sufficiently broad
  communications path for participant to exchange
  the volume of information necessary to calibrate
  their estimates with those of other participants.

16
Wideband Delphi

• Steps
• Coordinator presents each expert with a
  specification and a form upon which to record
  estimates, NO rationale behind the estimate
  required.
• Coordinator calls a group meeting in which the
  experts discuss estimation issues with
  coordinator and each other.
• Experts fill out forms anonymously.
• Coordinator prepares a summary of the experts
  responses on a form requesting another iteration
  of the experts estimate.
• Coordinator calls a group meeting, specifically
  focusing on having the experts discuss points
  where their estimates varied widely.
• Experts fill out forms, again anonymously, and
  the process is iterated for as many rounds as
  appropriate.

17
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

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

19
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 margine
  of extra time and money to continue to add
  marginally useful bells and whistles
• reinforces poor software development practice

20
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
• not enough resources and usually leads to
  complete disaster

21
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

22
Bottom-up Estimating

• The cost of each software component is estimated
  by an individual the costs are then summed
  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.
23
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.

24
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?

25
Next ClassFunction Point Analysis