the benefits & challenges of mbse: i know an old lady
TRANSCRIPT
Copyright © 2015
Benefits and challenges of MBSE – I know an old lady
By Prof Jon HoltTechnical Director, INCOSE UK
Overview
1. Realising MBSE2. I know an Old Lady3. Conclusions
1: Realising MBSE
«block»Person
«block»Process
«block»MBSE
«block»Tool
1..* 1..*
1..*
enables
1..* 1..*
drives
1..*
1..*
2: I Know an Old Lady …
… Who Swallowed a Fly …..
… I Don’t Know Why She Swallowed a Fly
• Knowing ‘why’ is essential• ‘Why’ will depend on context
– Different stakeholders have different needs– Different stakeholders want different benefits
Realising MBSE Benefits
«block»Person
«block»Process
«block»MBSE
«block»Tool
«block»Benefit
«block»Stakeholder Role
1..* 1..*
1..*
enables
1..*
1..*
must realise
1..*
1..*
drives
1..*
1..*
Typical MBSE Stakeholder Roles«block»
Stakeholder Role
«block»Customer
«block»External
«block»Supplier
«block»User
«block»Operator
«block»System Sponsor
«block»Standard
«block»Manager
«block»Engineer
«block»MBSE Sponsor
«block»Benefit
1..*
must realise
1..*
Engineer ContextEngineer Context
Improv e system dev elopment
Improv e consistency
Improv e automation
Make approach more efficient
Manage complexity
Increase understanding
Improv e communication
... for testing
... for artefact generation
... for model checking
improv e tool interoperability
MBSE Sponsor
Manager
«include»
«constrain»
«constrain»
«constrain»
«include»«include»
«constrain»
MBSE Sponsor ContextMBSE Sponsor Context
Increase v alue of business
Increase sales Increase quality
Inv est in MBSE
Demonstrate ROI
Operator
User
Engineer«include»
«constrain»
«constrain»
«include»
Identified Benefits of MBSE«block»
Time
«block»Resource
«block»Money
«block»Quality Attribute
«block»Safety
«block»Security
«block»Compliance
«block»Return on Inv estment
«block»Efficiency
«block»Consistency
«block»Complexity
Management
«block»Communication
«block»Re-use
«block»Tool Interoperability
«block»Automation
{incomplete}
MBSE
I Know an Old Lady Who Swallowed a Spider …
… That Wriggled and Jiggled About Inside Her• Look for tried and tested solutions• For flies, this is a spider• For MBSE, this is:
– Standards– Architecture frameworks– Modelling notations– Processes– Methodologies– More staff– Etc.
Example Solutions – Architectures
• Consider the following examples:– MODAF/DoDAF/NAF – Zachman – ISO 42010 (‘Systems and software Engineering -
Architecture description’)• What are you trying to do:
– Development?– Acquisition?– Enterprise Architecture?
Visualising Architecture
I Know an Old Lady Who Swallowed a Bird/Cat/Dog …
… How Absurd … Imagine That … What a Hog
• Need to understand and control use of techniques– Shows no understanding of systems engineering– Shows no understanding of own competence
• Need common language:– In terms of spoken language (e.g. SysML)– In terms of domain-specific language (e.g. an
Ontology)
Example of Common Spoken Language - SysML
Example of Common Domain Language – The MBSE Ontology
«block»Viewpoint
Element
«block»Architectural Framework
«block»Architecture
«block»Ontology
«block»Ontology Element
«block»View
«block»View Element
«block»Viewpoint
«block»Rule
properties ID : Text Description : Text
«block»Enabling System
«block»Constituent
System
«block»System Element
«block»System Context
«block»System of
Interest
«block»System of Systems
«block»System
«block»Virtual
«block»Collaborative
System
«block»Directed System
«block»Acknowledged
System
«block»Product
«block»Serv ice
«block»Activ ity
«block»Artefact
«block»Process
«block»Process
Execution Group
«block»Resource
«block»Stakeholder Role
«block»Context
«block»Use Case
«block»Lev el
«block»Competence
«block»Competency
«block»Competency
Scope
«block»Competency
Profile
«block»Person
«block»Life Cycle
«block»Life Cycle Interaction
«block»Life Cycle
Interaction Point
«block»Life Cycle Model
«block»Gate
«block»Stage
«block»Project
«block»Programme
«block»Organisational
Unit
«block»Organisation
«block»Concern
«block»Need
«block»Source Element
«block»Need Description
«block»Scenario
«block»Capability
«block»Goal«block»
Requirement
«block»Stakeholder
Context
«block»Project Context
«block»Organisational
Context
«block»Semi-formal
Scenario
«block»Formal Scenario
«block»Process Context
1 requires
1
1..*
1
1..*
is elicited from
1..*
1..*
de
scrib
es
me
asu
red
1
1..* 1
{incomplete}
1..*
describes the evolution of
1
1describes
1
1
is related to
0..*
1..*
is executed during
1
1
shows the order of execution of1..*
1..*represents the need for
1
1
interacts with
1..*
1..*
runs
1..*
1
1..*
describes the context of
1..*
1..*
describes
1..*
1..*
interacts with
1
1..*d
escrib
es th
e e
volu
tion
of
1
1
produces
1..*
1
is realised as
1..*
1
describes abilities of
1
1..*
1
1..*
1
1..*
corresponds to
11..*
11..*
1..*
shows behaviour of
1
1..*
validates
1..*
1..*
1
1..*
1
1..*
describes the need for
1
1..*
visualises
1
1
1..*produces/consumes
1..*
1
assesses the execution of
1
1
represents the need for
1
1..*
describes desired
1
1..*
1
1..*
1
1
interacts with
1..*
1..*
is needed to deliver 1
1..*
uses elements from
1
1..*
is executed during
1
1..*holds1..* 1..*
enables
1..*
1is held at
1
1..*
con
stra
ins
1
1..*
conforms to
1
1..*
1
describes interactions between
1
1..*
meets
1..*
1..*
interacts with
1
1
describes structure of
1
1..*
realises
1..*
1
interfaces with
1..*
1..*
0..1
1
is assessed against
1
1
interacts with
1..*
1
represents the need for
1..*
1..*
constrains
1..*
1
is responsible for
1..*
1
consumes
1
exhibits
1
1..*
1
1..*
1
Focus on Architecture
«block»Viewpoint Element
«block»Architectural Framework
«block»Architecture
«block»Ontology
«block»Ontology Element
«block»View
«block»View Element
«block»Viewpoint
«block»Rule
«block»System
1..*
1
1..*
describes
1..*
1..*
1
1..*
corresponds to
1
1
is related to
0..*
1..*
1
1
1
1..*
1
1
describes structure of
1
1..*
constrains
1
1..*
11..*
uses elements from
1
1..*
conforms to
1
1..*
visualises
1
Focus on Need
«block»Rule
«block»Context
«block»Use Case
«block»System Context
«block»Concern
«block»Need
«block»Source Element
«block»Need Description
«block»Scenario
«block»Capability
«block»Goal
«block»Requirement
«block»Stakeholder
Context
«block»Project Context
«block»Organisational
Context
«block»Semi-formal
Scenario
«block»Formal Scenario
«block»Process Context
1..*
constrains
1..*
1..*
validates
1..*
1..*
is needed to deliver 1
1..*
is elicited from
1..* 1..*
describes the context of
1..*
1..*
traces to
1..*
1
describes
1
{incomplete}
1..* meets
1..*
1
is related to
0..*1
is related to
0..*
I Know an Old Lady Who Swallowed a Goat/Cow …
… She Opened Her Throat … I Don’t Know How• Complete chaos!
– Lost sight of original goals– No concept of relationships between techniques
• The MBSE Ontology drives the implementation of MBSE– Basis for framework and associated views– Defines how views may be visualised (informs notation)– Allows understanding and definition of associated processes– Allows understanding and definition of associated
competence– Provides valuable input into tool assessment
Example View Based on the MBSE Ontology
«block»Rule
«block»Context
«block»Use Case
«block»System Context
«block»Concern
«block»Need
«block»Source Element
«block»Need Description
«block»Scenario
«block»Capability
«block»Goal
«block»Requirement
«block»Stakeholder
Context
«block»Project Context
«block»Organisational
Context
«block»Semi-formal
Scenario
«block»Formal Scenario
«block»Process Context
1..*
constrains
1..*
1..*
validates
1..*
1..*
is needed to deliver 1
1..*
is elicited from
1..* 1..*
describes the context of
1..*
1..*
traces to
1..*
1
describes
1
{incomplete}
1..* meets
1..*
1
is related to
0..*1
is related to
0..*
«block,rule»ACRE01
notesEach Source Element in the SourceElement View must be traceable to oneor more Need Description in theRequirement Description View.
«block,rule»ACRE02
notesEach Need Description in theRequirement Description View must betraceable to one or more SourceElement in the Source Element View.
«block,rule»ACRE03
notesRules, when they exist, must apply to aNeed Description.
«block,rule»ACRE04
notesRules, when they exist, must apply to aNeed Description.
«block,rule»ACRE05
notesEach Need Description must be relatedto at least one Use Case.
«block,rule»ACRE06
notesThe Need Description Views must relateto a Requirement Context View.
«block,rule»ACRE07
notesEach Need Description must have a fullset of attributes defined.
«block,rule»ACRE08
notesEach Rule must apply to at least oneNeed Description attribute or the NeedDescription itself.
«block,rule»ACRE09
notesEach Need Description may beconstrained by zero or more Rules.
«block,rule»ACRE10
notesEach Requirement Context View musthave a related element on a ContextDefinition View that defines theContext.
«block,rule»ACRE11
notesEach Use Case must be related to atleast one Need Description.
«block,rule»ACRE12
notesEach and every Need Description musthave at least one Use Case.
«block,rule»ACRE13
notesEach Stakeholder Role on theRequirement Context View must have anassociated element form a ContextDefinition View, such as a StakeholderRole or System Element.
«block,rule»ACRE14
notesEach Context Definition View must berelated to at least on RequirementContext View.
«block,rule»ACRE15
notesEach Use Case must be related to eitheranother Use Case or a Stakeholder Role.
«block,rule»ACRE16
notesEach Use Case must have at least oneValidation View associated with it.
«block,rule»ACRE17
notesEach element in each Context DefinitionView may define an individualRequirement Context View.
«block,rule»ACRE18
notesEach element on a Stakeholder ContextDefinition View, such as a StakeholderRole or System Element, may appear as aStakeholder Role on a RequirementContext View.
Example View Based on the MBSE Ontology
«block»Rule
«block»Context
«block»Use Case
«block»System Context
«block»Concern
«block»Need
«block»Source Element
«block»Need Description
«block»Scenario
«block»Capability
«block»Goal
«block»Requirement
«block»Stakeholder
Context
«block»Project Context
«block»Organisational
Context
«block»Semi-formal
Scenario
«block»Formal Scenario
«block»Process Context
1..*
constrains
1..*
1..*
validates
1..*
1..*
is needed to deliver 1
1..*
is elicited from
1..* 1..*
describes the context of
1..*
1..*
traces to
1..*
1
describes
1
{incomplete}
1..* meets
1..*
1
is related to
0..*1
is related to
0..*MBSE Champion
Requirement Engineer
Tester
Standard
Requirement Manager
Customer
Support capture of needs
Support capture of requirements
Support capture of capabilities Support capture of
goals
Must be model-based Comply with standards
Identify source of needs
Ensure consistent style
Define v alidation approach
Consider needs in context
Identify contexts
AF Framework Context
«constrain» «constrain»
«include»
«constrain»
«include»«include»
«constrain»
I know an old lady who swallowed a horse …
… She’s Dead, of Course!…
Copyright © 2015 29
2. Conclusions
• MBSE requires:– People, process and tools
• Essential concerns:– Understand why and the benefits– Do not apply techniques blindly
• Getting it right includes:– Have a solid basis for MBSE – use of MBSE Ontology
• Getting it wrong results in:– Dead bodies– Horse dung
