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

Cumulative Level of Understanding, Cost, Time, Product, and
Process Detail (Risk-Driven)

Concurrent
Engineering of
Products and
Processes

OPERATION 2

OPERATION

1

DEVELOPMENT

ARCHITECTING ARCHITECTING ARCHITECTING

VALUATION

STAKEHOLDER
COMMITMENT
REVIEW POINTS:
Opportunities to
proceed, skip
phases, backtrack,
or terminate

EXPLORATION

6 5 4 3 2 1

1
2
3
4

Exploration Commitment Review
Valuation Commitment Review
Architecture Commitment Review
Development Commitment Review
Operations 1 and Development 2
Commitment Review
Operations 2 and Development 3
Commitment Review

5

6

Fig. 14.4 The RD-ICM model as a spiral. Reprinted from Pew and Mavor ( 2007 ) with
permission from the National Academy of Sciences, courtesy of the National Academies Press

or 14.5 , but can be seen more clearly in Fig. 14.6 . This figure shows how the
amount of effort put into a given activity varies through the life of a system for
a hypothetical example system. Some peaks occur on some activities when their
phase is active (e.g., development), and some activities peak near the reviews
(i.e., the Evaluation, Valuation, Architecting, Construction, and Operations
Commitment Reviews). The level of activity will also vary within a phase, as
iterations are done within that phase.
4. The process explicitly takes account of risks during system development and
deployment. The level of risk is assessed at reviews between stages (shown
holistically in Fig. 14.4 and explicitly in Fig. 14.5 ). Risk is used to manage the
project—the level of effort and level of detail of work are driven by the level of
risk (Boehm 2008 provides some nice additional information and examples).
Where there is no risk to system development, there is no need for any effort to
reduce risk. For example, if the system being developed is similar to an existing
product, there may be no reason to explore further how to support users or how
to manufacture that system.