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.
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.
Details
Individual Systems Engineer
Why should I adopt MBSE?
(elaborated response)
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)
