1. CSE Senior Design I 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. 1 2 Estimations and Scheduling  Discussion: Case Study 8.1 (pp. 163-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. 1 3 Overview  The Software-Estimation Story (Synopsis)  Estimation-Process Overview  Size Estimation  Effort Estimation  Schedule Estimation  Ballpark Schedule Estimates  Estimate Refinement

4. 1 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?) range  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, The DSW Group Ltd.

5. 1 5 Estimate-Convergence Graph Initial product definition Approved product definition Requirements specification Architecture design specification Detailed design specification Product complete 1.0  0.25  44 22 0.5  1.5  0.67  1.25  0.8  1.0  0.6  1.6  1.25  0.8  1.15  0.85  1.1  0.9  Project Cost (effort and size) Project Schedule High Estimate Low Estimate

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

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

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

9. 1 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. 1 10 Estimation tips  Avoid off-the-cuff  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. 1 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. 1 12 Function-Point Multipliers Function Points ProgramLowMediumHigh CharacteristicComplexityComplexityComplexity 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 of installation. All of this gives a total function-point count. Use this with Jones’ First-Order Estimation Practice, or compare to previous projects for an estimate

13. 1 Jones First-Order Estimate: Influence Multipliers General System Characteristic Brief Description 1.Data communications How many communication facilities are there to aid in the transfer or exchange of information with the application or system? 2.Distributed data processingHow are distributed data and processing functions handled? 3.PerformanceWas response time or throughput required by the user? 4.Heavily used configuration How heavily used is the current hardware platform where the application will be executed? 5.Transaction rateHow frequently are transactions executed daily, weekly, monthly, etc.? 6.On-Line data entryWhat percentage of the information is entered On-Line? 7.End-user efficiencyWas the application designed for end-user efficiency? 8.On-Line updateHow many ILF’s are updated by On-Line transaction? 9.Complex processingDoes the application have extensive logical or mathematical processing? 10.ReusabilityWas the application developed to meet one or many user’s needs? 11.Installation easeHow difficult is conversion and installation? 12.Operational easeHow effective and/or automated are start-up, back-up, and recovery procedures? 13.Multiple sites Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations? 14.Facilitate change Was the application specifically designed, developed, and supported to facilitate change? 13

14. 1 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. 1 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. 1 16 Jones’ First-Order Estimation Kind of Software Best in Class Average Worst in Class Systems0.430.450.48 Business0.410.430.46 Shrink-wrap0.390.420.45 Take the function-point total and raise it to the appropriate power. Example: 350 function points average shrink-wrap development organization 350 0.42  12 calendar months This method works well for quick reality checks. (No magic!) Organization’s Skills/Abilities

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

18. 1 18 Shortest Possible Schedule Probability of Completing Exactly on the Scheduled Date Scheduled Completion Date Shortest possible schedule Impossible schedule 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 Table 8.8 High Risk of late completion.

19. 1 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. 1 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. 1 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 caseApril 1 Planned caseMay 15 Current caseMay 30 Worst caseJuly 15  Coarse dates and time periods “3rd quarter 97”  Confidence factors April 15% May 1550% July 195%

22. 1 22 Schedule Estimation - Example  Software Project Size and Productivity Approach Low SideHigh Side (Aggressive)(Conservative) Size Estimate10000 LOC30000 LOC Productivity400 LOC/PM200 LOC/PM Effort25 PM150 PM Duration 5 months30 months (5 person team)  McConnell Table 8-10 (p. 196), Nominal Schedule, System Product Duration10 months16 months

23. 1 23 Schedule Estimation - Example  Rule of Thumb (Duration = 3 x PM 1/3 ) Low SideHigh Side (Aggressive)(Conservative) 3 x 25 1/3 =3 x 150 1/3 = Duration 8.8 (  9) months15.9 (  16) months # FnPts Inputs1040 Outputs525 Inquiries1040 Logical Int. Files3030 Logical Ext. Files214 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  Function Points, with Jones’s First Order Schedule Estimation (Medium complexity project – Table 8-2)

24. 1 24 Schedule Estimation - Example  Basic CoCoMo Estimation Coefficients, based on project type/complexity:  CoCoMo – nominal, semi-detached Low SideHigh Side (Aggressive)(Conservative) Effort - PME = 3.0(10) 1.12 E = 3.0(30) 1.12 E = a(SLOC) b = 68.45 PM= 135.36 PM Duration – monthsE = 2.5(69).35 E = 2.5(136).35 D = c(E) d = 11 months= 14 months Coefficientabcd Organic2.41.052.50.38 Semi-detached3.01.122.50.35 Embedded3.61.202.50.32

25. 1 25 Schedule Estimation - Example  Comparing AggressiveConservative Size and Productivity5 months30 months McConnell Tables10 months16 months Rule of Thumb9 months16 months CoCoMo11 months14 months Function Points/Jones’s10.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. 1 26 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 1-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.

27. 1 27 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?

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

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