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

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

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

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

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

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; 18-24 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

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

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

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

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

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

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

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

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

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

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

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

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