1. Software project management (intro)
Introduction to estimating development effort

2. What makes a successful project?
Delivering:
agreed functionality
on time
at the agreed cost
with the required quality
Stages:
1. set targets
2. Attempt to achieve targets
BUT what if the targets are not achievable?

3. Over and under-estimating
Parkinson’s Law: ‘Work expands to fill the time available’
An over-estimate is likely to cause project to take longer than it would otherwise
Weinberg’s Zeroth Law of reliability: ‘a software project that does not have to meet a reliability requirement can meet any other requirement’

4. A taxonomy of estimating methods
Expert opinion - just guessing?
Bottom-up - activity based
Parametric e.g. function points
Analogy
artificial neural networks - a view of the future?
Parkinson and ‘price to win’

5. Heemstra and Kusters survey
Expert judgement %
Analogy %
‘Capacity problem’ 20.8%
Price-to-win 8.9%
Parametric models 13.7%

6. Heemstra and Kusters contd.
Only 50% kept project data on past projects - but 60.8% used analogy!
35% did not produce estimates
62% used methods based on intuition - only 16% used formalized methods
Function point users produced worse estimates!

7. Top-down versus Bottom-up
produce overall estimate based on project cost drivers
based on past project data
Bottom-up
use when no past project data

8. Top-down estimates Produce overall estimate using effort driver(s)
distribute proportions of overall estimate to components
Estimate
100 days
overall
project
design
code
test
30%
i.e.
30 days
30%
i.e.
30 days
40%
i.e. 40 days

9. 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

10. Parametric models
COCOMO (lines of code) and function points examples of these
Problem with COCOMO etc:
guess
algorithm
estimate
but what is desired is
system
characteristic
algorithm
estimate

11. Parametric models - continued
Examples of system characteristics
no of screens x 4 hours
no of reports x 2 days
no of entity types x 2 days
the quantitative relationship between the input and output products of a process can be used as the basis of a parametric model

12. 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

13. and output transaction types
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

14. Parametric models Other models focus on productivity: e.g. COCOMO
Lines of code (or FPs etc) an input
System
size
Estimated effort
Productivity
factors

15. COCOMO
Based on industry productivity standards - database is constantly updated
Allows an organization to benchmark its software development productivity

16. COCOMO – Examples Boehm simple model E = a * (KLOC)b D = 2.5 (E)d
Coefficient table
S/W Project ab bb db
Organic
2.4
1.05
0.38
Semi detached
3.0
1.12
0.35
Embedded
3.6
1.20
0.32

17. Estimating by analogy Use effort from source as estimate ?????
source cases
attribute values
effort
attribute values
effort
target case
attribute values
attribute values
?????
effort
attribute values
effort
effort
attribute values
attribute values
effort
Select case
with closet attribute
values

18. Anchor + adjustment pace distance on a bearing go to tall building
FOREST
go to tall building
by line of sight
FOREST
You are here:
how do you get to
red cross?

19. Estimating by analogy Identify significant attributes (‘drivers’)
locate closest match amongst source cases for target
adjust for differences between source and target

20. Machine assistance for source selection (ANGEL)
Source A
Source B
It-Is
Number of inputs
Ot-Os
target
Number of outputs
Euclidean distance = sq root ((It - Is)2 + (Ot - Os)2 )

21. 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

22. System size: function points
Based on work at IBM 1979 onwards
Albrecht and Gaffney wanted to measure the productivity independently of lines of code
has now been developed by the International FP User Group (which is US based)
Mark II FPs developed by Simons mainly used in UK

23. Albrecht function points
external interface files
internal
logical files
external
inputs
external
outputs
external inquiries

24. Function points are based on
2 ‘data function’ types
internal logical files (ILF)
external interface files (EIF)
3 ‘transactional function’ types
external inputs (EI)
external outputs (EO)
external inquiries (EQ)
Each occurrence is judged simple, average or complex

25. Albrecht FP weightings
FP = count total * ( *  (Fi)); i = 1 to 14

26. Taking Complexity into Account
0 (not important) to
5 (very important)
Factors are rated on a scale
Questions for Complexity Adjustment Values
Data communications
Backup and recovery
Distributed functions
Heavily used configurations
Transaction rate
On-line data entry
On-line update
End user efficiency
Complex processing
Installation ease
Operational ease
Multiple sites
Facilitate change
Reusable

27. Example: FP Approach

28. Some conclusions: how to review estimates
Ask the following questions about an estimate
What are the task size drivers?
What productivity rates have been used?
Is there an example of a previous project of about the same size?
Are there examples of where the productivity rates used have actually been found?