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 2 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 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.
Telelogic Lifecycle Solutions Connecting People, Process, and Tools Greg Gorman Vice President, Product Management Modeling and Test Products.
EmbeddedPlus Engineering (480) Embedded Plus Engineering Innovative Comprehensive Solutions V1.0 Current.
Chapter - 5 Understanding Requirements Unit II. Introduction Definition : “The broad spectrum of tasks and techniques that lead to an understanding of.
Systems Engineering 1Version 1.0 – October 18, 2005 Systems Architecting An introduction.
IBM Rational Requirements Management Tools Achieving better control over your requirements.
1 Don Schaefer – Mission Engineering TM - a transformational business analysis and system engineering approach Challenge the Dominant Paradigm.
Workshop ESS NET ON MICRO DATA LINKING AND DATA WAREHOUSING IN STATISTICAL PRODUCTION 22 & 23 SEPTEMBER 2011 “Mapping the GSBPM on a SDW architecture”
1/23/2014 9:52 AM SOA4HL7: Defining Services based on HL7 Messaging Artifacts Alan Honey, Kaiser Permanente Enterprise Architect (Based on material initially.
How to align IT/SOA on the basis of Changing Strategies and Capabilities ? TOGAF 9 and ArchiMate 2 on a short Case Study to drive SOA (Excerpts from the.
Documenting Software Architectures These notes are my personal view of the concepts presented on Duran-Limons paper: Documenting Software Architectures:
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design.
. MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 1 1 Improving Business Analysis and Requirements Engineering. Presented by: Morris Oslin, Trissential, LLC.
Software Process Modeling with UML and SPEM Chris Armstrong Armstrong Process Group
Toward Innovative Model based Enterprise IT Outsourcing NGEBIS Workshop at CAISE 2013 Vinay Kulkarni and Sagar Sunkle.
Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides prepared by Gunter Mussbacher with material from: Sommerville & Kotonya 1998, Lethbridge.
1 Computer Systems & Architecture Lesson 3 5. Designing the Architecture.
Agent Based Software Development Michael Luck, Ronald Ashri and Mark dInverno Chapter 4: Methodologies and Modeling Languages.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Topics covered l Functional and non-functional requirements l User requirements.
Agent Based Software Development Michael Luck, Ronald Ashri and Mark dInverno.
1 Systems Engineering A Way of Thinking A Way of Doing Business Enabling Organized Transition from Need to Product August 1997 Systems Engineering Technical.
Kathy Reed June 4, 2013 IIBA Austin CBAP Study Guide for the Business Analyst Body of Knowledge (BABOK) Version 2.0.
Performance Management should include activities that ensure that goals are consistently being met in an efficient and effective manner, making best use.
Chapter:4 Principles That Guide Practice Unit II.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java L6 (Adapted For ISE 2005/6 By Ananda Amatya, University.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Software Re-use IS301 – Software.
Ch-3 Requirements Specification and Management. Introduction Good requirements are essential for executing projects. Improperly understood or documented.
ASWEC 2008Slide 1 Construction by Configuration: An opportunity for SE research Prof. Ian Sommerville St Andrews University Scotland.
Introduction NAME 24 Sep 2009 Mr. Michael Wayson Enterprise Architecture & Standards Directorate Office of the DoD Deputy Chief Information Officer (703)
COMET Approach for UML Overview Chapter 6 Designing Concurrent, Distributed, and Real-Time Applications with UML Hassan Gomaa (2001)
© 2017 SlidePlayer.com Inc. All rights reserved.