Turning the V-model upside down: The A-model

The V-model is well known in many software development models:

However, this drawing, which is very representative for V-model drawings, has several inconsistencies. One of them is the arrow, that goes back in time. Another one is, that it puts Operation and Maintenance into the Project Test and Integration side. I have seen many V-model drawings, and I never really felt comfortable with them. The reason is simple: The V-model drawings all assume a time axis, i.e. at the end of the project, you check if the software actually works... there is no iterative development, there is no sanity check in the middle of the software development etc.

If one assumes, that acceptance criteria and test/verification criteria are made before the software is developed, as it is known from test driven development and other methodologies, the time axis should be from top to bottom, instead of from left to right. Once you do that, the next thing is: Why is the model occupying most space at the top, and most work at the bottom? Let's turn it all around, and make the A-model:

Now we have appropriate sizing of the boxes, and the confusing time axis has been removed. Just like the V-model, it is possible to have different layers in the pyramid, and use different terminologies and methods.

So, where did the time axis go? That could look something like this:

• Project is initiated, with user needs and validation criteria
• Project is planned, with design input and verification methods and acceptance criteria.
• Project is designed, which includes the creation of automated integration tests and unit tests. These may be done in parallel and iteratively, and it is possible to apply several design reviews, validations, tests etc. as part of this iterative process. The entire A-model's test-side will be applied, and the entire SPECs-side of the A-model may be changed as part of the iterative model.
• Project has it's final test, which may include formal test plans and automated tests - but in some less critical cases, in order to shorten the time-to-market, it may not include all the manual tests that were done in the design phase.
• Product is released.

Again, many different project models can be chosen, but the big work of writing the unit tests and integration tests, is done in parallel with designing and programming. Notably, integrations between software of different vendors is often integration-tested first, before details are programmed, in order to ensure that there is a connection between the two systems, early, so integration testing is started before unit testing.

I believe that this A-model represents most software development projects better than the V-model.