Chapter Five: Estimating Project Times and Costs

26-Mar-21
Chapter Five
Estimating Project Times and Costs
Copyright © 2018 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.
5–1
Where We Are Now
5–2
1
26-Mar-21
Suggested Readings and Links
• Extra Readings for Software Size Estimation:

Marchewka Book Appendix and Introduction to
the COSMIC method of measuring software,
v1.2 –first 4 sections (uploaded to Moodle, also
I do suggest you skim some of the MetricView
articles..)
• Links: Common Software Measurement
International Consortium https://cosmic-
sizing.org/ (ISO/IEC 19761:2011) –COSMIC v
4.0.2
3
Links (contd)
• ISBSG (International Software Benchmarking
Standards Group) http://isbsg.org/
• International Function Point User Group: IFPUG
4.3 http://www.ifpug.org/ (ISO/IEC 20926:2009)
• COCOMO II :
http://www.cocomo2.com/about-cocomoii/
http://softwarecost.org/tools/COCOMO/
• NESMA Netherlands Software Metrics users

Association https://nesma.org/ (ISO/IEC
24570:2018)
4
2
26-Mar-21
For Exams
• I will expect you to know the basics and ups and
downs of different approaches but I will not ask
you to calculate specific function points in
exams….
5–5
Learning Objectives
1. Understand estimating project times and costs are the

foundation for project planning and control
2. Describe guidelines for estimating time, cost, and resources
3. Describe the methods, uses, and advantages and
disadvantages of top-down and bottom-up estimating
methods
4. Distinguish different kinds of costs associated with a project
5. Suggest a scheme for developing an estimating database
for future projects
6. Understand the challenge of estimating mega projects and
describe steps that lead to better informed decisions
7. Define a “white elephant” in project management and
provide examples
5–6
3
26-Mar-21
Chapter Outline
5.1 Factors Influencing the Quality of Estimates
5.2 Estimating Guidelines for Times, Costs, and
Resources
5.3 Top-Down versus Bottom-Up Estimating
5.4 Methods for Estimating Project Times and
Costs
5.5 Level of Detail
5.6 Types of Costs
5.7 Refining Estimates
5.8 Creating a Database for Estimating
5.9 Mega Projects: A Special Case
5–7
Estimating Projects
• Estimating
– The process of forecasting or approximating the time
and cost of completing project deliverables
– The task of balancing expectations of stakeholders
and need for control while the project is implemented
• Types of Estimates
– Top-down (macro) estimates: analogy, group
consensus, or mathematical relationships
– Bottom-up (micro) estimates: estimates of elements
of the work breakdown structure
5–8
4
26-Mar-21
Why Estimating Time and Cost Is Important
• To support good decisions

• To schedule work
• To determine how long the project should take and
its cost
• To determine whether the project is worth doing
• To develop cash flow needs
• To determine how well the project is progressing
EXHIBIT 5.1
5–9
Factors Influencing the Quality of Estimates
Planning
Horizon
Other
Project
(Nonproject)
Complexity
Factors
Quality of
Organization Estimates People
Culture
Padding Project Structure

Estimates and Organization
5–10
5
26-Mar-21
Estimating Guidelines for Times,

Costs, and Resources
1. Have people familiar with the tasks make the estimate

2. Use several people to make estimates
3. Base estimates on normal conditions, efficient methods,
and a normal level of resources
4. Use consistent time units in estimating task times
5. Treat each task as independent, don’t aggregate
6. Do not make allowances for contingencies.
7. Add a risk assessment to avoid surprises to
stakeholders
5–11
Developing Work Package Estimates
Use people
familiar with
the tasks
Use several
Include a risk
people to make
assessment
estimates
Preparing
Make no Initial
Assume normal
allowance for Estimates conditions
contingencies
Assume tasks Use consistent

are independent time units
5–12
6
26-Mar-21
Top-Down versus Bottom-Up Estimating
• Top-Down Estimates
– Are usually derived from someone who uses
experience and/or information to determine the
project duration and total cost.
– Are sometimes made by top managers who have little
knowledge of the processes used to complete the
project.
• Bottom-Up Approach
– Can serve as a check on cost elements in the WBS
by rolling up the work packages and associated cost accounts to
major deliverables at the work package level.
– More detail has to be defined..
5–13
Top-Down versus Bottom-Up Estimating
Conditions for Preferring Top-Down or

Bottom-up Time and Cost Estimates
Top-down Bottom-up
Condition Estimates Estimates
- Strategic decision making X
- Cost and time important X
- High uncertainty X
- Internal, small project X
- Fixed-price contract X
- Customer wants details X
- Unstable scope X
TABLE 5.1
5–14
7
26-Mar-21
Estimating Projects: Preferred Approach
• Make rough top-down estimates

• Develop the WBS/OBS
• Make bottom-up estimates
• Develop schedules and budgets
• Reconcile differences between top-down
and bottom-up estimates (if not, can result in
“death march” projects)
5–15
Some problems with estimating
• Subjective nature of much of estimating

– It may be difficult to produce evidence to support your precise
target; managers tend to guesstimate, or guess at the estimates,
• Political pressures
– Managers may wish to reduce estimated costs in order to win
support for acceptance of a project proposal or pad their
estimates so that they are safe..
• Changing technologies
– these bring uncertainties, especially in the early days when there
is a ‘learning curve’+
– Experience on one project may not be applicable to another
• Estimate accuracy varies wildly esp in software industry
SPM (5e) Software effort estimation© The McGraw-Hill Companies, 2009 16
8
26-Mar-21
Approaches for Estimating Project Times

and Costs
• Consensus methods
• Ratio and apportion methods
• Function point methods for
software and system projects
Project Estimate
Times
• Learning curves (Not included) Costs
Some can work both top-down and

bottom up..
5–17
Apportion Method of Allocating Project Costs

Using the Work Breakdown Structure
FIGURE 5.1
5–18
9
26-Mar-21
WBS Figure
Exercise Figure 5.1

5–19
Consensus Methods: Delphi Technique
• Involves multiple, anonymous experts (or can

be conducted in an group, with outliers
explaining themselves)
• Each expert makes an estimate
• Estimates compared and reported
– If close, can be averaged
– If not, do another iteration until consensus is
reached
• Are you estimating the duration of task or its
size?
– Usually estimate theCopyright
size, then turn into duration
2015 John Wiley & Sons, Inc.
5-20
10
26-Mar-21
The Delphi Technique
Third Pass
Second Pass
First Pass
Poker Planning
• Variation of Delphi Technique used in agile
• Uses a deck of cards that represents an estimate in
days or relative effort (or story points – akin to
function points, but not standardized)
• Moderator (product owner usually) describes
particular task, feature, deliverable, or user story to be
estimated.
• Attempts to reach consensus in a few rounds of “play”
• What is the disadvantage of not being anonymous?

• See HW2…
Copyright 2015 John Wiley & Sons, Inc.
Copyright © 2018 McGraw-Hill Education. All5-22
rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.
11
26-Mar-21
Poker Planning
0, 1, 2, 3, 5, 8, 13, 20, 40 and 100; sometimes

“pass” cards too.. All revealed at the same time..
Averages not recommended, consensus sought..
• Ref:
https://www.mountaingoatsoftware.com/agile/
planning-poker
Copyright 2015 John Wiley & Sons, Inc.
Copyright © 2018 McGraw-Hill Education. All5-23
rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.
Relative Estimation – T Shirt cards
5–24
12
26-Mar-21
A few notes Time Estimates

• Estimated Effort in terms of task duration is
usually in person-hours; person-days; or person-
months
• Usually assumed to be 8 hour days 5 working
days, and 4 weeks in a month, that is 160 hours
in person-months of uninterrupted work
• What about the time we spend communicating,
drinking coffee etc?
– While scheduling, we find elapsed time by dividing
task duration with an efficiency factor (usually 0.6-
0.75) eg. 10/0.75 = 13 hours 20 mins
25
Functional Size Measurement

• Current Variants: Albrecht/IFPUG, NESMA, COSMIC,
Symons/MarkII, UCP
• “Function Point is NOT an effort measure; functional size
is not enough for cost and effort estimation
• Functional size determines how much functionality
software provides by measuring the aggregate amount
of cohesive execution sequences of the software as
defined by functional user requirements.
• Functional size is derived through the identification and
quantification of the base functional components (BFCs)
as defined by a measurement method. The sum of
functionalities (BFCs) determines the functional size of
the software.” (Ozkan and Demirors, 2016; Gencel and
Demirörs, 2009)
5–26
13
26-Mar-21
• Functional Size Measurement is not the same

thing as Functional Size Estimation (Early
Function Point Analysis (IFPUG, NESMA) uses
estimates by using default levels of complexity
etc.
• When measured using different methods, a
software product has different functional sizes.
Each method defines different functional size
units and as a result 1 IFPUG Function Point is
not equal to 1 COSMIC Function point (CFP)
5–27
• All points are NOT function points, see story

points… a story point is mostly defined as a
relative unit of “hardness” or “difficulty” of
developing a user story in agile where user
stories are pieces of user requirements of a
particular project.
• ISO 14143 multi-part standard on functional
software size measurement
5–28
14
26-Mar-21
• Productivity in general is output/input

• In software development Output can be in FPs
and Input is the effort in person-days (or
whatever) you put in the software development..
• Thus productivity measure becomes FP/person-
days or person-months
5–29
Turning Functional Size into Effort

• Estimated Effort (in person-hours or person-
days)= Size (in FPs) / Productivity (e.g. FP per
person-hours or person-days) .
• Productivity is also sometimes called
productivity rate. (FP/person-days for example)
• 1/productivity is the amount of person-hours or
days to implement one FP…
• If productivity average is five FPs in one person-
month, how do you turn into hours/FP?
• Heuristics: 4 ~ 15 person-hours per FP (IFPUG)
but has to be adjusted..
5–30
15
26-Mar-21
Why do we measure FP?

• Effort per function point
• Defects per function point
• Cost per function point –
– Contracts – negotiations between suppliers and
acquirers possible
• Price-per-FP
• Productivity based model
• Baseline based model – Service Level Agreement – price per
FP is adjusted
– Quality Models such as CMMI hold it as a mandate
– Performance Evaluation of Developers??!!
31
Automatic Software Estimation

• Sofware Risk Master www.namcook.com
• Price S www.pricesystems.com
• Slim www.qsm.com
• Seer www.galorath.com
• SystemStar and CoStar
http://www.softstarsystems.com/
• KnowledgePlan www.spr.com
• IFPUG’s FP guidelines say if more than 2K FPs,
automatic software estimation is said to make a
positive difference in correct estimation…
32
16
26-Mar-21
Parametric models
• Early models focus on productivity: e.g.

COCOMO
• Lines of code (or FPs etc) an input
System Estimated effort
size
Productivity
factors
Why is Source Lines of Code not considered a

good estimate or measure of effort?
..
Functional Size
Measurement (IFPUG style)
External
External Input Application Being Considered Interface Files
External Output Internal External Input

Logical
File
External Inquiry
External Output
Other
Applications
External Inquiry
• Functionality as viewed from the user’s perspective
34 © Copyright 2001. International Function Point User Group 2001
17
26-Mar-21
..
Steps in FP Counting
• Determine Type of Count

• Identify Counting Scope and Application
Boundary
• Count Data Functions
• Count Transactional Functions
• Determine Unadjusted Function Point
Count
• Determine Value Adjustment Factor
• Calculate Adjusted Function Point Count
..
FP Overview: What Is
Counted
EI P1
Update Master File
P2 EO Weekly
ILF Master
Produce Weekly Report
Summary
Report
File
System
Boundary
Key Reference
P3
Master File File
Details Details
on EIF
another
System
EQ
18
26-Mar-21
..
Function Points
EIF
EO
ILF
EO
37
©USC-CSSE 11/06/2017
..
Data Storage
• Internal Logical File (ILF)

Logical group of data maintained
by the application (e.g., Employee
file)
• External Interface File (EIF)

Logical group of data referenced
but not maintained (e.g., Global
state table)
19
26-Mar-21
..
Transactions
• External Input (EI)

Maintains ILF or passes control
data into the application
• External Output (EO)

Formatted data sent out of
application with added value (e.g.,
calculated totals)
• External Query (EQ)

Formatted data sent out of
application without added value
..
Functional Size
(Unadjusted Function Size)
Count the number of each item and multiply by its
weight factor
Function Type Low Average High
EI x3 x4 x6
EO x4 x5 x7
EQ x3 x4 x6
ILF x7 x 10 x 15
EIF x5 x7 x 10
20
26-Mar-21
..
Function Points
Transaction Functions:
Transaction Function:
EI – External Input
EO – Ext. Output
EQ – Ext. Queries
Classified by:
DET – Data Element Type
FTR - File Type Referenced
Data Functions:
Data Function:
ILF – Internal Logical File
EIF – External Interface File
Classified by:
DET – Data Element Type
RET - Record Element Type L : low
A:average
Adopted from Qi (2017), H: high
©USC-CSSE
41 11/06/2017
..
Example: Function Point Count Method
Note that the complexity factors are different in these

slides.
TABLE 5.3
5–42
21
26-Mar-21
..
Value Adjustment Factor
• Based on 14 General System

Characteristics (User Business
Constraints Independent of Technology)
– Examples: data communications, response
times, end user efficiency, multiple sites
and flexibility
• Adjusts FP count by up to + / - 35%
..
Function Points (2/3)

General System Characteristics General System Characteristics Cntd.
• Data communications • Installation ease

• Distributed data processing • Operational ease
• Performance • Multiple sites
• Heavily used configuration • Facilitate change
• Transaction rate
• Online data entry Value Adjustment Factor (VAF)
•
(åCi )
End-user efficiency
• Online update VAF = 0.65 +
• Complex processing 100
• Reusability
Where Ci is the rating of each characteristic
44
©USC-CSSE 11/06/2017
22
26-Mar-21
..
Where do we get the multipliers

such as 0.65 or 0.01?
(åCi )
VAF = 0.65 +
100
..
Examples
Payroll application has:

1. Transaction to input, amend and delete employee details
– an EI that is rated of medium complexity
2. A transaction that calculates pay details from timesheet
data that is input – an EI of high complexity
3. A transaction of medium complexity that prints out
pay-to-date details for each employee – EO
4. A file of payroll details for each employee – assessed as
of medium complexity ILF
5. A personnel file maintained by another system is
accessed for name and address details – a simple EIF
What would be the FP counts for these?
46 SPM (5e) Software effort estimation© The McGraw-Hill Companies, 2009
23
26-Mar-21
..
FP counts
1. Medium EI 4 FPs
2. High complexity EI 6 FPs
3. Medium complexity EO 5 FPs
4. Medium complexity ILF 10 FPs
5. Simple EIF 5 FPs
Total 30 FPs
If previous projects delivered 5 FPs a person-month,
implementing the above should take 30/5 = 6 person-months in
an unadjusted way
47 SPM (5e) Software effort estimation© The McGraw-Hill Companies, 2009
..
Influence Factors (or General System

Characteristics – GSC)
 Function point total is
adjusted by the influence
factors: Influence factors (example)
– Influence factors range Data communications
Distributed functions
2
0
from 0 to 5 (very simple to Performance objectives 3
Heavily used configuration 3
very complex or very low Transaction rate 4
to very high) On-line data entry 4
End-user efficiency 3
– Total Degree of On line update
Complex processing
2
3
Influence(TDI) Reusability 2
Installation ease 3
= Sum of the influence Operational ease 4
Multiple sites 5
factors Facilitate change 3
•TDI 41
– Value Adjustment Factor •VAF 1.06
•Function points ...
(VAF)
= 0.65 + (0.01 * TDI)
– Function Points
= VAF * unadjusted FP
24
26-Mar-21
Q!
• What about non functional requirements?
Technical or quality requirements?
• What about embedded software, reused code
etc?
49
IFPUG’s SNAP
• Software Nonfunctional Assessment Process
• Deals with nonfunctional requirements
• Used in addition to Function Points but not
directly additive
50
25
26-Mar-21
COCOMO II (Not a Functional Size

Measurement Method per se!)
• The core early design model is:
pm = A(size)(sf) ×(em1) ×(em2) ×(em3)….
where pm = person months, A is 2.94, size
is in KSLOC (thousand source lines of code),
or converted from function points or object
points; sf are additive scale factors put into
exponential use, and emi is an effort
multiplier for the ith cost driver.
Where do we get the multipliers such as A?
COCOMO II Scale factor

Based on five factors which appear to be
particularly sensitive to system size
1. Precedentedness (PREC). Degree to
which there are past examples that can be
consulted
2. Development flexibility (FLEX). Degree of
flexibility that exists when implementing the
project
3. Architecture/risk resolution (RESL). Degree
of uncertainty about requirements
4. Team cohesion (TEAM).
5. Process maturity (PMAT) could be
assessed by CMMI –
26
26-Mar-21
COCOMO II Scale factor values
Driver Very low Low Nom-inal High Very Extra

high high
PREC 6.20 4.96 3.72 2.48 1.24 0.00
FLEX 5.07 4.05 3.04 2.03 1.01 0.00
RESL 7.07 5.65 4.24 2.83 1.41 0.00
TEAM 5.48 4.38 3.29 2.19 1.10 0.00
PMAT 7.80 6.24 4.68 3.12 1.56 0.00
Example of scale factor

• A software development team is developing
an application which is very similar to
previous ones it has developed.
• A very precise software engineering
document lays down very strict requirements.
PREC is very high (score 1.24).
• FLEX is very low (score 5.07).
• The good news is that these tight
requirements are unlikely to change (RESL is
high with a score 2.83).
• The team is tightly knit (TEAM has high score
of 2.19), but processes are informal (so
PMAT is low and scores 6.24)
27
26-Mar-21
Scale factor calculation
The formula for sf is

sf = B + 0.01 × Σ scale factor values
i.e. sf = 0.91 + 0.01
× (1.24 + 5.07 + 2.83 + 2.19 + 6.24)
= 1.0857
If system contained 10 kloc then estimate would be 2.94 x
101.0857 = 35.8 person months
Using exponentiation (‘to the power of’) adds disproportionately
more to the estimates for larger applications
Development effort multipliers (dem)
According to COCOMO, the major productivity drivers include:

Product attributes: required reliability, database size, product complexity
Computer attributes: execution time constraints, storage constraints,
platform volatility
Personnel attributes: analyst capability, application experience, VM
experience, programming language experience
Project attributes: modern programming practices, software tools,
schedule constraints
some of them early design and some of them post-architecture level.
28
26-Mar-21
Effort multipliers
As well as the scale factor effort multipliers are
also assessed (early design):
RCPX Product reliability and complexity
RUSE Reuse required
PDIF Platform difficulty
PERS Personnel capability
FCIL Facilities available
SCED Schedule pressure
PREX Personnel experience
Effort multipliers
Extra Very low Low Nom-inal High Very Extra

low high high
RCPX 0.49 0.60 0.83 1.00 1.33 1.91 2.72
RUSE 0.95 1.00 1.07 1.15 1.24
PDIF 0.87 1.00 1.29 1.81 2.61
PERS 2.12 1.62 1.26 1.00 0.83 0.63 0.50
PREX 1.59 1.33 1.12 1.00 0.87 0.74 0.62
FCIL 1.43 1.30 1.10 1.00 0.87 0.73 0.62
SCED 1.43 1.14 1.00 1.00 1.00
29
26-Mar-21
Example
• Say that a new project is similar in most characteristics to those that

an organization has been dealing for some time
• except
– the software to be produced is exceptionally complex and will be
used in a safety critical system.
– The software will interface with a new operating system that is
currently in beta status.
– To deal with this the team allocated to the job are regarded as
exceptionally good, but do not have a lot of experience on this
type of software.
Example -continued
RCPX very high 1.91
PDIF very high 1.81
PERS extra high 0.50
PREX nominal 1.00
All other factors are nominal
Say estimate is 35.8 person months
With effort multipliers this becomes 35.8 x 1.91 x
1.81 x 0.5 = 61.9 person months
30
26-Mar-21
User view of Software for COSMIC
The COSMIC Generic Software Model

Principles
• A piece of software interacts with its functional users across a boundary,
and with persistent storage within this boundary.
• Functional user requirements of a piece of software to be measured can
be mapped into unique functional processes.
• Each functional process consists of sub-processes.
• A sub-process may be either a data movement or a data manipulation.
• A data movement moves a single data group.
• There are four data movement types, Entry, Exit, Write and Read.
– An Entry moves a data group into a functional process from a functional user.
– An Exit moves a data group out of a functional process to a functional user.
– A Write moves a data group from a functional process to persistent storage.
– A Read moves a data group from persistent storage to a functional process.
• A data group consists of a unique set of data attributes that describe a
single object of interest
31
26-Mar-21
COSMIC Unit of Measurement

• 1 CFP (Cosmic Function Point) is the size of one
data movement
• The size of a functional process is equal to the
number of its data movements.
• The functional size of a piece of software of
defined scope is equal to the sum of the sizes of
its functional processes.
The Mapping Phase
32
26-Mar-21
Example
• What are the functional processes of the following?
«Employee data is to be updated. User knows the
name but needs employee ID.
For this, application lists all employees, user selects
the employee, the application retrieves and list
employee’s details, user updates the information»
Functional Processes for this case are:
F1: User lists all the employees sorted by their name
F2: User selects the employee and list employment
details
F3: User updates employee’s information
The mapping phase

• An ENTRY (E) : Moves a Data Group type from a user
across the boundary into the functional process type
where it is required
• An EXIT (X): moves a Data Group type from a functional
process across the boundary to the user that requires it
– a single Exit shall be identified to represent all these message
occurrences within each functional process (OOI: errorindicator)
– a message passed on from the operating system: ‘printer X is
not responding’
• A READ (R) : moves a data group type from persistent
storage within reach of the functional process which
requires it
• A WRITE (W) : moves a data group type lying inside a
Functional Process to persistent storage
33
26-Mar-21
The Measurement Phase

• 1 CFP (Cosmic Function Point) which is defined
as the size of one data movement.
34
26-Mar-21
Example
• The task is to update an employee record,
where the user knows the employee’s name but
not the unique employee ID.
• How does COSMIC deal with non functional

requirements and project restrictions?
• Agile, DevOps etc adaptations are work in
progress of both IFPUG and COSMIC, still lot of
work and not always work.. So which way to go?
5–70
35
26-Mar-21
Bottom-Up Approaches for Estimating

Project Times and Costs
• Template methods
• Parametric procedures
applied to specific tasks
• Range estimates for
the WBS work packages
• Phase estimating: A hybrid
5–71
Range Estimating Template
FIGURE 5.2
5–72
36
26-Mar-21
Phase Estimating over Product Life Cycle
FIGURE 5.3
5–73
Top-Down and Bottom-Up Estimates
FIGURE 5.4
5–74
37
26-Mar-21
Level of Detail
• Level of detail in the WBS varies with the

complexity of the project, the need for control,
the project size, cost, duration, and other
factors.
• Excessive detail is costly.
– Fosters a focus on departmental outcomes rather
than on deliverable outcomes
– Creates unproductive paperwork
• Insufficient detail is costly.
– Lack of focus on goals
– Wasted effort on nonessential activities
5–75
Types of Costs
• Direct Costs
– Costs that are clearly chargeable to a specific work
package.
• Labor, materials, equipment, and other
• Direct (Project) Overhead Costs

– Costs incurred that are directly tied to project
deliverables or work packages.
• Salary of the project manager, rents, supplies, specialized
machinery
• General and Administrative Overhead Costs
– Organization costs indirectly linked to a specific
package that are apportioned to the project.
5–76
38
26-Mar-21
Contract Bid Summary Costs
Direct costs $80,000

Direct overhead $20,000
Total direct costs $100,000
G&A overhead (20%) $20,000
Total costs $120,000
Profit (20%) $24,000
Total bid $144,000
FIGURE 5.5
5–77
Three Views of Cost
FIGURE 5.6
5–78
39
26-Mar-21
Refining Estimates
• Reasons for Adjusting Estimates
– Interaction costs are hidden in estimates.
– Normal conditions do not apply.
– Things go wrong on projects.
– Changes in project scope and plans
– Overly optimistic
– Strategic misrepresentation
• Adjusting Estimates
– Time and cost estimates of specific activities are
adjusted as the risks, resources, and situation
particulars become more clearly defined.
5–79
Estimating Database Templates
FIGURE 5.7
5–80
40
26-Mar-21
Mega Projects: A Special Case
• Mega Projects
– Are large-scale, complex ventures that typically cost
$1 billion or more, take many years to complete, and
involve multiple private and public stakeholders.
• High-speed rail lines, airports, healthcare reform, the
Olympics, development of new aircraft
– Often involve a double whammy.
• Cost much more than expected but underdelivered on
benefits they were to provide.
– Are sometimes called “White Elephants”
• Over budget, under value, high cost of maintaining (exceeds
the benefits received)
5–81
Three Steps of the Reference Class

Forecasting (RCF) Process
• Select a reference class of projects similar to

your potential projects.
• Collect and arrange outcome data as a
distribution. Create a distribution of cost
overruns as a percentage of the original project
estimate.
• Use the distribution data to arrive at a realistic
forecast. Compare the original cost estimate for
the project with the reference class projects.
5–82
41
26-Mar-21
Benefits
- Outside empirical data mitigates human bias.
- Politics, strategic, and promoter forces have difficulty
ignoring outside RCF information.
- RCF serves as a reality check for funding large
projects.
- RCF helps executives avoid unsound optimism.
- RCF leads to improved accountability.
- RCF provides a basis for project contingency funds.

5–83
Key Terms
Apportionment Phase estimating

Bottom-up estimates Range estimating
Delphi method Ratio methods
Direct costs Reference class forecasting (RCF)
Function points Template method
Learning curves Time and cost databases
Overhead costs Top-down estimates
Padding estimates White elephant
5–84
42

Chapter Five: Estimating Project Times and Costs

Uploaded by

Copyright:

Available Formats

You might also like

Chapter Five: Estimating Project Times and Costs

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter Five: Estimating Project Times and Costs

Uploaded by

Copyright:

Available Formats

26-Mar-21

Where We Are Now

Suggested Readings and Links

• Extra Readings for Software Size Estimation:

• NESMA Netherlands Software Metrics users

1. Understand estimating project times and costs are the

Why Estimating Time and Cost Is Important

• To support good decisions

Factors Influencing the Quality of Estimates

Padding Project Structure

Estimating Guidelines for Times,

1. Have people familiar with the tasks make the estimate

Developing Work Package Estimates

Assume tasks Use consistent

Top-Down versus Bottom-Up Estimating

Top-Down versus Bottom-Up Estimating

Conditions for Preferring Top-Down or

Estimating Projects: Preferred Approach

• Make rough top-down estimates

Some problems with estimating

• Subjective nature of much of estimating

Approaches for Estimating Project Times

Some can work both top-down and

Apportion Method of Allocating Project Costs

Exercise Figure 5.1

Consensus Methods: Delphi Technique

• Involves multiple, anonymous experts (or can

The Delphi Technique

• What is the disadvantage of not being anonymous?

0, 1, 2, 3, 5, 8, 13, 20, 40 and 100; sometimes

Relative Estimation – T Shirt cards

A few notes Time Estimates

Functional Size Measurement

• Functional Size Measurement is not the same

• All points are NOT function points, see story

• Productivity in general is output/input

Turning Functional Size into Effort

Why do we measure FP?

Automatic Software Estimation

• Early models focus on productivity: e.g.

Why is Source Lines of Code not considered a

External Output Internal External Input

• Functionality as viewed from the user’s perspective

34 © Copyright 2001. International Function Point User Group 2001

• Determine Type of Count

36 © Copyright 2001. International Function Point User Group 2001

• Internal Logical File (ILF)

• External Interface File (EIF)

38 © Copyright 2001. International Function Point User Group 2001

• External Input (EI)

• External Output (EO)

• External Query (EQ)

Function Type Low Average High

40 © Copyright 2001. International Function Point User Group 2001

Example: Function Point Count Method

Note that the complexity factors are different in these

Value Adjustment Factor

• Based on 14 General System