Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software EngineeringOverview of the ICMProject Experience with ICM PrinciplesConclusionsUsing the Incremental Commitment Model to IntegrateSystem Acquisition, Systems Engineering, and SoftwareEngineeringBarry Boehm and Jo Ann LaneUniversity of Southern CaliforniaCenter for Systems and Software Engineering One of the top recommendations to emerge from the October 2006 Deputy Under Secretary of Defense (DUSD) Acquisition, Technology, and Logistics (AT&L) Defense Software Strategy Summit was to find ways of better integrating software engineering into the systems engineering and acquisition process. Concurrently, a National Research Council study was addressing the problem of better integrating human factors into the systems engineering and acquisition process. This paper presents a model that emerged from these and related efforts that shows promise of improving these integrations. This model, called the Incremental Commitment Model (ICM), organizes systems 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, andat which their risks of going forward can be better assessed and fitted into a risk-driven stakeholder resource commitment process. Introduct ionMany projects have difficulties in integrating their hardware, software, and human factors aspects. This is basically due to differences between these aspects with respect to their underlying economics, evolution patterns, product subsetability (ability to deliver usable partial initial operational capabilities), user tailorability, adaptability, underlying science, and testing considerations, as summarized in Table 1.This paper begins by summarizing trends that have caused difficulties for current systems engineering and acquisition processes (complex multi-owner systems of systems (SoS), emergentrequirements, rapid change, reused components, high assurance of qualities) and principles underlying the ICM that better address these trends (stakeholder satisficing, incremental and evolutionary growth of system definition and stakeholder commitment, iterative development, concurrent definition and development, and risk management). It then presents several complementary views of the ICM, discusses their implications with respect to acquisition and engineering practices and personnel career paths, and assesses project performance with respect to use of the principles. The principles can also be used to avoid the negative effects of common misinterpretations of other current models such as the V, spiral, and Rational Unified Process (RUP) models.1Table 1. Underlying Differences Between Hardware, Software, and Human FactorsEngineering.Difference Area Hardware Software Human FactorsMajor Life-cycle Cost SourceDevelopment, manufacturingLife-cycle evolution Training and operations laborEase of Changes Generally difficult Good within architectural frameworkVery good, but people-dependentNature of Changes Manual, labor-intensive, expensiveElectronic, inexpensive Need personnel retraining, can be expensiveUser-tailorability Generally difficult, limitedoptionsTechnically easy; mission-drivenTechnically easy; mission-drivenSubsetability Inflexible lower limit Flexible lower limit Smaller increments easier to introduceUnderlying Science Physics, chemistry, continuous mathematicsDiscrete mathematics, linguisticsBehavioral sciencesTesting By test organization; muchanalytic continuityBy test organization; little analytic continuityBy usersSummary of Difficulties and Some of Their CausesCurrent systems engineering and acquisition practices (and the associated program management personnel) still rely heavily on their historical hardware engineering and acquisition legacy. An emphasis on reducing hardware development and manufacturing costs often leads to selection of components with incompatible software infrastructures and human interfaces, leading to much higher development, operations, and maintenance costs and associated system underperformancein the software and human engineering areas. A hardware-oriented fixed-price, build-to-specification contract may deliver a hardware initial operational capability (IOC) within its development budget, but may elect not to architect or upgrade the software to avoid excessive software maintenance or human operational costs. The relative difficulty of modifying hardware installed in many places, as compared to electronicmodification of software or modification of human operational procedures, may lead to added software costs for hardware shortfall workarounds or to fitting the people to the product rather than fitting the product to the people. And the limited subsetability of hardware systems (e.g., aircraft without landing gear or complete flight controls) as compared to partial software or human interface features often leads to incompatibilities between single-increment hardware acquisition practices and multiple-increment software and human interface practices on the same project.If these hardware-software-human factors integration problems are difficult today, they will present formidable problems for the future if not adequately addressed. Some trends that will exacerbate such integration problems are - Complex, multi-owner systems of systems. Current collections of incompatible, separately-developed systems cause numerous operational deficiencies such as unacceptable delays in service, uncoordinated and conflicting plans, ineffective or dangerous decisions, and inability2to cope with fast-moving events. Multiple owners of key interdependent systems make integration of systems of systems a major challenge, but the current alternative of just trying to mash them together will only become worse in the future [1].- Emergent requirements. The most appropriate user interfaces and collaboration modes for a complex human-intensive system are not specifiable in advance, but emerge with system prototyping and usage. Forcing them to be prematurely and precisely specified generally leads to poor business or mission performance and expensive late rework and delays [2].- Rapid change. Specifying current-point-in-time snapshot requirements on a cost-competitivecontract generally leads to a big design up front, and