ETSF01: Welcome to Lecture 2!
Effort Estimation (Ch 5 except 5.11-12)
Kurs-representanter
C: Måns Ansgariusson dic14man
D: Emma Asklund dat14eas
D: Oscar Sigurdsson dat14osi
Course project info,
Project organisation, Resource allocation (Ch 8),
[email protected]
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Effort or Cost?
• Effort = work required in project, e.g. person/man-hours
• Cost includes
– Cost of person-hours, i.e. salaries, benefits etc
– Moving and living costs for new staff members
– Training of staff
– Travel costs, for international projects
– Legal & licencing fees, eg software licences, patents, copyrights
– Contractor and subcontractor costs
– Capital cost for new equipment
– Currency exchange rates, for international projects
– Marketing and advertising
– Inflation rate, for long projects
Effort estimation
T. Capers Jones, Estimating Software Costs, McGraw-Hill, 1998
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Over-estimate
Parkinson’s Law
‘Work expands to fill the time available’
→ project likely to take longer time than needed
What don’t we know?
•
•
•
•
Customers’ needs & expectations – requirements
Technical complexity & design choices
Reuse: Internal & external components
People
– Skills, competence, experience
– Co-operation & communication
• ……
Under-estimate
Brooks’ Law
‘putting more people on a late job makes it later’
→ delays
→ lower quality in order to meet target
TK Abdel-Hamid, SE Madnick, Impact of schedule estimation on software project behaviour,
IEEE Software, July 3(4), 70-75, 1986
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
When & Why?
1. Identify
project objectives
• Strategic planning
• Feasability study
• Evaluation of suppliers’
proposals
• Project planning
0.Select project
3. Analyse project
characteristics
4. Identify products
and activities
5. Estimate effort
for activity
6. Identify activity
risks
10. Lower level
planning
9. Execute plan
2. Identify project
infrastructure
For each
activity
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Example: Effort estimation
Dev of Android app with simple ToDo-list?
- CRUD (create/read/update/delete)
list items
- CRUD lists
7. Allocate
resources
8. Review/ publicize
plan
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Estimation approaches
Expert judgement – “Guestimates”
• Expert opinion
• Analogy - case-based, comparative
• Parametric or algorithmic models, e.g. function
points, COCOMO
Asking someone who is
familiar with and knowledgeable about the application
area and the technologies
• Particularly appropriate where existing code is to be
modified
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Analogy
or Case-based reasoning
1) Identify relevant
attributes (e.g. #new reqs)
source cases
attribute values
effort
attribute values
effort
attribute values
effort
attribute values
effort
attribute values
effort
attribute values
effort
3) Base estimate on
effort of source projt: diff,
risks, error
target case
attribute values
?????
2) Select case
with closest attribute
values
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Example:
Analogy / Case-based estimation
Previous Android apps
# of
screens
Android
Dev exp
Client/Server
solution
Effort spent
(person months)
4
novice
C&S
4.4
3
expert
C&S
1.2
1
novice
C
2.4
2
medium
C
1.1
Android ToDo-list app: …
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Algorithmic or Parametric models
Two main parametric models
Estimations based on historical data in the form of
measurements from earlier projects.
Models system size
• Function points
1. Albrecht/IFPUG function points
2. Symons/Mark II function points
3. COSMIC function points
• COCOMO
Focuses on
productivity factors
1. COCOMO81 (original)
2. COCOMO II
Requires
- good experience base
- good size estimate
System
size
Estimated effort
Productivity
factors
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Effort per SLOC
Wm – workmonth
SLOC – source lines of code
Project
wm /
kSLOC
2,8
2,7
a
b
wm
16,7
22,6
SLOC
6050
8363
c
d
e
32,2
3,9
17,3
13334
5942
3315
5,2
f
67,7
38988
1,7
g
10,1
38614
0,3
h
19,3
12762
1,5
i
59,5
26500
2,2
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Albrecht function points1 (FP)
Functional size measurement quantifying
”system functionality”
2,4
0,7
Actual project figures, see [Hughes, Table 5.1, p. 105]
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
External user types
External input type
External output type
Logical internal file type
External interface file type
External inquiry type
1def
Multiplier
(Complexity)
Low Medium High
3
4
6
4
5
7
7
10
15
5
7
10
3
4
6
by Allan Albrecht, IBM, 1979
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
The original COCOMO* model
(COCMO81, Boehm)
or FPs
• Allows benchmarking of software development
productivity
• Considers different types of systems
• Formula
effort = c x sizek
System type
Organic (Small, IS)
Semi-detached
Embedded (RT)
c
2.4
3.0
3.6
Scale factors
Cost drivers
k
1.05
1.12
1.2
*COnstructice COst MOdel
http://csse.usc.edu/tools/COCOMOII.php
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Factors in COCOMO, FP etc
Bottom-up versus top-down estimation
Influence the effort required
so…
also useful for expert judgement!
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
• Top-down
– produce overall estimate
• based on project cost drivers
• based on past project data
– divide overall estimate between jobs to be done
• Bottom-up
– estimate tasks of 1-2 mw, accumulate effort bottom-up
– quite time-consuming
– useful when no past project data of similar projects
NOTE: first identify all tasks (top-down)
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
SW Porting: Effort estimation
Parkinson & Price to win
• ‘Parkinson’
Setting a target based on amount of available staff
effort
• ‘Price to win’
Setting a target that is likely to win business when
tendering for work.
Start project, then adapt
scope--
$++
Rough estimate
-by Senior architect
-Analogy – cmp previous
-Expert judgement, main impact
Detailed estimate
- by SW area teams
- Expert judgement of tasks
lead time++
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Application Dev Project: Effort estimate
Task
USB adaptation
Verification
OTG
USB Audio
(optional)
Total
Effort (mw)
3
3
4
5
15
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Planning Poker (Story points)
§ Pre-study phase: Expert judgement using analogy
by SW architect
• Considers overall impact of new requirements
• Considers experience of team: individually &
together
• Dev phase. Per sprint & User story: Planning poker
by development team members
http://www.crisp.se/bocker-och-produkter/planning-poker
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Effort estimation
Summary
•
•
•
•
•
Part of cost estimation
Basic methods: algorithimic, analogy, expert judgement
Function points, COCOMO II
Combine methods to address uncertainties
Estimates get better with more info – re-estimate…
Recommended exercises: 5.7, 5.8, 5.11
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Project assignment
• Evaluate 3 SPM tools
• Provide recommendations for
• software porting project
• application development project
• Report evaluation & recommendations in a scientific way
Draft 1 due on Mon 3 April
- Full outline w headings and bullets (level 1 and 2)
- Drafted content for
- Introduction: opening, tools, case projects
- Method: planned approach
- Evaluation Framework: Activity planning, Effort estimation
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Report Structure
Max 7 pages* in IEEE format
• Abstract
• Introduction: SPM, Tools, scientific references
• Method: How evaluation was performed
• Case Projects
• Evaluation Framework
• Tool Evaluation incl improvements
• Tool Recommendations per SW project type
• Conclusion
• References
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Reference credibility
Different fora has different
To find scientific papers
credibility
– http://www.lub.lu.se
• Scientific fora
– http://scholar.google.com
– Journals
– Detective work
Peer reviewed
– Conferences
• Search broad
• Select
– Workshops
Ø Iterate
• Search deep
• Non-scientific fora:
– Textbooks
• Search
– Journalistist material
– Key words
– White papers
– Authors
– References
– Web pages (inkl Wikipedia!)
– Fora
– …
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Method section – Research approach
Example: Scientific references
B.W. Boehm, Software Risk Management: Principles and Practices,
IEEE Software, Jan 1991, pp. 32-41
T. Dybå, An Empirical Investigation of the Key Factors for Success in
Software Process Improvement, IEEE Transactions on Software
Engineering, 31(5), May 2005, pp. 410-424.
E. Bjarnason, K. Wnuk, B. Regnell. Are you biting off more than you can
chew? A case study on causes and effects of overscoping in largescale software engineering, Information and Software Technology,
54(10), Oct 2012, pp. 1107-1124.
E. Bjarnason, K. Wnuk, B. Regnell. Requirements are slipping through
the gaps – A case study on causes & effects of communication gaps
in large-scale software development. Proc. Of 19th IEEE
International Requirements Engineering Conference, pp. 37-46,
2011.
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Assessment
Consider
• What are the input? Course material, …
• What activities? Select tools, analyse case projects…
• In which order? Explore cases & tools, select tools, design
FW …
• Motivation for design choices, e.g. choice of tools,
framework factors
Bonus: discuss limitations of results, validity, e.g.
recommendations, framework
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
(see project description for details)
G
How evaluation was performed
Student Peer Assessment
Bonus points
Form
Correct use of IEEE template & page
limitations, Top-Down structure, good and
clear language
Excellent top-down flow of text incl
Intro moves
2
Work & Content
All content requested in project description
including SPA reviews
Excellent descriptions of SPM, case
projects, method incl limitations. >2
scientific references in Introduction.
5
Evaluation framework appropriately
designed including choice of properties and
measurements to include.
Clear reporting of the evaluation results.
Well-presented tool recommendation per
Tool recommendations are excellently
project type, motivated by evaluation results. motivated and presented based on the
evaluation results and clearly
connected to project characteristics.
2
Oral presentation
Clear and understandable, and within time.
Excellent. Use of rhetorical model.
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
1
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Moodle: Register for course
Project Deliveries vs Exercises*
Group
• 50 h before Ex2
• 2 h before Ex2
• At Ex 2
Moodle
Submit draft 1
Assessments
Student
NOW!
- Go to moodle.cs.lth.se
27-29th March
- Log in with stilID
- Register for ETSF01 course with group
key: ETSF01-in, where in = Group name
Example: ETSF01-a1 for members of project group A1
Exercise
Class
1 draft/student
Your assessment
Read & Review
using check list
Attend
Improvement suggestions, understanding of criteria
Discussion of
criteria and
feedback
Improve &
Revise report
• 50 h
before Ex3
* See course schedule
Submit draft 2
Process repeated for draft 2 / Exercise 3
Check lists with criteria
detailing grading criteria
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
1 pdf file per group
named
<Group>_Draft1.pdf
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Goal-Question-Metric (GQM)
Method for designing SW metrics to assess goal fullfillment
1.
2.
3.
4.
Read the report first
Consider the criteria / aspects
Re-read relevants parts of the report
Provide contructive feedback
Criteria also found on course page – Ex2
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Evaluation Factors for Effort Estimation
Goal:
When is Effort Estimation successfully supported by a tool?
What question help determine if that goal is achieved?
How assess/answer Q?
1.Define what the goals are, e.g. for tool support of planning
2.Define questions that determine if goal is met
- Refine goals
- Learn about progress towards goals
3.Define metrics (== factors in your evaluation FW) that
- Answer / measure each question
- Determine if goal is achieved
P1: V.R. Basili, Lindvall, Regardie, Seaman, Heidrich, Münch, Rombach, Trendowicz,
“Linking Software Development and Business Strategy through Measurement”, IEEE
Software, April 2010, pp. 57-65
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Evaluation Framework
Identify suitable factors to evaluate for 5 SPM areas
• Activity planning
• Effort estimation
• Risk management
• Resource allocation
• Monitor & control execution
+ Quality aspects, e.g. usability (changes), performance,
capacity
Define measurements with scales for each factor
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Measurement types & scales
ENSURE a
good mix!
• Objective vs Subjective
• Scales, e.g. integers, real, ordered labels (Low, Medium,
High), enum (analogy, COCOCMO II, expert judgement)
Examples
Assessing usability
- Time required for new user to split a task into two: ms
- Experienced ease of use:{Low, Medium, High}
Assessing functionality
- Support for estimation techn: {analogy, COCOCO, .}
- Degree of analogy: {None, Simple, Advanced}
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Anything else?
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Resource Allocation Task
RESOURCE ALLOCATION
Given
Estimated effort
= N mandays
Available resources = m people over t days
= mt mandays = $$$
achieve
optimized use of resources within budget
(cost) and scope => time
N
scope
t
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
And this!
Avoid this!
Lund University / Faculty of Engineering/ http://showermusings.com/tag/organizational-behavior/
Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
http://2.bp.blogspot.com/-Y9iRqpE_3gg/UFj7F-5rkjI/AAAAAAAAN0I/eASah-V-F6o/s1600/bear.jpg
http://philosophyforlife.org/a-technocratic-solution-to-a-spiritual-question/
Resources
include
– Labour – humans!
– equipment (e.g. workstations)
– materials
– space
– services
The right amount of people for each job!
The right amount of work for each person
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Prec nw - Consider resource need (Fig 8.2)
-> Resource requirements list (Table 8.1)
Stage Activity
Resource
type/category
ALL
Project manager
1
All
All
3
Workstation
20
IoE/P/3 Analyst/designer
15
IoE/P/4 Analyst/designer
25
IoE/P/5 Analyst/designer
15
Workstation
IoE/P/6 Senior analyst
…
…
Notes
1
Check SW availability
3
One per person
34
IoE/P/2 Analyst/designer
All
Quantity
104
Workstation
IoE/P/1 Senior analyst
2
mDays
Possibly
analyst/programmer
2
2
…
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
-> Resource Histogram:
1 per Resource type (Fig 8.3)
Resolving resource clashes
Max available
Resource
smoothing
required!
scope
lead time
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
cost /
effort
Impact of priorities: time, cost, scope?
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Prioritise resource allocation
Example: Burman’s priority list
Critical path
Consider:
- float
- duration
Example: Bar Chart (Fig 8.3)
Give priority to:
• Shortest critical (path) activities
• Other critical activities
• Shortest non-critical activities
• Non-critical activities with least float
• Non-critical activities
PJ Burman (1972) Precedence Networks for Planning and Control, McGraw-Hill
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Duration vs Estimated Effort
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Activity & Resource Schedule
• Time duration used in precedence network
• Person/man time (mdays, pdays etc) for required effort
Example
Develop new app feature: 2 weeks’ work for 2 developers
Estimated Effort: 4 mw (man-weeks)
Duration: ?
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
TO DO
• Read P1, Book!
• Draft evaluation
framework for
– Activity planning
– Effort estimation
• Draft report
• Submit Draft 1 in moodle
Due (50) h before
Exercise 2 class
Summary: Resource allocation
• Resource lists per category
• Prio of allocation: float, duration, Burman’s
• Resource smoothing
• Relationship to other SPM areas
• Project organization
Recommended exercises:
8.1, 8.3, 8.12 #2.5-6 [with SPM tools]
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Project Roles & Responsibilities
Project roles & responsibilities
Stakeholders ++
Project
sponsor /
director
Project
manager
Customers
Customer
representative
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Vendors
Steering committee
Project team members
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
IMPORTANT
Vague in book
Role
Responsibility
Project sponsor or
director
Secure budget + resources. Champion of project goals, ultimate
decision maker. Approve changes, progress, sign-off deliverables etc.
Steering committee
Resp f overall project success. Representatives for key stakeholders
and involved organisational units. Support project sponsor by providing
multiple perspectives.
Project manager
Day-to-day resp to ensure project meets goals (Scope-Time-Cost) by
planning and managing project and project team. Secure acceptance of
deliverables from sponsor and stakeholders.
Stakeholders: Key
and other
All project roles and others who may be impacted by the outcome of
the project.
Customer
representatives &/
decision makers
Active and available to project on matters of customer interests, e.g.
regarding requirements and acceptance of deliveriables.
Vendors
Contracted to deliver products or services to the project.
Project team
members
Execute tasks, produce deliverables as directed by project manager.
http://www2.cit.cornell.edu/computer/robohelp/cpmm/Project_Roles_and_Responsibilities.htm
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
SW Porting Project Organisation
SW Porting Project: Resource allocation
SW Porting PM
Resource Request per
Function Group
System
Test Leader
Software
Areas
SW Architect
Integration
& CM
Quality
Coordinator
Requirements
Coord.
Usability
Coordinator
SWA Test
Teams
Multimedia
Messaging
UMTS Services
SAT
PTT
OS&DD l
UtilityApps
Graphics
MMI
Audio Control
SyncML/Dev. Mngment
Text&Icons
BT&Local Connectivity
200602
200602_ALL
200602
Diff
200603
200602_REQ
200603
200602_ALL
200603
Diff
L_PG_A-DRM L_PG_A-DRM
L_PG_BTLC L_PG_BTLC
L_PG_CORE L_PG_CORE
1,7
2,65
3
1,9
2,4
2,7
-0,2
0,25
0,3
1,7
2,1
2
1,6
1,85
2,3
0,1
0,25
-0,3
L_PG_GAMES L_PG_GAMES
L_PG_GFX L_PG_GFX
L_PG_IMMM L_PG_IMMM
3,75
3
6,6
3
3
6,6
0,75
0
0
2,75
3
4,4
2,75
3
4,4
0
0
0
L_PG_MESSA L_PG_MESSA
L_PG_OAF L_PG_OAF
L_PG_PCSW L_PG_PCSW
L_PG_PIM L_PG_PIM
L_PG_PM-SW L_PG_PM-SW
L_PG_SAT L_PG_SAT
L_PG_SPEC L_PG_SPEC
L_PG_SVER1 L_PG_SVER1
L_PG_SVER2 L_PG_SVER2
6
4,5
1
1,75
4
1
3,2
8,5
12,55
7,75
5
1
1,75
3
5
3,5
1
1,75
4
1
3,5
8,2
12,9
4,5
3,75
1
1,75
3
3,2
7,85
13,05
-1,75
-0,5
0
0
1
1
0
0,65
-0,5
2,9
8,05
12,6
0,5
-0,25
0
0
1
1
0,6
0,15
0,3
L_PG_SWARC L_PG_SWARC
0,2
0,2
0
0,2
0,2
0
L_PG_SWPRO L_PG_SWPRO
L_PG_SYDEV L_PG_SYDEV
L_PG_UIAPP L_PG_UIAPP
L_PG_UIDES L_PG_UIDES
L_PG_UIGUI L_PG_UIGUI
L_PG_UISPC L_PG_UISPC
L_PG_UITXT L_PG_UITXT
L_PG_UMTS L_PG_UMTS
1
4
3,5
0,8
4
2
5
4,5
1
3,1
3,25
1,05
3,41
1,4
3,7
2,75
0
0,9
0,25
-0,25
0,59
0,6
1,3
1,75
1
4
3,5
0,8
4
2
5
4,25
1
1,8
1,25
1
2,91
1,4
3,7
1,75
0
2,2
2,25
-0,2
1,09
0,6
1,3
2,5
2
2,75
91,25
2
5,2
87,36
0
-2,45
3,89
2
2,75
84,6
2
4,5
73,36
0
-1,75
11,24
L_PG_VERCO L_PG_VERCO
L_PG_WAP L_PG_WAP
SUM
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
200602
200602_REQ
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Project Steering:
Software Porting Project
SW Porting: Resource allocation is continuous
November - Requested versus Allocated
Stakeholders, Sponsor
8
7
Steering Group
6
Persons
5
Requested
4
Allocated
3
Resource
Management
Project
Change Control
2
Line Managers
Project Manager
Product Owner
1
0
Function Groups
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Project Steering:
Application Dev Project
Initial scope &
resources
then primarily selfgovernance
Project
Resource
allocation
Sponsor
1 dev team (devs +
tester)
Scrum Master (PM)
Scope Change
Control
Product Owner
“Steering group”
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group
Lund University / Faculty of Engineering/ Department of Computer Science / Software Engineering Research Group