Estimation Why estimate What to estimate

Estimation • Why estimate? • What to estimate? • When to estimate? • How not to estimate? • How to estimate? (DRAFT) SWENET 1

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. (DRAFT) SWENET 2

What to Estimate? • Estimates are usually made in the following order: – System Size (LOC or Function points) – Effort – Duration – Cost How Long? Size Effort Duration Primary Driver (Other) (DRAFT) SWENET Cost How Much? 3

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. (DRAFT) SWENET 4

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). (DRAFT) SWENET 5

Effort vs. Duration Ironing a shirt Effort = 10 minutes Duration = 10 minutes Cooking a turkey Effort = 1 hour Duration = 3 hours Cutting a tree with a two-person saw Effort = 30 minutes Duration = 15 minutes (DRAFT) SWENET 6

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 (DRAFT) SWENET 7

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 (DRAFT) SWENET 8

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% (DRAFT) SWENET 9

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 (DRAFT) SWENET 10

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. (DRAFT) SWENET 11

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. (DRAFT) SWENET 12

Cone of uncertainty (DRAFT) SWENET 13

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 $1 M so we need to schedule a bid of $0. 9 M. (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. (DRAFT) SWENET 14

How to Estimate? • Techniques for estimating size, effort and duration: – Analogy – Expert judgement – Parametric (algorithmic) models (DRAFT) SWENET 15

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. (DRAFT) SWENET 16

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. (DRAFT) SWENET 17

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 (DRAFT) SWENET 18

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. (DRAFT) SWENET 19

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. (DRAFT) SWENET 20

COCOMO II • Schedule estimate is a function of person months: Duration. Months = 3. 67 * (Effortperson months)**F • F = an exponent based on the same non-linear project effects considered in the equation for person months. (DRAFT) SWENET 21

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. (DRAFT) SWENET 22