In my previous posts, I explained how simulation models and architectural models are merging, and how this is foundational to an Agile, model-based approach to developing complex systems. Another important step to enabling model-based systems engineering (MBSE) is to convert from a document-based approach.
While systems engineers have played a unique role to date in overseeing entire complex systems being designed, the goal is to democratize this ability. After all, numerous people are involved in bringing complex systems to market, from systems engineers and software developers to project managers, procurement, and manufacturing.
As organizations make the shift to MBSE, they must embrace a strategic approach to ensure success. Here are practical steps they can take to make this vision a reality.
Invite Others to Participate
As more stakeholders manage tasks concurrently to support the design ad manufacture of complex, connected systems, they need to understand how to work within a model-based approach. As they put in place a construct to support all stakeholders, organizations should consider the following:
This consideration has to be in line with the processes the organization is obligated to follow. This might include safety norms (e.g., DO178B/C, ISO26262, IEC61508, or others, depending on the domain), process norms (e.g., ISO12207, ISO15288, ISO2655x) or process maturity levels, like SPICE, A-SPICE, or CMMI. The roles involved in introducing the processes and ensuring that projects follow the rules are the best fit to look after the MBSE-relevant roles and their needs. That’s because more and more of these norms recommend or require model-based approaches.
Then the organization should educate and train all participants on the approach and their roles. This includes defining the following:
As organizations start down this path, it’s important to keep in mind that those outside of design engineering can be intimidated by the complexity of today’s systems and systems engineering methodologies. Only certain stakeholders in the process need to see how all elements link together. In fact, some stakeholders (such as customers) should not see everything involved in the system as organizations must protect their intellectual property.
To ensure people only see what is absolute necessary, organizations should take the following measures:
Rather than expose all the options of the language in use, organizations should define who is responsible for what and what types of artifacts, elements or links are part of that responsibility by role. Instead of giving everyone access to everything in the model, they can supply role-based apps that enable people to access all needed information while ensure they are handling the right tasks using the right data.
Those involved in the project that want to see how requirements are handled in the architectural model could access the requirements, which links into specific perspectives of the model. For example, they could see use cases, functional requirements, and context diagrams for interface requirements. Or someone responsible for the product portfolio could access the variability model and create logical connections between functions but not see how the options are linked into the system model or product family model.
Everyone should play their role in building up the organization’s systems engineering methodology so it does not all rest on the shoulders of a few systems engineers. Organizations can take these steps to make the necessary MBSE-related knowledge and resources accessible to all team members so that they are equipped and empowered to participate.