Part 1 of this series discussed the challenges and organizational impact of adopting Model-Based Design.
Part 2 looked at an overall strategy for adoption of Model-Based Design.
Process and tool migration plan
Model-Based Design provides a wide array of tools and techniques to facilitate each phase of an embedded software development process. Developing an initial process and tool migration plan requires an understanding of how the activities of Model-Based Design process differ from traditional processes.
To this end we present an overview of Model-Based Design activities and a set of pragmatic strategies for each stage of the process. The strategies are designed to help an organization discern what approaches to initially adopt and what practices to avoid. These recommendations are based on our cumulative experience in helping organizations make the transition.
The figure below illustrates a typical embedded software development process composed of requirements, design, implementation, and integration and test phases. The underlying processes of continuous verification, configuration management, and change management support overall process activities.
Requirements specification is the process of analyzing and documenting the requirements and constraints that the system being developed must satisfy. The ability to use a model to create an executable specification and run simulations makes it possible to analyze and validate requirements early and at a deep level that wasn’t previously possible.
Use executable specification development as an opportunity to solidify formal requirements
Industry studies show that requirement errors are the largest source of errors in embedded system development and are the most costly to fix because they typically aren't found until system integration and test at the end of the process. One of the most significant sources of reduced development time and cost savings in Model-Based Design is the early identification and correction of requirements errors.
However, if formal requirements do not exist for the project, use executable specification development as an opportunity to create a formal requirement, which doesn't create immediate savings but will yield benefits for subsequent design iterations. In some cases requirements for the design on which the new project is based need to be synthesized from the code implementing it. Once the formal requirement is established, the executable specification should be linked to requirements, and ultimately integrated with the change management process.
Validate requirements before moving to detailed design
Sufficient engineering time should be allocated to requirements gathering, analysis, and verification prior to initiating detailed design. Verification will often involve not only analyzing requirements but in case of new or complex applications will involve simulation and rapid prototyping to insure the requirements are both correct and complete. Failure to verify results in unnecessary design iterations. If verification is not possible without a fully elaborated design, use the model to document the expected output for each of the possible inputs and "stub" the design with a simplified implementation.
Communicate to internal and external customers and suppliers using a model
Specifications are developed to facilitate communication whether it is between an OEM and its supplier or between two departments within the same company. A model represents an unambiguous executable specification which makes it an ideal communication tool.
Engineers can use the executable specification to help eliminate the most common source of interpretation and translation errors. When an executable specification is used between an OEM and its supplier, the supplier should review the executable specification with the OEM as a project milestone, demonstrating how each requirement is to be met and confirming behavior of the system as the supplier understands from the requirement.
Make the model a source for documentation
In addition to serving as the core of the executable specification, the model can also be used to produce other documentation such as the test coverage report and, with proper information captured, the calibration user guide. Tools are available to automate the extraction, re-arrangement, and presentation of information stored in the model. The automation helps eliminate the need to prepare many design documents separate from the model, which can easily become out of sync with the design.