The V-Model

Having suffered through my adoration of the venerable Waterfall Model (WM), it’s time to expand upon it and bring us out of the bronze age of system development and into the age of steam with the V-Model (VM).

The VM is similar to the WM in that it promotes a flow from requirements through architecture and design to the implementation, thus increasing details over time. Where the VM diverges is that specification of testing comes early and often, right alongside development. The left side of the “V” represents the decomposition of requirements into an architecture and design that informs the system’s implementation, covering the first three quarters of the WM. The right side of the “V” represents stages of testing and integration of the implemented system. Arrows from the right to the left show what stage of tests will test what stage of development.

Figure 1: The V-Model

Starting at the top of the left side of the “V”, we have our requirements, a concept that was described in the WM article. As the requirements are being developed, tests for the requirements are created in parallel. This distinction from the WM is important because it adds another layer of review to the requirements during the crucial time of their development, i.e. as the requirements are being created and groomed the testers are developing their tests and to do so they must of course read and understand the requirements. This creates an implicit and early feedback loop between the requirements authors and testers, something the WM did not specify. The tests for the requirements cannot be run yet since we haven’t implemented the system but it’s nevertheless beneficial to have the work ongoing.

After the requirements, sliding down the left side of the “V”, the architecture and design is developed. Like the previous stage, as that is happening the tests against this development stage are being created. And again that creates another layer of review and feedback between the two streams of development. Since the architecture and design defines blocks of functionality and their interfaces, the stage of testing being created here are integration tests. In a modern, complex, software-dominated system these integration tests will focus on interfaces between software blocks. However hardware-software interfaces (HSI) as well as interfaces with the outside world are also important and developed at this stage.

At the tip of the “V”, on the left side is implementation and on the right is its unit testing. Whether you use a test-driven development (TDD) method or something else, the idea is the same as above: tests are developed alongside the implementation creating fast feedback loops for development. It should be noted that code reviews are implicitly included during the implementation, just as reviews are implicit in the development stages above.

For a complex system the VM is still a little simplistic so it is extended. The basic explanation of the “V” remains the same but layers are added on top.

Figure 2: The V-Model (extended)

Prior to work on the software, this extended “V” starts with system activities. At the system requirements stage, requirements describing the system as a black box (for very complex systems some breakdown might be assumed*) are created as well as the tests against those requirements. After that the architecture and design within the system boundary is developed along with the system integration tests. The system architecture and design breaks down into hardware subsystems where software subsystems are allocated and defines the HSI, interfaces with the outside world, as well as very high-level software interfaces (for instance between middleware and applications). The “implementation” of the system restarts the cycle with requirements at the software level, which gets broken down into a software architecture and design, and finally software implementation.

Before we wrap up, I want to mention that these models are typically very focused on software development since it has come to dominate complex system development. Parallel tracks of hardware development could be assumed to run alongside software. However — as far as this system/software engineer understands — methodologies for hardware development lag behind those of software and normally hardware development happens in a more-or-less organic fashion.

So now you’re asking yourself: why would a system/software engineer with 20 years’ experience in safety-critical industries take a job at SUSE just to write boring blog posts about system development models? Answer: I didn’t take a job at SUSE to write boring blog posts; I took the job to be a part of SUSE’s strategic partnership with Elektrobit to deliver a next generation, Linux-based operating system for future intelligent vehicles. And if you want to develop for the automotive industry, you have to know the V-Model and its relationship to ASPICE.

Tune in next time when I give an overview of ASPICE and how the V-Model relates to it.

* For instance, in many advanced driver-assistance systems (ADAS) there is a very high-level breakdown of functionality into sense, plan, act. Input from sensors is gathered, analyzed, and fused into an environmental model of the vehicle and its surroundings. Then ADAS features plan paths for the vehicle according to the environmental model and their purpose. Finally the plans are compared, prioritized, and implemented as commands for the vehicle to execute. This high-level breakdown of the software system can be assumed at the system requirements level so the entire system isn’t treated as a black box by the system requirements authors. As a concrete example of this breakdown, take adaptive cruise control (ACC). Front facing radar and camera data is fused into the environmental model to describe the vehicles in front of your own, including their relative positions and velocities. The ACC feature plans a path based on that model: if there are no slower vehicles in front then the driver-set speed is maintained, if there is a slower vehicle in front of your own the ACC will slow the car to match the speed of blocking vehicle and maintain a safe distance behind it. Then the ACC’s planned path is compared with other features’ plans and either implemented or overruled. In this case the ACC’s path might be overruled if the automatic emergency braking (AEB) feature determines a more vigorous reduction in speed is needed to not collide with the vehicle in front.