SWENET 1(DRAFT)

• Why estimate?

• What to estimate?

• When to estimate?

• How not to estimate?

• How to estimate?

Estimation

SWENET 2(DRAFT)

• 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.

Why Estimate?

SWENET 3(DRAFT)

• Estimates are usually made in the following order:– System Size (LOC or Function points)– Effort– Duration– Cost

What to Estimate?

Size Effort DurationCost

(Other)

Primary Driver

How Long?

How Much?

SWENET 4(DRAFT)

• 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.

Effort

SWENET 5(DRAFT)

• 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).

Duration

SWENET 6(DRAFT)

Effort vs. Duration

Cutting a tree with a two-person saw

Ironing a shirtEffort = 10 minutes

Duration = 10 minutes

Cooking a turkeyEffort = 1 hour

Duration = 3 hours

Effort = 30 minutes

Duration = 15 minutes

SWENET 7(DRAFT)

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

SWENET 8(DRAFT)

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

SWENET 9(DRAFT)

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%

SWENET 10(DRAFT)

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

SWENET 11(DRAFT)

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.

SWENET 12(DRAFT)

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.

SWENET 13(DRAFT)

Cone of uncertainty

Cost Estimation over time

0.25

0.50.67 0.8 1

4

21.5 1.2 1

0.1

1

10

Concep

ts

Req. S

pec.

Des

ign

Impl

emen

tatio

n

Accep

tanc

e

Project Phases

Ran

ge

of

cost

SWENET 14(DRAFT)

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.

SWENET 15(DRAFT)

How to Estimate?

• Techniques for estimating size, effort and duration:

– Analogy

– Expert judgement

– Parametric (algorithmic) models

SWENET 16(DRAFT)

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.

SWENET 17(DRAFT)

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.

SWENET 18(DRAFT)

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

SWENET 19(DRAFT)

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.

SWENET 20(DRAFT)

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.

SWENET 21(DRAFT)

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.

SWENET 22(DRAFT)

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.