Copyright , 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version “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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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)

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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?

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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?

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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 % 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)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M18 - Version 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

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