| Defect management is the process of managing and | | | | Currently there are defect tracking, also referred to |
| removing bugs from software or flaws from | | | | as issue tracking, software solutions available that |
| hardware. The primary goal is to prevent flaws, but | | | | have a variety of defect tracking tools to help in this |
| since total prevention is impossible in every program | | | | laborious process. This kind of software can provide |
| environment, the secondary goal becomes minimizing | | | | functions that other programs do not provide. One |
| the effect of a defect. Whenever possible debugging | | | | challenge of defect management is to keep as many |
| should occur before the product is released. Many | | | | people informed about the progress of defect |
| software companies now implement teams to | | | | resolution. Software tracks all changes for each |
| perform this aspect of the development. | | | | defect and reports the progress to management. |
| Defect management is not a linear process; it is more | | | | Therefore management always knows what stage |
| like a cycle. The cycle begins with programmers who | | | | of development the program is in. Also some bugs |
| try to prevent defects. They implement exception | | | | are common; software can allow programmers to |
| handling, or check for input that is consistent. The | | | | design tests that run automatically. And last, |
| next step in the process is called deliverable baseline. | | | | software provides a central location for all information |
| This occurs when a milestone in a development | | | | regarding defect resolution. So it is easily, and in |
| project has been reached; the product is then ready | | | | real-time, accessed by development teams. |
| for further development. After this step, any | | | | There are many software solutions for defect |
| changes to the product are tracked and controlled. | | | | tracking. One important feature is test automation; it |
| The next two steps are defect discovery and | | | | is useful to have a built-in library and the ability to |
| defect resolution. Resolution is done on a risk | | | | create automated tests. Software should also include |
| schedule meaning the defects that pose the most | | | | the ability to prioritize the handling of issues and bugs |
| risk to the implementation of the software are | | | | based on their risk level. It should be able to generate |
| revolved first. All changes and resolutions are | | | | reports and defect resolution summaries which are |
| documented. The second to last step is process | | | | accessible from secure, remote locations; this feature |
| improvement. Here the goal is to identify and analyze | | | | is especially useful for inter-company or |
| the process in which the defect took place as to | | | | across-department projects. Management should also |
| prevent future defects. And last, is reporting the | | | | be allowed to create reports tracking a particular bug |
| defect to assist management with the progress of | | | | or an entire project. |
| the projects risk and development. | | | | |