Difference between revisions of "MBSE Omega Guide - 6 Honest Serving Men"

From Model Based Systems Engineering Wiki
Jump to: navigation, search
Line 18: Line 18:
 
The rest of this material is organised around the '6 Wise Men' questions, as illustrated below.
 
The rest of this material is organised around the '6 Wise Men' questions, as illustrated below.
  
[[File:MBSE_Adoption_6_W_graphic.jpg]]
+
[[File:MBSE_Adoption_6_W_graphic.jpg | 500px]]
  
  

Revision as of 09:07, 18 September 2017

Notes: Please see the Discussion tab for supporting comments. You are currently looking at a web version of the guide - there is also a pdf version, similar to existing Omega Guides, the current draft here.

Contents

Overview

Model-Based Systems Engineering (MBSE) is the formalised application of modelling to support:

■ System requirements

■ Analysis

■ Design

■ Verification & Validation

beginning in the conceptual design phase and continuing throughout development and later lifecycle phases. (INCOSE). It contrasts with DBSE Document Based Systems Engineering where the primary artefacts of system engineering activities are documents. Establishing an understanding of, and adoption of, MBSE by individual systems engineers, systems engineering teams and organisations who apply systems engineering are non-trivial. This is an introductory Guide intended to assist individual systems engineers and organisations contemplating or travelling along the path of MBSE adoption. For elaboration of what MBSE is, the reader is referred to the INCOSE UK Z Guide Z9 'Model-Based Systems Engineering'. The rest of this material is organised around the '6 Wise Men' questions, as illustrated below.

MBSE Adoption 6 W graphic.jpg


Why should I adopt MBSE?

There is a steady trend in the systems engineering community to move from conventional or document-based systems engineering (DBSE) to model-based systems engineering. For both systems engineers and engineering managers, it will require you to understand MBSE philosophy, benefits, how you work within an organisation and team members using MBSE, and (for systems engineers) the use of practical 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 a systems engineer, adopt MBSE because (for rationale on wiki see Systems Engineer MBSE why rationale):

  • 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.

For an engineering manager, adopt MBSE because (for rationale on wiki see Engineering Manager MBSE why rationale):

  • 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.
  • 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?.

What does MBSE mean for my role?

For you as an individual systems engineer it means (for rationale on wiki see Systems Engineer MBSE what rationale):

  • 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;
  • You have exploited the various tutorials and documentated case studies available online (see elsewhere in INCOSE UK, and INCOSE.org for links - refine to include links here)
  • Gaining 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;
  • Connecting to the local community of other MBSE systems engineers, via your organisation and/or INCOSE;
  • Considering commercially available training for MBSE (note this can be 'badged' as 'SysML for MBSE' or some such;
  • building up experience incrementally.

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!

For an engineering manager, it will mean the following (for rationale on wiki see Engineering Manager MBSE what rationale):

  • 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;
  • Identifying, and sharing learning experience, with other non-SE stakeholders in your organisation, both positive and less-positive;
  • Considering support and resources to run small MBSE trials, or engage with other parties (such as academia) who might be running such trials;
  • Establishing a migration strategy, addressing: training, tooling, infrastructure, processes, internal and external stakeholders affected;
  • Establish a migration plan to implement your adoption strategy;
  • Obtaining resources and funding to support the execution of the plan;
  • Monitoring and course-correcting as necessary.

Where (activity area, disciplines, level of decomp) do I employ MBSE?

This is interpreted as “In which systems engineering activities should I employee MBSE?” and could be addressed from two perspectives:

  • A systems engineering practitioner (The person responsible for the work)
  • A systems engineering manager (The person accountable for the work)

Responsible and accountable and are used here in the same sense as in a responsibility assignment matric (RACI).

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-Centric (DCSE) one.

The choice of whether an activity should be Model-Based or Document-Centric (the assumption being that these are the only two approaches available) should be based on the perceived costs/benefits and risks of each. These considerations can be categorised in relation to the three elements required to successfully implement MBSE / DCSE, namely people, processes and tools.

Additionally, it is important to consider the flow of information between stakeholders and activities, and between two sequential activities, since the complexity introduced due to any change in approach may be prohibitive. In all these discussions it is assumed that all stakeholders who need to create or consume a particular artefacts have an adequate understanding of the languages used. To consider otherwise would be equivalent to proposing to do SE in French when none of the project team speak French. A taxonomy has been explored considering the generic transfers of information between the three key elements within MBSE / DCSE, namely:

  • The human stakeholder (engineer or engineering manager);
  • Document
  • Model

Regardless of the specific SE activity, a view of Effort (cost) versus Effectiveness can provide simple insight into the type of transfer. An elaboration of this Effort/Effectiveness is available on the wiki MBSE Where effort effectiveness page. A complementary perspective of where MBSE can be employed with respect to a subset of ISO 15288 Processes will be produced in a subsequent document; likely processes to be covered will include: architecture definition process; Business or Mission analysis process; integration process; stakeholder needs and requirements definition process; system analysis process; system requirements definition process; validation process; verification process.

When (temporal e.g. life cycle phase, criteria) 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. However, many legacy and current projects may already have extensive information in conventional document-based forms. The recommendation is to look for opportunities to incrementally convert parts of an existing information set (requirements, architctures) to models, and where necessary move to conventional forms being part-generated from the corresponding models.

Who else 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.

An Engineering Manager, with responsibility for the engineering activity and the engineering content of a system developed using an MBSE approach needs to be aware of and manage people, process and technology, aligned to the needs of the business.

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 of Systems Engineering Engineer; Support Engineer; Systems Engineer / Architect.

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

How do I make use of MBSE on my project?

You use an MBSE approach to:

  • 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;
  • reduce cost and effort of impact of change analysis;
  • make the best use of skilled engineers.

This topic is further elaborated on the wiki in how to use MBSE.

Support info

This leaflet is intended as a working guide to adoption of MBSE.

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 leaflet 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

Back to Main page

Model Based Systems Engineering Wiki

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox