Systems Engineering Your MBSE Deployment by David Long
Ғылым және технология
Model-based systems engineering is many things. It is architecture and analytics. It is communication and engineering. It is methods and tools. Fundamentally, it represents a change in technique and fidelity for systems engineering and those who practice it. The one thing that MBSE is not is one size fits all.
As individuals and organizations deploy MBSE, they fall into several traps. Many believe model-based systems engineering to be a tool or technical problem. While there is certainly a technical dimension and selecting the proper tool for the problem and process is key, the adoption of model-based systems engineering is far bigger. It is technology, people, training, and change at an individual, project, and potentially organizational level.
If we practice what we preach and bring a systems engineering approach to deploying MBSE, we can fundamentally change the impact and increase the likelihood of success. Assessing the environment and drawing the system boundary…defining the scope, eliciting requirements, and identifying constraints…considering behaviors and deploying the solution - all are critical to defining the right problem and solving the problem right. All are key in avoiding many of the traps along the way. Building upon good systems engineering practice and practical lessons learned from deployments across industry - some successful, some challenged - we can identify best practices going forward as we continue to apply and advance systems engineering within our organizations.
Пікірлер: 3
At about 30 minutes, Mr. Long talks about having control within our own system, but needing to make it easy for different external players by (what I take as) subscribing to their interfaces and building our system to those needs/requirements/specs. I'm having difficulty determining where the reciprocity occurs therein. If they change their interface, or outward facing stuff, we will likely need to change our interface that faces them. Why should they not change for us? Of course we want to be successful and maybe turn that other cheak. But wouldn't a healthy level of Quid Pro Quo be desireable? How do we go about designing systems that, under the worse circumstances, don't force stagnation because of inflexiblity at the interfaces?
@davidlong3623
5 жыл бұрын
In fresh design, interfaces are certainly up for negotiation between subsystems and teams. When re-engineering a system, we must either comply with existing interfaces or make an additional investment to change an interface. In the context of trying to deploy MBSE (which is re-engineering the engineering system as we seek to change the processes and systems in use), the objective is to bound the change. If when deploying a new process, we change the interface to others - either in the content provided or in the format - we include them inside the change boundary. If those impacted see the value of the change and are consulted as part of the change process, they may support the change or at least be neutral. All too often, this isn't the case and we accidentally "inflict" our change on others. If they are not engaged in the change process and don't see the benefit, they resist. Too much resistance will kill any change initiative no matter how good the change is. So when introducing a change - particularly one like MBSE which deals with how we represent, manage, and analyze information - the challenge is to draw the change boundary large enough to contain the change agents and deliver benefits while remaining small enough to avoid triggering too much resistance. The boundary can then be slowly expanded.
@RT-ym9us
5 жыл бұрын
That's very helpful and great to hear, thank you Mr. Long!