View source for MBSE Adoption Guide - v0.5

==Overview==
Model-Based Systems Engineering (MBSE) is the formalised application of modelling to support: 
* System requirements 
* Analysis 
* Design 
* Verification & Validation 
An MBSE approach begins, or can be applied, in the conceptual design phase and continues throughout development and later lifecycle phases. (INCOSE). It contrasts with Document Centric Systems Engineering (DCSE) where the primary artefacts of system engineering activities are documents. 

Adopting MBSE in a mature SE organisation is a non-trivial challenge because it requires a fundamental change to the way Systems Engineers, teams, and organisations think. Adopting MBSE can be organisation- and project-wide. However it can also be adopted incrementally, for instance selectively replacing ‘drawings’ of designs, by views generated from models of designs.

This is an introductory Guide intended to assist individual Systems Engineers and organisations contemplating or travelling along the path of MBSE adoption. 
 
[[File:6_WQ_and_How_much.png | 700px]]

For elaboration of what MBSE is, the reader is referred to the [http://incoseonline.org.uk/Documents/zGuides/Z9_model_based_WEB.pdf INCOSE UK Z Guide Z9 'What is Model-Based Systems Engineering’]. 
This Guide is organised around Kipling's 6 Questions: Why, What, Who, When, Where, How, and an added question How much?

==Why should I adopt MBSE?==

[[File:Cost_quality_risk.JPG |700px]]

There is a steady trend in the Systems Engineering community to move from conventional or document-centric Systems Engineering (DCSE) to model-based Systems Engineering. The drivers for such evolution include:
* Ever-Increasing system complexity, exposing limitations of document-based approaches, and necessitating improved abilities to analyse requirements and design material more effectively;
* Opportunities arising from design automation and solution generation capabilities, rapid prototyping, transformational and 3D printing techniques.
MBSE can:
* introduce (potentially incrementally) more rigour into the way your requirements are expressed and analysed;
* improve architecture structure and behaviour representation and analysis;
* enhance traceability between requirements, architecture, domain-specific models, discipline-based views of emerging designs, and verification and validation information;
* part-automate the generation of conventional document-based representation of Systems Engineering assets;
Adopting MBSE potentially affects many stakeholders involved in systems developments. This guide focusses on two specific roles – Systems Engineer and Engineering Manager – as an illustration of how specific roles are impacted, and to illustrate such variety of impact. Other roles’ impacts are explored elsewhere.

For both Systems Engineers and Engineering Managers, there is a need to understand MBSE philosophy, its benefits, and how to work within an organisation, and with team members, using MBSE.  Systems Engineers will need to understand both the concepts underlying, and the practical use of, formal modelling languages such as SysML and MBSE-enabling tools. The reasons to adopt MBSE will be different depending whether you are an individual Systems Engineer, or whether you are an Engineering Manager.

For an Engineering Manager, adopt MBSE because of benefits to cost, quality, productivity and competitiveness to your organisation:
* Use of models increases early rigour, identifies gaps and inconsistencies, and helps to eliminate errors.
* Helps to facilitate checking across domains and disciplines, and increases the degree to which requirements, design and V&V information can be checked by software, complementing the capabilities and skills of engineers.
* Increases the potential for design re-use.
(for elaboration and rationale see [[Engineering Manager MBSE why rationale]])

For a Systems Engineer, adopt MBSE because of improvements to your work activities, and increased career satisfaction and marketability:
* MBSE will enable you to perform many if not all Systems Engineering activities more effectively than you would otherwise do, for instance, in tackling systems of every-increasing complexity, exploiting tool-supported checking;
* 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 more marketable than those without. 

(for elaboration and rationale see [[Systems Engineer MBSE why rationale]])

==What does MBSE mean for my role?==
The impact of MBSE of different stakeholders varies depending on whether that role involves creation of material (requirements, designs, analysis…) or more simply ‘use’ of that material. Most significantly, creators of material have to take onboard a different mindset, and move from simply writing and drawing diagrams, to building (and using existing) models using appropriate languages and formalisms. 

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...;
* Ensuring you understand the approach and principles of MBSE;
* Practically using the formalisms that support MBSE (for instance, the notations and diagrams of SysML) to build, check and revise requirements and architecture models using appropriate tools;
* Making use of these diagrams and model content, via templates and tools capabilities, to part-generate systems engineering artefacts for review and authorisation. 

(for elaboration and rationale see [[Systems Engineer MBSE what rationale]])

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 MBSE is still Systems Engineering!

For an Engineering Manager, 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 organisation;
* Identifying, considering and potentially challenging information about cost, quality and timescale for Systems Engineering processes using MBSE;
* Changing to reviewing models via views or fragments, increasingly of online artefacts and making use of appropriate review-support tools, and signing off material via electronic signatures;
* Identifying, and sharing learning experience, with other non-SE stakeholders in your organisation, both positive and less-positive; 

(for elaboration and rationale see [[Engineering Manager MBSE what rationale]].)

==Where do I employ MBSE?==
The nature of adopting MBSE on system engineering activities is largely dependent on the users’ perspective: 
* A Systems Engineering practitioner (The person responsible for the work); the focus here is on specific Systems Engineering activities, process areas or subsets of a larger system.
* An Engineering Manager (The person accountable for the work); the focus here is on adoption within a project, or (for an organisation) across projects.

Since “MBSE is an approach to Systems Engineering (SE)” – INCOSE UK Z9 v2.0, the range of potential processes and activities that could employ a Model-Based approach includes all those identified as using a traditional document based-approach. ISO 15288 and the INCOSE SE HB provide taxonomies of process areas and activities, additionally ISO 15288 outlines the system / system-element hierarchy by which subsets of a larger system could be identified for a model-based approach. This topic is elaborated in [[incremental model-based activities]]. 

For the Engineering Manager, there are several distinct strategies that can be pursued to MBSE adoption:
* for a large ongoing project, consider opportunities to migrate the generation of artefacts that may support design reviews from a document-based to a model-based approach. 

[[File:reviews_vs_phase_table.JPG |700px]]

(Specific reviews may be Project-specific, see for instance, figures 3.9 and 3.11 in INCOSE Systems Engineering Handbook, Edition 4, 2017).
* from an organisational adoption perspective, consider opportunities to start small (perhaps research) projects, entirely using MBSE from the first phases (business or mission analysis, stakeholder needs and requirements definition) and subsequently migrate to, or adopt, MBSE on large projects.

[[File:percent_projects_that_use_MBSE_diag.JPG |700px]]

* a third incremental approach is to exploit a model-based approach on individual diagrams within an existing project’s artefacts.

==When should MBSE be employed?==
Ideally the earlier a model-based approach can be adopted, the better, since the benefits (increasing rigour, reduced ambiguity, increased automation support) start to be potentially realised as early as SE information is represented in a model. 

Many legacy and current projects already have extensive information in conventional document-based forms. Where this is the case, it is recommended to incrementally adopt MBSE,  converting parts of information sets (i.e. requirement sets, architectures)  to models and subsequently generating model-derived documentation. 

==Who needs to participate in, or will be impacted by the use of, MBSE activities? ==

A Systems Engineer operates as a member of a team and as such engages with a range of stakeholders to collectively ‘engineer’ a system. Taking an MBSE approach means that these stakeholders also need to participate in MBSE activities associated with their roles and responsibilities. This is important to ensure that the engineering effort is coherent, collectively effective and efficient, to produce a fit-for-purpose engineered system.

Note the impact on some Roles may be slight: if you are reviewing a System or Equipment Specification, it may not matter explicitly that the origin of much of that material (text, diagrams) are derived from an underlying model. The important point is that there will be benefits (e.g. in the integrity of the information set) resulting from the material being model-based.

Listed here are other Roles that a Systems Engineer and / or Engineering Manager may need to engage with: Customer; User; Project Manager; Qualifier / Certifier; Software Engineer; Specialist Engineer; Technical Experts; Capability Systems Engineer; Support Engineer; Systems Engineer / Architect.

[[File:engineers.JPG]]
 
Not listed here but also significant stakeholders are: engineers of other disciplines; basically any *user* of the model's information and any *contributor* to that information, also any *checker* or *approver*

The nature of the level of awareness or involvement for these roles are elaborated further here for [[Systems Engineers other roles]] and for [[Engineering Managers other roles]].

==How do I make use of MBSE on my project?==

MBSE is made use of on a project by: 
* initially establishing the basics of how it will be used as a general approach, establishing awareness and buy-in from affected stakeholders, through to which process areas, activities and project artefacts will be affected; such details are likely to be captured in appropriate project or organisation documents, like the systems engineering management plans, and training materials;
* subsequently performing SE activities following that MBSE approach, creating, validating and reviewing project materials as appropriate. Stakeholders involving in checking and reviewing materials are likely to be affected less in the transition to MBSE since many of the materials they interact with may take the same form as with DCSE; they may having be reviewing models directly online with appropriate tools rather than just reviewing documents. Stakeholders involving in producing and extending models associated with requirements, architecture and design definition and analysis will see a much more significant transition from DCSE to MBSE, as they explicit think ‘system model’.

This topic is further elaborated in [[how to use MBSE]].

==How much will adoption of MBSE cost?==

Expect the ‘cost’ of adopting an MBSE approach to be multi-facetted, and strongly complemented by the benefits of performing SE with an MBSE approach. Costs will include:
* training (awareness to appropriate stakeholders, through to hands-on tool training)
* tool licences (for specific SE capabilities)
* IT infrastructure updates (potential tool-tool interfaces, or adoption of interface standards; generation of Review document subsets through template / Model-Driven Architecture approaches)
* Costs of reworking existing DCSE materials to MBSE-based
* Updates to design maturity and progress indicator mechanisms.

Benefits are summarised in Why should I adopt MBSE?

==People, Process, Tools, Infrastructure==

The primary organisation of this Guide is in terms of the 6 W Questions. However, an alternative framework can be useful, one used by some authors is that of People Process Tools. Infrastructure on large projects can be a significant challenge in its own right so has been added. 
* '''People''' issues ranges from identification of stakeholders, and from simple awareness of MBSE and how that affects different stakeholders, through to training up selected stakeholders with appropriate skills and experience to adapt and exploit MBSE;
* '''Process''' aspect ranges from the higher level lifecycle and process areas selected for MBSE adoption, through to the specific methods and techniques utilised by stakeholders;
* '''Tool''' issues include selection of one or more chosen to support SE activities, through to tool licences (for specific SE capabilities), and support from tool vendor;
* '''Infrastructure''' issues include architecting of SE environment, configuration control, and mechanisms for interoperability between SE tools and those used by all other engineering and management functions, customers and suppliers.
 
These topics are elaborated here…

==Common pitfalls==
This section covers a number of common problems or use cases in failed or fraught MBSE adoption, such as trying to introduce MBSE without the correct mindset, skills, tooling, business support, customer support, basic need.
===Failure within your organisation or project===
Failure to achieve successful traction with MBSE adoption within a project or organisation can arise from:
* Inadequate internal stakeholder engagement and buy-in
* Being over ambitious or not incremental in MBSE adoption
* Insufficient training 
* Inadequate investment in tooling
* Poor motivation, perhaps through lack of understand reasons for adoption, 
* Lack of awareness of successes elsewhere and of avoiding previous mistakes
===Failure with interaction with other organisations or external stakeholders.===
Failure to achieve successful traction with MBSE adoption across organisations can arise from:
* Inadequate internal stakeholder engagement and buy-in
* Being over ambitious in MBSE adoption
* Inadequate consideration of cross-organisation configuration control or heterogeneous tool sets

==Footnotes==
This Adoption Guide is intended as a working guide to the adoption and refinement of a model-based Systems Engineering capability. 
This series of working guides is produced by members of the UK Chapter of INCOSE.
For further information, advice and links to helpful websites go to: www.incoseonline.org.uk
Members can download copies of this guide and other Systems Engineering resources online at: www.incoseonline.org.uk
For more information about the worldwide Systems Engineering professional community, go to www.incose.org
Series editor: hazel.woodcock@uk.ibm.com
Lead author: julian.johnson@holistem.co.uk
©2017 UK Chapter, International Council on Systems Engineering