Upload
incosewma
View
216
Download
0
Embed Size (px)
Citation preview
8/9/2019 Presentation from February 2002 Dinner Meeting
1/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
1
Developing a Defensible C4ISRArchitecture
Presented by Dr. Steven H. Dam and
James D. Willis, Colonel, USAF (retired)
8/9/2019 Presentation from February 2002 Dinner Meeting
2/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
2
RoadmapPart 1: Introduction
Part2: Why Systems Engineering and
Architecture Development?Part 3: Developing Your Architecture
Part 4: Packaging and Selling YourArchitecture
Part 5: Summary
8/9/2019 Presentation from February 2002 Dinner Meeting
3/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
3
Part 1: Introduction
8/9/2019 Presentation from February 2002 Dinner Meeting
4/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
4
PurposeTo provide the means to develop complete,
defensible architectures
using the C4ISR Architecture Framework and
good System Engineering processes and tools
8/9/2019 Presentation from February 2002 Dinner Meeting
5/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
5
Class GuidelinesDiscussionplus group participation
Avoid interrupting others
Ask questions as they arise
Unclassified Discussion
8/9/2019 Presentation from February 2002 Dinner Meeting
6/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
6
IntroductionsDr. Steve Dam
30+ years of software development and systemsengineering experience
Participated in the development of version 2.0 ofthe C4ISR Architecture Framework
Jim Willis
30+ years experience in the C4ISR domain as aUSAF officer and contractor
Currently provides training in systems engineeringfor NIMA and NIMA contractors
8/9/2019 Presentation from February 2002 Dinner Meeting
7/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
7
Whos Here?
Defense contractor?
Government employees?
Familiar with Systems Engineering?
Familiar with architectures?
Familiar with the C4ISR ArchitectureFramework?
8/9/2019 Presentation from February 2002 Dinner Meeting
8/109
8/9/2019 Presentation from February 2002 Dinner Meeting
9/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
9
Part2: Why Systems Engineeringand Architecture Development?
8/9/2019 Presentation from February 2002 Dinner Meeting
10/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
10
What is System Engineering?An integrated composite of people, products,and processes that provides a capability orsatisfies a stated need or objective.[DoD 5000.2]
Systems Engineering is an interdisciplinaryapproach and means to enable the realization
of successful systems. [INCOSE]
Problem-solving
In system engineering we seek to better understand
and control our environment
8/9/2019 Presentation from February 2002 Dinner Meeting
11/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
11
How Do We Go About Doing System
Engineering?Principal approach:
Decomposition
Your methodology should enable you to look at the
complete system and its behavior
Avoid oversimplification
8/9/2019 Presentation from February 2002 Dinner Meeting
12/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
12
What is an Architecture?Architecture: The structure of components,their interrelationships, and the principle
quidelines governing their design andevolution over time. [DSMC Acquisition Acronyms and Terms ]
Systems Architecture: The fundamentaland unifying system structure defined in terms
of system elements, interfaces, processes,constraints, and behaviors.
[INCOSE Systems Architecture Working Group]
8/9/2019 Presentation from February 2002 Dinner Meeting
13/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
13
How Does SE relate to C4ISR
Architecture Development?Architecture provides the broader context fora specific set of systems
System engineering methodologies apply
The main difference
Architecture study - less decomposition
System Engineering - more decomposition
Remember, one persons system is another personscomponent, is another persons architecture
8/9/2019 Presentation from February 2002 Dinner Meeting
14/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
14
What Do Architectures Do For Us?
Architectures provide a means to deal with the past,present and future
NOW NEAR TERM LONG TERM
Transition As - Is To - Be
What you have How you move now to then Your Vision
8/9/2019 Presentation from February 2002 Dinner Meeting
15/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
15
What Is the C4ISR Architecture
Framework?
So for the purposes of this seminar we will focus on
version 2.0, with highlights from draft 2.1
1996 1997 2000 20011998 1999 2002 2003
C4ISR AF V 1.0
New Standard
C4ISR AF V 2.0
Improvements DraftDoD AF V 2.1
Object-orientedmethodology
????
DoD AF V 1.0
OSD Memo
Mandatory use
8/9/2019 Presentation from February 2002 Dinner Meeting
16/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
16
Fundamental Linkages Among the
C4ISR Architecture Framework ViewsOperational
View
Identifies WarfighterRelationships and Information Needs
Systems
View
Relates Capabilities and Characteristicsto Operational Requirements
Technical
View
Prescribes Standards andConventions
Specific CapabilitiesIdentified to SatisfyInformation-ExchangeLevels and OtherOperational Requirements
Technical Criteria GoverningInteroperable Implementation/Procurement of the SelectedSystem Capabilities
ProcessingandLevelsof
Inform
ationExchange
RequirementsB
asicTechnology
Supportabilityand
NewCapabilities
Syst
emsA
ssocia
tion
s
toN
odes
,Activ
itie
s,
Nee
dlin
esand
Req
uire
men
ts
Proc
essi
ngand
Inte
r-N
odal
Lev
els
ofInf
orm
atio
n
Exc
hang
eR
equi
reme
nts
Reference: C4ISR Architecture Framework, Version 2.0
8/9/2019 Presentation from February 2002 Dinner Meeting
17/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
17
C4ISR ViewsApplicable
ArchitectureView
All Views(Context)
All Views(Terms)
General Description
Scope, purpose, intended users, environment depicted,analyticalfindings, if applicable
Definitions of all terms used in all products
ArchitectureProduct
Overview and SummaryInformation
Integrated Dictionary
ProductReference
AV-1
AV-2
Mandatory
MandatoryJoint
or
Supporting,Specific-
Purpose
Operational
Operational
Operational
Operational
Operational
Operational
Operational
Operational
Operational
High-level graphical and textual description of operational concept (high-level organizations, missions, geographic configuration, connectivity, etc.)
Command, control, coordination, other relationships among organizations
One of the three products used to describe operational activity sequence andtiming that identifies the business rules that constrain the operation
One of the three products used to describe operational activity sequence andtiming that identifies responses of a business process to events
One of the three products used to describe operational activity sequence andtiming that traces the actions in a scenario or critical sequence of events
Operationalnodes, activities performed at each node,connectivities &information flow between nodes
Information exchanged between nodes and the relevant attributes ofthat exchange such as media, quality, quantity, and the level ofinteroperability required.
Documentation of the data requirements and structural businessprocess rules of the Operational View.
High-level OperationalConcept Description
Organizational RelationshipsChart
Operational Rules Model
Operational State TransitionDescription
Operational Event/TraceDescription
Operational NodeConnectivity Description
Operational InformationExchange Matrix
Logical Data Model
OV-1
OV-4
OV-6a
OV-6b
OV-6c
OV-2
OV-3
OV-7
Mandatory
Mandatory
Mandatory
Activities, relationships among activities,inputs and outputs. In addition
overlays can show cost, performing nodes, or other pertinent information.A
ctivity ModelOV-5 M
andatory
Supporting
Supporting
Supporting
Supporting
Supporting
Systems
Systems
System InterfaceDescription
SV-1 Mandatory Identification of systems and system components and theirinterfaces, within and between nodes
Physical nodes and their related communicationslaydowns Systems CommunicationsDescri tionSV-2
Supporting
Mandatory
All Views(Capabilities)) AV-3
Capability MaturityProfile
SupportingDescription of focus areas in terms of incremental capability
levels, consistent with a standard capability maturity scale.
Reference: DoD Architecture Framework, Version 2.1 (draft)
timing that identifies the business rules that constrain the operation-
8/9/2019 Presentation from February 2002 Dinner Meeting
18/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
18
C4ISR Views (continued)
Operational
Operational
Operational
g p
One of the three products used to describe operational activity sequence andtiming that identifies responses of a business process to events
One of the three products used to describe operational activity sequence andtiming that traces the actions in a scenario or critical sequence of events
Documentation of the data requirements and structural businessprocess rules of the Operational View.
Operational State TransitionDescription
Operational Event/TraceDescription
Logical Data Model
OV-6b
OV-6c
OV-7
Supporting
Supporting
Supporting
Technical
Technical
Description of emerging standards that are expected to apply to thegiven architecture, within an appropriate set of timeframes
Extraction of standards that apply to the given architecture
Standards TechnologyForecast
TechnicalArchitectureProfile
TV-2
TV-1 Mandatory
Supporting
Planned incremental steps toward migrating a suite of systems to a moreefficient suite, or toward evolving a current system to a futureimplementation
Physical implementation of the information of the Logical DataModel, e.g., message formats, file structures, physical schema
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Functions performed by systems and the information flow amongsystem functions
Mapping of system functions back to operational activities
Detailing of data exchanges among system elements, applications andH/W allocated to system elements
Performance characteristics of each system(s) hardware and softwareelements, for the appropriate timeframe(s)
Emerging technologies and software/hardware products that are expected tobe available in a given set of timeframes, and that will affect futuredevelopment of the architecture
One of three products used to describe systems activity sequence andtiming -- Constraints that are imposed on systems functionality due tosome aspect of systems design or implementation
One of three products used to describe systems activitysequence and timing -- Responses of a system to events
One of three products used to describe systems activity sequence andtiming -- System-specific refinements of critical sequences of eventsdescribed in the operational view
System PerformanceParameters Matrix
Systems State TransitionDescription
Systems FunctionalityDescription
OperationalActivity to SystemFunction Traceability Matrix
System DataExchange Matrix
System EvolutionDescription
System TechnologyForecast
Systems Rules Model
Systems Event/TraceDescription
Physical Data Model
SV-4
SV-5
SV-6
SV-7
SV-8
SV-9
SV-10a
SV- 10b
SV -10c
SV-11
Supporting
Supporting
Supporting
Supporting
Supporting
Supporting
Supporting
Supporting
Supporting
Supporting
Systems
Systems
System InterfaceDescription
SV-1 Mandatory Identification of systems and system components and theirinterfaces, within and between nodes
Systems
Systems
Physical nodes and their related communications laydownsSystems CommunicationsDescriptionSV-2
Supporting
SV-3 Systems2Matrix Supporting
Relationships among systems in a given architecture; can be designed to show
relationships of interest, e.g., system-type interfaces, planned vs.
existing interfaces, etc.
Reference: DoD Architecture Framework, Version 2.1 (draft)
8/9/2019 Presentation from February 2002 Dinner Meeting
19/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
19
Conceptual Relationship Between
Architecture Purposes and Products
Reference: C4ISR Architecture Framework, Version 2.0
8/9/2019 Presentation from February 2002 Dinner Meeting
20/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
20
From Chapter 7. FURTHER EVOLUTION OF THE
DOD ARCHITECTURE FRAMEWORK2.1
The Framework does not advocate the use ofany one methodology/notation
[Use] whatever methodology/notation isappropriate.
In other words, the Framework products are intended to come from
the results of a complete system engineering process
8/9/2019 Presentation from February 2002 Dinner Meeting
21/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
21
How Is the C4ISR Architecture
Framework Useful to You?Provides a standard for communicating theessential elements of your architecture
Makes the case for a complete systemengineering approach, not just viewgraphengineering
8/9/2019 Presentation from February 2002 Dinner Meeting
22/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
22
Part 3: Developing Your Architecture
8/9/2019 Presentation from February 2002 Dinner Meeting
23/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
23
The Role of Methodology
Provides structure
Enables concurrent activity
The C4ISR Architecture Framework was intended to bemethodology independent, so we must select our own
methodology
8/9/2019 Presentation from February 2002 Dinner Meeting
24/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
24
A Variety of Methodologies to Choose
FromStructured Analysis with and without real-time extensions
Object-Oriented Analysis and Design
Unified Modeling Language (UML)
System/Software Requirements EngineeringMethodology (SREM/DCDS)
Zachman FrameworkAd infinitum
Make sure the methodology you choose withprovide a broad, complete foundation for analysis
and specification
8/9/2019 Presentation from February 2002 Dinner Meeting
25/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
25
Characteristics of a Good
MethodologyAddresses your full life cycle
Integrates a set of processes
Provide executable resultsUses appropriate software tools
Communicates well to all audiences
Extends ability to adjust to specific needsHas been applied successfully
8/9/2019 Presentation from February 2002 Dinner Meeting
26/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
26
The Role of ToolsTools help us keep track of the variety ofinformation
Before - paper and pencil
Today - wide variety of tools
netViz
System Architect
DOORS
CORE
ERWIN/BPWIN Rational Rose
Choose the tool that best implements the
methodology you want to use
8/9/2019 Presentation from February 2002 Dinner Meeting
27/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
27
Characteristics of a Good ToolSupports your chosen methodology
Provides several integrated functions
Employs rule-based standards
Enforces consistency
Uses an integrated, common database
Permits simulation capability
Facilitates exporting data and productsEnables flexible reconfiguration
Applies to multiple lifecycle phases
Supports multiple disciplines
8/9/2019 Presentation from February 2002 Dinner Meeting
28/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
28
The Methodology for This SeminarWe use the SREM/DCDS methodology
Why?
SREM 1969
To perform the system engineering and softwaredevelopment
Proven on major successful systems
DCDS early 1980s
Extension of SREM to distributed systems
Used extensively
Based on Entity, Relationship, Attribute diagrams,
8/9/2019 Presentation from February 2002 Dinner Meeting
29/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
29
The Tools for this SeminarCORE integrated rule-based, analysistool
netViz strong graphics with underlyingdatabase
MicrosoftOffice integrated clericalsupport
CORE provides a complete, logical language fordescribing a system or architecture
8/9/2019 Presentation from February 2002 Dinner Meeting
30/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
30
CORE LanguageEnglish
EquivalentCORE Example
Element OriginatingRequirement
Function
Component
...
Noun
Relationship OriginatingRequirementtracesto Functions
Functionsare allocatedto Components
...
Verb
Attribute Creator
CreationDate
TextDescription
...
Adjective
Attribute ofRelationship
amount ofResource consumed by Function acquire available (holdpartial) Resource for
Function
...
Adverb
Graphic Views: EFFBD, FFBD, N2, ER,
ERA, Hierarchies,IDEF0, Physical Block
Graphics/
Drawings
Structure
Copyright 1996-2000 Vitech Corporation. All rights reserved.
COREs Requirements Statement
Language
Note: CORE ReplacesEntity with Element
8/9/2019 Presentation from February 2002 Dinner Meeting
31/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
31
Entity-Relationship-Attribute (ERA)
Entity1
Attribute1.1Attribute1.2Attribute1.3
.
.
. Entity2
Attribute2.1Attribute2.2Attribute2.3
.
.
.
Relationship1-2
Attribute1-2.1Attribute1-2.2Attribute1-2.3
...
8/9/2019 Presentation from February 2002 Dinner Meeting
32/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
implemented by
OperationalArchitecture
Domain
NeedLine
Operational
Activity
OperationalInformation
built
rom
exchanges
(carries)
decomposed by
decomposed by
exits by
inputs / outputs / triggered by
captures / consumes / produces
per
orms
connected to
connected thru
implemented by
implemented by
Guidance
incorporates
traces to
AnyClass
OperationalTask
accomplishes
Mission
achieved by
composed o
OperationalElement
SystemArchitecture
Domain
Interface
Link
Function
Item
built
romjoins
joins thru
carries
decomposed by
decomposed by
inputs / outputs /
triggered by
captures/ consumes /produces
per
orms
connected to
connected thru
CompletionCriterion
Resource
implemented by
Originating
Requirement
incorporates
traces to
AnyClass
Architecture
composed o
System/Component
exits by
comprised o
Copyright 1992-2002. Vitech Corporation.
CORE 4.0 C4ISR Schema Overview
8/9/2019 Presentation from February 2002 Dinner Meeting
33/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
33
Function
Item
extended by
implements
Package
holds
Class
Extension for Java Software Definition
depends
Component
creates
Variable
JavaInterface
Method
Interface
APIcreated by
created by
made rom
created by
made rom
constructs
8/9/2019 Presentation from February 2002 Dinner Meeting
34/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
34
Extension for Relational Database
Schema Development
modi ied by
ItemOperationalInformation
leads to
Entity
Attribute
Relationship
elated rom
modi ied by
8/9/2019 Presentation from February 2002 Dinner Meeting
35/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
35
CORE
BehaviorDiagrams(EFFBDs)
Yes
No
Loop over whatever you want
Ref. OR
AND
Element 1
Element 2
AND
LPElement 3
LE
OR LP
OR Ref.
Input 1 Output 1
Trigger1
Date:
Thursday, March 30, 2000
Author:
Administrator
Number: Name:Not Applicable
Reference
Node
identifies next
function
Loop Exit
Shows
condition for
exiting loop
Multi-Exit Function
provides potential
paths from a function
(decision points)
Loop
specifies a
repeating offunctions until
loop exit
criteria is
satisfied
Trigger
special case
of
input/output
causes
function to
execute, if
enabled
Input data
flow into a
function
Output data
flow out of a
function
AND both
functions are
enabled in
parallel and
must complete
to go on
OR only one
path is
chosen,
usually by a
Trigger event
(Exclusive
OR)
Function Process/Base
Practice or
Procedure
step
8/9/2019 Presentation from February 2002 Dinner Meeting
36/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
36
Life Cycle ModelsDoD 5000.2
Another way we canvisualize the lifecycle is using the V
DSMC Systems Engineering Fundamentals
8/9/2019 Presentation from February 2002 Dinner Meeting
37/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
37
The V Model
ArchitectureDevelopment
SystemDesign
Hardware/SoftwareAcquisition
Integrationand Test
OperationalT&E andTransition
Future Operationsand Maintenance
Demolitionand Disposal
ProgramManagement
CurrentOperationsand Maintenance
8/9/2019 Presentation from February 2002 Dinner Meeting
38/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
38
How Do We Approach an
Architecture?
RequirementsAnalysis
FunctionalAnalysis andAllocation
Synthesis
SystemAnalysis and
Control
Best Use:Classical SE
Best Use:ReverseEngineering
Best Use:ArchitectureDevelopment
Adapted from EIA-632
8/9/2019 Presentation from February 2002 Dinner Meeting
39/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
39
Architecture Development Process
5. Develop the Architecture Contexts
6. Develop Operational Scenarios
1. Capture and Analyze Related Documents
4. Capture Technical Views (TV)
3. Identify Existing/Planned Systems
2. Identify Assumptions
7. Derive Operational Views (OV)
8. Derive System Views (SV)
9. Allocate OV to SV
10. Prepare Interface Diagrams
14. Provide Options
12. Perform Dynamic Analysis
11. Define Resources, Error Detection & Recovery
13. Develop Operational Demonstration Master Plan
15. Generate Operational and System Architecture Graphics, Briefings and Reports
Requirements Analysis
Functional Analysis
Synthesis
System Analysisand Control
Thisimplementationofthe middle-outapproachhasbeenprovenonavarietyofarchitecture projects
8/9/2019 Presentation from February 2002 Dinner Meeting
40/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
40
Whats Left?We have a methodology
We have a tool that implements the
methodologyWe have a process
Whats missing?
The People You
8/9/2019 Presentation from February 2002 Dinner Meeting
41/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
41
Who Should Be Part of My
Architecture Team?Need someone with vision
Need someone who can perform the detailedsystem engineering
Need someone who understands the domain
Need someone familiar with the methodologyand tools
Need someone who understands the process
Team: Pooled expertisereduces risk
8/9/2019 Presentation from February 2002 Dinner Meeting
42/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
42
Sample Problem
8/9/2019 Presentation from February 2002 Dinner Meeting
43/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
43
Problem: A New C4ISR Management
SystemThis system shall: Provide distribution of raw and processed data
from a new tactical UAV to support operationsspanning the Joint Task Force to Platoon levels
Platoons do not have to receive raw datadirectly, verbal commands are sufficient
Requested information from a platoon mustbe answered, if at all possible, within a fewminutes of the request, preferably withinseconds of most requests
Objective: Design a new C4ISR Management Systemthat enables this capability
8/9/2019 Presentation from February 2002 Dinner Meeting
44/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
44
Step 1: Capture and Analyze Related
DocumentsWhat documents would be relevant todeveloping this architecture?
What analysis can we perform?
8/9/2019 Presentation from February 2002 Dinner Meeting
45/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
45
Step 2: Identify AssumptionsWhat assumptions do we have to make in thestatement of the problem?
8/9/2019 Presentation from February 2002 Dinner Meeting
46/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
46
Step 3: Identify Existing/Planned
SystemsWhat are the kinds of other systems that mayaffect our architecture? (Keep it unclassified)
How can we find out moreabout these systems?
8/9/2019 Presentation from February 2002 Dinner Meeting
47/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
47
Step 4: Capture Technical Views (TV)What standards do we need to address here?
How do we build a TV-1?
Do we need to build a TV-2?
8/9/2019 Presentation from February 2002 Dinner Meeting
48/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
48
Step 5: Develop the Architecture
ContextsHow do we create the context for thisarchitecture?
21
8/9/2019 Presentation from February 2002 Dinner Meeting
49/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
49
Step 6: Develop Operational
ScenariosWhat scenarios should we address here?
How do we decide whichscenarios to pursue?
8/9/2019 Presentation from February 2002 Dinner Meeting
50/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
50
Step 7: Derive Operational Views
(OV)Which operational views should we develop?
Can we build them separatefrom the systems andtechnical views?
2
1
8/9/2019 Presentation from February 2002 Dinner Meeting
51/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
51
Step 8: Derive System Views (SV)Which systems views are appropriate?
21
8/9/2019 Presentation from February 2002 Dinner Meeting
52/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
52
Step 9: Allocate OV to SVHeres were the art of system engineeringcomes into play
8/9/2019 Presentation from February 2002 Dinner Meeting
53/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
53
Step 10: Prepare Interface DiagramsInterfaces fall out of the allocation
Which views describe the interfaces?
8/9/2019 Presentation from February 2002 Dinner Meeting
54/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
54
Step 11: Define Resources, Error
Detection & RecoveryNeeds to be done throughout the analysis,not wait to the last minute
8/9/2019 Presentation from February 2002 Dinner Meeting
55/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
55
Step 12: Perform Dynamic AnalysisCan be done with the operational and systemviews
Critical to ensure that your logic is executableCan be used to predictperformance when moredetailed information on
systems is available
8/9/2019 Presentation from February 2002 Dinner Meeting
56/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
56
Step 13: Develop Operational
Demonstration Master PlanA major goal of architecture development isto ensure that the architecture can be
bought offUse requirements derived fromtechnical, operational andsystem views; they specify the
functional, physical and performancerequirements
8/9/2019 Presentation from February 2002 Dinner Meeting
57/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
57
Step 14: Provide OptionsPresent the architectural options to yourcustomer let them make the decision
The options come from theunderlying trade studies
The next section will discussthis in more detail
8/9/2019 Presentation from February 2002 Dinner Meeting
58/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
58
Step 15: Graphics, Briefings and
ReportsThis step occurs throughout the process,usually in response to in-process reviews,
such as an SRR, SDR, PDR and CDRPart 4 will discuss ways topresent the information needed
8/9/2019 Presentation from February 2002 Dinner Meeting
59/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
59
Part 4: Packaging and Selling YourArchitecture
8/9/2019 Presentation from February 2002 Dinner Meeting
60/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
60
What have I been told to use?Standards (e.g. C4ISR ArchitectureFramework, Joint Technical Architecture, DII
COE, ISO9000, DoD 5000)Guidance documents and Directives (e.g.JV 2020, Defense Planning Guidance, DoDDirectives)
Capability Maturity Models (standards foryour process; e.g. SEI SW CMM; CMMI)
8/9/2019 Presentation from February 2002 Dinner Meeting
61/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
61
What might be useful to choose to
use?Other standards (not required)
System engineering tools (e.g., CORE, Slate,System Architect)
Simulation and Modeling tools (e.g., CORE,OpNet, COMNet, engagement models)
Word processing tools (e.g., MS Word)
Spreadsheets (e.g., MS Excel)Drawing tools (e.g., PowerPoint, netViz,
Adobe Illustrator)
8/9/2019 Presentation from February 2002 Dinner Meeting
62/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
62
Who is my target audience?Users
Developers
Acquisition personnelWarfighters
Recognize that you may have to tailor individualproducts for different audiences and most will
not understand any system engineering diagrams,except the OV-1
8/9/2019 Presentation from February 2002 Dinner Meeting
63/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
63
Example: EFFBD vs. PowerPoint
AND
C.1
PerformCustomerFunctions
0
Operate C4ISRManagement
System
C.2
PerformCollectorFunctions
AND
requests productsstatus
tasking data
PerformCustomerFunctions
OperateC4ISR
ManagementSystem
PerformCollectorFunctions
8/9/2019 Presentation from February 2002 Dinner Meeting
64/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
64
What questions does your target
audience ask?How does this help me understand thearchitecture better?
How does this help me make a decision?How does this help me get the best bang forthe buck?
How does this enhance National Security?
How does this get me my next promotion?
8/9/2019 Presentation from February 2002 Dinner Meeting
65/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
65
How do we put together an effective
architecture?Do the systems engineering right, thenproduce any required documentation (e.g.
C4ISR AF Views)Summarize the results in an easy to readsection, then provide detail in appendices
Provide a simple briefing that focuses on the
findings, not how you got there You will need the how you got there to back up
the findings
8/9/2019 Presentation from February 2002 Dinner Meeting
66/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
66
How can I show that elements of my
architecture provide value?One of the recent standards adopted by theGeneral Accounting Office (GAO) is BalancedScorecard*
Balanced Scorecard is an approach to providedecision makers with a way to make investmentstrategy decisions
Balanced Scorecard has three major steps:
Step 1. Define Mission and Desired Outcomes Step 2. Measure Performance Practices
Step 3. Use Performance Information
* GAO Report GAO/AIMD-
98-89, Measuring
Performance and
Demonstrating Results of
Information Technology
Investments
8/9/2019 Presentation from February 2002 Dinner Meeting
67/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
67
Balanced Scorecard ExampleEvaluation
CriteriaBaseline
Proposed Concepts/
Elements
Concept/Program Element:
Performance
Cost
Concept/Technology Maturity
Schedule for
Implementation
Key Functional
Requirements
Note thatthisscorecardisjustawaytoportraycost,schedule andperformance (andrisk) the basisforsystemsengineering
8/9/2019 Presentation from February 2002 Dinner Meeting
68/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
68
Part 5: Summary
8/9/2019 Presentation from February 2002 Dinner Meeting
69/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
69
Key DecisionsA proven methodology
A set of easy to use tools that support the
methodologyAn architecture development process
Other Factors
An achievable schedule
The right people
8/9/2019 Presentation from February 2002 Dinner Meeting
70/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
70
C4ISR Products NeededDepend on the phase that you are applyingthe Framework
These products should be a natural part ofyour methodology
Remember: Systems Engineering is your methodologyC4ISR products are your output
8/9/2019 Presentation from February 2002 Dinner Meeting
71/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
71
Questions ?????
Discussion !!!!!
8/9/2019 Presentation from February 2002 Dinner Meeting
72/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 72
8/9/2019 Presentation from February 2002 Dinner Meeting
73/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 73
Backup slides
8/9/2019 Presentation from February 2002 Dinner Meeting
74/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 74
Systems Engineering [INCOSE]
Systems Engineering is an interdisciplinary approach and meansto enable the realization of successful systems. It focuses on defining customerneeds and required functionality early in the development cycle, documentingrequirements, then proceeding with design synthesis and system validationwhile considering the complete problem:
Operations
Performance
Test
Manufacturing
Cost & Schedule
Training & Support
DisposalSystems Engineering integrates all the disciplines and specialty groups into ateam effort forming a structured development process that proceeds fromconcept to production to operation. Systems Engineering considers both thebusiness and the technical needs of all customers with the goal of providing aquality product that meets the user needs.
8/9/2019 Presentation from February 2002 Dinner Meeting
75/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 75
Architecture uses
Planning Programming
BudgetingExecution
StrategicPlanning
ProgramDefinition
BudgetingExecution
Threat
YourOrganization
ProgramDefinition$$$
Budgeting
Programs.Projects,
ActivitiesExecution
Products andServices
DefenseAgency
StrategicPlanning
8/9/2019 Presentation from February 2002 Dinner Meeting
76/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 76
DSMC Systems Engineering Fundamentals
Systems Engineering Process
8/9/2019 Presentation from February 2002 Dinner Meeting
77/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 77
DSMC Systems Engineering Fundamentals
Systems Engineering Process (simplified)
8/9/2019 Presentation from February 2002 Dinner Meeting
78/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 78
DoD Systems Engineering and the VEE
8/9/2019 Presentation from February 2002 Dinner Meeting
79/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 79
DSMC Systems Engineering Fundamentals
DoD Systems Engineering and the VEE
8/9/2019 Presentation from February 2002 Dinner Meeting
80/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 80
Architecture Context Defense Agency
Technology
DevelopmentAcquisition
Management
Information
Systems
Combat
Support
Resource
Management
Agency
Director
CommandersInChief
(CINCs)
Services
Components
JointChiefsof
Staff
(JCS)
Service
Acquistiion
Agencies
Specific
Review Committee
Congress
Secretaryof
Defense
(SECDEF)Acomplexseriesofinteractionswith
organizationsinside andoutsideCustomersOrganization
8/9/2019 Presentation from February 2002 Dinner Meeting
81/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 81
Architecture Context Tactical Unit
C4ISRManagement
System
Brigade
Company
Platoon
JTF
TUAV
Platoon
Platoon
Brigade
Company
8/9/2019 Presentation from February 2002 Dinner Meeting
82/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 82
Related Websites
8/9/2019 Presentation from February 2002 Dinner Meeting
83/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 83
Software Productivity Consortium - Sarah Sheard
Frameworks Quagmire
8/9/2019 Presentation from February 2002 Dinner Meeting
84/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 84
Essential C4ISR Products
AV-1. Text file (not provided)
AV-2. Text file (provided)
OV-1. Graphics (two provided)OV-2. Operational Elements Physical BlockDiagram (provided)
OV-3. Table in text file (provided)
SV-1. Context diagram Physical BlockDiagram (provided)
TV-1. Table in text file (provided)
8/9/2019 Presentation from February 2002 Dinner Meeting
85/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 85
Hi-level Operational Concept Graphi (OV-1) (template)
8/9/2019 Presentation from February 2002 Dinner Meeting
86/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 86
High level Operational Concept
8/9/2019 Presentation from February 2002 Dinner Meeting
87/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 87
Operational Node Connectivity (OV-2)
8/9/2019 Presentation from February 2002 Dinner Meeting
88/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 88
System Interface Description (SV-1)
2
1
Wide Area
8/9/2019 Presentation from February 2002 Dinner Meeting
89/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 89
Platoon
Tactical
UAV
Surveillance
Brigade
JTF
Enemy
Troops
Scenario 1: Tactical UAV
Controlled by JTF HQ (OV-1)
OV-1.Scenario 1
Wide Area
8/9/2019 Presentation from February 2002 Dinner Meeting
90/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 90
Platoon
Tactical
UAV
Surveillance
Brigade
JTF
Enemy
Troops
Scenario 2: Tactical UAV
Controlled by Brigade (OV-1)
OV-1.Scenario 2
8/9/2019 Presentation from February 2002 Dinner Meeting
91/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 91
OV-2. ScenarioParticipants
Tactical ic icati s
ri ade-JTF icati s
ri ade evel
erati al lem...
JTF evel ( and)
Operati nal lem...
lat n evel
Operati nal lem...
8/9/2019 Presentation from February 2002 Dinner Meeting
92/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 92
SV-1. Context Diagram
Command
ink
et
rn
ink
equest
ink
Collector
roduct
in
k
C.1
Customers
Component
C.2
Collectors
Component
Y .1
C4I
anagement
stem
System
8/9/2019 Presentation from February 2002 Dinner Meeting
93/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 93
Trace to All Products
SV-7
SV-9SV-8
OV-3SV-1
OV-6a
OV-4
OV-5 OV-2
OV-1
OV-6c
OV-6b
SV-10c
SV-4SV-2
SV-10bSV-10a
OV-7
SV-11
SV-6
SV-7
SV-5
AV-1 AV-2 TV-1
Trace to all Products
SV-3
Trace to All Systems Products
OV-6a
AV-3
DoD Architecture Framework V 2.1 (Draft)
8/9/2019 Presentation from February 2002 Dinner Meeting
94/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 94
Myths
8/9/2019 Presentation from February 2002 Dinner Meeting
95/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 95
Myth #1: The Framework is a nice tohave, but you dont really have to use it
In reality, for the C4ISR community in DoD,there is a memorandum that directs the useof the Framework for all C4ISR architecture
We see the C4ISR Architecture Framework as acritical element of the strategic direction in theDepartment, and accordingly direct that all on-going and, planned C4ISR or related architectures
be developed in accordance with Version 2.0.*.
*From a memorandum dated February 23, 1998, signed by the USDA&T, Acting ASD/C3I,and Director for C4 Systems, Joint Staff
8/9/2019 Presentation from February 2002 Dinner Meeting
96/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 96
Mandatory Use
direct all on-going or planned
C4ISR or relatedarchitectures beplanned inaccordance with
Version 2.0.
8/9/2019 Presentation from February 2002 Dinner Meeting
97/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 97
Myth #2: Only the essential products needbe created
In reality, you need to create many of thesupporting products to obtain the essentialproducts or its just viewgraph engineering.
Myth #3: The Framework provides a
8/9/2019 Presentation from February 2002 Dinner Meeting
98/109
2002 Systems and Proposal Engineering Company.All Rights Reserved. 98
Myth #3: The Framework provides amethodology for developing architectures
In reality, no detailed methodology was provided. Itprovides some guidelines and suggested processsteps in Section 3 (which is good reading formethodology developers), but there is no detailedmethodology that could evaluated using the SE-CMMor other process standard
This lack of a methodology was on purpose, to avoidforce fitting a methodology on the CINCs, Services
and Agencies. Instead it was assumed that each ofthese organizations and their support contractors hadeffective methodologies in-place
The Framework only provides a means for comparingarchitectures by means of these products.
8/9/2019 Presentation from February 2002 Dinner Meeting
99/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
99
Architecture Six Step Process
C4ISR Architecture Framework V 2.0
Myth #4: An architecture can be
8/9/2019 Presentation from February 2002 Dinner Meeting
100/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
100
Myth #4: An architecture can bedeveloped in one view only
In reality, the views are just that, views of anarchitecture and hence are not that easilyseparable
You may get away with it when trying todocument existing architectures, but itguarantees that each view will be sub-
optimizedIdeally, they should be worked onsimultaneously by the same group of people.
Myth #6: The Framework was developed
8/9/2019 Presentation from February 2002 Dinner Meeting
101/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
101
Myth #6: The Framework was developedto provide Architectures as something
different from the systems we engineer
In reality, the participants in the FrameworkPanel were all (or mostly) systems engineers.
The products are all systems engineeringproducts
The difference between systems andarchitecture engineering in usually in terms ofbreadth and depth. Architecture definitionsare usually broader and shallower thansystems, but the same techniques work forboth.
Myth #7: Using the Framework doesnt
8/9/2019 Presentation from February 2002 Dinner Meeting
102/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
102
Myth #7: Using the Framework doesn trequire the use of a database tool
In reality, when looking at the AV-2,Integrated Dictionary essential product, adatabase becomes necessary in dealing withall the data. The C4ISR Core ArchitectureData Model (CADM) provides a (complex,IDEF-based) schema for this database.However, not tool was directed, since thegroup believed that sufficient COTS toolswould do the job.
8/9/2019 Presentation from February 2002 Dinner Meeting
103/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
103
Comparison Enabler
8/9/2019 Presentation from February 2002 Dinner Meeting
104/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
104
Myth #5: The Framework provides a definitivemeans for comparing architectures
In reality, the Framework and in particular theessential products do not provide enough informationfor decision makers
No common metrics are provided for comparingperformance or cost
The architectures could actually reference different levels ofdecomposition, no hierarchy was define
These limitations were noted at the time and were
determined to be to difficult to arrive at that time.The assumption was that version 3.0 (which has yetto occur) would try to resolve these deficiencies
8/9/2019 Presentation from February 2002 Dinner Meeting
105/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
105
One Architecture Three Views
8/9/2019 Presentation from February 2002 Dinner Meeting
106/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
106
Each View Specific Products and References
8/9/2019 Presentation from February 2002 Dinner Meeting
107/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
107
Framework and the Lifecycle
Frameworkfacilitates allphases of theC4ISR lifecycle
Template of Desired Process
8/9/2019 Presentation from February 2002 Dinner Meeting
108/109
2002 Systems and Proposal Engineering Company.All Rights Reserved.
108
Template of Desired ProcessCOPYRIGHT by A. H. Levis (INCOSE Tutorial, March 2001)
Alternative approaches and tools can be used to design theC4ISR Architecture views
Alternative approaches and tools can be used to developthe executable model
Measures of Performance (MOPs) and Effectiveness(MOEs) are needed to evaluate and compare architectures
Architecture
Design
ExecutableModel
Construction
ArchitectureAnalysis and
Evaluation
D
O
M
A
I
N
C4ISR AF
Product
Generation
C4ISR AF
A hit t M th d l
8/9/2019 Presentation from February 2002 Dinner Meeting
109/109
Architecture MethodologyCOPYRIGHT by A. H. Levis (INCOSE Tutorial, March 2001)
EXE
CUTABLE
USER/ARCHITECT
INTERACTION
Technical
Arch.view
Operational
Arch.view
Systems
Arch.view
Integrated
Dictionary
USER
SPECIFIED
BEHAVIORS
ARCHITECTURE
SPECIFIED
BEHAVIORS