Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 1 8/8/2004 Day 2, Part 2 Estimating Software Effort & Cost Section 1 – Fundamental Issues

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 2 8/8/2004 Outline Measures of Effort Inputs to the Effort Estimate Effort Estimation Steps Estimation based on Historical Productivity Wideband Delphi for Effort Estimation Bottom Up Estimating

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 3 8/8/2004 The Overall Planning Cycle Analyze Job Manage Risks Execute Generate Detailed Plans Generate Initial Plans Measure, Manage Productivity and Quality

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 4 8/8/2004 Detailed Planning - Processes 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, All Rights Reserved Day 2, Part 2, Page 5 8/8/2004 Measures of Effort

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 6 8/8/2004 Effort Is... … the amount of labor required for the project It is typically measured in staff- months, staff-days or staff-hours  A month (or calendar-month) is a measure of time  A staff-month is a measure of effort If three people complete a job in 1 calendar-month, it is a 1 calendar-month job that requires 3 staff-months of effort

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 7 8/8/2004 Effort Is Not Defined Precisely There are no generally accepted, precise definitions for terms like staff-month or staff-day And people are known to “fudge” the definitions in their own favor

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 8 8/8/2004 Two Executives on the Golf Course We do 50 LOC per staff month - you do only 40! How do you measure staff months?

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 9 8/8/2004 Staff-Hours, Staff-Days, or Staff-Months There are many ways to measure these And these three are NOT necessarily related in a simple manner Because of this, comparisons can be very misleading

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 10 8/8/2004 How Many Hours per Day? 1 staff-hour = 1 person working for 1 hour 1 staff-day = 1 person working for 1 day How many staff-hours per staff-day? –7? 7.5? 8.0? 8.5? 9.5? ??? –How do you handle paid overtime? –How do you handle unpaid overtime? –How do you handle breaks, lunch hours, etc.?

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 11 8/8/2004 How many productive staff-days per staff-month? –30? 21? 19? ??? –Does it depend on which month? The underlined value is the default assumed by many U.S. companies and many estimating models (this value allows for average number of vacation days and holidays in the U.S.) How Many Days per Month?

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 12 8/8/2004 How Many Hours per Month? 144? 148? 152? 160? 175? 184? ??? Factors that can affect this: –Which month is it? –What is the length of the work day? –How do you handle overtime? –Vacations and holidays –Sick days –What country you are in? –How do you allocate management overhead

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 13 8/8/2004 Lines of code per staff month Objects Tested per staff hour Consistency is the Most Important Factor If you measure effort consistently, you can understand what it costs, compare different projects, and predict future performance

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 14 8/8/2004 Consistency Allows Reasonable Comparisons With Past History Like software size, there are many ways to measure effort and many arguments why each is good or bad You cannot make meaningful evaluations if each project measures effort differently

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 15 8/8/2004 Projects Often Hide Actual Effort Data You cannot tell what really happened on a previous project if you don’t know how they measured effort How many hours did you really spend? We don’t know - we didn’t count unpaid overtime

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 16 8/8/2004 There tend to be fewer variations in how a staff-hour is measured But many organizations use staff- months -- so you need to know how to convert properly in your organization Measure Hours if you Can

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 17 8/8/2004 The Relationship Between Time and Effort

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 18 8/8/2004 What Does a “Staff-month” Mean? If it requires 12 staff-months, does this mean –12 people for 1 month? –1 person for 12 months? –3 people for 4 months? –does it depend on the people? Too often, scheduling and estimating tools make the assumption that all of these are equivalent

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 19 8/8/2004 vs How Flexible is a Staff-Month? There is some flexibility, but only so much Brooks (see references: “The Mythical Man-Month”) explored this issue in considerable detail

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 20 8/8/2004 Cost of Adding More People CC = (N * (N-1))/2 Where... N = Number of people CC = Communication Complexity (extra overhead of managing N people) Brooks’ Equation for Intercommunication Effort

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 21 8/8/2004 You Cannot Just Allocate People Arbitrarily staff- days required to do the work Calendar Time Allocated for the Work Optimal Schedule COCOMO MODEL OF TIME VS EFFORT

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 22 8/8/2004 The Optimal Schedule Depends on Many Factors Process, people, nature of task, tools, management approach, environment, … Different cost estimating models make different assumptions about these matters and how they affect the results

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 23 8/8/2004 Until we have a better theoretical foundation, the only way to determine the optimal is through experience The various estimating models represent the experience of their originators and thus may predict different “optimal” schedules Your Experience Counts More Than Any Model

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 24 8/8/2004 Your Actual High Level Schedule May be Determined by Other Factors In early planning, your project’s overall goals and milestones may define constraints Product deadlines may determine schedule dates Reviews may have to occur at times convenient to others –Customers –Managers

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 25 8/8/2004 Compare the Actual and the Optimal Schedule to Gauge the Schedule Risk If the optimal is significantly different from the actual, you have schedule compression, which means a significant expectation of –increased cost, and –schedule risk Optimal vs. actual schedule information may help you determine cost impact (see “cost drivers,” later in this part)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 26 8/8/2004 Typical Inputs to the Effort Estimate

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 27 8/8/2004 Tasks to be Performed Are a Major Input to Effort Estimation Typically these are found in the WBS –Software development tasks (design, code, test) –Additional development tasks (requirements, system integration) –Support tasks (CM, QA, management) –Tasks requiring additional labor (documents, audits, etc.) –Additional dollar costs (travel, equipment, etc)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 28 8/8/2004 Other Inputs to Effort Estimate Estimated software size Historical data on effort & productivity High level schedule Process and methods Programming language Operating system for target system Tools to be used Staff experience level

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 29 8/8/2004 Effort Estimating Steps 1) Summarize and document the requirements for each task –Basis of estimate –WBS dictionary 2) Quantify the magnitude of each task –Size & complexity for software –# of pages, # of trips, # of whatever for other things

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 30 8/8/2004 Effort Estimating Steps 3) Estimate effort for software development tasks 4) Estimate again with an alternative method 5) Resolve discrepancies between the two methods (repeat from step 1, as required) 6) Add effort estimates for other tasks (such as support tasks)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 31 8/8/2004 In Other Words... WBS Estimate Size and Then Effort Estimate Costs Directly or as % of Development Costs Software Development Tasks requirements design code... Other Tasks and Costs management travel training overhead facilities equipment software … Convert to $ Total Cost Estimate Total Cost Estimate Estimate Development Costs Then Estimate Other Costs

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 32 8/8/2004 Notes for Effort Estimation Accuracy of estimate depends on –Experience –Historical data –Availability of information –& LUCK! At the start of a project, you are lucky to be within 20% unless you have very good historical data –It is not unusual to be 100% off

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 33 8/8/2004 Good History Data Good historical data are essential for accurate estimating.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 34 8/8/2004 Architecture of Spreadsheet Model Based Estimate Other Effort Estimates... Historical Size Estimate Software Reuse Analysis Size / Reuse Effort Final Effort Estimate Productivity Based Effort Estimate Other Size Estimates... Final Size Estimate Delphi Size Estimate Schedules Generic Schedule Effort Schedule

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 35 8/8/2004 Effort Estimation with Historical Productivity Data

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 36 8/8/2004 Effort Can Be Estimated From Size and Productivity Effort = Size * Historical Productivity Examples: –Staff Days = Lines of Code*Staff Days/LOC –Staff Days = Modules*Staff Days/Module –Staff Days = Function Points*Staff Days/FP Whatever unit you measure, if you have good historical data, this method can be fast and effective

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 37 8/8/2004 Typical values for Productivity Rates 2-15 LOC/day for high order languages 3-25 LOC/day for assembly language Lower values for constrained projects –real time/ safety critical systems etc. Higher numbers for commercial applications with few constraints Even higher numbers can be achieved if you use 4GLs, high levels of reuse, etc.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 38 8/8/2004 Example In the past, we have had the following productivity: –4 LOC/sd for complex software –8 LOC/sd for simple software For the new “8000 LOC”, “complex” software, it should take 8000/4 = 2000 staff days …But how accurate is this?

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 39 8/8/2004 Historical Data (Typical) LOC Developed per Staff-day

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 40 8/8/2004 Historical Data are Seldom Precise or Consistent Example: Effort for complex software varies from 2 to 6 LOC per staff day, with a mean of 4 LOC per staff day The expected effort for an 8000 SLOC program might be As low as 1334 staff days or... As high as 4000 staff days!

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 41 8/8/2004 In Other Words Historical Data usually gives a RANGE of values, not a precise estimate Based on past experience, this project should take from 100 to 125 staff months

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 42 8/8/2004 Three Risk Management Approaches Use multiple estimating methods –They will help improve the bounds on your estimate –Each new method will identify issues that other methods overlook Set aside a “reserve” amount based on the level of risk in your estimate Plan to update your estimates –You will have better information in the future

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 43 8/8/2004 What Do Multiple Methods Tell You? They help you understand the degree of uncertainty and/or confidence in your estimate - so you can manage more effectively They force you to ask hard questions about what facts each method overlooks They help you learn

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 44 8/8/2004 Statistical Variances and Uncertainties True Cost? Method 1 Method 3Method 2 Region of Likely Costs

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 45 8/8/2004 Beware of Averages Significant differences in estimates usually mean significant differences in assumptions or facts considered In such cases, averages may be meaningless XXXXXXX Average is Meaningless

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 46 8/8/2004 Wideband Delphi Wideband Delphi can be used to estimate effort as well as size –On small projects this is often the most effective way to estimate effort –Also useful for estimating other costs, such as management overhead, tools, support functions etc. I assume it will take 3 people for 2 months. x xx x x

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 47 8/8/2004 Bottom Up Estimating

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 48 8/8/2004 Bottom Up Estimating This method may take a lot of time It may or may not be based on size estimates This method has several benefits –Each part of the project is estimated by someone who knows that part well –Individuals “buy in” to the estimate because it was based on their expertise –It is easy to compare actual results with estimates and determine if and where you went wrong

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 49 8/8/2004 Bottom Up Estimating Process 1) Break the software down into components -- as detailed as you can –Break down until the individual parts are small enough for an individual to develop in a short time (1 week to 1 month perhaps) –If you do not know, make a reasonable estimate of how you could break each part of the software into smaller parts 2) Estimate each part 3) Combine estimates

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 50 8/8/2004 Sample Breakdown Data base I/F Error Processor Sort Module Synchro- nizer Command Processor Table Interface JoeMary & Jim Bert & Sally JoeBertSally Parser Code Generator File System Run Time System User Interface Manage Software Development Build “C” Compiler Build Test Suite Write Documentation Write Installation Software Software for “C” Compiler

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 51 8/8/2004 Sample Estimate 6 SW 1 SW 4 SW 5 SW 3 SW 4 SW JoeMary & Jim Bert & Sally JoeBertSally 12 SW28 SW23 SW14 SW18 SW 95 SW33 SW12 SW22 SW 180 SW

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 52 8/8/2004 For an Object Oriented Design You May Break it Up Differently Class “Query” Subclass “User Response” Class “Error Code” Class “Response” Subclass “System Response” Subclass “Maintenance Response”

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 53 8/8/2004 Day 2, Part 1 Estimating Effort and Cost Section 2 - Estimation as a Series of Schedules

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 54 8/8/2004 A Fundamental Issue in Estimation How do you “put it all together”? –Size –Effort –Cost –Schedule –Staffing levels How do you “keep it all together” as you revise and update the estimates?

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 55 8/8/2004 A General Process for Documenting & Updating Estimates The process to be described is a framework for estimating You can use any estimating methods you choose The process allocates estimated effort and cost across a schedule And by using a spreadsheet, you can easily update all estimates

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 56 8/8/2004 Architecture of Spreadsheet Model Based Estimate Other Effort Estimates... Historical Size Estimate Software Reuse Analysis Size / Reuse EffortSchedules Final Effort Estimate Productivity Based Effort Estimate Generic Schedule Effort Schedule Other Size Estimates... Final Size Estimate Delphi Size Estimate

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 57 8/8/2004 Some Features of This Estimating Process The process allows you to evaluate: –Staffing and shopload –Resource requirements (equipment, people, money, …) –Cash flow It serves as a basis for managing –It provides initial estimates of many quantities you will want to track against actuals during project execution

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 58 8/8/2004 Revised Effort Schedule Top Level Schedule Generic Schedule Effort Schedule Effort Cost Schedule Cost S, SA P AL WBS cost categories AD Initial Planning Process Model Additional Labor The Estimation Sequence

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 59 8/8/2004 Cost Categories for WBS Tasks Each category is used at a different point in the estimating process

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 60 8/8/2004 Revised Effort Schedule Top Level Schedule Generic Schedule Effort Schedule Cost Schedule S, SA P AL WBS cost categories AD Initial Planning Process Model The Estimation Sequence Effort Estimate Additional Labor Cost

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 61 8/8/2004 The Generic Schedule is... … a mapping of “the process” to the top level schedule –It indicates what portion of the schedule will be devoted to each phase of the process … the schedule control mechanism for the estimating spreadsheet –If you change your schedule or your process, you adjust the generic schedule and the rest of the schedules will automatically adjust

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 62 8/8/2004 The Generic Schedule Tells You... Where you will perform each process phase, in relation to the overall project schedule

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 63 8/8/2004 Typical Generic Schedule for Waterfall Model Lifecycle ProcessSchedule

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 64 8/8/2004 Typical Generic Schedule for Incremental Model Lifecycle

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 65 8/8/2004 Generic Schedule Notes You can do a separate generic schedule for each separate software item –And add them together to form a generic schedule for the total software project –This method is recommended if their processes or schedules are different Or you may combine all software items into one generic schedule –This method is recommended if their processes and schedules are the same

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 66 8/8/2004 Revised Effort Schedule Top Level Schedule Generic Schedule Effort Schedule Cost Schedule S, SA P AL WBS cost categories AD Initial Planning Process Model The Estimation Sequence Effort Estimate Cost Additional Labor

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 67 8/8/2004 The Effort Schedule is... … a mapping of the estimated effort to the process phases and the schedule –It indicates how much effort will be spent each month on each phase of the process

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 68 8/8/2004 You Need to Partition Estimated Effort by Phase SA S S S Cost Category

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 69 8/8/2004 The Effort Vector is Adjusted Base Effort Partitioned by Process Phase (Estimated) Adjusted Base Effort = 2100 staff-days Effort Vector SA S S S Cost Category

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 70 8/8/2004 Effort Schedule Matrix Equation Effort Schedule Effort Vector Generic Schedule = *

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 71 8/8/2004 Typical Initial Effort Schedule Sub-total = Adjusted Base Effort (S tasks plus SA tasks)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 72 8/8/2004 To Produce the Effort Schedule Multiply each cell in the Generic Schedule by the effort to be spent on the corresponding phase of the process (from the effort vector) The result is the corresponding cell in the Effort Schedule An example is found in the spreadsheet supplied with the course materials

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 73 8/8/2004 Support (“P”) Tasks Must be Added On, Usually Based on a Flat Percentage Example: –Support tasks will add about 300 staff- days of effort, which is 1/7 (14.3%) of the estimated effort –So we add 14.3% to each number in the sub-total line as “add-ons”

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 74 8/8/2004 Typical Final Effort Schedule (Total Effort)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 75 8/8/2004 The Effort Schedule Tells You... … how much total effort will be expended each month, for basic software development & support … what will be going on each month in terms of process phases

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 76 8/8/2004 How Many People? Head count (number of people) can be calculated by dividing the total effort by the availability (effort available per person per month) –This tells you how many people you will need each month Example: if there are 57 staff-days of effort required and each person works 19 days per month, then you need: 57/19 = 3 people.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 77 8/8/2004 Head Count

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 78 8/8/2004 The Head Count Tells You About Additional Risks Unrealistic staff growth Grossly uneven staffing needs

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 79 8/8/2004 Typical Head Count Graph Data taken directly from effort schedule

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 80 8/8/2004 You Can Track Actuals During Execution

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 81 8/8/2004 Revised Effort Schedule Top Level Schedule Generic Schedule Effort Schedule Cost Schedule S, SA P AL WBS cost categories AD Initial Planning Process Model The Estimation Sequence Effort Estimate Cost Additional Labor

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 82 8/8/2004 The Revised Effort Schedule... Incorporates labor for tasks beyond basic software development –Special audits –Validation steps –Special documents to be produced –Tasks beyond the usual process It is prepared by adding a row to the effort schedule that shows additional labor, and then a grand total row

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 83 8/8/2004 Revised Effort Schedule

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 84 8/8/2004 Revised Effort Schedule Top Level Schedule Generic Schedule Effort Schedule Cost Schedule S, SA P AL WBS cost categories AD Initial Planning Process Model The Estimation Sequence Effort Estimate Cost Additional Labor

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 85 8/8/2004 The Cost Schedule is... … three rows added to the effort schedule 1Effort converted to dollars (*) 2Additional money required (for travel, equipment, and other non-labor costs) 3Grand Total cost (#1 + #2) … the cells indicate dollars rather than effort (*) Multiply “Grand Total Effort” cells by average cost per labor hour

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 86 8/8/2004 Cost Schedule

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 87 8/8/2004 The Cost Schedule Indicates How much money will be spent each month And it incorporates money for costs not measured in units of labor (e.g., travel)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 88 8/8/2004 A Typical Cost Schedule

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 89 8/8/2004 The Cost Schedule Has Many Uses Cost of the project How much money you need each month Inflation can be adjusted for longer projects Interest information may be incorporated if money must be borrowed

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 90 8/8/2004 Revised Effort Schedule Top Level Schedule Generic Schedule Effort Schedule Effort Cost Schedule Cost S, SA P AL WBS cost categories AD Initial Planning Process Model Additional Labor The Estimation Sequence

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 91 8/8/2004 Architecture of Spreadsheet Model Based 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 EffortSchedules Generic Schedule Effort Schedule

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 92 8/8/2004 Day 2, Part 1 Estimating Effort and Cost Section 3 - Estimation Models & Negotiation

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 93 8/8/2004 Outline Developing an estimation model Calibrating and validating a model Cost drivers The Cocomo model Other estimation models Bottom-up estimating Estimating cost Negotiating

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 94 8/8/2004 Architecture of Spreadsheet Model Based 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 EffortSchedules Generic Schedule Effort Schedule

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 95 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 96 8/8/2004 Developing an Estimation Model

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 97 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 98 8/8/2004 A Very Simple Model Examples: –Staff Days = Lines of Code*Staff Days/LOC –Staff Days = Modules*Staff Days/Module –Staff Days = Function Points*Staff Days/FP The first estimation method is, in fact, a very simple estimating model Effort = Size * Productivity

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 99 8/8/2004 A Graph of the Model EffortEffort Size Effort = Size * Constant

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 100 8/8/2004 But We Know That... Effort usually grows faster as size increases due to management overhead and other such factors So the graph ought to curve up rather than being a straight line

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 101 8/8/2004 Perhaps Something like This Size EffortEffort

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 102 8/8/2004 One Model That Produces Such a Curve a and b are constants that depend on the software development organization and the type of software Size EffortEffort Effort = a * Size b Many organizations find that their software effort fits this model for effort as a function of software size

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 103 8/8/2004 “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, All Rights Reserved Day 2, Part 2, Page 104 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 105 8/8/2004 Economy of Scale (b < 1) Size EffortEffort

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 106 8/8/2004 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 One such model is called “Cocomo” –we will discuss Cocomo in subsequent slides

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 107 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 108 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 109 8/8/2004 How to Use on Your Projects Basic Cocomo was derived from a set of about 50 projects at TRW corporation from the late 1970’s To use this on your projects, you could estimate with the Basic Cocomo model, compare that with actual results or past experience, and adjust to more accurately reflect your experience.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 110 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 111 8/8/2004 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 CMM scale)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 112 8/8/2004 Calibrating & Validating a Model

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 113 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 114 8/8/2004 For Example, the Cocomo Model... Is calibrated from 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, All Rights Reserved Day 2, Part 2, Page 115 8/8/2004 Validating Suitability of a Model Look at data from your programs –Does the 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, All Rights Reserved Day 2, Part 2, Page 116 8/8/2004 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 … 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, All Rights Reserved Day 2, Part 2, Page 117 8/8/2004 Calibrating a Model Estimating Model Your Data Your Experience Your Model Your Insight adjust

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 118 8/8/2004 Cost Drivers

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 119 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 120 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 121 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 122 8/8/2004 Cost Drivers - I The Nature of the Job to be Done 1) Required Reliability –Applies mainly to real time applications 2) Data Base Size –Applies mainly to data processing apps 3) Product Complexity 4) Execution Time Constraints –When processor speed is barely sufficient

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 123 8/8/2004 Cost Drivers - I (continued) 5) Main Storage Constraints –Applies when memory size is barely sufficient 6) Target Machine Volatility –Includes hardware and operating system 7) Development Machine Volatility –Unstable OS, compilers, CASE tools, etc.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 124 8/8/2004 Cost Drivers - II The Practices & Tools 1) Modern Programming Practices –Structured Analysis or OO 2) Modern Programming Tools –e.g., CASE tools, good debuggers, test generation tools 3) Schedule Compression (or expansion) –Note -- deviation from ideal can never help, but shorter is worse than longer

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 125 8/8/2004 Cost Drivers - III The People Who Will Do It 1) Analyst Capability 2) Application Experience 3) Programmer Capability 4) Virtual Machine Experience –Includes operating system and hardware 5) Programming Language Experience –Includes tools and practices

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 126 8/8/2004 Cost Drivers - IV Additional Drivers Often Used 1) Requirements volatility –A little change in requirements is expected, but too much can have a strong effect on project cost 2) Security requirements 3) Access to data –Sometimes very difficult

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 127 8/8/2004 Cost Drivers - IV (continued) 4) Impact of standards and imposed methods 5) Impact of physical surroundings 6) A need to design software to be reusable 7 …) You can add whatever others make sense in your situation

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 128 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 129 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 130 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 131 8/8/2004 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, All Rights Reserved Day 2, Part 2, Page 132 8/8/2004 Applying Multiple Cost Drivers Table of Effort Multipliers DriverNormalHighVery High Complexity Reliability Experience etc.etc.etc.etc. Suppose: Nominal is 200 staff months Complexity is very high Staff experience is high Then: Estimated effort = 200 * 1.30 *.91 = The table represents your organization’s collective experience of the impact of various factors or cost drivers.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 133 8/8/2004 Intermediate Cocomo 1 Where where EAF = E 1 *E 2 *...*E n E i s are effort multipliers corresponding to a set of common cost drivers. –The nominal value of each E i = 1. –E i = 1 implies the cost driver does not apply –E i > 1 implies increased cost –E i < 1 implies decreased cost Effort = EAF * a * Size b 1) This model is often known as Cocomo 81

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 134 8/8/2004 Effort Multipliers Typical values range between 0.6 & 1.5 Preset values are established for each factor All Cocomo multipliers together can affect cost and schedule estimates by 10 times or more!

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 135 8/8/2004 Typical Table of Effort Multipliers

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 136 8/8/2004 EAF Effort 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

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 137 8/8/2004 EAF Effort Adjustment Factor (continued) A value of is typical today for a commercial software effort A value of is typical today for a real-time effort or a government project

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 138 8/8/2004 EAF Has Improved Over 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.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 139 8/8/2004 Intermediate Cocomo - “a” & “b” The “mode” is the general type of software Effort = EAF * a * Size b

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 140 8/8/2004 Cocomo Software 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 KLOC

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 141 8/8/2004 Cocomo Software Types (Modes) (continued) Embedded –Severe constraints, real time, etc. –No stated size range, but model is known to fail under 10KLOC NOTE: the origin of the names is obscure, and not considered significant, even by Barry Boehm, who invented Cocomo.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 142 8/8/2004 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

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 143 8/8/2004 Cocomo Tool Information CoCo Pro Available through ICONIX Software Engineering Inc. For more information on CoCoPro: Spec_Sheets/CoCoPro.html For more information on CoCoPro: Spec_Sheets/CoCoPro.html

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 144 8/8/2004 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: For more information on REVIC or SOFTEST:

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 145 8/8/2004 Cocomo Tool Information (continued) SOFTCOST-R Available through Resource Calculations Inc. For more information on SOFTCOST-R: For more information on SOFTCOST-R:

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 146 8/8/2004 Additional Cocomo II Information Under development at University of Southern California, Cocomo II project. For More Information on Cocomo II: research/COCOMOII/index.html For More Information on Cocomo II: research/COCOMOII/index.html

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 147 8/8/2004 Architecture of Spreadsheet Model Based Estimate Other Effort Estimates... Historical Size Estimate Software Reuse Analysis Size / Reuse EffortSchedules Final Effort Estimate Productivity Based Effort Estimate Generic Schedule Effort Schedule Other Size Estimates... Final Size Estimate Delphi Size Estimate

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 148 8/8/2004 Other Estimation Models

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 149 8/8/2004 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 System Analysis Software Requirements System Int &Test Software Design Software Code Software Int &Test Tasks Included in Cocomo

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 150 8/8/2004 Cocomo does not include –System level tasks –Software requirements definition and analysis –System integration and test Including software support of this activity –Management above the software project level System Analysis Software Requirements System Int &Test Software Design Software Code Software Int &Test Tasks Excluded From Cocomo

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 151 8/8/2004 Other Popular Cost/Schedule Estimation Models Putnam’s Model -- (SLIM) Shen and Conti -- (COPMO) Lockheed/Martin -- (Price-S) Galorath, Inc -- (SEER-SEM)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 152 8/8/2004 SLIM (1) Size is measured in lines of code (or can be thousands if C k is adjusted) Effort is measured in staff-years C k 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, Size = C k * Effort 1/3 * t 4/3

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 153 8/8/2004 SLIM Information EFFORT is for entire life cycle, including maintenance Development Effort =.39 * EFFORT, according to Putnam For more information on SLIM: For more information on SLIM:

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 154 8/8/2004 Copmo (1) 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. Effort = a + b * Size + c * (Staff) d

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 155 8/8/2004 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

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 156 8/8/2004 Price-S Additional Information Now supplied by PRICE Systems, a Martin-Lockheed Company The product is called the PRICE S Software Estimating Suite For more information on PRICE-S: For more information on PRICE-S:

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 157 8/8/2004 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

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 158 8/8/2004 SEER-SEM Additional Information Galorath, Incorporated El Segundo, California For more information on SEER-SEM: For more information on SEER-SEM:

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 159 8/8/2004 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

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 160 8/8/2004 Don’t Treat Maintenance as Reuse Generally speaking, maintenance affects only a small portion of the software If you model the unchanged part as “reused” you will get much too large a number for the estimated effort

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 161 8/8/2004 Process, Methods, and Tools Tools COSTAR, REVIC SLIM SOFTCOST Methods (Models) COCOMO, PUTNAM, ET. AL. Process (Purpose) EFFORT ESTIMATING

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 162 8/8/2004 Architecture of Spreadsheet Model Based Estimate Other Effort Estimates... Historical Size Estimate Software Reuse Analysis Size / Reuse EffortSchedules Final Effort Estimate Productivity Based Effort Estimate Generic Schedule Effort Schedule Other Size Estimates... Final Size Estimate Delphi Size Estimate

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 163 8/8/2004 Compare Results and Judge

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 164 8/8/2004 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?

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 165 8/8/2004 Dealing with Uncertain Size Estimates Generally speaking, you can predict 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

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 166 8/8/2004 Grady, Robert B. and Deborah L. Caswell, Software Metrics: Establishing a Company-Wide Program. An Issue with All Effort 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

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 167 8/8/2004 You Need to Track ……………… Actuals vs. Estimates

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 168 8/8/2004 You Need to Track and Adjust Actuals vs. Estimates

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 169 8/8/2004 Use Several Methods At the very least, using several methods will increase your chances of being close to the right answer XXX

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 170 8/8/2004 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

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 171 8/8/2004 Estimating Cost

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 172 8/8/2004 There are Many Costs Other Than Software Development WBS Estimate Size and Then Effort Estimate Costs Directly or as % of Development Costs Software Development Tasks requirements design code... Other Tasks and Costs management travel training overhead facilities equipment software … Convert to $ Total Cost Estimate Total Cost Estimate

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 173 8/8/2004 Turning Effort into Cost Turning effort estimates into cost estimates depends on many factors that depend on your specific company –Overhead rates –Cost of borrowing money –Methods of calculating profit margin –Allocations of management and support expenses –Costs of capital equipment –etc.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 174 8/8/2004 One Way to Convert Effort to $ Category% of TotalSalary Rate # Requirements10%$65/hour Design10%$50/hour Code30%$40/hour Test30%$30/hour Other5%$15/houretc. # use rate per hour if effort is measured in staff-hours use rate per day if effort is measured in staff-days etc. # use rate per hour if effort is measured in staff-hours use rate per day if effort is measured in staff-days etc.

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 175 8/8/2004 Multiply the Effort by the Percentages to get the Labor Distribution and $ 10,000 hours: 1000 hours - requirements x $65 = $65, hours - design x $50 = $50, hours - code x $40 = $120, hours - test x $30 = $90,000 etc. Total: $xxx,xxx

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 176 8/8/2004 A Note About the Salary Rate Chart Be sure to correlate the percentages with the “experience level” factors assumed in your effort estimate >> It is tempting to cut costs estimates by boosting the percentage of lower cost staff -- check what this does to the cost drivers first!!! <<

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 177 8/8/2004 Negotiation

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 178 8/8/2004 Detailed Planning - Processes 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, All Rights Reserved Day 2, Part 2, Page 179 8/8/2004 If the Plan is Not Feasible DO examine assumptions and data –initial cost estimates are often very conservative Do examine risk/cost tradeoffs to see if you can accept a higher risk Do make a list of barriers that must be removed in order to make the estimate fit the constraints

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 180 8/8/2004 “ The quickest way to make a project uneconomical is by doubling the resources needed and using the cover story that you need to prevent failures.” Adams, The Dilbert Principle “ The quickest way to make a project uneconomical is by doubling the resources needed and using the cover story that you need to prevent failures.” Adams, The Dilbert Principle If the Plan is Not Feasible DO NOT “cave in” & lower everything to meet a target cost or schedule

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 181 8/8/2004 The Negotiation Process We MUST have the lowest bid!!! We will, boss!!! Management will try to trim the budget by sending an army of low-ranking, clueless budget analysts to interview you and ask “insightful” questions. Adams, The Dilbert Principle

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 182 8/8/2004 Re-think key factors Spreadsheet for estimating This will never satisfy the cost goal!???!

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 183 8/8/2004 Identify Opportunities and Barriers Barriers Opportunities to Cut

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 184 8/8/2004 Negotiate If they will cut back on the reviews and... Well, I’ll think about it

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 185 8/8/2004 Beware... Estimates are Never Perfect

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 186 8/8/2004 Estimating Accuracy vs. Phase FeasibilityPlansDesignDetailed Design Code and Test Release Upper Limit Actual Lower Limit Typical Estimates

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 187 8/8/2004 Some Opportunities to Consider Plan to re-estimate after important milestones Prioritize requirements and promise to deliver the top ones by the deadline –Incremental deliveries Put a high cost on requirements changes Look at each “adjustment factor” in Cocomo as an opportunity Get training for everyone

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 188 8/8/2004 Some Typical Barriers to Faster Schedule or Lower Cost Lack of adequate resources –Software, tools, people, etc. Slow approval cycles for required resources Poor coordination with other disciplines, other companies, etc. Customers, peers in other disciplines, and managers who don’t understand software development very well

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 189 8/8/2004 Some Difficult Barriers to Faster Schedule or Lower Cost Irascible and irrational customers & managers Intentional barriers –Competitors, etc –Political constraints

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 190 8/8/2004 Negotiating Tip... The more facts you have, the better off you are during negotiation Get decision makers to review your estimate –Sometimes they don’t bother Be well prepared to explain it

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 191 8/8/2004 Detailed Planning - Processes 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, All Rights Reserved Day 2, Part 2, Page 192 8/8/2004 Several Iterations are Likely That’s why you should use a spreadsheet or an estimation tool! Identify the factors that affect the cost and schedule –Experience levels, stability levels, etc. Examine sensitivity of the results to various factors Examine historical data to make a better picture of probable events Don’t put too much faith in the accuracy of models

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 193 8/8/2004 Summary Effort & Cost Estimation (continued) Effort can be measured in many ways –The specific measurement can have a significant effect on the numbers computed during an estimate Effort and Schedule Length are interdependent –Time and effort can be traded off to some extent, but not completely - there are “infeasible” combinations

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 194 8/8/2004 Effort estimates can be made through historical experience or through models derived from historical experience Beware of averages Cost is derived through several steps The estimating process shown enables you to tie it all together and make updates Summary Effort & Cost Estimation (continued)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 195 8/8/2004 Models are often helpful to estimate effort –All are based on historical experience –All should be calibrated to your specific experience –And validated to be sure that they are right for your application –Most have additional parameters that allow you to “fine tune” to your specifics Summary Effort & Cost Estimation (continued)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 196 8/8/2004 Cocomo is a widely used method that is fairly successful when calibrated to your experience Like most models, Cocomo covers only some of the tasks of software development It is best to use multiple models/ methods to improve the quality of an estimate Summary Effort & Cost Estimation (concluded)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 197 8/8/ Boehm, “Software Engineering Economics”, Prentice-Hall, Boehm, et. al., Cost Models for Future Software Life Cycle Processes: Cocomo 2.0, Technical Report, USC Center for Software Engineering, Draft 2.0, September 6, Brooks, Fred, “The Mythical Man-Month”, 1975 / Conte, S.D., et. al. Software Engineering Metrics and Models. Benjamin Cummings, 1986, p314. References Effort & Cost Estimation

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 198 8/8/ Grady, Robert B. and Deborah L. Caswell, Software Metrics: Establishing a Company- Wide Program. Englewood Cliffs, N.J., Prentice-Hall, Inc., Putnam, Lawrence H., “A General Empirical Solution to the Macro Software Sizing and Estimating Problem,” IEEE Transactions on Software Engineering, July, 1978, p Tausworthe, R.C. Software Specifications Document, DSN Software Cost Model, Jet Propulsion Laboratory, JPL Publication 81-7 (1981). References Effort & Cost Estimation (continued)

Copyright © , Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 199 8/8/2004 Software Development Plan Execute Measure Engineer Quality