Supporting Development of

Complex System through

Model-Based Systems
Engineering (MBSE)

1
Dr. Oscar A Mondragon
Director MS in Software Engineering
Computer Science Department
The University of Texas at El Paso
Challenges of Systems Development
From where does system design currently emerge?
emerges from pieces, rather than from architecture
➔ systems are:
breakable,
difficult & complex to test and operate

Knowledge & Investment

The pace of change
• Lost at project lifecycle phase
• Greater pace of change • Development cost go up
• Reduce time to deliver solutions • Late discovery of design problems

System complexity
Increased due to:
Mission complexity growth
• Languages, technology, • Growing faster than our ability to manage it
• Global information flow. • Inadequate specifications
• Incomplete verification.

Systems development has not kept pace with

Demands of capability the demands to deliver more capability in less time
➔ traditional methods and development teams often fail to deliver
Source: “Essentials of IBM Rational Rhapsody for Systems Engineers” course from IBM Corporation 2012 & INCOSE Vision 2025
 Document-driven communication
Development is largely
document-driven.

Then submitted into a

?
Documentation is developed based stack of documents for
upon the needs of the customer. review and analysis.

Stack of documents is sent downstream System design is accepted and built

Architecture & Design are then created
But is the system correct?
Document-driven development - how it should work …

Traditional development assumes design input is both fully and correctly defined.

Down-stream phases are validated

Requirements System
Capture & Analysis Acceptance

Product Requirements
Specification

Systems Analysis & Sub-System

Design Integration & Test

Product Design Spec

SW Requirements Spec .exe

.doc
Specifications are
developed for the next Unit/Module
Software Design Integration Test
design & analysis phase.
SW Design .exe
Integration & testing
Specification
.doc verify that requirements
are satisfied.
SW Implementation

Source: “Essentials of IBM Rational Rhapsody for Systems Engineers” course from IBM Corporation 2012 & INCOSE Vision 2025
Document-driven development - how it should work …

The Problem
Requirements System
Capture & Analysis Acceptance

Product Requirements
Specification

Systems Analysis & Design Sub-System

Integration & Test

Product Design Spec

SW Requirements Spec .exe

.doc

Module
Software Design Integration Test
Documentation,
analyses, and design
SW Design are found to not be
.exe
Specification
.doc
correct at the end of
development, leading
SW Implementation to re-work.

Source: “Essentials of IBM Rational Rhapsody for Systems Engineers” course from IBM Corporation 2012 & INCOSE Vision 2025
 The Problem
Requirements System
Capture & Analysis Acceptance

Product Requirements
Specification

Systems Analysis & Design Sub-System

Integration & Test

Product Design Spec

SW Requirements Spec .exe

.doc

Module
Software Design Integration Test
Documentation,
analyses, and design
SW Design are found to not be
.exe
Specification
.doc
correct at the end of
development, leading
to re-work.
Rework is costly and
SW Implementation

time consuming
▪ schedule delays Common Issues
▪ Need for change is typically
• Documents are not updated
discovered late
▪ changes not reflected up • Documentation inconsistent, incorrect, & abandoned
or down • All the effort and discipline is wasted.

Source: “Essentials of IBM Rational Rhapsody for Systems Engineers” course from IBM Corporation 2012 & INCOSE Vision 2025
 Coupling with Complexity: iteration and Recursion
Enterprise/system of systems

Concept definition

Business or mission analysis Recursion

Stakeholder needs and requirements System of Interest

definition System
(SOI)
of Interest
(SOI)

System requirement definition

Concept definition

Business or mission analysis

Iteration

Architecture definition
Stakeholder needs and requirements
definition

Design definition
System requirements
System definition
Systemlevel
levelnn-1-1 System level n
System definition
System
-1 level n

Iteration
System
-1 level n
Architecture
System definition
Systemlevel
levelnn-1-1 -1

Design definition
System level n -1
System level n -1
Adapted from INCOSE (2015). Systems Engineering Handbook: A Guide
for System Life Cycle Process and Activities (4th ed.). Figure 3.5 on
page 33.
Risk – based Coupling with complexity: Spiral Methods
stakeholder
commitment
review points 2 Valuation commitment
Cumulative level of understanding, 1 Exploration commitment review review
product and process detail (risk – driven) 4 Development
3 Foundations commitment review commitment review

Spiral 5 Operation (1) and development

(2) commitment review
6
Operation (2) and
development (3)

Model commitment review

Activities
Concurrent risk – and –
opportunity – driven
Concurrent growth of system Initial scoping
engineering of
products and
understanding and
processes definition

Evaluation of
evidence of feasibility Feasibility evidence
to proceed

Stakeholder review
…
Risk – based acceptable Evidence – based review content and commitment
decisions • A first – class deliverable
• Independent expert review
Negligible
Risk High, but
• Shortfalls are uncertainties and risks
addressable

Too high, Adapted from INCOSE (2015). Systems Engineering Handbook: A Guide for
addressable System Life Cycle Process and Activities (4th ed.). Figure 3.10 on page 37.
Collaboration in text … in action
Ok this is how it should work: Communicating through only
The Device Manager sends a request to the Transaction Manager – that text can be difficult when
will put the Transaction Manager into a Checking State, from what it was trying to impart knowledge
before which was Idle.
and intent of a system.
The Transaction Manager then sends a message to the Account manager
to get authorization and waits for a message to come back.
If the authorization doesn’t come back within 2 seconds the Transaction
Manager sends a denied message back to the Device Manager. The Device
manager will have started in an Idle state but after it gets the
confirmation it should move to a state where it waits until it gets the
…what???
authorization. If it instead gets a denied message then it should move back
to being idle.
All this should happen in less than 5 seconds. ?

Engineer 2
Engineer 1 Source: “Essentials of IBM Rational Rhapsody for Systems Engineers” course from IBM Corporation 2012 & INCOSE Vision 2025 9
 Collaboration using diagrams
Communicating through visual representations is
a much more natural and intuitive method.

Here, look at this

Ahhh, now I
Sequence Diagram.
see!

The above model has:

• well defined syntax & semantics
• reduces ambiguity.

Engineer 2
Engineer 1 Source: “Essentials of IBM Rational Rhapsody for Systems Engineers” course from IBM Corporation 2012 & INCOSE Vision 2025 10
Graphical Abstraction
Graphical abstractions are used different fields,
They represent concepts.

(Click here)

Computer-aided Manufacturing
Circuit diagram Abstract model of an atom diagram for the face of a calculator

Top-view drafting of a floor

plan for a living space Side-view draft of a mechanical device

Source: “Essentials of IBM Rational Rhapsody for Systems Engineers” course from IBM Corporation 2012 & INCOSE Vision 2025 11
 What is MBSE?
Life-cycle Support
Model-based systems engineering
• formalized application of modeling to
support system requirements, design,
analysis, verification, and validation
activities
• Done throughout life cycle phases

INCOSE Systems Engineering Vision

2020 (2007)
Levels of Abstraction

More simply…
MBSE is the formalization of the practice of
systems development through the use of models

Source: INCOSE. 2015. Systems Engineering Handbook: A

Guide for System Life Cycle Processes and Activities, version
4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc
 MBSE Scopesystems
Model-based & Goalengineering

What is its scope?

To integrate with multiple modeling domains across
the life cycle from system of systems to component.

What is its goal?

Facilitate results in quality / productivity
improvements & lower risk

For the specification of a product,

MBSE enhances the ability to:

Capture Analyze data Share Manage

information knowledge complexity

Source: INCOSE. 2015. Systems Engineering Handbook: A

Guide for System Life Cycle Processes and Activities, version
4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc
 Characteristics of MBSE

Model-centric, not
Diagram-centric Views are generated
from the model
• An underlying model of the system is required,
not just several diagrams thrown together. • Consistency is maintained as changes occur
• A common repository is maintained for the
model. • Views are tailorable to the needs and
understanding-level of the audience.
• All team members have access to the model.
• One version of the truth is maintained across
all views

Complete, Query-able, Virtual

Unambiguous notation System Prototype

• Syntax and Semantics for each model • A prototype that can handle all aspects of
Systems Engineering
• Omissions within the design are found
• Capable of acting as a virtual prototype
 Example of SE Domains

Behavior Domain
Source Requirements Domain

To use MBSE, all defined SE V & V Domain Architecture Domain

domains must:
• be integrated
• have connectivity
• be coherent

Adapted from Webinar by Vitech

Model-centric, not diagram-
centric
“But don’t we draw diagrams???”
• Model-centric approach develops a central model
for the system-of-interest
• Have certain aspects represented by diagrams.

• So, by creating several diagrams of the system

• Throwing them together
• ➔ it does not constitute a model

It takes an organizational effort to

create an inclusive repository for the
knowledge contained in a model.

Adapted from Webinar by Vitech 16

Model-centric, not diagram-centric
Each member of a project must overcome the “silo” effect and contribute their
experience in transforming and incorporating the source material into the model.
Behavioral Analysis Architecture Synthesis
Verification

Requirements
Management

System-of-Interest
Source Model
Material Design Specifications,
Architecture artifacts,
SysML views

Adapted from Webinar by Vitech 17

 Unambiguous Notation
… What, … A or B and C
Ambiguous Notation
• Anything that can lead to multiple interpretations
• wastes both time and money
• misunderstand leads to multiple versions of the “Truth”
• natural language are prone to ambiguity.

Examples of ambiguous notation

that exists: • “….part of…”
• “…kind of…”
• “….associated with…”
• “…depends on…”

Promote continuity, not Ambiguity

• Use models with specific syntax
and semantics
• Ensure clarity among design teams

Adapted from Webinar by Vitech 18

Impact of Unambiguous Notations
Cost of Correcting Defects
Defect Identification $ 1000x

• Incomplete interfaces
• Unallocated behavior
• Unimplemented
$ 100x
requirements
• Unverified requirements
$ 10x
• Unaddressed risks
• Undocumented $ 1x
elements
Analysis Design Implementation Production Fielding

Is the requirement “The automated teller system shall respond to the

correct? ➔ user’s query within a reasonable amount of time.”

“reasonable amount of time” is ambiguous

If not caught early ➔ lot of rework later
Adapted from Webinar by Vitech 19
 Views Generated from the Model
Behavioral Architecture
Analysis Synthesis
Change control Requirements Verification
Management

Model-centric approach,
viewpoints must be generated
from the model
• ensures embedded knowledge
is consistent and correct. System-of-Interest
• Changes by developers in one Model
view ➔
reflected across all the model Design
Specifications,
Architecture
artifacts, SysML
views
Source
Material

Adapted from Webinar by Vitech 20

 Benefits of MBSE
Improved communications
Among all stakeholders
Customer, Program management, Systems engineers, Hardware and
Software developers, Testers, and Specialty Engr

Ability to manage system complexity Improved product quality

• Enabling a system model to be viewed from multiple • Providing an unambiguous and precise
perspectives model of the system
• Analyze the impact of changes • Model can be evaluated for consistency,
correctness, and completeness

Enhanced knowledge capture and reuse

• Capture information in standardized ways
• Leverages abstraction mechanisms inherent in
Teach and learn SE
model‐driven approaches.
• Lowers maintenance costs to modify the design Provides a clear and unambiguous
representation of the concepts

Source: INCOSE. 2015. Systems Engineering Handbook: A

Guide for System Life Cycle Processes and Activities, version
4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc
 MBSE methodologies
“Methodologies”
A methodology can be defined as the collection of related processes,
methods, and tools used to support a specific discipline (Martin, 1996).

MBSE methodology
The collection of related processes, methods, and tools used to support
the discipline of SE in a “model‐based” or “model‐driven” context
(Estefan, 2008).

Source: INCOSE. 2015. Systems Engineering Handbook: A

Guide for System Life Cycle Processes and Activities, version
4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc
OOSE - System Development Process
Integrated Product Development (IPD) is
essential to improve communications
between the Systems modeling team and the
Component modeling team.

OOSE activities

It is a recursive “V”
process that can be
applied to multiple levels
of the system hierarchy.

Source: INCOSE. 2015. Systems Engineering Handbook: A

23
Guide for System Life Cycle Processes and Activities, version
4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc
System Modeling Activities – OOSEM
Integrating MBSE into the SE Process
Major SE
development
activities

Common
sub-activities

The system requirements and design process is decomposed

into the OOSEM high‐level activities depicted above.

Source: INCOSE. 2015. Systems Engineering Handbook: A

24
Guide for System Life Cycle Processes and Activities, version
4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc
 Summary
Model-centric vs Model-centric systems engineering is to
Document-centric… replace document-centric approaches
(Click here)

MBSE involves... Formalization of practice of systems

(Click here) development through models

MBSE helps facilitate… • Communications among stakeholders

(Click here) • Management of complexity
• Support for consistency & error checking

A model-centric approach
• Removes ambiguity from a project
• Ensures one version of the “truth”
• One repository used by all members
• build multiple views from the model

25
References

• INCOSE. 2015. Systems Engineering Handbook: A Guide for System Life Cycle Processes and
Activities, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-
99940-0
• IBM Corporation 2012. Essentials of IBM Rational Rhapsody for Systems Engineers v7.6.1
course
• Vitech Corporation. 2013. Vitech Webinar 10/2/2013

Dr. Oscar A Mondragon

Director MS in Software Engineering
Computer Science Department
The University of Texas at El Paso
26