SE 501 Software Development
Processes
Dr. Basit Qureshi
College of Computer Science and Information Systems
Prince Sultan University
Lecture for Week 5
Contents
• Estimation
– Process Oriented Estimation
– Parametric or Algorithmic Estimation
• FP Estimation
– FP example
• More on Estimation
– COCOMO II – An empirical estimation technique
• Assignment #3 and Summary
SE 501 Dr. Basit Qureshi
2
Bibliography
•
•
•
•
•
•
•
•
•
Pressman, Software Engineering: A practitioners Approach, 7th Ed. 2009 (chapters 24-25)
J. Baik, Managing Software Development, Lecture Notes on Estimation, School of Engineering,
Information and Communication University, 2007
Kitchenham, B., "The Problem with Function Points," Software, IEEE , vol.14, no.2, pp.29,31,
Mar/Apr 1997
Furey, S., "Why we should use function points [software metrics]," Software, IEEE , vol.14, no.2,
pp.28, 30,, Mar/Apr 1997
Jones, C., "Backfiring: converting lines of code to function points," Computer , vol.28, no.11,
pp.87,88, Nov 1995
Abran, A.; Robillard, P.N., "Function points analysis: an empirical study of its measurement
processes," Software Engineering, IEEE Transactions on , vol.22, no.12, pp.895,910, Dec 1996
Low, G.C.; Jeffery, D.R., "Function points in the estimation and evaluation of the software
process," Software Engineering, IEEE Transactions on , vol.16, no.1, pp.64,71, Jan 1990
Giachetti, G.; Marin, B.; Condori-Fernandez, N.; Molina, J.C., "Updating OO-Method Function
Points," Quality of Information and Communications Technology, 2007. QUATIC 2007. 6th
International Conference on the , vol., no., pp.55,64, 12-14 Sept. 2007
Jeffery, D.R.; Low, G.C.; Barnes, M., "A comparison of function point counting techniques,"
Software Engineering, IEEE Transactions on , vol.19, no.5, pp.529,532, May 1993
SE 501 Dr. Basit Qureshi
3
ESTIMATION…?
SE 501 Dr. Basit Qureshi
4
Estimation session objectives
• Learn when estimation will occur
• Learn some major estimation techniques
• Learn the uncertainty in estimation
SE 501 Dr. Basit Qureshi
5
When to Estimate
• Estimation during the bid
– Short duration, fastest possible, least understanding
• Estimation at project start
– Creating full plan, allocating resources, detailed
estimation
• Estimation during the project
– How do you handle change
SE 501 Dr. Basit Qureshi
6
When to Estimate
Critical Issues during bid estimation
•
•
•
•
Identify critical requirements
Understand how to create a rough order estimate
Understand how to apply reuse to improve estimates
Understand the level of effort needed to bid on a
project
SE 501 Dr. Basit Qureshi
7
Why Estimation
• 30% of project never complete
• 100-200% cost overruns not uncommon
• Average project exceeds cost by 90%; Schedule
by 120%
• 15% of large project never deliver anything
• Only 16.2% of projects are successful
• Standish Group Chaos Report 1999, 2003
SE 501 Dr. Basit Qureshi
8
Why Estimation
What are the consequences?
• Economic
– Loss of contracts
– Company failure
• Technical
– Dependency on software growing
• Managerial
– Change of personnel
SE 501 Dr. Basit Qureshi
9
Why Estimation
Why are we bad at estimating?
• Complexity of the systems
– Infrequency - How often do we do the “same thing”
• V.S. manufacturing or construction
– Underestimation bias
• Computers are “easy”; software is “easy”
– We deal with Goals not estimates
• Must be done by June
– Complexity is what makes estimating hard
SE 501 Dr. Basit Qureshi
10
Why Estimation
Why are we bad at estimating?
• Complexity of the systems
– ~1000 FP in a pace maker (50K)
– ~18,800 FP in shuttle test scaffolding (1,000,000 LOC)
– ~75,400 FP in Nynex Switch (4,000,000LOC)
“Human brain capacity is more or less fixed, but
software complexity grows at least as fast as the square
of the size of the project”- Tony Bowden
SE 501 Dr. Basit Qureshi
11
Estimation in the Bid
• No “real” money in the bid
• Must estimate on your dollar
• What is important for this estimate
– Can I compare to history?
• Done as quickly and cheaply as possible
• How important is it?
SE 501 Dr. Basit Qureshi
12
Estimation in the Bid
Determining “ development effort”
• Development effort measures
–
–
–
–
Person-Month
LOC per Hour
Function point per hour
Requirement per hour
• Most common is person-months (or hours)
• We will look at ways to get development effort
SE 501 Dr. Basit Qureshi
13
Estimation in the Bid
First look for “similarities”
• Have we done something similar
• Do we have data on that project
• How long ago was it
– Geometric loss of understanding
• Do we still have the expertise
– Expertise does not last
• Do we have the artifacts from that project
– Can we read them
SE 501 Dr. Basit Qureshi
14
Estimation in the Bid
Next look for “ differences”
• Do we understand the differences
• Do we have expertise in this new area
– Training cost time and money
– Can we get the expertise quickly
• Do we have a proxy for this difference
– Have we done something similar on other projects
SE 501 Dr. Basit Qureshi
15
Estimation in the Bid
Make a Conceptual Design
• Can we create a rough solution
– End to end
– How big or small should the parts be
• Can we estimate the parts
• Never confuse conceptual with actual design
– This is for estimating, you will re-do if you win the bid
SE 501 Dr. Basit Qureshi
16
Estimation in the Bid
Estimating Exercise 1
• How many footballs will it take to fill this room?
– How would you go about making the estimate?
– What do you need to know?
– What assumptions would you make?
SE 501 Dr. Basit Qureshi
17
Estimation in the Bid
Estimating Exercise 2
• If the project is well understood
– 2 months to deliver (40 days)
– 25 LOC per day per engineer
– Estimated 5000 LOC
– How many people needed?
What are the major assumptions above?
SE 501 Dr. Basit Qureshi
18
Improving Your Estimate:
Wideband Delphi
Six step process
– Planning – define the scope of the problem

Break large problems into smaller
– The Kickoff – To deliver problem to team
– Individual preparation – Everyone does individual estimates
on problem parts

All assumptions are written down
– Estimation Meeting – Everyone on team gets together
– Assembling Tasks – Put together the whole project of
estimates
– Review Results – Bring team back to review final results
Copyright@ICU 2007
19
The Delphi process in Wideband
 Estimation Meeting
– A moderator collects the estimates for the task being estimated
 Present the average or a line with all estimates (anonymous)
–
–
–
–
The estimate is discussed and assumptions presented
Moderator calls for a new estimate from everyone
Values are again presented to the team as average or line
Continue process until:
 Four rounds are completed
 The estimates “converged” to an acceptably narrow range
 The allotted meeting time is complete
 All participants are unwilling to change their estimates
– 15-20 minutes per item discussed
Copyright@ICU 2007
20
Rounds in Delphi
Copyright@ICU 2007
21
Rules to insure best results for Wideband
Delphi
 Gather a heterogeneous team
 Write down assumptions
 Make anonymous estimates*
 Never estimate tasks larger than you are
comfortable with
 This is “estimation”, not “prediction”
*Why?
Copyright@ICU 2007
22
Estimate Uncertainty
4x
2x
+
+
+
+
x
Cost ($)
+
+
+
1.25x
+
USAF/ESD
Proposals
+
1.5x
Relative
Size
Range
Size (DSI)
Completed
Programs
+
+
+
+
+
0.5x
Concept of
Operation
0.25x
Feasibility
Product
Design
Spec.
Rqts.
Spec.
Plans
and
Rqts.
Product
Design
Detail
Design
Spec.
Detail
Design
Phases and Milestones
Copyright@ICU
23
2007
Accepted
Software
Devel.
and
Test
Estimation before you begin the work
Understand how to create a detailed estimate
Know how to apply a work break down
structure
Know how to create metrics to evaluate the
quality of an estimate
Know how to use model based estimation
techniques
Copyright@ICU 2007
24
Software Cost Estimation
“Predicting the resources required for a
software development process” - Ian
Sommerville
Estimate noun [C] “an approximate
calculation or judgement of the size,
value, amount, cost, etc. of something”
- Cambridge Dictionary
Copyright@ICU 2007
25
Inputs and Outputs to the Estimation Process
Classical view of software estimation process
[Vigder/Kark]
Product Specs
Size
Size Drivers Estimator
Complexity
Constraints
Personnel Skill
Environment
Size
Schedule
Cost
Estimation Effort
Process Cost
Project
Estimate
COST DRIVERS
Copyright@ICU 2007
26
Detailed estimating
Major techniques
– Process oriented techniques
– Parametric or Algorithmic Methods
Copyright@ICU 2007
27
1. Most Common Size Estimation
Techniques (Process Oriented)
 The WAG (Wild Altogether Guess)
 Estimation by analogy
– Small Grain and Large Grain
“All analogy methods require a local, idiosyncratic, database”
 Expert experience
Copyright@ICU 2007
28
WAG - Wild Altogether Guess
Totally new environment
No historical data
No expertise in this area
No experts to contact
Research turns up no information
…Guess, but make sure you record this
Copyright@ICU 2007
29
Estimation by analogy
The method:
– The project manager identifies the values of certain
“similarity dimensions”
 dimensions are derived from the software specification
 include application type, size of application, language used, etc.
– The project manager compares with other “similar projects”
for a final estimate
Copyright@ICU 2007
30
Estimation by analogy (2)
Advantages
– Data is derived in an easily understandable way
– Complex domain-knowledge is not required, since
information depends on historical data
– Avoids problems commonly associated with knowledge
elicitation (i.e. erroneous estimation)
– Can be applied at a very early stage in production
Copyright@ICU
31
2007
Estimation by analogy (3)
Disadvantages
– You need a historical database that contains a large variety
of past projects
– The accuracy of this method is directly related to the size
and quality of the database available
– There is generally no guarantee that the historical
information about any specific project is completely
accurate
– Any inaccuracies contained in the historical data will have
an effect on the estimation for the current project
Copyright@ICU 2007
32
Experts judgment
 Expert judgment involves consulting with human
experts to use their experience and understanding of
a proposed project to provide an estimate for the cost
of the project.
– The expert can factor in differences between past project
experiences and requirements of the proposed project
– The expert can also factor in project impacts caused by new
technologies, applications, and languages
– Expert judgment always compliments other estimation
methodologies
– the estimates are no better than the expertise and judgment of the
expert (hard to document)
Copyright@ICU 2007
33
2. Parametric or Algorithmic Methods
The algorithmic method uses equations to
create software estimates
Advantages:
– being able to generate repeatable results
– easily modifying input data
– easily refining and customizing formulas
– understanding of the estimating methods as formulas can be analyzed
Copyright@ICU 2007
34
Parametric Or Algorithmic Methods
 Disadvantages:
– questionable results when estimating future projects with
new technologies
– end equations are unable to deal with exceptional conditions
such as
 exceptional personnel in any software cost estimating exercises
 exceptional teamwork
 an exceptional match between skill-levels and tasks
Copyright@ICU
35
2007
Function points
Based on a combination of program
characteristics
– external inputs and outputs
– user interactions
– external interfaces
– files used by the system
A weight is associated with each of these
The function point count is computed by
multiplying each raw count by the weight and
summing all values
Copyright@ICU 2007
36
Function points
Function point count modified by complexity of
the project
FPs can be used to estimate LOC depending on
a language factor
– LOC = AVC * number of function points
– AVC is a language-dependent factor
FPs can be very subjective, depend on estimator
– Automatic function-point counting maybe impossible
Copyright@ICU 2007
37
Function Point Estimation
Step One – System Size
System Elements and their Complexity
Description
Low
Medium
High
Total
Inputs
__x 3
__x 4
__x 6
____
Outputs
__x 4
__x 5
__x 7
____
Queries
__x 3
__x 4
__x 6
____
Files
__x 7
__x 10
__x 15
____
Program
Interfaces
__x 5
__x 7
__x 10
____
TOTAL UNADJUSTED FUNCTION POINTS
Copyright@ICU 2007
____
38
Function Point Basics
Count the following:
– inputs
– outputs
– inquiries
– logical internal files
– external interfaces
Apply “simple, average, complex” multipliers
Apply the 14 adjustment factors (such as
designed for reuse? in a heavy traffic
environment? etc.)
Copyright@ICU 2007
39
Function Points (14 factors)
 Compute the technical complexity
factor (TCF)
– Assign a value from 0 (“not present”) to
5 (“strong influence throughout”) to
each of 14 factors such as transaction
rates, portability
– Add 14 numbers  total degree of
influence (DI)
TCF = 0.65 + 0.01  DI
– Technical complexity factor (TCF) lies
between 0.65 and 1.35
 The number of function points (FP) is
given by
FP = UFP  TCF
Copyright@ICU 2007
40
Converting Function Points to Lines of Code
Language
LOC/Function Code Point
Access
C
C++
COBOL
Excel
HTML
JAVA
Javascript
Oracle
Perl
Powerbuilder
SQL
VBScript
Visual Basic
Web Scripts
35
162
66
77
47
47
62
58
30
60
32
40
36
47
44
Source: Quality Software Management (www.qsm.com)
Copyright@ICU 2007
41
FP ESTIMATION EXAMPLE
SE 501 Dr. Basit Qureshi
42
FP Estimation Example 1
• A system has 10 external inputs, 20 external
outputs, fields 25 different queries, manages 4
internal logical files, and interfaces with 4
different legacy systems (4EIF). All of these data
are of average complexity and the overall
system is relatively simple. Compute FP for the
system.
SE 501 Dr. Basit Qureshi
43
Function Points
Weighting factor
Information
Domain Value
Count
simple average complex
=
40
=
100
6
=
100
10
15
=
40
7
10
=
28
External Inputs (EIs)
10
3
4
6
External Outputs (EOs)
20
4
5
7
External Inquiries (EQs)
25
3
4
Internal Logical Files (ILFs)
4
7
5
External Interface Files (EIFs)
4
308
Count total
44
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright
FP Estimation Example 2
• Case Study: Delta Consulting Group plans to
automate accounts payable system.
• Read Accompanying document (Case study)
• Read Notes from Pressman (Chapter 23)
• Look at Solution provided (Website)
SE 501 Dr. Basit Qureshi
45
The Downside of Function Points
Difficult to be consistent across the set of
counters
Does not reflect internal complexity very well
Adjustments needed
– Symons on complexity1
– Reifer for real-time systems2
Must be converted to LOC; database needed
for each language (Organizational)
There is hope: IFPUG – Release of counting
standard, but you must be member
– See tool in zip provided
1 - Reifer, Donald J., Asset-R IFPUG Spring Conference, Baltimore, Maryland, April, 1991.
2 - Symons, Charles R., Mark II Function Points IEEE Transactions on Software Engineering, Vol. SE14, no. 1, January 1988
Copyright@ICU 2007
46
Algorithmic Code Modelling
 A formulaic approach based on historical cost
information and which is generally based on the size
of the software
 Examples are:
• Putnam’s Software Life-cycle Model (SLIM)
• COCOMO II
 Advantages:
 Its results are repeatable
 Objectiveness
• Disadvantages:
 Some subjective input is needed
Copyright@ICU 2007
47
Putnam’s Software LIfe-cycle Model (SLIM)
 Putnam used Software
and manpower-build
Equation
 This method makes use
of a so-called Rayleigh
curve to estimate
project effort, schedule
and defect rate
 Supported by
Quantitative Software
Management (QSM)
www.qsm.com
Copyright@ICU 2007
48
SLIM - Rayleigh
Math Model; Based on two formulas
– Quality of Function = Process Productivity * Effort *
Schedule
– Size = Process Productivity Parameter * (Effort / B)(1/3) *
Time ( 4/3)
Process Productivity – Historical data
Size – LOC, FP, etc.
B – Complexity measure
Effort – Development effort required (labor categories)
Time – elapsed calendar duration
Copyright@ICU 2007
49
Estimation for OO Projects-I




Develop estimates using effort decomposition, FP analysis,
and any other method that is applicable for conventional
applications.
Using object-oriented requirements modeling (Chapter 6),
develop use-cases and determine a count.
From the analysis model, determine the number of key classes
(called analysis classes in Chapter 6).
Categorize the type of interface for the application and develop
a multiplier for support classes:





Interface type
No GUI
Text-based user interface
GUI
Complex GUI
Multiplier
2.0
2.25
2.5
3.0
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
50
Estimation for OO Projects-II



Multiply the number of key classes (step 3) by the
multiplier to obtain an estimate for the number of support
classes.
Multiply the total number of classes (key + support) by
the average number of work-units per class. Lorenz and
Kidd suggest 15 to 20 person-days per class.
Cross check the class-based estimate by multiplying the
average number of work-units per use-case
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
51
Estimation for Agile Projects



Each user scenario (a mini-use-case) is considered separately
for estimation purposes.
The scenario is decomposed into the set of software
engineering tasks that will be required to develop it.
Each task is estimated separately. Note: estimation can be
based on historical data, an empirical model, or “experience.”


Estimates for each task are summed to create an estimate for
the scenario.


Alternatively, the ‘volume’ of the scenario can be estimated in LOC,
FP or some other volume-oriented measure (e.g., use-case count).
Alternatively, the volume estimate for the scenario is translated into
effort using historical data.
The effort estimates for all scenarios that are to be implemented
for a given software increment are summed to develop the effort
estimate for the increment.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
52
The Make-Buy Decision
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
53
Computing Expected Cost
expected cost =
(path probability) x (estimated path cost)
i
i
For example, the expected cost to build is:
expected cost
= 0.30 ($380K) + 0.70 ($450K)
build
= $429 K
similarly,
expected cost
expected cost
expected cost
reuse
buy
contr
= $382K
= $267K
= $410K
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
54
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 II
COCOMO II takes into account different
approaches to software development, reuse, etc.
http://sunset.usc.edu/research/COCOMOII/
Copyright@ICU 2007
55
COCOMO II
Main objectives of COCOMO II:
– To develop a software cost and schedule
estimation model tuned to the life cycle
practices of the 1990’s and 2000’s
– To develop software cost database and tool
support capabilities for continuous model
improvement
Copyright@ICU 2007
56
Technique comparison
Method
Strengths
Weakness
Algorithmic Model
Objective,
repeatable, analyzable formula
Efficient, good for sensitivity analysis
Objectively calibrated to experience
Subjective
Expert judgment
Assessment
of representative,
interactions, exceptional circumstance
No
Analogy
Based
Level
Parkinson’s Law
Correlates
Price to win
Often
on representative experience
with some experience
gets the contract
inputs
Assessment of exceptional
circumstances
Calibrated to past, not future
better than participants
Biases, incomplete recall
of experience
Reinforces
Generally
poor practice
produces large
overruns.
Top-down
System
level focus
Efficient
Less
detailed basis
Less stable
Bottom-up
More
May
detailed basis
More stable
Fosters individual commitments
Copyright@ICU 2007
overlook system level
costs
Requires more effort
57
Have customers ever changed requirements?
Are all changes a change in scope?
Do resources ever change?
Does the market for a project ever change?
What do you do?
Copyright@ICU 2007
58
Revising the Schedule
 Some reasons to revise:
– To correct errors
– To reflect changes in assumptions
– To reflect reductions in project scope (i.e., elimination of
activities[never happens])
– To reflect changes in the project calendar
– In response to changes in the approach taken to complete
an activity
– In response to changes in precedence relationships
Copyright@ICU 2007
59
Programmer productivity
A measure of the rate at which individual
engineers involved in software development
produce software and associated
documentation
Quality assurance is a factor in productivity
assessment
Need a measure of useful functionality
produced per time unit (Key assumption for
estimates)
Copyright@ICU 2007
60
Productivity measures influence estimates
Size related measures based on some output
from the software process. This may be lines
of delivered source code, object code
instructions, etc.
Function-related measures based on an
estimate of the functionality of the delivered
software. Function-points are the best known
of this type of measure
Copyright@ICU 2007
61
Factors affecting productivity
Factor
Description
Application
domain
Experience
Process quality
Engineers who already understand an
application domain are likely to provide the most
effective software development.
Project size
The larger a project, the more time required for
team communications. Less for development.
Technology
support
Good support technology such as CASE tools,
supportive CM systems etc. can improve
productivity.
Working
environment
A quiet working environment with private work
areas contributes to improved productivity.
The development process used can have a
significant effect on productivity.
Copyright@ICU 2007
62
Quality and productivity
All metrics based on volume/unit time are
flawed because they do not take quality into
account
Productivity may generally be increased at the
cost of quality
It is not clear how productivity/quality metrics
are related
If change is constant then an approach based
on counting lines of code is not meaningful
Copyright@ICU 2007
63
Estimation techniques (cont.)
In short, estimation is the worst way to
decide how long a software project will
take...
Except for all
other ways!
Copyright@ICU 2007
64
Three times to estimate
 First we estimate to try and win a job. We say what
we think we can do and how we can do it
 Next we estimate to create a “baseline” by which the
project can be measured. This estimate will change,
but you have to start somewhere
 Last we re-estimate every time major changes hit the
project
Copyright@ICU 2007
65
Summary
• Software Product, Process and Project Metrics
• Software Estimation
• Discussion on Assignment #3.
SE 501 Dr. Basit Qureshi
66