2012-03-13 1 ETSF01: Software Engineering Process – Economy and Quality Dietmar Pfahl Lund University ETSF01 / Lecture 1, 2012 Software Risks (from 12 surveys) Source: Top Ten Lists of Software Project Risks: Evidence from the Literature Survey by Tharwon Arnuphaptrairong, Proceedings of IMEC 2011, March 16-18, 2011, Hong Kong ETSF01 / Lecture 1, 2012 The Magic Triangle Project Quality and Scope Time Effort (Cost) Trade -offs! ETSF01 / Lecture 1, 2012 Welcome to ETSF01! • Mandatory for C and D students • Requires ETSA01 • Size: 4 hp • 6 Lectures – Last lecture: course review and exam outlook • 1 Project • 5 Exercises (övningar) – Related to project (scheduled meetings with supervisor) – Exam-relevant exercises to be done at home (textbook) • 1 Final exam ETSF01 / Lecture 1, 2012 Course Materials Course web-page: • Assignments • Project instructions cs.lth.se/etsf01 Textbook Collection of formulas ETSF01 / Lecture 1, 2012 Lectures • Lecture 1: Course intro / Intro to SPM / SW project planning / SW process selection / Effort estimation intro • Lecture 2: Effort estimation (continued) • Lecture 3: Project evaluation / Activity planning • Lecture 4: Risk management / Resource allocation / Monitoring & control • Lecture 5: SW product and process quality / People and teams • Lecture 6: Course review and exam outlook
10
Embed
Lecture1-2012dp-004 - LTHcs.lth.se/fileadmin/cs/Dietmar_Pfahl/Lecture1-2012dp-004.pdf• Has a defined start and end point (i.e., ... Estimate effort for activity 8. ... #n+2 Iter
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
2012-03-13
1
ETSF01: Software Engineering Process –
Economy and Quality
Dietmar Pfahl Lund University
ETSF01 / Lecture 1, 2012
Software Risks (from 12 surveys) Source: Top Ten Lists of Software Project Risks: Evidence from the Literature Survey by Tharwon Arnuphaptrairong, Proceedings of IMEC 2011, March 16-18, 2011, Hong Kong
ETSF01 / Lecture 1, 2012
The Magic Triangle
Project
Quality and Scope
Time Effort (Cost)
Trade-offs!
ETSF01 / Lecture 1, 2012
Welcome to ETSF01!
• Mandatory for C and D students
• Requires ETSA01
• Size: 4 hp
• 6 Lectures – Last lecture: course review and
exam outlook • 1 Project • 5 Exercises (övningar)
– Related to project (à scheduled meetings with supervisor)
– Exam-relevant exercises to be done at home (à textbook)
• C: N. N. • C: N. N. • D: Julia Mauritsson • D: Peter Seimar
2012-03-13
3
ETSF01 / Lecture 1, 2012
Today’s Lecture (Part 1)
Chapters 1, 3, 4 Intro to SW project management SW project planning SW process selection
ETSF01 / Lecture 1, 2012
Plan with concrete People, activities, artifacts (Products)
Plan with concrete People, activities, artifacts (Products)
The six Ps in software engineering
• Product • Process • People • Program • Project • Plan
Process (= Project approach / method)
People (abstract, Roles)
Products (abstract)
Model World
Real World
Plan with concrete agents, activities, artifacts
Project Program
ETSF01 / Lecture 1, 2012
Characteristics of projects
• Non-routine tasks are involved • Planning is required • Specific objectives are to be met or a specified product is to be
created • Has a defined start and end point (i.e., a defined time-span) • Carried out for a customer (or many customers) • Carried out by a temporary work group • Involving several specialisations • Work is conducted in several phases • Constrained by resources • Large and/or complex
Project
Quality and Scope
Time Effort (Cost)
ETSF01 / Lecture 1, 2012
Are software projects really different from other projects?
Not really … but: • Invisibility (i.e., not tangible) • Complexity (i.e., can be enhanced easily) • Flexibility (i.e., can be changed easily)
… make software more problematic to build than other engineered artefacts.
ETSF01 / Lecture 1, 2012
What is (project) management?
• Planning – deciding what is to be done • Organizing – making arrangements • Staffing – selecting the right people for the job • Directing – giving instructions • Monitoring – checking on progress • Controlling – taking action to remedy hold-ups • Innovating – coming up with solutions when problems emerge • Representing – liaising with clients, users, developers and other
Idea: Sequential creation of products on different levels of abstraction (e.g., precede code by design, precede design by requirements) and integration in reverse direction Strictly sequential control flow can be weakened by controlled iterations
Prerequisites: Familiarity with application domains, methods, techniques, tools, engineering processes Good understanding of the requirements Stable requirements High capabilities for effort estimation
ETSF01 / Lecture 1, 2012
Boehm’s Spiral Model (1988)
Project Sart
ETSF01 / Lecture 1, 2012
Incremental delivery (Basili & Turner, 1975)
design build install evaluate
design build install evaluate
design build install evaluate
increment 1
increment 2
increment 3
First incremental delivery
Second incremental delivery
Third incremental delivery
delivered system
Requirements
2012-03-13
5
ETSF01 / Lecture 1, 2012
Rational Unified Process (RUP) (Jacobson, Rumbaugh, Booch, Kruchten, 1990s)
Iterations
Phases Process Workflows
Environment Project Management
Change & Configuration Mgmt
Elaboration Transition Inception Construction
Implementation Test
Analysis & Design
Deployment
Requirements Business modeling
Preliminary Iteration(s)
Iter. #1
Iter. #2
Iter. #n
Iter. #n+1
Iter. #n+2
Iter. #m
Iter. #m+1
Supporting Workflows
Organization along content
Organization along time
ETSF01 / Lecture 1, 2012
Extreme Programming – Evolutionary Process Model
ETSF01 / Lecture 1, 2012
XP – Rules and Practices
Planning User stories are written (by the customer!). Release planning creates the schedule. Make frequent small releases. The Project Velocity is measured. The project is divided into iterations. Iteration planning starts each iteration. Move people around. A stand-up meeting starts each day. Fix XP when it breaks.
Designing
Simplicity. Choose a system metaphor. Use CRC* cards for design sessions. Create spike solutions to reduce risk. No functionality is added early. Refactor whenever and wherever possible.
Coding The customer is always available. Code must be written to agreed standards. Code the unit test first. All production code is pair programmed. Only one pair integrates code at a time. Integrate often. Use collective code ownership. Leave optimization till last. No overtime.
Testing
All code must have unit tests. All code must pass all unit tests before it can be released. When a bug is found (acceptance) tests are created. Acceptance tests are run often and the score is published.
project in the Scrum process; they are the ones with "their bacon on the line".
– Product Owner – Scrum Master (or
Facilitator) – Team
"Chicken" roles • Chicken roles are not part of the
actual Scrum process, but must be taken into account.
– Users – Stakeholders (customers,
vendors) – Managers
• Note: An important aspect of an Agile approach is the practice of involving users, business and stakeholders into part of the process. It is important for these people to be engaged and provide feedback into the outputs for review and planning of each sprint.
As a guest, I want to change the dates of a reservation. 3
As a hotel employee, I can run RevPAR reports (revenue-per-available-room) 8
Improve exception handling 8
... 30
... 50
Tasks!Code the user interface!
Code the middle tier!
Test the middle tier!
Write online help!
Write the foo class!
Mon!8!
16!
8!
12!
8!
Tues!4!
12!
16!
8!
Wed! Thur!
4!
11!
8!
4!
Fri!
8!
8!
Add error logging!
8!
10!
16!
8!
8!
ETSF01 / Lecture 1, 2012
Sprint Burndown Chart – Example
(per
son-
hour
s)
ETSF01 / Lecture 1, 2012
‘Rules of thumb’ for selecting process
• IF uncertainty and complexity both low – THEN use waterfall process
• IF complexity is high but uncertainty is not – THEN use incremental process
• IF uncertainty is high – THEN use evolutionary/agile process
• IF schedule is tight/fixed – THEN use incremental or evolutionary/agile
approach • …
ETSF01 / Lecture 1, 2012
To be Agile or not to be Agile?
Source: Boehm, B.; Turner, R.; Observations on balancing discipline and agility, Proceedings of the Agile Development Conference, 2003. ADC 2003. Page(s):32-39
ETSF01 / Lecture 1, 2012
Alistair Cockburn – Project Categorizing
“Any one methodology is likely to be appropriate for only one of the boxes on one of the planes. Thus, at least 150 or so methodologies are needed!” [Alistair Cockburn: Selecting a Project 's Methodology. IEEE Software 17(4): (2000)]
Degree of Agility
ETSF01 / Lecture 1, 2012
Today’s Lecture (Part 2)
Chapter 5 Software effort estimation (intro)
2012-03-13
8
ETSF01 / Lecture 1, 2012
Cost/Schedule Estimation – Basic Idea
• Software cost/schedule estimation is the process of predicting the amount of effort (cost) required to build a software system and the time (schedule) to develop it.
• Project Cost:
– Hardware costs. – Travel and training costs. – Work costs (based on the effort spent by engineers).
• Project Schedule: – Elapsed time (in hours, days, weeks, months)
ETSF01 / Lecture 1, 2012
Typical problems with estimating
• Subjective nature of estimating – It may be difficult to produce evidence supporting assumptions
about cost (schedule) drivers • Political pressures
– Managers may wish to reduce estimated costs in order to win a project proposal
– Developers may wish to increase estimates to safeguard themselves from unforeseen (unforeseeable) risks
• Changing technologies – They involve risks (uncertainties), especially in the beginning when
there is a ‘learning curve’ • Projects differ
– Lessons learnt in one project may not be transferable to another
ETSF01 / Lecture 1, 2012
Estimation Techniques – Main Types
Cost/Schedule Estimation Techniques
Expert Judgment Algorithmic/ Parametric Models
Empirical Factor Models: - COCOMO / COCOMO II - ESTIMACS - PRICE S - Softcost - DOTY - CheckPoint - etc.
Constraint Models: - SLIM - Jensen Model - COPMO - etc.
Analogy
Machine Learning: - Case-Based Reasoning - Collaborative Filtering - Classification Systems - etc.
Other
Parkinson’s Law Pricing-to-Win Top-Down Estimation Bottom-Up Estimation
- Delphi-Method - Planning Poker - …
ETSF01 / Lecture 1, 2012
Example 1: Expert Judgement
Planning Poker All members of the development team participate. • Step 1: Give each estimator a deck of cards • Step 2: Moderator reads description of User
Story to be estimated. • Step 3: Product owner answers any question
the estimators may have about the User Story. • Step 4: Each estimator privately selects a card
representing his or her estimate. Cards are not shown until each estimator has made a selection.
• …
ETSF01 / Lecture 1, 2012
Planning Poker (cont’d)
• Step 5: When everyone has made an estimate, the cards are simultaneously turned over.
• Step 6: If estimates differ, the highest and lowest estimates are explained by the estimators - otherwise the estimation is completed for this User Story.
• Step 7: The group discusses the story and their estimates for a few more minutes. The moderator can take any notes he/she thinks will be helpful when this story is being programmed and tested. After the discussion, each estimator re-estimates by selecting a card.
Note: In many cases, the estimates will already converge by the second round. But if they have not, continue to repeat the process. The goal is for the estimators to converge on a single estimate that can be used for the story. It rarely takes more than three rounds, but continue the process as long as estimates are moving closer together.
ETSF01 / Lecture 1, 2012
Example 2: Estimation by Analogy
Case-Based Reasoning (CBR): – Involves:
1. Matching the new case (= problem, project) against cases (= problems, projects) encountered in the past, and
2. Adapting the solutions (= characteristics) of the past cases (= problems, projects) to the current context.
– It can be represented as a cyclical process that is divided into the four following sub-processes as depicted in the figure on the left:
• retrieve the most similar past case(s) from the case base
• reuse retrieved case(s) to solve the current case with an adaptation rule
• revise the proposed solution – if necessary • retain the solution for future problem solving
2012-03-13
9
ETSF01 / Lecture 1, 2012
Example 2: Estimation by Analogy
Case-Based Reasoning (CBR): – Involves:
1. Matching the new case (= problem, project) against cases (= problems, projects) encountered in the past, and
2. Adapting the solutions (= characteristics) of the past cases (= problems, projects) to the current context.
– It can be represented as a cyclical process that is divided into the four following sub-processes as depicted in the figure on the left:
• retrieve the most similar past case(s) from the case base
• reuse retrieved case(s) to solve the current case with an adaptation rule
• revise the proposed solution – if necessary • retain the solution for future problem solving
Similarity Function
ETSF01 / Lecture 1, 2012
Example 2: Estimation by Analogy
Case-Based Reasoning (CBR): – Involves:
1. Matching the new case (= problem, project) against cases (= problems, projects) encountered in the past, and
2. Adapting the solutions (= characteristics) of the past cases (= problems, projects) to the current context.
– It can be represented as a cyclical process that is divided into the four following sub-processes as depicted in the figure on the left:
• retrieve the most similar past case(s) from the case base
• reuse retrieved case(s) to solve the current case with an adaptation rule
• revise the proposed solution – if necessary • retain the solution for future problem solving
Adaptation Rule
ETSF01 / Lecture 1, 2012
Estimation by Analogy – CBR Example 1 Case-Based Reasoning (CBR) Example:
Attributes New Case Retrieved Case 1 Retrieved Case 2 Project Category Real Time Real Time Simulator Language C++ C++ C++ Team Size 10 10 9 System Size 150 200 175 Effort ? 1000 950 Similarity 90% ~50%
Adaptation rule 1: 7501000
200150
=∗=Effort_edictedPr
Possible adaptation rules to predict effort: 1. adapted effort based on 1 project 2. average effort of 2 projects 3. weighted average effort of 2 projects
Effort= f (System_Size)
ETSF01 / Lecture 1, 2012
Estimation by Analogy – CBR Example 2 Case-Based Reasoning (CBR) Example:
Attributes New Case Retrieved Case 1 Retrieved Case 2 Project Category Real Time Real Time Simulator Language C++ C++ C++ Team Size 10 10 9 System Size 150 200 175 Effort ? 1000 950 Similarity 90% ~50%
Adaptation rule 2: Possible adaptation rules to predict effort: 1. adapted effort based on 1 project 2. average effort of 2 projects 3. weighted average effort of 2 projects
7829501751501000
200150
21_ ≈⎟
⎠
⎞⎜⎝
⎛ ∗+∗=EffortedictedPr
Effort= f (System_Size)
ETSF01 / Lecture 1, 2012
Estimation by Analogy – CBR Example 3 Case-Based Reasoning (CBR) Example:
Attributes New Case Retrieved Case 1 Retrieved Case 2 Project Category Real Time Real Time Simulator Language C++ C++ C++ Team Size 10 10 9 System Size 150 200 175 Effort ? 1000 950 Similarity 90% ~50%
Adaptation rule 3:
Possible adaptation rules to predict effort: 1. adapted effort based on 1 project 2. average effort of 2 projects 3. weighted average effort of 2 projects
773145*950
175150
149*1000
200150_Pr ≈∗+∗=Effortedicted
Effort= f (System_Size)
ETSF01 / Lecture 1, 2012
Estimation by Analogy – CBR Examples Similarity(Pnew, P1): Distance Measure (Euclidean Distance) à Similarity = 1 – Distance
n
)P,P()P,P(cetandis
n
kjkik
ji
∑== 1
δ
⎪⎪⎪
⎩
⎪⎪⎪
⎨
⎧
≠=
⎟⎟
⎠
⎞
⎜⎜
⎝
⎛
−
−
=
jkik
jkik
kk
jkik
jkik
PPANDlcategoricakif,PPANDlcategoricakif,
continuouskifminmaxPP
)P,P(10
2
δ
P.,k Pnew,k P1,k δ(Pnew,k, P1,k) Project Category Real Time Real Time 0 Language C++ C++ 0 Team Size 10 10 0 System Size 150 200 0.04=(50/250)2
⇒ similarity(Pnew, P1) = 1 – distance(Pnew, P1) = 1 – sqrt(0.04/4) = 0.1 Note: We know that smallest system in DB has size=100 and largest system has size=350 à max – min = 250
2012-03-13
10
ETSF01 / Lecture 1, 2012
Estimation by Analogy – CBR Examples Similarity(Pnew, P2): Distance Measure (Euclidean Distance) à Similarity = 1 – Distance
n
)P,P()P,P(cetandis
n
kjkik
ji
∑== 1
δ
⎪⎪⎪
⎩
⎪⎪⎪
⎨
⎧
≠=
⎟⎟
⎠
⎞
⎜⎜
⎝
⎛
−
−
=
jkik
jkik
kk
jkik
jkik
PPANDlcategoricakif,PPANDlcategoricakif,
continuouskifminmaxPP
)P,P(10
2
δ
P.k Pnew,k P2,k δ(Pnew,k,P2,k) Project Category Real Time Simulator 1 Language C++ C++ 0 Team Size 10 9 0.01=(1/10)2
System Size 150 200 0.01=(25/250)2
⇒ similarity(Pnew, P2) = 1 – sqrt(1.02/4) ≈ 0.5 Note: We know that smallest team size in DB equals 6 persons and largest team size in DB equals 16 persons à max – min = 10
ETSF01 / Lecture 1, 2012
Rest of this week
• Read textbook chapters 1, 3, 4
• Read project description and project mission
• Form project groups • Attend Exercise 1 (mandatory)