Académique Documents
Professionnel Documents
Culture Documents
The Relationship of
System Engineering to the Project Cycle
By
Kevin Forsberg and Harold Mooz — Co-Principals
Center for Systems Management
19046 Pruneridge Avenue, Cupertino, CA 95014
Chattanooga, TN
21–23 October 1991
Oslo, Norway
9–11 June 1994
Abstract. A new way of portraying the technical aspect of the The Project Cycle
project cycle clarifies the role and responsibility of system Current Models. The project cycle is often displayed as a
engineering to a project. This new three dimensional graphic linear sequence of activities moving along a horizontal line,
illustrates the end-to-end involvement of system engineering punctuated by major reviews (System Requirements Review,
in the project cycle, clarifies the relationship of system engi- Preliminary Design Review, Critical Design Review, etc.).
neering and design engineering, and encourages the imple- An example of this approach is found in the DSMC Systems
mentation of concurrent engineering. Engineering Management Guide (1990b) (Exhibit 1). An-
Introduction other graphic representation, developed by W. Royce (1970b),
The development cycle for projects (commercial or presents the project cycle as a series of diagonal steps verti-
government) usually starts with User needs, which are then cally spaced from upper left to lower right. Project activity
translated into a feasible set of system requirements. The flows from the top to the bottom, and the process has been
system requirements are progressively decomposed into designated the “waterfall” model (Exhibit 2).
baselines for segments, elements, etc., until the lowest level of A third representation of the project cycle (Exhibit 3) is
detail (hardware parts or software units) are specified. The contained in DoD-STD 2167A (1988b). This exhibit illus-
physical parts, assemblies, and/or software units are then trates hardware-related events in an upward path and soft-
integrated into successively higher assemblies, until the inte- ware-related events in a separate downward path, conveying
gration process is complete as evidenced by a functioning, the false conclusion that these two vital parts of the project can
validated system. be managed separately and individually, until final system
The traditional illustrations of this complex process integration.
present an incomplete portrait of the actual process, and tend All three of the above models of the project cycle share
to obscure the role of system engineering and the timely a similar deficiency: the graphics imply that work down-
participation of concurrent engineering. As a consequence, stream cannot begin until the upstream major reviews (or
many project team members reject the current models of the control gates) have been satisfied. A common interpretation is
project cycle, claiming they are unrealistic and non-applicable that software coding or hardware fabrication should not begin
to their situation. However, until now, nothing has been until after the Critical Design Review has been completed. In
offered as an acceptable alternate and considerable confusion real life there is a need to initiate software design and coding,
remains about the proper sequence of events, as well as the and hardware modeling, earlier in the project cycle to ensure
roles and responsibilities of the project technical team. that User Requirements are understood and to prove technical
In the commercial project environment, the project cycle feasibility. This need has led to the development and use of
is often not defined, even in an informal manner, and the role hardware and software feasibility models (called “prototyping”
of system engineering as a vital part of the project team is in software and breadboarding in hardware) in the earliest
frequently ignored. phases of the project cycle.
173 fhd 02
Exhibit 2—View by W. Royce (1988b, Figs 2 and 3) of the implementation steps to develop a large computer program for
delivery to a customer, with iterative interaction
The recent DoD-I-5000.2 (1991b) requires the use of A fourth view of the project cycle, developed by Boehm
“prototypes” from the start of the project, with specific relief (1988b), attempts to resolve the above deficiency by address-
from executive management required if “prototypes” are not ing the need for early feasibility modeling (“prototyping”) to
to be used. 1 The disconnect between the earlier portrayals of identify risks and define appropriate action. While Boehm’s
the project cycle that fail to provide for modeling and the spiral representation (Exhibit 4) achieves his objective, the
recent requirement for modeling has led to widespread belief system engineering role is still obscured.
that the waterfall model is wrong or not applicable.
1
The dictionary defines a “prototype” as the first thing of its kind; an original. Traditionally, hardware prototypes are built to released
drawings, under engineering surveillance, and produce an example or model for production to replicate. In aircraft design
competition, built-to-print prototypes are flown to demonstrate achieved capability. Software engineering has distorted this
definition by naming user requirements clarification models and technical feasibility models “prototypes.” For further information
see the final paragraph of this paper.
Exhibit 3—An example of system development reviews and audits, from DoD-STD-2167A (1988b), pp. 10 (Fig. 1)
User
Need
User-driven Iteration
with User Requirements Project-driven Iteration Project-driven Iteration
with User Requirements with User Requirements
User Requirement User Reqmt. User User
Analysis & Agree. Update Requirement Update Requirement Update
Operational Requirements Document (ORD)
put under change control at the User
Requirements Review.
Assures that the system which meets the clarified
user requirements will satisfy the user.
SSS
Critical Issues to be Studied
System/Segment Specification (SSS) •User Requirements Clarification
put under change control after SRR. •Operations Concepts
Assures that the system which meets the •Driving Technology
•Software “Functional
performance specification will satisfy system Requirements Prototyping”
requirements. •Hardware Constraints
Critical Functional Des. Concept Des. Concept Des. Concept Design Concept
Segments Issues Allocation Formulation Selection Documents Document Update
Computer Software
Critical
Configuration Items Issues
CI Functional
Allocation
Design Des. Concept CI Spec. &
Formulation Selection Test Plan
(Continue as required)
Mission
Critical Support Task Detailed Task Procedure
Operations & Support Issues Concept Prelim. Design & Training Definition
Computer Software
Critical Concept Software
Components Issues Selection Prelim. Design
Detailed
Design
Analysis of
Design
User
Product
System Validation
“Does the verified system Deployment Performance Operations & Phaseout
Validation Sustaining Engineering
performance meet user
requirements?” Maintenance & Upgrade
Operational Site Training
System Verification
“Does the verified system Integration Config. & Perf. Pkg. for Production
performance meet system Verification Shipment Preparation Production/Spares
& Test
specifications?” System Training System
Segment Verification
“Does the verified segment
performance meet segment Integration Config. & Perf.
specifications?” & Test Verification Maintenance Segments
Design Engineering
Responsibility
Configuration Item Verification (System Engineering Audit)
Plans baselined at PDR; CI
tests performed after CI TRR.
No
Get buyer
approval of Output is the Next Level
solution, as Solution Requirements
Yes ”Design to”
required, and and Constraints
include solution Specification from Approved
into the approved and Concept of Baseline
technical baseline Operations for
145B dwg 03 the next level
Exhibit 8—Application of the System Analysis and Design Process to the Technical Aspect of the Project Cycle
Document
uncorrectable For uncorrectable Modify
deficiencies confirm approved
deficiencies Yes
no impact to technical
integration and get baseline to
No deviation approval incorporate
Redesign from buyer deviation
145B dwg 05B
Exhibit 10—Application of the System Verification and Integration Process to the Technical Aspect of the Project Cycle
The Relationship of
System Engineering to the Project Cycle
Barry Boehm’s Spiral Process Model, as refer- This same process is illustrated in the upper left
enced in our NCOSE technical paper, The Relationship portion of the Vee Process Model. The risk addressing,
of System Engineering to the Project Cycle, is becoming User Requirements Clarification Models, Operations
very well known and is being used as a guide in system Feasibility Models, and Technical Feasibility Models
development. This explanation is provided to relate the are all illustrated in the downward, off the Vee core, risk
Spiral Process Model to CSM’s Vee Process Model management activities. Customer/user evaluation of the
which is applicable to all commonly understood devel- technical solutions is shown in the upward off-core
opment processes. activities. The progression from on-core risk identifica-
The Spiral Process Model was conceived to illus- tion, down to off-core risk analysis model development,
trate a risk driven software management process that is and then up to off-core user evaluation of recommended
based on successive risk analysis model development approaches, and back down to on-core baseline ap-
until sufficient confidence exits that the standard Water- proval, is the sidewinder representation of the Spiral
fall Process Model can be used with confidence. Process Model. A low risk project would pursue little or
The Spiral Process offers the two options: one to no off-core risk analysis activity and the project would
retain the risk analysis model if it is sufficiently valuable follow the traditional Waterfall Process Model approach
to be built upon into a more comprehensive analysis through the Decomposition and Definition Phases of the
model as in the Evolutionary Development Process; or Vee.
second, to discard the risk analysis model as too imprac- Although the Spiral Process Model incorporates
tical to build upon, and proceed with the efficient devel- technical review at each upward pass of the left horizon-
opment of a more practical, more advanced risk analysis tal axis, the illustration fails to emphasize baseline man-
model based on all the lessons learned to date and agement and configuration control that is an essential
incorporating the risk reduction decisions decided upon. discipline to good system management. The Spiral
In either case, the most significant development risk has Process Model should illustrate the establishment of the
the highest priority and should be addressed next. technical baseline and the subsequent maturation of the
One possible point of confusion with the Spiral baseline with each turn of the spiral and crossing of the
Process Model is that it is not based on a typical horizon- left horizontal axis.
tal linear time base as are most project cycles, and as a The Vee Process Model illustrates baseline man-
result may incorrectly convey the impression that the agement in that each time the customer approves the
process doesn’t take any appreciable project time. The incorporation of risk reduction results, then those results
influence of time can be shown by unraveling the spiral become baselined on the core of the Vee at the associated
and illustrating it against a horizontal time base where it control gate. Subsequent changes to the approved baseline
will appear similar to a sidewinder snake. The sidewinder require formal approval of those affected.
form will descend when pursuing risk analysis activities The Vee Process Model can also be used to under-
and models, and will ascend when demonstrating the stand and illustrate the Incremental Development Pro-
results with recommended approaches to the customer/ cess. With Incremental Development, the Vee Process
user(s) to obtain feedback and approval necessary for the Model fans into a set of displaced Vees that are offset
next descent in pursuit of the next risk analysis. starting at the level of decomposition affected by the
incorporation of the approved enhancements.