UNIT-V DEFECT PREVENTION 1Defect prevention (Arun)

UNIT-VUNIT-VDEFECT PREVENTION

1Defect prevention (Arun)

Contents:Contents:Principles of software defect preventionProcess changes for defect preventionDefect prevention considerationsManagements roleFrame work for software process

changeManaging resistance to software

process changeCase studies


Principles of Software Defect Principles of Software Defect PreventionPreventionFundamental objective of software defect

prevention is to make sure that errors, once identified and addressed, do not occur again.

Defect prevention cannot be done by 1 or 2 people. Everyone must participate by faithfully executing the process.

It takes time to learn defect prevention well, but if everyone on the project participates, it can transform an organization.

To prevent these endless repetitions, we need to understand what causes these errors and take conscious action to prevent them.


The principles of S/W defect The principles of S/W defect prevention are:prevention are:The programmers must evaluate

their own errors.Feedback is an essential part of

defect prevention.There is no single cure-all that will

solve all the problems.Process improvement must be an

integral part of the processProcess improvement takes time to

learn.4Defect prevention (Arun)

Steps of Software Defect Steps of Software Defect preventionpreventionDefect reportingCause analysisAction plan developmentAction implementationPerformance trackingStarting over


Defect Reporting:Defect Reporting:A significant amount of

information must be gathered at the time a defect is identified.

For problems found in test, the person who finds or fixes the problem is often not the same as the one who originally made the error.


Error Cause CategoriesError Cause Categories Few categories will cover most of the errors in

a software system. six categories of errors that he suggests for defect prevention analysis are:

Technological Organizational Historic Group dynamic Individual Other causes and inexplicable causes


Cause analysisCause analysis Shortly after the time all the products modules have

completed detailed design, cause analysis sessions should have been held for all problems identified during the design inspections.

After the last module has completed each test phase, cause analysis meetings should have been held for all defects found during that test phase for these modules.

The later modules, cause analysis meetings should be held for all problems found for the first few modules as soon as possible after they have completed each development inspection or test phase.

Cause analysis reviews should be held on a product after a reasonable number of user problems have been found after customer release.

Cause analysis meetings should be held often enough to permit completion in one and a half to 2 hrs. Longer meetings will be less effective and harder to schedule.


Objective of the cause analysis meeting is to determine the following:

What caused each of the defects found to date? What are the major cause categories? What steps are recommended for preventing these

errors in the future? What priorities are suggested for these actions?


Action team:Action team:Key action team responsibilities

are: Priorities all action items Establish an implementation plan for the highest-

priority items Assign responsibilities Track implementation Report to management on progress Ensure that all success stories are recognized and the

responsible individuals identified. Continue with the next priority items.


Members of action team include the following:

Manager responsible for action implementation, often the process group leader.

A process group representative The education manager A tools and methods specialist 1 or more management representatives from the

involved product groups Quality assurance Configuration management



Tracking Action Progress:Tracking Action Progress:No one thinks much about tracking the

process changes required for defect prevention.

Every action must be logged and tracked and tracked and its status periodically reported.

Every delay in prevention action permits more errors to be made.


Prevention feedback:Prevention feedback:Actions they can take to prevent or

detect them at the earliest possible time

Awarness effort should involve training programs for the new tools and methods and special seminars on the most recent prevention experiences and plans.

this involves the full project team and

covers the following items:14Defect prevention (Arun)

The key phase activities are reviewed, including the inputs required, the outputs to be produced, and the key methodologies to be used. Any input problems are identified and resolved.

The error checklists are reviewed to ensure that all team members are aware of the errors most common to this phase and the actions recommended for their prevention.

Goals are set for the Phase. This includes the entire team’s commitment to defect injection and removal targets for the phase.


Process Changes for Defect Process Changes for Defect PreventionPreventionKickoff meeting- check list, review guidelines,

or new tools and methods.The data from the process task is entered in

the process database.A cause analysis review meeting is held as

part of task exit to examine the problems.A cause analysis team periodically reviews the

process database to determine any cross project problems.

All improvements suggestions are retained in the action tracking system.

An action team decides on priorities, select the items for immediate implementation and assigns implementation responsibility.


A feedback system is established to ensure that the results are communicated to the professionals and that their contributions are recognized.


Defect Prevention Defect Prevention Considerations:Considerations:Some Questions frequently asked about prevention are:

Where should one start?What is the role of tools & technology?What does it costs?What is management’s role?


Management Role:Management Role:Understand the quality situation

and whether they are prepared to take action. While these questions were developed for hardware manufacturing, they apply equally to software. Software managers should answer questions and then, unless satisfied with the result, proceed to implement the actions discussed in this chapter.


Assuming you decide to move ahead with defect prevention, the next steps are:

Meet with your team and make a joint commitment to defect prevention.

Select a trial project area and develop an introduction plan. Appoint an action team manager and assist in staffing the

action team. Develop kick-off packages for the pilot project. Install any needed tools and support. Conduct appropriate seminars and training. Launch a pilot defect prevention program. Monitor progress, and take corrective action as needed. After some initial are modest, prepare for broad

introduction. If the changes are substantial, conduct another pilot.

Finally, defect prevention is not a modest change in the software process; it is an entirely new way of life. It will transform your software organization.


Framework for software Framework for software process change:process change:Sell top management: additional resources and

consistent support. Senior managers will not provide such backing until they are convinced that the improvement program makes sense.

Get technical Support: few technical professional whose opinions are widely respected. It is directed to implement something they don’t believe in, it is much more likely to fail.

Involve all management levels: while the senior managers provide the resources and the technical professionals do the work, the middle managers make the daily decisions on what is done.

Establish an aggressive and a conservative plan: While senior management will be attracted by an aggressive strategy, the middle managers will insist on a plan that they know how to implement. It is thus essential to be both aggressive and realistic.


Stay aware of the current situation: It is essential to stay in touch with current problems. Issues change, and elegant solutions to last year’s problems may no longer be pertinent. While important changes take time, the plan must keep pace with current needs.

Keep Progress visible: People easily become discouraged if they don’t see frequent evidence of progress. Advertise success, periodically reward the key contributors, and maintain enthusiasm and excitement.


Managing resistance to Managing resistance to software process change:software process change:It is also wise to anticipate the

common questions that concern managers and professionals.

Many of these may be simple requests for information, but some are almost unanswerable and are often intended to detail the change effort.

The next several paragraph discuss the following questions:


What makes the process maturity model right?

Why should we have an SEPG?Why can’t software quality

assurance do the SEPG job?As my process improves, do I

need to retain SQA?Why is defect prevention so

important?What is the financial return from

this investment?Why do this work right now?


UNIT-V DEFECT PREVENTION 1Defect prevention (Arun)

Documents

defect prevention analysis

defect prevention arun

prevention action

prevention feedback

unitv defect prevention

recent prevention experiences

software process

cause analysis meetings