Professional Documents
Culture Documents
CH 5 مُعدل
CH 5 مُعدل
Management
Chapter 5
4th Edition
Software effort
estimation
1
©The McGraw-Hill Companies, 2005
• A successful project is one delivered on
the time ,within budget and with
required quality ,this imply that targets
are set which the project manager then
tries to meet.
• Realistic estimates are therefore crucial
,incorrect initial estimate is a problem.
• As a project proceed the accuracy of
the estimates should improve as
knowedge increase.
2
©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
6
©The McGraw-Hill Companies, 2005
continued
• Parkinson and ‘price to win’
-where the staff of effort available to do
the project becomes the estimate.
- Where the estimates is a figure that
seem sufficiently to win a contract.
• top_down :where an overall estimates
for the whole project is broken down
into effort required for component
tasks. 7
©The McGraw-Hill Companies, 2005
Bottom-up versus top-down
• Project manager will prbly try to get a number of different
estimates from different people using different methods.
• Bottom up: calculate effort for each activity to get an overall
estimation (where the project is novel).
• 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
• Having calculated the overall effort, the problem is then to
allocate proportion of that effort to various
8
activity.
©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
9
©The McGraw-Hill Companies, 2005
Top-down estimates
Estimate
100 days • Produce overall
overall
project estimate using effort
driver (s)
10
©The McGraw-Hill Companies, 2005
Algorithmic/Parametric models
• COCOMO : constructive cost model
• A model to forecast software development
effort has two key components.
1- a method of assessing the amount of
work needed.
2- assess the rate of work at which the task
can be done.
•Parametric models:
1. Focus on task size, e.g. function point.
2. Focus on productivity factors e.g.
COCOMO.
11
©The McGraw-Hill Companies, 2005
Algorithmic/Parametric models
13
©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
14
©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
15
©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
16
©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
17
©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
20
©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)
21
©The McGraw-Hill Companies, 2005
COCOMO81
• Based on industry productivity standards - database is
constantly updated.
- Data base: containing the performance details of executed
project
• Allows an organization to benchmark its software
development productivity
• Basic model
effort = c x sizek
23
©The McGraw-Hill Companies, 2005
The COCOMO constants
-Boehm finding that target project
tended to be less productivity than
small one because they needed
more effort for management and
coordination
- Effort = 2.4 X 51.05 = 13.003
- Effort = 3.6 X 101.20 = 57.056
24
©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
25
©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
26
©The McGraw-Hill Companies, 2005
Estimating by analogy
Use effort
source cases
from source as
estimate
attribute values effort
28
©The McGraw-Hill Companies, 2005
Stages: identify
• Significant features of the current
project
• previous project(s) with similar features
• differences between the current and
previous projects
• possible reasons for error (risk)
• measures to reduce uncertainty
29
©The McGraw-Hill Companies, 2005
Machine assistance for source
selection (ANGEL)
Source A
Source B
It-Is
Ot-Os
target
Number of outputs
31
©The McGraw-Hill Companies, 2005
conclusion
• Use more than one method of estimating.
• collect as much info. as possible from
precion of …..
•Seek a range of onions.
•Document your method of doing estimates
and record all your assumptions.
•Be carful about using other historical
productivity ,especially if it comes from a
different environment.