1. Using the Incremental Commitment Model (ICM) Process Decision Table
Barry Boehm
USC CSSE
October 2007
11/24/2018
(c) USC-CSSE

2. 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
11/24/2018
(c) USC-CSSE

3. 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 frequently-used 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
11/24/2018
(c) USC-CSSE

4. 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
11/24/2018
(c) USC-CSSE

5. 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
11/24/2018
(c) USC-CSSE

6. Common Risk-Driven Special Cases of the Incremental Commitment Model (ICM)
Example
Size, Complexity
Change Rate %
/Month
Criticality
NDI Support
Org, Personnel Capability
Key Stage I Activities : Incremental Definition
Key Stage II Activities: Incremental Development, Operations
Time per Build; per Increment
1. Use NDI
Small Accounting
Complete
Acquire NDI
Use NDI
2. Agile
E-services
Low
1 – 30
Low-Med
Good;
in place
Agile-ready
Med-high
Skip Valuation , Architecting phases
Scrum plus agile methods of choice
<= 1 day;
2-6 weeks
3. Scrum of Scrums
Business data processing
Med
1 – 10
Med-High
most in place
Combine Valuation, Architecting phases. Complete NDI preparation
Architecture-based Scrum of Scrums
2-4 weeks;
2-6 months
4. SW embedded HW component
Multisensor control device
0.3 – 1
Med-Very High
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;
Market-driven
5. Indivisible IOC
Complete vehicle platform
Med – High
High-Very High
Some in place
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: 6-18 months
6. NDI- Intensive
Supply Chain Management
0.3 – 3
Med- Very High
NDI-driven architecture
NDI-experienced;
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
7. Hybrid agile / plan-driven system
C4ISR
Med – Very High
Mixed parts:
Mixed parts; Med-Very High
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, next-increment rebaselining
1-2 months;
9-18 months
8. Multi-owner system of systems
Net-centric military operations
Very High
Many NDIs; some in place
Related experience, med-high
Full ICM; extensive multi-owner team building, negotiation
Full ICM; large ongoing system/software engineering effort
2-4 months; months
9. Family of systems
Medical Device Product Line
1 – 3
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
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.
IOC: Initial Operational Capability. LRIP: Low-Rate Initial Production. NDI: Non-Development Item. SW: Software
11/24/2018
(c) USC-CSSE

7. 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
11/24/2018
(c) USC-CSSE

8. 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
11/24/2018
(c) USC-CSSE

9. 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
11/24/2018
(c) USC-CSSE

10. 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
11/24/2018
(c) USC-CSSE

11. 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
11/24/2018
(c) USC-CSSE

12. 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
11/24/2018
(c) USC-CSSE

13. 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
11/24/2018
(c) USC-CSSE

14. 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
11/24/2018
(c) USC-CSSE

15. 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
11/24/2018
(c) USC-CSSE

16. 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
11/24/2018
(c) USC-CSSE

17. 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.
11/24/2018
(c) USC-CSSE

18. References
Boehm, B. “Implementing Risk Management”, in B. Boehm (ed.), Software Risk Management, IEEE CS Press, 1989, pp , Also in R. Selby(ed.), Software Engineering: Barry W. Boehm’s Contribution to Software Development, Management, and Research, Wiley, 2007, pp
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)
11/24/2018
(c) USC-CSSE