The greatest value from MBSE in design lies in the modeling playing an integral role in the process of design, helping mere mortals design with early prevention and detection of errors leading to reduced errors in the implementation. So for the same degree of product assurance, the optimum amount of verification of the implementation is reduced if MBSE has been used as a design tool. Beyond the reduced likelihood of design error if model-based design is performed, the average cost of detecting an error in logical design is lower than the average cost of detecting the same error by software testing. The ROI, already good, is dramatically increased when the average cost of errors that go undetected in software testing is added.

All of the above is predicated on the MBSE being based on sound design processes, using a logically sound MBSE language that provides for rigorous mapping of logic onto implementation.

So a way to maximise the MBSE ROI is to emphasize verification of design models, enabling a reduction in the amount of software testing that would otherwise be needed to achieve the same degree of product assurance.

The other aspect of MBSE is constructed simulations, where the simulation and the design are in different languages. These need a LOT of V&V, because the opportunity for undetected errors in the simulation is a lot higher than with formal logical design mapped to implementation. A case to illustrate the point is a theater missile defense program on which much of the design work was based on the results of constructed simulation using a particular simulator that had never been validated, and turned out to be riddled with bugs. Failures in test came close to killing the project, and the system failed subsequently in operational use provide the protection sought.

• using MBSE without a sound underlying design process
• loosing sight of the mail purpose of MBSE in design, which is to help us get the implementation right
• using inadequately verified and validated constructed simulations.