- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

#### Presentation Transcript

**1. **Software Cost and Schedule Estimation Dr. Harry R. Erwin
University of Sunderland
<http://osiris.sunderland.ac.uk/~cs0her/>
<mailto:[email protected]>

**2. **The Problems Predicting software cost
Predicting software schedule
Controlling software risk

**3. **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

**4. **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

**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
Aerospace applications
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
Poor estimates

**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
Estimates:
Requirements analysis
Product design
Programming
Test planning
Verification and validation
Project office
CM and QA
Documentation

**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)
Well-managed program

**16. **Input Data Delivered source instructions (DSI)
Various scale factors:
Experience
Process maturity
Required reliability
Complexity
Developmental constraints

**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
Activity Distribution
Product Level Estimates
Component Level Estimates
Cost Drivers

**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:
Cost
Schedule (covaries with cost)
Technical (opposes cost)
Approach:
Identify them
Track them
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!