SMU CSE 7315 Planning and Managing a Software Project

1. SMU CSE 7315Planning and Managing a Software Project Module 19 Some Popular Effort Estimation Models

2. Objectives of This Module • To describe the Intermediate Cocomo estimating model • To discuss other popular estimating models

3. The Big Picturefor Cost Estimating Source Information Statement of Work Requirements Constraints Standards Processes History etc. Estimate Effort and Cost Estimate Size WBS Size Effort & Cost Revise & Negotiate Not OK Complete Detailed Planning Evaluate Estimate Schedule Schedule OK

4. Intermediate Cocomo1 Effort = EAF * a * Size b Where where EAF = E1*E2*...*En Eis are effort multipliers corresponding to a set of common cost drivers. • The nominal value of each Ei = 1. • Ei = 1 implies the cost driver does not apply • Ei > 1 implies increased cost • Ei < 1 implies decreased cost 1) This model is often known as Cocomo 81

5. Effort Multipliers • Typical values range between0.6 & 1.66 • Preset values are established for each factor • All Cocomo multipliers together can affect cost and schedule estimates by 10 times or more!

6. Typical Table ofEffort Multipliers

7. EAFEffort Adjustment Factor • EAF is the product of the effort multipliers • A value of 1 would represent a relatively easy software effort, perhaps with no cost drivers

8. EAFEffort Adjustment Factor (continued) • A value of 1 - 1.5is typical today for a commercial software effort • A value of 1.5 - 2.0is typical today for a real-time effort or a government project

9. EAF Has ImprovedOver the Years • The values typically reported by software projects were once a lot larger (in the 3-4 range), but due to improvements in practices and processes, they have gotten a lot better.

10. Intermediate Cocomo - “a” & “b” Effort = EAF * a * Size b The “mode” is the general type of software

11. Intermediate CocomoSoftware Types (Modes) Organic • Fairly easy software • software development team is familiar with application, language, and tools. • Typically from 2-50 KLOC Semi-Detached • Average software, average team • Typically 50-300 KLOC

12. Intermediate CocomoSoftware Types (Modes) (continued) Embedded • Severe constraints, real time, etc. • No stated size range, but model is known to fail under 10 KLOC NOTE: the origin of the names is obscure, and not considered significant, even by Barry Boehm, who invented Cocomo.

13. Cocomo II Extension • In Cocomo II, there are formulas based on characteristics of the application that allow you to estimate the “a” and “b” values more precisely. • But the best way is always to calibrate to your own data

14. Tasks Included in Cocomo • Cocomo only accounts for the main tasks of software development. • It also includes certain amounts of management, CM, and QA • In Cocomo II, the latter amounts are larger than in older versions Software Code Software Int &Test System Int &Test System Analysis Software Requirements Software Design <---- Cocomo Includes ---->

15. Tasks Excluded From Cocomo • Cocomo does notinclude • System level tasks • Software requirements definition and analysis • System integration and test • Including software support of this activity • Management above the software project level Software Code Software Int &Test System Int &Test System Analysis Software Requirements Software Design <---- Cocomo Includes ---->

16. Division of Labor (Effort) Cocomo Assumes: Effort is divided as: 15-20% Design 50-65% Code and Unit Test 20-30% Integration and Test • These are ranges • You must determine your values • The only way to tell is to measure

17. Remember, Cocomo Excludes Requirements Analysis and System Integration If you add 20% to the total for requirements and integration support, it becomes (roughly): 15-17% Requirements Analysis 10-15% Design 35-50% Code and Unit Test 15-25% Integration and Test

18. The Frailey Percent Question • If you read that “25%” of the effort is devoted to some function, ask yourself the “Frailey Percent Question”: “25% of WHAT?” • 25% of total project effort? • 25% of technical development effort? • 25% of software development effort? • 25% of programming effort? • etc.

19. Assumptions for Time • The percent of time spent in each process phase is different from the percent of effort • The percent of time is more heavily tilted toward requirements analysis and design • You typically have fewer people doing requirements and design than you have in later phases

20. Percentages for Time • Specifics depend on the process being used • Typical numbers for time: 15-25% Requirements 25-30% Design 30-45% Code 10-20% Integration and Test

21. Various Sources Report Different Ratios for Time Grady and Caswell (of Hewlett-Packard) compare five different sources (p34, 35 - see reference at end of module) • Differences stem from: • Type of software being developed • Schedule compression • Organizational differences • Process and Methods

22. Hewlett-Packard Recommendations • Measure actuals • Count everything (overtime, etc.)

23. Process, Methods, and Tools Tools COSTAR, REVIC SLIM SOFTCOST Methods (Models) COCOMO, PUTNAM, ET. AL. Process (Purpose) EFFORT ESTIMATING

24. Cocomo Tool Information CoCo Pro Available through ICONIX Software Engineering Inc. For more information on CoCoPro: HTTP://WWW.ICONIXSW.COM/ Spec_Sheets/CoCoPro.html

25. Cocomo Tool Information (continued) REVIC - A free tool Available through USAF Cost Analysis Agency SOFTEST - an updated version For more information on REVIC or SOFTEST: http://sepo.spawar.navy.mil Or you may have to search the web.

26. Cocomo Tool Information (continued) • SOFTCOST-R / COSTAR • Available through Resource Calculations Inc. For more information: http://www.softstarsystems.com

27. Additional Cocomo II Information Under development at University of Southern California, Cocomo II project. For More Information on Cocomo II: HTTP://SUNSET.USC.EDU/ research/COCOMOII/index.html

28. Other Effort Estimation Models

29. Architecture of Spreadsheet Effort Effort and Cost Schedules Size / Reuse Software Reuse Analysis Final Effort Estimate Generic Schedule Productivity Based Effort Estimate Effort Schedule Final Size Estimate Labor Schedule Historical Size Estimate Model Based Effort Estimate Cost Schedule Delphi Size Estimate Other Effort Estimates ... Other Size Estimates ...

30. Other Popular Cost/Schedule Estimation Models • Putnam’s Model -- (SLIM) • Shen and Conti -- (COPMO) • Lockheed/Martin -- (Price-S) • Galorath, Inc -- (SEER-SEM)

31. SLIM (1) Size = Ck*Effort1/3*t4/3 Sizeis measured in lines of code (or can be thousands if Ck is adjusted) Effortis measured in staff-years Ck is a “state of technology” constant, reflecting use of modern practices, team experience, and software development tools. Compare with Cocomo adjustment factors. t is the development time, in years. (1) Putnam, IEEE Trans. on SW Engineering, July, 1978.

32. Other SLIM Information • EFFORT is for entire life cycle, including maintenance • Development Effort = .39 * EFFORT, according to Putnam For more information on SLIM: HTTP://WWW.QSM.COM

33. Copmo (1) Effort = a + b*Size + c*(Staff)d Effort = Programming Effort+ Coordination Effort The values of the constants a, b, c, and d must determined by regression analysis on actual project data The important issue here is the impact of staff size on management/coordination effort (1) Conte, S.D., et. al. Software Engineering Metrics and Models.

34. Price-S • This is a very complex, proprietary model, based on extensive analysis of many kinds of software projects • The parameters are similar to Cocomo’s adjustment factors, but can be very sensitive • For example, experience level of personnel can affect estimates by 5 times or more

35. Price-S Additional Information Now supplied by PRICE Systems, a Lockheed-Martin Company The product is called the PRICE S Software Estimating Suite For more information on PRICE-S: HTTP://WWW.PRICESYSTEMS.COM

36. SEER-SEM • This is a proprietary model, sold by Galorath, Inc., based on analysis of many kinds of software projects • The model also has elements for size estimation and project management • For example, one can use SEER tools to track progress and risks

37. SEER-SEM Additional Information Galorath, Incorporated El Segundo, California 310-414-3222 For more information on SEER-SEM: HTTP://www.galorath.com/

38. Software Maintenance Estimating • Usually this is done in a “bottom up” manner, such as: • Estimated number of changes * average cost per change or • Level of effort (“n” people per year for “m” years -- total cost = n*m) • Sometimes it is done on a “cost per transaction” basis

39. An Issue with Effort Estimating Methods based on Size • How can you know the size before you have designed the software -- and maybe before you even know its requirements?

40. Dealing with Uncertain Size Estimates • Generally speaking, you can predict size and cost better after design than you can before it • So re-estimation is a MUST for effective risk management • Methods not based on size, such as wideband delphi or “bottom up” effort estimating, should be considered to supplement size-dependent methods

41. An Issue with AllEffort Estimating Methods • You can manipulate the method to get any answer you want • Grady and Caswell report that typical estimates are 20-25% optimistic, even for experienced estimators • So you need to record your results, learn from your mistakes, and do better the next time Grady, Robert B. and Deborah L. Caswell, Software Metrics: Establishing a Company-Wide Program.

42. You Need to Track and Adjust Actuals vs. Estimates

43. Use Several Methods • At the very least, using several methods will increase your chances of being close to the right answer X X X

44. Remember the Goals of Estimating • Knowledge and insight are the real benefits of using different methods • Comparing the results of several methods will force you to resolve the discrepancies • This forces you to think about the issues • And produces more accurate estimates

45. Environmental Factors • Each model deals with factors beyond the basic issues of software development • Management • Coordination • Impact of experience • Stability of virtual machines • Etc. • But this may be the least well understood and most significant factor overall

46. Idealized View ofEngineering Activities Verbal component grows with product complexity

47. All Project Costs All Project Costs Project Effort, Purchased Hardware, Purchased Software, Project Effort, Purchased Hardware, Purchased Software, Purchased Material, Purchased Services, Purchased Material, Purchased Services, Facilities, Training, Travel Facilities, Training, Travel Project Effort Project Effort System Development, Software Development, Hardware Development, System Development, Software Development, Hardware Development, Production, Deployment, Support, Operations, Disposition Production, Deployment, Support, Operations, Disposition Software Development Software Development Planning, Requirements Specification, Planning, Requirements Specification, Software Development Covered by Estimate Software Development Covered by Estimate Software Development Covered By Estimate Software Development Covered By Estimate Preliminary Design, Detailed Design, Code & Unit Test, Integrati Preliminary Design, Detailed Design, Code & Unit Test, Integrati on & Test on & Test Scope of Estimate

48. Module Summary • Intermediate Cocomo combines the Basic Cocomo equation with effort multipliers for cost drivers • Like most models, Cocomo excludes some tasks • Various other models are available • It is best to use several methods, compare results, and iterate your estimates

49. END OF MODULE 19

50. References Conte, S.D., et. al. Software Engineering Metrics and Models. Benjamin Cummings, 1986, p314. Grady, Robert B. and Deborah L. Caswell, Software Metrics: Establishing a Company-Wide Program. Englewood Cliffs, N.J., Prentice-Hall, Inc., 1987. ISBN 0-13-821844-7. Putnam, Lawrence H., “A General Empirical Solution to the Macro Software Sizing and Estimating Problem,” IEEE Transactions on Software Engineering, July, 1978, p345.