Omega WIP page
Omega Team Reference material (source)
The majority of the material is actually on Alex's mbse.org site, specifically at this link, for those registered for the site:
A summary of the material and discussions on that forum appears in the table below, for easy reference. If there are significant points missing, please edit this page and its table content to correct.
| Date created | Topic title | Content summary |
| 5/5/2015 | Summary of Omega Men Session at WG Meeting 23/04/15 | Notes of meeting. Diagram of aim or post guide awareness: pre-Guide vs post-Guide awareness, both axes competency levels.
Thoughts about guide contents: case studies, languages, applicability of MBSE to specific project. Reference to alignment with ISO 15288. |
| 16/7/2015 | Moving Forward | Discussions: refinement to above framework, UKSPEC (yes, no), that MBSE is ‘not new’, stakeholders (inc system engineer, engineering manager) and use case diagram. |
| 21/10/2015 | 2015 10 20 Omega Group mtg Bham | Notes of meeting. Emergence of the Why / when / where / who / how structure, MBSE vs 15288 outcomes, other stakeholders?, reference to PM and RACI framework, benefits and challenges. |
| 7/11/2015 | MBSE Question | Summary of the 6 questions from Engineer / Eng Manager perspectives, suggestion common questions vs any stakeholder, pointer to OmegaProgress slideset at ASEC (inc slide 9 “how you can contribute”: 3 questions to MBSE WG participants), details of one response to presentation (8 paras), response from JJ “good points, apparently confusion over stakeholders?”, incorporate MBSE during bid phase. |
Overview
The current active thinking of the Omega 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):
- Why should I adopt MBSE?
- What does MBSE mean for my role?
- Where (activity area, disciplines level of decomp) do I employ MBSE?
- When (temporal e.g. life cycle phase, criteria) should MBSE be employed?
- Who else needs to participate in MBSE activities?
- How do I make use of MBSE on my project?
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. In terms of organisation of the material on the wiki, it may be appropriate that each of these two sections is migrated to their own pages, as the content grows.
Details
Individual Systems Engineer
Why should I adopt MBSE?
In recent years there has been a trend for all engineering disciplines to have tools that support the engineering work (design, analysis, visualisation) that use underlying models of the concepts in that domain. For instance, structural design moved from physical draughting drawings, to electronic versions of drawings, then to models of structures that could be re-rendered with plan, elevation views analogous to drawings. However such tools support other capabiliies, for instance, perspective projections of the structures, where the view can be dynamically rotated, assisting understanding. Arguably systems engineering is the last engineering discipline to see this trend to model-based approach adopted. It is becoming clear that model-based systems engineering will be a necessary competency for systems engineers now and into the future. In summary, as an engineer, adopt MBSE because:
- MBSE is an growing dominant approach to systems engineering;
- MBSE will enable you to perform many if not all systems engineering activities more effectively than you would otherwise do;
- MBSE shifts work from much involving drudgery (manual checking, consistency checking...) associated with the document-centric approach to engineering as an intellectual challenge.
But for an individual engineer, adopting MBSE has its challenges:
- it does require you to 'get your head around a model-based approach';
- it will require you to become familiar and proficient with an appropriate modelling notation (such as SysML) and at least one associated tool;
- it is unlikley to be an approach that you can adopt solo - an appropriate subset of an organisation (a research group, a project team, a functional department) needs to adopt MBSE as a way of doing business.
What does MBSE mean for my role?
(elaborated response)
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?
(elaborated response)
An engineering manager
Why should I adopt MBSE?
(elaborated response)
What does MBSE mean for my role?
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?
(elaborated response)
