Summary: Putting It All Together - Foundations for Designing User-Centered Systems - page 388

what risks do you want to reduce, will the system be fast enough to use? Fast
enough to learn? Will the error rate be too high? Using risk reduction in system
design is taken up in the next section.
14.4 Risk-Driven Incremental Commitment Model
14.4.1 Introduction
There is now widespread acceptance of the fact that most systems development
follows an iterative cycle, often represented by the spiral model (Boehm and
Hansen 2001 ). It is only relatively recently, however, that human factors issues
have been explicitly incorporated into the latest version of the spiral model
(Boehm and Lane 2006 ) by the (US) Committee on Human-System Design
Support for Changing Technology (Pew and Mavor 2007 ). The revised model—the
Risk Driven Incremental Commitment Model (RD-ICM)—encourages incremen-
tal development of systems in an ongoing spiral process comprising requirements
specification, technical exploration, and stakeholder commitment. The process is
shown in Fig. 14.4 , where movement around the spiral represents time and
commitment and work on the project.
The spiral is also sometimes shown linearly, as in Fig. 14.4 , for discussion
purposes. At each stage, the system development is assessed for risks to the
system's success. The process is then targeted at reducing these risks. Where the
risks are technical (e.g., Can we build it? Can we build it for that price?), technical
work is performed to reduce the risk through increased understanding of the
technical issues and how to deal with them. Other risks can arise from historical
events, which are harder to reduce; and from financial matters, which can often be
reduced by setting up contracts at a known price.
The RD-ICM has several key features:
1. Systems should be developed through a process that considers and satisfices the
needs of stakeholders (it finds a reasonable solution that keeps in mind the costs
of finding a (better) solution). This step is addressed by the Exploration and
Valuation stages shown in Fig. 14.4 .
2. Development is incremental and performed iteratively. These related aspects
are shown in Fig. 14.4 by the multiple loops representing the increasing amount
of resources committed to design and implementation, and in Fig. 14.5 by the
five stages (Exploration, Valuation, Architecting, Development, and Opera-
tion). These stages are incremental because movement from one stage to the
next depends upon a successful review to go to the next stage.
3. Development occurs concurrently, that is, multiple steps may be performed
simultaneously—some people thus refer to this model as an Incremental
Concurrent Commitment model. One part of the system may be implemented
while another part is being tested. This is not immediately clear from Figs. 14.4