Are you modeling? Are the models you design more than diagrams? Perhaps the models are visual aids, the specifications, the interfaces or, via a click of a button, the production software used in your system. This mode of work falls under the umbrella of Model Based Systems Engineering (MBSE) and is something I recently dove into. In this blog entry I want to share a survey of MBSE as I see it based on my research and reading the past several months.
What is Model Based Systems Engineering? (MBSE)
The MBSE initiative project site provides the following citation and definition:
The INCOSE SE Vision 2020 ( INCOSE-TP-2004-004-02 September, 2007) defines Model-based systems engineering (MBSE) as “the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. MBSE is part of a long-term trend toward model-centric approaches adopted by other engineering disciplines, including mechanical, electrical and software. In particular, MBSE is expected to replace the document-centric approach that has been practiced by systems engineers in the past and to influence the future practice of systems engineering by being fully integrated into the definition of systems engineering processes.”Applying MBSE is expected to provide significant benefits over the document centric approach by enhancing productivity and quality, reducing risk, and providing improved communications among the system development team.
Source: MBSE Initiative project site
Examples of what an MBSE approach may look like are below. The important points include (1) models are intrinsic steps in the process, (2) may take different forms based on the domain and lifecycle stage, and (3) models relate to other models.
All I need is a tool, right?
A tool will get you started, but a modeling tool is really only part of a model based approach.
It is comparable to thinking “all I need to make an App is Visual Studio, right?” While Visual Studio provides a means to build an application it does not provide a holistic software engineering solution covering topics such as version control, bug tracking and continuous integration. Clarifying up front why you want to make an app along with what it needs to do, who will use, test, and maintain it, are all decisions to clarify up front to ensure there is rationale to choose Visual Studio as the IDE.
At one point I was investigating tools that supported SysML, a particular modeling notation, and came across a page with a quote I think is appropriate here from Systems Engineering MBSE’ler Tim Weilkiens:
“There is no “best sysml modeling tool”. The best tool for project A is another than the best tool for project B. It depends on the different requirements of the projects.”
Source: Popular SysML Modeling Tools, Weilkiens, list.ly
Along my MBSE journey I created a modeling mind-map showing topics in the domain of modeling. Tools are just a part of the mind-map. Other topics include techniques, standards, simulation, transformation and notations. There is more, these are just the topics I made time to jot down.
So, a tool will get you started. But its not really about the tool, its about knowing what goals you want to achieve and if a modeling tool/solution has the capabilities to get you there.
No more documents?
Documentation typically still has value and the question is more about how is the model incorporated into stakeholder valued documentation with low cost (i.e. push of a button).
There you have it. A survey of MBSE with visual aids to highlight what it may look like and references from organizations and people doing it.