1 / 18

Using the Incremental Commitment Model (ICM) Process Decision Table

Using the Incremental Commitment Model (ICM) Process Decision Table. Barry Boehm USC CSSE October 2007. The Incremental Commitment Life Cycle Process: Overview. Stage I: Definition. Stage II: Development and Operations. Anchor Point Milestones. Synchronize, stabilize concurrency via FRs.

reyna
Download Presentation

Using the Incremental Commitment Model (ICM) Process Decision Table

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related