An interesting recent whitepaper has caught my attention recently [link opens as PDF in separate window]. Professor Barry Boehm and a colleague have updated Boehm’s venerable systems-development method known as the Spiral Model. The authors label this updated method the Incremental Commitment Model (ICM).
The paper outlines an update to the model by adopting some of the latest thinking in agile development, progressive acquisition and concurrent-engineering. The result is an up-to-date iterative development method that is scalable from medium-sized software projects to the largest systems engineering programmes.
Some of the highlights of the whitepaper are listed below.
The authors identify five critical success factors of ICM as:
Identifying the key stakeholders, understanding what value they want from the system and eliciting their most important requirements – a process the author dub “stakeholder satisficing”.
Incremental commitment to the project follows incremental system definition. By this, the author means that the key stakeholders become more committed to the project once they see the system incrementally deliver functionality aligned to their value propositions.
The cyclical refinement of requirements, solutions and plans by iterative development.
Concurrent engineering, ie requirements definition (eg via prototyping) and solution provision occurring simultaneously.
Risk management – the tailoring of the method is risk-driven. Where risk is deemed high, then considerable effort is spent on elaborating the design of the solution. Where the risk of not performing this work is low, then the effort can be minimised.
The ICM is based broadly on the RUP method, with extensions for hardware aspects and the commissioning and alignment of multiple vendors.
The phases are:
Exploration: the identification of the key stakeholders, initial scoping of the system and feasibility studies;
Valuation: refinement of the system scope, tendering from vendors and vendor down-selection;
Architecting*: establishment of the architecture of the system;
Development*: development of system;
Operation*: putting the system into the operational environment.
*= These phases are iterated as appropriate to build system incrementally.
The amount of work performed in each phase depends on the amount of perceived risk: for a medium-size software development project, such as a straightforward upgrade of a commercial off-the-shelf (COTS) product, the work may pass rapidly through the initial three phases to the Development phase, perhaps by using an agile method such as XP or DSDM Atern. Conversely, a programme that aims to integrate a number of products from disparate vendors to meet demanding performance requirements from multiple stakeholders will require considerable effort in the Exploration phase.
The authors also show that the ICM can synchronise and manage risks across multiple vendors/partners in major programmes by;
selection of and feasibility studies from candidate vendors (both suppliers and strategic partners) during the Exploration and Valuation phases respectively;
(for chosen vendors) synchronisation of concurrent engineering activities by risk management and product stabilisation at key milestones in the Architecture and Development phases.
The authors finish by discussing the problems with adopting ICM, namely regulations and standards that lead to contracts that:
encourage sequential-engineering thinking over concurrent-engineering thinking;
force early and complete definition of requirements;
are slow to adapt to change.
Interestingly, these monolithic contracts are increasingly falling out of favour for large programmes.
In describing the ICM, the authors make an interesting suggestion: rather than labelling the system definition set as “requirements”, which suggests something that is contractually fixed and non-negotiable, he suggests using the terms “goals”, “objectives” or “value propositions”. In addition, he suggests using mutually-acceptable ranges of capability rather than fixed performance figures.
Experienced practitioners will be keen learn more by studying the extensive references given at the end of the paper, especially regarding:
any explicit advice on decommissioning phase – the implication in the white paper being that this is the last iteration of the Operations phase;
discussion of integration of agile and plan-driven team across a major system programme, something that is only briefly mentioned in the white paper itself.
Interestingly, the ICM approach, especially that of dovetailing Agile techniques, formalises the work Agilier has performed in delivering more rapid business benefit on our clients' programmes.
A shorter version of the whitepaper can be viewed here.
