Transcript Estimation
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