The V-Model and Office Layout

Hi this is Gary.

Welcome to Episode 5 of Development That Pays.

Can the layout of an office have an impact on the software development process?

I’ve been lucky enough to work in a range of offices and development teams,

but the office layout at IntuDigital struck me as being nearly perfect for software development.

The way work flowed through the office reminded me of a model of software development that I hadn’t thought about for many years

A thing called the V-Model.

Unusually for me, I can remember exactly where I was when I first heard about it.

I was right here, in an "Information Systems" lecture.

The year was 1994.

In 1994, I hadn’t even heard of the internet!

Let’s take a look at one version of the V-Model.

We start with "Requirements Definition”

Then move on to "High level design"

Then on to "Detailed Design”

Now that we have the Why What and How, we’re ready to actually write some code.

Then things get a little more interesting: we start to move up the other side of the V…

first with "Unit Testing” then “System Testing" and finally "Acceptance testing"

And now we can see that the “V shape ” is all about verification and validation:

As we move back up the right hand side of the V, we VERIFY at each level.

Unit tests VERIFY that each chunk of code does what it should System tests VERIFY that the code complies with the high level design Acceptance tests VERIFY that it new feature does what it was conceived to do.

Let’s see how the V-Model works in the IntuDigital office

The MD sat here

Beside her, the Product Owner.

They are perfectly positioned to work together to develop REQUIREMENTS

Next, the Requirements would make the long journey to a conference room,

where the product owner would be joined by

the project manager the lead developer one or more of the developers and someone from test.

To thrash out the high level design.

From this point there was a feeling that the new feature was “heading home” - as if it as on a bungee cord.

The Developer would set to work in an iterative cycle of writing unit tests, writing code and then getting the unit tests to pass.

And when the the feature was ready, it would move across to Test.

This is where the central position of the Test Team really paid dividends:

Something not working? All they had to do was spin around in their seat and talk directly to the developer.

Any questions about the interpretation of the spec? Well, the Product Owner and the MD are right across the desk.

With system level tests complete, there’s just one step remaining:

that’s the Acceptance test which, - as we just said - is right across the desk!

Now I come to think of it, most offices I’ve worked in have been arranged a little bit like the left hand side of the V.

So we might have a product owner, beside a lead developer beside some developers beside some testers

What’s different here is that the office is optimised for the right hand side of the V.

Around the VERIFICATION of each stage.

It worked really really well.

Talk to you next time.