MBSE Omega Guide - 6 Honest Serving Men

From Model Based Systems Engineering Wiki
Revision as of 10:57, 22 September 2017 by Dr. Julian Johnson (Talk | contribs)

Jump to: navigation, search

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.

MBSE Adoption 6 W graphic.jpg

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.

Why should I adopt MBSE?

Cost quality risk.JPG

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

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.

What does MBSE mean for my role?

For you as an individual systems engineer it means (for elaboration and 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;

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 elaboration and 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.

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); the focus here is on specific systems engineering activities, process areas or subsets of a larger system.
  • A systems 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-Centric (DCSE) one; ISO 15288 and the INCOSE SE HB provide taxonomies of Process Areas and activities. ISO 15288 also outlines the system / system-element hierarchy by which subsets of a larger system could be identified for an model-based approach.

For the engineering Manager, there are two 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;

Reviews vs phase table.JPG

  • from an organisational adoption perspective, consider opportunities to start small (perhaps research) projects, entirely using model-based systems engineering from the first phases (business or mission analysis, stakeholder needs and requirements definition..). Subsequently migrate to, or adopt, MBSE on large projects.

Percent projects that use MBSE diag.JPG

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