using the incremental commitment model icm process decision table n.
Download
Skip this Video
Download Presentation
Using the Incremental Commitment Model (ICM) Process Decision Table

Loading in 2 Seconds...

play fullscreen
1 / 18

Using the Incremental Commitment Model (ICM) Process Decision Table - PowerPoint PPT Presentation


  • 138 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Using the Incremental Commitment Model (ICM) Process Decision Table' - hamish-hartman


Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
using the incremental commitment model icm process decision table

Using the Incremental Commitment Model (ICM)Process Decision Table

Barry Boehm

USC CSSE

October 2007

(c) USC-CSSE

the incremental commitment life cycle process overview
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

the icm as risk driven process generator
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

the icm process decision table key decision inputs
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

the icm process decision table key decision outputs
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

common risk driven special cases of the incremental commitment model icm
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

special case i use ndi
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

special case 2 pure agile
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

special case 3 scrum of scrums
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

scrum of scrums critical success factors
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

special case 4 software embedded hardware component
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

special case 5 indivisible ioc initial operational capability
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

special case 6 ndi intensive
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

special case 7 hybrid agile plan driven system
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

special case 8 multi owner system of systems
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

special case 9 family of systems
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

frequently asked question
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

references
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