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 the 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 will 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 build 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