Download
1 / 21
280 likes | 545 Views
3. 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.
E N D
3 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.
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 designactivity is carried out to determine which subcomponents arerequired. • 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.
