Society for Software Quality Spring 1996 Grant Winner
Defect Prevention
by Sunita Menon, University: University of Houston, Clearlake
Abstract:
This essay begins with an introduction to the Defect Prevention Model, followed by a discussion of the various blocks comprising this model. Several defect prevention techniques practiced in industry and their advantages are then discussed, with special reference to the assumptions underlying their implementation. The essay concludes with a brief summary of the essential ingredients required for implementing a defect prevention program in an organization.
Introduction:
Defect Prevention forms the essence of Total Quality Management. The Software Engineering Institute has identified Defect Prevention as a key process area in level 4 of the Capability Maturity Model (CMM). For successful implementation of a defect prevention program in an organization, the following systems should be in place: the right process, and some means of measuring the effectiveness of this process. But measurement alone is not sufficient it should be followed by analysis, feedback and suitable action to improve the process on the basis of this feedback.
Defect Prevention Model:
The requirements mentioned in the previous section are addressed in the defect prevention model shown in Fig. 1, which is a self correcting closed loop system designed for continuous improvement. Let us discuss each block of this model in detail.
The Process:
Defect prevention is achieved not by correcting the product, but by correcting the process that produces this product. The process model defines the various activities to be performed during the course of the project life cycle. For each phase of this life cycle model, the entry and exit criteria should be clearly defined and documented.
These entry and exit criteria should place emphasis not only on documentation, but also on the review of this documentation, so that wrong or ambiguous specifications do not give rise to defects in the upcoming phase.
Metric Data Collection:
The effectiveness of the process should be determined through periodic measurements made at various points in the software life cycle. In other words, an organization wide metrics program should be in place. Examples of metric data are data collected from inspections and data collected at the end of each phase. The former may be faults per line of code, rework time for each fault, fault severity level, fault category, etc., and the latter may be productivity and cost of quality. These metric data acts as an important indicator of process quality. Using the data collected from various projects, an organization wide metrics repository can be built up, which can be used to provide important inputs for estimations, fault projections and goal setting.
Analysis and Feedback:
Metric data collected should be analyzed to determine if the process is doing what it has been designed to do. For example, if the number of faults detected in a phase is more than the projected number of faults, then an analysis should be performed to isolate the "vital few from trivial many". Pareto chart generation is a proven technique for this purpose. Once these vital few have been identified, either in terms of their number or their severity, steps can be taken to determine the root cause of the problem. Ishikawa's cause-effect diagram can be used to perform this root cause analysis.
After the root cause of the problem has been determined, this information should be disseminated through reports, presentations, or recorded minutes of casual analysis meetings. This feedback should be utilized to perform the appropriate corrective action (which may involve changing or just fine tuning the process), so that the problems identified do not re-occur. For example, an excess of documentation's errors in a series of design documents may act as a pointer to the fact that documentation's standards were not finalized prior to design. If this is proven through root cause analysis, then finalization of documentation standards for a phase can be made an entry criterion for that phase.
Defect Prevention Techniques:
Through the application of the principles underlying continuous improvement, several defect prevention techniques have been identified and implemented in various organizations. A few of them are described below:
Preview Meetings: Before the beginning of each phase in the project life cycle, a preview meeting is held to discuss the problems anticipated and possible workarounds. Documentation of coding standards if relevant to that phase are also finalized. A list of error categories is drawn up, so that all team members are clear on what constitutes an error. If historical data on commonly occurring errors is available from previous projects, then strategies can be formulated for avoiding these errors. For the preview meeting to be effective, it is important that an agenda is prepared in advance, so that proper groundwork is done by the team and the meeting remains focused.
Post Mortem Meetings: These are held at the end of each phase or at the end of the project to discuss what went wrong, what went right, and what could have been done better. Basically, the focus is on lessons learnt, so that past mistakes can be avoided in future projects or upcoming phases of the same project. The minutes of these meetings, if made available across the organization, can be used to provide direction to new projects and help them in defect prevention.
Checklists: Checklists are important tools for defect prevention, and are prepared during preview meetings or even as the project progresses. These are referred to by the developer before he begins his work, so that he can prepare for the pitfalls ahead. For the checklists to be effective, it is important that they are short and meaningful, so the focus is not diverted through verbose sentences. Checklists are very useful when the language or domain is new to the programmer or designer.
Concurrent coding and unit testing: Instead of waiting until the entire coding is completed, unit testing can be done in parallel with coding. If each subprogram is tested as soon as it is coded, then the analysis of errors found in these subprograms can be used to prevent their re-occurrence in the remaining portion of the code.
Reuse: Although reuse was identified mainly for cycle time reduction, it is also gaining widespread use as a defect prevention strategy. A code proven to work in one application can be safely used in other similar applications without the fear of inherent bugs. Organization wide reuse repository can thus play an important role in defect prevention. However, it is important to ensure that the code which goes into the reuse repository has been fully tested. Interfacing issues are critical in functions being reused, hence the module under reuse should be perfectly matched to the application under consideration.
Automation: Automation code generators offer the best method of defect prevention and will play an important role in the coming years. However, the code generators themselves should be thoroughly tested before use. The development of code generators is economical only if the applications being developed are the same type.
Conclusion:
For an organization to implement the above mentioned techniques and build an effective defect prevention program, an organization wide metrics program should be in place. This requires commitment to quality on the part of the management as well as software engineers. The entire defect prevention program depends on the authenticity of data collected, hence the data reported by the software engineers should be accurate and complete. Software developers have yet to learn to work with the discipline practiced by members of others professions, and this discipline is the foundation required for successful defect prevention.
Return to the Grant-in-Aid Page
Go to How to Join
Last modified on Sunday, September 1, 1996 | Society for Software Quality | http://www.ssq.org/ |