Software Cost and Schedule Estimation - PowerPoint by veteranlives

VIEWS: 150 PAGES: 26

									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 MM 2000 SLOC 5 8000 SLOC 21 8 32000 SLOC 91 14 128000 SLOC 392 24

Schedule 5 Months Staff 1.1

2.7 376

6.5 352

16 327

SLOC/ MM

400

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!


								
To top