Day 2, Part 2 Estimating Software Effort & Cost Section 1 – Fundamental Issues

1. Day 2, Part 2 Estimating Software Effort & CostSection 1 – Fundamental Issues

2. 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. The Overall Planning Cycle Manage Risks Analyze Job Generate Initial Plans Generate Detailed Plans Execute Measure, Manage Productivity and Quality

4. Detailed Planning - Processes Source Information Statement of Work Requirements Constraints Standards Processes History etc. Estimate Effort and Cost Estimate Size WBS Size Effort & Cost Revise & Negotiate Not OK Complete Detailed Planning Evaluate Estimate Schedule Schedule OK

5. Measures of Effort

6. 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. 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. We do 50 LOC per staff month - you do only 40! How do you measure staff months? Two Executives on the Golf Course

9. 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. 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. How Many Days per Month? • 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.)

12. 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. Consistency is the Most Important Factor • If you measure effort consistently, you can understand what it costs, compare different projects, and predict future performance Lines of code per staff month Objects Tested per staff hour

14. 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. We don’t know - we didn’t count unpaid overtime How many hours did you really spend? 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

16. Measure Hours if you Can • 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

17. The Relationship Between Time and Effort

18. 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. 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. Cost of Adding More People Brooks’ Equation for Intercommunication Effort CC = (N * (N-1))/2 Where ... N = Number of people CC = Communication Complexity (extra overhead of managing N people)

21. You Cannot Just AllocatePeople Arbitrarily COCOMO MODEL OF TIME VS EFFORT staff-days required to do the work Optimal Schedule Calendar Time Allocated for the Work

22. The Optimal ScheduleDepends 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. Your Experience Counts More Than Any Model • 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

24. 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. 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. Typical Inputs to the Effort Estimate

27. 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. 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. 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. 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. Estimate Development Costs Then Estimate Other Costs In Other Words ... Estimate Size and Then Effort • Software Development Tasks • requirements • design • code • ... Convert to $ WBS Total Cost Estimate • Other Tasks and Costs • management • travel • training • overhead • facilities • equipment • software • … Estimate Costs Directly or as % of Development Costs

32. 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. Good History Data Good historical data are essential for accurate estimating.

34. Architecture of Spreadsheet Effort Schedules Size / Reuse Software Reuse Analysis Final Effort Estimate Generic Schedule Productivity Based Effort Estimate Effort Schedule Final Size Estimate Historical Size Estimate Model Based Estimate Delphi Size Estimate Other Effort Estimates ... Other Size Estimates ...

35. Effort Estimation with Historical Productivity Data

36. 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. Typical values forProductivity 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. 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. Historical Data (Typical) LOC Developed per Staff-day

40. 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. 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. 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. 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. Statistical Variances and Uncertainties Region of Likely Costs Method 1 True Cost? Method 2 Method 3

45. Beware of Averages • Significant differences in estimates usually mean significant differences in assumptions or facts considered • In such cases, averages may be meaningless X X X X X X X Average is Meaningless

46. 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. x xx x x I assume it will take 3 people for 2 months.

47. Bottom Up Estimating

48. 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. 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. Software for “C” Compiler Build “C” Compiler Build Test Suite Write Documentation Write Installation Software Manage Software Development User Interface File System Parser Code Generator Run Time System Data base I/F Sort Module Command Processor Table Interface Synchro- nizer Error Processor Bert & Sally Joe Joe Mary & Jim Bert Sally Sample Breakdown