architecture for dodaf
TRANSCRIPT
© Telelogic AB
Modeling DoDAF Compliant Architectures
Operational
Syste
ms Technical
© Telelogic AB
An Architecture Development Process
© Telelogic AB
Traditional Systems EngineeringStakeholderrequirements
definition
Systemrequirements
definition
Systemrequirements
definition
Systemrequirements
definition
Architecturaldesign
Componentdevelopments
Architecturaldesign
Architecturaldesign
Integratedsystem
Integratedconfiguration
items
Componentrequirements Component
designComponentbuild & test
Components
Integration&
verification
Installation& validation Operational
systemSingle project atthe systems level
Integratedconfiguration
items
Reporting, metrics &management control
Productengineering
Productengineering
Productengineering
Reporting, metrics &management control
Reporting, metrics &management control
Deliveredsub-systems
Programengineering
Deliveredcomponents
Multiple projects
Reporting, metrics &management control
“Local” user &organizationalrequirements
“Local” user &organizationalrequirements
Proposedcharacteristics
Integration&
verification
Integration&
verification
Multiple projectsAllocatedrequirements
Proposedcharacteristics
Allocatedrequirements
Proposedcharacteristics
ProposedcharacteristicsAllocated
requirements
Deliveredsub-systems
CUSTOMER
SUPPLIERS
© Telelogic AB
Systems Engineering and Architecture based acquisition and development
requirements
Statement ofNeed
Systemrequirements
definition
Systemrequirements
definition
Architecturaldesign
Componentdevelopments
Architecturaldesign
Architecturaldesign
IntegratedSoS
IntegratedSystem
Componentrequirements Component
designComponentbuild & test
Components
Integration&
verification
Installation& validation Operational
CapabilitySingle project atthe SoS level
Integratedconfiguration
items
Reporting, metrics &management control
Productengineering
Programengineering
Productengineering
Reporting, metrics &management control
Reporting, metrics &management control
Deliveredsystems
Programengineering
Deliveredcomponents
Multiple projects
Reporting, metrics &management control
“Local” user &organizational
“Local” user &organizationalrequirements
Proposedcharacteristics
Integration&
verification
Integration&
verification
Multiple projectsAllocatedrequirements
Proposedcharacteristics
Allocatedrequirements
Proposedcharacteristics
ProposedcharacteristicsAllocated
requirements
Deliveredsub-systems
OperationalConceptCUSTOMER
SUPPLIERS
© Telelogic AB
Requirements layer
Modelling layerRequirements layer
Modelling layerRequirements layer
Modelling layerRequirements layer
Systems Engineering is a Club SandwichOur apologies to Forrest Gump!
© Telelogic AB
Functionalmodeling
Functionalmodeling
Models Bridge Layers of RequirementsTraditional Systems Engineering
Requirements layer
Modelling layer
Requirements layer
Modelling layer
Requirements layer
Modelling layer
Requirements layer
e.g Goal / Usage modeling
e.g. Functionalmodeling
Stakeholderrequirements
Architecturaldesign
Systemrequirements
Statementof need
Functionalmodelinge.g. Performance
modeling
© Telelogic AB
Functionalmodeling
Functionalmodeling
Models Bridge Layers of RequirementsDoDAF Perspective
Requirements layer
Modelling layer
Requirements layer
Modelling layer
Requirements layer
Modelling layer
Requirements layer
e.g Goal / Usage modeling
e.g. Functionalmodeling
Capabilityrequirements
SystemRequirements
ArchitecturalDesign
Statementof need
Functionalmodelinge.g. Performance
modeling
© 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
DeriveRequirements
Requirementsdocuments
Requirementsdocuments
InputRequirements
Analyze&
Model
Requirementsdocuments
Requirementsdocuments
OutputRequirements
Requirementsdocuments
Requirementsdocuments Design
© Telelogic AB
Basic Process for the Data Model Showing Traceability
DeriveRequirements
Analyze&
Model
Requirements
documentsRequirements
documents
Output
Requirements
RequirementsdocumentsRequirements
documents InputRequirements
DesigndocumentsDesigndocuments
Design
1
2
3
DesigndocumentsDesigndocumentsDesign (in layer below)
4
© 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
Status & Analysis for Managers
Bidder Responses& Score Cardsfor Assessors
Criteria Definition for Preparers
© Telelogic AB
Smooth Handoff to Engineering
Traceability
Reuse
Application
Systems Modeling
Software Design
Architecture Modeling
© Telelogic AB
Thank You
• I hope you found this both educational and enjoyable.
• All comments, questions and suggestions welcome.