The Hidden Secrets of the V-Model

Episode 6 - 07 Oct 2015

The V-Model of Software Development has stood the test of time: it can trace its roots back to the early 90s.

But it's not just a model of "verification": there's more that it can teach us.

(Hint: it's to do with Money!)

Enjoy the video.

Hi this is Gary. Welcome to Development That Pays.

In the last episode we touched on a thing called the V-Model of software development.

This is an interesting little model and there's more to it than meets the eye.

That's what I'd like to talk to you about today.

Let's start, though, with a quick review of the V-Model.

We start at the top left with Requirements Definition.

Then move into Functional Design.

Then into Technical Design.

Finally we're ready to do some Coding.

And then as we move back up the right hand side of the V, we verify at every stage.

So Unit Tests verifying the Technical Design.

System Tests verifying the Functional Design.

And Acceptance Tests - or USER Acceptance Tests - verifying the Requirements Definition.

So the V-Model is really a model of VERIFICATION.

But there's something else that this clever little model can teach us, and it's the thing that made me sit up and take notice some twenty-odd years ago when I first heard about the V-Model.

It's that each of these horizontal lines is an indication of the cost of getting it wrong.

So bugs - unless they’re particularly insidious - are generally quick and simple and therefore cheap for us to rectify.

But if we've gone and built entirely the wrong thing then of course that's a much more expensive mistake.

Now as I started to think a little bit more about this this idea of the cost of failure I started to wonder if maybe the V-Model - at least this version of the V-Model was incomplete.

So I did what I always do in a case like this: I Googled it.

A search for V-Model brings up no shortage of variations on this theme.

But what most of them have in common is that they started the top here with something that is Requirements Definition or some very close analogue of that and on the right hand side here Acceptance Testing, User Acceptance Testing or, again, something quite like that.

But I was able to track down version of the V-Model that adds another layer on top. A layer that I like rather a lot.

On the left hand side our additional box is Business Case.

On the right hand side is Realisation

And this goes back to something that I think we talked about in episode three.

The idea that you never really know that what you've built is right until its live and it's out there and it's being used (or not used) as the case may be.

And if you've got to all the way to that stage before realising that something isn't quite right, then that's the biggest cost of all.

So I have a question for you: now that you know that, which of these projects would you rather take responsibility for.

This huge imposing V on the left or the small and perfectly formed V on the right?

Safer I think to do lots of little V’s than one big huge V.

Talk to you next time.

Watch "The Hidden Secrets of the V-Model" on YouTube.