Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Software Project Management
Introduction to
Estimating Development Effort
(courtesy of “Software Project management –
Hughes & Cotterell” 4th Edition)
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
What Makes a Successful Project?
Delivering: agreed functionality on time at the agreed cost with the required
quality
Stages: set targets attempt to achieve
targets
BUT what if the targets are not achievable?
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
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
(http://www.heretical.com/
miscella/parkinsl.html)
Weinberg’s Zeroth Law of reliability: ‘a software project that does not have to meet a reliability requirement can meet any other requirement’
(http://eppsnet.com/tag/
jerry-weinberg)
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
A Taxonomy of Estimating Methods
Expert opinion - just guessing? Bottom-up - activity based Parametric e.g. function points Analogy Parkinson and ‘price to win’
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Estimation Techniques
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Heemstra and Kusters Survey
Expert judgement 25.5% Analogy 60.8% ‘Capacity problem’ 20.8% Price-to-win 8.9% Parametric models 13.7%
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Pricing to Win The project costs whatever the customer
has to spend on it. Advantages:
– You get the contract. Disadvantages:
– The probability that the customer gets the system he or she wants is small. Costs do not accurately reflect the work required.
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Heemstra and Kusters (cont.)
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!
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Top-down versus Bottom-up
Top-down– produce overall estimate based on project cost
drivers– based on past project data
Bottom-up– use when no past project data
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Top-down Estimates
Produce overall estimate using effort driver(s)
distribute proportions of overall estimate to components
design code
overall project
test
Estimate100 days
30%i.e.30 days
30%i.e.30 days
40%i.e. 40 days
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
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
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Parametric Models
COCOMO (lines of code) and function points examples of these problem with COCOMO etc:
guess algorithm estimate
but what is desired issystem
characteristicalgorithm estimate
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Parametric Models (cont.)
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
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Conventional Methods:LOC/FP Approach
Compute LOC/FP using estimates of information domain values
• Line of Code (LOC)• Function Point (FP)
Use historical effort for the project
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Example: LOC Approach
Functions
UICF
2DGA
3DGA
DSM
CGDF
PCF
DAM
Totals
estimated LOC $/LOC Cost Effort (months)LOC/pm
2340
5380
6800
3350
4950
2140
8400
33,360
14
20
20
18
22
28
18
315
220
220
240
200
140
300
32,000
107,000
136,000
60,000
109,000
60,000
151,000
655,000
7.4
24.4
30.9
13.9
24.7
15.2
28.0
145.0
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Example: FP Approach
number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces algorithms
measurement parameter
4 5 4 7 7 3
count
x x x x x x
count-total
= = = = = =
weight
complexity multiplier
feature points
0.25 p-m / FP = 120 p-m
40 25 12 4 4 60
160 125 48 28 28 180
569
.84
478
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
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
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Parametric models Some models focus on task or system size
e.g. Function Points FPs originally used to estimate Lines of
Code, rather than effortNumber
of file types
model
Numbers of input and output transaction types
‘systemsize’
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Parametric Models Other models focus on productivity: e.g.
COCOMO Lines of code (or FPs etc.) an input
SystemSize
Productivity Factors
Estimated Effort
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
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.
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 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(
Consumer Credit Trade Association): – should be compatible with SSADM; mainly
used in UK has developed in parallel to IFPUG FPs IFPUG (International Function Point Users Group)
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Function Points Mk II (Cont.) For each
transaction, count– data items input
(Ni)
– data items output (No)
– entity types accessed (Ne)
#entities accessed
#inputitems
#outputitems
FP count = Ni * 0.58 + Ne * 1.66 + No * 0.26
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Using Mark II Function Points Calculate FPs for each transaction in a
system Total transaction counts to get a count for
the system Recall that
estimated effort = size (FPs) x productivity rate (effort per FP)
Productivity rate obtained from past projects
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Estimating by Analogy
source cases
attribute values
effort
attribute values ?????
target case
attribute values
attribute values
attribute values
attribute values
attribute values
effort
effort
effort
effort
effortSelect case with closet attributevalues
Use effortfrom source as estimate
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Estimating by Analogy
Identify significant attributes (‘drivers’) Locate closest match amongst source cases
for target Adjust for differences between source and
target
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
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
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
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?
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Estimating the size of the measure (e.g. how many function points).
Estimating the total number of programmer months that have elapsed.
Estimating contractor productivity (e.g. documentation team) and incorporating this estimate in overall estimate.
Measurement Problems
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
System Development Times
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Real-time embedded systems, 40-160 LOC/P-month.
Systems programs , 150-400 LOC/P-month. Commercial applications, 200-900
LOC/P-month. In object points, productivity has been
measured between 4 and 50 object points/month depending on tool support and developer capability.
Productivity Estimates
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Changing Technologies Changing technologies may mean that previous
estimating experience does not carry over to new systems– Distributed object systems rather than mainframe
systems;– Use of web services;– Use of Enterprise Resource Planning (ERP) or
database-centred systems;– Use of off-the-shelf software;– Development for and with reuse;– Development using scripting languages;– The use of CASE tools and program generators.
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Estimate uncertainty
x
2x
4x
0.5x
0.25x
Feasibility Requirements Design Code Delivery
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
The COCOMO Model 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.
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
COCOMO 81
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
COCOMO 2 COCOMO 81 was developed with the
assumption that a waterfall process would be used and that all software would be developed from scratch.
Since its formulation, there have been many changes in software engineering practice and COCOMO 2 is designed to accommodate different approaches to software development.
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
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.
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Use of COCOMO 2 ModelsNumber of
application points
Number of functionpoints
Based on Used for
Used for
Used for
Used for
Based on
Based on
Based on
Number of lines ofcode reused or
generated
Number of lines ofsource code
Applicationcomposition model
Early design model
Reuse model
Post-architecturemodel
Prototype systemsdeveloped using
scripting, DBprogramming etc.
Initial effortestimation based onsystem requirementsand design options
Effort to integratereusable components
or automaticallygenerated code
Development effortbased on system
design specification
Guide to Computer Forensics and Investigations, 2eCC20O7N Software Engineering 1
Application Composition Model Supports prototyping projects and projects where
there is extensive reuse. Based on standard estimates of developer
productivity in application (object) points/month. Takes CASE tool use into account. Formula is
– PM = ( NAP (1 - %reuse/100 ) ) / PROD
– PM is the effort in person-months, NAP is the number of application points and PROD is the productivity.