EN 
DE A maturity model for model-based systems engineering
Authors: Dr. Maximilian Junker, Qualicen GmbH, Prof. Dr. Andreas Vogelsang, Dr. Wolfgang Böhm, Technical University of Berlin
Contribution – Embedded Software Engineering Congress 2017
Many companies want to manage the increasing complexity of their products and the rising demands for reusability and cost-efficiency by using model-based approaches. However, implementing these approaches presents a significant challenge for the organization, one that cannot and should not be accomplished all at once. In this article, we present a maturity model specifically tailored to the phased implementation of model-based systems engineering (MBSE). The model takes into account the specific circumstances of the company.
introduction
In software and systems development, we are increasingly confronted with networked and highly complex systems. The traditional, document-centric approach to developing and describing such systems is no longer able to handle this complexity. The document-centric approach also reaches its limits in terms of reusability and the ability to manage a large number of variants. Model-based systems engineering (MBSE) promises a solution to these challenges. By replacing documents with comprehensive system models in which system parts (e.g., functions and components) are explicitly represented as models and dependencies are also consistently modeled, the complexity of large systems can be managed. Unlike plain text, model elements with clearly modeled interfaces can be reused more easily and reliably. Finally, models enable advanced quality assurance techniques, such as simulation. Errors and inconsistencies can thus be identified and corrected early on. Overall, MBSE promises a reduction in development costs, an acceleration of development time (e.g., through simpler and faster quality assurance), and an increase in quality.
The path to implementing MBSE is often fraught with challenges. New methods and tools must be established, and processes must be adapted for MBSE. Furthermore, MBSE implementation places significant demands on change management within an organization. A sudden, comprehensive MBSE rollout is therefore often neither feasible nor advisable. Even with a step-by-step approach, numerous questions arise: Which areas (e.g., requirements, functions, architecture) should be integrated into an MBSE methodology first? What content should be captured in the models, and at what level of detail? Which modeling techniques are suitable for this purpose?
Maturity models provide guidance by outlining a roadmap for incremental improvement. However, general frameworks such as CMMI or SPICE are often unsuitable for implementing MBSE, as they are too generic and frequently too cumbersome. Therefore, we propose a maturity model specifically tailored for MBSE implementation. This model allows organizations to define their MBSE objectives and measure their current MBSE capabilities. By comparing the current state with the target state, the model allows for the derivation of concrete steps (e.g., the implementation of specific methods) that an organization can address next.
Our maturity model is based on the Focus Area Maturity Model (FAMM) [1], a generic method for developing maturity models with a focus on incremental implementation and improvement. In the specific design of the model, we refer to the SPES approach [2], a comprehensive approach to model-based software and systems engineering. However, the maturity model itself is generic and not dependent on the use of SPES.
This article first provides an overview of the structure and content of the maturity model. We then discuss its practical application in maturity assessment. Finally, we describe our experiences using the model in practice and report on the challenges encountered.
Overview of the maturity model
The core element in the MBSE maturity model is Capabilities (German skills). A capability describes an ability that can be achieved through the use of models and model-based techniques. An example of a capability in our model is "The relationship between requirements and system functions is modeled." Capabilities are always described independently of a specific modeling language (e.g., SysML) and can be implemented using various specific modeling techniques. Capabilities can build upon one another; that is, one capability can be a prerequisite for another.
Focus Areas Capabilities are summarized and describe a field or activity within the MBSE framework. System Function Modeling is an example of a Focus Area. Within a Focus Area, capabilities are ranked according to their MBSE maturity by assigning them maturity levels. The maturity levels of the capabilities never conflict with dependencies. Therefore, if one capability builds upon another, it has a higher maturity level.
Focus areas will be discussed in Engineering Functions In summary, the engineering functions in our maturity model correspond to the views of a system as described, for example, in SPES, and include context analysis, requirements, system functions, and several others.
Engineering Functions, Focus Areas, and Capabilities together form the MBSE Maturity Matrix. Within this matrix, the Focus Areas, grouped by Engineering Functions, form the rows, and the maturity levels form the columns. The individual Capabilities are arranged within the cells of the Maturity Matrix.
It is important that the maturity model can and should be adapted to the specific situation within an organization. For example, if certain focus areas are not relevant for an organization within the framework of MBSE (e.g., testing), these parts of the model can be omitted.
Fig. 1 (see. PDFFigure 1 shows an example of a generic, unadapted maturity matrix. It illustrates that, for instance, the Engineering Function Context Analysis includes two focus areas. The first of these, Operational Context, defines seven capabilities (AG).*. The capabilities are assigned ascending maturity levels. The empty cells in the matrix arise because capabilities that depend on another capability always have a higher maturity level than the capability they depend on.
Derivation of an implementation strategy using the MBSE maturity model
We use the MBSE Maturity Model to determine an MBSE implementation strategy. Our approach is illustrated in Figure 1. 2 (see. PDFAs a first step, we conduct one or more initial workshops with the key MBSE stakeholders within an organization. Typically, one to three people from a development team participate in each workshop, representing several of the engineering functions (e.g., requirements engineering, functional development, software development, etc.).
An initial workshop is based on a questionnaire derived from the Maturity Model. For each capability in the model, the questionnaire includes a description and an example of a possible concrete implementation. During the workshop, participants use the questionnaire to review all capabilities and document whether each capability is implemented in the area under investigation (e.g., department or team). They also have the option to indicate that a capability is not relevant to their organizational area or that they are unaware of it. The information gathered in this way reflects the current state of the area with regard to the use of model-based techniques.
In addition to identifying currently existing capabilities, the workshop will determine the organization's goals regarding the implementation of MBSE. These goals are usually at a significantly higher level of abstraction than the capabilities themselves. One example of a goal we identified in a previous interview is supporting "digital integration," meaning that the models themselves allow for comprehensive statements about the interaction of system components. Another, more concrete goal would be, for example, greater reuse in the description of technical components (e.g., sensors).
In a second step, the workshop results are mapped onto the Maturity Matrix. This means, firstly, that the existing capabilities are entered into the matrix. Secondly, the identified goals are mapped to the capabilities necessary to achieve them. These goal-related capabilities are also entered into the matrix. The result of this step is a completed Maturity Matrix that reflects the organization's current capabilities and goals.
In the next step, an analysis is conducted based on this information. We determine where discrepancies exist between existing capabilities and objectives, or where they currently overlap. Furthermore, we identify gaps where the necessary prerequisites for existing capabilities are lacking. Finally, we identify quick wins. These are situations where only a few capabilities are missing to achieve the organization's objective (or a key milestone), but these missing capabilities represent a significant step towards achieving the objective.
Both the matrix itself and the specific improvement suggestions are subsequently validated and discussed with the organization in a further workshop. During this workshop, we develop a roadmap that describes which of the capabilities necessary for achieving the goal should now be developed step by step. Often, the identified quick wins provide a good starting point. Furthermore, the dependencies defined in the maturity model help in creating the roadmap.
Experiences from practical application
In this section, we report on our experience with the MBSE maturity model from initial industrial applications. In particular, we focus on the challenges we encountered during its application.
A major initial obstacle to applying the maturity model is often the terminology. Terms like context, function, component, scenario, and similar concepts are not standardized and are used differently in various organizations (sometimes even within different teams of the same organization). However, a consistent understanding of the core concepts is essential for a meaningful assessment of the current state and the objectives. To address this issue, we have included concrete examples in the questionnaire to give interviewees a better understanding of capability. Furthermore, we recommend preparatory workshops that include, among other things, a clarification of the terminology.
A second problem is that the current state analysis is primarily based on interviews. The responses don't always reflect the actual situation. Instead, wishes and plans are often included, even if these haven't yet been implemented. It's advisable to base the responses on concrete examples or validate them using development artifacts. It's also helpful to conduct interviews with several people from the same organizational unit and compare the results.
In practice, we frequently encounter situations, particularly in larger organizations, where significant differences exist within the organization itself. These differences relate both to objectives (different departments have different problems they want to address with MBSE) and to existing capabilities. Therefore, it is difficult to create a single, unified picture. However, this is also a strength of the method, as it allows for the separate analysis of situations in different departments and, consequently, a more nuanced adaptation of the roadmap to individual parts of the organization.
Summary
Based on the observation that the introduction of model-based systems engineering (MBSE) must be a gradual process, we have presented a maturity model in this article to support the implementation of MBSE. The maturity model is based on the definition of Capabilities, This model defines the capabilities an organization can achieve in relation to MBSE. It helps identify the specific capabilities that must be developed to achieve an organization's goals. Together with the organization, a roadmap for implementing MBSE can then be developed. In practice, we encounter several challenges. We describe the most significant challenges and discuss possible solutions.
Bibliography
| [1] | M. van Steenbergen, R. Bos, S. Brinkkemper, I. van de Weerd, and W. Bekkers, „The Design of Focus Area Maturity Models,“ in DESRIST 2010, 2010. |
| [2] | K. Pohl, H. Hönninger, R. Achatz and M. Broy, Model-Based Engineering of Embedded Systems. The SPES 2020 Methodology, Springer, 2010. |
Software Engineering Management – our training courses & coaching sessions
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Software Engineering Management / process, project and product management.
Training & coaching on the other topics in our portfolio can be found here. here.
Software Engineering Management – Expertise
Valuable expertise in software engineering management / process, project and product management is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
