As the past coordinator for the MAAB Style Guidelines, I have spent a fruitful number of hours thinking about guidelines for the Model-Based Design and Safety Critical environments. In a recent discussion, I was challenged by the question “Why have a guideline that you cannot check”?
Now any guideline can be validated through a manual review process. In this instance, the query was specifically asking about automatic validation. Further, they were working in an environment where the majority of users were new to the Model-Based Design environment. So here is my, evolved, answer.
Why can’t it be enforced?
Some guidelines cannot be enforced because they depend on human judgment, things like “meaningful names” or “readable diagrams” are, by their very nature subjective. (Though I have an idea for a neural network solution for the meaningful names issue). Since that can’t be enforced is it worth throwing out? Generally no; it becomes a “best practice” and perhaps a subset of the rule could be enforced (e.g. limit the number of blocks per level of the model, minimum name lengths…)
What do you do with the non-enforceable?
As a general best practice when guidelines are rolled out there should be an education seminar to explain the guidelines and their purpose. Special emphasis needs to be placed on those guidelines that cannot be automatically enforced. Explain the
- Rationale: why the guideline benefits the end user
- Effort: how hard will it be for the user to follow
- Benefit: what does the end user and the team get out of following the guideline
Final thoughts
In the end, these guidelines should be thought of as a recommendation. Some, but not all will be caught during reviews with co-workers and by test engineers. That they will not always be followed should be expected but if you never provide the guidance they never can be followed. If you keep them to a minimum, say no more then 6 to 10, these guidelines that are highly impactful, well, eventually people will follow them without thinking.
