This document discusses software project estimation. It begins by defining estimation as using a function or formula to derive a solution or make a prediction, unlike approximation. It then discusses why software estimation is important for activities like project planning, budgeting, and scheduling. The document outlines what can be estimated in software projects, such as size, effort, schedule, and derived estimates. It also covers common problems with software estimation like a lack of historical data, incomplete project information, and failure to update estimates as more information becomes available. Finally, it presents tools and techniques for performing software estimations, such as work breakdown structures, product breakdown structures, top-down estimation, and bottom-up estimation.
BIM Execution Plan (BXP)- What, Why, When and HowUnited-BIM
The most important element of BIM (Building Information Modeling) is “Information”. The objective of developing a BIM Execution Plan (BEP) is to facilitate the management of the information in a BIM project. It can be defined as the plan prepared to streamline how the “Information Modeling” part of a project will be executed.
3_Logframe, problem and objectives, indicators, assumptionscsdialogue
How to write effective EU project proposals: Introduction to Full application preparation. Application Package for Applicants. Common mistakes.
Natasa Gospodjinacki
Kiev, 3-4 September 2015
Why is our defense procurement system broken and what do we need to understand before we attempt to "right the ship." A properly architected Project Management Office would be a good place to start and put operational decisions for programs at the correct level.
BIM Execution Plan (BXP)- What, Why, When and HowUnited-BIM
The most important element of BIM (Building Information Modeling) is “Information”. The objective of developing a BIM Execution Plan (BEP) is to facilitate the management of the information in a BIM project. It can be defined as the plan prepared to streamline how the “Information Modeling” part of a project will be executed.
3_Logframe, problem and objectives, indicators, assumptionscsdialogue
How to write effective EU project proposals: Introduction to Full application preparation. Application Package for Applicants. Common mistakes.
Natasa Gospodjinacki
Kiev, 3-4 September 2015
Why is our defense procurement system broken and what do we need to understand before we attempt to "right the ship." A properly architected Project Management Office would be a good place to start and put operational decisions for programs at the correct level.
In this presentation we have done earlier a project for Phillip Morris (Pakistan) for the access control system and canteen management system. It is the project presentation for our subject Planning and Scheduling. i hope it is the best for the understanding Project planning and scheduling.
Project Management Office (PMO) for Management ConsultantsAsen Gyczew
What is the aim of this course?
Sometimes to create value in the firm or manage a huge number of complicated projects you have to set up Project Management Office (PMO). PMO is responsible for making sure that all strategic projects will be delivered on time. PMO has to also analyze and select projects and support project managers in managing project delivery. Building and running PMO is pretty difficult, especially when it comes to selecting the right projects and later on implementing them. I will teach you in this course how to do it efficiently. We will look at different types of PMO set-up for different purposes. In this course you will learn:
1. In what situation PMO is used and how its goals differ depending on the situation
2. How to select the right projects to implement using PMO
3. What PMO deliverables you will have to create
4. What tools you can use to run the PMO efficiently
In this presentation we have done earlier a project for Phillip Morris (Pakistan) for the access control system and canteen management system. It is the project presentation for our subject Planning and Scheduling. i hope it is the best for the understanding Project planning and scheduling.
Project Management Office (PMO) for Management ConsultantsAsen Gyczew
What is the aim of this course?
Sometimes to create value in the firm or manage a huge number of complicated projects you have to set up Project Management Office (PMO). PMO is responsible for making sure that all strategic projects will be delivered on time. PMO has to also analyze and select projects and support project managers in managing project delivery. Building and running PMO is pretty difficult, especially when it comes to selecting the right projects and later on implementing them. I will teach you in this course how to do it efficiently. We will look at different types of PMO set-up for different purposes. In this course you will learn:
1. In what situation PMO is used and how its goals differ depending on the situation
2. How to select the right projects to implement using PMO
3. What PMO deliverables you will have to create
4. What tools you can use to run the PMO efficiently
2012.06.12 Research on Academic Entrepreneurship: Lessons Learnt Part 2NUI Galway
Professor Donald Siegel, University at Albany, State University of New York, presented the keynote address "Research on Academic Entrepreneurship - Lessons Learnt" at the IntertradeIreland All-Island Innovation Programme annual conference 2012, Exploiting Industry and University Research, Development and Innovation: Why it Matters held at National University of Ireland, Galway, 12 - 13 June 2012. Part 2
2012.06.12 Research on Academic Entrepreneurship: Lessons Learnt. Part 1NUI Galway
Professor Donald Siegel, University at Albany, State University of New York, presented the keynote address "Research on Academic Entrepreneurship - Lessons Learnt" at the IntertradeIreland All-Island Innovation Programme annual conference 2012, Exploiting Industry and University Research, Development and Innovation: Why it Matters held at National University of Ireland, Galway, 12 - 13 June 2012. Part 1
Project Risk management is an integral part for business survival. This research paper focuses on determining project risk factors using genetic algorithm and fuzzy logic base on the demerits of conventional approaches. Genetic algorithm help optimise the parameters data items while fuzzy logic handle imprecisions. Unified Modelling Language was utilized for modelling the software system, depicting clearly the interaction between various components and the dynamic aspect of the system. This paper demonstrates the practical application of metric based soft computing techniques in the health sector in determining patient’s satisfaction
Demystifying Disruption: A New Model for Understanding and Predicting Disrupt...Vivek Pundir
The failure of firms in the face of technological change has been a topic of intense research and debate,
spawning the theory (among others) of disruptive technologies. However, the theory suffers from circular
definitions, inadequate empirical evidence, and lack of a predictive model. Sood & Tellis develop a new schema to address these limitations. The schema generates seven hypotheses and a testable model relating to platform technologies.
The authors test this model and hypotheses with data on 36 technologies from seven markets. Contrary to extant theory,
technologies that adopt a lower attack (“potentially disruptive technologies”) (1) are introduced as frequently
by incumbents as by entrants, (2) are not cheaper than older technologies, and (3) rarely disrupt firms; and (4)
both entrants and lower attacks significantly reduce the hazard of disruption. Moreover, technology disruption is not permanent because of multiple crossings in technology performance and numerous rival technologies coexisting without one disrupting the other. The proposed predictive model of disruption shows good out-of sample predictive accuracy. The authors discuss the implications of these findings.
Research assistants: Esra Kent, Vivek Pundir, and K. L. Dang.
2. SoberIT
Software Business and Engineering Institute
Process Choice
There are several factors Risks ~
that affect which type of - novelty of
process you should use: methods,
tools,
Product type application
Business type Iterative, prototyping
domain
Project size - fuzziness of
requirements
Project initial Incremental
uncertainty
Environmental
uncertainty
Organizational culture Plan-driven
…
Product
size/complexity
HELSINKI UNIVERSITY OF TECHNOLOGY
3. Dimensions Affecting Process Model
SoberIT
Selection and Engineering Institute
Software Business
Personnel (Boehm & Turner 2003)
(Percent level 1B) (Percent level 2 and 3)
40 15
30 20
20 25
Criticality Dynamism
(Loss due to impact (Percent requirements
on defects) Single 10 30 change/month)
life
Discretionary
Many 1
funds 0 35 5
lives
10
Essential
funds 30
Comfort 50
3
90 Ag
10 ile
70
Pla
30 n-d
r ive
50 n
100
Size 30
300 Culture
(# of
HELSINKI UNIVERSITY OF TECHNOLOGY
(% of thriving on chaos vs. order)
personnel) 10
Size Culture
(Number of personnel) (Percent thriving on chaos versus order)
4. SoberIT
Software Business and Engineering Institute
T-76.5612 Software Project Management
Spring 2010
3: Software estimation
Tuomas Niinimäki
Department of Computer Science and Engineering
Helsinki University of Technology
HELSINKI UNIVERSITY OF TECHNOLOGY
6. SoberIT
Software Business and Engineering Institute
What is estimation?
In mathematics, use of a function or formula to derive a solution or
make a prediction.
Unlike approximation, it has precise connotations. In statistics,
for example, it connotes the careful selection and testing of a
function called an estimator. In calculus, it usually refers to an
initial guess for a solution to an equation, which is gradually
refined by a process that generates closer estimates. The
difference between the estimate and the exact value is the error.
(Encyclopedia Britannica Concise)
HELSINKI UNIVERSITY OF TECHNOLOGY
7. SoberIT
Software Business and Engineering Institute
Why would we want to
estimate software?
HELSINKI UNIVERSITY OF TECHNOLOGY
8. SoberIT
Software Business and Engineering Institute
The use of estimates (1/3)
Phase / Activity Why The question answered
Strategic Planning Finding out potential Could we do this more efficiently than
application domains the others?
Prioritizing projects Should we emphasize this project over
the others?
Feasibility study Cost-benefit analysis, Is the project worth doing?
making a bid
(Adapted from Boehm, 2000, Hughes & Cotterell, 2002)
HELSINKI UNIVERSITY OF TECHNOLOGY
9. SoberIT
Software Business and Engineering Institute
The use of estimates (2/3)
Phase / Activity Why The question answered
Evaluation of Evaluating project cost How much should we pay for this
suppliers’ project?
proposals
Evaluating supplier’s Is this bidding realistic?
proposals
Has the supplier understood the
requirements?
Project Planning Budgeting How much is the project going to cost?
Resourcing and How long is the project going to take?
Scheduling
How does the resourcing decisions affect
it?
(Adapted from Boehm, 2000, Hughes & Cotterell, 2002)
HELSINKI UNIVERSITY OF TECHNOLOGY
10. SoberIT
Software Business and Engineering Institute
The use of estimates (3/3)
Phase / Activity Why The question answered
System Requirements analysis How long does it take to implement a
specification feature/requirement?
Which features will take the most effort?
Project execution Iteration-level plans How much effort do the different tasks
take?
Making trade-offs Should I leave this feature out to match
the schedule wishes?
(Adapted from Boehm, 2000, Hughes & Cotterell, 2002)
HELSINKI UNIVERSITY OF TECHNOLOGY
11. SoberIT
Software Business and Engineering Institute
What to estimate in software
project?
HELSINKI UNIVERSITY OF TECHNOLOGY
12. SoberIT
Software Business and Engineering Institute
What to estimate in software
project?
Effort
Schedule Size
HELSINKI UNIVERSITY OF TECHNOLOGY
13. SoberIT
Software Business and Engineering Institute
What to estimate in software
project?
Resources
Effort
Schedule Size
Time Scope
HELSINKI UNIVERSITY OF TECHNOLOGY
14. SoberIT
Software Business and Engineering Institute
What can be estimated in software?
Software size
Lines of code?
Number of classes / methods?
Amount of database tables / queries / user views?
Functionality?
Effort
Person-hours
Schedule
Calendar-days or months
HELSINKI UNIVERSITY OF TECHNOLOGY
15. SoberIT
Software Business and Engineering Institute
Derived estimates (examples)
Software size
Potential / probable number of defects
Probable number of change requests
…
Effort
Project cost
Team size
Schedule
Suitable number of iterations / milestones
HELSINKI UNIVERSITY OF TECHNOLOGY
16. SoberIT
Software Business and Engineering Institute
Project cost drivers (from COCOMO81)
… or even better,
Use the
relevant
cost drivers
for
your project /organization
HELSINKI UNIVERSITY OF TECHNOLOGY
17. SoberIT
Software Business and Engineering Institute
How to estimate software?
Estimation process in a nutshell:
1 2 3
Estimate the size of the product Estimate the effort Estimate the schedule
Provide the estimates in ranges
Periodically refine the ranges to provide increasing precision as
the project progresses
(McConnell, Rapid Development, 1996)
HELSINKI UNIVERSITY OF TECHNOLOGY
18. SoberIT
Software Business and Engineering Institute
Problems in software estimation (1/6)
Basic problem: Predicting the future by looking into the
past
HELSINKI UNIVERSITY OF TECHNOLOGY http://www.flickr.com/photos/wabbit42/3691518084/ CC BY-NC-SA 2.0
19. SoberIT
Software Business and Engineering Institute
Problems in software estimation (2/6)
A lack of good historical information
Does the historical information have such metrics that distinguish the
previous projects from each others?
Does the historical data contain enough cases to make a reliable
estimation?
Can these metrics describe the project you are estimating?
Do we have the right metrics to measure the project environment?
HELSINKI UNIVERSITY OF TECHNOLOGY
20. SoberIT
Software Business and Engineering Institute
Problems in software estimation (3/6)
A lack of information on the project to be estimated
Most influential decisions are made in the early phases of
project, based on inadequate information
Important information is not available
... or there simply is not enough time to collect it
HELSINKI UNIVERSITY OF TECHNOLOGY
21. SoberIT
Software Business and Engineering Institute
Problems in software estimation (4/6)
Estimates are done sloppily
”If they cannot be done perfectly, why pay attention to
them?”
There can be a order-of-magnitude difference between a
careful and a sloppy estimate
There are no “final estimates” - they can (and should!) be
updated whenever new information becomes available
HELSINKI UNIVERSITY OF TECHNOLOGY
22. SoberIT
Software Business and Engineering Institute
Project Cost Project
(effort and size) schedule
4× 1.6×
2× 1.25×
1.5× 1.15×
1.25× 1.1×
1.0× 1.0×
0.8× 0.9×
0.67× 0.85×
0.5× 0.8×
0.25× 0.6×
Initial Approved Requirements Product Detailed Product
product product specification design design complete
HELSINKI UNIVERSITYdefinition
definition OF TECHNOLOGY specification specification
23. SoberIT
Software Business and Engineering Institute
Problems in software estimation (5/6)
Estimates are not updated
Estimating is done only in the beginning of the project, based
on incomplete information
New estimates are not done, but the old estimates are still
followed
As new information becomes available, estimates should be
updated
Estimates can be used in various stages of software project
e.g. size estimation for estimating the number of bugs
HELSINKI UNIVERSITY OF TECHNOLOGY
24. SoberIT
Software Business and Engineering Institute
Problems in software estimation (6/6)
Estimates are not followed, respected or trusted
An estimate should not be an opinion
An opinion can be overruled by your superior
An estimate is not automatically a commitment
... but may be considered as such
Justify and criticize the estimates
Accept uncertainties
Visualize probabilities
HELSINKI UNIVERSITY OF TECHNOLOGY
26. SoberIT
Software Business and Engineering Institute
Tools for estimation
Work breakdown structure
Product breakdown structure
Top-down estimation
Bottom-up estimation
HELSINKI UNIVERSITY OF TECHNOLOGY
27. SoberIT
Software Business and Engineering Institute
Work breakdown structure
Work Breakdown Structure (WBS) is a graph (a tree) of activities
done during the project
Each activity is broken down into tasks, until desired level of
detail is reached
A task must contain work related only to their parent activity
The top-level activity (= project) must contain 100% of work
in the project
For each node, the sum of work shares in its sub-activities
must be 100%
A desired level of detail for tasks is usually the size of task
that can be allocated to a single person
Maximum size is usually 10-20 hours
HELSINKI UNIVERSITY OF TECHNOLOGY
28. SoberIT
Software Business and Engineering Institute
Example: Work breakdown structure
Project
Specification Implementation Testing Delivery
Eliciting Implementing Testing Installing
requirements module A module A software
Analyzing Implementing Testing
Training
requirements module B module B
Writing req. Implementing Testing
specification doc. module C module C
Creating Integrating Integration
architecture plan modules testing
Acceptance
testing
HELSINKI UNIVERSITY OF TECHNOLOGY
29. SoberIT
Software Business and Engineering Institute
Product breakdown structure
Product Breakdown Structure (PBS) is a similar construct as
WBS, but is based on the structure of product rather than the
type of activities
Lower levels in PBS describe the structure of item on level above
The top level of PBS is the product
Second level may consist of the major components of the
product
Lowest level should contain items that are “comprehensible”
HELSINKI UNIVERSITY OF TECHNOLOGY
30. SoberIT
Software Business and Engineering Institute
Example: Product breakdown structure
Product
Documentation Software
Project plan Module A
Requirements
Class A_x Module B
specification
Class A_y
Architecture
Class A_z Module C
specification
User manual Main module
HELSINKI UNIVERSITY OF TECHNOLOGY
31. SoberIT
Software Business and Engineering Institute
Top-down estimation
Idea: Allocate proportions of an effort estimate to different
activities of the project
Inputs: Main project activities (high level design) and
earlier project data on efforts spent for activities
Outputs: Rough work breakdown with corresponding effort
estimates
Advantages
Takes into account integration, configuration management and
documentation costs (e.g. algorithmic models seldom take)
Disadvantages
Underestimating the difficult low-level technical problems
HELSINKI UNIVERSITY OF TECHNOLOGY
32. SoberIT
Software Business and Engineering Institute
Example: Top-down estimation
100 %
800 h
Project
Specification Implementation Testing Delivery
Eliciting Implementing Testing Installing
requirements module A module A software
Analyzing Implementing Testing
Training
requirements module B module B
Writing req. Implementing Testing
specification doc. module C module C
Creating Integrating Integration
architecture plan modules testing
Acceptance
testing
HELSINKI UNIVERSITY OF TECHNOLOGY
33. SoberIT
Software Business and Engineering Institute
Example: Top-down estimation
100 %
800 h
Project
20 % 40 % 30 % 10 %
Specification h
160 Implementation h
320 Testing 240 h Delivery 80 h
Eliciting Implementing Testing Installing
requirements module A module A software
Analyzing Implementing Testing
Training
requirements module B module B
Writing req. Implementing Testing
specification doc. module C module C
Creating Integrating Integration
architecture plan modules testing
Acceptance
testing
HELSINKI UNIVERSITY OF TECHNOLOGY
34. SoberIT
Software Business and Engineering Institute
Example: Top-down estimation
100 %
800 h
Project
20 % 40 % 30 % 10 %
Specification h
160 Implementation h
320 Testing 240 h Delivery 80 h
50 % Eliciting Implementing Testing Installing
80 h
requirements module A module A software
30 % Analyzing Implementing Testing
48 h requirements Training
module B module B
10 % Writing req. Implementing Testing
16 hspecification doc. module C module C
20 % Creating Integrating Integration
16 h architecture plan modules testing
Acceptance
testing
HELSINKI UNIVERSITY OF TECHNOLOGY
35. SoberIT
Software Business and Engineering Institute
Bottom-up estimation
Idea: Calculate the total effort from the sum of effort
estimations of single tasks (by analogy estimation or
expert judgement)
Inputs: Detailed work breakdown (tasks 1-2 weeks for 1
person), descriptions of factors affecting production
Outputs: Effort estimates on individual tasks, total effort
Advantages
If the task division is accurate, the model may provide the most
accurate estimates
Disadvantages
Underestimates costs of system level (e.g. integration and
documentation)
Needs detailed breakdown of project tasks
HELSINKI UNIVERSITY OF TECHNOLOGY
36. SoberIT
Software Business and Engineering Institute
Example: Bottom-up estimation
Project
Specification Implementation Testing Delivery
Eliciting 60 Implementing
h Testing Installing
requirements module A module A software
Analyzing Implementing Testing
Training
requirements module B module B
Writing req. Implementing Testing
specification doc. module C module C
Creating Integrating Integration
architecture plan modules testing
Acceptance
testing
HELSINKI UNIVERSITY OF TECHNOLOGY
37. SoberIT
Software Business and Engineering Institute
Example: Bottom-up estimation
Project
Specification Implementation Testing Delivery
Eliciting 60 Implementing
h Testing Installing
requirements module A module A software
Analyzing 80 Implementing
h Testing
Training
requirements module B module B
Writing req. 45 Implementing
h Testing
specification doc. module C module C
Creating 68 h Integrating Integration
architecture plan modules testing
Acceptance
testing
HELSINKI UNIVERSITY OF TECHNOLOGY
38. SoberIT
Software Business and Engineering Institute
Example: Bottom-up estimation
Project
252 h
Specification Implementation Testing Delivery
Eliciting 60 Implementing
h Testing Installing
requirements module A module A software
Analyzing 80 Implementing
h Testing
Training
requirements module B module B
Writing req. 45 Implementing
h Testing
specification doc. module C module C
Creating 68 h Integrating Integration
architecture plan modules testing
Acceptance
testing
HELSINKI UNIVERSITY OF TECHNOLOGY
39. SoberIT
Software Business and Engineering Institute
Example: Bottom-up estimation
695 h
Project
272 h 252 h 100 h 70 h
Specification Implementation Testing Delivery
68 h Eliciting 60 Implementing
h 20 h Testing Installing
10 h
requirements module A module A software
68 h Analyzing 80 Implementing
h 20 h Testing 60 h
Training
requirements module B module B
68 h Writing req. 45 Implementing
h 20 h Testing
specification doc. module C module C
68 h Creating 68 h Integrating 20 h Integration
architecture plan modules testing
20 h Acceptance
testing
HELSINKI UNIVERSITY OF TECHNOLOGY
41. SoberIT
Software Business and Engineering Institute
Estimation techniques
Estimation by analogy
Expert judgment
Agile estimation
Algorithmic models
Albrecht & MarkII function points
COCOMO 81 and COCOMO II
HELSINKI UNIVERSITY OF TECHNOLOGY
42. SoberIT
Software Business and Engineering Institute
Estimation by analogy (1/2)
Idea: Finding similar cases to the target project
Inputs: Earlier projects, each described with p features
Outputs: Project size, effort estimate, schedule
estimate, (estimation error)
HELSINKI UNIVERSITY OF TECHNOLOGY
43. SoberIT
Software Business and Engineering Institute
Example: Estimation by analogy
ce
ce
n
n
o
n
s
e
ti
n
th
e
ri
ts
p
o
ri
e
ts
n
ri
ti
in
e
e
p
o
sc
ta
n
d
p
o
x
m
y
e
co
x
p
e
n
e
it
ze
m
e
d
e
r
rm
n
x
a
f
m
e
si
in
le
g
io
ct
o
n
d
ir
in
le
o
a
p
g
ct
n
m
je
s
u
l
tf
m
ta
m
si
le
st
e
p
q
n
a
ro
la
n
Im
o
e
e
o
a
o
Fu
e
e
Li
D
D
R
P
P
C
C
T
T
T
Project time
tracking
software 41 246 246 287 820 6.3 1 140 8300 Very low Nominal Very high
Customizable
user register
module 25 50 138 37 250 3.2 1 40 2300 Low High High
Mobile
calendar and
email
application 525 1575 700 700 3500 12 3 310 22000 Nominal Very low Nominal
Intranet
product 237 316 553 474 1580 11 1 260 18200 Low High Nominal
Web survey
tool 105 126 84 105 420 2 2 92 5200 Nominal High Low
For new project:
Lines of code?
Complexity? Finding similar Deriving estimate
(inter/extrapolation)
Platform experience? earlier projects
from actual outcomes
Domain experience?
HELSINKI UNIVERSITY OF TECHNOLOGY
44. SoberIT
Software Business and Engineering Institute
Estimation by analogy (2/2)
Advantages
If done systematically, the estimate can be justified to project
stakeholders
If a good analogy is found, the estimation can be fairly accurate
Tool support (e.g. ANGEL, http://dec.bournemouth.ac.uk/ESERG/ANGEL/)
Disadvantages
The feature data on earlier projects is limited
There may not be an analogous project in the project data set
Choosing the right features for finding analogous project
The significance of many features only becomes visible afterwards
It might not be documented systematically even in earlier projects
By definition, no project is exactly equivalent
HELSINKI UNIVERSITY OF TECHNOLOGY
45. SoberIT
Software Business and Engineering Institute
Estimation techniques
Estimation by analogy
Expert judgment
Agile estimation
Algorithmic models
Albrecht & MarkII function points
COCOMO 81 and COCOMO II
HELSINKI UNIVERSITY OF TECHNOLOGY
46. SoberIT
Software Business and Engineering Institute
Expert judgment (1/4)
Idea: Ask the required estimate from persons that have previous
experience on some parts of the problem
Inputs: Descriptions of problem domain, technology or other
affecting factors
Outputs: Project size, effort estimate, schedule estimate (in all
varying metrics)
Dominant technique for effort estimation (Jorgensen, 2004)
HELSINKI UNIVERSITY OF TECHNOLOGY
47. SoberIT
Software Business and Engineering Institute
Expert judgment (2/4)
Who are the experts?
Your own developers
Domain experts
Technology experts
Other project managers
Non-technical people may be better at estimating than technical
people
Skilled technical personnel tend to be overoptimistic
Varying background (employment, education, domain
experience) of estimators can improve the estimates
Different backgrounds yield different estimation strategies
HELSINKI UNIVERSITY OF TECHNOLOGY
48. SoberIT
Software Business and Engineering Institute
Expert judgment (3/4)
In practice expert judgment estimates are derived from
analogies to earlier projects
Experience on similar projects is crucial
Require justification for estimates, so that they can be
reviewed
HELSINKI UNIVERSITY OF TECHNOLOGY
49. SoberIT
Software Business and Engineering Institute
Expert judgment (4/4)
Advantages
Cheap and fast
Easy to adapt to changing situations (a judgement can be made
based on whatever information is available)
If developers are making the estimates, they are more committed to
them
More accurate than algorithmic methods, if the experts have good
domain knowledge and the project is of low uncertainty
Disadvantages
The analogies or evaluation criteria cannot be easily made visible
How to distinguish good estimates from bad ones?
Underestimation of large tasks and overestimating small
Can be strongly biased by information that is irrelevant for the
estimates (e.g. schedule constraints)
HELSINKI UNIVERSITY OF TECHNOLOGY
50. SoberIT
Software Business and Engineering Institute
Estimation techniques
Estimation by analogy
Expert judgment
Agile estimation
Algorithmic models
Albrecht & MarkII function points
COCOMO 81 and COCOMO II
HELSINKI UNIVERSITY OF TECHNOLOGY
51. SoberIT
Software Business and Engineering Institute
Agile estimation (Scrum) (1/5)
Strategic Release Management
Release Project Cycle 3 months
Sprint 1 month
Time-paced (heartbeat - sprint - release project - strategic)
Time is fixed, scope can change
User requirements come as “user stories”
“Things to do” (tasks) are stored in product & sprint backlog
HELSINKI UNIVERSITY OF TECHNOLOGY
52. SoberIT
Software Business and Engineering Institute
Agile estimation (Scrum) (2/5)
Each feature (a “user story”) is assigned a number of points
This number represents how hard / time consuming it is to
complete this feature
Story A Story B Story C Story D
3 pt 5 pt 4 pt 7 pt
What do these numbers mean?
Where do these numbers come from?
HELSINKI UNIVERSITY OF TECHNOLOGY
53. SoberIT
Software Business and Engineering Institute
Agile estimation (Scrum) (3/5)
They do not mean much individually (they are relative)
They come out from team “consensus”
Delphi method, planning poker
Story A Story B Story C Story D
3 pt 5 pt 4 pt 7 pt
I think B is much
more work than A
(B = ~2 x A)
I guess A would be quite
I agree, but I think D
simple to do (A = 3)
is the hardest one
(D ~ A + B)
HELSINKI UNIVERSITY OF TECHNOLOGY
54. SoberIT
Software Business and Engineering Institute
Planning poker
1. At the start of planning poker, each estimator is given a
deck of cards.
Each card has written on it one of the valid estimates (e.g.
1,2,3,5,8,13,…)
2. For each user story or theme to be estimated, a
moderator reads the description.
The product owner answers any questions that the
estimators have.
3. After all questions are answered, each estimator
privately selects a card representing his or her
estimate. Cards are not shown until each estimator has
made a selection
If estimates differ, the high and low estimators explain their
estimates.
4. After the discussion, each estimator re-estimates by
selecting a card.
5. Continue the process as long as estimates are moving
closer together http://www.flickr.com/photos/tomnatt/ CC BY-NC 2.0
HELSINKI UNIVERSITY OF TECHNOLOGY
55. SoberIT
Software Business and Engineering Institute
Agile estimation (Scrum) (4/5)
After a few sprints
The story points assigned to the user stories start to stabilize
You may start counting the story points implemented per
sprint
This measure is called velocity
Velocity tells how many story points can be completed on
average during a sprint
However, velocity is not a team performance metric
Sprint 1: planned scope = 8 pt
Story A Story B Story C Story D
3 pt 5 pt 4 pt 7 pt
HELSINKI UNIVERSITY OF TECHNOLOGY
56. SoberIT
Software Business and Engineering Institute
Agile estimation (Scrum) (5/5)
Velocity tells how many story points can be completed on
average during a sprint
Velocity can be used to estimate the amount of work for a
new sprint
Backlog: sum of points = 11 pt > 8 pt
Story C Story D
4 pt 7 pt
Sprint 1: implemented => velocity = 8 pt Sprint 2: “maximum” story points = 8 pt
Story A Story B
3 pt 5 pt
HELSINKI UNIVERSITY OF TECHNOLOGY
57. SoberIT
Software Business and Engineering Institute
Agile estimation: Summary
Advantages
Simple and comprehensible process
Easy to set up and maintain
Empowers developers (helps in team&project commitment)
Self-calibrating
Disadvantages
Needs active participation, self-organization, motivation
It can be difficult to give reasoning to the story points
It usually takes a number of iterations to stabilize
Long-term estimation is difficult
Stories are created
and story points assigned “just-in-time”
HELSINKI UNIVERSITY OF TECHNOLOGY
58. SoberIT
Software Business and Engineering Institute
Estimation techniques
Estimation by analogy
Expert judgment
Agile estimation
Algorithmic models
Albrecht & MarkII function points
COCOMO 81 and COCOMO II
HELSINKI UNIVERSITY OF TECHNOLOGY
59. SoberIT
Software Business and Engineering Institute
Algorithmic models
Based on an algorithm (procedure of calculation)
Model based on (non-)linear regression
Research on software engineering
Weights and factors derived from past project metrics
Function point methods are used to estimate software size
Constructive cost model (COCOMO) is used to estimate effort
based on estimated software size
See course material (Estimation of Software) for more details
and examples
HELSINKI UNIVERSITY OF TECHNOLOGY
60. SoberIT
Software Business and Engineering Institute
Function point methods (1/2)
Idea: Quantify the size of programs independently of programming
languages
Function point methods are based on historical data
Mathematical model is similar as in (algorithmic) estimation by
analogy, but the granularity is finer
Function point methods should be calibrated to each organization
Even though they give one number, they are not necessarily more
(or less) accurate than other estimation techniques
Inputs: ”External user types” (Albrecht) or ”transactions” (MarkII)
Outputs: Project size (in function points)
HELSINKI UNIVERSITY OF TECHNOLOGY
61. SoberIT
Software Business and Engineering Institute
Function point methods (2/2)
Advantages
Can be made in early stages of project (e.g. based on requirements or a
detailed problem description)
Independent of implementation details or the person estimating
Tool support
Disadvantages
Difficult to apply for application domains which are hard to describe with
external user types or transactions
Do not take development process, organization or technology into account
(Apply corrective multipliers for deriving person-hours from function points,
e.g. COCOMO or data on earlier projects)
Need to be calibrated for each organization
May give false sense of accurate estimates
HELSINKI UNIVERSITY OF TECHNOLOGY
62. SoberIT
Software Business and Engineering Institute
Albrecht function points (1/3)
Based on five major components - the external user types
External input type: input transactions from user that update internal
files
External output type: transactions that output data to user
Logical internal file type: data storage used by the system
External interface file type: input/output between different computer
systems
External inquiry type: transactions initiated by users that do not
update the internal files
HELSINKI UNIVERSITY OF TECHNOLOGY
63. SoberIT
Software Business and Engineering Institute
Albrecht function points (2/3)
Function points are calculated for each activity in the software,
including
functionality
reports
data storage
The total function points for a system is the sum of function
points for all activities
HELSINKI UNIVERSITY OF TECHNOLOGY
64. SoberIT
Software Business and Engineering Institute
Albrecht function points (3/3)
Steps to calculate function points for an activity:
1. Identify the external user type for the activity
2. Identify the record types used in the activity
Record types could be modeled as classes in OOP
Note that you might need to take a look at other activities to fully
determine the record types used in this activity
3. Identify the data types
Data types could be modeled as attributes in OOP
4. Determine component complexity multiplier based on external user
type and the amount of record and data types involved
Identifying record and data types requires training to do
properly, and can be subjective in some cases
HELSINKI UNIVERSITY OF TECHNOLOGY
65. SoberIT
Software Business and Engineering Institute
MarkII function points
MarkII function points are calculated for activities modeled as
transactions:
Input data is data provided by the user
The system then processes the input data, and (possibly)
manipulates some internal data (= entity types)
The system outputs data to user
Calculating the total function points for the system is done by
calculating the sum of function points of the transactions in the
system
HELSINKI UNIVERSITY OF TECHNOLOGY
66. SoberIT
Software Business and Engineering Institute
Constructive cost model (COCOMO)
Idea: Quantify the effort required based on a size estimate
Inputs: ”Lines of code” (COCOMO 81 & II) or ”function
points” (COCOMO II), ”cost multipliers”, ”scale factors”
Outputs: Effort estimate (in person-months = 152 person-hours)
COCOMO II dataset is updated continuously, software
support is available
Possibly the biggest and most descriptive dataset on software
projects
HELSINKI UNIVERSITY OF TECHNOLOGY
67. SoberIT
Software Business and Engineering Institute
Constructive cost model (COCOMO)
The basic model of COCOMO 81 is based on the equation
effort = c x sizek
effort = person-months
size = thousands of delivered source code instructions
c,k = constants (depend on the system type)
System types are classified as follows:
Organic mode: relatively small team, highly familiar environment,
flexible interface requirements
Embedded mode: very tight constaints on the system
Semi-detached mode: characteristics between organic and embedded
mode
HELSINKI UNIVERSITY OF TECHNOLOGY
68. SoberIT
Software Business and Engineering Institute
Constructive cost model (COCOMO)
The intermediate model of COCOMO 81 takes development
environment into account via 15 cost drivers, resulting in
equation
effort’ = effort x dem = c x sizek x dem
effort’ = effort estimate adjusted by cost drivers
effort = original effort estimate from the basic model
dem = development effort multiplier
The 15 cost driver coefficients are multiplied to get the
development effort multiplier
Each cost driver is evaluated on scale (very low, low, nominal, high,
very high, extra high)
Values for each cost driver are determined from past projects
HELSINKI UNIVERSITY OF TECHNOLOGY
69. SoberIT
Software Business and Engineering Institute
Constructive cost model (COCOMO)
Advantages
Independent of the estimator (provided that the scale factors can be
determined objectively)
An effort estimate can be derived quickly if the needed information is
available
Disadvantages
Underlying assumption that lines of code or function points are easier
to calculate than the effort needed
A company needs a huge dataset of its own projects to calibrate all
the scale factors
Risk: you get ”an exact number”
HELSINKI UNIVERSITY OF TECHNOLOGY
70. SoberIT
Software Business and Engineering Institute
What techniques are actually used?
Technique McAulay Heemstra Wydenbach
1987 1989 1995
Expert Expert Judgement 26% 86%
based Intuition and experience 85% 62%
Estimation by Analogy 61% 65%
Model
Algorithmic Models 13% 14% 26%
based
Other Price-to-win 8% 16%
Capacity related 21% 11%
Top-down 13%
Bottom-up 51%
Other 12% 9% 0%
(Moløkken et al.: A Survey on Software Estimation in the Norwegian Industry, 2004)
HELSINKI UNIVERSITY OF TECHNOLOGY
71. SoberIT
Software Business and Engineering Institute
Effort estimation best practices (1/3)
Allow time for making the estimate, and plan it
Use documented data from previous projects
Use developer-based estimates
Estimate by walk-through
Estimate at a low level of detail
Don’t omit common tasks
Use software estimation tools
Use several different estimation techniques, and compare the
results
Monitor and adapt estimation practices as the project progresses
(McConnell, 1996)
HELSINKI UNIVERSITY OF TECHNOLOGY
72. SoberIT
Software Business and Engineering Institute
Effort estimation best practices (2/3)
Reduce situational and human bias
Find estimation experts with highly relevant domain background and
good estimation records
Ask the evaluators to justify and criticize their estimations
Assess the uncertainty of the estimate
Use plus/minus qualifiers or value ranges to indicate the direction of
uncertainty or estimation range
Quantify risks – explicate the reasons of uncertainty
Provide estimation feedback and training opportunities
Provide feedback on estimation accuracy and development task
relations
Provide estimation training opportunities
(Jørgensen, 2004)
HELSINKI UNIVERSITY OF TECHNOLOGY
73. SoberIT
Software Business and Engineering Institute
Effort estimation best practices (3/3)
Use several estimation techniques and compare them
If they converge, you are probably on the right track
Find out why the estimates are different
Delphi method - Combine several expert opinions
Ask each expert to make an estimate independently
Then let each of them present their estimate and reasoning
Based on this discussion, let them adjust their estimation
Iterate until the estimates converge
Ask several different estimates – optimistic, probable and
pessimistic – and compare them
HELSINKI UNIVERSITY OF TECHNOLOGY
74. SoberIT
Software Business and Engineering Institute
Exercise 1 best practices
Start early!
Read the exercise carefully!
Read the additional material (especially Estimation of Software)
Estimation is sometimes subjective
Don’t get frustrated!
Sometimes you just have to assume
Remember to give reasoning and make your process visible
Each question is graded separately
Don’t give up!
Keep track of the time you are spending and give feedback!
HELSINKI UNIVERSITY OF TECHNOLOGY
75. SoberIT
Software Business and Engineering Institute
Thank you.
Questions?
Tuomas Niinimäki
tuomas.niinimaki@soberit.hut.fi
HELSINKI UNIVERSITY OF TECHNOLOGY
77. SoberIT
Software Business and Engineering Institute
Example: Albrecht function points
Actual requirement from exercise 1:
List category products: This screen lists the product, its name, price, short description,
thumbnail image,variations (size, colors and materials) and their stock availability.
When clicking a product name or image, a detailed product data screen is activated
(see FR3). The user is also able to make an order through this screen (see FR4).
Step 1: Identify the external user type
User type is external inquiry, as no data structures are updated.
Step 2: Identify record types
Category, Product, Customer, Discount
Note that you may have to look into other requirements to identify
all records that are present - in this case, the Discount type is stated
in a different requirement (not shown here).
Step 3: Identify data types
categoryName, productName, price, shortDescription, smallImage,
size, color, material, availability
HELSINKI UNIVERSITY OF TECHNOLOGY
78. SoberIT
Software Business and Engineering Institute
Example: Albrecht function points
Step 4: Determine component complexity multiplier based on
external user type and the amount of record and data types
involved
External inquiry with 4 record types, 9 data types
External inquiries use whichever complexity is higher,
external input or external output complexity
In this case, both give a high complexity
For our requirement, the multiplier for high external
inquiry complexity is 6; therefore, we get 6 adjusted
function points for this requirement!
HELSINKI UNIVERSITY OF TECHNOLOGY
79. SoberIT
Software Business and Engineering Institute
Example: MarkII function points
Actual requirement from exercise 1:
List category products: This screen lists the product, its name, price, short
description, thumbnail image,variations (size, colors and materials) and their
stock availability. When clicking a product name or image, a detailed product
data screen is activated (see FR3). The user is also able to make an order
through this screen (see FR4).
Step 1: Identify input types, entity types and output types
Input types: categoryName
Entity types: Category, Product, Customer, Discount
Output types: productName, price, shortDescription, smallImage,
size, color, material, availability
Step 2: Calculate function point amount using weights
0.58*1 + 1.66*4 + 0.26*8 = 9.30 function points.
HELSINKI UNIVERSITY OF TECHNOLOGY
80. SoberIT
Software Business and Engineering Institute
Example: Constructive cost model
Using COCOMO 81 to estimate effort:
1. Calculate function points for the system
Example: FP = 19
2. Calculate source lines of code for the system based on the function
points
Example: Development in Java, thus SLOC = 60 x 19 = 1140
3. Apply the basic model for nominal effort estimate
Example: Organic model (c=2.4,k=1.05) => effort = c x sizek =
2.4 x (1.140)1.05 = 2.75 person-months
4. Apply the development effort multiplier
Example: Other cost drivers at nominal level, but programmer
capability (PCAP) and operating system experience (VEXP) is
high: dem = 0.80 x 0.90 = 0.72 => effort’ = 0.72 x effort =
1.98 person-months
HELSINKI UNIVERSITY OF TECHNOLOGY