ADA557895.pdf

System of Systems Engineering
and Family of Systems Engineering
from a Standards, V-Model,
Dual V-Model, and DoD Perspective
Systems and Software Technology Conference
A il 2010
April 2010
John O. Clark
Chief Engineer
INCOSE Certified SE Professional
Information Systems Sector
Northrop Grumman Corporation
Copyright © 2010 by Northrop Grumman Corporation

Report Documentation Page
Form Approved
OMB No. 0704-0188
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it
does not display a currently valid OMB control number.
1. REPORT DATE
APR 2010 2. REPORT TYPE
3. DATES COVERED
00-00-2010 to 00-00-2010
4. TITLE AND SUBTITLE
System of Systems Engineering and Family of Systems Engineering from
a Standards, V-Model, Dual V-Model, and DoD Perspective
5a. CONTRACT NUMBER
5b. GRANT NUMBER
5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S) 5d. PROJECT NUMBER
5e. TASK NUMBER
5f. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)
Northrop Grumman Corporation,Information Systems Sector,468 Viking
Drive,Virginia Beach,VA,23452-7308
8. PERFORMING ORGANIZATION
REPORT NUMBER
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
11. SPONSOR/MONITOR’S REPORT
NUMBER(S)
12. DISTRIBUTION/AVAILABILITY STATEMENT
Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES
Presented at the 22nd Systems and Software Technology Conference (SSTC), 26-29 April 2010, Salt Lake
City, UT. Sponsored in part by the USAF. U.S. Government or Federal Rights License
14. ABSTRACT
15. SUBJECT TERMS
16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF
ABSTRACT
Same as
Report (SAR)
18. NUMBER
OF PAGES
39
19a. NAME OF
RESPONSIBLE PERSON
a. REPORT
unclassified
b. ABSTRACT
unclassified
c. THIS PAGE
unclassified
Standard Form 298 (Rev. 8-98)
Prescribed by ANSI Std Z39-18

Copyright Acknowledgement
• Based on "System of Systems Engineering and Family of Systems Engineering from a
S d d P i " b J h O Cl k hi h d i h IEEE I i l
py g g
Acknowledgement
Standards Perspective," by John O. Clark which appeared in the IEEE International
Conference on Systems Engineering, 2009. Copyright © 2009 by IEEE. Reprinted by
Permission. www.ieee.org
• Excerpts from "Systems Engineering” (EIA/IS 632) Copyright © 1994 by the
• Excerpts from Systems Engineering (EIA/IS 632), Copyright © 1994 by the
Government Electronics and Information Technology Association a Sector of the
Electronic Industries Alliance. All Rights Reserved. Reprinted by Permission.
http://geia.org
• V-Model excerpted, modified by John O. Clark (Northrop Grumman) from Forsberg,
Mooz “Proceedings of the First Annual NCOSE Conference,” 1990, and Forsberg, Mooz,
Cotterman “Visualizing Project Management,” Copyright © 2000 by John Wiley & Sons,
Inc., and used by permission of Dr Kevin Forsberg.
• Dual V-Model excerpted, modified by John O. Clark (Northrop Grumman), Copyright ©
2005 by The Center for Systems Management (CSM) Inc., and used by permission of
Dr Kevin Forsberg.
• International Council of Systems Engineering (INCOSE) Systems Engineering
Handbook, Version 3.1, August 2007, Copyright © 2007 by INCOSE, subject to the
following restrictions: INCOSE use. Permission to reproduce this document and to
prepare derivative works from this document for INCOSE use is granted, provided this
2
p p g , p
copyright notice is included with all reproductions and derivative works.
www.incose.org

Contents
• Introduction
• Systems Engineering Views
J Clark
• What is Different About SoSE and FoSE?
• Building Block
Building Block
• V-Model
• Technical Baselines, Documents, and Reviews for a System
, , y
• Simple Definitions of SoS and FoS
• INCOSE’s Definitions of System and SoS
• U.S. Department of Defense’s Definitions of SoS and FoS
• V-Model Example for a System of Systems
• Technical Baselines, Documents, and Reviews for a SoS
• Systems Thinking
3
• Conclusion
• Summary

Introduction – My Perspective
• System of Systems Engineering (SoSE) and Family of Systems
Engineering (FoSE) continue to be two of the least well-understood
SE di i li
J Clark
SE disciplines.
• Knowledge of the SE process standards, the V-Model, and
particularly the 3-dimensional Dual-V Model significantly aid this
particularly the 3 dimensional Dual V Model, significantly aid this
understanding, including the relationship between SE, SoSE, and
FoSE.
• The goals of this presentation are to:
– Define SoS, SoSE, and FoSE from an SE Standards perspective
– Describe the original V-Model and the Dual-V Model
– Show how to apply these SE Standards and V-Models to a system, to SoSs,
and to FoSs
– Encourage and challenge the participants to understand, select, tailor, and
l th SE t d d d V M d l t l S S d F S
apply these SE standards and V-Models to complex SoSs and FoSs
• Individuals may have an understanding of portions of SE, SoSE, and
FoSE based on other sources. The SE Standards, V-Model, and
4
FoSE based on other sources. The SE Standards, V Model, and
Dual-V Model provide a more complete and common understanding.

Introduction – My Perspective (cont)
• SoSE versus SE is currently debated in the literature and at
conferences such as this
J Clark
• Question: Is engineering a SoS really any different from engineering
an ordinary system?
– Some believe SoSE is “different” from SE, the SE processes are inadequate
or insufficient for SoSE, and additional processes are needed.
– Others, like me, believe the SE processes as documented in the SE
standards: IEEE 1220, EIA/IS-632, EIA-632, ISO 15288, and the guide: ISO
TR 19760, are a necessary and sufficient set of processes for SoSE, and no
additional processes are needed. Otherwise, please help us revise these
standa ds
standards.
• In my opinion (based on reading, comparing, understanding,
teaching revising tailoring and applying the SE standards):
teaching, revising, tailoring, and applying the SE standards):
– There is only one classical SE process
– There are multiple views of this one classical process
Th lti l i id h i i h i th t
5
– These multiple views provide a comprehensive view as shown in the next
chart. By understanding them, you get a comprehensive view.

Systems Engineering Views – My Perspective
DoD 5000
EIA/IS-632
1994
IEEE 1220
MIL-STD-499
Syste s g ee g e s y e spect e
SE Process
Standards
J Clark
DAU SE
Fund.
DAG
IEEE 1220
2005
EIA-632
1998
Customer
SE Docs
ISO 15288
2008
ISO TR19760
2003
DoDAF
Systems
Analysis &
Control
Process Input
Requirements
Analysis
F ti l
Requirements
Loop SE Docs
2003
ISO TR24748
2008
V-Models
Synthesis
Functional
Analysis/
Allocation
Verification
Loop
Design
Loop
COS S
CMMI
Textbooks
Corporate
Manuals
EIA-731 Process Output
INCOSE SE
Handbook Classical
Systems Engineering Process
…
Provided with the permission of EIA from EIA/IS-632-1994.
Copyright 1995 EIA All rights reserved
6
Multiple views provide a comprehensive view.
Copyright 1995 EIA. All rights reserved.

What is Different About SoSE and FoSE? – My Perspective
What is Different About SoSE and FoSE? My Perspective
• The management (e.g., acquisition) processes are inadequate,
not the technical (SE Standards) processes:
J Clark
not the technical (SE Standards) processes:
– There is no god (no overall Program Manager) of a SoS or FoS
– Acquisitions are stovepipes (single systems, not SoS or FoS)
– Systems are directed to “integrate” with other systems, often after
fielding
– Suppliers don’t cooperate with each other in FoSE (they believe it’s not in
th i b t i t t)
their best interest)
– Acquirers don’t cooperate with each other for the same reason
– FoSE costs more up-front to develop for re-use (but saves much more
later)
– Interoperability is hampered by lack of SoSE and FoSE
7

Building Block - Used in SE Standards
Building Block Used in SE Standards
J Clark
System Building Block
System
People
Products Processes
Subsystem Subsystem
8

Building Block – Used in SE Standards (cont)
Building Block Used in SE Standards (cont)
J Clark
System of Systems Building Blocks
P l
P d P
System
· ·
·
People
Products Processes
Subsystem Subsystem
System System
People
Products Processes
Subsystem Subsystem · ·
·
People
Products Processes
Subsystem Subsystem
· ·
·
People
Products Processes
System
Subsystem Subsystem
People
Products Processes
System
Subsystem Subsystem
People
Products Processes
System
Subsystem Subsystem
People
Products Processes
System
Subsystem Subsystem
9

V-Model
K Forsberg
Original V-Model (Entity V-Model)
Validation
USER
REQUIREMENTS,
SYSTEM CONCEPT,
VALIDATION PLAN
VALIDATE SYSTEM TO
USER REQUIREMENTS
Verification
SYSTEM
SPECIFICATION AND
VERIFICATION PLAN
INTEGRATE SYSTEM AND
VERIFY TO
SPECIFICATIONS
Verification
CONFIGURATION ITEM
(CI) “DESIGN -TO”
SPECIFICATIONS AND
VERIFICATION PLAN
ASSEMBLE CI’S AND
VERIFY TO
SPECIFICATIONS
Verifi-
cation
“BUILD-TO”
SPECIFICATIONS
AND VERIFICATION
PROCEDURES
INSPECT/TEST TO
“BUILD -
TO”
SPECIFICATIONS
DECOMPOSITION
AND DEFINITION
INTEGRATION AND
VERIFICATION
Notes:
= JOC Additions”
“Design-To” Spec = Requirements Spec
“Build-To” Spec = Design Spec
FABRICATE, ASSEMBLE, CODE
TRAIN
10
V-Model excerpted, modified by John Clark (Northrop Grumman), and used by permission of Kevin
Fosberg from Forsberg, Mooz “Proceedings of the First Annual NCOSE Conference,” 1990, and
Forsberg, Mooz, Cotterman “Visualizing Project Management,” ©2000 by John Wiley & Sons, Inc.
Build To Spec = Design Spec

V-Model (cont)
Dual V-Model Example Details (1 System V)
CSM
( )
1 System
2 Subsystems
4 Lowest Configuration Items
11
Dual V-Model Copyright 2005 by The Center for Systems Management (CSM) Inc.,
and used by permission of Dr Kevin Forsberg.

V-Model (cont)
Dual V-Model Example CSM
System
Dual V-Model Example
( )
System
V-Model
1 System
Entity
V M d l
1 System
2 Subsystems
V-Models
12

V-Model (cont)
Dual V-Model Example Details (1 System Entity V) CSM
( )
1 System
13

V-Model (cont)
Dual V-Model Example Details (2 Subsystem Entity Vs) CSM
( )
2 Subsystems
14

V-Model (cont)
Dual V-Model Example Details (4 Lowest Configuration Item Entity Vs)
CSM
( )
4 Lowest
Configuration
Items (LCIs)
15

V-Model (cont)
S
Dual V-Model Example Sequence
CSM
( )
System
V-Model
Start
End
1 System
2 Subsystems
Entity
V-Models
2 Subsystems
16
Dual V-Model excerpted, modified by John Clark (Northrop Grumman), and Copyright 2005 by The
Center for Systems Management (CSM) Inc., and used by permission of Dr Kevin Forsberg.

Baselines, Documents, and Reviews for a System – My Perspective
Review Types:
A R F I
PD CD TR TC FCA VR PCA
, , y y p
J Clark
FULL MENU
yp
Document Types: ORD/
ICD
S/SS
IRS
S/SS
IRS
S/SDD
SDD
HDD
IDD
DBDD
SDD
HDD
IDD
DBDD
T Plan
T Proc
T Rpt Rpt Rpt Rpt
SYSTEM
LEVEL
System
Requirements
Baseline
S t
ASR SRR SFR SPDR SCDR STRR STCR SVR SPCA
ORD/
ICD
SS
IRS
SS
IRS
SDD SDD ST Plan
ST Proc
ST Rpt Rpt
Rpt
ISR
System
requirements
allocated to
subsystems
Rqmts
flow
down:
Roll
up:
SubRR SubFR SubPDR SubCDRSubTRR SubTCR SubFCA SubPCA
ISubR
SUBSYSTEM
LEVEL
System Allocated Baseline =
Subsystem Requirements Baseline
Subsystem
requirements
allocated to
SubS SubS
IRS
SubDD SubDD SubT Plan
SubT Proc
SubT Rpt Rpt Rpt
Rqmts Roll
SubS
IRS
allocated to
Lowest
Configuration
Item (LCI)
flow
down:
SWRR SWFR SWPDR SWCDR SWTRR SWTCR SWFCA SWPCA
up:
LOWEST
CONFIGURATION
Subsystem Allocated Baseline =
LCI Requirements Baseline
17
SWRS
IRS
SWRS
IRS
SWDD
IDD
DBDD
SWDD
IDD
DBDD
SWT Plan
SWT Proc
SWT Rpt Rpt Rpt
CONFIGURATION
ITEM (LCI)
LEVEL
LCI Requirements Baseline
(e.g., Software CI Requirements Baseline)

Simple Definitions of SoS and FoS – My Perspective
Simple Definitions of SoS and FoS My Perspective
S S Th f h h l i h h f h
J Clark
• SoS: The sum of the whole is greater than the sum of the
individual parts
– The parts are integrated ( i.e., have interfaces)
– The parts may or may not be members of a common domain (such as a
product line, for example: surface ship radars)
F S Th f th h l i l t th f th i di id l
• FoS: The sum of the whole is equal to the sum of the individual
parts
– The parts are not integrated
– The parts are members of a common domain (such as a product line)
18

U.S. Department of Defense’s Definitions of SoS
Defense Acquisition Guidebook (DAG)-2006 Definition of SoSE
• Deals with planning, analyzing, organizing, and integrating the capabilities of a
U.S. Department of Defense s Definitions of SoS
Deals with planning, analyzing, organizing, and integrating the capabilities of a
mix of existing and new systems into a SoS capability greater than the sum of
the capabilities of the constituent parts.
• SoSs should be treated and managed as a system in their own right, and should
therefore be subject to the same systems engineering processes and best
practices as applied to individual systems.
• Differs from the engineering of a single system. The considerations should
include the following factors or attributes:
• Larger scope and greater complexity of integration efforts;
• Larger scope and greater complexity of integration efforts;
• Collaborative and dynamic engineering;
• Engineering under the condition of uncertainty;
• Emphasis on design optimization;
• Emphasis on design optimization;
• Continuing architectural reconfiguration;
• Simultaneous modeling and simulation of emergent System of Systems behavior; and
• Rigorous interface design and management
19
• Rigorous interface design and management.

U.S. Department of Defense’s Definitions of SoS (cont)
Systems Engineering Guide for Systems of Systems, v1.0, 2008
(References the Draft Defense Acquisition Guidebook (DAG)-2008
U.S. Department of Defense s Definitions of SoS (cont)
(not issued in 2008) for the Definition of a SoS)
• A SoS is a set or arrangement of systems that results when
independent and useful systems are integrated into a larger system that
independent and useful systems are integrated into a larger system that
delivers unique capabilities.
• Both individual systems and SoS conform to the accepted definition of a
Both individual systems and SoS conform to the accepted definition of a
system in that each consists of parts, relationships, and a whole that is
greater than the sum of the parts; however, although an SoS is a
system not all systems are SoS
system, not all systems are SoS.
• Consistent with the DoD transformation vision and enabling net-centric
operations (NCO), SoS may deliver capabilities by combining multiple
operations (NCO), SoS may deliver capabilities by combining multiple
collaborative and autonomous-yet-interacting systems.
• The mix of systems may include existing, partially developed, and yet-
20
y y g, p y p , y
to-be-designed independent systems.

(References the Draft Defense Acquisition Guidebook (DAG)-2008
(not issued in 2008) for the Definition of a SoS)
• The SE Guide to SoS identifies 3 new SoS SE “roles”:
– Translating Capability Objectives
– Understanding Systems & Relationships
– Monitoring & Assessing Changes
g g g
• My Opinion: It is unclear to me why these three SoS SE roles are really
“new.” In my opinion they are included in the 16 technical and
technical management processes defined in the DAG chapter 4, and are
included in the SE Standards, V-Model, and Dual-V Model on which the
DAG chapter 4 is based.
p
21

Interim Defense Acquisition Guidebook (DAG)-2009 Definition of SoS and SoSE
(Reference: Systems Engineering Guide for Systems of Systems, v1.0, 2008)
• A SoS is defined as a set or arrangement of systems that results from
independent systems integrated into a larger system that delivers
unique capabilities
unique capabilities.
• Both systems and SoS conform to the accepted definition of a system,
in that each consists of parts relationships and a whole that is greater
in that each consists of parts, relationships, and a whole that is greater
than the sum of its parts.
• While a SoS is a system, not all systems are SoS.
While a SoS is a system, not all systems are SoS.
• SoS engineering deals with planning, analyzing, organizing, and
integrating the capabilities of a mix of existing and new systems into an
g g p g y
SoS capability greater than the sum of the capabilities of the
constituent parts.
22
• SoS engineering is an activity that spans the entire system’s life cycle;
from pre-Milestone A through Disposal.

Interim Defense Acquisition Guidebook (DAG)-2009 Definition of SoSE
Types of Systems of Systems
(Reference: Systems Engineering Guide for Systems of Systems, v1.0, 2008)
23

U.S. Department of Defense’s Definitions of FoS
Defense Acquisition Guidebook (DAG)-2006 Definition of FoS
U.S. Department of Defense s Definitions of FoS
• Is not considered to be a system per se.
• Does not create capability beyond the additive sum of the individual
Does not create capability beyond the additive sum of the individual
capabilities of its member systems.
• Basically a grouping of systems having some common characteristic(s).
y g p g y g ( )
For example, each system in a FoS may belong to a domain or product
lines (e.g., a family of missiles or aircraft).
• Lacks the synergy of a SoS.
• Does not acquire qualitatively new properties as a result of the
i I f t th b t t b t d i t
grouping. In fact, the member systems may not be connected into a
whole.
24

Interim Defense Acquisition Guidebook (DAG)-2009 Definition of FoS
• A family of systems is a grouping of systems having some common
characteristic(s).
• For example, each system in a family of systems may belong to a
domain or product line (e.g., a family of missiles, aircraft, or situation
awareness systems)
awareness systems).
• In general, a family of systems is not considered to be a system per se
because it does not necessarily create capability beyond the additive
because it does not necessarily create capability beyond the additive
sum of the individual capabilities of its member systems.
• A family of systems lacks the synergy of a SoS.
y y y gy
• The family of systems does not acquire qualitatively new properties as a
result of the grouping. In fact, the member systems may not be
25
connected into a whole.

(References the CJCS Definition of a FoS)
• A set of systems that provide similar capabilities through different
approaches to achieve similar or complementary effects.
• For instance, the war fighter may need the capability to track moving
targets. The FoS that provides this capability could include unmanned
or manned aerial vehicles with appropriate sensors a space-based
or manned aerial vehicles with appropriate sensors, a space based
sensor platform, or a special operations capability. Each can provide the
ability to track moving targets but with differing characteristics of
persistence accuracy timeliness etc
persistence, accuracy, timeliness, etc.
26

INCOSE’s Definitions of System and SoS
INCOSE s Definitions of System and SoS
• A system is a combination of interacting elements organized to
hi t t d
achieve one or more stated purposes.
• System of systems applies to a system-of-interest whose system
elements are themselves systems; typically these entail large scale
elements are themselves systems; typically these entail large scale
inter-disciplinary problems with multiple, heterogeneous, distributed
systems.
Further simplification by myself leads to:
• System of systems applies to a system whose system elements are
System of systems applies to a system whose system elements are
themselves systems.
27
International Council of Systems Engineering (INCOSE) Systems Engineering Handbook, Version 3.1, August 2007, Copyright © 2007 by INCOSE,

V-Model Example for a System of Systems
CSM
p y y
SoS
V-Model
1 SoS
2 Systems
Entity
V-Models
y
4 Subsystems
28
Dual V-Model excerpted, modified by John Clark (Northrop Grumman), and Copyright 2005 by The Center for
Systems Management (CSM) Inc., and used by permission of Dr Kevin Forsberg.

Baselines, Documents, and Reviews for a SoS – My Perspective
R i T
A R F I
PD CD TR TC FCA VR PCA
J Clark
, , y p
FULL MENU
Review Types:
Document Types: ORD/
ICD
S/SS
IRS
S/SS
IRS
S/SDD
SDD
HDD
IDD
DBDD
SDD
HDD
IDD
DBDD
T Plan
T Proc
T Rpt Rpt Rpt Rpt
SoS
LEVEL
SoS
Requirements
Baseline
DBDD DBDD
ASoSR SoSRRSoSFR SoSPDR SoSCDR SoSTRR SoSTCR SoSVR SoSPCA
ORD/
ICD
SoSS
IRS
SoSS
IRS
SoSDD SoSDD SoST Plan
SoST Proc
SoST Rpt Rpt Rpt
ISoSR
SoS
requirements
allocated to
system
ICD IRS IRS SoST Proc
Rqmts
flow
down:
Roll
up:
SRR SFR SPDR SCDR STRR STCR SFCA SPCA
ISR
SYSTEM
LEVEL
SoS Allocated Baseline =
System Requirements Baseline
System
SRR SFR SPDR SCDR STRR STCR SFCA SPCA
SS
IRS
SS
IRS
SDD SDD ST Plan
ST Proc
ST Rpt Rpt Rpt
Rqmts Roll
ISR
SUBSYSTEM
System
requirements
allocated to
subsystem
S t All t d B li
Rqmts
flow
down:
SubRR SubFR SubPDR SubCDR SubTRR SubTCR SubFCA SubPCA
Roll
up:
29
SUBSYSTEM
LEVEL
System Allocated Baseline =
Subsystem Requirements Baseline SubRS
IRS
SubRS
IRS
SubDD
IDD
DBDD
SubDD
IDD
DBDD
SubT Plan
SubT Proc
SubT Rpt Rpt Rpt

V-Model Example for a System or SoS – My Perspective
J Clark
Incorrect V-Model
p y y p
USER
REQUIR
EMENT
S,
SYST
EM CONCEPT
,
VALIDAT
ION PL
AN
SYST
EM
SPECIFICATION AND
VERIF
ICAT
ION PLAN
CONFIGURAT
ION IT
EM
(CI) “ DESIGN - T
O ”
SPECIFIC
AT
IONS AND
ASSEMBLE CI ’ S AND
VERIF
Y T
O
SPECIFIC
AT
IONS
INT
EGRAT
E SYST
EM AND
VERIF
Y T
O
SPECIFICATIONS
VALIDAT
E SYST
EM T
O
USER REQU
IREM
ENT
S
SPECIFIC
AT
IONS AND
VERIF
ICAT
ION PLAN
“ BUILD - T
O ”
SPECIFICAT
IONS
AND VERIFICAT
ION
PROCED
URES
FABRICAT
E, A
SSEMBLE, CODE
INSPECT
/T
ESTTO
“ BUILD - T
O ”
SPECIFIC
AT
IONS
DECOMPO
SITIO
N
AND D
EFINITION
INTEGR
ATION AND
VERIF
ICATION
. . . . . . . . .
USER
REQUIREMENTS,
SYSTEM CONCEPT,
VALIDATION PLAN
SYSTEM
SPECIFICATION AND
VERIFICATION PLAN
CONFIGURATION ITEM
(CI) “DESIGN - TO”
SPECIFICATIONS AND
VERIFICATION PLAN
ASSEMBLE CI’S AND
VERIFY TO
SPECIFICATIONS
VERIFY TO
SPECIFICATIONS
VALIDATE SYSTEM TO
USER REQUIREMENTS USER
REQUIREMENTS,
SYSTEM CONCEPT,
VALIDATION PLAN
SYSTEM
SPECIFICATION AND
VERIFICATION PLAN
CONFIGURATION ITEM
(CI) “DESIGN - TO”
SPECIFICATIONS AND
ASSEMBLE CI’S AND
VERIFY TO
SPECIFICATIONS
VERIFY TO
SPECIFICATIONS
VALIDATE SYSTEM TO
USER REQUIREMENTS
“BUILD - TO”
SPECIFICATIONS
AND VERIFICATION
PROCEDURES
INSPECT/TEST TO
“BUILD - TO”
SPECIFICATIONS
DECOMPOSITION
AND DEFINITION
INTEGRATION AND
VERIFICATION
VERIFICATION PLAN
“BUILD - TO”
SPECIFICATIONS
AND VERIFICATION
PROCEDURES
INSPECT/TEST TO
“BUILD - TO”
SPECIFICATIONS
DECOMPOSITION
AND DEFINITION
INTEGRATION AND
VERIFICATION
30
V-Model excerpted, modified by John Clark (Northrop Grumman), and used by permission of Dr Kevin Forsberg from Forsberg, Mooz “Proceedings of the First Annual
NCOSE Conference,” 1990, and Forsberg, Mooz, Cotterman “Visualizing Project Management,” ©2000 by John Wiley & Sons, Inc.

V-Model Example for a FoS – My Perspective
K Forsberg
J Clark
FoS V-Model
p y p
USER
REQUIREMENTS,
VALIDATE SYSTEM TO
USER REQUIREMENTS
SYSTEM CONCEPT,
VALIDATION PLAN
SYSTEM
SPECIFICATION AND
VERIFICATION PLAN
VERIFY TO
SPECIFICATIONS
CONFIGURATION ITEM
(CI) “DESIGN -TO”
SPECIFICATIONS AND
VERIFICATION PLAN
ASSEMBLE CI
’S AND
VERIFY TO
SPECIFICATIONS
“BUILD - TO”
SPECIFICATIONS
AND VERIFICATION
PROCEDURES
INSPECT/TEST TO
“BUILD -TO”
SPECIFICATIONS
31
V-Model excerpted, modified by John Clark (Northrop Grumman), and used by permission of Dr Kevin Forsberg from Forsberg, Mooz “Proceedings of the First Annual
NCOSE Conference,” 1990, and Forsberg, Mooz, Cotterman “Visualizing Project Management,” ©2000 by John Wiley & Sons, Inc.

Systems Thinking - My Perspective
Systems Thinking My Perspective
J Clark
32
NORTHROP GRUMMAN
You Are Here.........._

Systems Thinking – My Perspective (cont)
Systems Thinking My Perspective (cont)
E thi d (f th i t th l f
J Clark
• Everything and everyone (from the universe to the nucleus of an
atom) is a system, a SoS, and a subsystem of a higher-order system
Everything and everyone that exists/existed (things people
• Everything and everyone that exists/existed (things, people,
thoughts, sayings, writings, actions, etc.) uses/used the systems
engineering process
• You see everything and everyone as a system, a SoS, a subsystem
of a higher-order system, and a member of a FoS
• You “Stand on the standards”
• You have “The Knack”
33

Conclusion – My Perspective
Conclusion My Perspective
I i i S S ll diff t f i i
J Clark
• Is engineering a SoS really any different from engineering an
ordinary system?
Some believe that SoSE is “different” from SE the SE processes are
• Some believe that SoSE is “different” from SE, the SE processes are
inadequate or insufficient for SoSE, and additional processes are
needed.
• Others, like me, believe the SE processes as documented in the SE
process standards, and as illustrated in the V-Model and Dual-V
Model are a necessary and sufficient set of processes for SoSE and
Model, are a necessary and sufficient set of processes for SoSE, and
no additional processes are needed. If you disagree, please get
involved in the SE standards working groups and help us fix them.
h d d dd l d h l h
What is needed is additional guidance on how to apply these SE
processes to SoSE.
34

Summary
y
• Introduction
J Clark
• What is Different About SoSE and FoSE?
• Building Block
Building Block
• V-Model
• Technical Baselines, Documents, and Reviews for a System
, , y
• Simple Definitions of SoS and FoS
• INCOSE’s Definitions of System and SoS
• U.S. Department of Defense’s Definitions of SoS and FoS
• V-Model Example for a System of Systems
• Technical Baselines, Documents, and Reviews for a SoS
• Systems Thinking
35
• Conclusion
• Summary

THE END!
THE END!
For More Information Contact: J Clark
John O. Clark, Chief Engineer
h G C i
Northrop Grumman Information Systems Sector
f S i i i
Defense Systems Division
Warfare Systems Engineering Department
468 Viki D i
468 Viking Drive
Virginia Beach, VA 23452-7308 USA
john.clark@ngc.com
(757) 481 1504
36
(757) 481-1504

37
NORTHROP GRUit#HAIV

J Clark
BACKUP
Not in the IEEE Paper
38

Hypotheses, Challenges, and Objectives
• Hypotheses:
– The SE Standards and V-Models describe the SE processes very well.
J Clark
– The SE Standards and V-Models contain a necessary and sufficient set of SE processes for
solving complex SE and SoSE/FoSE problems.
– Apply the SE Standards and V-Model processes that we already have to these problems,
they will work.
– The technical (SE Standards and V-Model) processes are adequate, the management (e.g.,
DoD acquisition) processes are not
• Challenges:
g
– Communicate what the SE Standards and V-Models say about the SE processes for solving
complex SE and SoSE/FoSE problems.
– Gain consensus on what the SE Standards and V-Models say.
– Convince stakeholders to read, understand, tailor, and apply the SE Standards and V-Models
Convince stakeholders to read, understand, tailor, and apply the SE Standards and V Models
to solve these problems.
– Obtain help to correct the SE Standards and V-Models if they’re inadequate.
• Objectives:
Objectives:
– Describe SE, SoSE, and FoSE from the SE Standards and V-Models perspective / view
(EIA/IS-632, IEEE 1220, EIA-632, ISO 15288, Dr Kevin Forsberg)
– Demonstrate that these SE standards and V-Models contain a complete set of SE processes
for complex SE and SoSE/FoSE problems and no additional processes are necessary
39
for complex SE and SoSE/FoSE problems, and no additional processes are necessary
– Show how to apply these SE standards and V-Models
– Promote “Systems Thinking”

ADA557895.pdf

Recommended

Recommended

More Related Content

Similar to ADA557895.pdf

Similar to ADA557895.pdf (20)

Recently uploaded

Recently uploaded (20)

ADA557895.pdf