University of Southern California
    
Home   Contact Us    
Center for Systems and Software Engineering

About us
News
History
People
Events
Upcoming
Highlights
Past
Publication
Tech. Report
TR by Author
Research
Projects
Tools
Courses
Education
Degrees
Admissions
Affiliates
List of Affiliates
Private Area
Other Resources

Research Main Page Alphabetical Project List

Incremental Commitment Model (ICM)

Lead Personnel: Barry Boehm, Jo Ann Lane

Objectives

The Incremental Commitment Model organizes software and system engineering and acquisition processes in ways that better accommodate the different strengths and difficulties of hardware, software, and human factors engineering approaches.  It also provides points at which they can synchronize and stabilize, and at which their risks of going forward can be better assessed and fitted into a risk-driven stakeholder resource commitment process.

Imagine you are going to Las Vegas. Most software and system projects are developed like playing roulette. You put all your money in at once and hope your number comes up. That is to say, a full set of requirements is specified up front, the full set of resources is committed to an essentially fixed-price contract, and you wait to see if the bet was a good one or not. ICM is more like poker or blackjack. With the ICM, you place a smaller bet to see whether the prospects of a win are good or not, and decide whether to increase the bet based on better information (by seeing more cards) about the prospects of success.

To continue with the poker metaphor, every round of ante or betting is like an Increment. An Archor Point or Milestone is when the dealer starts a round by, say, flipping a card. Feasibility Evidence, as to the success of the project, is the card(s) that are shown. Risk management is seeing how good your hand is compared to what the others might be holding. Stakeholder Satisficing is deciding whether it's worth it to continue betting, and how much. The only place where the poker metaphor doesn't apply is that sometimes there is concurrent development, the simultaneous dealing of cards and betting within a round.

In roulette, nothing can change as soon as the wheel starts to spin. Besides not being able to change your bet, numbers don't suddenly disappear off the wheel, or new numbers start to appear. The technological world is not so static. Software platforms change all the time. Systems depend more and more on being parts of network-centric, collaboration-intensive systems of systems. An incremental model can keep up with the changes that are bound to happen in every project enviornment, due to competitors, relied-upon outside components, or the emergent requirements from each prototype.

Information

IS&SE 2007 Study for DoD/SSE Final Report

        1-IS&SE Final Report Exec Summary 123107.doc

        2-IS&SE Final Report Charts 123107.ppt

        3-IS&SE Workshop Summary Report.doc

Using the Incremental Model TR USC-CSSE-2007-715.doc

An ICM-Based Process Decision Table for IS&SE.doc

SE-Guide-for-SoS Pre Release.pdf (OSD Pre Release)

Competitive Prototyping Overview1.ppt

NDIA SW Acquisition UNIFIED outbrief 2008-04-1632.ppt

Using ICM to Help Execute CP5.ppt

ISSEwithICM-July08v6.ppt

Feasibility Evidence Developmentv9.ppt

ICM Tutorial 14 Jul 2008 v9.ppt

For more information on ICM, contact Jo Ann Lane (jolane@usc.edu) or Barry Boehm (boehm@usc.edu).