Multiple V-model

Introduction In embedded systems, the test object is not just executable code. First a model of the system is built on a PC, which simulates the required system behavior. When the model is found to be correct, code is generated from the model and embedded in a prototype.

Introduction The experimental hardware of the prototypes is gradually replaced by the real hardware, until the system is built in its final form as it will be used and mass produced. The reason for building those intermediate product-appearances is, of course, that it is cheaper and quicker to change a prototype than to change the final product, and even cheaper and quicker to change the model.

multiple V-model In principle each of the product appearances (model, prototypes, final product) follows a complete V-development cycle, including design, build and test activities.

multiple V-model Testing the different physical versions often requires specific techniques and a specific test environment. Therefore a clear relation exists between the multiple V-model and the various test environments.

Iterative and parallel development The middle V especially, where the prototypes are developed, is iterative in nature. Iterative development models that may apply here. In reality, developing an embedded system is a complex process for the following reasons. - It is a multidisciplinary project involving both software and hardware development teams. These often work independently and in parallel. - A good project manager will ensure that there is frequent communication, integration, and testing. This usually results in an iterative process.

Iterative and parallel development - The development of large and complex systems requires (functional) decomposition of the system, leading to parallel development of components and stepwise integration. - For each component a model can be developed, followed by iterative development of both hardware and software.

Iterative and parallel development This explains why the development of a particular embedded system will be a (unique) complex process with many development and test activities happening at various times, requiring much communication and coordination.

Test activities in the multiple Vs There are many test design techniques that can and will be applied, test levels and test types that must be executed, and test related issues that require attention. In order to plan and manage this well, the test manager needs an overall picture of all relevant test activities and issues, and how they are related.

Test activities in the multiple Vs

The nested multiple V-model The left side of the V-model handles the decomposition of the system into its components. The middle part of the V-model consists of parallel development cycles for all components. The right side of the V-model handles the integration of the components.

The nested multiple V-model

For such a component, an architectural design activity is carried out to determine which subcomponents are required. Because this may result in a V-model within a V- model (within a V-model, …) the development lifecycle model is said to be “nested.”

The nested multiple V-model In fact the purely sequential multiple V-model is mainly applicable to the component level. Usually it is not the complete system which is fully modeled first, then completely prototyped, and so on. It is the components that are built in this stepwise way. When the V-model at the system level is combined with the multiple V-model at the component level, it results in the so-called “nested multiple V-model”

The nested multiple V-model

With this model, all test-related activities and issues can be allocated to the correct level in the correct place. At the system level, higher-level test issues can be allocated to the overall development cycle.

The nested multiple V-model

The multiple V-model is not only helpful when a test has to be planned and executed for a completely new (developed) product, but also in the case of new releases of an existing product. First it should be identified where the development activities fit in the multiple V-model. Then the full master test plan helps in choosing the integration and test activities for an effective master test plan dedicated to this new release.