Paper

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

Presented at the joint conference sponsored by:

National Council On Systems Engineering (NCOSE) and
American Society for Engineering Management (ASEM)

Chattanooga, TN
21–23 October 1991

also presented at:

The 12th INTERNET World Congress on Project Management

Oslo, Norway
9–11 June 1994

©1995 Center for Systems Management

©1996 CSM P0003 RelSys 9508 1

 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

©1995 Center for Systems Management

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.

©1996 CSM P0003 RelSys 9508 2

173 fhd 01 Exhibit 1—System Engineering Management Guide (1990b, Fig. 12-1) view of Technical
Reviews and the System Development 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.

©1996 CSM P0003 RelSys 9508 3

173 fhd 03

Exhibit 3—An example of system development reviews and audits, from DoD-STD-2167A (1988b), pp. 10 (Fig. 1)

the “Vee” chart developed by NASA as part of the Software

Management and Assurance Program (SMAP).
The substantial advance in visualization of the technical
aspect of the project cycle, and the role of system engineering,
is gained by understanding the comprehensive “Vee” chart
(Exhibit 6, foldout chart, “Technical Aspect of the Project
Cycle”). The shaded area on Exhibit 6 is the core of the “Vee.”
The activities shown on the core map directly onto the simpli-
fied display of the “Vee” (Exhibit 5).
The DoD Cycle
The major project reviews from Department of Defense
(DoD) MIL-STD 973 (which has replaced MIL-STD 1521B)
have been used in Exhibit 6 because they are familiar to most
contractors involved in government projects. Their use is not
limited to DoD. The Department of Energy, Department of
Transportation, NASA, and other agencies use the same or
very similar control gates. These control gates (or phase
PM 9005 2-12
transition reviews) are also applicable to commercial projects,
and have been recommended as a guideline for commercial
Exhibit 4—Boehm’s (1988b) spiral model of the
development projects which require FDA approval. Commer-
software process
cial project teams often resist the DoD process, incorrectly
believing that the Government method can’t be correct or
The “Vee” Model. In our approach, the technical aspect of the efficient.
project cycle is envisioned as a “Vee,” starting with User
needs on the upper left and ending with a User-validated Detailed discussion of the “Vee” chart
system on the upper right. Exhibit 5 provides a summary level Decomposition and Definition . The “Vee” chart provides a
overview of the cycle. On the left side of the chart, Decompo- three-dimensional view of the technical aspect of the project
sition and Definition descends as in the waterfall model. cycle. At each level, moving into the depth of the paper
However, Integration and Verification flows up and to the (perpendicular to the surface) there are a number of parallel
right as successively higher levels of assemblies, units, com- boxes illustrating that there may be many Segments or Con-
ponents, and subsystems are verified, culminating at the figuration Items (CIs)2 that make up the system at that level of
system level. This summary chart follows the basic outline of decomposition. Also at the System level, on the left of the
2
A Configuration Item (CI) requires a discrete development specification; individual design reviews; individual qualification testing
and reporting; individual Acceptance Reviews; and individual operator and maintenance manuals. A CI should be selected to
facilitate management accountability and replacement capability.

©1996 CSM P0003 RelSys 9508 4

chart, the number of parallel boxes illustrates that alternate points in the project cycle. Work should not progress beyond
concepts should be evaluated to determine the best solution a decision point until the Project Manager is ready to publish
for the User’s needs. At the System Requirements Review and control the documents containing decisions agreed to at
(SRR), the choice is approved and a single concept is baselined that point.
for further definition. Unlike the commonly held view of the waterfall method,
As project development progresses, a series of six there is no prohibition against doing detailed work early in the
baselines are established to systematically manage cohesive cycle. In fact, hardware and software feasibility models may
system development. The first is the “User Requirements be required at the very first stage (User Requirement Analysis
Baseline” established by the System Requirement Document and Agreement) in order to clarify the User Requirements
approved and put under Configuration Management prior to Statement, and to ensure that the User is not asking for an
the SRR. The second is the “Concept Baseline” established by unachievable result such as an antigravity machine. Early
the Concept Definition section of the Integrated Program application of involved technical and support disciplines is an
Summary document at the SRR. The third is the “System essential part of this process; this is in fact the implementation
Performance Baseline” (or Development Baseline) estab- of concurrent engineering (see IDA report, 1990b).
lished by the System Performance Specification at the SDR. As the project progresses, detailed analyses, risk identi-
The fourth is the “‘Design-To’ Baseline” (or Allocated fication, and risk reduction modeling continues. This is shown
Baseline) established at the series of PDRs. The fifth is the on the chart by the vertical and descending off-core activities.
“‘Build-To’ Baseline” (or preliminary Product Baseline) es- While technical feasibility decisions are made in the off-
tablished at the series of CDRs. The sixth is the “‘As-Built’ core activities only decisions at the core-level are put under
Baseline” (or Production Baseline) established at the series of Configuration Management at the various Control Gates.
Formal Qualification Reviews (FQRs). Each of the baselines Off-core activities, analyses, and models are performed to
is put under formal Configuration Management at the time substantiate the core decisions and to ensure that risks have
they are approved. been mitigated or determined to be acceptable. The off-core
The left side of the core of the “Vee” (the shaded area in work is not formally controlled, and will be repeated at the
Exhibit 6) follows the well-established waterfall model for the appropriate level to prepare justification for introduction into
project cycle. The Control Gates define significant decision the baseline definition.

127 TAPC Simple V (2)

Exhibit 5—Overview of the Technical Aspect of the Project Cycle

©1996 CSM P0003 RelSys 9508 5

 The multiple arrows descending from the bottom of the The detailed evaluation of operational feasibility, iden-
left side of the core of the “Vee” indicate that there can, and tification of driving technologies, development of software
should be, sufficient iteration downward to establish feasibil- and hardware feasibility models, and identification of system
ity and to identify and quantify risks. Upward iteration with risks must be done by or perceptively reviewed by technical
User Requirements (and levels leading to them) is permitted, experts. These tasks are the off-core activities shown in
but should be kept to a minimum unless the user is still Exhibit 6, and are key to the success of this project cycle
generating requirements. The User needs to be cautioned that concept.
changes in requirements during the development process will Note that at the fourth and fifth levels on the chart
cause positive or negative changes in the predicted cost and (Exhibit 6), the tasks break into three parallel efforts: opera-
schedule and may cause the project to be not cost or schedule tions (including manual operations), hardware, and software.
effective. The System Engineer must be sufficiently competent to direct
Often in software projects upward confirmation of solu- meaningful trades between these areas. Many system func-
tions with the User is necessary because User Requirements tions can be performed by any of the three areas, and for most
cannot be adequately defined at the start. Even for software projects the optimum choice is not obvious. Engineers some-
projects, however, iteration with User Requirements should times misapply creativity to automate functions that can easily
be stopped at PDR, or the project will not converge to an be done manually, and to create sophisticated, intellectually
acceptable solution within manageable cost or schedule bounds. satisfying designs that are hard to build or expensive to
Modification of User Requirements after PDR should be operate. Early involvement by human factors and manufactur-
held for the next model or release. If significant changes to ing specialists can avoid such design concept errors.
User Requirements must absolutely be made after PDR, then It is also essential that the system engineer address both
the project should be stopped and restarted at the start of a new test and facilities implications of the alternate concepts as part
“Vee,” reinitiating the entire process. The repeat of the pro- of the Study Period trade-off analysis process. These addi-
cess may be quicker because of the lessons learned, but all tional par-allel efforts could have been illustrated on the chart
steps must be redone. (Exhibit 6) to highlight their importance, but to reduce chart
Time and project maturity flows from left to right on the complexity, they were only implied.
Vee. Once a Control Gate is passed, iteration is not possible Test philosophy and planning are part of the Verification
backward. Iteration with User Requirements, is possible only and Validation Plans identified earlier and are developed in
vertically as illustrated on the Vee. conjunction with the system decomposition process. The
Incremental Development. If the User Requirements are too design of experiments, the design of test equipment, and the
vague to permit final definition at PDR, one approach is to development of hardware, software, and operational test pro-
develop the project in predetermined incremental releases. cedures, are all part of the oversight function of System
The first release is focused on meeting a minimum set of User Engineering that should ensure the tests will produce the
Requirements, with subsequent releases providing added func- tangible evidence necessary to prove System Verification.
tionality and performance. This is a common approach in Making sure that manufacturing producibility special-
software development. ists, and facility design engineers participate early in the
The representation of the incremental development ap- system development process is an example of concurrent
proach is easy to illustrate using the “Vee” chart. All incre- engineering. Designing the correct solution in an orderly
ments have a common heritage down to the first PDR. The process is much more cost and schedule effective than retro-
balance of the project cycle has a series of displaced and actively correcting a defective design at a later date.
overlapping “Vees,” one for each release. Role of System Engineering. The interface between System
Concurrent Engineering. If high iteration with User Re- Engineering responsibility and Design Engineering responsi-
quirements is required after the System Design Review (SDR), bility is illustrated by the rectangle on the right side of the
it is probable that the project has passed early Control Gates chart. Above the line System Engineering is responsible, and
prematurely, and it is not sufficiently defined. One cause of Design Engineering provides technical assistance. Below the
premature advance is that the appropriate technical experts line Design Engineering is responsible, and System Engineer-
were not involved at early stages, resulting in acceptance of ing performs technical audit. Note that System Engineering is
requirements and design concepts which cannot be built, influential throughout the entire project life cycle, from User
inspected, and/or maintained. System Engineering is respon- Requirements development to system decommissioning.
sible for involving key personnel (to address human factors, Technology Insertion. Projects are sometimes initiated with
safety, producibility, inspectibility, reliability, maintainabil- known technology shortfalls, or with areas for which new
ity, logistics, etc.) at each step, starting with risk analyses and technology will result in substantial product improvement.
feasibility studies in the Concept Definition phase. This does Technology development can be done in parallel with the
not require a dedicated team. However, it does require a project evolution, and inserted as late as Preliminary Design
proactive System Engineer who can ensure that appropriate Review. The technology development would be represented
expert advice and detailed assistance is applied to all areas of by a horizontal bar off the core, at the Configuration Item level
project risk. (or below), and would be managed and statused by the project
manager and System Engineer as a critical activity (Exhibit 6).
©1996 CSM P0003 RelSys 9508 6
Integration and Verification. Descending down the left side System Development Definitions. The authors would like to
of the “Vee” represents Decomposition and Definition. As- use this forum to start a movement for clarification of misused
cending the right side of the “Vee” is the process of Integra- terminology in the Technical Development process specifi-
tion and Verification. cally with regard to Technical Models. Common industry
At each level there is a direct correspondence between terms include Breadboard, Brassboard, Engineering Model,
activities on the left and right sides of the chart. This is Mock-up, Simulation, Prototype, Protoqual, etc. The layman
deliberate. The method of verification must be determined as has a difficult time deciphering these terms and experienced
the requirements are developed and documented at each level. personnel frequently misapply the referenced terms. More-
This minimizes the chances that requirements are specified in over, these terms used in contract documents can lead to
a way which cannot be measured or verified. confusion and even contract default. A more enlightened
Even at the initial and highest level, as User Require- approach would be to always use the term “model” prefaced
ments are translated into system requirements, the system by the use terminology, i.e., User Requirements Model, Tech-
verification approach must be determined that will prove that nical Feasibility Model, Physical Fit Model, Field Test Model,
the system does what it is required. The verification process Concept Demonstration Model, Test Simulation Model, Pro-
can drive cost and schedule and may in fact be a discriminator duction Demonstration Model, etc.
between alternate concepts.
References
Note the overt distinction on the right of the core be-
Boehm, B.W., “A Spiral Model of Software Development,” in
tween verification and validation. Verification is the process Tutorial: Software Engineering Project Management,
of proving that each product meets its specification (“Have we edited by R.H. Thayer, IEEE Computer Society Press,
built the system right?”). Validation is the process of demon- Washington D.C., 1988, pp. 128–142.
strating (as opposed to proving) that the product satisfies the Department of Defense, DoD STD 2167 A, “Defense System
User Needs, “regardless” of what the system specification Software Development,” 29 February 1988, pp. 10.
requires (“Have we built the right system?”). Department of Defense, DoD I 5000.2, “Defense Acquisition
Note also the parallel pattern of Test Readiness Reviews Management Policies and Procedures,” February 1991.
(TRRs) and Acceptance Reviews (ARs). For some reason the Defense Systems Management College, Systems Engineering
prevalent impression in the industry is that Test Readiness Management Guide, Jan 1990, pp. 12-2.
Reviews are only done at high system levels, and then only if Institute of Defense Analysis (IDA), Concurrent Engineer-
the customer requires them. It is the System Engineer’s ing, 1990.
responsibility to ensure that Test Readiness Reviews are Royce, Winston W., “Managing the Development of Large
performed prior to all testing and with customer participation Software Systems,” Proceedings, IEEE WESCON, Au-
whenever official sell data is to be developed by the tests. gust 1970, pp. 1–9. Reprinted in Tutorial: Software
Engineering Project Management, edited by R.H.
Process versus Sequence Thayer, IEEE Computer Society Press, Washington
System Analysis and the Design Process. The “Vee” chart D.C., 1988.
addresses the technical aspect of the project cycle and repre-
Acknowledgment
sents the sequence of project events. The system engineering
The authors want to express their appreciation for the
process (Exhibit 7) illustrates the activities the System Engi-
technical contributions and perceptive critique by their friend
neer must perform at each level of the project cycle during
and colleague, Mr. Richard Roy. Mr. Roy was a major con-
system decomposition and definition.
tributor in the development of the “Vee” chart, and to the
It is difficult to explain system engineering activities
expression of the underlying philosophy on System Engineer-
during the project life cycle without providing a clear distinc-
ing.
tion between the process and the cycle. The orthogonal model
(Exhibit 8) was developed to illustrate the relationship of the About the Authors
two, and to emphasize that the system engineering process is Kevin Forsberg. Dr. Forsberg draws on 27 years of experi-
repeated at every level of the cycle, and may be repeated many ence in Applied Research, System Engineering, Program, and
times within a phase. Proposal Management, followed by seven years of successful
System Verification and Integration Process. The system consulting to both government and industry. He received the
NASA Public Service Medal for his contributions to the Space
engineering process during integration and verification is
Shuttle program. He is one of the co-founders of the Center for
illustrated in Exhibit 9. Systems Management.
The orthogonal model (Exhibit 10) illustrates the rela- Dr. Forsberg received his B.S. in Civil Engineering at
tionship of the process and cycle during each level of integra- Massachusetts Institute of Technology and his Ph.D. in Engi-
tion and verification. neering Mechanics at Stanford University.
System Engineering Definition. As a result of the foregoing, Hal Mooz. Mr. Mooz draws on 22 years of experience in
System Engineering can now be more accurately defined as System Engineering and Program Management, followed by
the application of the System Analysis and Design Process and ten years of successful consulting to government and industry.
Mr. Mooz has won and successfully managed highly reliable,
the Integration and Verification Process to the logical se- sophisticated satellite programs from inception to operations.
quence of the Technical Aspect of the Project Cycle. He is one of the co-founders of the Center for Systems
Management.
Mr. Mooz received his M.E. in Mechanical Engineering
from Stevens Institute of Technology.
©1996 CSM P0003 RelSys 9508 7
 Technical Aspect
of the
DoD Project Cycle
(MIL-STD-1521B Compliant)

Phase 0 Phase I Phase II

Concept Exploration Demonstration & Validation Engineering & Manufacturing
& Definition Development

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.

System Concept System Concept

Document Update Document Update
Critical Concept Concept Concept System System Specification System Specification
System Issues Formulation Trades Selection Specification Update Update

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

(Continue as required) SSDD

Critical System Issues for Each Concept Identified
System/Segment Design Document • User Requirements Clarification
• Operations Feasibility
(SSDD) put under change control at SFR. • Affordability Assessment
• Environmental Analysis
Assures that the Operations, HW, & SW design • Driving Technology
concepts will satisfy all system performance • Software “Feasibility Prototyping”
specifications. • Hardware Feasibility Models
• System Risks Post PDR changes to
System Performance
Mission Specifications should
Critical Ops. & Support Task Design/Ops. Ops. Spec. be held for next
Operations & Support Issues Functions Formulation Interaction & Test Plan system upgrade
Hardware
Critical
Configuration Items Issues
CI Functional
Allocation
Design
Formulation
Des. Concept CI Spec. &
Selection Test Plan

Computer Software
Critical
Configuration Items Issues
CI Functional
Allocation
Design Des. Concept CI Spec. &
Formulation Selection Test Plan

(Continue as required)

Critical System Issues for Each

Configuration Item Identified
“Design-to” specifications put under change • User Requirements Clarification
• Operations Feasibility
control at CI PDRs. • Driving Technology
Assures that the group of CIs which meet the CI • Software “Feasibility Prototyping”
specifications will satisfy all segment specifications. • Hardware Feasibility Models
• Requirements Verification Planning
• System Risk Analyses
• Failure Modes Analyses

Mission
Critical Support Task Detailed Task Procedure
Operations & Support Issues Concept Prelim. Design & Training Definition

Hardware Critical Concept Hardware Detailed Analysis of

Assemblies Issues Selection Prelim. Design Design Design

Computer Software
Critical Concept Software
Components Issues Selection Prelim. Design
Detailed
Design
Analysis of
Design

(Continue as required) (Continue as required)

“Build-to” documentation put under change

control at CI CDR.
Assures that CIs which are built to the CI design Hardware Critical Detailed
documentation will satisfy all CI specifications. Parts & Processes Issues Design
1993 Center for Systems Management, Inc.
19046 Pruneridge Avenue, Cupertino, CA 95014, 408-255-8090 Computer Critical
127 DoD TAPC 930122 Detailed
Software Units Issues Design

Time & Maturity

Exhibit 6A—Technical Aspect of the Project Cycle

(Part 1 of 2)

©1996 CSM P0003 RelSys 9508 8

 Phase II Phase III Phase IV
Engineering & Manufacturing Production & Deployment Operations & Support
Development

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

System Verification Plan

baselined at SFR; System tests
performed after Sys TRR.

Segment Verification
“Does the verified segment
performance meet segment Integration Config. & Perf.
specifications?” & Test Verification Maintenance Segments

CI Qualification specifications baselined

at PDR; results of Qualification tests
reviewed at CI FQR.
Configuration
Item Verification
“Does the verified CI
performance meet CI
specifications?” Configuration Item
Training & Education
Configuration
Items System Engineering
Integration Qual. Config. & Maintenance Responsibility
& Test Verif. Performance
Verification
Config. &
(Design Engineering
Integration Qual. Performance Maintenance
Participation)
& Test Verif. Verification

Design Engineering
Responsibility
Configuration Item Verification (System Engineering Audit)
Plans baselined at PDR; CI
tests performed after CI TRR.

Control Gate Legend

Government Only Joint Contractor Only Milestone
Support Operational
Documents Assessment
C
Integration Config. & Perf. AR – Acceptance Review PCA – Physical Configuration Audit
& Test Verification ASR – Alternative System Review PDR – Preliminary Design Review
CDR – Critical Design Review PRR – Production Readiness Review
FCA – Functional Configuration Audit SSR – Software Specification Review
Integration Config. & Perf. FQR – Formal Qualification Review SFR – System Functional Review
& Test Verification HSR – Hardware Specification Review SRR – System Requirements Review
Baseline Nomenclature OAR – Operational Acceptance Review SVR – System Verification Review
HW Assembly and CSC Test & Integration ORR – Operational Readiness Review TRR – Test Readiness Review
plans prepared for CI CDR. CSM MIL-STD-499B
User Requirements None

Concept None Abbreviations and Acronyms

Procurement, Fabrication,
& In Process Test Functional Functional Agree. – Agreement HW – Hardware Reqmt. – Requirement
Assy. – Assembly IOC – Initial Operational Spec. – Specification
“Design-to” Allocated Config. – Configuration Capability SW – Software
Code & Unit Integration CI – Configuration Item Ops. – Operations SSS – Sys/Seg Spec.
Unit Test & Test “Build-to” None CSC – Computer Software Perf. – Performance SSDD – Sys/Seg Des. Doc.
Component Pkg. – Package Sys – System
“As-built” None Des. – Design Prelim. – Preliminary Verif. – Verification
Doc. – Document Qual. – Qualification
ime & Maturity Production Product

Exhibit 6B—Technical Aspect of the Project Cycle

(Part 2 of 2)

©1996 CSM P0003 RelSys 9508 9

 Define the
required
Higher Level behavior in a
Requirements and functional
Constraints from interaction
Approved Baseline diagram
& Candidate 3
Candidate 2
Understand the Candidate 1 Evaluate
Define the &
Concept of solutions against
Problem to be Conceive
Operations of the criteria, evaluate
solved and the candidate
Level Under risks and failure
evaluation solutions
Analysis as modes and
criteria for the
Driven by Higher Define the select the best
solutions
Level Baselines required solution
functional
performance
by quantitative
analysis

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 7—System Analysis and Design Process

154C fhd 122B

Exhibit 8—Application of the System Analysis and Design Process to the Technical Aspect of the Project Cycle

©1996 CSM P0003 RelSys 9508 10

 Verification Requirements and
Constraints from Approved Baseline Integrate with
next CI and
repeat
verification
Inspect, and test process
to verification
CI to be requirements to No
Deficiencies
verified prove readiness for
integration with
next assembly Identify and fix
Yes
correctable
deficiencies

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 9—System Verification and Integration Process

154C fhd 122C

Exhibit 10—Application of the System Verification and Integration Process to the Technical Aspect of the Project Cycle

©1996 CSM P0003 RelSys 9508 11

 Addendum #1 to

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.

©1996 CSM P0003 RelSys 9508 12