Chapter 23

Project Planning

Chapter 23 Project 1
Planning
Estimation techniques

Chapter 23 Project 2
Planning
 Estimation techniques

 Organizations need to make software effort and cost estimates.

 There are two types of technique that can be used to do

this:
 Experience-based techniques The estimate of future effort
requirements is based on the manager’s experience of past projects and
the application domain. Essentially, the manager makes an informed
judgment of what the effort requirements are likely to be.

 Algorithmic cost modeling In this approach, a formulaic approach is

used to compute the project effort based on estimates of product
attributes, such as size, and process characteristics, such as experience
of staff involved.
Chapter 23 Project 3
Planning
Estimate uncertainty

Chapter 23 Project 4
Planning
Experience-based approaches
 Experience-based techniques rely on judgments based on
experience of past projects and the effort expended in these
projects on software development activities.
 Typically, you identify the deliverables to be produced in a
project and the different software components or systems that
are to be developed.
 You document these in a spreadsheet, estimate them
individually and compute the total effort required.
 It usually helps to get a group of people involved in the effort
estimation and to ask each member of the group to explain
their estimate.
Chapter 23 Project 5
Planning
Problem with experience-based approaches

 The difficulty with experience-based techniques is that a new

software project may not have much in common with previous
projects.
 Software development changes very quickly and a project will
often use unfamiliar techniques.
 If you have not worked with these techniques, your previous
experience may not help you to estimate the effort required,
making it more difficult to produce accurate costs and
schedule estimates.

Chapter 23 Project 6
Planning
 Algorithmic cost modelling
 Cost is estimated as a mathematical function of
product, project and process attributes whose values
are estimated by project managers:
 Effort = A * SizeB * M
 A is an organisation-dependent constant, B reflects the disproportionate
effort for large projects and M is a multiplier reflecting product, process
and people attributes.
 The most commonly used product attribute for cost
estimation is code size.
 Most models are similar but they use different values for A, B
and M.

Chapter 23 Project 7
Planning
 Estimation accuracy
 The size of a software system can only be known
accurately when it is finished.
 Several factors influence the final size
 Use of reused systems and components;
 Programming language;
 Distribution of system.
 As the development process progresses then the size
estimate becomes more accurate.

Chapter 23 Project 8
Planning
Effectiveness of algorithmic models

 Algorithmic cost models are a systematic way to estimate the

effort required to develop a system. However, these models
are complex and difficult to use.
 There are many attributes and considerable scope for
uncertainty in estimating their values.
 This complexity means that the practical application of
algorithmic cost modeling has been limited to a relatively small
number of large companies, mostly working in defense and
aerospace systems engineering.

Chapter 23 Project 9
Planning
COCOMO cost modeling

Chapter 23 Project 1
Planning 0
COCOMO cost modeling
 An empirical model based on project experience.
 Well-documented, ‘independent’ model which is not tied to a
specific software vendor.
 Long history from initial version published in 1981
(COCOMO-81) through various instantiations to
COCOMO 2.
 COCOMO 2 takes into account different approaches to
software development, reuse, etc.

Chapter 23 Project 1
Planning 1
 COCOMO
• Constructive Cost Model, developed by
Barry Boehm in 1981
• Most widely used and accepted of the
effort estimation models
• Predicts the effort and duration of a project
based on inputs relating to the size and a
number of "cost drives" that affect
productivity

Chapter 23 Project 1
Planning 2
 Original COCOMO
• Original COCOMO is a collection of three
– Basic
models
• Applied early in the project
– Intermediate
• After requirements are
specified
– Advanced/Detailed
• After a design is complete
• All three models take the form
• Size is in Thousands of Lines of Code
• Effort is in Staff Months, assuming 19 staff days per
staff month

Chapter 23 Project 1
Planning 3
 Three Levels of Difficulty
• Organic -- Fairly easy software, software
development team is familiar with application,
language, and tools.
– Typically from 2-50 KLOC

• Semi-Detached -- Average software, average

team, rigid requirements
– Typically 50-300 KLOC

• Embedded -- Severe constraints, large project

team, complex, innovative, real time, etc.
– No stated size range, but model is known to fall
under >300 KLOC Chapter
Planning
23 Project 1
4
 Three Levels of Difficulty
Organic Semi Detached Embedded

Size 2-50 KLOC 50-300 KLOC 300 & above KLOC

Team Size Small Size Medium size Large team

Developer Experienced developer Average Experience Very little

Experience needed Experience
Environment Familiar Environment Less familiar Significant changes
Almost new
Innovation Little Medium Major

Deadline Not tight Medium Very Tight

Payroll System Utility Air Traffic

System(compilers) monitoring System
Chapter 23 Project 1
Planning 5
 COCOMO Modes
• Boehm found that the calibration to COCOMO was
similar within each level of difficulty.
• Thus there are three COCOMO “modes” or “standard values
of a and b”

MODE a b
Organic 2.4 1.05
Semi- 3.0 1.12
Detached
Embedded 3.6 1.20
Chapter 23 Project 1
Planning 6
Basic COCOMO Equation in Graph Form

Three Cocomo Modes

400.00
embedded
300.00
semi-
200.00 detached
100.00
organic
0.00

Size (KLOC)

Chapter 23 Project 1
Planning 7
Example

Chapter 23 Project 1
Planning 8
COCOMO 2 models
 COCOMO 2 incorporates a range of sub-models that
produce increasingly detailed software estimates.
 The sub-models in COCOMO 2 are:
 Application composition model. Used when software is composed
from existing parts.
 Early design model. Used when requirements are available but
design has not yet started.
 Reuse model. Used to compute the effort of integrating reusable
components.
 Post-architecture model. Used once the system architecture has
been designed and more information about the system is
available.

Chapter 23 Project 1
Planning 9
 Algorithmic cost modelling
 Cost is estimated as a mathematical function of
product, project and process attributes whose values
are estimated by project managers:
 Effort = A * SizeB * M
 A is an organisation-dependent constant, B reflects the disproportionate
effort for large projects and M is a multiplier reflecting product, process
and people attributes.
 The most commonly used product attribute for cost
estimation is code size.
 Most models are similar but they use different values for A, B
and M.

Chapter 23 Project 2
Planning 0
 Estimation accuracy
 The size of a software system can only be known
accurately when it is finished.
 Several factors influence the final size
 Use of reused systems and components;
 Programming language;
 Distribution of system.
 As the development process progresses then the size
estimate becomes more accurate.

Chapter 23 Project 2
Planning 1
Albrecht/IFPUG function points

Albrecht worked at IBM and needed a way of measuring

the relative productivity of different programming
languages.
Needed some way of measuring the size of an application
without counting lines of code.
Identified five types of component or functionality in an
information system
Counted occurrences of each type of functionality in order
to get an indication of the size of an information system

2
3
2
4
Albrecht/IFPUG function
points - continued
Five function types
1. Logical interface file (LIF) types – equates roughly to
a datastore in systems analysis terms. Created and
accessed by the target system
2. External interface file types (EIF) – where data is
retrieved from a datastore which is actually
maintained by a different application.

2
5
 Albrecht/IFPUG function
points - continued

3. External input (EI) types – input transactions which

update internal computer files
4. External output (EO) types – transactions which
extract and display data from internal computer files.
Generally involves creating reports.
5. External inquiry (EQ) types – user initiated
transactions which provide information but do not
update computer files. Normally the user inputs some
data that guides the system to the information the user
needs.

2
6
Function Point

•UFP (Unadjusted Function Points):

•Raw count of the software’s functional components.
•Based on inputs, outputs, user interactions, and data storage.
•VAF (Value Adjustment Factor):
•Adjusts UFP based on external factors affecting software complexity.
•Calculated using a set of 14 general system characteristics.
•FP (Function Points):
•The final measure of the software’s complexity.
•Calculated as FP=UFP×VAF.

2
7
VAF Calculation

2
8
Example

2
9
Example

3
VAF = (TDI * 0.01) + 0.65. 0
3
1
Function points Mark II

Developed by Charles R. Symons

‘Software sizing and estimating - Mk II FPA’, Wiley &
Sons, 1991.
Builds on work by Albrecht
Work originally for CCTA:
should be compatible with SSADM; mainly used in UK
has developed in parallel to IFPUG FPs
A simpler method

3
2
 Function points for
embedded systems
Mark II function points, IFPUG function points were
designed for information systems environments
COSMIC FPs attempt to extend concept to embedded
systems
Embedded software seen as being in a particular ‘layer’ in
the system
Communicates with other layers and also other
components at same level

3
3
 COCOMO81

Based on industry productivity standards - database is

constantly updated
Allows an organization to benchmark its software
development productivity
Basic model
effort = c x sizek
C and k depend on the type of system: organic, semi-
detached, embedded
Size is measured in ‘kloc’ ie. Thousands of lines of code

3
4
3 types of COCOMO:

1- Basic Cocomo Model

2- Intermediate Cocomo Model

3- Detailed Cocomo Model

3
5
Difference

3
6
FYI:

3
7
1- Basic Cocomo

3
8
1- Example

39
2- Intermediate Cocomo
Model

4
0
EAF Table

41
2- Example

42
3- Detailed Cocomo Model

43
3- Example

44
4
5
4
6
4
7
4
8
4
9
COCOMO 2 models
 COCOMO 2 incorporates a range of sub-models that
produce increasingly detailed software estimates.
 The sub-models in COCOMO 2 are:
 Application composition model. Used when software is composed
from existing parts.
 Early design model. Used when requirements are available but
design has not yet started.
 Reuse model. Used to compute the effort of integrating reusable
components.
 Post-architecture model. Used once the system architecture has
been designed and more information about the system is
available.

Chapter 23 Project 5
Planning 0
COCOMO estimation models

Chapter 23 Project 5
Planning 1