Application of MBSE
Theory in a World of
Practical Deadlines
and Deliverables:
Lessons Learned
March 29th , 2014
MBSE Symposium: INCOSE Chesapeake Chapter
and JHU/APL
Tamara Valinoto
Systems Architect/Model Driven Engineering (MDE)
Community of Practice(CoP) Chair
tamara.valinoto@ngc.com
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
What is Model Based Engineering?
MBE = MBSE + MDD + MBI&T
Framework
Model Based SE
Collaboration
MDE
MDE
COP
COP
Descriptive
MBSE
MBI&T
Support
Model Based I&T
Perf Verification
Model Driven
Development
Analytical
MBSW/
MBHW
(MDD)
Common MDE
Framework Views
Tools & Processes
Artifacts / Products
MBE includes Model-Based Systems Engineering,
Model Driven Development, and Model Based Integration and Test
2
2
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
Breakdown in the Development Process
Leveraging Models / Design Between Engineering Disciplines
Delivered System Does Not Reflect the System
Design
System
Architecture
Model(s)
Software
Architecture
Model(s)
Software
Implementation
Model(s)
• 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
Similar Corollary For
Hardware Design
3
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
How MBE/MBE Should Work Across Disciplines
Using Models to Effectively Communicate and Implement System
System
Architecture
Model(s)
Software
Architecture
Model(s)
Software
Implementation
Model(s)
• 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
4
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
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
5
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
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):
•
•
6
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
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
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):
•
7
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
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
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:
•
•
Training:
•
8
Create HTML exports of views and/or Create Text Diagrams
containing hyperlinks to views within model
Bring in Tool Vendor to showcase the various browser panes if
they exist
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
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:
•
•
Schedule:
•
•
Products Aligned to Milestones ( i.e. CDRLs)
Milestone Reviews:
•
9
Modeling languages
Present Product Traceability from Requirements
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
What are the Architecture Products to Develop at
Each Architecture level for each Milestone?
External
System of Systems Nodes
System
PDR
Segments
Air
Ground
SV-1
(L0)
OV-1d
OV-2
SRR
SV-4a
(L0)
OV-5
SV-1
(L1)
SV-5
SV-2
(L1)
SV-4a SV-10c
(L1)
SV-6
SV-11
CDR
Elements Payload 1
Payload 2
Comms
Behavior
Diagrams
IBD
BDD
Unified Profile for MODAF and DoDAF (UPDM)
Systems Modeling Language (SysML)
Emphasis to Produce and Control Products that Specify the
Design
10
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
Data Model
How Do I Develop Relationships between
Capabilities and Segment Functional Architecture?
Manual
Operational Activity
ArtisanStudi
o®
Mission
Use
Case
System
Spec
DOORS
11
Manual
Segment
Functions
System Behavior
Diagrams
ArtisanStudio
®
Segment
Artisan
Studio
®
ArtisanStudi
o®
System
Segment
Spec
System
Functions
Excel
Segment Behavior ArtisanS
Diagrams
tudio ®
ArtisanStudio ®
Artisan
Studio
®
Operational
Capability
ArtisanSt
udio ®
Customer
Spec
Segment
Use Case
Enables Validation of Top Level Capabilities and Ability to Analyze Future
Copyright © 2014 Tamara Valinoto, Published and Capabilities
used by INCOSE and affiliated societies with permission.
How Do I Develop Relationships at System
Level Architecture?
SV-1
System
External
External
External
External
Nodes
Nodes
Nodes
Nodes
Segment
Node
«SystemConnector»
External
External
External
External
Nodes
Nodes
Nodes
Nodes
«DataExchange»
«CommunicationsLink»
Uses (1..n)
Exchanges (1)
«DataElement
»
SV-11
«DataElement
»
Segment
Node
Instance of (1)
Segment
«DataElement
»
«DataElement
»
SV-2
External Node
External Node
«DataExchange»
«Operation»
System
SV-10c
External Node
Function
«ObjectFlow»
SV-4a
Segment
Function
System Level Architecture – UPDM Profile
Purpose to Validate Implementation Path and Functional Need for Data
12
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
How Do I Develop Relationships Across Levels
of Architecture?
External
External
External
External
Nodes
Nodes
Nodes
Nodes
«SystemConnector»
SysA SysB DE1 Dx IF1 NITF 1kb FTP U
SysA SysB DE1 Dx IF1 NITF 1kb FTP U
Segment Level Exchanges (1)
SysML Profile
Classification
Throughput
Port Type
Comms Path
To Node
IBD
«ItemFlow»
Element
13
SV-6
N1 N2 CP1 PT2 1kbps U
N1 N2 CP1 PT2 1kbps U
Segment
«ItemFlow»
«DataType»
COMMS
From Node
ItemFlow(s)
Data Element
Data Exchange
Destination
Refines (1..n)
Source
•Data Standard
•Size
•Classification
•Throughput
DATA
SYSTEMS
Classification
Exchanges (1)
«DataElement»
Segment
Node
«CommunicationsLink»
•Periodicity
•Transfer Protocol
SV-11
SV-2
Uses (1..n)
Transfer Protocol
«DataExchange»
Segment
Node
SV-1
Size
External
External
External
External
Nodes
Nodes
Nodes
Nodes
System
Data Standard
System Level
UPDM Profile
Element
Exchanges (1)
Element
Purpose to Validate all External Data Elements are Implemented in Segment
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
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:
•
•
Management Perception:
•
14
Determine up front whether to use them or to have an
experienced programmer to retrieve model data
Tailoring is required of the Processes and not all tools are
created equal
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
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
15
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
View Data Across All Levels of the Architecture
• Traditional approaches maintain numerous hierarchy diagrams
Func 1
Func 1.1
Func 1.1
Func 1.1.1
Func 1.2
Func 1.1.2
• Hierarchy diagrams can be replaced by a single hierarchy report
Operational Activity
Operational Activity 1
Operational Activity 2
16
System Function
Func 1
Segment Function
Func 1.1
Func 2
Func 1.2
Func 2.1
Func 3
Func 3.1
Element Function
Func 1.1.1
Func 1.1.2
Func 1.2.1
Func 2.1.1
Func 3.1.1
Func 3.1.2
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
Additional Relationship Reports
Port Type used on
Flow Spec BDD(s)
C1 Block 1 Block 3 Inbound IF1 DT1 OSD1 PN1 PN3 PT1 BDD1
C2 Block 2 Block 4 Internal IF2 DT2 OSD2 PN2 PN4 PT2 BDD2
• Bi-directional «InformationElement» to «DataElement» trace report
• Communications protocol sub-address utilization report
• Diagram notes report
• Sequence & Activity Diagram reports
• «OperationalNode» & «Block» activity reports
17
Port Type
To Port
From Port
PORT INFO
Item Flow OSD(s)
«DataType»
«ItemFlow»
DATA
Direction
Destination «Block»
• Bi-directional Requirement to
Function trace report
«Connector»
• Custom Internal Block Diagram
(IBD) report
Source «Block»
BLOCKS
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
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?
«OperationalPartition»
«OperationalNodeRole» :: «OperationalNode»
«OperationalNode»
«performs»
«OperationalActivityAction»
«OperationalActivity»
18
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
ArtisanStudio ® Generated Reports Support
Validation of Integrated Architecture
Validation
Model Elements
System Function
Mission Use Case
System Requirement to System Function
OPSCON Activity
Mapping
Segment Function
Requirement
System Interfaces
Data Exchanges
System Data Exchange Matrix
Data Elements
Comms Paths
System Sequence Diagram Report
Segment Internal Block Diagram Data
Exchange Matrix
Segment Activity Diagram Report
Sequence Diagrams
Sequence Diagram Messages
Internal Interfaces
Item Flows
Activity Diagram
Swimlane
Activity
Connection Type
Data Element
System to Operational Data Mapping
Purpose
Depict Function Traceability throughout model
Identify functions mapping to requirement
Create Verfification binning metrics
Determine meeting operational needs of users
View mapping from Operational into System Functional
Architecture
Identify Interfaces with/without Data Exchanges
Identify Data Exchanges with/without Comms Paths
Identify Data Exchanges with/without behavior
diagrams
Identify Functions with/without behavior diagrams
Calculate % of functions with behavior diagrams
Identify interfaces with/without Item Flows
IdentifyItem Flows with/without Behavior Diagrams
Identify inconsistencies in flow spec models
List all Connection Types for any element
List Activities grouped by owning element
View mapping from System to Operational Data
Architecture
Information Element
Providing these Products Established Evidence to Customer
that the System will Accomplish It’s Intended Requirements
19
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
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:
•
20
Present burn down charts of both aspects of the functional and data
architecture paths
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
Status Reporting and Metrics
• Automatically generate custom-designed metrics
Percentage of Objects Mapped
Mapped
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
Unmapped
Final
16
23
10
194
100%
116
90%
Intentionally
Omitted
Current
Diagram Status
ECR Rework
8
796
10
15
Draft
101 10
Preliminary
15
80%
70%
60%
50%
40%
38
21
40
30%
13
20%
10%
12
0%
System
21
Segment
Element
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
In Work
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):
•
22
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
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
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
23
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
Keystone Data Case (KDC)
KDC Sequence Diagram
Usage
Func 1 E Leaf Yes
Yes KDC Yes
Func 2 I Leaf No Partial Other No
Func 3 S Leaf Partial Yes KDC Yes
KDC
Category
DATA
Classification
Usage
Test Event B
Test Event A
Type
SYSTEMS
KDC
Interface
SysB KDC Yes
SysB Other No
SysC KDC Yes
Name
Usage
SysA
SysA
SysB
Category
Source
SC1
SC2
SC2
FUNCTION
KDC
Destination
Interface
SYSTEMS
All «DataExchange»
All «SystemFunction»
Transfer Protocol
Sequence Diagram n
Data Standard
ref
All Object Sequence
Diagram (OSD) steps
Data Element
Sequence Diagram 2
Data Exchange
ref
Destination
Sequence Diagram 1
«OSD» Keystone Data Case
«OSD» Sequence Diagram 1
Step 1
par
Step 1.1
also par
Step 1.2
end par
Step 2
«OSD» Sequence Diagram 2
Step 1
…
Source
ref
All «SystemConnector»
24
• MS Excel Report containing:
Seg B
Category
Seg A
Importance
Ext
SC1 SysA SysB DE1 D1 KMZ FTP U KDC Yes
SC2 SysA SysB DE1 D1 KMZ FTP U Other No
SC2 SysB SysC DE2 D2 XLS HTTPS U KDC Yes
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
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
25
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
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]
26
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
Acknowledgements
• Additional Authors
– Jeff Herbert, Systems Engineer, Northrop Grumman Electronic
Systems
27
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
Questions and Answers
28
Copyright © 2014 Tamara Valinoto, Published and used by INCOSE and affiliated societies with permission.
29