370 likes | 483 Views
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
E N D
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Roll up the Estimate • Combine the estimates of all components • Again assign a reasonableness test Computer Engineering 203 R Smith Estimation 1/2009
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
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
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
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
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
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
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
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
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