Difference between revisions of "MBSE Adoption Guide"
(→Related Material) |
(→Details of 6 W's and responses) |
||
| Line 24: | Line 24: | ||
===[[An engineering manager]]=== | ===[[An engineering manager]]=== | ||
| + | |||
| + | ===Who needs to be aware? (other roles)=== | ||
==Case Studies== | ==Case Studies== | ||
Revision as of 08:42, 27 October 2016
Contents |
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):
- 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.
Details of 6 W's and responses
Individual Systems Engineer
An engineering manager
Who needs to be aware? (other roles)
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).
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).
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 |
|---|---|---|
| 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 |
