ODC - Orthogonal Defect Classification

Introduction to Software Defects

The notion of a defect in the software development and service industry tends to be different from the classical textbook definitions of fault, error and failure [Ed.92]. Essentially, it wraps several issues into one, sometimes obliterating the purported difference between error and fault, and at other times, identifying issues which by the formal definition of these terms may not fit into either. Accounts of what makes a software defect can often be challenged on the grounds of expected behavior of service, but the debate usually never ends since the causal train of events can often be perpetually pursued. Thus, in the realm of definition, there are philosophical differences between concept and practice, which should not appear as a surprise. The concepts get better with our advancement in engineering, while changes in practice, which exist in embodiments of tools and processes, are guided by time constants of changes in culture, which are often longer.

  
Figure 1: The Lifecycle of a Software Defect

To understand what a software defect is, it is helpful to have some idea of software development and its processes, or lack thereof. Although we do not need to get into the debate of what software development processes are and how many there are, it is reasonable to assume that there is usually some design, followed by development and field use. Figure 1 illustrates the lifecycle of software defects in the software development industry relative to such a process. It is a fallacy to believe that errors get injected in the beginning of the cycle and are removed through the rest of the development process. Errors occur all the way through this process. The fixing of these errors may occur sooner or later, deepening on knowledge of these errors and the ability to institute change into the product.

As a result of these errors, a change is necessary and that change is what I call a Defect. Tracking these changes is, in some quarters, reasonably common. However, there are development processes that are quite ill defined, where there may be no retrievable record of the change. Yet, for progress of the product, the change must have occurred and that change is the defect.

There is a subtlety in saying that the necessary change is the defect. This is because it could be the case that a change is necessary but was not executed. Someone may have forgotten about it, or there may have been no resource to fix it. It is still a defect, since it was deemed a necessary change.

Treating the necessary change as a defect ties the metaphysical concept of a fault, error, or failure to a physical event which makes this notion much more tractable. No matter what the development environment, the activity is specific and can become the anchor point from which other measurements can follow.

• Defects during development
• Defects in the field