The graphic on the right came up for discussion at the office today.
The V Model is a traditional model, still widely used, but (IMO) bad for at least a couple of reasons.
-
Look where User Requirements and UAT are — the first and last items in the V. This ensures that the maximum amount of time goes by between users saying what they want and being able to test out the implementation. The more time that goes by between users saying what they want and being able to try it out, the more likely it is that they’re going to change their minds, for any number of reasons. That’s bad.
-
If our testing is honest, there’s always some non-zero probablilty that the system will fail, again for any number of reasons — too slow, too buggy, not what I asked for, etc. By putting testing last, we don’t find out that the system is a failure until we’ve already invested the entire cost of building it, thus the rich history of big-ticket IT failures, where huge sums of money were spent and nothing usable was ever delivered.
IMO, you can use a design-code-test V model, but you have to use it iteratively every week or two weeks or at most every month on a project to avoid these problems and make sure users are getting what they want.
Thus spoke The Programmer.