Software Cost and Schedule Estimation Dr. Harry R. Erwin University of Sunderland

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) Problems with stability

RCA PRICE S Model (Freiman- Park, 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 (Carriere- Thibodeau, 1979) Limited information available Obvious typos and mistakes

Bailey-Basili Meta-Model (Bailey- Basili, 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 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 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 Size2000 SLOC 8000 SLOC SLOC SLOC MM Schedule Months Staff SLOC/ 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. 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!