CSE Senior Design I
Your Plan: Estimation
Instructor: Vassilis Athitsos
This presentation was derived from the textbook used for this class, McConnell,
Steve, Rapid Development, Chapter 8, further expanded on by Mr. Tom Rethard
for this course, and further modified by Mr. Mike O'Dell and Vassilis Athitsos.
1
Estimations and Scheduling
Discussion: Case Study 8.1 (pp. 163-165)
 Has this ever happened to you (work/school)?
 What was the underlying problem?
 What should Carl have done?
Estimating the job by:
 Seat of the pants, or
 A proven, rational process?
2
1 Overview
The Software-Estimation Story (Synopsis)
Estimation-Process Overview
Size Estimation
Effort Estimation
Schedule Estimation
Ballpark Schedule Estimates
Estimate Refinement
3
1 The Software Estimation Story*
 Software/System development, and thus
estimation, is a process of gradual
refinement.
 Can you build a 3-bedroom house for
$100,000? (Answer: It depends!)
 Some organizations want cost estimates to
within ± 10% before they’ll fund work on
requirements definition. (Is this possible?)
 Present your estimate as a range instead of a
“single point in time” estimate.
 The tendency of most developers is to underestimate and over-commit!
* Copyright 2007, The DSW Group Ltd.
4
1 Estimate-Convergence Graph
Project Cost
(effort and size)
Project
Schedule
1.6
4
2
1.25
1.5
1.15
1.25
1.0
0.8
1.1
1.0
0.9
0.67
0.85
0.5
0.8
0.25
Initial
product
definition
Approved Requirements Architecture
Detailed
product
specification
design
design
definition
specification specification
0.6
Product
complete
5
1 Estimation vs. Control
Initially desired
feature set
Features
Resources
Initially available
resources
Evolution of Project
(fixed resources)
Initially desired
feature set
Features
Product
Size/Features
Product
Size/Features
 Initially, customers want more than they
can afford, something’s gotta give…
Resources
Initially available
resources
Evolution of Project
(fixed requirements)
 Developers and customers must choose between
estimation accuracy and project control.
6
1 Cooperation, Refinement
 Explain to stakeholders that you will have
better estimates at each project milestone.
 You can’t estimate what you don’t know.
Estimate
Convergence
Estimate too low:
costs higher due
to planning
inefficiencies and
mistakes
Actual
Schedule
Estimate too high:
costs higher due
to Parkinson’s law
Minimum actual
schedule
Actual schedule = Estimated Schedule
Estimated Schedule
7
1 Estimation-Process Overview
Step 1: Estimate the size of the product
(lines of code or function points)
Step 2: Estimate the effort
(man-months)
Step 3: Estimate the schedule
(calendar months)
Step 4 (Meta-Step): Provide estimates in ranges
and periodically (frequently) refine the
ranges to provide increasing precision as
the project progresses
8
1 Size Estimation
Use an algorithmic approach, that
estimates a program’s size from its
features
Use size-estimation software
Compare to similar projects in your
organization, by pieces.
Software programs and algorithmic
approaches should be calibrated to your
environment.
9
1 Estimation tips
Avoid off-the-cuff estimates
Allow time for the estimate (do it right!)
Use data from previous projects
Use developer-based estimates
Estimate by walk-through
Estimate by categories
Estimate at a low-level of detail
Don’t forget/omit common tasks
Use software estimation tools
Use several different techniques, and compare the
results
 Evolve estimation practices as the project progresses










10
1 Function-Point Estimation
Based on number of
 Inputs
(screens, dialogs, controls, messages)
 Outputs
(screens, reports, graphs, messages)
 Inquiries
(I/O resulting in a simple, immediate output)
 Logical internal files
(Major logical groups of end-user data, controlled by
program)
 External interface files
(Files controlled by other programs that this program
uses. Includes logical data that enters/leaves
program)
11
1 Function-Point Multipliers
Program
Characteristic
Number of inputs
Number of outputs
Inquiries
Logical internal files
External interface files
Low
Complexity
3
4
3
7
5
Function Points
Medium
Complexity
4
5
4
 10
7
High
Complexity
6
7
6
 15
 10
Sum these to get an “unadjusted function-point total”
Multiply this by an “influence multiplier” (0.65 to 1.35),
based on 14 factors from data communication to ease of
installation.
All of this gives a total function-point count.
Use this with Jones’ First-Order Estimation Practice, or
compare to previous projects for an estimate
12
1 Jones First-Order Estimate:
Influence Multipliers
General System
Characteristic
Brief Description
2.
How many communication facilities are there to aid in the transfer or exchange of
information with the application or system?
Distributed data processing How are distributed data and processing functions handled?
3.
Performance
4.
Heavily used configuration
5.
Transaction rate
Was response time or throughput required by the user?
How heavily used is the current hardware platform where the application will be
executed?
How frequently are transactions executed daily, weekly, monthly, etc.?
6.
On-Line data entry
What percentage of the information is entered On-Line?
7.
End-user efficiency
Was the application designed for end-user efficiency?
8.
On-Line update
How many ILF’s are updated by On-Line transaction?
9.
Complex processing
Does the application have extensive logical or mathematical processing?
10.
Reusability
Was the application developed to meet one or many user’s needs?
11.
Installation ease
How difficult is conversion and installation?
12.
Operational ease
13.
Multiple sites
14.
Facilitate change
How effective and/or automated are start-up, back-up, and recovery procedures?
Was the application specifically designed, developed, and supported to be installed at
multiple sites for multiple organizations?
Was the application specifically designed, developed, and supported to facilitate
change?
1.
Data communications
13
1 Effort Estimation
Use estimation software to create an
effort estimate directly from size
estimate
Use McConnell’s schedule tables (Tables 88 through 8-10)
Use your organization's historical data
Use algorithmic approach (COCOMO,
Putnam)
14
1 Schedule Estimation
 Rule-of-thumb equation
 schedule in months = 3.0 * man-months 1/3
This equation implies an optimal team size.
 Use estimation software to compute the schedule
from your size and effort estimates
 Use historical data from your organization
 Use McConnell’s Tables 8-8 through 8-10 to look up
a schedule estimate based on the size estimate
 Use the schedule estimation step from one of the
algorithmic approaches (e.g., COCOMO) to get a
more fine tunes estimate than the “Rule of thumb”
equation.
15
1 Jones’ First-Order Estimation
Kind of Software
Systems
Business
Shrink-wrap
Organization’s Skills/Abilities
Best in Class
Average
Worst in Class
0.43
0.45
0.48
0.41
0.43
0.46
0.39
0.42
0.45
Take the function-point total and raise it to the appropriate power.
Example:
350 function points
average shrink-wrap development organization
3500.42  12 calendar months
This method works well for quick reality checks. (No magic!)
16
1 Ballpark Schedule Estimates
 Usable, concrete information is either:
 embedded in expensive software-estimation systems
 in books with dozens of equations and multipliers
 McConnell’s tables describe
 systems software
 business software
 shrink-wrap software
 Size in lines of code
 Accuracy of McConnell’s tables… better than
seat of the pants, but should be validated.
17
1 Shortest Possible Schedule
Table 8.8
Probability of
Completing
Exactly on the
Scheduled Date
High Risk of late
completion.
Shortest
possible
schedule
Scheduled Completion Date
Impossible schedule
• This tables assumes:
-
Top 10% of talent pool, all motivated, no turnover
entire staff starts working on Day 1, & continue until project released
advanced tools available to everyone
most time-efficient development methods used
requirements completely known, and do not change
18
1 Efficient Schedules (Table 8-9)
 This table assumes:





Top 25% of talent pool
Turnover < 6% per year
No significant personnel conflicts
Using efficient development practices from Chap 1-5
Note that less effort required on efficient schedule
tables
 For most projects, the efficient schedules represent
“best-case”
19
1 Nominal Schedules (Table 8-10)
 This table assumes:





Top 50% of talent pool
Turnover 10-12% per year
Risk-management less than ideal
Office environment only adequate
Sporadic use of efficient development practices
 Achieving nominal schedule may be a 50/50 bet.
20
1 Estimate Presentation Styles
 Plus-or-minus qualifiers
“6 months, +3 months, -2
months”
 Ranges
“5-9 months”
 Risk quantification
 Cases
Best case
Planned case
Current case
Worst case
April 1
May 15
May 30
July 15
 Coarse dates and time
periods
“6 months...
+1 month for late
“3rd quarter 97”
subcontractor,
+0.5 month for staff sickness,  Confidence factors
etc...”
April 1
5%
May 15
50%
July 1
95%
21
1 Schedule Estimation - Example
 Software Project Size and Productivity Approach
Low Side
High Side
(Aggressive)
(Conservative)
Size Estimate
Productivity
Effort
Duration
(5 person team)
10000 LOC
30000 LOC
400 LOC/PM
200 LOC/PM
25 PM
150 PM
5 months
30 months
 McConnell Table 8-10 (p. 196), Nominal Schedule, System Product
Duration
10 months
16 months
22
1 Schedule Estimation - Example
 Rule of Thumb (Duration = 3 x PM1/3)
Low Side
(Aggressive)
3 x 251/3 =
8.8 (9) months
Duration
High Side
(Conservative)
3 x 1501/3 =
15.9 (16) months
 Function Points, with Jones’s First Order Schedule Estimation (Medium
complexity project – Table 8-2)
# FnPts
Use Influence Multiplier of 1.2
Inputs
10
40
Outputs
5
25
Inquiries
10
40
Logical Int. Files
30
30
Assuming Nominal Skills, System
Product, Jones’s First Order says:
Logical Ext. Files
2
14
Duration = 180.45 = 10.35 months
Therefore:
1.2 x 149  180 adjusted fn points
149 (unadj.)
23
1 Schedule Estimation - Example
 Basic CoCoMo Estimation Coefficients, based on project
type/complexity:
Coefficient
a
b
c
d
Organic
2.4
1.05
2.5
0.38
Semi-detached
3.0
1.12
2.5
0.35
Embedded
3.6
1.20
2.5
0.32
 CoCoMo – nominal, semi-detached
Low Side
(Aggressive)
High Side
(Conservative)
Effort - PM
E = a(SLOC)b
E = 3.0(10)1.12
= 68.45 PM
E = 3.0(30)1.12
= 135.36 PM
Duration – months
D = c(E)d
E = 2.5(69).35
= 11 months
E = 2.5(136).35
= 14 months
24
1 Schedule Estimation - Example
 Comparing
Size and Productivity
McConnell Tables
Rule of Thumb
CoCoMo
Function Points/Jones’s
Aggressive
Conservative
5 months
30 months
10 months
16 months
9 months
16 months
11 months
14 months
10.35 months
 Sanity Test (Weiss & Wysocki, 1992)
E = (O + 4M + P) / 6, where O = optimistic, M = Nominal, P = Pessimistic
Therefore, our E = (5 + 44 + 30) / 6 = 79/6 = 13.17 (14) months
25
1 Estimate Refinement
Estimate can be refined only with a more
refined definition of the software
product
Developers often let themselves get
trapped by a “single-point” estimate, and
are held to it (Case study 1-1)
 Impression of a slip over budget is created
when the estimate increases
When estimate ranges decrease as the
project progresses, customer confidence
is built-up.
26
1 Recommendations
 Do not depend on a single cost or schedule
estimate.
 Use several estimating techniques or cost
models, compare the results, and determine the
reasons for any large variations.
 Document the assumptions made when making the
estimates.
 Monitor the project to detect when assumptions
that turn out to be wrong jeopardize the
accuracy of the estimate.
 Maintain a historical database
28
1 Conclusions
 Estimate accuracy is directly proportional to
product definition.
 Before requirements specification, product is very
vaguely defined
 More effort, variety of approaches/methods
used in estimating = better estimates.
 Use ranges for estimates and gradually refine
(tighten) them as the project progresses.
 Measure progress and compare to your historical
data
 Refine… Refine… Refine!!!
29