 |
|
 |
|
| Home > Methodologies > Metrics | Search: | for |
|
|
|
|
|
Software Defect Prevention - In a Nutshell
Organizations face many problems that impede rapid development of software systems critical to their operations and growth. The challenge in any software product development lies in minimizing the number of defects. Occurrence of defects is the greatest contributor to significant increases in product costs due to correction and rework time. Most defects are caused by process failures rather than human failures. Identifying and correcting process defects will prevent many product defects from recurring. This article will present various tools and techniques for use in creating a Defect Prevention (DP) strategy that, when introduced at all stages of a Software life cycle, can reduce the time and resources necessary to develop high quality systems. Specifically, how implementing a model-based strategy to reduce Requirement Defects, Development Rework and Manual test development efforts will lead to significant achievements in cost reduction and total productivity. Defect Prevention Mature IT organizations have an established software process to carry out their responsibilities. This process is enhanced when DP methodologies are implemented to improve quality and productivity and reduce development costs. Figure 1 clearly depicts that identifying defects late in the game is costly.
A model for an enhanced Software Process, including a DP strategy, is presented in Figure 2. Adopting a DP methodology will allow the organization to provide its clients with a product that is "of High Quality and Bug Free."
On a macro level defects can be classified and filtered as depicted in Figure 3.
Features of Defect Prevention To assist in the successful implementation of a DP strategy, members of the software-engineering group and other software-related groups should receive training to perform their DP activities. Training should include software quality assurance, configuration management and document support and focus on DP and statistical methods (e.g., cause/effect diagrams and Pareto analysis). Creation of an Action Plan plays a key role in the implementation process. At the beginning of a software task, the members of the team meet to prepare for the task and related DP activities. A kick-off meeting is held to familiarize members of the team with details of the implementation process. Included in the meeting is information related to the software process, standards, procedures, methods, and tools applicable to the task, with an emphasis on recent changes; inputs required and available for the task; expected outputs; and methods for evaluation of outputs and of adherence to the software process. A list of common errors and recommended preventive actions are also introduced along with team assignments, a task schedule and project goals. Periodic reviews are conducted by each of the teams assigned to coordinate DP activities. During the reviews, action items are identified and priorities set based on a causal analysis that determines:
Additional DP activities involve reviewing results of defect prevention experiments and taking actions to incorporate the results of successful experiments into the rest of the project or organization, as appropriate. Examples of defect prevention experiments include using a temporarily modified process or a new tool. Data Documentation And Measurement The DP teams oversee the work product in a "managed and controlled" environment with changes incorporated in a controlled manner. If a greater degree of regulation is desired, teams can invoke the full discipline of configuration management, as is described in the Software Configuration Management key process area. Measurements are made and used to determine the status of DP activities. Examples include the costs mentioned above; the number of action items proposed, open, and completed; the number of defects injected in each stage, and the overall number of defects. Verifying Implementation. The organization's activities for defect prevention are reviewed with senior management on a periodic basis to provide awareness of and insight into, software process activities at an appropriate level of abstraction and in a timely manner. The time between reviews should meet the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available. Management reviews include major defect and action categories and the frequency of distribution across those categories; significant actions taken to address major defect categories; and a summary of proposed, open and completed action items. In addition, management should review the effectiveness of DP activities, the savings attributable to the activities, and their actual and projected cost. Once the effectiveness of the activities are verified, it is important for the team to ensure that significant efforts and successes in preventing defects are recognized. Case Study The Reference Line The Beizer Taxonomy included ten major categories, each of which was divided into three levels, resulting in a 4-digit number which specifies unique defects. The ten top level categories were: 0xxx PlanningThe causes of the defects as determined by the engineers doing the classification, fell into four major categories: Communication, Education, Oversight and Transcription. In creating the reference line, detailed interviews with 24 software engineers took place. The interviews allowed a full understanding of the reason for each defect, classification of the cause and an understanding of defect prevention activities. This data mining was performed on all defects, resulting in a series of classification tables and a Pareto analysis of the most common problems. The results of the pareto analysis according to the Beizer Taxonomy top level categories are presented below with the breakdown in descending order.
The final step was to compare the numbers and types of TETRA Release 2 defects with those of the reference line. The effectiveness of the prevention tool-set was measured in the quantity and types of defects found in the second release of the project. The effective prevention actions could then be integrated into the OSSP to improve quality and cycle time for all the projects in MCIL. The impact on the OSSP, including changes to Review Guidelines and changes to the Phase Kickoffs, are considered part of the PIE results. Expected Outcomes
Implementation of Improved Actions In each progressive phase, engineers became more adept at recording the defects using Distributed Defect Tracking Systems and at performing causal analysis. They became more open minded about reporting and recording their own defects, understanding the importance of a systematic tracking approach to the quality of the product and the process. Many TETRA engineers expressed satisfaction with the causal analysis process and kickoff meetings, which made them feel better equipped to prevent defects and improved their general attitude towards the software process. Both technical and business staffs considered the PIE a positive process, which provided an advantage in creating better quality products, and reducing cycle time of the development process. As such, the TETRA development group adopted several changes to its processes to accommodate the DP environment. Internal dissemination outside of the TETRA development group, will begin with a presentation of the DP method to the Software Engineering Process Group (SEPG), the owner of MCIL's OSSP. This group will analyze results of the PIE project and update the OSSP accordingly. The SEPG will also be responsible for deploying the new process and training the other development groups. This will occur through a series of technical meetings with engineers and managers, who interact with DP activities, the PIE and the updated OSSP. Results and Conclusion
The absolute reduction in defects, which relates to the % Improvement shown in the above table, can be observed in the following figure.
The obvious observation is that a higher percentage of the defects migrated to later phases of the development process: from Requirement Specifications, Preliminary Design and Detailed Design, to Coding. In Tetra Release 1, 76.5% of the defects are in the Requirement and Design phases and only 23.4% are in Coding, while in Tetra Release 2, 45.5% of the defects are in Requirement and Design and 54.5% are in Coding. This implies that the DP methods employed in the early phases of development were very effective. The % Improvement column shows the improvement within each development phase with respect to the absolute number of defects. This is a different view of the improvement in the number of defects, partially attributable to the Improvement Actions. Another comparison was made in respect to the Cause category with the following results.
The observation here is that the differences are not significant. The largest bulk of the defects are caused by human errors. Lessons Learned
Acknowledgements About The Author References Reproduction Without Permission Is Strictly Prohibited – Copyright Requests Publish an Article: Do you have a Six Sigma tip, learning or case study? Share it with the largest community of Six Sigma professionals, and be recognized by your peers. It's a great way to promote your expertise and/or build your resume. Read more about submitting an article. "The Bottom Line" Links
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
| Home | Discussion Forum | Event Calendar | Job Shop | |
 | |
| Link To iSixSigma | Rate This Page | Report A Problem | Free Content For Your Site | Submit Article For Publishing | |
| |
| Terms of Service. ©2000-2009 iSixSigma. All rights reserved. v3.0lb, 2.0-A-244 |
About iSixSigma · Contact Us · Privacy Policy · Site Map. |