Multiple V-model

IntroductionIn 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.

IntroductionThe 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-modelIn principle each of the product

appearances (model, prototypes, final product) follows a complete V-development cycle, including design, build and test activities.

multiple V-modelTesting 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 developmentThis 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 VsThere 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

Test activities in the multiple Vs

Test activities in the multiple Vs

Test activities in the multiple Vs

The nested multiple V-modelThe 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

The nested multiple V-modelFor 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-modelIn 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

The nested multiple V-modelWith 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 nested multiple V-modelThe 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.