1. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 1 4/19/2003 Day 2, Part 2 Estimating Software Effort & Cost Section 1 – Fundamental Issues

2. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 2 4/19/2003 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

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

4. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 4 4/19/2003 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

5. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 5 4/19/2003 Measures of Effort

6. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 6 4/19/2003 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

7. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 7 4/19/2003 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

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

9. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 9 4/19/2003 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

10. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 10 4/19/2003 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.?

11. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 11 4/19/2003 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?

12. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 12 4/19/2003 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

13. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 13 4/19/2003 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

14. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 14 4/19/2003 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

15. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 15 4/19/2003 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

16. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 16 4/19/2003 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

17. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 17 4/19/2003 The Relationship Between Time and Effort

18. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 18 4/19/2003 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

19. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 19 4/19/2003 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

20. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 20 4/19/2003 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

21. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 21 4/19/2003 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

22. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 22 4/19/2003 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

23. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 23 4/19/2003 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

24. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 24 4/19/2003 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

25. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 25 4/19/2003 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)

26. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 26 4/19/2003 Typical Inputs to the Effort Estimate

27. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 27 4/19/2003 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)

28. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 28 4/19/2003 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

29. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 29 4/19/2003 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

30. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 30 4/19/2003 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)

31. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 31 4/19/2003 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

32. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 32 4/19/2003 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

33. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 33 4/19/2003 Good History Data Good historical data are essential for accurate estimating.

34. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 34 4/19/2003 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

35. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 35 4/19/2003 Effort Estimation with Historical Productivity Data

36. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 36 4/19/2003 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

37. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 37 4/19/2003 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.

38. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 38 4/19/2003 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?

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

40. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 40 4/19/2003 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!

41. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 41 4/19/2003 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

42. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 42 4/19/2003 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

43. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 43 4/19/2003 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

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

45. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 45 4/19/2003 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

46. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 46 4/19/2003 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

47. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 47 4/19/2003 Bottom Up Estimating

48. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 48 4/19/2003 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

49. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 49 4/19/2003 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

50. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 50 4/19/2003 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

51. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 51 4/19/2003 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

52. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 52 4/19/2003 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”

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

54. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 54 4/19/2003 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?

55. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 55 4/19/2003 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

56. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 56 4/19/2003 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

57. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 57 4/19/2003 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

58. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 58 4/19/2003 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

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

60. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 60 4/19/2003 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

61. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 61 4/19/2003 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

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

63. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 63 4/19/2003 Typical Generic Schedule for Waterfall Model Lifecycle ProcessSchedule

64. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 64 4/19/2003 Typical Generic Schedule for Incremental Model Lifecycle

65. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 65 4/19/2003 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

66. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 66 4/19/2003 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

67. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 67 4/19/2003 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

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

69. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 69 4/19/2003 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

70. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 70 4/19/2003 Effort Schedule Matrix Equation Effort Schedule Effort Vector Generic Schedule = *

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

72. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 72 4/19/2003 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

73. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 73 4/19/2003 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”

74. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 74 4/19/2003 Typical Final Effort Schedule (Total Effort)

75. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 75 4/19/2003 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

76. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 76 4/19/2003 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.

77. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 77 4/19/2003 Head Count

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

79. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 79 4/19/2003 Typical Head Count Graph Data taken directly from effort schedule

80. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 80 4/19/2003 You Can Track Actuals During Execution

81. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 81 4/19/2003 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

82. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 82 4/19/2003 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

83. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 83 4/19/2003 Revised Effort Schedule

84. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 84 4/19/2003 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

85. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 85 4/19/2003 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

86. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 86 4/19/2003 Cost Schedule

87. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 87 4/19/2003 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)

88. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 88 4/19/2003 A Typical Cost Schedule

89. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 89 4/19/2003 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

90. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 90 4/19/2003 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

91. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 91 4/19/2003 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

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

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

94. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 94 4/19/2003 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

95. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 95 4/19/2003 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

96. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 96 4/19/2003 Developing an Estimation Model

97. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 97 4/19/2003 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

98. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 98 4/19/2003 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

99. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 99 4/19/2003 A Graph of the Model EffortEffort Size Effort = Size * Constant

100. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 100 4/19/2003 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

101. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 101 4/19/2003 Perhaps Something like This Size EffortEffort

102. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 102 4/19/2003 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

103. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 103 4/19/2003 “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

104. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 104 4/19/2003 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

105. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 105 4/19/2003 Economy of Scale (b < 1) Size EffortEffort

106. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 106 4/19/2003 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

107. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 107 4/19/2003 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

108. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 108 4/19/2003 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

109. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 109 4/19/2003 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.

110. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 110 4/19/2003 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

111. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 111 4/19/2003 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)

112. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 112 4/19/2003 Calibrating & Validating a Model

113. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 113 4/19/2003 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?

114. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 114 4/19/2003 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

115. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 115 4/19/2003 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

116. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 116 4/19/2003 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

117. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 117 4/19/2003 Calibrating a Model Estimating Model Your Data Your Experience Your Model Your Insight adjust

118. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 118 4/19/2003 Cost Drivers

119. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 119 4/19/2003 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

120. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 120 4/19/2003 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

121. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 121 4/19/2003 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

122. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 122 4/19/2003 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

123. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 123 4/19/2003 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.

124. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 124 4/19/2003 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

125. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 125 4/19/2003 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

126. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 126 4/19/2003 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

127. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 127 4/19/2003 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

128. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 128 4/19/2003 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?

129. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 129 4/19/2003 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)

130. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 130 4/19/2003 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

131. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 131 4/19/2003 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

132. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 132 4/19/2003 Applying Multiple Cost Drivers Table of Effort Multipliers DriverNormalHighVery High Complexity1.01.151.30 Reliability1.01.151.40 Experience1.0.91.82 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 = 236.6 The table represents your organization’s collective experience of the impact of various factors or cost drivers.

133. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 133 4/19/2003 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

134. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 134 4/19/2003 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!

135. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 135 4/19/2003 Typical Table of Effort Multipliers

136. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 136 4/19/2003 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

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

138. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 138 4/19/2003 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.

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

140. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 140 4/19/2003 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 50-300 KLOC

141. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 141 4/19/2003 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.

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

143. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 143 4/19/2003 Cocomo Tool Information CoCo Pro Available through ICONIX Software Engineering Inc. For more information on CoCoPro: HTTP://WWW.ICONIXSW.COM/ Spec_Sheets/CoCoPro.html For more information on CoCoPro: HTTP://WWW.ICONIXSW.COM/ Spec_Sheets/CoCoPro.html

144. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 144 4/19/2003 Cocomo Tool Information (continued) REVIC - A free tool Available through USAF Cost Analysis Agency SOFTEST - an updated version For more information on REVIC or SOFTEST: http://sepo.nosc.mil/estimation.html For more information on REVIC or SOFTEST: http://sepo.nosc.mil/estimation.html

145. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 145 4/19/2003 Cocomo Tool Information (continued) SOFTCOST-R Available through Resource Calculations Inc. For more information on SOFTCOST-R: http://www.softstarsystems.com For more information on SOFTCOST-R: http://www.softstarsystems.com

146. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 146 4/19/2003 Additional Cocomo II Information Under development at University of Southern California, Cocomo II project. For More Information on Cocomo II: HTTP://SUNSET.USC.EDU/ research/COCOMOII/index.html For More Information on Cocomo II: HTTP://SUNSET.USC.EDU/ research/COCOMOII/index.html

147. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 147 4/19/2003 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

148. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 148 4/19/2003 Other Estimation Models

149. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 149 4/19/2003 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

150. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 150 4/19/2003 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

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

152. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 152 4/19/2003 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, 1978. Size = C k * Effort 1/3 * t 4/3

153. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 153 4/19/2003 SLIM Information EFFORT is for entire life cycle, including maintenance Development Effort =.39 * EFFORT, according to Putnam For more information on SLIM: HTTP://WWW.QSM.COM For more information on SLIM: HTTP://WWW.QSM.COM

154. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 154 4/19/2003 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

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

156. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 156 4/19/2003 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: HTTP://WWW.PRICESYSTEMS.COM For more information on PRICE-S: HTTP://WWW.PRICESYSTEMS.COM

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

158. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 158 4/19/2003 SEER-SEM Additional Information Galorath, Incorporated El Segundo, California 310-414-3222 For more information on SEER-SEM: HTTP://www.galorath.com/ For more information on SEER-SEM: HTTP://www.galorath.com/

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

160. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 160 4/19/2003 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

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

162. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 162 4/19/2003 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

163. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 163 4/19/2003 Compare Results and Judge

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

165. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 165 4/19/2003 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

166. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 166 4/19/2003 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

167. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 167 4/19/2003 You Need to Track ……………… Actuals vs. Estimates

168. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 168 4/19/2003 You Need to Track and Adjust Actuals vs. Estimates

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

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

171. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 171 4/19/2003 Estimating Cost

172. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 172 4/19/2003 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

173. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 173 4/19/2003 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.

174. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 174 4/19/2003 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.

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

176. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 176 4/19/2003 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!!! <<

177. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 177 4/19/2003 Negotiation

178. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 178 4/19/2003 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

179. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 179 4/19/2003 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

180. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 180 4/19/2003 “ 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

181. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 181 4/19/2003 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

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

183. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 183 4/19/2003 Identify Opportunities and Barriers Barriers Opportunities to Cut

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

185. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 185 4/19/2003 Beware... Estimates are Never Perfect

186. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 186 4/19/2003 Estimating Accuracy vs. Phase 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 FeasibilityPlansDesignDetailed Design Code and Test Release Upper Limit Actual Lower Limit Typical Estimates

187. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 187 4/19/2003 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

188. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 188 4/19/2003 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

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

190. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 190 4/19/2003 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

191. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 191 4/19/2003 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

192. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 192 4/19/2003 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

193. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 193 4/19/2003 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

194. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 194 4/19/2003 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)

195. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 195 4/19/2003 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)

196. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 196 4/19/2003 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)

197. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 197 4/19/2003 1. Boehm, “Software Engineering Economics”, Prentice-Hall, 1981. 2. 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, 1994. 3. Brooks, Fred, “The Mythical Man-Month”, 1975 / 1995. 4. Conte, S.D., et. al. Software Engineering Metrics and Models. Benjamin Cummings, 1986, p314. References Effort & Cost Estimation

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

199. Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 199 4/19/2003 Software Development Plan Execute Measure Engineer Quality