Using the Incremental Commitment Model (ICM) Process Decision Table

1. Using the Incremental Commitment Model (ICM)Process Decision Table Barry Boehm USC CSSE October 2007 (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 (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 (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 (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 (c) USC-CSSE

6. Common Risk-Driven Special Cases of the Incremental Commitment Model (ICM) 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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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. (c) USC-CSSE

18. 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) (c) USC-CSSE