Software effort estimation

CHAPTER

Software Project Management Slide# 1

 Software effort estimation
CHAPTER

Objectives

• Avoid the dangers of unrealistic estimates;

• Understand the range of estimating methods that can be used;
• Estimate project using a bottom-up approach;
• Count the function points and object points for a system
• Estimate the effort needed to implement software using a
procedural programming language;
• Understand the COCOMO approach to developing effort models.

Software Project Management Slide# 2

 Software effort estimation
5.1 Introduction

Definition of successful project:

“on time and within budget and with the required quality.”

• Novel applications of software;

• Changing technology;

• Lack of homogeneity of project experience

Software Project Management Slide# 3

 Software effort estimation
5.1 Introduction

0
Select Project
1 Identify project 2 Identify project
scope and objective infrastructure
3
Analyze project
characteristics

4 Identify the
Review products and activities

5 Estimate effort
for activity
For each activity
Lower level detail 6 Identify
activity risks

10 Lower level planning

7 Allocate resources

9 Execute plan 8 Review/publicize plan

Software Estimation take place in step 3 and 5 in particular

Software Project Management Slide# 4

 Software effort estimation
5.1 Introduction
Table 5.1: Some project data – effort in work months
Project Design Coding Testing Total
Wm (%) Wm (%) Wm (%) Wm SLOC

A 3.9 (23) 5.3 (32) 7.4 (44) 16.7 6050

B 2.7 (12) 13.4 (59) 6.5 (26) 22.6 8363
C 3.5 (11) 26.8 (83) 1.9 (6) 32.2 13334
D 0.8 (21) 2.4 (62) 0.7 (18) 3.9 5942
E 1.8 (10) 7.7 (44) 7.8 (45) 17.3 3315
F 19.0 (28) 29.7 (44) 19.0 (28) 67.7 38988
G 2.1 (21) 7.4 (74) 0.5 (5) 10.1 38614
H 1.3 (7) 12.7 (66) 5.3 (27) 19.3 12762
I 8.5 (14) 22.7 (38) 28.2 (47) 59.5 26500

Calculate the productivity (i.e. SLOC per wm) of each of the projects in Table 5.1 and
also for the organization as a whole. If the project leaders for projects A and D has
Exercise 5.1 correctly estimated the source number of line of code (SLOC) and then used the
average productivity of the organization to calculate the effort needed to complete the
project, how far out would their estimates have been from the actual effort?

Software Project Management Slide# 5

 Software effort estimation
5.1 Introduction

Subjective nature of estimating

• Underestimate
• Overestimate

Political implications

• Different groups within an organization

have different objectives

Software Project Management Slide# 6

 Software effort estimation
5.2 Where are estimates done?

• Strategic planning
• Feasibility study
• System specification
• Evaluation of suppliers’ proposals
• Project planning

Software Project Management Slide# 7

 Software effort estimation
5.3 Problem with over- and under-estimates

Parkinson’s Law

Work expands to fill the time available

Brooks’ Law
Putting more people on a late job makes it later.

Software Project Management Slide# 8

 Software effort estimation
5.3 Problem with over- and under-estimates

Under-estimate

• Not be completed on time or to cost;

• Implement in a shorter time than project with more
generous estimate;
• The danger is the effect on quality;
• Reliability.

Software Project Management Slide# 9

 Software effort estimation
5.4 The basis for software estimating

1. The need for historical data

2. Measure of work
• It is impossible to calculate directly the actual cost
or time required to implement the project.

• Software measurement : source line of code

(SLOC) or thousands of line of code (KLOC).

3. Complexity

Software Project Management Slide# 10

 Software effort estimation
5.5 Software effort estimation techniques

Algorithmic models
Expert judgment A model is developed
using historical cost
One or more experts on the
Analogy information which relates
software development
some software metric
techniques
This technique to be used and
is applicable
Parkinson (usually its size) to the
when other on the application
projects the Andomain
projectincost. estimate
same
The effort are
application consulted.
domain
is determined by metric
Price to win is made of that
have been resources
available completed.
and modelratherpredicts the
Theby
than estimated
objective effort
effort required.
Top-down depends on the customer’s
assessment.
Estimates are made on the
budget and not on the
Bottom-up basis of the logical function
software functionality.
Each component is
rather than components
estimated. Allthat
implementing of them are
function.
added to product a final
estimate.
Software Project Management Slide# 11
 Software effort estimation
5.5 Software effort estimation techniques

Bottom-up estimating
The estimator breaks the project into its component tasks
and then estimates how much effort will be required to
carry out this task.
With a large project, the process of breaking down into
tasks would be a repetitive one: each task would be
analyzed into its component sub-tasks and these in turn
would be further analyzed.
This is repeated until you get to components that can be
executed by a single person in about a week or two.
The bottom-up part comes in adding up the calculated
effort for each activity to get an overall estimate.

Software Project Management Slide# 12

 Software effort estimation
5.5 Software effort estimation techniques

The top-down approach and parametric models

• The top-down approach is normally associated with parametric
models.
• Form of parametric models’ formulation:

Effort = (system size) X (productivity rate)

The top-down and bottom-up approaches are not mutually exclusive. Project
managers will probably try to get a number of different estimates from
different people using different methods. Some parts of an overall estimate
could be derived using a top-down approach while other parts could be
calculated using a bottom-up method.

Software Project Management Slide# 13

 Software effort estimation
5.5 Software effort estimation techniques

The top-down approach and parametric models

Example

Amenda at IOE might estimate that the first software module to be constructed is 2KLOC. She might
then judge that if Kate undertook the development of the code, with her expertise she could work at
a rate of 40 days per KLOC.

Software Project Management Slide# 14

 Software effort estimation
5.6 Expert judgement

It is shown that experts tend to use a

combination of an informal analogy approach
where similar projects from the past are
identified, and bottom-up estimating.

Software Project Management Slide# 15

 Software effort estimation
5.7 Estimating by analogy

• Case-based reasoning;
• Estimator seeks out project that have been completed –
“Source cases”;
• That has been similar characteristics to the new project –
“Target cases”;
• The effort that has been recorded for the matching source
case can then be used as a base estimate for the target;
• The estimator should then try to identify any differences
between the target and the source and make adjustments to
the base estimate for the new project.

Software Project Management Slide# 16

 Software effort estimation
5.7 Estimating by analogy

The Euclidean distance is calculated:

distance = tp 1  sp 1   ...  tp n  sp n 

2 2

Where tp = target parameter
sp = source parameter

Software Project Management Slide# 17

 Software effort estimation
5.7 Estimating by analogy

Example 5.1

The new project is known to require 7 inputs and 15 outputs. One of the
past cases, project A, has 8 inputs and 17 outputs. The Euclidean distance
between source and the target is =
Project B has 5 inputs and 10 outputs. What would be the Euclidean
distance between this project and the target new project being considered
above? Is the project B a better analogy with the target than project A?

Software Project Management Slide# 18

 Software effort estimation
Summary

Methodology Description

Analogy (Comparative) Compare project with past similar projects

Individuals assess components, then component

Bottom-up (Grass Roots) estimates are summed to obtain total estimate.
Project partitioned into lower level components & life
Top-down cycle phases beginning at highest level

Expert Judgment Consult with one or more experts.

Perform overall estimate using design parameters and

Parametric (Algorithm) mathematical algorithms.

Software Project Management Slide# 19

 Software effort estimation
Summary

Methodology Advantages

Analogy Estimates are based on actual experience.

Accurate estimates are possible because of detailed

Bottom-up basis for estimate; also promotes individual
responsibility, supports project tracking.
More applicable to early project estimates.
Top-down Considers system level activities,
faster, easier to implement.
Little or no historical data are needed; good for new
Expert Judgment or unique projects.

Models are usually fast and easy to use, and useful

Parametric early in a program. They are also objective and
repeatable.

Software Project Management Slide# 20

 Software effort estimation
Summary

Methodology Disadvantages

Analogy Truly similar projects must exist.

• Methods are time-consuming.

• Detailed data needed may not be available,
Bottom-up especially early in a program.
• Integration costs may be disregarded.
• Process is costly

• Less accurate than other methods,

Top-down • tends to overlook lower-level components,
• provides little detail.
Experts tend to be biased, and knowledge level is
Expert Judgment sometimes questionable.

• They are often inaccurate and unstable.

Parametric • Also, calibration to historical data may not be
relevant for new programs.
Software Project Management Slide# 21
 Software effort estimation
5.8 Albrecht function point analysis

The basis of function point analysis is that computer-based

information systems comprise five major components, or external
user types in Albrecht’s terminology, that are of benefit to the users:

External input types

External output types
Logical internal file types
External interface file types
External inquiry types

Software Project Management Slide# 22

 Software effort estimation
5.8 Albrecht function point analysis

Case Study Examples: Assessing the complexity of a logical internal file

Table 5.2: Albrecht complexity multipliers

Multiplier
External user type Low Average High

External input type 3 4 6

External output type 4 5 7
Logical internal file type 7 10 15
External interface file type 5 7 10
External inquiry type 3 4 6

Software Project Management Slide# 23

 Software effort estimation
5.8 Albrecht function point analysis

Format Examples: Assessing the complexity of a logical internal file

Software Project Management Slide# 24

 Software effort estimation
5.8 Albrecht function point analysis

Complexity Tables: Albrecht Function point

External Input Table (EI) Shared EO and EQ Table

Values for transactions

Software Project Management Slide# 25

 Software effort estimation
5.8 Albrecht function point analysis

Complexity Tables: Albrecht Function point

Internal Logical File & External Interface File (ILF & EIF)

Software Project Management Slide# 26

 Software effort estimation
5.8 Albrecht function point analysis

Level of selected software languages relative to Assembler language

Language Ratio-source : Executable

Assembler 1:1
C 1 : 1.5
COBOL 1:3
FORTRAN 1:3
PASCAL 1 : 3.5
RPG 1:4
PL/1 1:4
BASIC 1:5
4GLs 1:8
QUERY LANG. 1 : 20
SPREADSHEET 1 : 50

Software Project Management Slide# 27

 Software effort estimation
5.8 Function points

FP = Total UFP X [0.65 + 0.01 x  (VAF)] ; VAF = Scale of 0 to 5

Software Project Management Slide# 28

 Software effort estimation
5.8 Function points - SLOC

Software Project Management Slide# 29

 Software effort estimation
5.9 Function points Mark II

The ‘Mark II’ label implies an improvement and replacement of

the Albrecht method.
The information processing size is initially measured in
unadjusted function points [UFPs] to which a technical complexity
adjustment [TCA] can then be applied.

Software Project Management Slide# 30

 Software effort estimation
5.9 Function points Mark II

For each transaction the UFPs are calculated:

Wi x (number of input data element types) +
We x (number of entity types referenced) +
Wo x (number of output data element types)

Here, W is weightings that might be derived by asking developers what proportion of effort
has been spent in previous projects developing those parts of the software that deal with
processing inputs, assessing, and modifying stored data and processing outputs.
Data Store

Input Output Return

From
User Process to user
Model of transaction

Note: Industry averages are 0.58 for W-input, 1.66 for W-entity and 0.26 for W-output. All ratios are 2.5
Software Project Management Slide# 31
 Software effort estimation
5.9 Function points Mark II

Case study Example: Calculating Mark II function points

• Two entity types – Invoice and CashReceipt

• Data elements – InvoiceNumber, DateReceived, CashReceived
• Output – error message

The unadjusted function points, using the industry average weightings,

for this transaction would therefore be:

(0.58 x 3) + (1.66 x 2) + (0.26 x 1) = 5.32

Software Project Management Slide# 32

 Software effort estimation
5.9 Function points Mark II

Example 5.7

The IOE maintenance group accounts subsystem for which Amanda is

responsible will have a transaction which sets up details of new group
account customers. The operator will input:
• Customer account number
• Customer Name
• Address
• Postcode
• Customer Type
• Statement production date

All this information will set up in a CUSTOMER record on the system’s

database. If a CUSTOMER account already exists for the account number that
has been input, an error message will be displayed to the operator. Calculate
the number of unadjusted Mark II function points for this transaction, using the
industry average weightings.

Software Project Management Slide# 33

 Software effort estimation
5.9 Function points Mark II

The original Albrecht FP method identified 14 technical complexity

adjustment factors – Mark II FPs identify five more factors:

• Interfaces to other applications;

• Special security features;
• Direct access for third parties;
• User training features;
• Documentation requirements.

Software Project Management Slide# 34

 Software effort estimation
5.9 Function points Mark II

If you have figures for the effort expended on past projects and also
the system size in FPs, you should be able to work out a productivity
rate, that is:
Productivity = size / effort.
For new projects, the function points can be counted and then the
effort can be projected using the productivity rate derived above:

Effort = size / productivity.

A more sophisticated way of doing this would be by using the

statistical technique, least squares regression, to derive an equation
in the form:

Effort = constant1 + size x constant2.

Software Project Management Slide# 35

 Software effort estimation
5.10 COSMIC Full Function Points
Common Software Measurement Consortium – Full Function Point
Full function point (FFP) method has its origins in the work of two
interlinked research group.
COSMIC requires the analyst to break down the system architecture
into a hierarchy of software layers.
Data groups can be moved about in four ways:
Entries (E)
Exits (X)
Reads (R)
Writes (W).

The overall FFP count is derived by simply adding up the counts for each of the four
types of data movement. The resulting units are Cfsu (COSMIC functional size units).
Software Project Management Slide# 36
 Software effort estimation
5.10 Object points

If you are building a system using a high level application

building tool – object-oriented techniques, the approach uses
counts of the screens, reports, and 3GL components that an
application might possess – it is these that are referred to as
objects.
Each object has to be classified as one of the following:
Simple;
Medium;
Difficult.

Software Project Management Slide# 37

 Software effort estimation
5.10 Object points

srvr is the number of server ( mainframe or equivalent ) data tables used in conjuction with the SCREEN or REPORT
clnt is the number of client ( personal workstation ) data tables used in conjuction with the SCREEN or REPORT

Software Project Management Slide# 38

 Software effort estimation
5.10 Object points

Complexity weighting
Object Type Simple Medium Difficult
Screen 1 2 3
Report 2 5 8
3GL - - 10
Component

Object points complexity weightings

Software Project Management Slide# 39

 Software effort estimation
5.10 Object points

If application containing 840 object points, 20% can be supplied by

using existing components, then the adjusted new object points
(NOP) score would be:

NOP = 840 x (100 – 20)/100 = 672

Productivity rate (PROD) has to be identified. An estimate of the

person-months needed to carry out the project is then calculated by
dividing PROD into NOP.

Given 672 new object points and a development environment where

productivity was nominal, then estimated effort for the project would
be:
672/13 = 52 months.
Here, nominal of PROD = 13 (see Table 5.9 object point effort conversion).

Software Project Management Slide# 40

 Software effort estimation
5.11 A procedural code-oriented approach

1. Envisage the number and type of programs in

the final system

2. Estimate the SLOC of each identified program

3. Estimate the work content, taking into account

complexity and technical difficulty

4. Calculate the work-days effort

Software Project Management Slide# 41

 Software effort estimation
5.12 COCOMO : a parametric model

The COCOMO Model ( Barry Boehm 1981):

The COnstructive COst MOdel ( COCOMO) is an example of

regression models used for estimating software cost and effort.
These methods use a basic formula with parameters that are
determined via a historical database and current project
characteristics.

The COCOMO Model is the most widely used and accepted

of the cost / effort estimation models. This model as a size-driven
model is highly dependent upon the manager's ability to estimate
the size of the software system at an early stage. This method is
generally used in conjunction with one of the size estimation models
such as function points.

Software Project Management Slide# 42

 Software effort estimation
5.12 COCOMO : a parametric model

COCOMO (Constructive Cost Model) is often referred to in the

literature on software project management, particularly in
connection with software estimating. The term COCOMO really
refers to a group of models.

The basic model was built around the equation:

effort = c x sizek

Where effort is measured in pm, or the number of ‘person-months’ consisting of

units of 152 working hours, size is measured in kdsi, thousands of delivered source
code instructions, and c and k are constants (see Table 5.10).

Software Project Management Slide# 43

 Software effort estimation
5.12 COCOMO : a parametric model (ADD)

Small Projects:
Measurements of small to moderate projects resulted in a model of the following form:
EFFORT = a * SIZE + b
Here, the magnitude of the effort is a linear function of the size of the project ( Number of Lines of
Code, usually ). This model holds up until a certain point, usually for projects that can be reasonably
accomplished by small teams of two or three people. By increasing the size of the project, the above
model becomes less and less accurate an the need for a new model increases.

Large Projects:

Projects requiring teams of more than three or so people tend to behave in the following
way:

EFFORT = a * SIZE b
Here, the size of the project is scaled exponentially, therefore as a product increases in size, the
effort to produce the product grows more than linearly ( for b >= 1 ). It means that if we try to
develop a larger product, our productivity ( SIZE / EFFORT ) Decreases. This decrease in productivity
on larger projects is called a diseconomy of scale.

Software Project Management Slide# 44

 Software effort estimation
5.12 COCOMO : a parametric model

The Organic Mode

 Software developed “in house”

 Experienced developers
 Requires small developer teams
 Small communication overhead
 Stable development environment
 Small size (about 50 KSLOCs)
NOTE: Boehm’s notation for SLOCs: DSI (Delivered Source Instructions).

Software Project Management Slide# 45

 Software effort estimation
5.12 COCOMO : a parametric model

Semi-Detached Mode

 Developers have an intermediate level of experience

with related systems.
 Mixture of experienced and unexperienced
developers.
 Team can have experience relative only for some
project aspects.
 Size extends up 300 KDSI
This is the intermediate level between Organic and Embedded mode.

Software Project Management Slide# 46

 Software effort estimation
5.12 COCOMO : a parametric model

Embedded Mode

 Projects developed within tight constraints.

 Product must operate within (embedded in) a
strongly coupled complex of hardware, software
and operational procedures.
 High cost on changing parts.
 Projects on not very known fields.
 Any size

Software Project Management Slide# 47

 Software effort estimation
5.12 COCOMO : a parametric model

C K

2.4 1.05
• Organic Mode

• Embedded Mode 3.6 1.20

• Semi-detached Mode 3.0 1.12

Software Project Management Slide# 48

 Software effort estimation
5.12 COCOMO : a parametric model

The nominal estimate is then adjusted by a development effort

multiplier (dem):
pmest = pmnom x dem
Where dem is calculated by taking into account multipliers based on the effort drivers
in Table 5.11

The effect of analyst capability: ACAP

Very Low 1.46
Low 1.19
Nominal 1.00
High 0.8
Very High 0.71

Software Project Management Slide# 49

 Software effort estimation
5.12 COCOMO : a parametric model

Driver type Code Cost driver

Product attribute RELY Required software reliability
DATA Database size
CPLX Product complexity
Computer attribute TIME Execution time constraints
STOR Main storage constraints
VIRT Virtual machine volatility
TURN Computer turn around time
Personnel attribute ACAP Analyst capability
AEXP Application experience
PCAP Programmer capability
VEXP Virtual machine experience (OS)
LEXP Programming language experience
Project attribute MODP Use of modern programming practice
TOOL Use of software tools
SCED Required development schedule.
Software Project Management Slide# 50
 Software effort estimation
5.12 COCOMO : a parametric model

Attribute Very low Low Nominal High Very high

ACAP 1.46 1.19 1.00 0.86 0.71
AEXP 1.29 1.13 1.00 0.91 0.82
PCAP 1.42 1.17 1.00 0.80 0.70
VEXP 1.21 1.10 1.00 0.90 -
LEXP 1.14 1.07 1.00 0.95 -

Software Project Management Slide# 51

 Software effort estimation
5.12 COCOMO : a parametric model

COCOMO II has been designed to accommodate this by having models

for three different stages.

Application composition
Early design
Post architecture

Software Project Management Slide# 52

 Software effort estimation
5.12 COCOMO II : a parametric model

Software Project Management Slide# 53

 Software effort estimation
5.12 COCOMO II : a parametric model
Different between Basic COCOMO and Intermediate COCOMO

Software Project Management Slide# 54

 Software effort estimation
5.12 COCOMO II : a parametric model

To estimate the effort for application composition, the counting of

object points, which were described earlier, is recommended by the
developers of COCOMO II.
At the early design stage, FPs are recommended as the way of
gauging a basic system size. An FP count might be converted to a SLOC
equivalent by multiplying the FPs by a factor for the programming
language that is to be used.

The following model can then be used to calculate an estimate

of person-months:
pm  A  size  em1  em2  ...  emn
sf

A is a constant, size is measured in SLOC, sf is exponent scale factor, em is

effort multipliers.

sf  0.91  0.01  exp .driver.rate 

Software Project Management Slide# 55

 Software effort estimation
5.12 COCOMO II : a parametric model

Effort Adjustment Factor (EAF)

Very Low Low Nominal High Very High
1. Product Distribution
- Software Reliability 0.75 0.88 1.00 1.15 1.40
- Database Size 0.94 0.94 1.00 1.08 1.16
- Product Complexity 0.70 0.85 1.00 1.15 1.30
2. Computer Distribution
- Execute time constraints 1.00 1.00 1.00 1.11 1.30
- Main storage constraints 1.00 1.00 1.00 1.06 1.21
- Virtual machine volitility 0.87 0.87 1.00 1.15 1.30
- Computer turnaround time 0.87 0.87 1.00 1.07 1.15
3. Personnel Distribution
- Analyst Capability 1.46 1.19 1.00 0.86 0.71
- Applications experience 1.29 1.13 1.00 0.91 0.82
- Programmer capability 1.42 1.17 1.00 0.86 0.70
- Virtual machine experience 1.21 1.10 1.00 0.90 0.90
- Programming Language experience 1.14 1.07 1.00 0.95 0.95
4. Project attributes
- Use of modern programming practice 1.24 1.10 1.00 0.91 0.82
- Use of software tools 1.24 1.10 1.00 0.91 0.83
- Require development schedule 1.23 1.08 1.00 1.04 1.10

Software Project Management Slide# 56

 Software effort estimation
5.12 COCOMO II : a parametric model

The qualities that govern the exponent driver used to calculate the 5
scale factors are listed below:

Precedentedness
Development flexibility
Architecture/risk resolution
Team cohesion
Process maturity

Software Project Management Slide# 57

 Software effort estimation
5.12 COCOMO II : a parametric model

COCOMO II Effort Equation

The COCOMO II model makes its estimates of required effort (measured in Person-Months
– PM) based primarily on your estimate of the software project's size (as measured in
thousands of SLOC, KSLOC)):

Effort = 3.0  EAF  (SIZE)E

Where
EAF is the Effort Adjustment Factor derived from the Cost Drivers
E is an exponent derived from the five Scale Drivers

Software Project Management Slide# 58

 Software effort estimation
5.12 COCOMO II : a parametric model

COCOMO II Schedule Equation

The COCOMO II schedule equation predicts the number of months required to complete
your software project. The duration of a project is based on the effort predicted by the
effort equation:

Duration = 2.5  (Effort)SE

Where
Effort is the effort from the COCOMO II effort equation
SE is the schedule equation exponent derived from the five Scale Drivers

Effort
Staffing 
Duration

Software Project Management Slide# 59

 Software effort estimation
5.12 COCOMO II : Example

Consider a database system needed for an office automation project. The

requirements document shows 4 modules needed. The project is judged
to be ORGANIC

Sizes are estimated as follows:

data entry 0.6 KDSI

data update 0.6 KDSI
query 0.8 KDSI
report gen. 1.0 KDSI

The manager rates project details as follows:

Complexity (HIGH) EAF = 1.15

Storage (HIGH) EAF = 1.06
Experience Programmer (LOW) EAF = 1.13
Capabilities (LOW) EAF = 1.17

Software Project Management Slide# 60

 Software effort estimation
5.12 COCOMO II : Example

PROJECT SIZE = 0.6 + 0.6 + 0.8 + 1.0 = 3.0 KDSI

EAF = 1.15 x 1.06 x 1.13 x 1.17 = 1.61

Person Months for the project:

PM = 1.61 x 3.2 x (3.0)1.05

PM = 1.61 x 3.2 x 3.17
PM = 16.33

DURATION

DURATION = 2.5 x EFFORT 0.38

DURATION = 2.5 x (16.33)0.38
DURATION = 2.5 x 2.89
DURATION = 7.23 7 months to complete

Software Project Management Slide# 61

 Software effort estimation
5.12 COCOMO II : Example

Effort
Staffing 
Duration

How Many people to hire ?

Staffing = 16.33 pm / 7.23 months = 2.26 persons

3 team members needed

Software Project Management Slide# 62

 Software effort estimation
5.13 Conclusion

To summarize some key points:

 Estimates are really management targets
 Collect as much information about previous projects as possible
 Use more than one method of estimating
 Top-down approaches will be used at the earlier stages of project planning
while bottom-up approaches will be more prominent later on
 Be careful about using other people’s historical productivity data as a basis
for your estimates, especially if it comes from a different environment
 Seek a range of opinions
 Document your method of doing estimates and record all your
assumptions

Software Project Management Slide# 63