1 / 23

Project Estimation

Project Estimation. Paul Sorenson Department of Computing Science University of Alberta. CMPUT 402 Software Engineering. Topic Overview. The “Bad News” Why is project estimation difficult? What can be done about? Some approaches. Practical estimation COCOMO Model. How many LOC?.

thad
Download Presentation

Project Estimation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project Estimation Paul Sorenson Department of Computing Science University of Alberta CMPUT 402 Software Engineering CMPUT 402 - Project Estimation

  2. Topic Overview • The “Bad News” • Why is project estimation difficult? • What can be done about? Some approaches. • Practical estimation • COCOMO Model CMPUT 402 - Project Estimation

  3. How many LOC? // Initialize the OLE librarieshRslt = CoInitializeEx(NULL, COINIT_MULTITHREADED);if (SUCCEEDED(hRslt)) { hRslt = CreateFileMoniker(wcsPath, &pmk); if (SUCCEEDED(hRslt)) hRslt = BindMoniker(pmk, 0, IID_IHello, (void **)&pHello); if (SUCCEEDED(hRslt)) { // print a string out pHello->PrintSz(wcsT); Sleep(2000); ulCnt = pHello->Release(); } else printf("Failure to connect, status: %lx", hRslt); // Tell OLE we are going away. CoUninitialize(); }return(0); CMPUT 402 - Project Estimation

  4. How good/bad are we? US DOD Sustaining Base Information Services (SBIS) Program Example (source Scientific Am. Apr’96) • 10 year project to replace 3,700 automated applications with 1,500 new applications by the year 2002. • Decided to split it into phases - 1st phase was common infrastructure plus 89 applications • IBM won contract with bid of $474M but were soon dropped for non-delivery • After investing $158M in first three years not on single replacement system was delivered. • Latest estimate for a reduced 1st phase is $1.4B with only 19 of 89 systems - uncertain if 2002 date can be met. CMPUT 402 - Project Estimation

  5. More Bad News A Standish Group survey of 8,000 software projects in the mid-’90s found that the average project exceeded its planned budget by 90 percent and its schedule by 120 percent. Several industry studies have reported that fewer than half of software projects finish within their allotted schedules and budgets. CMPUT 402 - Project Estimation

  6. Reasons for Runaway Projects • A study conducted by KPMG Pete Marwick found these • causes of software runaways: • Project Objectives Not Fully Specified (51%) • Bad Planning and Estimating (48%) • Technology New to the Organization (45%) • Inadequate/No Project Management Methodology (42%) • Insufficient Senior Staff on the Team (42%) • Poor Performance by Suppliers of Hardware/Software (42%) CMPUT 402 - Project Estimation

  7. Why is it so difficult? CMPUT 402 - Project Estimation

  8. It’s difficult because . . . • We often begin with a fuzzy picturepoor set of requirements? • Software development is then a gradual process of refinements of requirements. an estimate can come into focus only along with the software itself • Yet, in the face of existing evidence, some companies want cost estimates to within  10%. CMPUT 402 - Project Estimation

  9. Requirements? • Design? • Implementation? • Testing? • Deployment? • Personnel? • Technology? • Others? Examples of uncertainty at each phase and elsewhere . . . Fuzziness Arch. knowledge/preferences Language and develop. envir. Extensiveness (was quality built in?) User acceptance Experience & expertise (10:1 factor) Multi-platform or not CMPUT 402 - Project Estimation

  10. Req. Defn Accept. Testing Arch. Design Integration Testing Detailed Design Unit Testing V - Modelfor System Development Implementation CMPUT 402 - Project Estimation

  11. Common Estimation Methods • Decomposition techniques - project is decomposed into tasks until an estimate for each task can be made. • Empirical models for the estimation using past experience to predict cost and effort. • Automated estimation tools that use a combination of decomposition and empirical models, but develop the estimates automatically from project information. CMPUT 402 - Project Estimation

  12. Estimation through Refinement Project Cost (effort and size) Project Schedule 4x 2x 1.5x 1.25x 1.0x 0.8x 0.67x 0.5x 0.25x 1.6x 1.25x 1.15x 1.10x 1.0x 0.9x 0.85x 0.8x 0.6x Estimate-convergence graph Initial Prod Defn Approved Prod Defn Product D. Specs Detailed D. Specs Req. Specs Product Complete CMPUT 402 - Project Estimation

  13. Estimation vs Control Product Size Product Size Initial desired feature set Initial desired feature set Features Resources Features Resources Initial available resources Initial available resources Evolution of Product Evolution of Product CMPUT 402 - Project Estimation

  14. actual schedule = estimated schedule Actual Schedule minimum actual schedule Estimated Schedule Cooperation & Covergence • Help customers by telling the parts you are able to estimate accurately • Tell customers you will refine estimates at the end of various phases. • Estimates too low planning inefficiencies which drive costs up • Estimates too high Parkinson’s law drives up actual costs. Estimate too high Estimate too low CMPUT 402 - Project Estimation

  15. Estimation Process Overview Three Steps: • Estimate size of the product (LOC, function points and/or history of similar projects) • Estimate the effort (person months) • Estimate the schedule (calendar months). CMPUT 402 - Project Estimation

  16. Program Characteristic Low Complexity Medium Complex High Complex Total 44 53 32 100 65 2 =8 3 =18 Number of inputs Number of outputs Number of inquiries Logical internal files External interface files 6 =18 7 =35 0 =0 7 =28 2 =8 4 =24 0 =0 2 =20 3 =45 5 =35 0 =0 2 =20 9 =45 304 1.15 350 Unadjusted function-point total Influence multiplier Adjusted function-point total Function Point Size Estimation • championed by Caper Jones *4 *5 *4 *10 *7 *6 *7 *6 *15 *10 *3 *4 *3 *7 *5 CMPUT 402 - Project Estimation

  17. Good Estimation Practices • Avoid off-the-cuff estimates - pressure from management • Allow time for estimating and plan for it. • Use historical data. (Whose data?) • Use developer-based estimates. • Estimate by walk-through • Estimate by category • Estimate at a low level of detail • Include common tasks -e.g. cut-over, client demos • Use estimation tools (if their good) • Use several techniques - LOC, function-points, 1st order • Change estimation practice as project proceeds- bounded historical at project defn, - COCOMO at requirements defn - module level estimates at architectural design CMPUT 402 - Project Estimation

  18. Presenting Estimates E.g., Risk-Quantification Estimates Estimate: 8 months, +3 months, -2 months +1 month for late delivery of database system +1 month for new CASE tools not working as planned +0.5 months for staff unexpected staff leaves and sicknesses +0.5 months for underestimating size -1 month for less delay in hiring -1 month for new CASE tools working better than planned CMPUT 402 - Project Estimation

  19. Case-Based Estimate Confidence Factor 20% 75% 95% Case Best case Current case Worst case Estimate December 10 January 15 February 22 CMPUT 402 - Project Estimation

  20. Sched. 6 9 15 22 30 Effort 25 110 540 1650 3900 Sched. 3.5 5.5 9 13 17 Effort 5 22 110 330 780 Sched. 4.2 7 11 15 20 Effort 8 37 190 580 1400 Effort Estimation • Caper Jone’s 1st order estimation practices • Boehm’s empirical validation tables for shortest possible schedules System ProductsBusiness ProductsShrink-Wrap Product System Size 10,000 30,000 100,000 250,000 500,000 • COCOMO CMPUT 402 - Project Estimation

  21. COCOMO -COnstructive COst MOdel • Screen-oriented, interactive software package and model (COCOMO II) that assists in budgetary planning and schedule estimation of a software development project. (Model base on his book Software Engineering Economics) • The model is based on two general set of cost drivers:- Early Design - Post Architecture CMPUT 402 - Project Estimation

  22. COCOMO -COnstructive COst MOdel • Early Design Cost Drivers (7) • Personnel Capability (PERS) • Product Reliability and Complexity (RCPX) • Required Reuse (RUSE) • Platform Difficulty (PDIF) • Personnel Experience (PREX) • Facilities (FCIL) • Schedule (SCED) CMPUT 402 - Project Estimation

  23. COCOMO -COnstructive COst MOdel • Post-Architecture • Product Factors (5) -Required Software Reliability (RELY) • - Data Base Size (DATA) • - Product Complexity (CPLX) • - Required Reusability (RUSE) • - Documentation match to life-cycle needs (DOCU) • Personnel Factors (6) • - Analyst Capability (ACAP) • - Programmer Capability (PCAP) • - Applications Experience (AEXP) • - Platform Experience (PEXP) • - Language and Tool Experience • (LTEX) • - Personnel Continuity (PCON) • Project Factors(3) • - Use of Software Tools (TOOL) • - Multisite Development (SITE) • - Required Development Schedule (SCED) • Platform Factors (3) - Execution Time Constraint (TIME) • - Main Storage Constraint (STOR) • - Platform Volatility (PVOL) CMPUT 402 - Project Estimation

More Related