Automatic calculation of orthogonal defect classification (ODC) fields

Mechanisms for Orthogonal Defect Classification (ODC) analysis in a computing system are provided. One implementation involves determining a defect in a software application, providing a defect fix to the software application, linking the source code fix to the defect, and automatically performing ODC analysis and calculating ODC information based on calculations against the source code linked to the defect fixed.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to software defect analysis and in particular to software defect analysis using ODC.

2. Background Information

Orthogonal Defect Classification (ODC) was formulated by IBM Research. ODC is a scheme to capture the semantics of each software defect quickly. It is the definition and capture of defect attributes that make mathematical analysis and modeling possible. Analysis of ODC data provides a valuable diagnostics method for evaluating the various phases of the software life cycle (e.g., design, development, test and service) and the maturity of the product. ODC makes it possible to push the understanding and use of defects well beyond quality.

ODC methodology requires an effective ODC validation process in place. ODC fields can be divided between opener ones (i.e., the ones filled in when the defect is opened) and responder ones (i.e., who fixes the defects has the responsibility to fill them).

In existing approaches, ODC classification and validation involve manual time consuming processes that require product knowledge and ODC experience. Among all the ODC fields, the following provide objective values (i.e., not subject to interpretation): ODC Target, ODC Defect Type, ODC Qualifier and ODC Source History. Specifically, ODC Target represents the high level identity of the entity that was fixed. ODC Defect Type represents the actual correction that was made (the “type” captures the size, scope, and complexity of the fix). ODC Defect Qualifier captures the element of a non-existent, wrong or irrelevant implementation. ODC Source History is the selection which identifies the history of the program code or information which was fixed (applicable to all defect Targets). ODC classification also involves organizational costs wherein ODC fields must be set on each field and must be validated by a senior developer.

SUMMARY OF THE INVENTION

The invention provides a method and system for Orthogonal Defect Classification (ODC) analysis in a computing system. One embodiment involves determining a defect in a software application, providing a defect fix to the software application, linking the source code fix to the defect, and automatically performing ODC analysis and calculating ODC information based on calculations against the source code linked to the defect fixed.

Calculating ODC information may further involve extracting the source code before and after the fix, determining changes representing lines of code added, deleted and modified, and calculating ODC fields based on said code changes. Automatically calculating ODC fields may further include calculating Defect target, Defect type, Defect qualifier and Source history, based on the code changes.

Automatically calculating ODC fields may further include calculating a set of measures including one or more of: Number of lines inserted (CI), Number of lines modified (CM), Number of lines deleted (CD), Number of changed files (F), Number of components impacted by the changes (NC), File extensions (FE), and Number of lines changed (CC), wherein CC is a function of CI, CM and CD; and calculating the ODC fields based on said set of measures.

Calculating the ODC fields based on said set of measures may further include determining Defect qualifier based on the number and type of codes lines changed, as:

Calculating the ODC fields based on said set of measures may further include determining Defect type as a function of the total number of code lines changed, as:

Calculating the ODC fields based on said set of measures may further include determining Defect target representing a component in which code has been changed, as:

Calculating the ODC fields based on said set of measures may further include determining Source History representing differences between the code before a change and a reference baseline determined by a customizable code level that identifies the base code, as:

Base: Updated code was present in the base code,New: Updated code was not present in the base code,Refixed: Updated code not present in the base code,Rewritten: Updated code was present in the base code.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The invention provides a method and system for automatic calculation of Orthogonal Defect Classification (ODC) fields. One embodiment involves calculation of one or more ODC fields (e.g., ODC responder fields) in a defect tracking tool (e.g., defect tracking software module) according to the invention, to assist software developers both in filling them and to validating them. Since every software modification (e.g., defect fix) implies a change, the defect tracking tool analyzes the changes to provide defaults to ODC responder fields (i.e., ODC Target, ODC Defect Type, ODC Qualifier and ODC Source History). The defect tracking tool automates ODC classification and validation.

FIG. 1shows a functional block diagram of a system10implementing the above-mentioned embodiment of the defect tracking tool. The system10generally includes a hardware layer and a software layer. The software layer executes on the hardware layer.

The hardware layer includes a processing module11including a computing module12, a storage module13and an interface module14. The computing module12includes one or more processors to execute application programs comprising instruction codes. The storage module13includes one or more storage devices (e.g., disk drive, tape drive, memory, etc.) for storing data. The interface module14includes functions that provide various interface capabilities to support communication with other systems, with users, with communication devices, etc. The processing module11may be a single processing machine or comprise a set of networked processing machines.

The software layer includes a defect management application15, a defect database16, a source code management application17, a source code repository18, and an ODC calculation engine19.

In an example operation scenario, an Application developer (e.g., a software engineer) writes and maintains source code of a software application17A. Source code for the application17A is stored in the source code repository18. A Tester (e.g., a user that performs quality analysis) tests the application17A and utilizes the defect management application16to create, manage and classify the defects that the Tester found in the software application17A. The Application developer utilizes the source code management application17to load, view and edit the source code. Further, the Application developer also utilizes the defect management application15to view defects that testers have found, to fix those defects and load the fixes in the source code.

Specifically, the defect management application15is configured to store defects data, wherein for each defect, information is stored to characterize the defect, including, for example: severity, priority, phase found, software component, ODC fields, etc. The source code management application17is configured to enable software developers to store, and share with other developers, the source code in the source code repository18. The source code management application17may be integrated with the defect management application15. Preferably the defects are linked with the required code that fixes the problem (example implementations of such linking functions include IBM CMVC or IBM Rational Clear Quest). The defect database16comprises a relational database that stores defects information. The source code repository18comprises a protected file system or a database that stores the source code securely. The source code repository18cooperates with the source code management application17to store the history of changes made to the source code. The ODC calculation engine19comprises a software module configured for automatically calculating the ODC fields (i.e., ODC Target, ODC Defect Type, ODC Qualifier and ODC Source History), according to the invention.

FIG. 2shows a flowchart of a process20involving a user interaction scenario with the system10for detecting code defects, fixing code defects and then automatically calculating said ODC fields via ODC calculation engine19, according to an embodiment of the invention, including:Block21: A Tester finds a defect in the software under test17A.Block22: The Tester creates a defect record in the defect database.Block23: An Application developer views the defect and creates/changes source code to fix the defect.Block24: The Application developer loads the source code that fixes the defect, and links the source code fix to the defect.Block25: The ODC calculation engine automatically determines and fills ODC fields based on source code changes.

Conventionally, the application developer uses knowledge and experience to find the proper values for the ODC fields. According to the invention however, the ODC calculation engine automatically determines the ODC fields based on calculations against the source code linked to the defect that is being fixed.

FIG. 3shows a flowchart of a process30performed by the ODC calculation engine. The process30is preferably performed as soon after the Developer loads the fix and links the code with the defect. The process30includes:Step31: Extract the source code before and after the fix.Step32: Calculate the lines of code added, deleted and modified.Step33: Extract the source code at the beginning of the project (base code), before the fix and after the fix.Step34: Determine if the fix (difference in code between before and after the fix) touches parts of the code that were not changed between base code and code before the fix. This information is later used to determine the ODC Source History field.Step35: Calculate ODC fields using ODC calculation algorithms (detailed further below) based on code changes. This provides default values for ODC fields that will help the Developer in filling the correct values.Step36: Store default values for ODC fields in the defect database.

Validating the ODC fields requires (from a validation stand point) analyzing the changes. The following ODC fields have a clear relationship with the underlying code changes: Defect target, Defect type, Defect qualifier, Source history. In one embodiment according to the invention, the system analyzes two snapshots of a set of source files and calculates a set of measures to determine the above-mentioned ODC fields. Said measures include: Number of lines inserted (CI), Number of lines modified (CM), Number of lines deleted (CD), Number of lines changed (CC) (i.e., CI+CM+CD), Number of changed files (F), Number of components impacted by the changes (NC), and File extensions (FE). In one example, Code versioning tools such as Configuration Management & Version Control (CMVC) which track code changes associated with defects can be utilized, wherein changes can be programmatically analyzed to determine said measures for calculating the above-mentioned ODC fields. Specifically, said measures are used by the ODC calculation engine to calculate the following ODC fields, as:

Defect qualifier: The main indicator to be used for calculation Defect qualifier is the number and type of codes lines changed:

Defect type: Is based on total number of code lines changed:

Defect target: Represents component in which code has been changed

Source History: The differences between the code before a change and a reference baseline are determined by a customizable “code level” that identifies the base code:

Base: Updated code was present in the base code.New: Updated code was not present in the base code.Refixed: Updated code not present in the base code (changes wereintroduced recently by another defect).Rewritten: Updated code was present in the base code (changes wereintroduced recently by another defect).

In another embodiment, the automatic ODC field calculation process can be applied in a simplified process where no human intervention is required. In this case, ODC fields are calculated based on the same calculation as above but the Developer and/or Tester can only view the calculated values. This may not provide an optimum quality of the ODC fields since the ODC calculation determines the most probable value of each field. However, ODC field values are provided for analysis to existing projects without additional costs (no human intervention). The ODC calculation engine can be applied to code of an old software project, allowing it to gather historical data on completed projects that can be used to better plan future product development cycles.

As is known to those skilled in the art, the aforementioned example embodiments described above, according to the present invention, can be implemented in many ways, such as program instructions for execution by a processor, as software modules, as computer program product on computer readable media, as logic circuits, as silicon wafers, as integrated circuits, as application specific integrated circuits, as firmware, etc. Though the present invention has been described with reference to certain versions thereof, however, other versions are possible. Therefore, the spirit and scope of the appended claims should not be limited to the description of the preferred versions contained herein.