Getting the Most From Your Quality Initiatives

Process improvement methods such as Capability Maturity Model (CMM), Capability Maturity Model Integration (CMMI) and ISO 9000-3 offer software developers a standardized framework for fine-tuning development life cycles. Using such methods, it's possible to get your software development life cycle to the point that continuous improvement is the standard operating procedure.

It's possible, but it isn't likely.

Process improvement methods, while a valuable idea, do nothing to directly address error prevention. They attempt only to regulate processes with the intention of preventing errors. Without automation, these initiatives often fall short of their stated goals. Why? The answer is simple. Because they cannot actually implement practices that enforce and support their written procedures.

A short list of my main issues with process improvement initiatives includes the following:

  • They are vague. They outline only a plan for quality control. They don't tell you exactly what to do.
  • They regulate human interactions, not actual manufacturing processes.
  • They rely too much on manual labor to set up and maintain. Certification comes only when you have a written document in place that outlines how you want to improve your processes. This is backward. Certification should come only when you actually have real process improvement, not just a written plan.
  • They are difficult to automate, but without automation they decay and eventually become useless.
  • The guidelines for auditors and for the process of auditing are vague. Any system that involves human oversight is open to abuse. This part of the system is badly set up. How do you know that your auditor is following the guidelines? How do you know that they aren't interpreting the written procedures in a way that you had not intended?

The real problem with process improvement initiatives is that there is no practical way to get these initiatives off the page and into your software development life cycle. What do you need to measure? How do you behave in the group? How do you improve your processes when errors are found? How do you ensure that those errors don't reoccur? How do you automate process improvement guidelines?

Unfortunately, process improvement methods have precious little to say about such practical details. What is needed is a comprehensive method for addressing these concerns, for really putting automated error-prevention practices into the software development life cycle, and keeping them there. This is the purpose of automated error prevention (AEP).

Based on W. Edwards Deming's total quality management philosophy, the AEP methodology improves software quality and reliability by combining the necessary intelligence, tools, techniques and services to automatically prevent errors in software.

What is exciting about the AEP methodology is that it helps the development group -- especially project managers and architects -- map and fulfill standard process improvement initiatives. AEP allows you to put into practice many of the requirements mandated in these initiatives; in fact, when using the AEP methodology, what you find is that quality initiatives such as CMM, CMMI and ISO 9000-3 already have elements of AEP built into them.

For instance, in CMM, there are two key process areas (KPA) in Level 2 known as Software Project Planning and Software Configuration Management. These KPAs help you create repeatable project planning and configuration management processes. Without AEP, however, the issues these KPAs address are nothing more than suggestions. You need to determine the functional requirements of your application, address planning methods and determine how the project activities will be tracked and managed. Again, the problem here is, How do you take these paper initiatives and put them into practice?

AEP helps you define and implement these important KPAs by precisely determining who will do what, how, and how those tasks will be automated. AEP defines the roles of each "actor" or member in the group -- developer, tester, architect, project manager and so on -- to determine task ownership. For instance, who is in charge of creating and maintaining coding standards (the architect), where they should be stored (the team server), who should use them (the developers) and when (upon checking code into the source code repository).

To measure the requirements of the KPAs in CMM (or any quality initiative), AEP takes well-known error prevention practices -- coding standards as mentioned before, but also unit testing, load testing, monitoring, regression testing, defensive programming and others -- and puts them into place throughout the software development life cycle.

To ensure that these practices are used uniformly, all tools used by development are identically configured. Not only does this fulfill the requirements of the Configuration Management KPA, but it also helps you immediately address higher-level quality concerns -- peer reviews, intergroup coordination, integrated software management, training, process change management and defect prevention.

In order to do this, AEP provides a built-in infrastructure that enables the group to measure practices and collect valuable data to understand how well those practices are working. This "measure and remember" capability allows project managers and architects to immediately understand how close a project is to completion, what needs further work, and how well all AEP practices are working. Since management understands how development is behaving, the group architect can adjust test behavior in any way necessary to improve the process.

This insight is a key part of the Software Project Planning KPA in Level 2, for example, but it is also an important part of the Quantitative Process Management and Software Quality Management KPAs in Level 4.

Knowing what you are doing on a daily basis, and knowing how to measure your activities to see if they are stable, is the key to achieving Level 4 in CMM. Because you are able to stabilize your processes using AEP, you are able to automatically rocket your software development life cycle to the continuous process improvement, the fifth and final level in CMM. In this stage, defect prevention is enabled and maintained, without decay, because of the AEP infrastructure.

Using the AEP methodology, the requirements in CMM don't have to be fulfilled individually and in sequence, but can be fulfilled vertically since the infrastructure put into place for Level 2 KPAs is also used to measure KPA requirements in Levels 3, 4 and 5. In this way, the AEP methodology makes full life-cycle process improvement an achievable and practical goal.

Copyright © 2004 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon