1 / 37

Estimating

Estimating. First we estimate, then we schedule and track. Estimating determines the amount of work to do, not the schedule/dates in which the work can be done Regardless of dates it is important to understand how much work there is to do. Determine if dates are realistic

nash-smith
Download Presentation

Estimating

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. Estimating • First we estimate, then we schedule and track. • Estimating determines the amount of work to do, not the schedule/dates in which the work can be done • Regardless of dates it is important to understand how much work there is to do. • Determine if dates are realistic • Determine resources and costs • Determine what function can be included Computer Engineering 203 R Smith Estimation 1/2009

  2. Why estimate if dates are fixed? • Knowing the amount of work clarifies your options. • Be in XXXXXX one week from today. • Is it realistic? What options do you have? • Be in XXXXXX tomorrow. • Is it realistic? What options do you have? • Be in XXXXXX one hour from now. • Is it realistic? What options do you have? Computer Engineering 203 R Smith Estimation 1/2009

  3. Estimation • How are they different? • Precision versus accuracy • Detailed but inaccurate or high level and correct? • What is estimation? • When can estimation be done? • Overview of estimation techniques • Wideband Delphi Computer Engineering 203 R Smith Estimation 1/2009

  4. Scheduling • Scheduling is concerned with WHEN • Factors involved in scheduling once we have estimates of the work to be done • Resource availability • Dependencies • Priorities Computer Engineering 203 R Smith Estimation 1/2009

  5. Estimation • Estimation is concerned with how much work there is to do and the amount of effort needed to complete that work. • How much work is concerned with the size of the work. • Effort (in man-hours) is the size divided by the production rate. Different components may have different production rates. Computer Engineering 203 R Smith Estimation 1/2009

  6. Why talk in terms of size? • Size gives us a single variable to talk about. • While not completely unambiguous it is certainly less ambiguous than dates. • Example what is a line of code • It allows discussions to be more objective. Computer Engineering 203 R Smith Estimation 1/2009

  7. Measure of Size • There are many measures of size • Lines of code • Function points • Objects • Pages of documentation • Files • Etc. • Choose the measure that best reflects the work to be done. Computer Engineering 203 R Smith Estimation 1/2009

  8. Why Choose a Measure of Size that Reflects the work being done • Lines of code is often not the best measure of the work being done • Is making a 2 line fix really the work that is involved? • The effort needed to complete a task must be related to the size of the task. Computer Engineering 203 R Smith Estimation 1/2009

  9. Size is not Effort • Size is a reflection of how much work there is to do. • Effort is a reflection of how many man-hours it takes to do complete a task of a certain size at a specified production rate. • Example digging a hole • A 3’x3’X3’ hole is a fixed size regardless of the effort if takes to dig it. • The effort depends on rock or sand, hand or power tools etc. Computer Engineering 203 R Smith Estimation 1/2009

  10. Production Rate • Production rate is how many hours, days, weeks etc it takes to complete a task of certain size. • Where do we find production rate data? • Our own experience • Company experience • Industry experience Computer Engineering 203 R Smith Estimation 1/2009

  11. Factors the effect Production Rates • Developer experience • Complexity of the work • Critical project characteristics such as performance • Location of the team • A large number of communications interfaces can negatively impact a team’s production rate. Computer Engineering 203 R Smith Estimation 1/2009

  12. Example why size is important • You are asked how many Widgets you can make in a 8 hours. • You will be paid 10 dollars for everyone you produce. • You get nothing if you do not make as many as you said. • What do you do? Computer Engineering 203 R Smith Estimation 1/2009

  13. Use of contingency in estimation • Contingency is the recognition that estimates are not perfect. • Contingency is not a fudge factor, slack or a pad. • Contingency is based on past experience and accounts for what is unknown at a given point in the project. • Contingency is greater in the early stages of a project and can vary throughout the project. Computer Engineering 203 R Smith Estimation 1/2009

  14. Views on Estimating • Management needs to have estimates of all parts tasks that are part of a project. • Allocate resources • Schedule tasks • Individual contributors need to estimate their work so they can provide management with an estimate. Computer Engineering 203 R Smith Estimation 1/2009

  15. Problems in estimation • Lack of estimating experience • With the process • Historical • Lack of systematic estimation process • Failure to include all activities • Unrealistic assumptions and expectations • Incomplete requirements • Failure to recognize uncertainty Computer Engineering 203 R Smith Estimation 1/2009

  16. Problems in estimation • Getting buy-in • Not accounting for defect correction time • Not accounting for training time • Not accounting for integration time • Not allowing for the possibility of change • Always assuming the best case Computer Engineering 203 R Smith Estimation 1/2009

  17. Getting Developers to Think in Terms of Size • Why can a developer give you a date yet he is not sure of the size? • Relating to past experience • Making comparisons • Having enough information Computer Engineering 203 R Smith Estimation 1/2009

  18. When can estimates be done? • Developers want to wait until the last minute for estimates • Developers want everything certain • Managers need estimates as early as possible • Managers will create their own estimates if none is provided Computer Engineering 203 R Smith Estimation 1/2009

  19. When can estimates be done? • Bad estimates harden with age • Management gets attached to the dates they want to hear • Business decisions require estimates as early as possible Computer Engineering 203 R Smith Estimation 1/2009

  20. Estimation Techniques • Seat of the pants • Work breakdown structures • Classic technique • Algorithmic Methods • Constructive Cost Model (COCOMO II) • Converts size into effort • Wideband Delphi • Function Point Analysis • You do not need to use just one method Computer Engineering 203 R Smith Estimation 1/2009

  21. Wideband Delphi • Also called expert opinion • Should be repeated at multiple stages within the project • Results need to be recorded • Once the team is familiar with the method it can be low cost Computer Engineering 203 R Smith Estimation 1/2009

  22. Basic Steps in the Wideband Delphi Method • Preparation • Kickoff meeting • Homework • Working session • Resolve issues • Roll up the Estimate Computer Engineering 203 R Smith Estimation 1/2009

  23. Preparation • Put together your sizing team along with someone who knows how to facilitate the sizing • The facilitator does not need to be an expert in the work being done • “Experts” can come from all areas • Search the your experience Computer Engineering 203 R Smith Estimation 1/2009

  24. Kickoff Meeting • Musts for the Kickoff meeting • Decide on the components to estimate • Components should be relatively large • Decide on the measure of size • Each component may have a different measure of size • Work within a component should be uniform • Describe to overall work to be estimated Computer Engineering 203 R Smith Estimation 1/2009

  25. Homework • Each team member makes an individual estimate of the size of each component • Use of personal experience • Use of company data • Use of industry data Computer Engineering 203 R Smith Estimation 1/2009

  26. Working Session • Everyone gets together and compares estimates of size • Ensure that everyone has a common understanding of the work to be done • Understand differences between estimates Computer Engineering 203 R Smith Estimation 1/2009

  27. Resolve Issues • Resolve differences • Apply a reasonableness test to the agree to size • Example • Estimate a one day presentation • Side benefit is a common understanding of the work to be done Computer Engineering 203 R Smith Estimation 1/2009

  28. Roll up the Estimate • Combine the estimates of all components • Again assign a reasonableness test Computer Engineering 203 R Smith Estimation 1/2009

  29. Assigning Production Rates • Past experience, company data and industry data • How to judge a reasonable production rate? Computer Engineering 203 R Smith Estimation 1/2009

  30. Apply Production Rates and Calculate the Total Effort • Determine the total effort for the project • Next add in contingency • Contingency helps to keep schedule dates from moving Computer Engineering 203 R Smith Estimation 1/2009

  31. Contingency Factors • Planning for what you know you do not know. • What has your experience shown that you do not know at this stage of the project? • Contingency for change • Contingency for growth Computer Engineering 203 R Smith Estimation 1/2009

  32. Notes on Contingency Use • Do not just think of contingency in terms of time. • Time • Resources • Reduction in function Computer Engineering 203 R Smith Estimation 1/2009

  33. Notes on Contingency Use • Know when you are using contingency • Know why you are using contingency • Contingency for change should be under change control • Do not use contingency if you do not need to Computer Engineering 203 R Smith Estimation 1/2009

  34. Modified Delphi Summary • Can be done for any type of project • Can be done early in the project • Provides common understanding of the work to be done • Industry data can be ambiguous • Requires a historical data base • Should be done at multiple points in the project Computer Engineering 203 R Smith Estimation 1/2009

  35. Function Point Analysis • A method of measuring project size based on an analysis of “function points.” • Function points are derived from data and transactions that cross the application boundary. • Internal Logical File • External Interface File • External Input • External Output • External Inquiry Computer Engineering 203 R Smith Estimation 1/2009

  36. Function Point Analysis • Once counts are determined they are adjusted based on 15 factors. • Final counts can be converted directly into time estimates or first converted into lines of code and then time estimates. • Issues • Complexity of function point counting • Number of variables in determining the count • Function Points are not representative measures of size for all applications. Computer Engineering 203 R Smith Estimation 1/2009

  37. Function Point Summary • Function Points are a specific measure of size and is measured in a defined way. • Industry function point data is available • Function Point counting is complex • Function Point counting requires a good understanding of not only requirements but also design. • Function Point counts are always to best measures of size • Counts should be done multiple times Computer Engineering 203 R Smith Estimation 1/2009

More Related