Incremental Commitment Spiral Model,
Expedited Engineering,
and Kanban
Jo Ann Lane and Alexey Tregubov
USC CSSE
Rich Turner
Stevens University
Outline
• Incremental Commitment Spiral Model (ICSM)
Overview
• ICSM and lean engineering
• Kanban processes for large, complex
development organizations
3/13/13
CSSE ARR 2013
2
What is the ICSM?
• Risk-driven framework for determining and evolving
best-fit system life-cycle process
• Integrates the strengths of phased and risk-driven
spiral process models
• Synthesizes together principles critical to successful
system development
– Stakeholder value-based system definition and evolution
– Incremental commitment and accountability
– Concurrent hardware, human factors, and software system
definition and development
– Evidence-based and risk-based decision-making
Principles
trump
diagrams…
Principles used by 60-80% of CrossTalk Top-5 projects, 2002-2005
3/13/13
CSSE ARR 2013
3
Risk-Driven Scalable Spiral Model:
Increment View
Unforeseeable Change (Adapt)
Agile
Rebaselining for
Future Increments
Rapid
Change
Foreseeable
Change
(Plan)
Short
Development
Increments
Increment N Baseline
Stable Development
Increments
High
Assurance
Current V&V
Resources
Continuous V&V
3/13/13
Future Increment Baselines
Deferrals
Short, Stabilized
Development
of Increment N
Artifacts
Verification and
Validation (V&V)
of Increment N
CSSE ARR 2013
Increment N Transition/
Operations and Maintenance
Concerns
Future V&V
Resources
4
Small Custom Software Systems
Case ID
1
2
3
3/13/13
Name
Description
Agile
Software developed using pure agile
methods with short-duration sprints
Architected agile
Initial sprint focuses on
foundations/architecture issues, then
transitions to pure agile process for
development of software capabilities
Formal methods
Critical software system or subsystem,
often containing security- or safetyrelevant software or critical/high-precision
algorithms that must be rigorously
developed, tested, and often certified
CSSE ARR 2013
5
COTS-Based
Case ID
4
3/13/13
Name
Description
Systems range from single COTS
products to multiple integrated
COTS products.
COTS-Based System
CSSE ARR 2013
6
Larger, More Complex
Hardware/Software Systems
Case ID
Name
Description
5
Software-intensive
device
Hardware-software user-interactive device not part of a product
line
6
Large software-intensive system with varying component
Large software-intensive types/complexity. Differs from system of systems in that
system
components are typically always integrated and not
reconfigured for specific system missions.
Large-scale platform with embedded software systems.
Development is driven by hardware platform and software
supports platform capabilities.
7
Platform-based system
8
Set of independent (constituent) systems that can be integrated
System of systems/
together in a manner that allows them to interoperate and
enterprise-wide systems
perform cross-cutting mission-specific capabilities.
9
Family of
systems/product lines
10
Brownfield
modernization
3/13/13
Set of systems that can interoperate with each other or are
related to each other (e.g., have common components) as part
of a product line.
Incremental legacy phase-out.
CSSE ARR 2013
7
Basis for Spin and Increment Planning
MC 1
Req 1
Req 2
Product 1
Product 1:
Req 1
Req 2
Req 3
Req 6
Performance Reqs
3/13/13
MC 2
Req 3
Req 4
Req 5
MC 3
Req 6
Req 7
Req 8
Product 2
Product 3
Product 4
Product 2:
Req 1
Req 3
Req 4
Req 6
Product 3:
Req 1
Req 2
Req 5
Req 7
Product 4:
Req 1
Req 2
Req 3
Req 4
Req 5
Req 7
Req 8
Computation Reqs
CSSE ARR 2013
Interface Reqs
8
Kanban Scheduling System (KSS)
Network
Dash
Execu ve/Stakeholder
Management
SLA establishment and monitoring
Strategic planning
Capability priori za on
Dash
Product/Domain Engineering
Dash
KSS
Users
KSS
Needs
Backlog*
User Support
Customer rela ons
Ini al Triage
Capability Engineering
Analyze needs and alterna ves
Refine capabili es
Develop requirements
Allocate requirements
Product Team
Dash
Product SE
Iden fy SW Features
Allocate features to SWDT
Integrate features into requirements
KSS
KSS
Form cross organiza onal teams
Cross-product and specialty engineering
KSS
SW Development Team
Validate and fully enable capabili es
KSS Pa ent Safety Domain Team
Work Flow
Visibility
* All organiza ons can contribute to the Needs Backlog
3/13/13
CSSE ARR 2013
KSS
Network Domain Team
9
Classes of Service
•
•
•
•
•
3/13/13
Critical Expedite
Important
Date Certain
Standard
Background
CSSE ARR 2013
10
Health Care Example
• New capability to interface to a new health
insurance company
• New capability to integrate and analyze
information from multiple patient telemetry
systems to improve diagnostic capabilities
• User response improvement
• Periodic upgrade of pharmacy formulary
information
• Patient safety issue due to interoperability
problem
3/13/13
CSSE ARR 2013
11
Kanban Flow for Healthcare
Examples
Per f o r m a n ce
I ssue I n i t i at ed
I n sur a n ce a n d
Tel em et r y I ssues
I n i t i at ed
Stakeholders
ESM
Per f o r m a n c e
I ssu e Tr a n sf er r ed
Demand
Ext.
Source
Request
No r m al Co S
Wo r k I t em s
CE
Users
Pat i ent Reco r d s
I ssue
I n i t i at ed
Demand
US
Stakeholders
Ext.
Source
Request
ESM
Fo r m u l ar y
Upd at e
Demand
I m po r t a n t Co S
Wo r k I t em
Pat i en t Rec o r d s
I ssu e Escal at ed
[ Pat i en t sa f et y]
Demand
Cr i t i cal Ex ped i t e
Wo r k
CE
Demand
Demand
Dat e Cer t a i n Wo r k
I t em
Ext.
Source
Request
Requ i r em en t s
t o Tea m s
3/13/13
Demand
Database DT
Ext.
Source
Request
Demand
Cu r r en t
Dev el o pm en t
Requ i r em en t s
Crisis
Team
Cr i t i cal
Ex ped i t e
Wo r k
Ext.
Source
Request
Demand
Ext.
Source
Request
US
Demand
Ext.
Source
Request
Pharmacy DT
Ext.
Source
Request
Users
PT
Demand
Database DT
Reso u r c es
Wo r k
CSSE ARR 2013
12
PT
Future Work
• Continue work on
– “Value” strategies
– Priority strategies
More details on this in
next presentation…
• Identify organizations to pilot
• Work with Kanban tool vendors
3/13/13
CSSE ARR 2013
13
Questions?
3/13/13
CSSE ARR 2013
14