The Problems. Predicting software costPredicting software scheduleControlling software risk. Criteria for a Good Model. Defined?clear what is estimatedAccurateObjective?avoids subjective factorsResults understandableDetailedStable?second order relationshipsRight ScopeEasy to UseCausal?future data not requiredParsimonious?everything present is important.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
1. Software Cost and Schedule Estimation Dr. Harry R. Erwin
University of Sunderland
2. The Problems Predicting software cost
Predicting software schedule
Controlling software risk
3. Criteria for a Good Model Defined—clear what is estimated
Objective—avoids subjective factors
Stable—second order relationships
Easy to Use
Causal—future data not required
Parsimonious—everything present is important
4. Early Models 1965 SDC Model
Putnam SLIM Model
RCA PRICE S Model
1977 Boeing Model
1979 GRC Model
5. 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
6. 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
7. Doty Model (Herd et al., 1977) Extended the SDC Model
MM = C(special factors)*(DSI) 1.047
Problems with stability
8. RCA PRICE S Model (Freiman-Park, 1979) Commercially available
Similar to CoCoMo (see below)
9. IBM-FSD Model (Walston-Felix, 1977) Not fully described
Used by IBM to estimate programs
Some statistical concerns
10. 1977 Boeing Model (Black et al., 1977) Similar to CoCoMo, but simpler
Out of use
11. 1979 GRC Model (Carriere-Thibodeau, 1979) Limited information available
Obvious typos and mistakes
12. Bailey-Basili Meta-Model (Bailey-Basili, 1981) Rigorous statistical analysis of factors and size.
Not much experience
13. CoCoMo Waterfall Model
Can be adapted to other models
Verification and validation
CM and QA
14. Where to Find CoCoMo http://sunset.usc.edu/index.html
Or do a Google search on Barry Boehm.
15. Nature of Estimates Man Months (or Person Months), defined as 152 man-hours of direct-charged labor
Schedule in months (requirements complete to acceptance)
16. Input Data Delivered source instructions (DSI)
Various scale factors:
17. 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
18. Basic Schedule Model
19. 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
20. Nominal Project Profiles
21. 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.
22. More Sophisticated Modeling Incorporates: Development Modes
Product Level Estimates
Component Level Estimates
23. Risk Analysis A risk is a vulnerability that is actually likely to happen and will result in some significant effect
Standard software development risks:
Schedule (covaries with cost)
Technical (opposes cost)
Spend money to control them (Spiral Model)
24. 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
25. 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.
26. 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!