CSE Senior Design I Your Plan: Estimation Instructor: Vassilis Athitsos This presentation 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, and further modified by Mr. Mike O'Dell and Vassilis Athitsos. 1 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? 2 1 Overview The Software-Estimation Story (Synopsis) Estimation-Process Overview Size Estimation Effort Estimation Schedule Estimation Ballpark Schedule Estimates Estimate Refinement 3 1 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, The DSW Group Ltd. 4 1 Estimate-Convergence Graph Project Cost (effort and size) Project Schedule 1.6 4 2 1.25 1.5 1.15 1.25 1.0 0.8 1.1 1.0 0.9 0.67 0.85 0.5 0.8 0.25 Initial product definition Approved Requirements Architecture Detailed product specification design design definition specification specification 0.6 Product complete 5 1 Estimation vs. Control Initially desired feature set Features Resources Initially available resources Evolution of Project (fixed resources) Initially desired feature set Features Product Size/Features Product Size/Features Initially, customers want more than they can afford, something’s gotta give… Resources Initially available resources Evolution of Project (fixed requirements) Developers and customers must choose between estimation accuracy and project control. 6 1 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 Estimated Schedule 7 1 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 1 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 1 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 1 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 1 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 1 Jones First-Order Estimate: Influence Multipliers General System Characteristic Brief Description 2. How many communication facilities are there to aid in the transfer or exchange of information with the application or system? Distributed data processing How are distributed data and processing functions handled? 3. Performance 4. Heavily used configuration 5. Transaction rate Was response time or throughput required by the user? How heavily used is the current hardware platform where the application will be executed? 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 13. Multiple sites 14. Facilitate change How effective and/or automated are start-up, back-up, and recovery procedures? 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? 1. Data communications 13 1 Effort Estimation Use estimation software to create an effort estimate directly from size estimate Use McConnell’s schedule tables (Tables 88 through 8-10) Use your organization's historical data Use algorithmic approach (COCOMO, Putnam) 14 1 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. 15 1 Jones’ First-Order Estimation Kind of Software Systems Business Shrink-wrap Organization’s Skills/Abilities Best in Class Average Worst in Class 0.43 0.45 0.48 0.41 0.43 0.46 0.39 0.42 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 1 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. 17 1 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 1 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 1 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 1 Estimate Presentation Styles Plus-or-minus qualifiers “6 months, +3 months, -2 months” Ranges “5-9 months” Risk quantification Cases Best case Planned case Current case Worst case April 1 May 15 May 30 July 15 Coarse dates and time periods “6 months... +1 month for late “3rd quarter 97” subcontractor, +0.5 month for staff sickness, Confidence factors etc...” April 1 5% May 15 50% July 1 95% 21 1 Schedule Estimation - Example Software Project Size and Productivity Approach Low Side High Side (Aggressive) (Conservative) Size Estimate Productivity Effort Duration (5 person team) 10000 LOC 30000 LOC 400 LOC/PM 200 LOC/PM 25 PM 150 PM 5 months 30 months McConnell Table 8-10 (p. 196), Nominal Schedule, System Product Duration 10 months 16 months 22 1 Schedule Estimation - Example Rule of Thumb (Duration = 3 x PM1/3) Low Side (Aggressive) 3 x 251/3 = 8.8 (9) months Duration High Side (Conservative) 3 x 1501/3 = 15.9 (16) months Function Points, with Jones’s First Order Schedule Estimation (Medium complexity project – Table 8-2) # FnPts Use Influence Multiplier of 1.2 Inputs 10 40 Outputs 5 25 Inquiries 10 40 Logical Int. Files 30 30 Assuming Nominal Skills, System Product, Jones’s First Order says: Logical Ext. Files 2 14 Duration = 180.45 = 10.35 months Therefore: 1.2 x 149 180 adjusted fn points 149 (unadj.) 23 1 Schedule Estimation - Example Basic CoCoMo 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 CoCoMo – nominal, semi-detached Low Side (Aggressive) High Side (Conservative) Effort - PM E = a(SLOC)b E = 3.0(10)1.12 = 68.45 PM E = 3.0(30)1.12 = 135.36 PM Duration – months D = c(E)d E = 2.5(69).35 = 11 months E = 2.5(136).35 = 14 months 24 1 Schedule Estimation - Example Comparing Size and Productivity McConnell Tables Rule of Thumb CoCoMo Function Points/Jones’s Aggressive Conservative 5 months 30 months 10 months 16 months 9 months 16 months 11 months 14 months 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 25 1 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. 26 1 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 28 1 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!!! 29