Software Cost and Schedule
Estimation
Dr. Harry R. Erwin
University of Sunderland
<http://osiris.sunderland.ac.uk/~cs0her/>
<mailto:harry.erwin@sunderland.ac.uk>
The Problems
• Predicting software cost
• Predicting software schedule
• Controlling software risk
Criteria for a Good Model
•
•
•
•
•
•
•
•
•
•
Defined—clear what is estimated
Accurate
Objective—avoids subjective factors
Results understandable
Detailed
Stable—second order relationships
Right Scope
Easy to Use
Causal—future data not required
Parsimonious—everything present is important
Early Models
•
•
•
•
•
•
•
•
•
1965 SDC Model
Putnam SLIM Model
Doty Model
RCA PRICE S Model
IBM-FSD Model
1977 Boeing Model
1979 GRC Model
Bailey-Basili Meta-Model
CoCoMo
1965 SDC Model (Nelson 1966)
• A linear regression of 104 attributes of 169
early software projects
• Produces a MM estimate
• Mean of 40 MM
• Standard deviation of 62 MM
• Counterintuitive—too much non-linearity in
real program development
Putnam SLIM Model (Putnam
1978)
• Commercially available
• Popular with the US Government
• Uses a Rayleigh distribution of project
personnel level against time
• DSI = C*(MM) (1/3) *(Schedule) (4/3)
• Radical trade-off relationships
Doty Model (Herd et al., 1977)
• Extended the SDC Model
• MM = C(special factors)*(DSI) 1.047
• Problems with stability
RCA PRICE S Model (FreimanPark, 1979)
• Commercially available
• Aerospace applications
• Similar to CoCoMo (see below)
IBM-FSD Model (Walston-Felix,
1977)
• Not fully described
• Used by IBM to estimate programs
• Some statistical concerns
1977 Boeing Model (Black et al.,
1977)
• Similar to CoCoMo, but simpler
• Out of use
• Poor estimates
1979 GRC Model (CarriereThibodeau, 1979)
• Limited information available
• Obvious typos and mistakes
Bailey-Basili Meta-Model (BaileyBasili, 1981)
• Rigorous statistical analysis of factors and size.
• Not much experience
CoCoMo
• Waterfall Model
• Can be adapted to other models
• Estimates:
–
–
–
–
–
–
–
–
Requirements analysis
Product design
Programming
Test planning
Verification and validation
Project office
CM and QA
Documentation
Where to Find CoCoMo
• http://sunset.usc.edu/index.html
• Or do a Google search on Barry Boehm.
Nature of Estimates
• Man Months (or Person Months), defined as
152 man-hours of direct-charged labor
• Schedule in months (requirements complete to
acceptance)
• Well-managed program
Input Data
• Delivered source instructions (DSI)
• Various scale factors:
–
–
–
–
–
Experience
Process maturity
Required reliability
Complexity
Developmental constraints
Basic Effort Model
• MM = 2.4(KDSI)1.05
– More complex models reflecting the factors listed
on the previous slide and phases of the program
– The exponent of 1.05 reflects management overhead
Basic Schedule Model
#include <iostream>
#include <cmath>
using namespace std; //introduces namespace std
int main()
{
cout << "This is COCOMO Calc" << endl << endl;
double old,newer,mm;
for(;;) {
cout << "Enter the manmonths estimated for the task. Enter 0 to quit" << endl;
cin>>mm;
if(mm<=0.0)break;
cout<<endl<<"The following are 10/50/90 percentile estimates:"<<endl;
old = pow(mm,0.32);
newer = pow(mm,0.28);
cout<<"Old COCOMO: "<<2.0*old<<'\t'<<2.5*old<<'\t'<<3.0*old<<endl;
cout<<"New COCOMO: "<<0.8*3.67*newer<<'\t'<<3.67*newer<<'\t'<<1.2*3.67*newer<<endl;
}
return 0;
}
Productivity Levels
• Tends to be constant for a given programming
shop developing a specific product.
• ~100 SLOC/MM for life-critical code
• ~320 SLOC/MM for US Government quality
code
• ~1000 SLOC/MM for commercial code
Nominal Project Profiles
Size
2000
SLOC
5
8000
SLOC
21
32000
SLOC
91
128000
SLOC
392
Schedule
Months
Staff
5
8
14
24
1.1
2.7
6.5
16
SLOC/
MM
400
376
352
327
MM
What About Function Points?
• Can also be used to estimate productivity.
• Capers Jones (use Google to find) provides
conversion factors between FPs and SLOC.
<http://www.spr.com/>
• The development organization needs previous
experience with the problem domain to estimate
FPs accurately. SLOC are easier to estimate
with no experience.
More Sophisticated Modeling
Incorporates:
•
•
•
•
•
Development Modes
Activity Distribution
Product Level Estimates
Component Level Estimates
Cost Drivers
Risk Analysis
• A risk is a vulnerability that is actually likely to happen
and will result in some significant effect
• Standard software development risks:
– Cost
– Schedule (covaries with cost)
– Technical (opposes cost)
• Approach:
– Identify them
– Track them
– Spend money to control them (Spiral Model)
Spiral Model
• Defines early development activities to buy
down risk
• Maintains the interest of stakeholders
• Takes longer and costs more
• Ends with a standard Waterfall
Effects of Parallelism
• Without parallelism, you do a critical path
analysis.
• With parallelism, statistical factors affect which
task completes first.
• With several parallel tasks of equal length, the
mean schedule is about one standard deviation
beyond that length.
• Use Monte Carlo to study this.
Conclusions
• Experience shows that seat-of-the-pants estimates of cost and
schedule are only about 75% of the actuals. This amount of
error is enough to get a manager fired in many companies.
• Lack of hands-on experience is associated with massive cost
overruns.
• Technical risks are associated with massive cost overruns.
• Do your estimates carefully!
• Keep them up-to-date!
• Manage to them!