University of Southern California
Center for Systems and Software Engineering
Process Models
CS510
Supannika Koolmanojwong
University of Southern California
Center for Systems and Software Engineering
Outline
•
•
•
•
•
•
•
What is a Process Model?
Spiral Family of Models (1988 – 2011)
Incremental Commitment Spiral Model
V-Model
RUP/OpenUp
Lean, Scrum, XP, Kanban
Concurrent Engineering
(C) 2012 USC-CSSE
2
University of Southern California
Center for Systems and Software Engineering
Code-and-fix
• Free-form working environments
• Hobby project
• Cowboy programming
– Lack of structure
– Uncertain design requirements
– Incompleteness
• Code monkey – simple, repetitive code
• Indie development – mostly video game
(C) 2012 USC-CSSE
3
University of Southern California
Center for Systems and Software Engineering
Software Development Process
• Or Software Development Life Cycle
• The actual set of activities performed within
an organization
• Popular Models:
–
–
–
–
Waterfall model
Spiral model
Iterative and Incremental model
Agile model
(C) 2012 USC-CSSE
4
University of Southern California
Center for Systems and Software Engineering
Waterfall Model
Spiral Model
Iterative and Incremental
Model
(C) 2012 USC-CSSE
Agile Model
5
University of Southern California
Center for Systems and Software Engineering
Biggest Waterfall Software
Project Failure
• Throughout the 1980s and into the 1990s,
most DoD projects followed the Waterfall
approach
– 75 percent of the projects failed or were never
used.
• HealthCare.gov ??
• FBI Virtual Case File ?? $170 Million
http://www.infoq.com/resource/articles/scaling-software-agility/en/resources/ch02.pdf
(C) 2012 USC-CSSE
6
University of Southern California
Center for Systems and Software Engineering
Biggest Agile Software
Development Failure
• UK Universal Credit (UC) digital project, £2bn ,
• 2010 and going on
• UK is trying to promote Agile software
development
• Claimed to be the biggest agile software
development project
• To replace six of the main tax and benefits system
in UK (tax credit, housing benefits, ..)
(C) 2012 USC-CSSE
http://www.computerweekly.com/news/2240187478/Why-agile-development-failed-for-Universal-Credit
7
University of Southern California
Center for Systems and Software Engineering
Biggest Agile Software
Development Failure
• Facts
– Started with Agile
– 24 contractors including HP, IBM, Capgemini,
ThoughtWorks, ….
– after two project directors departed (fired?, one dead), the
third one changed to waterfall (2013)
– 1500 people, massive number of suppliers
• Claims
–
–
–
–
Problems from Waterfall-like contract
Command and Control culture
Contractors learn agile on the fly; never done agile before
disguise traditional processes as agile
(C) 2012 USC-CSSE
http://www.computerweekly.com/news/2240187478/Why-agile-development-failed-for-Universal-Credit
8
University of Southern California
Center for Systems and Software Engineering
Outline
•
•
•
•
•
•
•
What is a Process Model?
Spiral Family of Models (1988 – 2011)
Incremental Commitment Spiral Model
V-Model
RUP/OpenUp
Lean, Scrum, XP, Kanban
Concurrent Engineering
(C) 2012 USC-CSSE
9
University of Southern California
Center for Systems and Software Engineering
Spiral Family of Models
Spiral Model
1988
WinWin Spiral
1994
Anchor Point Milestones
Spiral/RUP compatibility
1996
MBASE
1999
Spiral, MBASE
variants and invariants
2001
LeanMBASE
2005
Where do OC&A’s come from?
Where are phases and milestones ?
How to avoid model clashes?
What is really required and optional ?
How to make the process more lean and agile?
• How can spiral be mapped onto system
acquisition phases and milestones?
• How can hardware, software and human
factors be integrated?
Incremental Commitment Model
Incremental Commitment Spiral Model
(C) 2012 USC-CSSE
2007
2010
10
University of Southern California
Center for Systems and Software Engineering
Spiral Model (1988)
Waterfall model
-Focus on front load elaboration
Spiral model
-Risk-driven
-Complete a round by review
-Round 0- Feasibility Study
-Round 1- Concepts of Operations
-Round 2- Top level Reqm Spec
http://csse.usc.edu/csse/TECHRPTS/1988/usccse88-500/usccse88-500.pdf
(C) 2012 USC-CSSE
11
University of Southern California
Center for Systems and Software Engineering
WinWin Spiral Model (1994)
Use the Theory W (win-win) approach to converge on a system's next level
objectives, constraints and alternatives.
http://csse.usc.edu/csse/TECHRPTS/1995/usccse95-509/usccse95-509.pdf
(C) 2012 USC-CSSE
12
University of Southern California
Center for Systems and Software Engineering
Anchor Point Milestones (1996)
•Lack of intermediate milestones
– Anchor Points:
LCO, LCA, IOC
– Concurrent-engineering spirals between anchor points
http://csse.usc.edu/csse/TECHRPTS/1995/usccse95-507/usccse95-507.pdf
(C) 2012 USC-CSSE
13
University of Southern California
Center for Systems and Software Engineering
Spiral/RUP compatibility
(C) 2012 USC-CSSE
14
University of Southern California
Center for Systems and Software Engineering
Model-Based (System) Architecting and Software Engineering
(MBASE)
(C) 2012 USC-CSSE
15
University of Southern California
Center for Systems and Software Engineering
The Incremental Commitment Model
6 Key Principles:
Commitment and
accountability
Incremental growth of
system definition and
stakeholder commitment
Concurrent engineering and
Iterative development
cycles
Success-critical stakeholder
satisficing
Risk-based activity levels
and milestones
(C) 2012 USC-CSSE
16
University of Southern California
Center for Systems and Software Engineering
ICSM: The Incremental Commitment Spiral Model
Cumulative Level of Understanding, Product and Process
Detail (Risk-Driven)
Concurrent
Engineering of
Products and
Processes
OPERATION2
DEVELOPMENT3
FOUNDATIONS4
OPERATION1
DEVELOPMENT2
FOUNDATIONS3
DEVELOPMENT1
FOUNDATIONS2
FOUNDATIONS
RISK-BASED
STAKEHOLDER
COMMITMENT
REVIEW
POINTS:
VALUATION
EXPLORATION
6
5
4
3
2
1
Opportunities to
proceed, skip
phases
backtrack, or
terminate
Risk-Based Decisions
Evidence-Based Review Content
- A first-class deliverable
- Independent expert review
- Shortfalls are uncertainties and risks
Acceptable
Negligible
Risk
Too High,
Unaddressable
High, but
Addressable
(C) 2012 USC-CSSE
1
Exploration Commitment Review
2
Valuation Commitment Review
3
Foundations Commitment Review
4
Development Commitment Review
5
Operations1 and Development2
Commitment Review
6
Operations2 and Development3
Commitment Review
17
University of Southern California
Center for Systems and Software Engineering
Spiral Family of Models
Spiral Model
1988
WinWin Spiral
1994
Anchor Point Milestones
Spiral/RUP compatibility
1996
MBASE
1999
Spiral, MBASE
variants and invariants
2001
LeanMBASE
2005
Where do OC&A’s come from?
Where are phases and milestones ?
How to avoid model clashes?
What is really required and optional ?
How to make the process more lean and agile?
• How can spiral be mapped onto system
acquisition phases and milestones?
• How can hardware, software and human
factors be integrated?
Incremental Commitment Model
Incremental Commitment Spiral Model
(C) 2012 USC-CSSE
2007
2010
18
University of Southern California
Center for Systems and Software Engineering
Outline
•
•
•
•
•
•
•
What is a Process Model?
Spiral Family of Models (1988 – 2011)
Incremental Commitment Spiral Model
V-Model
RUP/OpenUp
Lean, Scrum, XP, Kanban
Concurrent Engineering
(C) 2012 USC-CSSE
19
University of Southern California
Center for Systems and Software Engineering
V-Model
- Extension of Waterfall model, but V up to pair development with testing
- Widely used in systems engineering
- Does not explicitly shown the concurrent engineering
- Challenges in supporting evolutionary development
(C) 2012 USC-CSSE
20
University of Southern California
Center for Systems and Software Engineering
Dual-Vee Model
-Show concurrent development
-Supports system of systems
Forsberg, Kevin; Harold Mooz, Howard Cotterman (2005), Visualizing Project Management, Third Edition, New York, NY:
J. Wiley & Sons, Inc.
(C) 2012 USC-CSSE
21
University of Southern California
Center for Systems and Software Engineering
V with multiple deliveries
(C) 2012 USC-CSSE
22
University of Southern California
Center for Systems and Software Engineering
The death of V-model ???
(software development)
• Does not accommodate the change
• Inefficient testing technique (write test as
soon as the architecture is done)
• Definitely not in System Engineering
• May be just not popular in Software
Engineering
http://www.harmonicss.co.uk/index.php/tutorials/software-engineering/56?task=view
(C) 2012 USC-CSSE
23
University of Southern California
Center for Systems and Software Engineering
Outline
•
•
•
•
•
•
•
What is a Process Model?
Spiral Family of Models (1988 – 2011)
Incremental Commitment Spiral Model
V-Model
RUP/OpenUp
Lean, Scrum, XP, Kanban
Concurrent Engineering
(C) 2012 USC-CSSE
24
University of Southern California
Center for Systems and Software Engineering
Rational Unified Process (RUP)
Discipline
Six Best Practices
• Develop iteratively
• Manage requirements
• Use components
• Model visually
• Verify quality
• Control changes
http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
(C) 2012 USC-CSSE
25
University of Southern California
Center for Systems and Software Engineering
OpenUP
• OpenUP is a lean Unified Process that
applies iterative and incremental
approaches within a structured lifecycle
http://epf.eclipse.org/wikis/openup/
(C) 2012 USC-CSSE
26
University of Southern California
Center for Systems and Software Engineering
Outline
•
•
•
•
•
•
•
What is a Process Model?
Spiral Family of Models (1988 – 2011)
Incremental Commitment Spiral Model
V-Model
RUP/OpenUp
Lean, Scrum, XP, Kanban
Concurrent Engineering
(C) 2012 USC-CSSE
27
University of Southern California
Center for Systems and Software Engineering
Lean Principles
• From Toyota Production System
• 7 Lean principles
– Eliminate waste – anything that does not add value
– Amplify learning – continuous update about the project
– Decide as late as possible – delay decisions, gather more information
– Deliver as fast as possible – daily deliveries, daily standup meeting
– Empower the team – get good people, listen, communicate
– Build integrity in – build good products
– See the whole - “Think big, act small, fail fast; learn rapidly”
(C) 2012 USC-CSSE
28
University of Southern California
Center for Systems and Software Engineering
Eliminate waste
•
•
•
•
Waste = anything that does not create
value for a customer
Step 1: learning to see waste
Step 2: uncover the biggest sources of
waste and eliminate them
Step 3: uncover the biggest remaining
sources of waste and eliminate them
(C) 2012 USC-CSSE
29
University of Southern California
Center for Systems and Software Engineering
The seven wastes of Software Development
1. Partially Done Work – tend to become obsolete; no idea it will
eventually work; waste resources; should do risk-reduction and
waste-reduction
2. Extra Processes – paperwork necessary?, try to use table, template
3. Extra Features – waste time and resources
4. Task Switching – put people in multiple projects
5. Waiting – causes delay; decide as late as possible
6. Motion – even walking down the hall waste time; sit in the same
room
7. Defects – detect defect as soon ASAP
8. Management activities – instead of tracking status, make sure work
flows properly; reduce tracking time
(C) 2012 USC-CSSE
30
University of Southern California
Center for Systems and Software Engineering
Scrum
• Compared to Rugby game, where all partners tackle the
problem, passing the ball back and forth
• Three main roles: Scrum master, Product owner, Team
• Self-organizing, co-location teams
(C) 2012 USC-CSSE
31
University of Southern California
Center for Systems and Software Engineering
http://www.codeproject.com/KB/architecture/scrum.aspx
(C) 2012 USC-CSSE
32
University of Southern California
Center for Systems and Software Engineering
Introduction to scrum
• Scrum Framework
• http://www.youtube.com/watch?v=_BWbaZ
s1M_8&feature=related
• Explaining Scrum
• http://www.youtube.com/watch?v=WxiuE1ujCM&feature=related
(C) 2012 USC-CSSE
33
University of Southern California
Center for Systems and Software Engineering
Scrum
Scrum vs ICSM
Definition
ICSM
Product Backlog List
Prioritized list of requirements; may be or may
be not developed;
Requirements, Capabilities
Sprint
Two to four weeks
Iteration
Product Increment
Result of each iteration
Iteration assessment report
Scrum Master
A management representative
Facilitator; Success Critical
Stakeholder
Daily Scrum
Short daily team meeting
Team meeting
Product owner
Prioritize backlog; decide the order in which
things are built
Success Critical Stakeholder
Scrum team
Stakeholders
Success Critical Stakeholder
Sprint Backlog
List of tasks to perform during each Sprint
Iteration plan
Sprint Review Meeting
End of sprint meeting; to review product
increment
ARB
Impediment
Things that block the project progress
Risks, defects, concerns, issues,
problems
Sprint Retrospective
Look backward- what went well …
Iteration assessment
Planning Poker
Estimation
Cost, schedule estimation
Prioritization
Definition of Done
Successful condition of an item
Exit Criteria
(C) 2012 USC-CSSE
34
University of Southern California
Center for Systems and Software Engineering
XP-Extreme Programming
•
•
•
•
Frequent release
Shorter timebox
Frequent communication
Expecting requirements
changes
Drawbacks
• Unstable requirements
• No documents
• Lack of overall design
(C) 2012 USC-CSSE
35
University of Southern California
Center for Systems and Software Engineering
XP Practice
XP principles
Description
The Planning Game
User stories describe the desired features of the software system. Evaluate
/estimate on how long and how important for each story
Small Releases
User stories are prioritized and allocated to small releases
Organizing System
Metaphor
Metaphor for system selected to guide implementation and naming conventions.
Simple Design
Only implement that which is required at current point in time.
Continuous Testing
Software tests are planned and written as part of the design process. Unit Test.
Acceptance testing is specified by the customer.
Refactoring
Restructure the code or the underlying data model for the software system as the
software system evolves
Pair Programming
All code is written by two developers, one entering the code and one reviewing
Collective Ownership of All code is “owned” by all developers working on the software system. Eliminate the
Code
need to “coordinate” changes with other developers.
Continuous Integration
All code changes are entered into the code base on a daily basis and tested daily in
the integrated environment.
40-Hour Work Week
All developers work 40 hour week with few exceptions.
On-site Customer
Continuous access to a CRACK customer representative to ensure timely response
Coding Standards
Every developer follows the same coding standards
(C) 2012 USC-CSSE
36
University of Southern California
Center for Systems and Software Engineering
XP
• Three types of wastes from Toyota Production
system
– Muda – non-value added tasks
• E.g. No gold plating
• Avoid Muda by using high planning and coordination
– Muri – uneveness or variability
• Avoid Muri by using skilledcraftmanship, one story at
a time
– Mura – overburdening or failure load
• E.g. Fixing bugs, responds to helpdesk, fix
requirements
• Avoid Mura by using tests and tight definition of done
Ref: David Anderson, XP 2010 , Trondheim, Norway
(C) 2012 USC-CSSE
37
University of Southern California
Center for Systems and Software Engineering
To reduce waste in XP
• Techniques to reduce waste in XP
– Agile Workcell
– Elimination of planning
– Reducing Red
• This introduces Kanban (further elimination
of waste)
(C) 2012 USC-CSSE
38
University of Southern California
Center for Systems and Software Engineering
Scrum vs XP
http://tommynorman.blogspot.com/2009_01_01_archive.html
(C) 2012 USC-CSSE
39
University of Southern California
Center for Systems and Software Engineering
Kanban
•
•
•
•
Focus on “managing flow”
Limit Work-In-Progress: complete a feature before starting a new one
Iteration and estimate are optional
Could be used on top of other processes
http://www.crisp.se/kanban
(C) 2012 USC-CSSE
40
University of Southern California
Center for Systems and Software Engineering
Kanban concepts
• Visualize workflow
– More than work, but interaction and
coordination
• Limit Work-in-progress
• Measure and Manage Flow
– Use metrics such as velocity,
burndown, churn
• Make Process Policies explicit
Traffic at 100 percent capacity
does not move
– Clear on who is doing what and when
• Use Models to evaluate
improvement opportunities
Ref: David Anderson, XP 2010 , Trondheim, Norway
http://moduscooperandi.com/personalkanban/why-limit-work-in-progress/
(C) 2012 USC-CSSE
41
University of Southern California
Center for Systems and Software Engineering
Visualize Workflow & Limit WIP
At a morning standup meeting……
1.Observe workflow
•What is happening?
•Where is the bottleneck?
2.Check performance
•Velocity, backlog
3.Identify improvement
opportunities
David Anderson, XP 2010 , Trondheim, Norway
(C) 2012 USC-CSSE
42
University of Southern California
Center for Systems and Software Engineering
• Probably no instant feedback from Success Critical Stakeholders
• What can be improved here ?
– Bottleneck, Variability, Waste
• Craftmanship & Leadership to improve the process and use performance as
evidence to support
David Anderson, XP 2010 , Trondheim, Norway
(C) 2012 USC-CSSE
43
University of Southern California
Center for Systems and Software Engineering
How to start assigning tasks?
(C) 2012 USC-CSSE
44
University of Southern California
Center for Systems and Software Engineering
(C) 2012 USC-CSSE
45
University of Southern California
Center for Systems and Software Engineering
Limit Work-In-Progress
If urgent, drop the green task, because it has the lowest cost of delay
(C) 2012 USC-CSSE
46
University of Southern California
Center for Systems and Software Engineering
Example of Kanban Board
(C) 2012 USC-CSSE
47
University of Southern California
Center for Systems and Software Engineering
Kanban applied to Scrum
• http://www.youtube.com/watch?v=0EIMxyF
w9T8
(C) 2012 USC-CSSE
48
University of Southern California
Center for Systems and Software Engineering
Comparing ICSM with Lean and Agile
ICSM Principles [a]a
Commitment and
accountability of system
sponsors
Related Lean Principles
 See the whole: balanced objectives,
contract incentives, measuring the
right thing(s)
 Empower the team



Success-critical stakeholder
satisficing
Iterative development cycles
and incremental growth of
system definition and
stakeholder commitment
Concurrent engineering
Risk-based activity levels and
milestones
 Deliver as fast as possible

 Amplify learning
 Build integrity in
 Decide as late as possible to support
concurrent development while
keeping options open
 Empower the team
 Decide as late as possible to support
concurrent development while
keeping options open
 Eliminate waste
 Amplify learning
 Build integrity in









(C) 2012 USC-CSSE
Related Agile Principles
Business people and developers must work together daily
throughout the project.
Provide the developers with environment and support they
need
The most efficient and effective method of conveying
information to and within a development team is face-toface conversation.
Satisfy the customer through early and continuous delivery
of valuable software.
Welcome changing requirements, even late
in development.
Deliver working software frequently
Working software is the primary measure of progress
Agile processes promote sustainable development.
Continuous attention to technical excellence and good
design enhances agility.
The best architectures, requirements, and designs emerge
from self-organizing teams.
Team reflects periodically on how to become more
effective, then tunes and adjusts its behavior accordingly
Simplicity--the art of maximizing the amount of work not
done--is essential.
Agile processes promote sustainable development.
49
University of Southern California
Center for Systems and Software Engineering
Outline
•
•
•
•
•
•
•
What is a Process Model?
Spiral Family of Models (1988 – 2011)
Incremental Commitment Spiral Model
V-Model
RUP/OpenUp
Lean, Scrum, XP, Kanban
Concurrent Engineering
(C) 2012 USC-CSSE
50
University of Southern California
Center for Systems and Software Engineering
Concurrent Engineering
• TeamX – JPL
• Concept Design Center – Aerospace Corp.
(C) 2012 USC-CSSE
51
University of Southern California
Center for Systems and Software Engineering
(C) 2012 USC-CSSE
CDC Tasks
52
University of Southern California
Center for Systems and Software Engineering
(C) 2012 USC-CSSE
53
University of Southern California
Center for Systems and Software Engineering
(C) 2012 USC-CSSE
54
University of Southern California
Center for Systems and Software Engineering
(C) 2012 USC-CSSE
55
University of Southern California
Center for Systems and Software Engineering
(C) 2012 USC-CSSE
56