Difference between revisions of "MBSE Adoption Guide"

From Model Based Systems Engineering Wiki
Jump to: navigation, search
(→‎Overview and the 6 W's)
(→‎Previous Reports)
 
(24 intermediate revisions by 2 users not shown)
Line 4: Line 4:
  
 
* An individual systems engineer;
 
* An individual systems engineer;
−
* An engineering manager (with responsibility for a project, or organisational unit / department / function).
+
* An engineering manager (with responsibility for a project, or organisational unit/department/function).
  
 
Current generic questions are proposed to be (''JJ - have deliberately re-ordered to bring Why to top''):
 
Current generic questions are proposed to be (''JJ - have deliberately re-ordered to bring Why to top''):
Line 10: Line 10:
 
# Why should I adopt MBSE?
 
# Why should I adopt MBSE?
 
# What does MBSE mean for my role?
 
# What does MBSE mean for my role?
−
# Where (activity area, disciplines level of decomp) do I employ MBSE?
+
# Where (activity area, disciplines, level of decomposition etc.) do I employ MBSE?
 
# When (temporal e.g. life cycle phase, criteria) should MBSE be employed?
 
# When (temporal e.g. life cycle phase, criteria) should MBSE be employed?
 
# Who else needs to participate in, or will be impacted by the use of, MBSE activities?
 
# Who else needs to participate in, or will be impacted by the use of, MBSE activities?
 
# How do I make use of MBSE on my project?
 
# How do I make use of MBSE on my project?
  
−
A graphic illustrating this outline is available on the MBSE.org site here:
+
==Latest status==
−
[http://www.mbse.org.uk/forum/viewtopic.php?f=6&t=7&start=10#p43 6-questions poster draft]
+
A Version 0.4 was evolved through to late 2017 and made available both in wiki and pdf formats (broadly identical). This went through a conventional review process, leading to a version v0.5 being produced (captured offline by JJ) which addressed many (although not all) of the comments and suggestions made. The initial version of the Adoption Guide now available on the wiki is that same v0.5 - however as authors update and extend that text on the wiki, it will, of course, deviate from the (JJ) baselined version.
 +
===Previous Reports===
  
−
So what we see below are two subsections, for each of these two primary roles, and with an elaborated response for each of the 6 questions, for each role.
+
*[http://www.incosewiki.info/Model_Based_Systems_Engineering/Files/4/43/INCOSE_UK_MBSE_Subgroup_Status_MBSE_Adoption_Guide_20170427.pdf 27-04-2017]
−
 
+
* [http://www.incosewiki.info/Model_Based_Systems_Engineering/Files/9/90/2017_09_26_INCOSE_UK_MBSE_IG_-_subgroups_Status_JJ_v1_no_res.pdf 26-09-2017]
−
==Details of 6 W's and responses==
+
*[http://www.incosewiki.info/Model_Based_Systems_Engineering/Files/0/06/2018_03_20_INCOSE_UK_MBSE_IG_-_Adoption_and_MDA_subgroups_Status_JJ_v1_no_res.pdf 20-03-2018]
−
===[[Individual Systems Engineer]]===
+
−
 
+
−
===An engineering manager===
+
−
====Why should I adopt MBSE?====
+
−
You should adopt an MBSE approach for systems engineering because
+
−
* There is an steady trend in the systems engineering community to move from conventional or document-based systems engineering (DBSE) to model-based systems engineering.  
+
−
* Use of models increases early rigour, identifies gaps and inconsistencies, and helps to eliminate errors.
+
−
* Increases the potential for design re-use.
+
−
* Helps to facilitate checking across domains and disciplines.
+
−
* Increases the degree to which requirements, design and V&V information can be checked by software, complementing the capabilities and skills of engineers.
+
−
* Although there is mixed evidence of sound Return on Investment (ROI) in MBSE approaches over 'short' time frames, there is compelling evidence that MBSE approaches do systematically offer improved rigour and thoroughness to SE compared with the outcome of the same activities performed with DBSE; some authors would argue that asking 'what is the ROI for MBSE adoption?' is asking the wrong question; a better question would be 'what improvements in quality and error reduction do I realise with adoption of MBSE compared to DBSE?.
+
−
 
+
−
''Rationale''
+
−
 
+
−
The trend to adopt MBSE has emerged for several reasons: a few spectacular failures of DBSE often due to relatively simple reasons that might otherwise have been avoided by the adoption of more rigour from models (for instance, the Mars Lander failure, due to mis-match of engineering units between different engineering teams; the wish to increase rigour to early-phase systems engineering activities (requirements elicitation and management...).
+
−
 
+
−
====What does MBSE mean for my role?====
+
−
It will mean the following:
+
−
* Becoming aware of the principles, practical aspects, benefits and challenges of adopting MBSE as a way of doing systems engineering for your part of the engineering organisation;
+
−
* Identifying, considering and potentially challenging information about cost, quality and timescale for systems engineering processes followed in a MBSE approach;
+
−
* Identifying, and sharing learning experience, with other non-SE stakeholders in your organisation, both positive and less-positive;
+
−
* Considering suport and resources to run small MBSE trials, or engage with other parties (such as academia) who might be running such trials;
+
−
* Once convinced of the need to migrate to MBSE, establishing an migration strategy;
+
−
* Your strategy will need to address many aspects and implications including: training, tooling, infrastructure, processes, internal and external stakeholders affected;
+
−
* Establish a migration plan to pursue the MBSE adoption, consistent with your adoption strategy;
+
−
* Obtaining resources and funding to support the execution of the plan;
+
−
* Monitor and course-correct as necessary.
+
−
 
+
−
''Rationale''
+
−
 
+
−
As an engineering manager the focus is on the appropriate engineering contribution to effective development to cost, quality and timescale. This then brings in all the perspectives of persons, process, tools, infrastructure, interoperability, configuration control, technical risk, lean vs agility, and appropriateness of approach for the given level of integrity (safety level etc).  
+
−
 
+
−
Conventional document-based systems engineering (DBSE) is a known quantity (to some extent). Adopting a MBSE approach requires a different skill set and experience, different tools, different infrastructure and a profile of progress for the development that is likely to be significantly different to that for DBSE.
+
−
 
+
−
====Where (activity area, disciplines, level of decomp) do I employ MBSE?====
+
−
(elaborated response)
+
−
 
+
−
====When (temporal e.g. life cycle phase, criteria), should MBSE be employed?====
+
−
(elaborated response)
+
−
====Who else need to participate in MBSE activities?====
+
−
(elaborated response)
+
−
====How do I make use of MBSE on my project / area of responsibility?====
+
−
(elaborated response)
+
  
 
==Case Studies==
 
==Case Studies==
−
This section lists details of any case studies of applicaiton of MBSE, with appropriate hard information, where that can be made available.
+
This section lists details of any case studies of application of MBSE, or adoption of MBSE, with appropriate supporting information, where that can be made available.
  
 
''(to be populated).''
 
''(to be populated).''
 +
 
==FAQ==
 
==FAQ==
 
This section will evolve to contain frequently asked questions about MBSE and its adoption, with responses, supported by references where possible.
 
This section will evolve to contain frequently asked questions about MBSE and its adoption, with responses, supported by references where possible.
  
 +
''(to be populated).''
  
−
''(to be populated).''
+
==Related Material==
 +
Links to external and/or INCOSE materials relevant to MBSE Adoption.
 +
 
 +
Note: Some of the links below may only be accessible to INCOSE members, and you may need to login to INCOSE Connect to access.
 +
 
 +
{| class="wikitable"
 +
!Reference
 +
!Relevance
 +
!Link
 +
|-
 +
|Don't Panic - The Absolute Beginner's Guide to Model_based Systems Engineering, Jon Holt and Simon Perry,INCOSE UK ltd, 2017
 +
|As the book back cover states: "(This book) aims to provide an honest, straightforward and simple introduction to the world of MBSE that almost anyone can understand." A short (~50 pp) book that does a quick gallop through MBSE: history, modelling (concept of), language (of modelling), art of (modelling), implementing MBSE, and best practice. Littered with sweet little handy icons for: pitfalls, myths, key concepts and benefits.
 +
|[https://incoseonline.org.uk/Program_Files/Store/Default.aspx?CatID=Store link]
 +
|-
 +
|Part 4, Transitioning to MBSE, in A Practical Guide to SysML, the Systems Modelling Language, 2nd edition, Friedenthal, Moore, Steiner, Morgan Kaufman Elsevier, 2012 
 +
|Although the book itself focusses on SysML the modelling language, this Part has chapters exploring the role of the 'systems model' wrt other models, the use of tools and information flows between tools, and data exchange. It also looks at deploying SysML into an organisation, as part of a Improvement Process.
 +
|[https://www.amazon.co.uk/Practical-Guide-SysML-Modeling-Language/dp/0123852064 link]
 +
|-
 +
|Introducing MBSE by using Systems Engineering Principles, Jonas Hallqvist and Jonas Larsson, 26th Annual INCOSE International Symposium (IS 2016) Edinburgh, Scotland, UK, July 18-21, 2016
 +
|Describes one way to introduce MBSE in a company, in an aerospace context. After success on an initial pilot stody, adoption on a much large project was attempted, but stalled due to a number of issues. A systematic approach was adopted to understand all aspects of the transition to MBSE from the current situation: processes affected, incremental small steps, coordination, risk analysis, training. Subsequently a re-focus on systems engineering principles, including clarity on systems engineering purpose: describe different views of the systems architecture and design by using SysML in a modelling tool. Subsequently producing a model of their (MBSE) modelling environment, its capabilties, and its emergent properties (for instance, support for creating training material for the chosen method). A useful conclusion with many lessons-learned including: adopt holistic view to the change; keep focus on the why-change; think big, start small, evolve; prototype change, but beware scaleability; address all stakeholders; involve people that have gone through change before; ensure good leadership; form an effective commucation plan.
 +
|[http://onlinelibrary.wiley.com/doi/10.1002/j.2334-5837.2016.00175.x/pdf link]
 +
|-
 +
|Getting Started with MBSE in Product Development, Nichole Kass and James Kolozs, 26th Annual INCOSE International Symposium (IS 2016) Edinburgh, Scotland, UK, July 18-21, 2016
 +
|Prompted by concern about the complexity of default underlying MBSE schema, the authors developed a simplified schema that underpinning basic V lifecycle systems engineering processes, and cross-cutting concepts (traceability, definitions, documents, issues). The authors explain aspects of this simplied schema and its relationship to supporting systems engineering processes, and how even on larger, more complex projects, they adopt and then refine and extend this schema required for the specific project.
 +
|[http://onlinelibrary.wiley.com/doi/10.1002/j.2334-5837.2016.00176.x/pdf link]
 +
|}

Latest revision as of 17:54, 17 October 2020

Contents

[edit] Overview and the 6 W's

The current active thinking of the MBSE Adoption Guide structure is that it is based on 6 key questions, and from the perspectives of at least two stakeholders with respect to MBSE:

  • An individual systems engineer;
  • An engineering manager (with responsibility for a project, or organisational unit/department/function).

Current generic questions are proposed to be (JJ - have deliberately re-ordered to bring Why to top):

  1. Why should I adopt MBSE?
  2. What does MBSE mean for my role?
  3. Where (activity area, disciplines, level of decomposition etc.) do I employ MBSE?
  4. When (temporal e.g. life cycle phase, criteria) should MBSE be employed?
  5. Who else needs to participate in, or will be impacted by the use of, MBSE activities?
  6. How do I make use of MBSE on my project?

[edit] Latest status

A Version 0.4 was evolved through to late 2017 and made available both in wiki and pdf formats (broadly identical). This went through a conventional review process, leading to a version v0.5 being produced (captured offline by JJ) which addressed many (although not all) of the comments and suggestions made. The initial version of the Adoption Guide now available on the wiki is that same v0.5 - however as authors update and extend that text on the wiki, it will, of course, deviate from the (JJ) baselined version.

[edit] Previous Reports

[edit] Case Studies

This section lists details of any case studies of application of MBSE, or adoption of MBSE, with appropriate supporting information, where that can be made available.

(to be populated).

[edit] FAQ

This section will evolve to contain frequently asked questions about MBSE and its adoption, with responses, supported by references where possible.

(to be populated).

[edit] Related Material

Links to external and/or INCOSE materials relevant to MBSE Adoption.

Note: Some of the links below may only be accessible to INCOSE members, and you may need to login to INCOSE Connect to access.

Reference Relevance Link
Don't Panic - The Absolute Beginner's Guide to Model_based Systems Engineering, Jon Holt and Simon Perry,INCOSE UK ltd, 2017 As the book back cover states: "(This book) aims to provide an honest, straightforward and simple introduction to the world of MBSE that almost anyone can understand." A short (~50 pp) book that does a quick gallop through MBSE: history, modelling (concept of), language (of modelling), art of (modelling), implementing MBSE, and best practice. Littered with sweet little handy icons for: pitfalls, myths, key concepts and benefits. link
Part 4, Transitioning to MBSE, in A Practical Guide to SysML, the Systems Modelling Language, 2nd edition, Friedenthal, Moore, Steiner, Morgan Kaufman Elsevier, 2012 Although the book itself focusses on SysML the modelling language, this Part has chapters exploring the role of the 'systems model' wrt other models, the use of tools and information flows between tools, and data exchange. It also looks at deploying SysML into an organisation, as part of a Improvement Process. link
Introducing MBSE by using Systems Engineering Principles, Jonas Hallqvist and Jonas Larsson, 26th Annual INCOSE International Symposium (IS 2016) Edinburgh, Scotland, UK, July 18-21, 2016 Describes one way to introduce MBSE in a company, in an aerospace context. After success on an initial pilot stody, adoption on a much large project was attempted, but stalled due to a number of issues. A systematic approach was adopted to understand all aspects of the transition to MBSE from the current situation: processes affected, incremental small steps, coordination, risk analysis, training. Subsequently a re-focus on systems engineering principles, including clarity on systems engineering purpose: describe different views of the systems architecture and design by using SysML in a modelling tool. Subsequently producing a model of their (MBSE) modelling environment, its capabilties, and its emergent properties (for instance, support for creating training material for the chosen method). A useful conclusion with many lessons-learned including: adopt holistic view to the change; keep focus on the why-change; think big, start small, evolve; prototype change, but beware scaleability; address all stakeholders; involve people that have gone through change before; ensure good leadership; form an effective commucation plan. link
Getting Started with MBSE in Product Development, Nichole Kass and James Kolozs, 26th Annual INCOSE International Symposium (IS 2016) Edinburgh, Scotland, UK, July 18-21, 2016 Prompted by concern about the complexity of default underlying MBSE schema, the authors developed a simplified schema that underpinning basic V lifecycle systems engineering processes, and cross-cutting concepts (traceability, definitions, documents, issues). The authors explain aspects of this simplied schema and its relationship to supporting systems engineering processes, and how even on larger, more complex projects, they adopt and then refine and extend this schema required for the specific project. link
Retrieved from ‘http://www.incosewiki.info/Model_Based_Systems_Engineering/index.php?title=MBSE_Adoption_Guide&oldid=1072’

Model Based Systems Engineering Wiki

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox