1. UNIT-V
DEFECT PREVENTION
Defect prevention (Arun)

2. Contents: Principles of software defect prevention
Process changes for defect prevention
Defect prevention considerations
Managements role
Frame work for software process change
Managing resistance to software process change
Case studies
Defect prevention (Arun)

3. Principles of Software Defect Prevention
Fundamental 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.
Defect prevention (Arun)

4. The principles of S/W defect 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 process
Process improvement takes time to learn.
Defect prevention (Arun)

5. Steps of Software Defect prevention
Defect reporting
Cause analysis
Action plan development
Action implementation
Performance tracking
Starting over
Defect prevention (Arun)

6. 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.
Defect prevention (Arun)

7. Error 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
Defect prevention (Arun)

8. Cause 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.
Defect prevention (Arun)

9. 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?
Defect prevention (Arun)

10. 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.
Defect prevention (Arun)

11. 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
Defect prevention (Arun)

12. Defect prevention (Arun)

13. 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.
Defect prevention (Arun)

14. 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:
Defect prevention (Arun)

15. 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.
Defect prevention (Arun)

16. Process Changes for Defect Prevention
Kickoff 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.
Defect prevention (Arun)

17. A feedback system is established to ensure that the results are communicated to the professionals and that their contributions are recognized.
Defect prevention (Arun)

18. Defect Prevention 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?
Defect prevention (Arun)

19. 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.
Defect prevention (Arun)

20. 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.
Defect prevention (Arun)

21. Framework for software 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.
Defect prevention (Arun)

22. 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.
Defect prevention (Arun)

23. Managing resistance to 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:
Defect prevention (Arun)

24. 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?
Defect prevention (Arun)