Application of mbse theory in a world of practical deadlines and deliverables lessons learned
This presentation is the property of its rightful owner.
Sponsored Links
1 / 29

Application of MBSE Theory in a World of Practical Deadlines and Deliverables: Lessons Learned PowerPoint PPT Presentation


  • 124 Views
  • Uploaded on
  • Presentation posted in: General

Application of MBSE Theory in a World of Practical Deadlines and Deliverables: Lessons Learned. March 29 th , 2014. Tamara Valinoto. Systems Architect/Model Driven Engineering (MDE) Community of Practice(CoP) Chair. [email protected]

Download Presentation

Application of MBSE Theory in a World of Practical Deadlines and Deliverables: Lessons Learned

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Application of mbse theory in a world of practical deadlines and deliverables lessons learned

Application of MBSE Theory in a World of Practical Deadlines and Deliverables: Lessons Learned

March 29th, 2014

Tamara Valinoto

Systems Architect/Model Driven Engineering (MDE) Community of Practice(CoP) Chair

[email protected]

MBSE Symposium: INCOSE Chesapeake Chapter and JHU/APL


What is model based engineering mbe mbse mdd mbi t

Support

Framework

Collaboration

MDE

MDE COP

COP

Model Based SE

Model Based I&T

Descriptive

Perf

Verification

Model Driven

Development

Analytical

Tools & Processes

Artifacts / Products

What is Model Based Engineering? MBE = MBSE + MDD + MBI&T

MBSE

MBI&T

Common MDE Framework Views

MBSW/

MBHW(MDD)

MBE includes Model-Based Systems Engineering,

Model Driven Development, and Model Based Integration and Test

2


Breakdown in the development process leveraging models design between engineering disciplines

Breakdown in the Development ProcessLeveraging Models / Design Between Engineering Disciplines

Delivered System Does Not Reflect the System Design

  • Process Chain Breaks Down Between Disciplines

    • No Standard Translations Between Model Languages

    • Models and Requirements are not Consistent or Traceable

    • No Process or Translation for Feedback into the System Architecture

      • Systems / Software Architectures Might Not Have Valid Implementations

System

Architecture

Model(s)

Software

Architecture

Model(s)

Software

Implementation

Model(s)

Similar Corollary For

Hardware Design


Application of mbse theory in a world of practical deadlines and deliverables lessons learned

How MBE/MBE Should Work Across DisciplinesUsing Models to Effectively Communicate and Implement System

  • Consistent Models Shared Between Disciplines

    • Standard Transformations Between Models, Both To and From

    • Feedback so System Designs Have Valid Implementations

      • Constructs in Systems Models Map to Valid Implementations

      • Implementations Set Standard Rules to Guide Systems Architecture

    • Enable Communications Between Disciplines and Customer

  • ‘As Designed’ and ‘As Built’ are one in the same

System

Architecture

Model(s)

Software

Architecture

Model(s)

Software

Implementation

Model(s)


An integrated system model is a multi faceted approach to provide solutions

An Integrated System Model is a Multi-Faceted Approach to Provide Solutions

  • Model is a central repository for all knowledge about the system

    • Aiding communication and collaboration

  • Automatically self-consistent system architecture and design

    • Improving maintainability and reducing ambiguity of design

  • Automate traceability of requirements to architecture elements

    • Aiding analysis of change Impact(s)

  • Automate ability to generate formal documentation from model

    • Ensuring documents reflect what was designed

  • Automatic Code Synchronizer (ACS) to generate code from UML designs

    • Design, Develop, and Implement high quality code in less time


Lesson s learned obtain chief systems engineer backing in effort

Lesson(s) Learned: Obtain Chief Systems Engineer Backing in Effort

  • Question(s):

  • Architecture Team: How do we get the Chief Systems Engineer to be an advocate for the team’s MBE effort?

  • Lesson(s):

  • Relationship:

    • Build a bond and present together on current state of architecture(i.e. pretty picture and modeling data)

    • Determine the responsibilities of the person who owns the content and its accuracy

  • Get Early Buy in from Program Management, Engineering Manager


Lesson s learned everyone makes pretty pictures but enforce data comes from model

Lesson(s) Learned: Everyone Makes Pretty Pictures BUT Enforce Data Comes from Model

  • Question(s):

  • Architecture Team: How do I ensure the whole program team uses the model as “ground truth” when making their presentation material?

  • Customer: What is “ground truth” of architecture?

  • Lesson(s):

  • Presentation Packages:

    • Determine Process for “how” people request data from model or have them as read only users to grab periodic data from model to build presentations

    • Ensure your team is on the presentation review board

    • Present process to customer


Lesson s learned showcase how to navigate model database

Lesson(s) Learned: Showcase “how” to Navigate Model Database

  • Question(s):

  • Architecture Team: How do I navigate the model element relationships behind the views/viewpoints?

  • Customer: How do I find the latest set of views/viewpoints that were reviewed in the last meeting?

  • Lesson(s):

  • Model:

    • Create HTML exports of views and/or Create Text Diagrams containing hyperlinks to views within model

  • Training:

    • Bring in Tool Vendor to showcase the various browser panes if they exist


Lesson s learned map views viewpoints to system decomposition

Lesson(s) Learned: Map Views/Viewpoints to System Decomposition

  • Question(s):

  • Architecture Team: What is the scope for each architecture level (i.e. boundaries of my system, segment, element)? How to divide the work among the distributed team? What are the modeling languages applied at each level and are they required (i.e. UPDM for SoS, System; SysML for Segment/Element; UML for Subsystem)? How far will we model the system?

  • Customer: What views/viewpoints will be delivered at each milestone?

  • Lesson(s):

  • Training:

    • Modeling languages

  • Schedule:

    • Products Aligned to Milestones ( i.e. CDRLs)

  • Milestone Reviews:

    • Present Product Traceability from Requirements


What are the architecture products to develop at each architecture level for each milestone

What are the Architecture Products to Develop at Each Architecture level for each Milestone?

SRR

SV-1 (L0)

OV-2

OV-1d

System of Systems

System

External Nodes

SV-4a (L0)

SV-5

OV-5

PDR

SV-2 (L1)

SV-6

SV-1 (L1)

Segments

Air

Ground

SV-11

SV-10c

SV-4a (L1)

CDR

Elements

IBD

Behavior Diagrams

Comms

Payload 1

Payload 2

BDD

Data Model

Unified Profile for MODAF and DoDAF (UPDM)

Systems Modeling Language (SysML)

Emphasis to Produce and Control Products that Specify the Design


How do i develop relationships between capabilities and segment functional architecture

How Do I Develop Relationships between Capabilities and Segment Functional Architecture?

Customer Spec

Capability

Manual

Mission Use Case

ArtisanStudio ®

Operational Activity

ArtisanStudio ®

Operational

ArtisanStudio ®

System Spec

System Functions

System Behavior Diagrams

DOORS

ArtisanStudio ®

ArtisanStudio ®

ArtisanStudio ®

System

ArtisanStudio ®

Segment Use Case

Segment Behavior Diagrams

Segment Spec

Excel

ArtisanStudio ®

Manual

Segment Functions

Segment

Enables Validation of Top Level Capabilities and Ability to Analyze Future Capabilities


How do i develop relationships at system level architecture

How Do I Develop Relationships at System Level Architecture?

System Level Architecture – UPDM Profile

System

SV-1

Segment Node

«SystemConnector»

External Nodes

External Nodes

External Nodes

External Nodes

SV-2

External Nodes

External Nodes

External Nodes

External Nodes

Segment Node

«DataExchange»

Uses (1..n)

«CommunicationsLink»

Exchanges (1)

Instance of (1)

SV-10c

«DataElement»

Segment

External Node

External Node

«DataExchange»

«DataElement»

«Operation»

«DataElement»

SV-11

SV-4a

Segment

System

Function

«DataElement»

«ObjectFlow»

External Node

Function

Purpose to Validate Implementation Path and Functional Need for Data Element


How do i develop relationships across levels of architecture

How Do I Develop Relationships Across Levels of Architecture?

System Level

UPDM Profile

Segment Node

System

SV-1

External Nodes

External Nodes

External Nodes

External Nodes

«SystemConnector»

SV-2

External Nodes

External Nodes

External Nodes

External Nodes

Segment Node

  • «DataExchange»

  • Periodicity

  • Transfer Protocol

Uses (1..n)

  • «CommunicationsLink»

  • Throughput

SV-11

Exchanges (1)

  • «DataElement»

  • Data Standard

  • Size

  • Classification

SV-6

Refines (1..n)

Segment Level

SysML Profile

Exchanges (1)

IBD

Segment

«ItemFlow»

«ItemFlow»

Element

Element

«DataType»

Exchanges (1)

Element

Purpose to Validate all External Data Elements are Implemented in Segment Design


Lesson s learned keep open mind about tools techniques processes

Lesson(s) Learned: Keep Open Mind about Tools/Techniques/Processes

  • Question(s):

  • Architecture Team: What can the tool support and not support in terms of report generation, traceability, model relationships, etc? Can we accomplish our goal without support from tool vendor? Does our techniques align with NGES processes?

  • Customer: What can the tool provide me in sense of traceability to requirements and the system behavior?

  • Lesson(s):

  • Tool Vendor Support:

    • Determine up front whether to use them or to have an experienced programmer to retrieve model data

  • Management Perception:

    • Tailoring is required of the Processes and not all tools are created equal


Why export mbe data

Why Export MBE Data?

  • View different perspectives without creating diagrams for use in each type of ‘view’ into the model

    • Decrease number of diagrams to maintain and configuration manage

  • Viewing the information in the model is limited to the application GUI that many find cumbersome or confusing

    • Model reviewers don’t need tool training

  • Relationships stored in the database can be ‘hidden’ from certain views or diagrams

Exporting modeled information into a familiar format aids in communication, model validation, and facilitates deliverables


View data across all levels of the architecture

View Data Across All Levels of the Architecture

  • Traditional approaches maintain numerous hierarchy diagrams

  • Hierarchy diagrams can be replaced by a single hierarchy report


Additional relationship reports

Additional Relationship Reports

  • Custom Internal Block Diagram(IBD) report

  • Bi-directional Requirement to Function trace report

  • Bi-directional «InformationElement» to «DataElement» trace report

  • Communications protocol sub-address utilization report

  • Diagram notes report

  • Sequence & Activity Diagram reports

  • «OperationalNode» & «Block» activity reports


Automated model review

Automated Model Review

  • Diagrams show custom views into the underlying model

    • What is in the model that isn’t represented on the diagram?

    • Did the activities really get deleted from the model?

  • Automated analysis can check the entire model

    • Are all my ports typed by the correct model object type?

    • Are there unused item flows defined that the system does not need?

    • What relationship(s) is the modeling tool creating or deleting automatically?

«OperationalNode»

«OperationalPartition»

«OperationalNodeRole» :: «OperationalNode»

«performs»

«OperationalActivityAction»

«OperationalActivity»

«OperationalActivity»


Artisanstudio generated reports support validation of integrated architecture

ArtisanStudio ® Generated Reports Support Validation of Integrated Architecture

Providing these Products Established Evidence to Customer that the System will Accomplish It’s Intended Requirements


Lesson s learned compile functional data architecture completion measures

Lesson(s) Learned: Compile Functional/Data Architecture Completion Measures

  • Question(s):

  • Architecture Team: How do we know when the architecture is done tweaking and we can start building? How do we know when we have satisfied the requirements with the architecture?

  • Customer: What state is the architecture? What are those measures? What measures provide insight into architecture status and progress?

  • Lesson(s):

  • Model:

    • Assign Attributes to monitor relationships (i.e. traceability of requirements to functions)

    • Determine visual representation of measures to depict gaps that need to be worked

  • Customer/Program Meetings:

    • Present burn down charts of both aspects of the functional and data architecture paths


Status reporting and metrics

Status Reporting and Metrics

  • Automatically generate custom-designed metrics


Lesson s learned collaborate with stakeholders on model data needs wants

Lesson(s) Learned: Collaborate with Stakeholders on Model Data Needs/Wants

  • Question(s):

  • Architecture Team: When do I transition the model to System Test? How do I support SW Integration? What are the benefits of MBE? What does my customer need/want to be able to sell off on architecture? What are our requirements for modeling the system (i.e. real time system with executable sequence diagrams/rate monotonic analysis)?

  • Lesson(s):

  • Face to Face Meetings:

    • Determine Stakeholders’ needs vs. wants and lay our against schedule and cost

    • Agree on set of products for stakeholders

    • Create team chart for each product lifecycle phase to maintain and build higher fidelity model


Keystone data case kdc

Keystone Data Case (KDC)

  • End-to-end scenario of normal system operations

  • Owned by System Integration & Test

  • Provides consistent scenario with associated data products across entire system to be used in system integration

  • Documented in ArtisanStudio ® as a series of Sequence Diagrams

    • Custom ArtisanStudio ® export contains:

      • All included sequence diagram steps

      • All included diagrams

      • All utilized data flows (and those not utilized)

      • All implemented functions (and those not implemented)

      • All utilized interfaces (and those not utilized)

    • Helps define KDC to maximize system utilization


Keystone data case kdc1

Keystone Data Case (KDC)

KDC Sequence Diagram

  • MS Excel Report containing:

Ext

Seg A

Seg B

ref

ref

ref

Sequence Diagram 1

Sequence Diagram 2

Sequence Diagram n

All Object Sequence Diagram (OSD) steps

All «DataExchange»

All «SystemFunction»

All «SystemConnector»


End to end test scenarios

End-to-End Test Scenarios

  • Mimic KDC approach within ArtisanStudio ® to allow definition of and export of system behavior scenarios

  • System I&T can leverage system design in test case design

    • System I&T stays in sync with system design

    • Currently only used as a reference for test case design

  • Proposed Option (not adopted to date):

    • Apply attributes to individual sequence diagram steps

      • Free text attribute describing step (required user action or description of automated activity)

      • Link to Test Resources (managed as model objects)

    • Custom script exports all information to a Test Case template document (MS Word)

    • Custom script to aid in population of Test Case steps and Test Resource linking


Benefits to stakeholders

Benefits to Stakeholders

  • Assists decision makers in identifying gaps

  • Ensures complete and consistent architecture from user need to the system design

  • Builds refinement detail for test cases

  • Assists with requirements definition for new systems that are needed to achieve similar capabilities

  • Ability for re-use on future similar architecture programs

Validating that you are “building the right system”…… [Boehm]


Acknowledgements

Acknowledgements

  • Additional Authors

    • Jeff Herbert, Systems Engineer, Northrop Grumman Electronic Systems


Questions and answers

Questions and Answers


  • Login