Dissecting the V Model

It has recently come to my attention that even today there are still enterprises that standardise on the so called “V model” for their software development work (from requirements writing to testing). In this article I will explain why this is a bad idea, even looking through some very forgiving lenses.

What Is the V model?

The V model (also explained here) is an extension of the sequential (“waterfall”) model of software development. Instead of showing the sequence of work tasks as a straight line as in the waterfall model, both ends of the process chain are bent upwards to signify higher levels of abstraction, different roles, and a correspondence between requirements, designs and tests. Looks pretty logical, right?

V model

The V model

What Is Wrong with the V Model?

Historically, the V model was made with the waterfall model of software development in mind. It assumes long time-frames with phases progressing in an ordered fashion from requirements analysis to system design to programmering, and finally to testing. All descriptions of the V model talk about each node as a “phase”. Phases have more or less been removed from software development today, displaced by iterative or continuous models.

Philosophically, the V model assumes any problem can be solved by breaking it down into smaller and smaller pieces. This is the analytic view of any engineer. When the V model was created, most programmers were engineers and software engineering was in vogue. This idea is sadly flawed. First of all, not all problems can or should be solved this way. For example, any form of modelling or design job is really an iterative process of gradually discovering better (more useful) solutions. There is really no right or wrong. A top-down, divide-and-conquer attack is great for mathematics and engineering; less so for design. Secondly, only a minority of programmers are engineers today and they solve problems very far from engineering.

The V model implies an ordered sequence of steps, which is hard to reconcile with the daily realities of software development. Obviously, the person who designed the V model wanted development to occur that way because it appeals to a mind who likes order. But saying it is so does not change reality – it only misleads. Studies have shown how experts switch quickly between understanding the problem (analysis) and fleshing out a solution (design).

The V model divides responsibility strictly into roles, which creates waste. For example, the requirements analysis is performed by a business analyst or similar, the system design by an architect, and so on. This increases the divide between people instead of promoting collaboration. These last decades, there has been an increased understanding that to get good results, we have to work together. By grooming specialists with narrow responsibilities we will get more hand-overs, more misunderstandings, and more rework.

The V model is document-driven. It dictates that each development phase to the left result in some form of description, which can be used to design verification tests, which are then performed at the end, on the right-hand side of the model. We have gained the understanding that written communication is not always best. It has its advantages, but when you really want to spread a common understanding, face-to-face communication is superior.

The V model puts way too much time between specification and verification. In the V model, testing that requirements have been satisfied occurs quite some time after the requirements were fixed. Even unit testing is separated from programming of the unit, typically performed by another person than the developer. However, the sooner we can verify something, the faster we get feedback. In a process using feedback, that means quicker response times and quicker corrections. The last 15 years software developers have even managed to move the feedback before the module being developed and in that ingenious step merged verification and specification into one.

The V model puts far too much weight on verification testing (finding and removing defects at the end) and not nearly enough weight (none, to be frank) on preventing errors in the first place. Quality studies have shown that teams with great quality skills avoid many of the defects that end up costing a lot more if found at the verification stage. Examples of practices that promote this are pairing, specification-by-example, and test-driven development. There is a quote from Edwards Deming related to this:

“As Harold S. Dodge said many years ago, ‘You cannot inspect quality into a product.’ The quality is there or it isn’t by the time it’s inspected.”

Finally, the V model is too limited in scope. It assumes there are some omniscient people on one end with a perfect view of what the customers will need and those assumptions are never verified. We only verify that the requirements, as described, are satisfied, which is clearly not the same thing. The growing awareness of the role of the customer (or user) in product development has shown us that leaving them out of the loop is not a clever idea. We have realised, from user-centred design and user experience fields, that business value appears when someone actually uses a feature, never before that. From Toyota Production System we have the “pull” model, where customers are though of as pulling new products out of the factory. There is even talk among management consultants that we are entering a new era of “consumer capitalism“. The buyer is in control and companies that delight the customers will be successful. To summarize, we need continuous feedback from our customers and stakeholders.

Re-interpretation of the V Model

Now, there are probably readers who feel I have been too harsh on the V model in this article. They will claim that a modern interpretation of the V model is to read the length of one ‘V’ as one iteration instead of a project. Then, surely, the V model would make sense even in agile projects? My response to this would be an emphatic “NO“. Agile iterations are not small waterfalls. Activities of different type happen in parallel, dynamically, when needed. Furthermore, most of the other objections above would still hold.

But what if we narrowed it down even further? What if one ‘V’ just represented development of a single feature? A few days work, maybe. Would that solve the problem? Sadly, still no. There are still no feedback loops. The model still communicates an unrealistic degree of order. It still emphasises inspecting quality after-the-fact. It is still limited and heavy on work documentation. It still promotes specialists with a limited view of the whole process.

Let’s face it: The V model is not suitable for product development and it never really was. Why try to cram modern thinking into an obsolete model? Why not use some other model instead? It is time to put the V model to rest.

What Would a Better Model Look Like?

First of all, a new model would be contextual, meaning it depends on the situation. Like many have said before me, there are no “best practices” in product development. Therefore, I cannot give you a model that will work for you. Only you can do that. But what I can do is present some ideas, which I think could be identifiable in a process development model in harmony with current thinking.

I believe a more useful product development model would:

  • …include users and other stakeholders, starting from their needs all the way to actual use of features and back again.
  • …focus on optimizing flow of value through the process instead of having defined roles and steps.
  • …de-emphasize phases, instead have work cycles with feedback to gradually refine the solution.
  • …de-emphasize specialist roles and boundaries between them, instead focusing on teams working to optimise the whole.
  • …de-emphasize documentation as a means of communication, instead relying on natural collaboration between team members.
  • …remove the artificial boundary between requirements and tests. Specification by example shows us how to specify software in a human-friendly yet automatable manner, using examples to guide us.
  • ..remove the artificial boundary between software design and tests. TDD shows us how to design software incrementally, with quality built-in, using tests to guide us.

8 thoughts on “Dissecting the V Model

  1. Hi Jocke

    First of all. I think the main purpose of the V-model was to put testing on the map. The idea behind it was – like you say to have test phases. Now even the most fanatic process people in testing has changed that to test levels instead. I agree that there is still some focus on phases. Yes, the V-model has some fundamental flaws as do all models. The first step away was the Unified process with even more focus on heavy documentation and roles. That failed too..

    So let us discuss your suggestions for a better model.

    Including users – could not agree more. It is essential. One thing that worries me is that some agile people agrue hard for minimizing the customer demo. Show only the basics and do not put a lot of effort into it. We have done that – partly because the simplest features were the only ones that worked – and the effect has been that end users/product owner/developers does not think enough about the details of the impementation. Thus they find many problems when they finally start to use the application. So I would argue for spending more time on the customer demo. Any reflection on how to get the customer more engaged in testing what they get early?

    De-empasizing roles and steps. From working in SW developement for 15 yrs I have the following reflections. Heavy process sucks – however developers are usually pretty bad at eliciting requirements from users regardless if we are talking about RUP, Waterfall or agile. You may have another experience with that but my experience is that process analysis, business analysis and requirements are better done by non-developers. But I welcome developers that are eager to take those tasks as well! Designing the system from a user perspective requires deep knowledge about interaction design and graphical design. We have used specialists for this in three projects the last year and let me tell you – the usability and appearance of the application are taken to a new level. As a tester I may complain about usability but that does not mean I am competent enough to CREATE the design on my own. As for testing, the scope for agile projects that I have worked in and read about seem to be what I call checking. That means verifying that you CAN do something as specified. It is very human NOT wanting to break what you have just built so I do think you need testers that do good manual exploratory testing. I think the idea of TDD and continuos integration are great but it is not enough to ensure quality on their own.

    Emphasizing value and communication and short work cycles- absolutely. I often use an effect map to get an overview of user groups and effects. It works great to start with the map when creating user stories that I think are superior to use cases.

    I too dislike heavy documentation but simply commenting in the code is not enough. If I ask a developer about how a specific function/service works one or two sprints after it was built – they cannot answer unless there is some basic form of documentation. Now the fact that to little documentation exists may be due to that the devlopers I have worked wth are not experienced enough? But I assume that you use some level of documentation for your own good?

    So in short. I think agile development and your ideas have som nice benefits but there are – as in all models – some serious flaws as well. I wish I knew the perfect model – but I doubt there is one. Skilled people that communicate are essential ingredients. For the process – I could argue that with the right people, any process will work!

    • Hi Tobbe and thank you indeed for your comprehensive comment!

      Yes, I agree that the V model had its purposes. Maybe, if some pointy-haired manager still did not understand the importance of quality, it could be of use even today. But still I think it would be better to search for better ways of modelling your development work and explain where testing fit in.

      I am not diminishing testing by arguing against the V model. Testing does not get less important by moving most of it to the front of the process, quite the opposite. As the use of specification by (testable, automatable) examples (BDD, ATDD) grows, the importance of having a “tester’s attitude” in every step grows more important. Someone from the contextual school of testing might say that you automate the “checking” to leave room for the “testing” (ET, SBT).

      Regarding specialities, I believe we will still have our special interests and specialities, even though more people can do many tasks. Too many, narrowly defined, expert roles have a hard time collaborating. By helping out and learning the basics of other fields, we reduce people risks and increase flow of work. We understand each other more fully and create great teams.

      Documentation, sure we will need some. But the best documentation is correct documentation. And to be correct, it needs to be alive. Executable specifications can be evolved into exactly that; living documentation. Check out Relish to see how teams use it to create great functional documentation out of Cucumber specifications.

      Yes, teams and collaboration are more important than process, but adopting a misleading view of the work (the model) makes something that is really hard to do well even harder.

  2. Hi Jocke!

    Thanks for yet another great article that gave me a valuable perspective on the V-model which some people are trying to use at the company I work for.

    To me the role hierarchy of the model stood out as particularly sad, putting the “coding” part at the bottom level, as if it could be executed by code monkies and then needed to be verified in layer after layer by people with a better comprehension of the world and what the customer actually ordered.

    Luckily Fred Georges presentation on QCon (http://www.infoq.com/presentations/Leaner-Programmer-Anarchy) cheered me up! His company has become very successful by using a process they call “developer anarchy”. It is described as the next step after agile. It emphasizes the trust between managers who set the goals for the product and the developers. The key to the success seems to be to get rid of the fear of failure and increase freedom by showing trust. The developers are given goals from the managers and are totally free to solve it any way they like. But the developers are also free to set goals, for example speeding up an legacy application by rewriting it in Clojure… However testers and requirement people are not mentioned.

    How about we find a process that equally respects customers, requirement people, developers and testers, to me its obvious we are all needed in larger projects. Your concluding tips are a good way to start.

    cheers,
    Pia

    • Hi Pia!

      Thank you for your kind and encouraging words! I am sorry that my post made you feel a little sad, but I think that only shows how important it is that we rid our selves of these flawed models. Glad that you agree. We (people in all development roles including managers) are worth something better.

      Thank you for the presentation tip! I will have a look at it. It sounds a little bit like what has been called the “chaordic” organisation, (Dee Hock). Also, Bob Marshall, the founder of the rightshifting movement in the UK considers this organisation type as the 4th and most highly evolved, after the “synergistic”, which could be considered a Lean/Agile organisation. Most organisations today would probably be classified as either “analytic” or even “ad-hoc”. Read more in this pdf.

  3. Hey Jocke!

    Nice article, and I agree although I could use some more order in my project as you can imagine🙂

    /Kalle

Comments are closed.