1 / 38

Software Project Estimation

Software Project Estimation. Jerrid Gimenez Feb. 7, 2013. Software Estimation: What.

may-ratliff
Télécharger la présentation

Software 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. Software Project Estimation Jerrid Gimenez Feb. 7, 2013

  2. Software Estimation: What Software Estimation – “estimation of the software size, development effort, software development cost, and software development schedule for a specified project in a specified environment, using defined methods, tools, and techniques” -MuraliChemuturi Author: Software Estimation Best Practices, Tools & Techniques

  3. SE: What - Cont. • What do we get out of the estimate? • Components • Size • Effort needed • Cost • Time • Risk • Data for future improvements

  4. Software Estimation: Who • Recommended: Project Lead • Person responsible for completion of estimated task • Often: You!

  5. Software Estimation: Why • Estimation gives the Customer: • Budget • “Quote” to compare with • Estimation gives the Supplier: • Budget • chance to evaluate the risks/rewards of a project • way to keep track of progress • Why is this Important to You? • It will be a part of our job as Software Engineers!

  6. Software Estimation: When • Before Development • When project is acquired from customer • Following project Approval for internal projects. • During Development • Decreases Uncertainty(See Uncertainty Later…) • Estimating… After Development? • Not as common - but very beneficial • Compare actual cost size time to estimated values • Improves knowledge for future estimations

  7. The Challenges • Many variables • Sizing • Development Environment • Support Environment • Staff (how much/how talented)

  8. Challenges: Size Estimation • Not done as often as Estimating Effort. • Why do we do it? • Drives Scheduling and Cost Estimations • Size -> Effort -> Cost • How do we size Software?

  9. Sizing – cont. Experiment: How many lines of code(LOC)? //Function Population(string town) returns count of //people in personList who live in the input town Public int Population(string town) { int count = 0; for(inti = 0; i < personList.length(); i++) if(personList[i].Town == town) count++; return count; }

  10. Size Estimation: Lines of Code • Orginal method of estimating size • Program Size = LOC needed for functionality • How many LOC from the experiment? • The world may never know…

  11. Calculating the LOC Estimate Alternative – Average between Min. and Max. LOC

  12. LOC Pros / Cons • Pros • Beneficial for Real Time/Embedded Applications • Can be used to create Historical data for future estimates • Easy to count • Cons • No defined “Line” • Doesn’t promote code optimizations

  13. Size Estimation: Function Points • What are they? • Points used to quantify functionality given to the user • Most popular size measure • Developed late 1970’s – Allan J. Albrecht of IBM • International Function Point Users Group • Maintains FP standards • Certifications • Training

  14. Function Points – cont. • Function Point Analysis Counts: • External Inputs • External Outputs • External Inquiry • Internal Logical File • External Interface File • Each has 3 complexity possibilities to come up with FP count

  15. Function Points – Pros / Cons • Pros: • Very well defined • Benchmarking • Used to show Productivity • Cons: • Not Intuitive • Must train / find well trained counters • Need user perspective

  16. Estimating the Effort Person Hours/Months/[Unit of time] Derives Schedule, Cost…

  17. Methods: Analogy • How it’s done: • Use knowledge of previous projects to come up with estimates • What is needed for success: • Company must keep records • Similar Projects must have been made

  18. Analogy – cont. • Parameters for Analyzing • Project Type • Full life cycle • Implementation • Conversion • Port • Migration • Client Information • Application Domain • Size of client’s organization • Number of client locations • Development Platform

  19. Analogy: Strengths / Weaknesses • Strengths: • Reliable • Inuitive • Estimation Data can be purchased • Weaknesses • Poor Record Keeping = bad estimates • Not the best for new organizations • Time consuming

  20. Methods: Expert Judgment(Delphi) • How it’s done: • Work with Subject Matter Experts (SMEs) to formulate estimates • If a small team of SMEs is used, a common estimate is derived. • Works well because: • No historical data needed • If proper SME is chosen - Extremely accurate • Quick • Inaccurate because: • SME can be biased / inconsistent / overconfident

  21. Delphi: Converging Estimates • Expert Estimates must be Converged • Simple average • Swap extremes

  22. Methods: Activity and Work Decomposition

  23. Activity and Work Decomposition – cont. • How it’s done: • Outline the needed tasks involved for the project • Should be done by person who ensures the tasks are accomplished. • Use knowledge of needed work and skill set of the implementers to derive time estimates. • Pros: • Estimator is knowledgeable of the work at hand • No explicit sizing such as Lines of Code count is needed • Limitations: • Subjective – accuracy is up to the estimator’s opinion • No sizing

  24. Methods: Top-Down • How it’s done: • Decomposition of system into smaller components • Works well because: • Estimates are linked to requirements • Inaccurate when: • Good requirements aren’t available • Bias may lead to underestimation

  25. Methods: Bottom-Up • How it’s done: • Individuals evaluate each component of the entire system. • Sum to formulate project estimate • Works well because: • Can be very accurate – detailed • Builds responsibility • Issues: • Time consuming process • Details may not be available • Bias can lead to underestimation • Can miss integration costs

  26. Methods: Design to Cost • How it’s done: • Work with SMEs to find out how much we can give the customer for given budget • Works well because: • The price is right! • Issues: • Need knowledge of functionality cost

  27. Methods: Parametric Models • How it’s done: • Estimate by use of design parameters and mathematic formulas • Works well because: • Fast • Ease of use • Can be re-useable • Issues: • Models need to “fit the bill” • Can end up being very inaccurate through poor choice of parameters

  28. Parametric Method: COCOMO • Developed by: Dr. Barry Boehm • Studied historical data • 63 projects: 2,000 – 100,000 LOC • Large following • 3 Types: • Basic • Intermediate • Product Attributes • Hardware Attributes • Personnel Attributes • Project Attributes • Advanced • Intermediate + Phase approach

  29. Basic COCOMO • 3 Classes of Projects Used for Formula • Organic • Small team • More experienced • Less rigid requirements / constraints • Semi-detached • Mixed teams / experiences • Mixed rigidity of requirements / constraints • Embedded • Tight constraints

  30. Basic COCOMO Calculations

  31. Example 49 Person Months • Organic Mode - We have estimated: • 15 KLOC minumum • 17.5 KLOC likely • 22 KLOC maximum

  32. Estimating… Uncertainty?

  33. The Cone of Uncertainty • 400% to 25% !? • Current studies show closer to +100% / -50% at feasibility stage • Strong tendency to underestimate

  34. Acknowledging Uncertainty • Alternatives to giving a single number • Between X and Y person months • X% chance it will be under Y person months • Use the “pX” approach • “X” = X% chance of NOT exceeding the estimate • Example – You’re on a project and your estimate is 8 person months. You’ve researched that 10% of similar projects have been under budget. • p10 estimate = 7 staff months – 10% chance of being under, 90% being over

  35. Dealing with Uncertainties • Communicate in a way that makes them known, such as the pX method. • Methodology > Gut Feelings • Work pressure drives over confidence • Re-Estimate • Feasibility Stage - Ball Park • Requirements Stage – More Detailed • Design Stage - Refined • Agile Environments: • Expect higher uncertainty

  36. Why Estimates Fail – A recap. • Little / Misused historical data • Record estimates + actual data • Make sure data “fits the bill” • Over-Optimistic / Hopeful management • Avoid gut feelings – use the methods • Avoid over-confidence • Not using the estimate! • Don’t Confuse targets with estimates • Not updating the estimate • Acknowledge uncertainty in estimation • Estimate often – it will become more accurate

  37. Questions?

  38. References Chemuturi, M. (2009). Software estimation best practices, tools & techniques. Fort Lauderdale, FL: J. Ross Publishing, Inc.. FAQs. (n.d.). International function point users group. Retrieved February 4, 2013, from http://www.ifpug.org/?page_id=12 Galorath, D. D., & Evans, M. W. (2006). Software sizing, estimation, and risk management when performance is measured performance improves. Boca Raton, FL: AuerbachPublications. Laird, L., & Brennan, M. (2006). Software measurement and estimation: a practical approach. Hoboken, NJ: John Wiley & Sons, Inc.. Pressman, R. (n.d.). A brief summary of the original cocomo model. McGraw hill higher education. Retrieved February 4, 2013,from www.mhhe.com/engcs/compsci/pressman/information/olc/ COCOMO.html

More Related