Your Plan: Estimation

1. Your Plan: Estimation Instructor: Mike O’Dell This presentations was derived from the textbook used for this class, McConnell, Steve, Rapid Development, Chapter 8, further expanded on by Mr. Tom Rethard for this course.

2. Estimations and Scheduling • Discussion: Case Study 8.1 (pp. 164-165) • Has this ever happened to you (work/school)? • What was the underlying problem? • What should Carl have done? • Estimating the job by: • Seat of the pants, or • A proven, rational process?

3. Overview • The Software-Estimation Story (Synopsis) • Estimation-Process Overview • Size Estimation • Effort Estimation • Schedule Estimation • Ballpark Schedule Estimates • Estimate Refinement

4. The Software Estimation Story* • Software/System development, and thus estimation, is a process of gradual refinement. • Can you build a 3-bedroom house for $100,000? (Answer: It depends!) • Some organizations want cost estimates to within ± 10% before they’ll fund work on requirements definition. (Is this possible?) • Present your estimate as a range instead of a “single point in time” estimate. • The tendency of most developers is to under-estimate and over-commit! * Copyright 2007, Chris Weber, The DSW Group Ltd.

5. Estimate-Convergence Graph Project Cost(effort and size) Project Schedule 4 1.6 2 1.25 High Estimate 1.5 1.15 1.25 1.1 Actual Cost 1.0 1.0 0.8 0.9 0.67 0.85 Low Estimate 0.5 0.8 0.25 0.6 Initialproductdefinition Approvedproductdefinition Requirementsspecification Architecturedesignspecification Detaileddesignspecification Productcomplete

6. Estimation vs. Control • Initially, customers want more than they can afford, something’s gotta give… Initially desired feature set Features Initially desired feature set Resources Product Size/Features Product Size/Features Features Initially available resources Resources Initially available resources Evolution of Project (fixed resources) Evolution of Project (fixed requirements) • Developers and customers must choose between estimation accuracy and project control.

7. Cooperation, Refinement • Explain to stakeholders that you will have better estimates at each project milestone. • You can’t estimate what you don’t know. Estimate too low: costs higher due to planning inefficiencies and mistakes Estimate Convergence Estimate too high: costs higher dueto Parkinson’s law Actual Schedule Minimum actual schedule Actual schedule = Estimated Schedule Estimated Schedule

8. Estimation-Process Overview Step 1: Estimate the size of the product (lines of code or function points) Step 2: Estimate the effort(man-months) Step 3: Estimate the schedule(calendar months) Step 4 (Meta-Step): Provide estimates in ranges and periodically (frequently) refinethe ranges to provide increasing precision as the project progresses

9. Size Estimation • Use an algorithmic approach, that estimates a program’s size from its features • Use size-estimation software • Compare to similar projects in your organization, by pieces. • Software programs and algorithmic approaches should be calibrated to your environment.

10. Estimation tips • Avoid off-the-cuff estimates • Allow time for the estimate (do it right!) • Use data from previous projects • Use developer-based estimates • Estimate by walk-through • Estimate by categories • Estimate at a low-level of detail • Don’t forget/omit common tasks • Use software estimation tools • Use several different techniques, and compare the results • Evolve estimation practices as the project progresses

11. Function-Point Estimation • Based on number of • Inputs(screens, dialogs, controls, messages) • Outputs(screens, reports, graphs, messages) • Inquiries(I/O resulting in a simple, immediate output) • Logical internal files(Major logical groups of end-user data, controlled by program) • External interface files(Files controlled by other programs that this program uses. Includes logical data that enters/leaves program)

12. Function-Point Multipliers Function Points Program Low Medium High Characteristic Complexity Complexity Complexity Number of inputs  3  4  6 Number of outputs  4  5  7 Inquiries  3  4  6 Logical internal files  7  10  15 External interface files  5  7  10 Sum these to get an “unadjusted function-point total” Multiply this by an “influence multiplier” (0.65 to 1.35),based on 14 factors from data communication to ease ofinstallation. All of this gives a total function-point count. Use this with Jones’ First-Order Estimation Practice, orcompare to previous projects for an estimate

13. Jones First-Order Estimate: Influence Multipliers

14. Effort Estimation • Use estimation software to create an effort estimate directly from size estimate • Use McConnell’s schedule tables (Tables 8-8 through 8-10) • Use your organization's historical data • Use algorithmic approach (COCOMO, Putnam)

15. Schedule Estimation • Rule-of-thumb equation • schedule in months = 3.0 * man-months 1/3 This equation implies an optimal team size. • Use estimation software to compute the schedule from your size and effort estimates • Use historical data from your organization • Use McConnell’s Tables 8-8 through 8-10 to look up a schedule estimate based on the size estimate • Use the schedule estimation step from one of the algorithmic approaches (e.g., COCOMO) to get a more fine tunes estimate than the “Rule of thumb” equation.

16. Jones’ First-Order Estimation Kind of Software Best in Class Average Worst in Class Systems 0.430.450.48 Business 0.41 0.430.46 Shrink-wrap 0.39 0.42 0.45 Organization’s Skills/Abilities Take the function-point total and raise it to the appropriate power. Example: 350 function points average shrink-wrap development organization 3500.42 12 calendar months This method works well for quick reality checks. (No magic!)

17. Ballpark Schedule Estimates • Usable, concrete information is either: • embedded in expensive software-estimation systems • in books with dozens of equations and multipliers • McConnell’s tables describe • systems software • business software • shrink-wrap software • Size in lines of code • Accuracy of McConnell’s tables… better than seat of the pants, but should be validated.

18. Shortest Possible Schedule Probability of Completing Exactly on the Scheduled Date Table 8.8High Risk of late completion. Shortest possible schedule Scheduled Completion Date Impossibleschedule • This tables assumes: - Top 10% of talent pool, all motivated, no turnover - entire staff starts working on Day 1, & continue until project released - advanced tools available to everyone - most time-efficient development methods used - requirements completely known, and do not change

19. Efficient Schedules (Table 8-9) • This table assumes: • Top 25% of talent pool • Turnover < 6% per year • No significant personnel conflicts • Using efficient development practices from Chap 1-5 • Note that less effort required on efficient schedule tables • For most projects, the efficient schedules represent “best-case”

20. Nominal Schedules (Table 8-10) • This table assumes: • Top 50% of talent pool • Turnover 10-12% per year • Risk-management less than ideal • Office environment only adequate • Sporadic use of efficient development practices • Achieving nominal schedule may be a 50/50 bet.

21. Estimate Presentation Styles • Plus-or-minus qualifiers “6 months, +3 months, -2 months” • Ranges “5-9 months” • Risk quantification “6 months... +1 month for late subcontractor, +0.5 month for staff sickness, etc...” • Cases Best case April 1 Planned case May 15 Current case May 30 Worst case July 15 • Coarse dates and time periods “3rd quarter 97” • Confidence factors April 1 5% May 15 50% July 1 95%

22. Schedule Estimation - Example • Software Project Size and Productivity Approach Low SideHigh Side (Aggressive)(Conservative) Size Estimate 10000 LOC 30000 LOC Productivity 400 LOC/PM 200 LOC/PM Effort 25 PM 150 PM Duration 5 months30 months (5 person team) • McConnell Table 8-10 (p. 196), Nominal Schedule, System Product Duration 10 months16 months

23. Schedule Estimation - Example • Rule of Thumb (Duration = 3 x PM1/3) Low SideHigh Side (Aggressive)(Conservative) 3 x 251/3 = 3 x 1501/3 = Duration 8.8 (9) months 15.9 (16) months • Function Points, with Jones’s First Order Schedule Estimation (Medium complexity project – Table 8-2) # FnPts Inputs 10 40 Outputs 5 25 Inquiries 10 40 Logical Int. Files 30 30 Logical Ext. Files 2 14 149 (unadj.) Use Influence Multiplier of 1.2 Therefore: 1.2 x 149  180 adjusted fn points Assuming Nominal Skills, System Product, Jones’s First Order says: Duration = 180.45 = 10.35 months

24. Schedule Estimation - Example • Basic CoCoMo81 Estimation Coefficients, based on project type/complexity: • CoCoMo81 – nominal, semi-detached Low SideHigh Side (Aggressive)(Conservative) Effort - PM E = 3.0(10)1.12 E = 3.0(30)1.12 E = a(SLOC)b = 68.45 PM = 135.36 PM Duration – months E = 2.5(69).35 E = 2.5(136).35 D = c(E)d = 11 months= 14 months Note: Also try CoCoMo-II

25. Schedule Estimation - Example • Comparing AggressiveConservative Size and Productivity 5 months 30 months McConnell Tables 10 months 16 months Rule of Thumb 9 months 16 months CoCoMo 11 months 14 months Function Points/Jones’s 10.35 months • Sanity Test (Weiss & Wysocki, 1992) E = (O + 4M + P) / 6, where O = optimistic, M = Nominal, P = Pessimistic Therefore, our E = (5 + 44 + 30) / 6 = 79/6 = 13.17 (14) months

26. Schedule Estimation - Example • Simplified Hybrid Approach • Estimate size using Adjusted Function Point total and Source Lines-Of-Code per Function Point • Estimate effort using Simplified CoCoMo (1.4 x KSLOC) • Estimate time to completion using Rule-of-Thumb

27. Schedule Estimation - Example • Lines-of-Code per Function Point* *Source: Capers Jones, Software Productivity Research

28. Schedule Estimation - Example • Our Example • Size: Adjusted Function Points x SLOC/Function Point, assuming C++ 180 x 50 = 9000 SLOC • Effort: 1.4 x KSLOC = 1.4 x 9 = 13.5 • Time: 3.0 x 13.51/3 = 7.14 months

29. Estimate Refinement • Estimate can be refined only with a more refined definition of the software product • Developers often let themselves get trapped by a “single-point” estimate, and are held to it (Case study 8-1) • Impression of a slip over budget is created when the estimate increases • When estimate ranges decrease as the project progresses, customer confidence is built-up.

30. Estimate Refinement • Discussion: Case Study 8-2 • Contrast this with Case Study 8-1 • What was done right, up front • How often, and when was the estimate refined? • What was the result?

31. Recommendations • Do not depend on a single cost or schedule estimate. • Use several estimating techniques or cost models, compare the results, and determine the reasons for any large variations. • Document the assumptions made when making the estimates. • Monitor the project to detect when assumptions that turn out to be wrong jeopardize the accuracy of the estimate. • Maintain a historical database

32. Conclusions • Estimate accuracy is directly proportional to product definition. • Before requirements specification, product is very vaguely defined • More effort, variety of approaches/methods used in estimating = better estimates. • Use ranges for estimates and gradually refine (tighten) them as the project progresses. • Measure progress and compare to your historical data • Refine… Refine… Refine!!!