Defect Prevention in SDLC Phases
Defect Prevention is one of three key process areas (KPAs) identified to achieve a level 5 maturity in terms of the SEI-CMM Level 5 mandate. As expressed here - "Defect Prevention involves analyzing defects that were encountered in the past and taking specific actions to prevent the occurrence of those types of defects in the future. The defects may have been identified on other projects as well as in earlier stages or tasks of the current project". Most readers working in mature software organizations would have heard this before. But, what craves special attention is the point regarding "early stages or tasks of the current project".
Defect Prevention and related activities of the genre are unfortunately considered to be post-project activities with the focus on providing enough inputs to prevent similar defects in subsequent projects. There are of course no complaints about this. But, the problem with relegating this as a post-project activity is that you miss on improving in each phase of your current project.
I have always believed that it is important to nurture defect prevention into each phase of an executing project. Make no mistake; this is an important investment that is going to save a lot of long term headaches for your project.
Most companies in the world are often in a race to recruit the best personnel coming out universities and colleges in the world. The plan is to invest in this talent and train them over a term to reap benefits in actual production environments. Despite trainings, it is natural that these personnel need time to adapt to live working environments. When such a fresher is assigned to code a particular module, it is normal that some habits of college-style coding creep into the work product, which could in turn manifest into much bigger problems at the end if not caught and controlled in advance. Some typical problems seen include non-conformance to coding standards, writing non-performant code, lack of consideration of the failure case in a conditional statement, initialization of variables etc. A planned code review at the end of the coding phase would result in a large number of such problems being detected, resulting in the possible shifting of focus from the review of actual functionality to unnecessary details. Besides, sending the code back to the developer to fix all such problems would result in a good amount of change in the baseline code, with the resultant possibility of new defects being introduced - and hence a need for another code review. This could introduce unwanted cycles of fix and review - affecting schedule, confidence in work achieved. Matters compound when customers ask why such a large number of defects were being detected now.
Defect Prevention inserted in each phase of the project could help prevent such a situation. Adopting a stop, review, analyze and feedback approach during completion of around 10% or 20% of the current phase would help. Perform a vigorous review of code completed at 10% of the coding phase, analyze the defects, detect the root causes, plan measures and feedback to the developers. Most defects that are detected at such check points are defects related to standards, coding styles, carelessness, lack of experience in needing to consider both the positive and negative conditions etc. Pointing this out early will prevent repetition of such defects in the remaining 80% of the code, thus allowing a more meaningful end phase review with the focus being on functionality and achievement of other quality attributes. Such specialized focus will help unearth meaningful, quality and complex defects fixing which will definitely result in code which oozes confidence within expected timelines.
Even in projects having regular experienced team members, such a phase is important to understand the course of the phase early enough and signal corrections to prevent end phase frustrations and long term project complications.
In the Requirements phase, analysis and documentation of a single detailed (important) business case or subset of business cases and discussions with the customer to check if all his needs are well covered - can help in covering the remaining business use cases with the necessary details on understanding the customer's thinking process. Doing such an exercise could help uncover earlier unexpressed thoughts/recommendations in customer's minds which could help in other use cases going forward.
In the Design Phase, a thorough review of the high level design/architecture would help in preventing a wrong course in the detailed design. Review on 10%-20% completion of the detailed design, will help in validating if the designers have understood the requirements correctly early enough to enable a course correction. A review here also enables correcting incorrect assumptions, incorrect documentation styles etc. which are basic defects which cause immense heartburn if caught in the end-of-phase review resulting in preventable rework.
With regard to Testing, a review of created test cases at 10%-20% completion will help detect if the test case creator is indeed being imaginative enough in creating cases for normal, boundary and error cases with a good understanding of the functionality. Problems in understanding functionality can be disastrous if not caught early enough - as test cases created might not be meaningful or penetrative enough to guarantee a good quality end product.Ofcourse, the usual problems of documentation style etc. can be corrected here.
Remember the old adage - "An apple a day keeps the doctor away". Detecting defects and correcting course early enough in each phase, keeps end project complexities away. Insist on incorporating defect prevention activities in each phase, and reap the benefits of a good quality product with reduced frustrating rework!
