Browse Prior Art Database

Method to analyze the historical behavior of a defect or problem record to give weight to future problem queries or redirect the defect to the proper component

IP.com Disclosure Number: IPCOM000124973D
Original Publication Date: 2005-May-16
Included in the Prior Art Database: 2005-May-16
Document File: 3 page(s) / 32K

Publishing Venue

IBM

Abstract

Method to analyze the historical behavior of a defect or problem record to give weight to future problem queries or redirect the defect to the proper component

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 1 of 3

Method to analyze the historical behavior of a defect or problem record to give weight to future problem queries or redirect the defect to the proper component

The disclosed assists with the management of defects, making defect owners and originators aware of the potential defects out there that are related to a new problem they are reporting. It uses the component history of an problem reported in a defect database such as Bugzilla, to give weight to the relevancy of any search matches or to redirect the problem to the correct component within a database.

Currently, a user guesses the proper component of the database, and the owner transfers the defect as it is determined that the current component is not appropriate. A previous disclosure discussed using the current value of any given field, including the component field, to influence the relevance of any given search match. This disclosure builds upon this idea, by tracing the component history, and using this history to:

1) more accurately access the relevancy of any matches found, and
2) correct users errors when opening defects.

Adjusting the relevancy of a defect search match:

Text matches for defects search are generally considered more relevant if the component of the two defects are identical, or from a similar list. For example, if you open a defect with the following text "FAILED test 7" and the component is perl, and the text "FAILED test 7" is found in the Bugzilla database, but the current component for that defect is "compiler and library", then you generally don't care about that defect. However, there are many circumstances that might affect your opinion about the relevancy of the defect,

Namely:

Relevant Component was historically involved: - defects that were at one time assigned to a related component, but are no longer listed as belonging to this component, are considered more relevant than defects with no history of being associated with the current component. An older defect with the text "FAILED test 7" , that eventually ended up in 'test cases' is more interesting to a perl defect owner, when the defect had spent some time in the 'perl' component. This makes it more likely that the this text was a part of the message "t/heuristic ..... FAILED test 7"
that perl generates.

- there are some cases where certain components are typically visited on it's way to a final component. These are "indicator" components where a type of problem always causes a defect to first go to component A, who's owner then routes it to component B.

Poor component identification: - when the number of hops as measured by total number of hops in a fixed time period is high (considering some range of values), then the defect is likely to be incorrectly

1

Page 2 of 3

classified, and this defect might be

     1) excluded from affecting the relevancy entirely (i.e. the component factor can neither increase or decrease it's relevancy), or

     2) used to define the relevancy probability as "0". this is...