Embedded Development Models and Project Management
Below is an excerpt from our book, Project Management of Complex and Embedded Systems for those that believe the “V” model means single pass product development (as if) – think again! This book has a significant automotive perspective, complex, highly tooled machines that must meet and government regulations.
Embedded Development Overview[1]
Embedded software development requires extensive planning, monitoring and thorough follow up to succeed in all quarters. The responsibility of the project manager is to prepare the schedule for documentation, development, build, and quality assurance. In order to manage all of these activities and risk, an understanding of the workflow is necessary. The workflow is essentially a model of the production sequence for designing, implementing, and testing embedded software—a map of the process.
General embedded development knowledge and the workflow model allow the project manager to ask pertinent questions. These questions provoke answers about risk from those responsible for the deliverables. Moreover, it allows the project manager to do some risk assessment on his own. Knowledge of acceptable software life cycle processes (via the workflow model) makes it possible to identify situations of increased risk.
There are a number of development cycle models. The project team should reference the same model since this provides a common frame of reference for subsequent team discussions.
- Waterfall model
- Spiral model
- Big Bang model
- Iterative
- Evolutionary development
- V model
- Rapid prototyping
- Model driven
Figure below is an illustration of the ”V-cycle” model for software development life cycle. The model illustrates how the development starts from a systems level and progresses through increasingly detailed development phases. The activities start at the upper left hand corner with customer requirements. This customer input drives concept selection and documentation. Once the team defines the concept, they generate the system requirements that support the concept. The system requirements are broken down to the next level of detail where they document the component(s) requirements (hardware and software specifications). Finally, with the component level documentation complete, the hardware and software design implementation work starts. The output of each block is the input to the next one.
V-Model Connection between Development and Test
V-cycle Model
This model provides a juxtaposition of the development work (left side of the “V”), with the verification or testing work (right side of the “V”) necessary to quality secure the product. In the figure each step has related verification to ensure the requirements are satisfied. For example, design is verified by Developmental tests. The model applies to both software and hardware. During the hardware design stage, performance and functional theories and hypotheses can be tested–verified–to either substantiate or refute an expected quality level.
As with all models, there are limitations with this model. The “V-cycle” model does not adequately reflect the iterative nature of the development process. However, with some imagination it is possible to extend the V-cycle graphic to account for the additional phases (refer to figure).
Demonstration of Iterative and Incremental Approach
[1] Pries, K., & Quigley, J. (2009). Embedded Development Overview. In Project Management of Complex and Embedded Systems Ensuring Product Integrity and Program Quality (pp. 297-299). Boca Raton, FL: CRC Press.
