The Capability Maturity Model Integration (CMMI) framework defines the requirements for a comprehensive software process. Based on those requirements, you can develop either a good or a bad process.
I recently met a gentleman working for a company that was in the process of developing a
CMMI-compliant development process. Unfortunately, the effort was led by bureaucrats. It sounded to me that many classic mistakes were being made, including the institution of a large number of rigid quality gates that development teams had to pass through during the development process.
A quality gate is a validation point that a project team must pass to proceed to the next stage of development. It can be something as simple as a conversation between two people to something as rigid as a formal inspection or review. The benefit of quality gates is they give management visibility into the project (although true managers are actively involved in projects to begin with) and they provide a way to validate that the team is doing the right thing.
The primary disadvantages of quality gates are they slow things down and can force the team into working in a serial manner. Modern development proceeds in an iterative and incremental (evolutionary) manner, not a serial one, which was popular in the 1970s and 1980s.
So, which quality gates work best? Early in the project you want to validate that the team has identified the scope of the project and has gained stakeholder acceptance. They should have done some initial requirements-gathering, but not have wasted a lot of time writing a detailed requirements specification. A 2001 study in the UK of 1,027 projects showed that writing a detailed requirements specification – and the corresponding change prevention process associated with it – was cited as the leading cause of failure for 82 per cent of them. Competent IT professionals accept the fact that change happens and therefore adopt evolutionary –and better yet, agile – modelling techniques.
The second quality gate a development team should pass early in a project involves proving that the architecture works. They should build a working technical prototype that tests the architecture from end to end. Bureaucrats often mistakenly believe a team needs to develop a detailed architecture model. I’m a firm believer in modelling, but experience tells me models mean little in practice. Just because something works on paper doesn’t mean developers will follow the model in the end. Working software is the only true measure of progress for a development project.
A third quality gate should validate that a system is ready for pre-production testing (function testing, system testing and acceptance testing). With evolutionary development, project teams will have to pass through this gate each time they deliver an internal release into your QA environment.
The fourth quality gate, which in my opinion should be quite rigid, should validate that the system is ready to be deployed into production.
Scott Ambler is an independent consultant specializing in object-oriented development. His latest book is The Object Primer 3rd Edition: Agile Model Driven Development with UML 2. www.ambysoft.com