Estimation Why estimate? What to estimate? When to estimate? How not to estimate? How to estimate?

Why Estimate? At the beginning of a project customers usually want to know: How much? How long? Programmers don’t like “death march” projects. Good estimates lead to realistic project plans.

What to Estimate? Estimates are usually made in the following order: System Size (LOC or Function points) Effort Duration Cost How Long? System size is usually measured in Lines of Code (LOC) or Function Points. Effort and Duration are defined in the next two slides. A short description of the two concepts might be appropriate here in order to interpret the diagram. System size drives effort estimates which drive both duration and cost estimates. Cost to some extent depends on duration. It usually costs less to spread development over a longer duration. When development is rushed costs tend to go up. Size Effort Duration Primary Driver Cost (Other) How Much?

Effort Effort is the amount of labor required to complete a task. Effort is typically measured in terms of person months or person hours. Effort is a function of developer productivity. Productivity = LOC or function points per month or hour.

Duration Duration is the amount of calendar time or clock time to complete a project or task. As an analogy, you can rent a car by the mile (effort) or period of time (duration).

Effort vs. Duration Ironing a shirt Cooking a turkey Effort = 10 minutes Duration = 10 minutes Cooking a turkey Effort = 1 hour Duration = 3 hours Cutting a tree with a two-person saw The effort and duration required to complete a task are rarely equal. If you are ironing a shirt effort = duration. If you are baking a turkey, the effort is minimal (putting it in the oven and taking it out), but the time (duration) it takes to bake a turkey is about 3 hours. The effort to cut a tree with a two person saw is twice the duration of the task because two people are working at it. Effort = 30 minutes Duration = 15 minutes

Size Estimate: Lines of Code Widely used, even though there are obvious limitations: need a counting standard language dependent hard to visualize early in a project hard to understand by clients does not account for complexity or environmental factors The last few slides made the distinction between effort and duration. You may want to remind the audience at this point the topic is “What to measure?” The answer is size, effort, duration, and cost. Now we are giving more detail about estimating size.

Size Estimate: Function Points -1 Developed by Albrecht (1979) at IBM in the data processing domain and subsequently refined and standardised. Based on a user view of a system: external inputs - e.g. input screen external outputs - e.g. output screen external enquiries - e.g. prompt for input internal logical files - e.g. database internal interface files - e.g. shared math routines

Size Estimate: Function Points -2 Basic Function Points = 4 * EI + 5 * EO + 4 * EQ + 10 * ILF + 7 * EIF Each elementary function type has its own relative weighting for complexity: low -25%, average, high +50%

Size Estimate: Function Points -3 There is also a Value Adjustment Factor (VAF) which is determined by 14 general system characteristics covering factors such as operational ease, transaction volume, distributed data processing. The VAF ranges from 0.65 to 1.35

Difficulties with Function Points Counting function points is subjective, even with standards in place. Counting can not be automated (even for finished systems, c.f. LOC). The factors are dated and do not account for newer types of software systems, e.g. real-time, GUI-based. There are many extensions to the original function points that attempt to address new types of system.

When to Estimate? Estimates are made at the beginning of a project and updated at regular intervals as new information is gained and uncertainty reduced.

Cone of uncertainty

How not to Estimate (van Vliet) We were given 12 months to do the job, so it will take 12 months. (Parkinson) We know our competitor put in a bid of $1M so we need to schedule a bid of $0.9M. (Priced to win) We want our product at the trade show next year so the software must be written and tested in the next nine months. Actually the project needs one year but I can’t sell that to my boss. We know 10 months is acceptable so we will settle for 10 months. Estimates are not targets. A target is a desired cost, schedule, etc. Estimates are what realistically can be accomplished. Parkinson's "law" is that work expands to consume available time and resources.

How to Estimate? Techniques for estimating size, effort and duration: Analogy Expert judgement Parametric (algorithmic) models Not all techniques apply to all parameters you might want to estimate. The algorithmic models usually only work for effort and duration. Analogy and expert judgment can be applied to any estimate.

Estimating by Analogy Identify one or more similar projects and use this project (or parts of it) to produce an estimate for the new project. Estimating accuracy is often improved by partitioning a project in parts and making estimates of each part (errors cancel out so long as estimating is unbiased). Can use a database of projects from your own organisation or from multiple organisations. Because effort doesn't scale linearly with size and complexity, extrapolating from past experience works best when the old and new systems are based on the same technology and are of similar size and complexity.

Estimating by Expert Judgment Have experts estimate project costs possibly with the use of consensus techniques such as Delphi. Bottom-up composition approach: Costs are estimated for work products at the lowest-levels of the work breakdown structure and then aggregated into estimates for the overall project. Top-Down decomposition approach: Costs are estimated for the project as a whole and then divided among the phases and components of the project.

Wide-band Delphi Get multiple experts/stakeholders Share project information Each participant provides an estimate independently and anonymously All estimates are shared and discussed Each participant estimates again Continue until or consensus, or exclude extremes and calculate average

Parametric (Algorithmic) Models Formulas that compute effort and duration based on system size and other cost drivers such as capability of developers, effectiveness of development process, schedule constraints, etc. Most models are derived using regression analysis techniques from large databases of completed projects. In general the accuracy of their predictions depends on the similarity between the projects in the database and the project to which they are applied.

Effortperson months = 2.94 * (Cost Drivers) * (KLOC)**E COCOMO II COCOMO = Constructive Cost Model Basic formula: Effortperson months = 2.94 * (Cost Drivers) * (KLOC)**E KLOC = Size estimate Cost Drivers = project attributes that have a linear effect on effort. Examples: analyst capability, reliability requirements, etc. E = an exponent based on non-linear project effects such as process maturity, team cohesion, etc. Nominal or average values for cost drivers is 1. So, if analysts have average capability you multiple by 1. If they are below average you multiple by a number greater than 1 such as 1.15.

DurationMonths = 3.67 * (Effortperson months)**F COCOMO II Schedule estimate is a function of person months: DurationMonths = 3.67 * (Effortperson months)**F F = an exponent based on the same non-linear project effects considered in the equation for person months.

Estimation Guidelines Don’t confuse estimates with targets Apply more than one technique and compare the results Collect and use historical data Use a structured and defined process. Consistency will facilitate the use of historical data. Update estimates as new information becomes available Let the individuals doing the work participate in the development of the estimates. This will garner commitment. Be aware that programmers tend to be optimistic when estimating.