Using the Incremental
Commitment Model (ICM)
Process Decision Table
Barry Boehm
USC CSSE
October 2007
6/27/2016
(c) USC-CSSE
1
The Incremental Commitment Life Cycle
Process: Overview
Stage I: Definition
Stage II: Development and Operations
Anchor Point
Milestones
Synchronize, stabilize concurrency via FRs
Risk patterns
determine life
cycle process
6/27/2016
(c) USC-CSSE
2
The ICM as Risk-Driven
Process Generator
• Stage I of the ICM has 3 decision nodes with 4
options/node
– Culminating with incremental development in Stage II
– Some options involve go-backs
– Results in many possible process paths
• Can use ICM risk patterns to generate frequentlyused processes
– With confidence that they fit the situation
• Can generally determine this in the Exploration phase
– Develop as proposed plan with risk-based evidence at VCR
milestone
– Adjustable in later phases
6/27/2016
(c) USC-CSSE
3
The ICM Process Decision
Table: Key Decision Inputs
•
•
•
•
Product and project size and complexity
Requirements volatility
Mission criticality
Nature of Non-developmental Item
(NDI) support
– Commercial, open-source, reused
components
• Organizational and Personnel Capability
6/27/2016
(c) USC-CSSE
4
The ICM Process Decision
Table: Key Decision Outputs
• Key Stage I activities: incremental
definition
• Key Stage II activities: incremental
development and operations
• Suggested calendar time per build, per
deliverable increment
6/27/2016
(c) USC-CSSE
5
Common Risk-Driven Special Cases of the
Incremental Commitment Model (ICM)
Special Case
Example
Size,
Comple
xity
Change
Rate %
/Month
Criticali
ty
NDI Support
1. Use NDI
Small
Accounting
2. Agile
E-services
Low
1 – 30
LowMed
Good;
in place
3. Scrum of
Scrums
Business data
processing
Med
1 – 10
MedHigh
4. SW
embedded HW
component
Multisensor
control device
Low
0.3 – 1
5. Indivisible
IOC
Complete
vehicle
platform
Med –
High
6. NDIIntensive
Supply Chain
Management
7. Hybrid agile
/ plan-driven
system
Org, Personnel
Capability
Key Stage I Activities :
Incremental Definition
Key Stage II Activities:
Incremental Development,
Operations
Acquire NDI
Use NDI
Agile-ready
Med-high
Skip Valuation , Architecting
phases
Scrum plus agile methods of
choice
<= 1 day;
2-6 weeks
Good;
most in place
Agile-ready
Med-high
Combine Valuation,
Architecting phases. Complete
NDI preparation
Architecture-based Scrum of
Scrums
2-4 weeks;
2-6 months
MedVery
High
Good;
In place
Experienced;
med-high
Concurrent HW/SW
engineering. CDR-level ICM
DCR
IOC Development, LRIP, FRP.
Concurrent Version N+1
engineering
SW: 1-5
days;
Marketdriven
0.3 – 1
HighVery
High
Some in
place
Experienced;
med-high
Determine minimum-IOC likely,
conservative cost. Add
deferrable SW features as risk
reserve
Drop deferrable features to
meet conservative cost. Strong
award fee for features not
dropped
SW: 2-6
weeks;
Platform: 618 months
Med –
High
0.3 – 3
MedVery
High
NDI-driven
architecture
NDIexperienced;
Med-high
Thorough NDI-suite life cycle
cost-benefit analysis,
selection, concurrent
requirements/ architecture
definition
Pro-active NDI evolution
influencing, NDI upgrade
synchronization
SW: 1-4
weeks;
System: 6-18
months
C4ISR
Med –
Very
High
Mixed
parts:
1 – 10
Mixed
parts;
MedVery
High
Mixed parts
Mixed parts
Full ICM; encapsulated agile in
high change, low-medium
criticality parts (Often HMI,
external interfaces)
Full ICM ,three-team
incremental development,
concurrent V&V, nextincrement rebaselining
1-2 months;
9-18 months
8. Multi-owner
system of
systems
Net-centric
military
operations
Very
High
Mixed
parts:
1 – 10
Very
High
Many NDIs;
some in
place
Related
experience,
med-high
Full ICM; extensive multiowner team building,
negotiation
Full ICM; large ongoing
system/software engineering
effort
2-4 months;
18-24
months
9. Family of
systems
Medical
Device
Product Line
Med –
Very
High
1–3
Med –
Very
High
Some in
place
Related
experience,
med – high
Full ICM; Full stakeholder
participation in product line
scoping. Strong business case
Full ICM. Extra resources for
first system, version control,
multi-stakeholder support
1-2 months;
9-18 months
Complete
C4ISR: Command, Control, Computing, Communications, Intelligence, Surveillance, Reconnaissance. CDR: Critical Design Review.
DCR: Development
Commitment Review. FRP: Full-Rate Production. HMI: Human-Machine
Interface. HW: Hard ware.
6/27/2016
(c) USC-CSSE
IOC: Initial Operational Capability. LRIP: Low-Rate Initial Production. NDI: Non-Development Item. SW: Software
Time per
Build; per
Increment
6
Special Case I: Use NDI
• Exploration phase identifies NDI opportunities
• NDI risk/opportunity analysis indicates risks
acceptable
– Product growth envelope fits within NDI capability
– Compatible NDI and product evolution paths
– Acceptable NDI volatility
• Some open-source components highly volatile
– Acceptable usability, dependability, interoperability
– NDI available or affordable
6/27/2016
(c) USC-CSSE
7
Special Case 2: Pure Agile
• Exploration phase determines
– Low product and project size and complexity
– Fixing increment defects in next increment
acceptable
– Existing hardware and NDI support of growth
envelope
– Sufficient agile-capable personnel
– Need to accommodate rapid change, emergent
requirements, early user capability
• At least daily builds, 2-6 week delivery
increments recommended
6/27/2016
(c) USC-CSSE
8
Special Case 3: Scrum of
Scrums
• Exploration phase determines
– Need to accommodate fairly rapid change, emergent
requirements, early user capability
– Low risk of scalability up to 100 people
– NDI support of growth envelope
– Nucleus of highly agile-capable personnel
– Moderate to high loss due to increment defects
• Several teams using Scrum techniques
– Roughly 10-person teams; Scrum Master; 2-4 week,
timeboxed, increment sprints; prioritized backlog; daily
standup meetings
– Followed by daily standup meeting of teams’ Scrum Masters
6/27/2016
(c) USC-CSSE
9
Scrum of Scrums: Critical
Success Factors
• Management commitment, with incremental feasibility
checkpoints
–
–
–
–
Clear message about objectives, scope, and strategy
Involve top people from stakeholder organizations
Build in growth to expansion sites
Lead through early successes
• Thoroughly prepare the ground
– Infrastructure, policies, practices, roles, training
– Customer buy-in and expectations management
– Get help from experts
• Make clear what’s essential, optional
– Most frequently, Scrum plus organizational essentials
– Precede Development Sprints by Architecting Sprint
• Follow by Release Sprint, beta testing
– Where needed, work compliant mandate interpretations
• CMMI, ISO, SPICE, Sarbanes-Oxley
• Monitor, reflect, learn, evolve
6/27/2016
(c) USC-CSSE
10
Special Case 4: Software
Embedded Hardware Component
• Example: Multisensor Control Device
• Biggest risks: Device recall, lawsuits, production line
rework, hardware-software integration
– DCR carried to Critical Design Review level
– Concurrent hardware-software design
• Criticality makes Agile too risky
– Continuous hardware-software integration
• Initially with simulated hardware
• Low risk of overrun
– Low complexity, stable requirements and NDI
– Little need for risk reserve
• Likely single-supplier software makes daily-weekly builds
feasible
6/27/2016
(c) USC-CSSE
11
Special Case 5: Indivisible IOC
- Initial Operational Capability
• Example: Complete Vehicle Platform
• Biggest risk: Complexity, NDI uncertainties
cause cost-schedule overrun
– Similar strategies to case 4 for criticality (CDR,
concurrent HW-SW design, continuous
integration)
– Add deferrable software features as risk reserve
• Adopt conservative (90% sure) cost and schedule
• Drop software features to meet cost and schedule
• Strong award fee for features not dropped
– Likely multiple-supplier software makes longer
(multi-weekly) builds more necessary
6/27/2016
(c) USC-CSSE
12
Special Case 6: NDI-Intensive
• Example: Supply Chain Management
– NDI Enterprise Resource Planning, manufacturing, logistics,
Customer Relations Management, marketing packages
• Biggest risks: incompatible NDI; rapid change,
business/mission criticality; low NDI assessment and
integration experience; supply chain stakeholder
incompatibilities
• Key Stage I activities: thorough NDI
capability/compatibility assessment, concurrent
requirement/architecture definition, NDI shortfall
fallback plans
• Key Stage II activities: Pro-active NDI evolution
influencing, multiple-NDI upgrade synchronization
6/27/2016
(c) USC-CSSE
13
Special Case 7: Hybrid
Agile/Plan-Driven System
• Example: Command and Control (urban, military)
– Sensor processing, data fusion, situation understanding,
platform dispatching and management
• Biggest risks: large scale, high complexity, rapid
change, mixed high/low criticality, partial NDI support,
mixed personnel capability
• Key Stage I activities: extensive risk-driven
prototyping, modeling, simulation, feasibility analysis;
early development of high-risk elements; architecting
to enable concurrent agile and plan-driven
development
• Key Stage II activities: full ICM concurrent 3-team
development and next-increment rebaselining
• 1-2 Months per build; 9-18 months per major release
6/27/2016
(c) USC-CSSE
14
Special Case 8: Multi-Owner
System of Systems
• Biggest risks: all those of Case 7 plus
– Need to synchronize, integrate separately-managed,
independently-evolving systems
– Extremely large-scale; deep supplier hierarchies
– Rapid adaptation to change extremely difficult
• Key Stage I activities: scale-up of Case 7 plus
extensive teambuilding, development of integration
infrastructure and integration and test facilities
• Key Stage II activities: scale-up of Case 7 plus
multiple concurrent version control, more complex
change management
6/27/2016
(c) USC-CSSE
15
Special Case 9: Family of
Systems
• Example: Medical Device Product Line
– Common domain architecture reflecting product line element
commonalities and variabilities
• Biggest risks: Product line too broad (noncompetitive)
or too narrow (few reuse opportunities); product line
divergence; version proliferation and change
management; NDI compatibility
• Key Stage I activities: domain engineering, product
line architecting, feasibility analysis, market analysis
• Key Stage II activities: next-increment feature
prioritization; high-assurance common-component
development and certification; version control and
change management; market trend analysis
6/27/2016
(c) USC-CSSE
16
Frequently Asked Question
• Q: Having all that ICM generality and then using
the decision table to come back to a simple
model seems like an overkill.
– If my risk patterns are stable, can’t I just use the
special case indicated by the decision table?
• A: Yes, you can and should – as long as your
risk patterns stay stable. But as you encounter
change, the ICM helps you adapt to it.
– And it helps you collaborate with other organizations
that may use different special cases.
6/27/2016
(c) USC-CSSE
17
References
• Boehm, B. “Implementing Risk Management”, in B. Boehm (ed.),
Software Risk Management, IEEE CS Press, 1989, pp.433-440,
Also in R. Selby(ed.), Software Engineering: Barry W. Boehm’s
Contribution to Software Development, Management, and
Research, Wiley, 2007, pp 481-492.
• Boehm, B., and R. Turner, Balancing Agility and Discipline,
Addison Wesley, 2004
• Pew, R., and A. Mavor, Human System Integration in the System
Development Process: A New Look, National Academies Press,
2007.
• Boehm, B., and J. Lane, “Using the Incremental Commitment
Model to Integrate System Acquisition, Systems Engineering,
and Software Engineering”, USC-CSSE-TR-2207, (Short
Version in Cross Talk, October 2007, pp, 4-9)
6/27/2016
(c) USC-CSSE
18