29-05-2012, 03:28 PM
USING DEFECT ANALYSIS FEEDBACK FOR IMPROVING QUALITY AND PRODUCTIVITY IN ITERATIVE SOFTWARE DEVELOPMENT
USING DEFECT ANALYSIS FEEDBACK FOR.pdf (Size: 184.53 KB / Downloads: 97)
Introduction
A project using the traditional waterfall model of developing software
assumes that that requirements are stable, and delivers the entire software at
one shot in the end. Unchanging requirements, unfortunately, do not exist in
reality, and the “big bang” approach of delivery entails heavy risks, as the
users do not know till the very end what they are getting. To alleviate these
two key limitations, an iterative development model can be employed. In an
iterative development, software is built and delivered to the customer in
iterations – each iteration delivering a working software system that is
generally an increment to the previous delivery.
Measurements for Defect Analysis
In some sense the goal of all methodologies and guidelines is to prevent
defects. For example, a design methodology gives a set of guidelines that if
used will give a good design. In other words, the design methodology aims to
prevent the designer from introducing design defects by guiding him along a
path that produces good and correct designs.
However, by defect prevention (DP) we mean learning from actual
defect data from a project with the goal of developing specific plans to
prevent defects from occurring in the future. As the main goal of DP is
reduction in defect injection and consequent reduction in rework effort, it is
best if suitable measurements are made such that impact of DP can be
quantitatively evaluated.
Deploying Defect Analysis and Prevention
In a project, to use DP, all the DP related activities should be planned, like
any other major task. We propose that the project planning stage be
augmented by the following tasks to support defect prevention activities:
• Identify defect prevention team within the project
• Have a kick-off meeting and identify existing solutions
• Set defect prevention goals for the project
• Get the DP team trained on DP and causal analysis, if needed
Most of the activities relating to DP planning are self-explanatory. A project
identifies a team that will do perform the DP analysis (obviously, the actual
solutions that are to be executed to prevent defects will have to be performed
by everyone in the project.) A kick-off meeting is held in the start to raise the
awareness and identify the solutions that may be available somewhere in the
organization. The training for DP team on DP and causal analysis is done, if
needed.