1 / 0

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 29 th , 2014. Tamara Valinoto. Systems Architect/Model Driven Engineering (MDE) Community of Practice(CoP) Chair. tamara.valinoto@ngc.com.

keren
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 tamara.valinoto@ngc.com MBSE Symposium: INCOSE Chesapeake Chapter and JHU/APL
  2. 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
  3. 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
  4. 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)
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. View Data Across All Levels of the Architecture Traditional approaches maintain numerous hierarchy diagrams Hierarchy diagrams can be replaced by a single hierarchy report
  17. 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
  18. 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»
  19. ArtisanStudio ® Generated Reports Support Validation of Integrated Architecture Providing these Products Established Evidence to Customer that the System will Accomplish It’s Intended Requirements
  20. 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
  21. Status Reporting and Metrics Automatically generate custom-designed metrics
  22. 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
  23. 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
  24. 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»
  25. 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
  26. 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]
  27. Acknowledgements Additional Authors Jeff Herbert, Systems Engineer, Northrop Grumman Electronic Systems
  28. Questions and Answers
More Related