|The Death of the V-Model|
The V-Model of software development is widely in use today, especially in the defence industry. It’s a pity then, that it is fundamentally flawed, and that it is responsible for misleading project managers into thinking that the project they are about to undertake is well understood. The reality is that the more the V-Model is used as a tool to manage the software development process, the more likely that project is to fail.
The V-Model of Software Development
The following diagram is a typical representation of the V-Model. The development life cycle follows a fixed path from Requirements Analysis to Operational Testing and subsequent delivery to the customer. Testing tasks are generated from knowledge gained from development tasks, for instance the High Level Design will generate the Integration Tests. A project following this model will move through these tasks one at a time, moving on when the current task is completed.
This model does have a number of good points, such as:
However, this is as far as it goes. This simple model does not account for the complexities involved, and thus can prove to mislead a project manager if relied upon.
The Dying V-Model
Let us take a look at the software development process for a moment. As stated by P.G. Armour, in "The Laws of the Software Process"¹, software development can be viewed as a quest for knowledge.
In the software development world, you can bet your last dollar that the plan will change. That means that the software development model has to model change. The V-Model does nothing to accommodate change, and this is the primary reason why it fails as a model.
A second reason whey the V-Model fails, is in the testing phases, and has been illustrated by Brian Marick². He explains that implementing unit tests and integration tests as single, separate phases results in a thoughtless approach to testing. For example, a single unit test will require a custom test harness. Each unit may require a different test harness. For a large projects with lots of units, this could prove to be costly and problematic. It could be a better idea to test a unit when connected to the actual system, using the system to deliver test messages. The point is that no thought is being applied to the trade-offs involved in testing early, testing late, or testing as-you-go.
The V-Model is Already Dead
In reality, a development project that is working is not following the V-Model, even if management believe that this is so. This is because good engineers are flexible and adapt to problems, they are able to expect and respond to change. They test code when it has been written, to get a feel for the system. Extremely good engineers even update the documentation when the design changes!
The Final Nail in the Coffin
The most damaging aspect of the V-Model is not in the model itself. Any model is an approximation, and this model does at least provide some value. The biggest problem arises from the manager’s steadfast reliance on the model, making the assumption that the model is a ‘tool’ to be ‘used’. When the V-model is accepted as a good model for software development, it blinds the project manager to the realities of the software development process, and distorts this process to the point whereby it is counter productive. It is like a one dimensional view of a four dimensional universe - fundamentally flawed and very far removed from reality. As it is this bad, don’t even bother to mention it except in the history books as a dead model.
The V-Model is an inadequate model for software development for the following reasons:
The original pdf can be downloaded: Death of the V-Model (76.9 kB)