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

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

3. 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?

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

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

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

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

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

9. 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%

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

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

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

13. Cone of uncertainty

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

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

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

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

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

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

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

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

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