a key process area for level 5: Optimizing
The purpose of Defect Prevention is to identify the cause of defects and
prevent them from recurring.
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. Defect prevention
activities are also one mechanism for spreading lessons learned between
Trends are analyzed to track the types of defects that have been encountered
and to identify defects that are likely to recur. Based on an understanding of
the project's defined software process and how it is implemented (as described
in the Integrated Software Management and Software Product Engineering key
process areas), the root causes of the defects and the implications of the
defects for future activities are determined.
Both the project and the organization take specific actions to prevent
recurrence of the defects. Some of the organizational actions may be handled
as described in the Process Change Management key process area.
Defect prevention activities are planned.
Common causes of defects are sought out and identified.
Common causes of defects are prioritized and systematically eliminated.
Commitment to perform
Commitment 1 -- The organization follows a written policy for defect prevention activities.
This policy typically specifies that:
- Long-term plans and commitments are established for funding, staffing, and
other resources for defect prevention.
- The resources needed are allocated for the defect prevention activities.
- Defect prevention activities are implemented across the organization to
improve the software processes and products.
- The results of the defect prevention activities are reviewed to ensure the
effectiveness of those activities.
- Management and technical actions identified as a result of the defect
prevention activities are addressed.
Commitment 2 -- The project follows a written organizational policy for defect prevention activities.
This policy typically specifies that:
- Defect prevention activities are included in each project's software
- The resources needed are allocated for the defect prevention activities.
- Project management and technical actions identified as a result of the
defect prevention activities are addressed.
Ability to perform
Ability 1 -- An organization-level team to coordinate defect prevention activities exists.
- This team is either part of the group responsible for the organization's
software process activities (e.g., software engineering process group) or its
activities are closely coordinated with that group.
Refer to the Organization Process Focus key process area.
Ability 2 -- A team to coordinate defect prevention activities for the software project exists.
- This team is closely tied to the team responsible for developing and
maintaining the project's defined software process.
Members of the team coordinating defect prevention activities are usually
assigned to this team on a part-time basis and have other software engineering
activities as their primary responsibility.
Refer to Activities 1 and 2 of the Integrated Software Management key process
area for practices covering developing and maintaining the project's defined
Ability 3 -- Adequate resources and funding are provided for defect prevention activities at the project and organization levels.
- Defect prevention activities are planned into each person's
responsibilities, as appropriate.
Examples of defect prevention activities include:
- task kick-off meetings,
- causal analysis meetings,
- reviewing and planning proposed actions, and
- implementing actions.
- Management participation in the defect prevention activities is planned.
- Each software project is represented on the team coordinating defect
prevention activities for the organization, as appropriate.
- Tools to support defect prevention activities are made
Examples of support tools include:
- statistical analysis tools, and
- database systems.
Ability 4 -- Members of the software engineering group and other software-related groups receive required training to perform their defect prevention activities.
Examples of software-related groups include:
- software quality assurance,
- software configuration management, and
- documentation support.
Examples of training include:
- defect prevention methods,
- conduct of task kick-off meetings,
- conduct of causal analysis meetings, and
- statistical methods (e.g., cause/effect diagrams and Pareto
Refer to the Training Program key process area.
Activity 1 -- The software project develops and maintains a plan for its defect prevention activities.
- Identifies the defect prevention activities (e.g., task kick-off and
causal analysis meetings) that will be held.
- Specifies the schedule of defect prevention activities.
- Covers the assigned responsibilities and resources required, including
staff and tools.
- Undergoes peer review.
Refer to the Peer Reviews key process area.
Activity 2 -- At the beginning of a software task, the members of the
team performing the task meet to prepare for the activities of that
task and the related defect prevention activities.
Kick-off meetings are held to familiarize the members of the team with the
details of the implementation of the process, as well as any recent changes to
These kick-off meetings cover:
- The software process, standards, procedures, methods, and tools applicable
to the task, with an emphasis on recent changes.
Changes may be implemented as an experiment to evaluate a recommendation from a
previous causal analysis meeting.
- The inputs required and available for the task.
- The outputs to be produced with examples, if available.
- The methods to be used to evaluate the outputs.
- The methods to be used to verify adherence to the software process.
- A list of errors that are commonly made or introduced during the current
stage and recommended preventive actions for these errors.
- The team assignments.
- The task schedule.
- The software product quality goals for the task and software project.
Refer to the Software Quality Management key process area.
Activity 3 -- Causal analysis meetings are conducted according to a documented procedure.
This procedure typically specifies that:
- Each team that performs a software task conducts causal analysis
- A causal analysis meeting is conducted shortly after the task is completed.
- Meetings are conducted during the software task if and when the number of
defects uncovered warrants the additional meetings.
- Periodic causal analysis meetings are conducted after software products
are released to the customer, as appropriate.
- For software tasks of long duration, periodic in-process defect prevention
meetings are conducted, as appropriate.
An example of a long duration task is a level-of-effort, customer support task.
- The meetings are led by a person trained in conducting causal analysis
- Defects are identified and analyzed to determine their root
An example of a method to determine root causes is cause/effect diagrams.
- The defects are assigned to categories of root causes.
Examples of defect root cause categories include:
- inadequate training,
- breakdown of communications,
- not accounting for all details of the problem, and
- making mistakes in manual procedures (e.g., typing).
- Proposed actions to prevent the future occurrence of identified defects
and similar defects are developed and documented.
Examples of proposed actions include modifications to:
- the process,
- communications, and
- software work products.
- Common causes of defects are identified and documented.
Examples of common causes include:
- frequent errors made in invoking a certain system function, and
- frequent errors made in a related group of software units.
- The results of the meeting are recorded for use by the organization and
Activity 4 -- Each of the teams assigned to coordinate defect prevention activities meets
on a periodic basis to review and coordinate implementation of action proposals
from the causal analysis meetings.
The teams involved may be at the organization or project level.
- Review the output from the causal analysis meetings and select action
proposals that will be addressed.
- Review action proposals that have been assigned to them by other teams
coordinating defect prevention activities in the organization and select action
proposals that will be addressed.
- Review actions taken by the other teams in the organization to assess
whether these actions can be applied to their activities and processes.
- Perform a preliminary analysis of the action proposals and set their
Priority is usually nonrigorous and is based on an understanding of:
An example of a technique used to set priorities for the action proposals
is Pareto analysis.
- the causes of defects,
- the implications of not addressing the defects,
- the cost to implement process improvements to prevent the defects, and
- the expected impact on software quality.
- Reassign action proposals to teams at another level in the organization,
- Document their rationale for decisions and provide the decision and the
rationale to the submitters of the action proposals.
- Assign responsibility for implementing the action items resulting from the
- Implementation of the action items
includes making immediate changes to the activities that are within the purview
of the team and arranging for other changes.
- Members of the team usually implement the action items, but, in some
cases, the team can arrange for someone else to implement an action
- Review results of defect prevention experiments and take 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, and
- using a new tool.
- Track the status of the action proposals and action items.
- Document software process improvement proposals for the organization's
standard software process and the projects' defined software processes as
The submitters of the action proposal are designated as the submitters of the
software process improvement proposals.
Refer to Activity 5 of the Process Change Management key process area for
practices covering handling of software process improvement proposals.
- Review and verify completed action items before they are closed.
- Ensure that significant efforts and successes in preventing defects are
Activity 5 -- Defect prevention data are documented and tracked across the teams
coordinating defect prevention activities.
- Action proposals identified in causal analysis meetings are documented.
Examples of data that are in the description of an action proposal include:
- originator of the action proposal,
- description of the defect,
- description of the defect cause,
- defect cause category,
- stage when the defect was injected,
- stage when the defect was identified,
- description of the action proposal, and
- action proposal category.
- Action items resulting from action proposals are documented.
Examples of data that are in the description of an action item include:
- the person responsible for implementing it,
- a description of the areas affected by it,
- the individuals who are to be kept informed of its status,
- the next date its status will be reviewed,
- the rationale for key decisions,
- a description of implementation actions,
- the time and cost for identifying the defect and correcting it, and
- the estimated cost of not fixing the defect.
- The defect prevention data are managed and controlled.
"Managed and controlled" implies that the version of the work product in use at
a given time (past or present) is known (i.e., version control), and changes
are incorporated in a controlled manner (i.e., change control).
If a greater degree of control than is implied by "managed and controlled" is
desired, the work product can be placed under the full discipline of
configuration management, as is described in the Software Configuration
Management key process area.
Activity 6 -- Revisions to the organization's standard software process resulting from
defect prevention actions are incorporated according to a documented procedure.
Refer to Activity 1 of the Organization Process Definition key process area for
practices covering the organization's standard software process.
Activity 7 -- Revisions to the project's defined software process resulting from defect
prevention actions are incorporated according to a documented procedure.
Refer to Activity 2 of the Integrated Software Management key process area for
practices covering the project's defined software process.
Activity 8 -- Members of the software engineering group and software-related groups receive
feedback on the status and results of the organization's and project's defect
prevention activities on a periodic basis.
The feedback provides:
- A summary of the major defect categories.
- The frequency distribution of defects in the major defect categories.
- Significant innovations and actions taken to address the major defect
- A summary status of the action proposals and action items.
Examples of means to provide this feedback include:
- electronic bulletin boards,
- newsletters, and
- information flow meetings.
Measurement and analysis
Measurement 1 -- Measurements are made and used to determine the status of the defect
Examples of measurements include:
- the costs of defect prevention activities (e.g., holding causal analysis
meetings and implementing action items), cumulatively;
- the time and cost for identifying the defects and correcting them,
compared to the estimated cost of not correcting the defects;
- profiles measuring the number of action items proposed, open, and
- the number of defects injected in each stage, cumulatively, and over
releases of similar products; and
- the number of defects.
Verification 1 -- The organization's activities for defect prevention are reviewed with senior
management on a periodic basis.
The primary purpose of periodic reviews by senior management is 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.
These reviews cover:
- A summary of the major defect categories and the frequency distribution of
defects in these categories.
- A summary of the major action categories and the frequency distribution of
actions in these categories.
- Significant actions taken to address the major defect
- A summary status of the proposed, open, and completed action items.
- A summary of the effectiveness of and savings attributable to the defect
- The actual cost of completed defect prevention activities and the
projected cost of planned defect prevention activities.
Verification 2 -- The software project's activities for defect prevention are reviewed with the
project manager on both a periodic and event-driven basis.
Refer to Verification 2 of the Software Project Tracking and Oversight key
process area for practices covering the typical content of project management
Verification 3 -- The software quality assurance group reviews and/or audits the activities and
work products for defect prevention and reports the results.
Refer to the Software Quality Assurance key process area.
At a minimum, the reviews and/or audits verify that:
- The software engineering managers and technical staff are trained for
their defect prevention roles.
- The task kick-off meetings and causal analysis meetings are properly
- The process for reviewing action proposals and implementing
action items is followed.
Table of contents
Forward one chapter