Many of the process and quality gurus written about on this site wrote about this topic years ago and when you look at the model below it should, if not be familiar, at least be intuitively right.
The earlier you address problems the cheaper they are to fix.
Here is a construction example; When building a house the builder stops and checks the concrete slab before constructing the rest of the building. If he didn’t, and rushed into the building of the walls and roof he may find there are problems with the foundations and have to rip the building down and start again, wasting a lot of work and materials.
The same can be applied to any almost any type of project, and especially large complex software projects.
There is also the idea of managing quality in, rather than managing defects out.
Pulling defects out of a production line is one way of increasing quality for customers, but these days it’s generally accepted that you want to pull out the defects of the production process itself, so that it doesn't create defects and so you can get the highest yield out of your production line.
In software development this is done by two streams of activities; validation of the requirements and solution design, usually by document reviews, and also by ensuring that the system is functional, robust and meets customer requirements before releasing it into production.
That way, once the users have logged on for the first time the system is likely to be doing as expected, and process workarounds will not be required to perform smoke and mirror tricks so the customers experience a quality experience.
The next post will talk about the software development process and how the V-model fits into it.