CSE Senior Design I Your Plan Estimation Instructor

CSE Senior Design I Your Plan: Estimation Instructor: Manfred Huber This presentations was derived from the textbook used for this class, Mc. Connell, Steve, Rapid Development, Chapter 8, further expanded on by Mike O’ O’Dell and Mr. Tom Rethard for this course.

3 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? 2

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

3 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 underestimate and over-commit! * Copyright 2007, Chris Weber, The DSW Group Ltd. 4

3 Estimate-Convergence Graph Project Cost (effort and size) Project Schedule 1. 6 4 Hig h. E stim ate 2 1. 5 1. 25 1. 0 0. 8 0. 67 Actual Cost 0. 5 0. 25 Initial product definition Low ate m i t Es Approved Requirements Architecture Detailed product specification design definition specification 1. 25 1. 1 1. 0 0. 9 0. 85 0. 8 0. 6 Product complete 5

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

3 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 Convergence Estimate too low: costs higher due to planning inefficiencies and mistakes Actual Schedule Estimate too high: costs higher due to Parkinson’s law Minimum actual schedule Actual schedule = Estimated Schedule 7

3 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) refine the ranges to provide increasing precision as the project progresses 8

3 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. 9

3 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 10

3 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) 11

3 Function-Point Multipliers Program Characteristic Number of inputs Number of outputs Inquiries Logical internal files External interface files Low Complexity 3 4 3 7 5 Function Points Medium Complexity 4 5 4 10 7 High Complexity 6 7 6 15 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 12

3 Jones First-Order Estimate: Influence Multipliers General System Characteristic Brief Description How many communication facilities are there to aid in the transfer or exchange of information with the application or system? 1. Data communications 2. Distributed data processing How are distributed data and processing functions handled? 3. Performance Was 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 rate How frequently are transactions executed daily, weekly, monthly, etc. ? 6. On-Line data entry What percentage of the information is entered On-Line? 7. End-user efficiency Was the application designed for end-user efficiency? 8. On-Line update How many ILF’s are updated by On-Line transaction? 9. Complex processing Does the application have extensive logical or mathematical processing? 10. Reusability Was the application developed to meet one or many user’s needs? 11. Installation ease How difficult is conversion and installation? 12. Operational ease How effective and/or automated are start-up, back-up, and recovery procedures? 13. Multiple sites 14. Facilitate change Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations? Was the application specifically designed, developed, and supported to facilitate change? 13

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

3 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 Mc. Connell’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. 15

3 Jones’ First-Order Estimation Organization’s Skills/Abilities Kind of Software Systems Business Shrink-wrap Best in Class 0. 43 0. 41 0. 39 Average 0. 45 0. 43 0. 42 Worst in Class 0. 48 0. 46 0. 45 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!) 16

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

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

3 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” 19

3 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. 20

3 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 Planned case Current case Worst case April 1 May 15 May 30 July 15 Ø Coarse dates and time periods “ 3 rd quarter 97” Ø Confidence factors April 1 May 15 July 1 5% 50% 95% 21

3 Schedule Estimation - Example Ø Software Project Size and Productivity Approach Low Side High Side (Aggressive) (Conservative) Size Estimate 10000 LOC 30000 LOC Productivity 400 LOC/PM 200 LOC/PM Effort 25 PM 150 PM Duration 5 months (5 person team) 30 months Ø Mc. Connell Table 8 -10 (p. 196), Nominal Schedule, System Product Duration 10 months 16 months 22

3 Schedule Estimation - Example Ø Rule of Thumb (Duration = 3 x PM 1/3) Low Side High 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) # Fn. Pts Use Influence Multiplier of 1. 2 Inputs 10 40 Therefore: Outputs 5 25 1. 2 x 149 180 adjusted fn points Inquiries 10 40 Logical Int. Files 30 30 Assuming Nominal Skills, System Product, Jones’s First Order says: Logical Ext. Files 14 2 149 Duration = 180. 45 = 10. 35 months 23

3 Schedule Estimation - Example ØBasic Co. Mo 81 Estimation Coefficients, based on project type/complexity: Coefficient a b c d Organic 2. 4 1. 05 2. 5 0. 38 Semi-detached 3. 0 1. 12 2. 5 0. 35 Embedded 3. 6 1. 20 2. 5 0. 32 ØCo. Mo 81 – nominal, semi-detached Low Side High Side (Aggressive) (Conservative) Effort - PM E = a(SLOC)b E = 3. 0(10)1. 12 E = 3. 0(30)1. 12 = 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 Co. Mo-II 24

3 Schedule Estimation - Example Ø Comparing Aggressive Conservative Size and Productivity 5 months 30 months Mc. Connell Tables 10 months 16 months Rule of Thumb 9 months 16 months Co. Mo 11 months 14 months Function Points/Jones’s 10. 35 months Ø Sanity Test (Weiss & Wysocki, 1992) E = (O + 4 M + P) / 6, where O = optimistic, M = Nominal, P = Pessimistic Therefore, our E = (5 + 44 + 30) / 6 = 79/6 = 13. 17 (14) months 25

3 Schedule Estimation - Example Ø Simplified Hybrid Approach 1. Estimate size using Adjusted Function Point total and Source Lines-Of-Code per Function Point 2. Estimate effort using Simplified Co. Mo (1. 4 x KSLOC) 3. Estimate time to completion using Rule-of-Thumb 26

3 Schedule Estimation - Example Ø Lines-of-Code per Function Point* Language Approximate LOC/Function Point C 130 Java 55 C++ 50 Visual Basic 30 Power Builder 15 HTML 15 Package, e. g. Excel, Access, … 10 -40 *Source: Capers Jones, Software Productivity Research 27

3 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 28

3 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. 29

3 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? 30

3 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 31

3 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 32