Upload
esther-cannon
View
214
Download
0
Embed Size (px)
Citation preview
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 14/19/2003
Day 2, Part 2 Estimating Software Effort &
Cost Section 1 – Fundamental Issues
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 24/19/2003
Outline
• Measures of Effort• Inputs to the Effort Estimate• Effort Estimation Steps• Estimation based on Historical
Productivity• Wideband Delphi for Effort
Estimation• Bottom Up Estimating
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 34/19/2003
The Overall Planning Cycle
AnalyzeJob
Manage Risks
Execute
GenerateDetailed Plans
GenerateInitial Plans
Measure, Manage Productivity and Quality
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 44/19/2003
Detailed Planning - Processes
EstimateSize
EstimateEffort and
Cost
EstimateSchedule
Evaluate
Source InformationStatement of Work
RequirementsConstraintsStandardsProcesses
Historyetc.
WBS Size
Effort &
Cost
Schedule
OKCompleteDetailedPlanning
Revise &Negotiate
Not OK
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 54/19/2003
Measures of Effort
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 64/19/2003
Effort Is ...… the amount of labor required for the
project• It is typically measured in staff-
months, staff-days or staff-hours A month (or calendar-month) is a
measure of time A staff-month is a measure of effort
If three people complete a job in 1 calendar-month, it is a 1 calendar-month job that requires 3 staff-months of
effort
If three people complete a job in 1 calendar-month, it is a 1 calendar-month job that requires 3 staff-months of
effort
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 74/19/2003
Effort Is Not Defined Precisely
• There are no generally accepted, precise definitions for terms like staff-month or staff-day
• And people are known to “fudge” the definitions in their own favor
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 84/19/2003
Two Executives on the Golf Course
We do 50 LOC per staff month - you do only
40!
How do you measure staff
months?
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 94/19/2003
Staff-Hours, Staff-Days, or Staff-Months
• There are many ways to measure these• And these three are NOT necessarily
related in a simple manner• Because of this, comparisons can be
very misleading
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 104/19/2003
How Many Hours per Day?
• 1 staff-hour = 1 person working for 1 hour
• 1 staff-day = 1 person working for 1 day
• How many staff-hours per staff-day?– 7? 7.5? 8.0? 8.5? 9.5? ???– How do you handle paid overtime?– How do you handle unpaid overtime?– How do you handle breaks, lunch hours,
etc.?
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 114/19/2003
• How many productive staff-days per staff-month?– 30? 21? 19? ???– Does it depend on
which month?
The underlined value is the default assumed by many U.S. companies and
many estimating models (this value allows for average number of vacation days and
holidays in the U.S.)
The underlined value is the default assumed by many U.S. companies and
many estimating models (this value allows for average number of vacation days and
holidays in the U.S.)
How Many Days per Month?
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 124/19/2003
How Many Hours per Month?
144? 148? 152? 160? 175? 184? ???Factors that can affect this:
– Which month is it?– What is the length of the work day?– How do you handle overtime?– Vacations and holidays– Sick days– What country you are in?– How do you allocate management overhead
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 134/19/2003
Linesof code
per staff
month
Objects Tested
per staff hour
Consistency is the Most Important Factor
• If you measure effort consistently, you can understand what it costs, compare different projects, and predict future performance
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 144/19/2003
Consistency Allows Reasonable Comparisons With
Past History
• Like software size, there are many ways to measure effort and many arguments why each is good or bad
• You cannot make meaningful evaluations if each project measures effort differently
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 154/19/2003
Projects Often Hide Actual Effort Data
• You cannot tell what really happened on a previous project if you don’t know how they measured effort
How many
hours did you
really spend?
We don’t know - we
didn’t count unpaid
overtime
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 164/19/2003
• There tend to be fewer variations in how a staff-hour is measured
• But many organizations use staff-months -- so you need to know how to convert properly in your organization
Measure Hours if you Can
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 174/19/2003
The Relationship Between Time and Effort
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 184/19/2003
What Does a “Staff-month” Mean?
• If it requires 12 staff-months, does this mean– 12 people for 1 month? – 1 person for 12 months? – 3 people for 4 months?– does it depend on the people?
• Too often, scheduling and estimating tools make the assumption that all of these are equivalent
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 194/19/2003
vs
How Flexible is a Staff-Month?
• There is some flexibility, but only so much
• Brooks (see references: “The Mythical Man-Month”) explored this issue in considerable detail
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 204/19/2003
Cost of Adding More People
CC = (N * (N-1))/2Where ...N = Number of peopleCC = Communication
Complexity (extra overhead of managing N people)
Brooks’ Equation for Intercommunication Effort
0
20
40
60
80
100
120
1 3 5 7 9 11 13 15
People
Management
Overhead
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 214/19/2003
You Cannot Just AllocatePeople Arbitrarily
staff-days
required to do the
work
Calendar Time Allocated for the Work
Optimal Schedule
COCOMO MODEL OF TIME VS EFFORT
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 224/19/2003
The Optimal ScheduleDepends on Many Factors
• Process, people, nature of task, tools, management approach, environment, …
• Different cost estimating models make different assumptions about these matters and how they affect the results
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 234/19/2003
• Until we have a better theoretical foundation, the only way to determine the optimal is through experience
• The various estimating models represent the experience of their originators and thus may predict different “optimal” schedules
Your Experience Counts More Than Any Model
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 244/19/2003
Your Actual High Level Schedule May be Determined
by Other Factors• In early planning, your project’s
overall goals and milestones may define constraints
• Product deadlines may determine schedule dates
• Reviews may have to occur at times convenient to others– Customers– Managers
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 254/19/2003
Compare the Actual and the Optimal Schedule to Gauge
the Schedule Risk• If the optimal is significantly different
from the actual, you have schedule compression, which means a significant expectation of – increased cost, and – schedule risk
Optimal vs. actual schedule information may help you determine cost impact (see
“cost drivers,” later in this part)
Optimal vs. actual schedule information may help you determine cost impact (see
“cost drivers,” later in this part)
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 264/19/2003
Typical Inputs to the Effort Estimate
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 274/19/2003
Tasks to be Performed Are a Major Input to Effort Estimation• Typically these are found in the WBS
– Software development tasks (design, code, test)
– Additional development tasks (requirements, system integration)
– Support tasks (CM, QA, management)– Tasks requiring additional labor
(documents, audits, etc.)– Additional dollar costs (travel,
equipment, etc)
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 284/19/2003
Other Inputs to Effort Estimate
• Estimated software size • Historical data on effort & productivity• High level schedule• Process and methods• Programming language• Operating system for target system• Tools to be used• Staff experience level
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 294/19/2003
Effort Estimating Steps
1) Summarize and document the requirements for each task– Basis of estimate
– WBS dictionary
2) Quantify the magnitude of each task– Size & complexity for software
– # of pages, # of trips, # of whatever for other things
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 304/19/2003
Effort Estimating Steps
3) Estimate effort for software development tasks
4) Estimate again with an alternative method
5) Resolve discrepancies between the two methods (repeat from step 1, as required)
6) Add effort estimates for other tasks (such as support tasks)
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 314/19/2003
In Other Words ...
WBS
EstimateSize and
ThenEffort
Estimate Costs Directlyor as % of
Development Costs
Software Development Tasks
• requirements
• design• code• ...
Other Tasks and Costs
• management
• travel• training• overhead• facilities• equipment• software• …
Convertto$
TotalCost
Estimate
TotalCost
Estimate
Estimate Development Costs
Then Estimate Other Costs
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 324/19/2003
Notes for Effort Estimation• Accuracy of estimate depends on
– Experience – Historical data– Availability of information– & LUCK!
• At the start of a project, you are lucky to be within 20% unless you have very good historical data– It is not unusual to be 100% off
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 334/19/2003
Good History Data
Good historical data are essential for
accurate estimating.
Good historical data are essential for
accurate estimating.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 344/19/2003
Architecture of Spreadsheet
Model BasedEstimate
Other EffortEstimates ...
HistoricalSize Estimate
SoftwareReuse
Analysis
Size / Reuse Effort
Final EffortEstimate
ProductivityBased Effort
Estimate
Other SizeEstimates ...
Final SizeEstimate
DelphiSize Estimate
Schedules
Generic Schedule
Effort Schedule
0
5
10
15
20
25
M1 M2 M3 M4 M5 M6
Total
Build 1
Build 2
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 354/19/2003
Effort Estimation with Historical Productivity Data
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 364/19/2003
Effort Can Be Estimated From Size and Productivity
Effort = Size * Historical ProductivityExamples:
– Staff Days = Lines of Code*Staff Days/LOC– Staff Days = Modules*Staff Days/Module– Staff Days = Function Points*Staff Days/FP
Whatever unit you measure, if you have good historical data, this method can be
fast and effective
Whatever unit you measure, if you have good historical data, this method can be
fast and effective
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 374/19/2003
Typical values forProductivity Rates
• 2-15 LOC/day for high order languages• 3-25 LOC/day for assembly language• Lower values for constrained projects
– real time/ safety critical systems etc.
• Higher numbers for commercial applications with few constraints
• Even higher numbers can be achieved if you use 4GLs, high levels of reuse, etc.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 384/19/2003
Example
• In the past, we have had the following productivity:– 4 LOC/sd for complex software– 8 LOC/sd for simple software
• For the new “8000 LOC”, “complex” software, it should take
8000/4 = 2000 staff days
…But how accurate is this?
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 394/19/2003
Historical Data (Typical)
0
1
2
3
4
5
6
7
1998 1999 2000 2001 2002 2003 2004
History
Proposed
LOC Developed per Staff-day
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 404/19/2003
Historical Data are Seldom Precise or Consistent
Example:Effort for complex software varies from 2 to 6 LOC per staff day, with a mean of 4 LOC per staff dayThe expected effort for an 8000 SLOC program might be
• As low as 1334 staff days or ...• As high as 4000 staff days!
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 414/19/2003
In Other Words
• Historical Data usually gives a RANGE of values, not a precise estimate
Based on past experience,this project should take from
100 to 125 staff months
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 424/19/2003
Three Risk Management Approaches
• Use multiple estimating methods– They will help improve the bounds on
your estimate– Each new method will identify issues
that other methods overlook• Set aside a “reserve” amount based
on the level of risk in your estimate• Plan to update your estimates
– You will have better information in the future
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 434/19/2003
What Do Multiple Methods Tell You?
• They help you understand the degree of uncertainty and/or confidence in your estimate - so you can manage more effectively
• They force you to ask hard questions about what facts each method overlooks
• They help you learn
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 444/19/2003
Statistical Variances and Uncertainties
TrueCost?
Method 1
Method 3Method 2
Region of Likely Costs
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 454/19/2003
Beware of Averages
• Significant differences in estimates usually mean significant differences in assumptions or facts considered
• In such cases, averages may be meaningless
XXX XX X X
Average is MeaninglessAverage is Meaningless
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 464/19/2003
Wideband Delphi• Wideband Delphi can be
used to estimate effort as well as size– On small projects this is often
the most effective way to estimate effort
– Also useful for estimating other costs, such as
management overhead, tools,support functions etc.
I assume it will take 3 people for 2 months.
x xx x x
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 474/19/2003
Bottom Up Estimating
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 484/19/2003
Bottom Up Estimating• This method may take a lot of time• It may or may not be based on size
estimates• This method has several benefits
– Each part of the project is estimated by someone who knows that part well
– Individuals “buy in” to the estimate because it was based on their expertise
– It is easy to compare actual results with estimates and determine if and where you went wrong
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 494/19/2003
Bottom Up Estimating Process1) Break the software down into
components -- as detailed as you can– Break down until the individual parts
are small enough for an individual to develop in a short time (1 week to 1 month perhaps)
– If you do not know, make a reasonable estimate of how you could break each part of the software into smaller parts
2) Estimate each part3) Combine estimates
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 504/19/2003
Sample Breakdown
Database I/F
ErrorProcessor
Sort Module
Synchro-nizer
CommandProcessor
TableInterface
Joe Mary &
Jim
Bert &
Sally
Joe Bert Sally
ParserCode
GeneratorFile
SystemRun TimeSystem
UserInterface
ManageSoftware
Development
Build “C”Compiler
Build TestSuite
WriteDocumentation
WriteInstallationSoftware
Software for“C” Compiler
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 514/19/2003
Sample Estimate
6 SW6 SW 1 SW1 SW4 SW4 SW 5 SW5 SW3 SW3 SW 4 SW4 SW
Joe Mary &
Jim
Bert &
Sally
Joe Bert Sally
12 SW 28 SW23 SW 14 SW18 SW
18 SW95 SW 33 SW 12 SW 22 SW
180 SW
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 524/19/2003
For an Object Oriented DesignYou May Break it Up
Differently
Class“Query”
Subclass“User
Response”
Class“ErrorCode”
Class“Response”
Subclass“System
Response”
Subclass“Maintenance
Response”
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 534/19/2003
Day 2, Part 1Estimating Effort and Cost
Section 2 - Estimation as a Series of Schedules
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 544/19/2003
A Fundamental Issue in Estimation
• How do you “put it all together”?– Size – Effort– Cost– Schedule– Staffing levels
• How do you “keep it all together” as you revise and update the estimates?
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 554/19/2003
A General Process for Documenting & Updating
Estimates• The process to be described is a
framework for estimating• You can use any estimating
methods you choose• The process allocates estimated
effort and cost across a schedule• And by using a spreadsheet, you
can easily update all estimates
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 564/19/2003
Architecture of Spreadsheet
Model BasedEstimate
Other EffortEstimates ...
HistoricalSize Estimate
SoftwareReuse
Analysis
Size / Reuse Effort Schedules
Final EffortEstimate
ProductivityBased Effort
Estimate
Generic Schedule
Effort Schedule
Other SizeEstimates ...
Final SizeEstimate
DelphiSize Estimate
0
5
10
15
20
25
M1 M2 M3 M4 M5 M6
Total
Build 1
Build 2
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 574/19/2003
Some Features of This Estimating Process
• The process allows you to evaluate:– Staffing and shopload– Resource requirements (equipment,
people, money, …)– Cash flow
• It serves as a basis for managing– It provides initial estimates of many
quantities you will want to track against actuals during project execution
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 584/19/2003
Revised Effort Schedule
Top Level Schedule
Generic Schedule
Effort Schedule Effort
Cost Schedule Cost
S, SA
P
AL
WBS costcategories
AD
Initial Plannin
gProcess Model
Additional Labor
The Estimation Sequence
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 594/19/2003
Code Category Aff ects ExamplesS Sof tware
DevelopmentCost &
ScheduleSof tware Design, Sof twareCoding, Sof tware Testing
SA Additional Sof twareDevelopment
Cost &Schedule
Sof tware Requirements,System Testing
P Sof tware Support Cost Sof tware Management, SQA,Config Management
AL Additional Labor Cost Project Management,Document Generation
AD Additional Dollars Cost Travel, Development Tools,Special Equipment,
Cost Categories for WBS Tasks
Each category is used at a different point in the estimating process
Each category is used at a different point in the estimating process
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 604/19/2003
Revised Effort Schedule
Top Level Schedule
Generic Schedule
Effort Schedule
Cost Schedule
S, SA
P
AL
WBS costcategories
AD
Initial Planning
Process Model
The Estimation Sequence
EffortEstimate
Additional Labor
Cost
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 614/19/2003
The Generic Schedule is ...… a mapping of “the process” to the
top level schedule– It indicates what portion of the
schedule will be devoted to each phase of the process
… the schedule control mechanism for the estimating spreadsheet– If you change your schedule or your
process, you adjust the generic schedule and the rest of the schedules will automatically adjust
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 624/19/2003
The Generic Schedule Tells You ...
• Where you will perform each process phase, in relation to the overall project schedule
Phase Percentage Eff ortM1 M2 M3 M4 M5 M6 .
Rqmts 25% 25% 25% 15% 10%
P Des 15% 25% 30% 20% 10%
D Des etc etc
C&UT etc
I nteg.
REVIEWS SRR PDR
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 634/19/2003
Typical Generic Schedule forWaterfall Model Lifecycle
Phase M1 M2 M3 M4 M5 M6 … TOTRqmts 25% 25% 25% 15% 10% 100%
P Des 15% 30% 20% … 100%
D Des … 100%
C&UT … 100%
I nteg. … 100%
REVIEWS SRR PDR
Process Schedule
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 644/19/2003
Phase M1 M2 M3 M4 M5 M6 . TOTRqmts 25% 5% 5% 25% 5% 100%P Des 30% 5% 10% 20% 100%D Des 25% 10% etc 100%C&UT 5% 25% 5% 100%I nteg. 10% 20% 100%CYCLE 1 1 1 1 1/ 2 2 2
Typical Generic Schedule forIncremental Model Lifecycle
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 654/19/2003
Generic Schedule Notes• You can do a separate generic
schedule for each separate software item– And add them together to form a generic
schedule for the total software project– This method is recommended if their
processes or schedules are different
• Or you may combine all software items into one generic schedule– This method is recommended if their
processes and schedules are the same
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 664/19/2003
Revised Effort Schedule
Top Level Schedule
Generic Schedule
Effort Schedule
Cost Schedule
S, SA
P
AL
WBS costcategories
AD
Initial Planning
Process Model
The Estimation Sequence
EffortEstimate
Cost
Additional Labor
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 674/19/2003
The Effort Schedule is ...
… a mapping of the estimated effort to the process phases and the schedule– It indicates how much effort will be spent each
month on each phase of the process
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 684/19/2003
You Need to Partition Estimated Effort by PhasePhase of Process Percent of Adjusted
Base Eff ortRequirements 9.5%
Preliminary Design 14.3%
Detailed Design 23.8%
Coding & UnitTest 23.8%
I ntegration 28.6%
SA
SA
S
S
S
Cost Category
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 694/19/2003
The Effort Vector is Adjusted Base Effort Partitioned by Process Phase
Phase of Process Percent of Adj .Base Eff ort
Eff ort
Requirements 9.5% 200
Preliminary Design 14.3% 300
Detailed Design 23.8% 500
Coding & UnitTest 23.8% 500
I ntegration 28.6% 600
(Estimated) Adjusted Base Effort = 2100 staff-days
Effort Vector
SA
SA
S
S
S
Cost Category
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 704/19/2003
Effort Schedule Matrix Equation
Effort Schedule
Effort Vector
Generic Schedule
= *
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 714/19/2003
Typical Initial Effort SchedulePhase Eff ort M1 M2 M3 M4 M5 Mn TOTRqmts 200 50 50 50 30 20 0 200
P Des 300 0 0 0 45 90 etc 300
D Des 500 0 0 0 0 0 etc 500
C&UT 500 0 0 0 0 0 0 500
I nteg 600 0 0 0 0 0 0 600
SUB-TOTAL 2100 50 50 50 75 110 etc 2100
Sub-total = Adjusted Base Effort
(S tasks plus SA tasks)
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 724/19/2003
To Produce the Effort Schedule
• Multiply each cell in the Generic Schedule by the effort to be spent on the corresponding phase of the process (from the effort vector)
• The result is the corresponding cell in the Effort Schedule
• An example is found in the spreadsheet supplied with the course materials
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 734/19/2003
Support (“P”) Tasks Must be Added On, Usually Based on a
Flat Percentage• Example:
– Support tasks will add about 300 staff-days of effort, which is 1/7 (14.3%) of the estimated effort
– So we add 14.3% to each number in the sub-total line as “add-ons”
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 744/19/2003
Typical Final Effort Schedule(Total Effort)
Phase Eff ort M1 M2 M3 M4 M5 Mn TOTRqmts 200 50 50 50 30 20 0 200
P Des 300 0 0 0 45 90 etc 300
D Des 500 0 0 0 0 0 etc 500
C&UT 500 0 0 0 0 0 0 500
I nteg 600 0 0 0 0 0 0 600
SUB-TOTAL 2100 50 50 50 75 110 etc 2100
ADD-ONS 300 7 7 7 11 16 etc 300
TOTALEFFORT
2400 57 57 57 86 126 etc 2400
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 754/19/2003
The Effort Schedule Tells You ...
… how much total effort will be expended each month, for basic software development & support
… what will be going on each month in terms of process phases
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 764/19/2003
How Many People?
• Head count (number of people) can be calculated by dividing the total effort by the availability (effort available per person per month)– This tells you how many people you will
need each month• Example: if there are 57 staff-days
of effort required and each person works 19 days per month, then you need:
57/19 = 3 people.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 774/19/2003
Head CountPhase Eff ort M1 M2 M3 M4 M5 Mn TOTRqmts 200 50 50 50 30 20 0 200
P Des 300 0 0 0 45 90 etc 300
D Des 500 0 0 0 0 0 etc 500
C&UT 500 0 0 0 0 0 0 500
I nteg 600 0 0 0 0 0 0 600
SUB-TOTAL 2100 50 50 50 75 110 etc 2100
ADD-ONS 300 7 7 7 11 16 etc 300
TOTALEFFORT
2400 57 57 57 86 126 etc 2400
Head Count 3.0 3.0 3.0 4.5 6.6
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 784/19/2003
The Head Count Tells You About Additional Risks
• Unrealistic staff growth• Grossly uneven staffing needs
0
20
40
60
80
100
Start Month
1
Month
2
Month
3
Month
4
Month
5
Month
6
Total Staff
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 794/19/2003
Typical Head Count Graph
0
2
4
6
8
M1 M2 M3 M4 M5 M6 M7 M8
Planned
Data taken directly from effort schedule
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 804/19/2003
You Can Track ActualsDuring Execution
0
2
4
6
8
M1 M2 M3 M4 M5 M6 M7 M8
Planned Actual
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 814/19/2003
Revised Effort Schedule
Top Level Schedule
Generic Schedule
Effort Schedule
Cost Schedule
S, SA
P
AL
WBS costcategories
AD
Initial Planning
Process Model
The Estimation Sequence
EffortEstimate
Cost
Additional Labor
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 824/19/2003
The Revised Effort Schedule ...• Incorporates labor for tasks beyond
basic software development– Special audits– Validation steps– Special documents to be produced– Tasks beyond the usual process
• It is prepared by adding a row to the effort schedule that shows additional labor, and then a grand total row
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 834/19/2003
Revised Effort SchedulePhase Eff ort M1 M2 M3 M4 M5 Mn TOT… … … … … … … … …
SUB-TOTAL 2100 50 50 50 75 90 etc 2100
ADD-ONS 300 7 7 7 11 13 etc 300
Total Eff ort 2400 57 57 57 86 126 etc 2400
AdditionalLabor
300 19 19
Grand TotalEff ort
2700 57 57 76 105 126 …
Head Count 3.0 3.0 4.0 5.4 6.6 126
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 844/19/2003
Revised Effort Schedule
Top Level Schedule
Generic Schedule
Effort Schedule
Cost Schedule
S, SA
P
AL
WBS costcategories
AD
Initial Planning
Process Model
The Estimation Sequence
EffortEstimate
Cost
Additional Labor
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 854/19/2003
The Cost Schedule is ...
… three rows added to the effort schedule1 Effort converted to dollars (*)2 Additional money required (for travel,
equipment, and other non-labor costs)3 Grand Total cost (#1 + #2)
… the cells indicate dollars rather than effort
(*) Multiply “Grand Total Effort” cells by average cost per labor hour
(*) Multiply “Grand Total Effort” cells by average cost per labor hour
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 864/19/2003
Cost SchedulePhase Eff ort M1 M2 M3 M4 M5 Mn TOT Grand Total Eff ort
2700 57 57 76 105 126
Dollars $280K 6K 6K 8K 11K 13K … …
Additional Dollars
$150K 88K
22K 14K
Grand Total Cost
$430K 94K
6K 30K 25K 13K …
Head Count 3.0 3.0 4.0 5.4 6.6 126
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 874/19/2003
The Cost Schedule Indicates
• How much money will be spent each month
• And it incorporates money for costs not measured in units of labor (e.g., travel)
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 884/19/2003
A Typical Cost Schedule
0
1
2
3
4
5
6
M2 M3 M4 M5 Ms
Month
K$
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 894/19/2003
The Cost Schedule HasMany Uses
• Cost of the project• How much money you need each
month• Inflation can be adjusted for longer
projects• Interest information may be
incorporated if money must be borrowed
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 904/19/2003
Revised Effort Schedule
Top Level Schedule
Generic Schedule
Effort Schedule Effort
Cost Schedule Cost
S, SA
P
AL
WBS costcategories
AD
Initial Planning
Process Model
Additional Labor
The Estimation Sequence
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 914/19/2003
Architecture of Spreadsheet
Model BasedEstimate
Other EffortEstimates ...
HistoricalSize Estimate
SoftwareReuse
Analysis
Final EffortEstimate
ProductivityBased Effort
Estimate
Other SizeEstimates ...
Final SizeEstimate
DelphiSize Estimate
Size / Reuse Effort Schedules
Generic Schedule
Effort Schedule
0
5
10
15
20
25
M1 M2 M3 M4 M5 M6
Total
Build 1
Build 2
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 924/19/2003
Day 2, Part 1Estimating Effort and Cost
Section 3 - Estimation Models & Negotiation
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 934/19/2003
Outline
• Developing an estimation model• Calibrating and validating a model• Cost drivers• The Cocomo model• Other estimation models • Bottom-up estimating• Estimating cost• Negotiating
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 944/19/2003
Architecture of Spreadsheet
Model BasedEstimate
Other EffortEstimates ...
HistoricalSize Estimate
SoftwareReuse
Analysis
Final EffortEstimate
ProductivityBased Effort
Estimate
Other SizeEstimates ...
Final SizeEstimate
DelphiSize Estimate
Size / Reuse Effort Schedules
Generic Schedule
Effort Schedule
0
5
10
15
20
25
M1 M2 M3 M4 M5 M6
Total
Build 1
Build 2
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 954/19/2003
Effort Estimating Models ...
… help us predict effort and cost, given many facts about the software
(The principal facts are the estimated size and complexity of the software)
These are similar to the size models we discussed before, in general concept
These are similar to the size models we discussed before, in general concept
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 964/19/2003
Developing an Estimation Model
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 974/19/2003
An Effort Estimation Model is ...
… an algorithm or equation or set of equations that produces an estimate of the effort, given inputs that describe the software to be written
EstimationModel
Description of
Software
Estimate of
Effort
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 984/19/2003
A Very Simple Model
Examples:– Staff Days = Lines of Code*Staff Days/LOC– Staff Days = Modules*Staff Days/Module– Staff Days = Function Points*Staff Days/FP
The first estimation method is, in fact, a very simple estimating model
The first estimation method is, in fact, a very simple estimating model
Effort = Size * Productivity
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 994/19/2003
A Graph of the Model
Effort
Size
Effort = Size * Constant
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1004/19/2003
But We Know That ...
• Effort usually grows faster as size increases due to management overhead and other such factors
• So the graph ought to curve up rather than being a straight line
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1014/19/2003
Perhaps Something like This
Size
Effort
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1024/19/2003
One Model That ProducesSuch a Curve
a and b are constants that depend on the software development organization and the type of software
Size
Effort
Effort = a * Size b
Many organizations find that their software effort fits this model for effort as a function of software
size
Many organizations find that their software effort fits this model for effort as a function of software
size
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1034/19/2003
“b” Is Called the“Economy of Scale” Factor
• On most software projects, especially large ones, we observe a diseconomy of scale (b > 1) because of the additional communication and management overhead of larger projects (as shown on previous slides)
• This causes the curve to turn up
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1044/19/2003
Economy of Scale Is Possible
• We could see economy of scale (b<1), especially on small projects, such as:– when fixed start-up costs are amortized
as size increases– or when something about the nature of
the approach allows you to be more productive for larger software projects
• See next slide for an illustration
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1054/19/2003
Economy of Scale(b < 1)
Size
Effort
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1064/19/2003
How to Determine the Curve
• By observing organizational experience over a period of time, you can – collect enough data to determine
whether this curve fits your data, and– calculate typical values of a and b
• One such model is called “Cocomo”– we will discuss Cocomo in subsequent
slides
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1074/19/2003
Does This Apply to My Project?
• Some argue that models like this only make sense for large projects using traditional software development methods
While such models are more commonly used for large projects and traditional software development methods, there are many principles applicable to small
projects and to newer development methods
While such models are more commonly used for large projects and traditional software development methods, there are many principles applicable to small
projects and to newer development methods
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1084/19/2003
Basic Cocomo Model
• Size is in thousands of lines of code
• Effort is in staff months, assuming 19 staff days per staff month
Effort = 3 * Size 1.12
This is the least detailed version of the Cocomo model. It is often used for making sanity checks on results of estimates from
other methods
This is the least detailed version of the Cocomo model. It is often used for making sanity checks on results of estimates from
other methods
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1094/19/2003
How to Use on Your Projects
• Basic Cocomo was derived from a set of about 50 projects at TRW corporation from the late 1970’s
• To use this on your projects, you could estimate with the Basic Cocomo model, compare that with actual results or past experience, and adjust to more accurately reflect your experience.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1104/19/2003
Calibration
• Over time, you would calibrate your experience on projects to the equation and determine the values of “a” and “b” that fit your data the best.
• For example, your version of the model might turn out to be:
Effort = 2.7 * Size 1.24
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1114/19/2003
Cocomo II Extension• In Cocomo II, the latest version of the
model, the exponent, b, can be estimated based on a series of “scale drivers” which address such factors as:– experience with similar projects– flexibility of development process– maturity of design approach– team cohesion– process maturity (on SEI CMM scale)
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1124/19/2003
Calibrating & Validating a Model
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1134/19/2003
Validation ...
… is the process of evaluating or proving that the model accurately predicts what you want it to predict– Does your data typically fit the curve?– Is this the right curve?– What was the basis for the equation(s)
used in the model?• What assumptions were made?• What type of application is intended?
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1144/19/2003
For Example, the Cocomo Model...
• Is calibrated from relatively large programs (more than 10,000 lines of code)
• Assumes a relatively formal development process based on the waterfall lifecycle
• Was derived from about 50 programs developed by TRW corporation in the late 1970’s
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1154/19/2003
Validating Suitability of a Model
• Look at data from your programs– Does the data tend to fit the same kind
of curve?
• Compare your assumptions with those of the model– If the assumptions do not match, you
may need to investigate further to see if the model still fits
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1164/19/2003
Calibration ...… is the process of adjusting the key
constants or other model factors so the results tend to approximate your data– For example, a and b in Cocomo
… usually accomplished by statistical methods such as regression analysis
Often you need to calibrate differently for different kinds of software or different application
types
Often you need to calibrate differently for different kinds of software or different application
types
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1174/19/2003
Calibrating a Model
Estimating
Model
Your Data
Your Experien
ce
Your
Model
Your Insigh
t
adjust
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1184/19/2003
Cost Drivers
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1194/19/2003
Nominal Effort
• When we apply a model, the “nominal” effort is the effort predicted by the model under typical or nominal circumstances– Nothing unusual or out of the ordinary– Something we know how to do
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1204/19/2003
But Not All Projects Are Typical
• It is very common to have factors that make the effort for a particular project higher or lower than normal– Experience of staff– Complexity of products– Strength of tools
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1214/19/2003
Factors that Affect Effort
• Such factors influence the effort estimate & hence cost -- and thus are termed “Cost Drivers”
• Cost drivers are often included as parameters to effort estimating models
• We will examine the cost drivers used in more advanced versions of Cocomo– Similar drivers are used in other models
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1224/19/2003
Cost Drivers - I The Nature of the Job to be
Done1) Required Reliability
– Applies mainly to real time applications
2) Data Base Size– Applies mainly to data processing apps
3) Product Complexity
4) Execution Time Constraints– When processor speed is barely sufficient
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1234/19/2003
Cost Drivers - I (continued)
5) Main Storage Constraints– Applies when memory size is barely
sufficient
6) Target Machine Volatility– Includes hardware and operating system
7) Development Machine Volatility– Unstable OS, compilers, CASE tools, etc.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1244/19/2003
Cost Drivers - II The Practices & Tools
1) Modern Programming Practices– Structured Analysis or OO
2) Modern Programming Tools– e.g., CASE tools, good debuggers, test
generation tools
3) Schedule Compression (or expansion)– Note -- deviation from ideal can never
help, but shorter is worse than longer
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1254/19/2003
Cost Drivers - III The People Who Will Do It
1) Analyst Capability
2) Application Experience
3) Programmer Capability
4) Virtual Machine Experience– Includes operating system and hardware
5) Programming Language Experience– Includes tools and practices
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1264/19/2003
Cost Drivers - IV Additional Drivers Often Used
1) Requirements volatility– A little change in requirements is
expected, but too much can have a strong effect on project cost
2) Security requirements
3) Access to data– Sometimes very difficult
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1274/19/2003
Cost Drivers - IV(continued)
4) Impact of standards and imposed methods
5) Impact of physical surroundings
6) A need to design software to be reusable
7 …) You can add whatever others make sense in your situation
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1284/19/2003
Example of Applying aCost Driver
• You need to train the new people• You need to allow them time to gain
experience or “get up to speed” (this is known as “climbing the learning curve”)
• They will be less productive than experienced people would be on the same job
“Nominal” estimate with experienced staff is 60 staff-weeks (3 people, 20 weeks)
Suppose we have an inexperienced staff -- what can we estimate?
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1294/19/2003
How You Might Factor In This Cost Driver
With inexperienced people, you plan:• A training period - 1 week per person or
3 staff-weeks total• Lower productivity - 66.7% of normal effort
(estimate based on your experience)• Thus estimate for effort is 60/66.7% = 90
staff-weeks + 3 staff-weeks of training= 93 staff-weeks total (3 people, 31
weeks)
“Nominal” estimate with experienced staff is 60 staff-weeks (3 people, 20 weeks)
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1304/19/2003
How Do You Handle Multiple Cost Drivers?
• Some cost drivers have a multiplicative effect on effort
• For such cases, you can define an effort multiplier for each cost driver
• For example, if high complexity tends to make effort about 12% higher, than you can define a “high complexity” effort multiplier of 1.12
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1314/19/2003
Effort Multipliers
•Determine an effort multiplier for each cost driver–multiplier = 1 means the driver does not apply–multiplier > 1 means the driver increases cost–multiplier < 1 means the driver decreases cost
Effort = Nominal * Product of All Multipliers
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1324/19/2003
Applying Multiple Cost Drivers
Table of Effort Multipliers
Driver Normal High VeryHigh
Complexity 1.0 1.15 1.30
Reliability 1.0 1.15 1.40
Experience 1.0 .91 .82
etc. etc. etc. etc.
Suppose:
• Nominal is 200 staff months
• Complexity is very high
• Staff experience is high
Then:
Estimated effort = 200 * 1.30 * .91
= 236.6
The table represents your organization’s collective experience of the impact of
various factors or cost drivers.
The table represents your organization’s collective experience of the impact of
various factors or cost drivers.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1334/19/2003
Intermediate Cocomo1
Where where EAF = E1*E2*...*En
Eis are effort multipliers corresponding to a set of common cost drivers. – The nominal value of each Ei = 1.
– Ei = 1 implies the cost driver does not apply
– Ei > 1 implies increased cost
– Ei < 1 implies decreased cost
Effort = EAF * a * Size b
1) This model is often known as Cocomo 811) This model is often known as Cocomo 81
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1344/19/2003
Effort Multipliers• Typical values range between 0.6 &
1.5• Preset values are established for
each factor• All Cocomo multipliers together can
affect cost and schedule estimates by 10 times or more!
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1354/19/2003
Typical Table ofEffort Multipliers
Value Low Nominal High Very High
Extremely High
Complexity .85 1.0 1.15 1.30 1.65
Language Experience
1.07 1.0 .95 .86
…
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1364/19/2003
EAFEffort Adjustment Factor
• EAF is the product of the effort multipliers
• A value of 1 would represent a relatively easy software effort, perhaps with no cost drivers
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1374/19/2003
EAFEffort Adjustment Factor
(continued)
• A value of 1 - 1.5 is typical today for a commercial software effort
• A value of 1.5 - 2.0 is typical today for a real-time effort or a government project
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1384/19/2003
EAF Has ImprovedOver the Years
• The values typically reported by software projects were once a lot larger (in the 3-4 range), but due to improvements in practices and processes, they have gotten a lot better.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1394/19/2003
Intermediate Cocomo - “a” & “b”
The “mode” is the
general type of
software
The “mode” is the
general type of
software
Effort = EAF * a * Size b
Mode a b
Organic 3.2 1.05
Semi-Detached
3.0 1.12
Embedded 2.8 1.20
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1404/19/2003
Cocomo Software Types (Modes)
Organic – Fairly easy software– software development team is familiar
with application, language, and tools.– Typically from 2-50 KLOC
Semi-Detached– Average software, average team– Typically 50-300 KLOC
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1414/19/2003
Cocomo Software Types (Modes) (continued)
Embedded – Severe constraints, real time, etc.– No stated size range, but model is
known to fail under 10KLOC
NOTE: the origin of the names is obscure, and not considered
significant, even by Barry Boehm, who invented Cocomo.
NOTE: the origin of the names is obscure, and not considered
significant, even by Barry Boehm, who invented Cocomo.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1424/19/2003
Cocomo II Extension
• In Cocomo II, there are formulas based on characteristics of the application that allow you to estimate the “a” and “b” values more precisely.
• But the best way is always to calibrate to your own data
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1434/19/2003
Cocomo Tool Information
CoCo ProAvailable through ICONIX Software
Engineering Inc.
For more information on CoCoPro:
HTTP://WWW.ICONIXSW.COM/Spec_Sheets/CoCoPro.html
For more information on CoCoPro:
HTTP://WWW.ICONIXSW.COM/Spec_Sheets/CoCoPro.html
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1444/19/2003
Cocomo Tool Information (continued)
REVIC - A free toolAvailable through USAF Cost Analysis
AgencySOFTEST - an updated version
For more information on REVIC or SOFTEST:
http://sepo.nosc.mil/estimation.html
For more information on REVIC or SOFTEST:
http://sepo.nosc.mil/estimation.html
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1454/19/2003
Cocomo Tool Information (continued)
• SOFTCOST-R• Available through Resource
Calculations Inc.
For more information on SOFTCOST-R:
http://www.softstarsystems.com
For more information on SOFTCOST-R:
http://www.softstarsystems.com
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1464/19/2003
Additional Cocomo II Information
Under development at University of Southern California, Cocomo II project.
For More Information on Cocomo II:HTTP://SUNSET.USC.EDU/
research/COCOMOII/index.html
For More Information on Cocomo II:HTTP://SUNSET.USC.EDU/
research/COCOMOII/index.html
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1474/19/2003
Architecture of Spreadsheet
Model BasedEstimate
Other EffortEstimates ...
HistoricalSize Estimate
SoftwareReuse
Analysis
Size / Reuse Effort Schedules
Final EffortEstimate
ProductivityBased Effort
Estimate
Generic Schedule
Effort Schedule
Other SizeEstimates ...
Final SizeEstimate
DelphiSize Estimate
0
5
10
15
20
25
M1 M2 M3 M4 M5 M6
Total
Build 1
Build 2
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1484/19/2003
Other Estimation Models
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1494/19/2003
• Cocomo only accounts for the main tasks of software development.
• It also includes certain amounts of management, CM, and QA
• In Cocomo II, the latter amounts are larger than in older versions
SystemAnalysis
SoftwareRequirements
SystemInt &Test
SoftwareDesign
SoftwareCode
SoftwareInt &Test
<---- Cocomo Includes ---->
Tasks Included in Cocomo
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1504/19/2003
• Cocomo does not include– System level tasks– Software requirements definition and analysis– System integration and test
• Including software support of this activity
– Management above the software project level
SystemAnalysis
SoftwareRequirements
SystemInt &Test
SoftwareDesign
SoftwareCode
SoftwareInt &Test
<---- Cocomo Includes ---->
Tasks Excluded From Cocomo
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1514/19/2003
Other Popular Cost/Schedule Estimation Models
• Putnam’s Model -- (SLIM)
• Shen and Conti -- (COPMO)
• Lockheed/Martin -- (Price-S)
• Galorath, Inc -- (SEER-SEM)
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1524/19/2003
SLIM (1)
Size is measured in lines of code (or can be thousands if Ck is adjusted)
Effort is measured in staff-years
Ck is a “state of technology” constant, reflecting use of modern practices, team experience, and software development tools. Compare with Cocomo adjustment factors.
t is the development time, in years.(1) Putnam, IEEE Trans. on SW Engineering, July, 1978.
Size = Ck*Effort1/3*t4/3
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1534/19/2003
SLIM Information
• EFFORT is for entire life cycle, including maintenance
• Development Effort = .39 * EFFORT, according to Putnam
For more information on SLIM:
HTTP://WWW.QSM.COM
For more information on SLIM:
HTTP://WWW.QSM.COM
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1544/19/2003
Copmo (1)
Effort = Programming Effort + Coordination Effort
The values of the constants a, b, c, and d must determined by regression analysis on actual project data
The important issue here is the impact of staff size on management/coordination effort
(1) Conte, S.D., et. al. Software Engineering Metrics and Models.
Effort = a + b*Size + c*(Staff)d
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1554/19/2003
Price-S• This is a very complex, proprietary
model, based on extensive analysis of many kinds of software projects
• The parameters are similar to Cocomo’s adjustment factors, but can be very sensitive
• For example, experience level of personnel can affect estimates by 5 times or more
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1564/19/2003
Price-S Additional Information
Now supplied by PRICE Systems, a Martin-Lockheed Company
The product is called the PRICE S Software Estimating Suite
For more information on PRICE-S:
HTTP://WWW.PRICESYSTEMS.COM
For more information on PRICE-S:
HTTP://WWW.PRICESYSTEMS.COM
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1574/19/2003
SEER-SEM• This is a proprietary model, sold by
Galorath, Inc., based on analysis of many kinds of software projects
• The model also has elements for size estimation and project management
• For example, one can use SEER tools to track progress and risks
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1584/19/2003
SEER-SEM Additional Information
Galorath, IncorporatedEl Segundo, California310-414-3222
For more information on SEER-SEM:
HTTP://www.galorath.com/
For more information on SEER-SEM:
HTTP://www.galorath.com/
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1594/19/2003
Software Maintenance Estimating
• Usually this is done in a “bottom up” manner, such as:– Estimated number of changes *
average cost per changeor– Level of effort (“n” people per year for
“m” years -- total cost = n*m)
• Sometimes it is done on a “cost per transaction” basis
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1604/19/2003
Don’t Treat Maintenance as Reuse
• Generally speaking, maintenance affects only a small portion of the software
• If you model the unchanged part as “reused” you will get much too large a number for the estimated effort
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1614/19/2003
Process, Methods, and Tools
Tools
COSTAR, REVICSLIM
SOFTCOSTMethods (Models)
COCOMO,PUTNAM,ET. AL.
Process (Purpose)
EFFORT ESTIMATING
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1624/19/2003
Architecture of Spreadsheet
Model BasedEstimate
Other EffortEstimates ...
HistoricalSize Estimate
SoftwareReuse
Analysis
Size / Reuse Effort Schedules
Final EffortEstimate
ProductivityBased Effort
Estimate
Generic Schedule
Effort Schedule
Other SizeEstimates ...
Final SizeEstimate
DelphiSize Estimate
0
5
10
15
20
25
M1 M2 M3 M4 M5 M6
Total
Build 1
Build 2
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1634/19/2003
Compare Results and Judge
Method Productivity Cocomo Bottom Up
Final Estimate
Eff ort 376 402 358 360
Productivity 1.1 .9 1.2 1.2
Schedule 12.8 14.2 12 12
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1644/19/2003
An Issue with Effort Estimating Methods based on
Size• How can you know the size before
you have designed the software -- and maybe before you even know its requirements?
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1654/19/2003
Dealing with Uncertain Size Estimates
• Generally speaking, you can predict better after design than you can before it
• So re-estimation is a MUST for effective risk management
• Methods not based on size, such as wideband delphi or “bottom up” effort estimating, should be considered to supplement size-dependent methods
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1664/19/2003
Grady, Robert B. and Deborah L. Caswell, Software Metrics: Establishing a Company-Wide Program.
An Issue with AllEffort Estimating Methods
• You can manipulate the method to get any answer you want– Grady and Caswell report that typical
estimates are 20-25% optimistic, even for experienced estimators
– So you need to record your results, learn from your mistakes, and do better the next time
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1674/19/2003
You Need to Track ………………
Actuals vs. Estimates
0
20
40
60
80
100
120
140
1 2 3 4 5 6 7 8 9 10
Estimate
Actual
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1684/19/2003
You Need to Track and Adjust
Actuals vs. Estimates
0
20
40
60
80
100
120
140
1 2 3 4 5 6 7 8 9 10
Estimate
Actual
Revised Estimate
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1694/19/2003
Use Several Methods
• At the very least, using several methods will increase your chances of being close to the right answer
X X X
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1704/19/2003
Remember the Goals of Estimating
• Knowledge and insight are the real benefits of using different methods
• Comparing the results of several methods will force you to resolve the discrepancies – This forces you to think about the
issues
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1714/19/2003
Estimating Cost
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1724/19/2003
There are Many CostsOther Than Software
Development
WBS
EstimateSize and
ThenEffort
Estimate Costs Directlyor as % of
Development Costs
Software Development Tasks
• requirements
• design• code• ...
Other Tasks and Costs
• management
• travel• training• overhead• facilities• equipment• software• …
Convertto$
TotalCost
Estimate
TotalCost
Estimate
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1734/19/2003
Turning Effort into Cost
• Turning effort estimates into cost estimates depends on many factors that depend on your specific company– Overhead rates– Cost of borrowing money– Methods of calculating profit margin– Allocations of management and support
expenses– Costs of capital equipment– etc.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1744/19/2003
One Way to Convert Effort to $
Category % of Total Salary Rate#
Requirements 10% $65/hourDesign 10% $50/hourCode 30% $40/hourTest 30% $30/hourOther 5% $15/houretc. etc.
# use rate per hour if effort is measured in staff-hours use rate per day if effort is measured in staff-days etc.
# use rate per hour if effort is measured in staff-hours use rate per day if effort is measured in staff-days etc.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1754/19/2003
Multiply the Effort by the Percentages to get the Labor
Distribution and $10,000 hours:
1000 hours - requirements x $65 = $65,000
1000 hours - design x $50 = $50,000
3000 hours - code x $40 = $120,000
3000 hours - test x $30 = $90,000
etc.
Total: $xxx,xxx
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1764/19/2003
A Note About theSalary Rate Chart
• Be sure to correlate the percentages with the “experience level” factors assumed in your effort estimate
>> It is tempting to cut costs estimates by boosting the percentage of lower cost staff -- check what this does to the cost drivers first!!! <<
>> It is tempting to cut costs estimates by boosting the percentage of lower cost staff -- check what this does to the cost drivers first!!! <<
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1774/19/2003
Negotiation
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1784/19/2003
Detailed Planning - Processes
EstimateSize
EstimateEffort and
Cost
EstimateSchedule
Evaluate
Source InformationStatement of Work
RequirementsConstraintsStandardsProcesses
Historyetc.
WBS Size
Effort &Cost
Schedule
OKCompleteDetailedPlanning
Revise &Negotiate
Not OK
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1794/19/2003
If the Plan is Not Feasible
• DO examine assumptions and data– initial cost estimates are often very
conservative
• Do examine risk/cost tradeoffs to see if you can accept a higher risk
• Do make a list of barriers that must be removed in order to make the estimate fit the constraints
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1804/19/2003
“The quickest way to make a project uneconomical is by doubling the resources needed and using the cover story that you need to prevent failures.”
Adams, The Dilbert Principle
“The quickest way to make a project uneconomical is by doubling the resources needed and using the cover story that you need to prevent failures.”
Adams, The Dilbert Principle
If the Plan is Not Feasible
• DO NOT “cave in” & lower everything to meet a target cost or schedule
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1814/19/2003
The Negotiation Process
We MUST havethe lowest bid!!!
We will, boss!!!
Management will try to trim the budget by sending an army of low-ranking, clueless budget analysts to interview you and ask “insightful” questions. Adams, The Dilbert Principle
Management will try to trim the budget by sending an army of low-ranking, clueless budget analysts to interview you and ask “insightful” questions. Adams, The Dilbert Principle
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1824/19/2003
Re-think key factors
Spreadsheet for estimating
This will never satisfy the cost
goal!???!
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1834/19/2003
Identify Opportunities and Barriers
Barriers
Opportunities to Cut
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1844/19/2003
Negotiate
If they will cut back on the reviews
and ...
Well, I’ll think about
it
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1854/19/2003
Beware ... Estimates are Never
Perfect
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1864/19/2003
Estimating Accuracy vs. Phase
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
Feasibility Plans Design DetailedDesign
CodeandTest
Release
Upper LimitActual
Lower Limit
• Typical Estimates
• • • • • • •
•
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1874/19/2003
Some Opportunities to Consider
• Plan to re-estimate after important milestones
• Prioritize requirements and promise to deliver the top ones by the deadline – Incremental deliveries
• Put a high cost on requirements changes
• Look at each “adjustment factor” in Cocomo as an opportunity
• Get training for everyone
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1884/19/2003
Some Typical Barriers to Faster Schedule or Lower Cost• Lack of adequate resources
– Software, tools, people, etc.• Slow approval cycles for required
resources• Poor coordination with other
disciplines, other companies, etc.• Customers, peers in other disciplines,
and managers who don’t understand software development very well
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1894/19/2003
Some Difficult Barriers to Faster Schedule or Lower Cost
• Irascible and irrational customers & managers
• Intentional barriers– Competitors, etc
– Political constraints
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1904/19/2003
Negotiating Tip . . .
• The more facts you have, the better off you are during negotiation
• Get decision makers to review your estimate – Sometimes they don’t bother
• Be well prepared to explain it
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1914/19/2003
Detailed Planning - Processes
EstimateSize
EstimateEffort and
Cost
EstimateSchedule
Evaluate
Source InformationStatement of Work
RequirementsConstraintsStandardsProcesses
Historyetc.
WBS Size
Effort &Cost
Schedule
OKCompleteDetailedPlanning
Revise &Negotiate
Not OK
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1924/19/2003
Several Iterations are Likely• That’s why you should use a spreadsheet or
an estimation tool!• Identify the factors that affect the cost and
schedule– Experience levels, stability levels, etc.
• Examine sensitivity of the results to various factors
• Examine historical data to make a better picture of probable events
• Don’t put too much faith in the accuracy of models
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1934/19/2003
SummaryEffort & Cost Estimation
(continued)• Effort can be measured in many ways
– The specific measurement can have a significant effect on the numbers computed during an estimate
• Effort and Schedule Length are interdependent– Time and effort can be traded off to
some extent, but not completely - there are “infeasible” combinations
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1944/19/2003
• Effort estimates can be made through historical experience or through models derived from historical experience
• Beware of averages• Cost is derived through several steps• The estimating process shown enables
you to tie it all together and make updates
Summary Effort & Cost Estimation
(continued)
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1954/19/2003
• Models are often helpful to estimate effort– All are based on historical experience– All should be calibrated to your specific
experience– And validated to be sure that they are
right for your application– Most have additional parameters that
allow you to “fine tune” to your specifics
SummaryEffort & Cost Estimation
(continued)
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1964/19/2003
• Cocomo is a widely used method that is fairly successful when calibrated to your experience
• Like most models, Cocomo covers only some of the tasks of software development
• It is best to use multiple models/ methods to improve the quality of an estimate
SummaryEffort & Cost Estimation
(concluded)
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1974/19/2003
1. Boehm, “Software Engineering Economics”, Prentice-Hall, 1981.
2. Boehm, et. al., Cost Models for Future Software Life Cycle Processes: Cocomo 2.0, Technical Report, USC Center for Software Engineering, Draft 2.0, September 6, 1994.
3. Brooks, Fred, “The Mythical Man-Month”, 1975 / 1995.
4. Conte, S.D., et. al. Software Engineering Metrics and Models. Benjamin Cummings, 1986, p314.
ReferencesEffort & Cost Estimation
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1984/19/2003
4. Grady, Robert B. and Deborah L. Caswell, Software Metrics: Establishing a Company-Wide Program. Englewood Cliffs, N.J., Prentice-Hall, Inc., 1987.
5. Putnam, Lawrence H., “A General Empirical Solution to the Macro Software Sizing and Estimating Problem,” IEEE Transactions on Software Engineering, July, 1978, p345.
6. Tausworthe, R.C. Software Specifications Document, DSN Software Cost Model, Jet Propulsion Laboratory, JPL Publication 81-7 (1981).
ReferencesEffort & Cost Estimation
(continued)
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, Page 1994/19/2003
SoftwareDevelopment
Plan
Execute
Measure
EngineerQuality