1. Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M18 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project Module 18 Introduction to Effort Estimating Models

2. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 2 Objectives of This Module  To introduce the concept of effort estimating models  To present some simple models  To discuss general issues associated with such models

3. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 3 The Big Picture for Cost Estimating Estimate Size Estimate Effort and Cost Estimate Schedule Evaluate Source Information Statement of Work Requirements Constraints Standards Processes History etc. WBSSize Effort & Cost Schedule OK Complete Detailed Planning Revise & Negotiate Not OK

4. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 4 Architecture of Spreadsheet Model Based Effort Estimate Other Effort Estimates... Historical Size Estimate Software Reuse Analysis Final Effort Estimate Productivity Based Effort Estimate Other Size Estimates... Final Size Estimate Delphi Size Estimate Size / Reuse EffortEffort & Cost Schedules Generic Schedule Effort Schedule Labor Schedule Cost Schedule

5. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 5 Effort Estimating Models... … help us predict effort and cost, given many facts about the software (The principal facts are the estimated size and complexity of the software) These are similar to the size models we discussed before, in general concept

6. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 6 Developing an Effort Estimation Model

7. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 7 An Effort Estimation Model is... … an algorithm or equation or set of equations that produces an estimate of the effort, given inputs that describe the software to be written Estimation Model Description of Software Estimate of Effort

8. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 8 A Very Simple Model Examples: –staff-days = lines of code*staff-days/LOC –staff-months = modules*staff-months/module –staff-hours = function points*staff-hours/FP The first estimation method is, in fact, a very simple estimating model Effort = Size * Productivity

9. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 9 A Graph of the Model EffortEffort Size Effort = Size * Constant

10. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 10 But We Know That... … effort grows faster as size increases, due to management overhead and other such factors –This is known as “diseconomy of scale”  So the graph ought to curve up rather than being a straight line

11. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 11 Size EffortEffort Perhaps Something like This (Diseconomy of Scale)

12. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 12 One Model That Produces Such a Curve a and b are constants that depend on the organization and the type of software Effort = a * Size b Many organizations find that their software effort fits this model for effort as a function of software size Size EffortEffort

13. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 13 “b” Is Called the “Economy of Scale” Factor  On most software projects, especially large ones, we observe a diseconomy of scale (b > 1) because of the additional communication and management overhead of larger projects (as shown on previous slides)  This causes the curve to turn up

14. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 14 Economy of Scale Is Possible  We could see economy of scale (b<1), especially on small projects, such as: –when fixed start-up costs are amortized as size increases –or when something about the nature of the approach allows you to be more productive for larger software projects  See next slide for an illustration

15. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 15 Economy of Scale (b < 1) Size EffortEffort

16. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 16 How to Determine the Curve  By observing organizational experience over a period of time, you can –collect enough data to determine whether this curve fits your data, and –calculate typical values of a and b using curve fitting techniques taught in numerical analysis courses  One such model is called “Cocomo” –we will discuss Cocomo later in this module

17. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 17 Does This Apply to My Project?  Some argue that models like this only make sense for large projects using traditional software development methods While such models are more commonly used for large projects and traditional software development methods, there are many principles applicable to small projects and to newer development methods

18. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 18 Basic Cocomo Model  Size is in Thousands of Lines of Code  Effort is in staff-months, assuming 19 staff- days per staff-month Effort = 3 * Size 1.12 This is the least detailed version of the Cocomo model. It is often used for making “sanity checks” on results of estimates from other methods

19. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 19 Use on Real Projects  Basic Cocomo was derived from a set of about 50 projects at TRW corporation from the late 1970’s  To use this on this a real project, you could estimate with the Basic Cocomo model, compare it with actual results or past experience, and adjust to more accurately reflect your experience.

20. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 20 Calibration  Over time, you would calibrate your experience on projects to the equation and determine the values of “a” and “b” that fit your data the best.  For example, your version of the model might turn out to be: Effort = 2.7 * Size 1.24

21. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 21 Cocomo II Extension  In Cocomo II, the latest version of the model, the exponent, b, can be estimated based on a series of “scale drivers” which address such factors as: –experience with similar projects –flexibility of development process –maturity of design approach –team cohesion –process maturity (on SEI CMMI scale)

22. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 22 Calibrating & Validating a Model

23. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 23 Validation... … is the process of evaluating or proving that the model accurately predicts what you want it to predict –Does your data typically fit the curve? –Is this the right curve? –What was the basis for the equation(s) used in the model?  What assumptions were made?  What type of application is intended?

24. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 24 For Example, the Basic Cocomo Model... … was based on relatively large programs (more than 10,000 lines of code … assumes a relatively formal development process based on the waterfall lifecycle … was derived from about 50 programs developed by TRW corporation in the late 1970’s

25. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 25 Validating Suitability of a Model for Your Projects  Look at data from your projects –Do your data tend to fit the same kind of curve?  Compare your assumptions with those of the model –If the assumptions do not match, you may need to investigate further to see if the model still fits

26. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 26 Calibration... … is the process of adjusting the key constants or other model factors so the results tend to approximate your data –For example, a and b in Cocomo … is usually accomplished by statistical methods such as regression analysis Often you need to calibrate differently for different kinds of software or different application types

27. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 27 Calibrating a Model Estimating Model Your Data Your Experience Your Model Your Insight adjust

28. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 28 Cost Drivers and Effort Multipliers

29. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 29 Nominal Effort  When we apply a model, the “nominal” effort is the effort predicted by the model under typical or nominal circumstances –Nothing unusual or out of the ordinary –Something we know how to do

30. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 30 But Not All Projects Are Typical  It is very common to have factors that make the effort for a particular project higher or lower than normal –Experience of staff –Complexity of products –Strength of tools

31. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 31 Factors that Affect Effort  Such factors influence the effort estimate & hence cost -- and thus are termed “Cost Drivers”  Cost drivers are often included as parameters to effort estimating models  We will examine the cost drivers used in more advanced versions of Cocomo –Similar drivers are used in other models

32. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 32 Cost Drivers - I The Nature of the Job to be Done 1) Required Reliability (0.75 – 1.40) –Often applies to real time applications –Or to applications with long lifetimes 2) Data Base Size (0.94 – 1.16) –Applies mainly to data processing applications (numbers in parentheses represent range of impact in intermediate Cocomo model)

33. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 33 Cost Drivers - I (continued) The Nature of the Job to be Done 3) Product Complexity (0.70 – 1.65) 4) Execution Time Constraints (1.0 – 1.66) –This driver is relevant when processor speed may not be sufficient for the application –Or when precise timing is required

34. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 34 Cost Drivers - I (continued) The Nature of the Job to be Done 5) Main Storage Constraints (1.0 – 1.56) –Applies when memory size may not be sufficient for the application 6) Target Machine Volatility (0.93 – 1.16) –Includes hardware and operating system 7) Development Machine Volatility (0.92 – 1.17) –Unstable OS, compilers, development tools, etc.

35. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 35 Cost Drivers - II The Practices & Tools 1) Modern Programming Practices (1.24 – 0.82) –Structured Analysis or OO 2) Modern Programming Tools (1.24 – 0.83) –e.g., integrated design tools, good debuggers, test generation tools 3) Schedule Compression (1.23 – 1.0) or Expansion (1.0 – 1.10) –Note -- deviation from ideal can never help, but shorter is worse than longer

36. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 36 Cost Drivers - III The People Who Will Do It 1) Analyst capability (1.46 – 0.71) 2) Programmer capability (1.42 – 0.70) 3) Analyst experience (1.29 – 0.82) 4) Virtual machine experience (1.21 – 0.90) –Includes operating system and processor 5) Programming language experience (1.14 – 0.86) –Includes experience with tools and practices

37. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 37 Cost Drivers - IV Additional Drivers Often Used 1) Requirements volatility –Some change in requirements is expected, but too much can have a strong effect on project cost 2) Security requirements (1.0 – 1.1) 3) Access to data –Sometimes very difficult

38. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 38 Cost Drivers - IV (continued) Additional Drivers Often Used 4) Impact of standards and imposed methods 5) Impact of physical surroundings 6) A project requirement to design software to be reusable (1.0 – 1.5) 7 …) You can add whatever others make sense in your situation

39. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 39 Example of Applying a Cost Driver You need to train the new people You need to allow them time to gain experience or “get up to speed” (this is known as “climbing the learning curve”) They will be less productive than experienced people would be on the same job “Nominal” estimate with experienced staff is 60 staff-weeks (3 people, 20 weeks) Suppose we have an inexperienced staff -- what can we estimate?

40. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 40 How You Might Factor In This Cost Driver With inexperienced people, you plan: A training period - 1 week per person or 3 staff-weeks total Lower productivity - 66.7% of normal effort (estimate based on your experience) Thus estimate for effort is 60/66.7% = 90 staff-weeks + 3 staff-weeks of training = 93 staff-weeks total (3 people, 31 weeks) “Nominal” estimate with experienced staff is 60 staff-weeks (3 people, 20 weeks)

41. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 41 How Do You Handle Multiple Cost Drivers?  Some cost drivers have a multiplicative effect on effort  For such cases, you can define an effort multiplier for each cost driver  For example, if high complexity tends to make effort about 12% higher, than you can define a “high complexity” effort multiplier of 1.12

42. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 42 Effort Multipliers  Determine an effort multiplier for each cost driver –multiplier = 1 means the driver does not apply –multiplier > 1 means the driver increases cost –multiplier < 1 means the driver decreases cost Effort = Nominal * Product of All Multipliers

43. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 43 Suppose: Nominal is 200 staff-months Complexity is very high Staff experience is high Then: Estimated effort = 200 * 1.30 *.91 = 236.6 staff-months Applying Multiple Cost Drivers Table of Effort Multipliers Cost DriverNormalHighVery High Complexity1.01.151.30 Reliability1.01.151.40 Experience1.0.91.82 etc.etc.etc.etc. The table represents your organization’s collective experience of the impact of various cost drivers.

44. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 44 Module Summary  Models are often helpful to estimate effort –All are based on historical experience –All should be calibrated to your specific experience –Most have additional parameters that allow you to “fine tune” to specific circumstances

45. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 9.01 45 END OF MODULE 18