In a recent meeting, I was asked: “What are the common questions that people ask about Model-Based Design?” With some reflection, I came up with these four questions and answers.
What are the benefits of adopting Model-Based Design?
The financial benefits?
This question, which generally comes from management is straight forward. Do we see a financial benefit (ROI) from adopting? If so how long before we see these benefits? The answer, of course, depends on the starting point of the group, however, the following link provides a good overview on estimating ROI for the adoption process. The timeline for realizing benefits is generally 6 months to start seeing the ROI. Full adoption and full realization occur between 2 ~ 4 years after the start of the project.
The process benefits?
This is, more often than not, 
a defensive question. There is, understandably, a reluctance to change existing processes if they are working. Because of this, the answer addresses the common problem that existing traditional hand coding environments, errors introduced at the handoffs points between researchers to developers to test engineers to system engineers to… As discussed in earlier blog posts, one of the fundamental aspects of Model-Based Design is the use of a model as the single development environment throughout the full development process.
I have a technical question…
How do I reuse all these existing…
For most companies, there is a
significant investment in existing infrastructure. Therefore, it is a high priority task to figure out how existing software objects. First, as talked about in these blogs much of the existing software development infrastructure can and should be reused with some modification and extensions.
Second, there is the perennial engineering advice: “If it ain’t broke don’t fix it.” One of the earliest tasks in adopting Model-Based Design is identifying the parts of the existing software infrastructure that is
- Well partitioned and encapsulated
- Reflects and maps to the requirements
- Has good test coverage
Once those have been identified, leave them alone. For other software objects, they can either be recreated or they can be incorporated into the Model-Based Design environment depending on their level of “completeness.”
How can it ever be as good as what Sally does?
Sally, or Bob, depending on the day I am speaking, is the local guru. They are the person who produces the best code, tests, or system
architecture following a traditional design practice.
The short answer that I give is this: no automation process, for a single task, can match a highly experienced developer. However, there is a limit to how many Sallys/Bobs that exist in an organization and the automation software produces code that is on par with an average developer for single tasks. Further, due to the optimizations that are possible for an automated methodology, it can find optimizations that humans have difficulty in finding.
There is another aspect to this; has anyone asked Bob and Sally if they would like to be working on higher level tasks? Frequently these people could accomplish even more if they were not down in the “guts”