Modeling DoDAF Compliant Architectures
Operational
© Telelogic AB
An Architecture Development Process
© Telelogic AB
Traditional Systems Engineering
Stakeholder
requirements
definition
CUSTOMER
Single project at
the systems level
SUPPLIERS
Program
engineering
Product
engineering
Architectural
design
Allocated
requirements
Proposed
characteristics
Multiple projects
“Local” user &
organizational
requirements
Reporting, metrics &
management control
Proposed
characteristics
System
requirements
definition
System
requirements
definition
Architectural
design
Product
engineering
Multiple projects
“Local” user &
organizational
requirements
System
requirements
definition
Architectural
design
Allocated
requirements
Component
developments
Component
requirements
Integrated
system
Integration
&
verification
Reporting, metrics &
management control
Proposed
characteristics
Allocated
requirements
Operational
system
Installation
& validation
Delivered
sub-systems
Integration
&
verification
Integrated
configuration
items
Delivered
sub-systems
Reporting, metrics &
management control
Product
engineering
Proposed
characteristics
Component
design
Integrated
configuration
items
Integration
&
verification
Reporting, metrics &
management control
Component
build & test
Delivered
components
Components
© Telelogic AB
Systems Engineering and Architecture
based acquisition and development
Statement of
Need
Single project at
the SoS level
CUSTOMER
Program
engineering
Proposed
characteristics
Multiple projects
“Local” user &
organizational
requirements
Program
engineering
Architectural
design
Allocated
requirements
SUPPLIERS
Reporting, metrics &
management control
Proposed
characteristics
Operational
Concept
System
requirements
definition
Architectural
design
Product
engineering
Multiple projects
“Local” user &
organizational
requirements
System
requirements
definition
Architectural
design
Allocated
requirements
Component
developments
Component
requirements
Proposed
characteristics
Component
design
Delivered
systems
Integration
&
verification
Reporting, metrics &
management control
Product
engineering
Integrated
SoS
Integration
&
verification
Reporting, metrics &
management control
Proposed
characteristics
Allocated
requirements
Operational
Capability
Installation
& validation
Integration
&
verification
Reporting, metrics &
management control
Component
build & test
Integrated
System
Delivered
sub-systems
Integrated
configuration
items
Delivered
components
Components
© Telelogic AB
Systems Engineering is a Club Sandwich
Our apologies to Forrest Gump!
Requirements layer
Modelling layer
Requirements layer
Modelling layer
Requirements layer
Modelling layer
Requirements layer
© Telelogic AB
Models Bridge Layers of Requirements
Traditional Systems Engineering
Requirements layer
Statement
of need
e.g Goal / Usage
modeling
Modelling layer
Requirements layer
Stakeholder
requirements
e.g.Functional
Functional
modeling
modeling
Modelling layer
Requirements layer
System
requirements
Functional
Functional
e.g. Performance
modeling
modeling
modeling
Modelling layer
Requirements layer
Architectural
design
© Telelogic AB
Models Bridge Layers of Requirements
DoDAF Perspective
Requirements layer
Statement
of need
e.g Goal / Usage
modeling
Modelling layer
Requirements layer
Capability
requirements
e.g.Functional
Functional
modeling
modeling
Modelling layer
Requirements layer
Architectural
Design
Functional
Functional
e.g. Performance
modeling
modeling
modeling
Modelling layer
Requirements layer
System
Requirements
© Telelogic AB
The Role of Models
Models can be used to complement requirements management at each
of the different layers and are useful in a number of ways:
•Architecture modeling adds formality to the design process that lies
between each layer of requirement
•The architecture model promotes an active understanding of the details
in large requirements documents
•The design rationale gathered around the architecture model becomes
the rationale for traceability between layers of requirements
•The structure of the architecture model can be used to give structure to
the requirements document
•The architecture model is the basis for:
– costing, interoperability analysis, partitioning to different development
teams, scheduling (WBS), analysis of alternatives, early validation, and risk
management.
© Telelogic AB
Systems Modeling Techniques
•A very wide range of very domain-specific modeling techniques
may be used to aid systems design:
– Aerodynamic models using wind tunnels
– Safety, reliability and maintainability models
– Weight distribution models
– Network performance models using queuing theory
•Although many models are necessarily domain-specific, every
system has aspects which can be modeled using a basic
approach such as DoDAF.
•A basic architecture model that proves that the architecture
provides the desired capabilities (structure and behavior) should
be done prior to committing resources to more detailed
modeling and simulation.
© Telelogic AB
The Basic Systems Engineering Process
© Telelogic AB
Activities in the Systems Engineering
Process
• There are two major activities in the Basic systems engineering
process:
– To analyze the input requirements and create a model
– To derive the output requirements from the model
• These steps are applied recursively through the layers.
© Telelogic AB
Basic Process for the Data Model
Requirements
Input
Requirements
documents
Requirements
documents
Analyze
&
Model
Requirements
Requirements
documents
Design
documents
Derive
Requirements
Requirements
Output
Requirements
documents
Requirements
documents
© Telelogic AB
Basic Process for the Data Model Showing
Traceability
Requirements
Requirements
Input
documents
documents
Requirements
Analyze
&
Model
1
Design
Design
Design
documents
documents
2
4
3
Derive
Requirements
Requirements
Requirements
Output
documents
Requirements
documents
Design
Design
Design
documents
documents
(in layer below)
© Telelogic AB
Top-Level Activity Model for Developing
DoDAF Architectures
Analyze
& Model
© Telelogic AB
First Level of Decomposition of Activity
Model for Developing Architectures
© Telelogic AB
Simplified Structured Analysis Workflow
for Developing the Operational View
© Telelogic AB
Simplified Structure Analysis Workflow
for Developing the System View
(and integrating to OV)
© Telelogic AB
Simplified Workflow for Developing the
Technical Standards View
(and integrating)
© Telelogic AB
Object Oriented Workflow
•
Structure Analysis decomposes behaviour and structure separately,
then does an explicit allocation of behaviour to structure.
– Data, Behaviour and Structure are considered independently
– Activity model (OV-5) focus
•
OO Methods focus on objects (the things that possess behaviour and
structure) and does implicit allocation of behaviour to structure.
– Data, Behaviour and Structure are considered simultaneously
– Main goal is to describe re-useable objects that encapsulate behaviour
and structure.
– Lends itself to iterative development and resilient architectures.
– Event Trace (OV-6c) focus
•
The Case Study uses a blend of the two methodologies (as does
DoDAF itself).
© Telelogic AB
The Telelogic Enterprise Architect
© Telelogic AB
Telelogic Enterprise Architect - Objective
• Use integrated, best of breed tools
– Map work products to tool that best supports them
• Provide domain-specific menus and help
– Make it easy to adopt
• Leverage automation
– Reports, templates and model execution
• Model-based tool repository
– Easy model development and update with real-time checking
• Standards-based
– Proven, standard notation, executable and scalable
– Methodology Independent: OO or SADT or a combination
– Direct hand-off to systems engineering and software engineering
© Telelogic AB
Telelogic Enterprise Architect - What is it?
• A TAU G2 DoDAF profile and set of templates in DOORS to
support and simplify:
– Production of architecture descriptions
– Analysis of architecture descriptions
– Reporting
© Telelogic AB
Telelogic Enterprise Architect - Benefits
• Comprehensive support of all views and products
– Automated consistency between products
– Automatic generation of selected products (e.g. OV-3, OV-6c, SV-3, SV-5,
SV-6, SV-10c)
– Custom icons to enhance communication
– Meta-model, based on CADM, drives the tool to speak the language of the
domain
• Executable Models
– Verify behaviour and completeness early
• Integration from requirements and standards, through enterprise
architecture, to systems designs, development and acquisition
– Complete traceability easy to establish and maintain (“Link as you think”)
– Impact and gap analysis
– Same tool for System Architecture, Software Design, Software
Implementation.
© Telelogic AB
Smooth Handoff to Procurement
Criteria Definition
for Preparers
Status & Analysis
for Managers
Bidder Responses
& Score Cards
for Assessors
© Telelogic AB
Smooth Handoff to Engineering
Architecture Modeling
Reuse
Systems Modeling
Software Design
Application
Traceability
© Telelogic AB
Thank You
• I hope you found this both educational and enjoyable.
• All comments, questions and suggestions welcome.
– Greg.Gorman@Telelogic.com
© Telelogic AB