Software Effort Estimation
Software Effort Estimation
Software Effort Estimation
ESTIMATION
1
The McGraw-Hill Companies, 2005
What makes a successful
project?
Delivering: Stages:
agreed functionality 1. set targets
on time 2. Attempt to achieve
at the agreed cost targets
with the required
quality
3
The McGraw-Hill Companies, 2005
A taxonomy of estimating
methods
Top down
Bottom-up - activity based, analytical
Parametric or algorithmic models e.g.
function points
Expert opinion - just guessing?
Analogy - case-based, comparative
Parkinson
price to win
4
The McGraw-Hill Companies, 2005
Bottom-up versus top-down
Bottom-up
use when no past project data
identify all tasks that have to be done so quite
time-consuming
use when you have no data about similar past
projects
Top-down
produce overall estimate based on project cost
drivers
based on past project data
divide overall estimate between jobs to be done
5
The McGraw-Hill Companies, 2005
Bottom-up estimating
1. Break project into smaller and smaller
components
2. Stop when you get to what one person
can do in one/two weeks]
3. Estimate costs for the lowest level
activities
4. At each higher level calculate estimate
by adding estimates for lower levels
6
The McGraw-Hill Companies, 2005
Top-down estimates
Estimate
100 days Produce overall
overall
project estimate using effort
driver (s)
7
The McGraw-Hill Companies, 2005
Algorithmic/Parametric models
9
The McGraw-Hill Companies, 2005
Parametric models - the
need for historical data
simplistic model for an estimate
estimated effort = (system size) /
productivity
e.g.
system size = lines of code
productivity = lines of code per day
productivity = (system size) / effort
based on past projects
10
The McGraw-Hill Companies, 2005
Parametric models
Some models focus on task or system
size e.g. Function Points
FPs originally used to estimate Lines of
Code, rather than effort
Number
of file types
model system
size
Numbers of input
and output transaction types
11
The McGraw-Hill Companies, 2005
Parametric models
Other models focus on productivity: e.g.
COCOMO
Lines of code (or FPs etc) an input
Estimated effort
System
size
Productivity
factors
12
The McGraw-Hill Companies, 2005
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
13
The McGraw-Hill Companies, 2005
Function points Mk II
continued
For each
transaction,
#entities count
accessed data items input
(Ni)
data items
output (No)
#input #output entity types
items items accessed (Ne)
Higher layers
Makes a request
Receives service
for a service
Lower layers
16
The McGraw-Hill Companies, 2005
COSMIC FPs
The following are counted:
Entries: movement of data into software
component from a higher layer or a peer
component
Exits: movements of data out
Reads: data movement from persistent storage
Writes: data movement to persistent storage
Each counts as 1 COSMIC functional size unit
(Cfsu)
17
The McGraw-Hill Companies, 2005
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
18
The McGraw-Hill Companies, 2005
The COCOMO constants
System type c k
Organic (broadly, 2.4 1.05
information systems)
Semi-detached 3.0 1.12
19
The McGraw-Hill Companies, 2005
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, virtual machine (VM) volatility
Personnel attributes: analyst capability,
application experience, VM experience,
programming language experience
Project attributes: modern programming
practices, software tools, schedule constraints
20
The McGraw-Hill Companies, 2005
Using COCOMO development
effort multipliers (dem)
An example: for analyst capability:
Assess capability as very low, low, nominal,
high or very high
Extract multiplier:
very low 1.46
low 1.19
nominal 1.00
high 0.80
very high 0.71
Adjust nominal estimate e.g. 32.6 x 0.80 =
26.8 staff months
21
The McGraw-Hill Companies, 2005
Estimating by analogy
Use effort
source cases
from source as
estimate
attribute values effort
23
The McGraw-Hill Companies, 2005
Machine assistance for source
selection (ANGEL)
Source A
Source B
It-Is
Ot-Os
target
Number of outputs
25
The McGraw-Hill Companies, 2005