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. Any items which are explicit about potential content (as distinct to characteristics it should exhibit, like useability, credibility, etc.), are highlighted in bold. If there are significant points missing, please edit this page and its table content to correct.
| Date created | Topic title | Content summary, especially if relevant to content |
| 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 how aligned with ISO 15288. |
| 16/7/2015 | Moving Forward | Discussions: refinement to above framework, competency, 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), paraphrase of response from JJ “good points, apparently confusion over stakeholders?”, incorporate MBSE during bid phase. |
Note that there are also potential content suggestions summarised in MBSE_Omega_Guide, from the Teamstorming session, (see summary table) again highlighted in bold.
Overview and the 6 W's
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, or will be impacted by the use of, MBSE activities?
- How do I make use of MBSE on my project?
A graphic illustrating this outline is available on the MBSE.org site here: 6-questions poster draft
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 of 6 W's and responses
Individual Systems Engineer
Why should I adopt MBSE?
As an engineer, adopt MBSE because:
- MBSE is an growing dominant approach to systems engineering, in constrast to conventional document-based 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 involving much drudgery (manual checking, consistency checking...) associated with the document-centric approach to engineering as an intellectual challenge;
- systems engineers with MBSE experience are likely to be increasingly marketable than those without.
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.
Rationale
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.
What does MBSE mean for my role?
For you as an individual systems engineer it means:
- Ensuring your involvement and adoption of MBSE aligns with your organisation's strategy; it may mean you follow that strategy, or that you play a key role in defining it...;
- Ensure you understand the approach and principles of MBSE;
- Browse the various tutorials and documentated case studies available online (see elsewhere in INCOSE UK, and INCOSE.org for links - refine to include links here)
- Gain access to at least one of the tools that support MBSE - there are both COTS and open source tools available - and experiment in a sandbox;
- Connect to the local community of other MBSE systems engineers, via your organisation and/or INCOSE;
- Consider commercially available training for MBSE (note this can be 'badged' as 'SysML for MBSE' or some such;
- build up experience incrementally.
Rationale
Aliging what you do as an individual with your organisation's approach is important, since the majority of benefits from MBSE only come from the sharing of common information around a systems model - and possibly other models related to that model. Such sharing could be across 2 or more systems engineers, across systems engineers and other engineering disciplines, or across engineering and non-engineering disciplines (project management, commercial, product support, procurement...).
Becoming proficient in performing systems engineering in a model-based way requires a combination of awareness and education, and practical hands-on use. It also helps greatly to work with others who have either come up the learning curve, or at least are also going up it. Bear in mind that MSBE is still systems engineering!
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?
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
This section lists details of any case studies of applicaiton of MBSE, with appropriate hard information, where that can be made available.
(to be populated).
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).
