We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byOwen Webb
Modified over 4 years ago
© Telelogic AB Modeling DoDAF Compliant Architectures Operational Systems Technical
© Telelogic AB An Architecture Development Process
© Telelogic AB Traditional Systems Engineering
© Telelogic AB Systems Engineering and Architecture based acquisition and development CUSTOMER SUPPLIERS
© Telelogic AB Requirements layer Modelling layer Requirements layer Modelling layer Requirements layer Modelling layer Requirements layer Systems Engineering is a Club Sandwich Our apologies to Forrest Gump!
© Telelogic AB Functional modeling Functional modeling Models Bridge Layers of Requirements Traditional Systems Engineering Requirements layer Modelling layer Requirements layer Modelling layer Requirements layer Modelling layer Requirements layer e.g Goal / Usage modeling e.g. Functional modeling Stakeholder requirements Architectural design System requirements Statement of need Functional modeling e.g. Performance modeling
© Telelogic AB Functional modeling Functional modeling Models Bridge Layers of Requirements DoDAF Perspective Requirements layer Modelling layer Requirements layer Modelling layer Requirements layer Modelling layer Requirements layer e.g Goal / Usage modeling e.g. Functional modeling Capability requirements System Requirements Architectural Design Statement of need Functional modeling e.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 Derive Requirements documents Requirements documents Input Requirements Analyze & Model Requirements documents Requirements documents Output Requirements documents Requirements documents Design
© Telelogic AB Basic Process for the Data Model Showing Traceability Derive Requirements Analyze & Model Requirements documents Requirements documents Output Requirements documents Requirements documents Input Requirements Design documents Design documents Design 1 2 3 documents Design documents Design (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 Cards for 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. –Greg.Gorman@Telelogic.com
1 Service Oriented Architectures (SOA): What Users Need to Know. OGF 19: January 31, 2007 Charlotte, NC John Salasin, Ph.D, Visiting Researcher National.
Chapter 5 – Enterprise Analysis
Telelogic Lifecycle Solutions Connecting People, Process, and Tools
2009 – E. Félix Security DSL Toward model-based security engineering: developing a security analysis DSML Véronique Normand, Edith Félix, Thales Research.
Mahmut Ali GÖKÇEIndustrial Systems Engineering Lecture 2 System Identification ISE102 Spring 2007.
S Y S T E M S E N G I N E E R I N G.
Objectives Explain the purpose and various phases of the traditional systems development life cycle (SDLC) Explain when to use an adaptive approach to.
2004 by SEC Chapter 2 Software Development Process Models.
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
May 14, May 14, 2015May 14, 2015May 14, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University, Azusa,
Information System Design IT60105 Lecture 3 System Requirement Specification.
Verification “Auditability” Can Be “Free” James H. Jones Optants Documented Decision Support Company (ODDSCO)
Software Engineering General Project Management Software Requirements
Requirement Engineering – A Roadmap
® IBM Software Group © 2007 IBM Corporation Achieving Harmony IBM's Platform and Methodology for Systems Engineering and Embedded Software Development.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
The Software Product Life Cycle. Views of the Software Product Life Cycle Management Software engineering Engineering design Architectural design.
Introduction to Systems Analysis and Design
project management office(PMO)
© 2018 SlidePlayer.com Inc. All rights reserved.