Introduction
About five years ago, my organization decided to pilot the introduction of MBSE (Model Based Systems Engineering) on a new project. Two of us had extensive experience modeling software (using the Schler-Mellor methodology and tools) and we hoped that our experience would help us make this major change. But implementation was much more difficult than we anticipated. There were many things we did wrong, and some we did right.
Lessons Learned
Get a really good modeling tool!
Our management was initially lukewarm about using MBSE. They picked a tool for us that they liked because it was free. It was free because it had been developed by the French government as a research project. While functional, it was difficult to install and the user interface made making any sort of diagram very painful. The two of us with software modeling experience were able to get it to work, but all our mental energy was absorbed in trying to get the modelling tool to do what we wanted. We had very little mental energy left over to think about the actual model! Our models were ugly and hard to interpret because the tool provided little in the way of making them pretty and intelligible. No one else made any progress at all, and a couple of people gave up on modeling altogether.
Then we hired a new engineer who recommended a MBSE tool he had used at his previous company. It was a joy to use compared to what we had been using. It was easy to put together charts quickly and rearrange them so that the ideas we were trying to model were visually apparent. When we reviewed the models, we could discuss the content of the model rather than spending our time trying to decipher what it meant.
A model is not a programming language
Some beginners with a software background were tempted to use the state transition rules as a programming language. This is a mistake. MBSE should focus on representing the design so that the design can be evaluated and evolved.
MBSE improved design reviews
Once we became reasonably proficient at putting together models, we started to use them in our design reviews. This worked better than expected. We expected software engineers to be able to decipher the diagrams, but somewhat to our surprise, the mechanical and electrical engineers caught on very quickly and were comfortable reviewing the diagrams too. Even the engineering managers were able to follow and understand the diagrams.
Another pleasant surprise was that our review meetings became more productive. When you review written documents, especially requirements documents, you spend a lot of time wordsmithing. Apparently, most engineers on our staff minored in English. Reviews often devolved into discussions about choosing exactly the right adjective, or the best way to phrase a sentence. Reviewing models eliminated all that subjectivity. We spent more time discussing whether the model got things right, or whether the design could be improved.
MBSE requires good spatial thinking skills
Spatial thinking skills are required to make maps, graphs, cross-sectional drawings, and 2D representations of 3D objects. Children first develop these skills by playing with toys such as blocks, Tinker Toys, Lincoln Logs, Legos, and Erector sets. (Note that these activities have traditionally been considered more appropriate for boys than for girls. Enforcing these gender stereotypes no doubt handicapped girls who had an interest and aptitude for engineering).
Educators have noticed a decline in the ability to think spatially. Unfortunately, video games and other digital entertainment do NOT develop these skills. Even more unfortunately, research indicates that spatial thinking is a prerequisite of many math skills. By neglecting the kind of play that hones these skills, we are making it more difficult for children to learn math.
The good news is that spatial thinking skills are not innate. They can be trained and developed. I spent a year training a group of new systems engineers in MBSE and saw that as their spatial thinking skills improved, so did the quality of their models.
Aesthetics matter in modeling
There is an aesthetic quality to good spatial thinking. People with good spatial thinking produce models that have aesthetic qualities: symmetry, proportion, simplicity, pleasing layout. This connection is so strong that often just a quick look at the aesthetic qualities of a model can give you a rough idea of how good it is. Models that look messy, complicated and confusing often upon closer examination reveal that the design being modeled is poorly thought out!
Pay attention to Nomenclature
Choose names that correctly describe the object and are consistent with other names in the model.
Simulations
The tool we used provided the ability to run simulations on a model. After creating a model, you can run simulations to test its logical correctness and consistency.