Software Quality Framework

The next generation of a complete software Quality framework via ODC.

We at SW-Quality.com provide training and implementation of a best in class Software Quality Framework via ODC. The ODC quality framework is applicable to most industries without any modification.

We have institutionalized this framework in Enterprise and Business Software, Telecommunications, Health Care IT, Medical Devices, and others.

What is ODC?

• ODC, Orthogonal Defect Classification, forms the basics of a complete Software Quality Framework.
• A systematic framework for Software Defect Classification, developed originally. by IBM, currently in use by many companies, including IBM, NASA, Motorola.
• A concept that enables in-process feedback to developers by extracting signatures on the development process from defects.
• Use of semantic information from defects to extract cause-effect relationships in the development process.
• Built-in mechanisms for Phase Escape and Root Cause Analysis.
• ODC is designed to work with all software Agile processes.
• ODC is referred to as an “MRI” on a Software Defect.

ODC Builds Cause-Effect Relationships

Every defect passes through two sections in ODC, an Opener or submitter section and a Closer or Resolver Section.

Opener/Submitter Section of ODC

The Opener/Submitter section is populated by the person who discovers the defect, usually by Software Tester (Quality Assurance Team).

The following attributes can be classified by the Opener/Submitter of the Defect:

Activity: This is the actual activity performed at the time of defect discovery. For example, during function test phase, an engineer might decide to do a code inspection. The phase would be function test but the activity is code inspection.

Trigger: The environment or condition that had to exist for the defect to surface. What is needed to reproduce the defect? During Review and Inspection activities, choose the selection which best describes what you were thinking about when you discovered the defect. For other defects, match the description with the environment or condition which was the catalyst for the failure.

Impact: For in-process defects, select the impact which you judge the defect would have had upon the customer if it had escaped to the field. For field reported defects, select the impact the failure had on the customer.

Closer/Resolver section of ODC

The Closer/Resolver section is populated by the person who fixes the defect, usually by Software Engineer.

The following attributes can be classified by the Closer/Resolver of the defect, once the defect is fixed.
Target: Represents the high level identity of the entity that was fixed.
Defect Type: Represents the nature of the actual correction that was made.
Qualifier: (applies to the Defect Type): Captures the element of either a nonexistent or wrong or irrelevant implementation.
Source: Identifies the origin of the Target ( i.e. Design/Code, ID, etc.) which had the defect.
Age: Identifies the history of the Target ( i.e. Design/Code, ID, etc.) which had the defect.

The Value of ODC

• Provide fast & effective feedback to developers.
• Captures information from defects that occurred through development phases & field usage.
• Allows understanding of defect trends over the lifecycle phases due to consistency of defect types.
• Through multi-dimensional measurement & analysis ODC assists developers to properly manage their development processes & product quality.

ODC Attributes

1. Phase Found
2. Activity
3. Trigger
4. Impact
5. Defect Type
6. Qualifier
7. Target
8. Source
9. Age

Each Attribute is designed to be populated by software engineers or testers in 30 seconds. Each Attribute has predetermined fields, like a “drop down menu”.

Please see table below for attribute definitions:

We at SW-Quality.com can help you implement ODC to dramatically improve your organizations Quality. Please contact us at contact@swreliability.com