1. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #1 r2 TM Software Lifecycle Management Lecture r2SEF for COCOMO Integrating Duration, Effort, Cost, Defects, and Uncertainty Presentation to 22 nd International Forum on Systems, Software, and COCOMO Cost Modeling November 2007 Mike Ross President & CEO r2E STIMATING, LLC 7755 E. Evening Glow Drive Scottsdale, Arizona 85262-1295 (o) 480.488.8382 (f) 480.488.8420 mike.ross@r2estimating.com TM

2. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #2 r2 TM r2 Software Estimating Framework (r2SEF) Goals Unify Existing Model MathematicsUnify Existing Model Mathematics –Software Productivity –Defect Propensity –Management Stress Support More Calibration FlexibilitySupport More Calibration Flexibility Support Visual Tools for Analyzing TradeoffsSupport Visual Tools for Analyzing Tradeoffs Support Visual Tools for Analyzing UncertaintySupport Visual Tools for Analyzing Uncertainty

3. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #3 r2 TM Fundamental Empirically-Verified Hypotheses Software can be estimated as a multiplicative relationship between labor and timeSoftware can be estimated as a multiplicative relationship between labor and time –More Size  More Effort and/or More Duration –More Effort  More Size and/or Less Duration –More Duration  More Size and/or Less Effort Defects can be estimated as a ratio relationship between labor and timeDefects can be estimated as a ratio relationship between labor and time –More Effort  More Defects –More Duration  Less Defects

4. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #4 r2 TM Reasonable Corollary Truisms Bigger Software  More DefectsBigger Software  More Defects Shorter Schedule with More People  Higher Cost and More DefectsShorter Schedule with More People  Higher Cost and More Defects Longer Schedule with Fewer People  Lower Cost and Fewer DefectsLonger Schedule with Fewer People  Lower Cost and Fewer Defects

5. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #5 r2 TM Three Laws of Software Project Dynamics Software Construction Process LawSoftware Construction Process Law –Smaller teams tend to be more efficient and more effective. –Increasing the number of people that work on a project dramatically increases communication overhead, which dramatically decreases productivity and dramatically increases defect propensity. Brooks’ Law (limit) – too many people  Brooks’ Law (limit) – too many people   –Adding manpower to a late software project makes it later. –Every project, by its nature (divisibility or potential for concurrency), can effectively handle only so much management stress (only so many people); therefore, there exists, for every project, some minimum achievable development time. Parkinson’s Law (limit) – too much time  Parkinson’s Law (limit) – too much time   –Work expands so as to fill the time available for its completion. –Every project, by its nature (divisibility or potential for concurrency), has some point of maximum productivity; therefore, there exists, for every project, some minimum achievable development effort. (Boehm, 1981), (Boehm et al., 2000), (Jensen, n.d.), (Putnam, 1980), (Ross, 2007a)

6. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #6 r2 TM Defect Propensity LawDefect Propensity Law Defects can be estimated as a ratio relationship between labor and time. Three Parts to the Software Construction Process Law Software Productivity LawSoftware Productivity Law Software can be estimated as a multiplicative relationship between labor and time. Management Stress LawManagement Stress Law Management stress quantifies the balance (or imbalance) between effort and duration. (Jensen, n.d.), (Putnam, 1980) (Ross, 2007a)(Jensen, n.d.), (Putnam, 1980), (Ross, 2007a)

7. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #7 r2 TM Parkinson’s Law (Limit)Parkinson’s Law (Limit) For a given size and efficiency, there exists minimum practical management stress (potential for concurrency) that limits, on the low side, the effort necessary to complete the project. Brooks’ and Parkinson’s Laws Mathematical Relationships Brooks’ Law (Limit)Brooks’ Law (Limit) For a given size and efficiency, there exists maximum achievable management stress (potential for concurrency) that limits, on the low side, the time necessary to complete the project. Too Little Time Too Much Time (Jensen, n.d.), (Putnam, 1980), (Ross, 2007a)(Ross, 2007a)

8. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #8 r2 TM r2 Software Estimating Framework (r2SEF) Equations (Ross, 2007a)

9. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #9 r2 TM r2SEF Variables (Ross, 2007a)

10. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #10 r2 TM r2SEF Variables (Ross, 2007a)

11. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #11 r2 TM COCOMO II to r2SEF Software Productivity Equation (Boehm, et al., 2000), (Ross, 2007a)

12. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #12 r2 TM COCOMO II to r2SEF Software Productivity Equation Variables (Ross, 2007a)

13. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #13 r2 TM COCOMO II to r2SEF Defect Propensity Equation (Boehm, et al., 2000), (Ross, 2007a)

14. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #14 r2 TM COCOMO II to r2SEF Defect Propensity Equation (Ross, 2007a)

15. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #15 r2 TM COCOMO II to r2SEF Defect Propensity Equation Variables (Ross, 2007a)

16. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #16 r2 TM COCOMO II to r2SEF Management Stress Equation (Boehm, et al., 2000), (Ross, 2007a)

17. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #17 r2 TM COCOMO II to r2SEF Management Stress Equation Variables (Ross, 2007a)

18. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #18 r2 TM COCOMO II to r2SEF Management Stress Equation Variables (Boehm, 1981), (Ross, 2007a)

19. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #19 r2 TM Single Point Estimate and Goal Satisfaction Size/Efficiency Ratio Stress (M)

20. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #20 r2 TM Uncertainty in Size and Efficiency Size/Efficiency Ratio 99% 50% 1%

21. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #21 r2 TM Distribution of Solutions for a Given Management Stress Value Size/Efficiency Ratio 99% 50% 1% Stress (M)

22. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #22 r2 TM Ranges of Possible Outcomes 99% 50% 1% Size/Efficiency Ratio Stress (M)

23. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #23 r2 TM Typical (Nominal Stress) Solution at 70% Desired Confidence Probabilities 50% Size/Efficiency Ratio 70% Stress (M)

24. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #24 r2 TM Example Software Project Estimating Scenario Real time embedded avionics software for commercial air transport applicationReal time embedded avionics software for commercial air transport application Effective software size:Effective software size: – [45,000; 50,000; 60,000] SLOC (triangular) Nominal defect density:Nominal defect density: –[1.06; 1.48; 2.07] defects/KSLOC (triangular) Cost of labor: 40 ph/pw; $100/phCost of labor: 40 ph/pw; $100/ph Constraints:Constraints: –Duration: Goal ≤ 104 weeks; Confidence ≥ 80% –Effort: Goal ≤ 2,000 pw; Confidence ≥ 50% –Cost: Goal ≤ $7,000,000; Confidence ≥ 80% –Defects: Goal ≤ 100 deliv. defects; Confidence ≥ 90%

25. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #25 r2 TM COCOMO II Post Architecture Scale Driver and Effort Multiplier Inputs

26. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #26 r2 TM Typical (Nominal Management Stress)

27. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #27 r2 TM Minimum Acceptable Duration

28. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #28 r2 TM Minimum Necessary Duration

29. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #29 r2 TM Identifying and Analyzing Alternatives Change AssumptionsChange Assumptions –Reduce the effective software size (i.e., postpone or eliminate functionality), –Reduce the uncertainty range around effective software size (i.e., refine the size estimate and secure functionality freezes to reduce variability and potential for growth), –Increase efficiency (i.e., better people, better processes/tools, less complex product, etc.), –Reduce the uncertainty range around efficiency (i.e., lock down decisions about the product technology and the development environment). Change ConstraintsChange Constraints –Relax one or more of the goal values, –Relax one or more of the desired confidence probabilities.

30. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #30 r2 TM Typical (Nominal Management Stress)

31. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #31 r2 TM Reduced Effective Software Size

32. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #32 r2 TM Minimum Necessary Duration

33. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #33 r2 TM Relaxed Duration Goal

34. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #34 r2 TM Minimum Necessary Duration

35. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #35 r2 TM High Duration Risk

36. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #36 r2 TM Minimum Necessary Duration

37. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #37 r2 TM Composite Solution #1 Reduced Size & Relaxed Duration Goal

38. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #38 r2 TM Minimum Acceptable Duration

39. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #39 r2 TM Composite Solution #2 Relaxed Effort, Cost, & Defects Goals

40. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #40 r2 TMReferences Boehm, Barry W. 1981. Software Engineering Economics. Englewood Cliffs : Prentice-Hall, Inc., 1981. Boehm, Barry W., et al. 2000. Software Cost Estimation with COCOMO II. Upper Saddle River : Prentice-Hall, Inc., 2000. Browne, J. 2001. Probabilistic Design: Course Notes. Melbourne, Australia : Swinburne University of Technology, 2001. Jensen, Randall W. n.d.. An Improved Macrolevel Software Development Resource Estimation Model. s.l. : Software Engineering, Inc., n.d. Musa, John D. 2004. Software Reliability Engineering: More Reliable Software Faster and Cheaper. 2nd. Bloomington : AuthorHouse, 2004. Norden, Peter V. 1977. Project Life Modeling: Background and Application of Life Cycle Curves. Proceedings, Software Life Cycle Management Workshop. Airlie, VA, USA : Sponsored by USACSC, 1977. Putnam, Lawrence H. 1980. Software Cost Estimating and Life-Cycle Control: Getting the Software Numbers. New York : IEEE Computer Society, 1980.

41. © 2007 r2E STIMATING, LLC r2SEF for COCOMO – Initial #41 r2 TMReferences Ross, Michael A. 2007a. Next Generation Software Project Estimating: 25 Years and Thousands of Projects Later. Proceedings, Joint ISPA / SCEA 2007 Conference. New Orleans, LA, USA : The International Society of Parametric Analysts and The Society of Cost Estimating and Analysis, June 2007a. —. 2007b. Next Generation Software Project Estimating: Know the Odds Before Placing Your Bet. Proceedings, AIAA SPACE 2007 Conference & Exhibition. Long Beach, CA, USA : American Institute of Aeronautics and Astronautics, September 2007b. AIAA 2007-6022.