Browse Prior Art Database

A cognitive solution reducing errors in the servicing of software products

IP.com Disclosure Number: IPCOM000246818D
Publication Date: 2016-Jul-04
Document File: 4 page(s) / 99K

Publishing Venue

The IP.com Prior Art Database

Abstract

Issuing a fix to a customer that then introduces bugs of its own is very poor customer service and a reason for customer dissatisfaction. A solution is required to analyse the fixes that produce further problems and alert an engineer when their fix falls into the same pattern. This solution provides the end user with a metric (% rank) on how risky / likely it is that they may potentially issue a bad fix by analysing the fix with respect to other fixes which are 'bad' with a set of rules. A fix with a high rank is an indicator to the engineer that the fix should be more deeply reviewed and tested before issuance.

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

Page 01 of 4

A cognitive solution reducing errors in the servicing of software products

Customers raise bug reports against products and an engineer is assigned to fix the problem and issue the fix to the customer. In modern complex long-lived products a fix that fixes one problem can introduce bugs of its own. This can occur due to the following reasons:

    1. Aged code updates - Code is not updated very often and so is inherently not well understood leading to bug injection.

    2. Large code updates - Multiple part changes for a single piece of the function.

3. File type of the part changed, e.g. assembler parts.

4. Partial fix builds leading to errors in unbuilt code.

5. Fix application and product restart.

    6. Multiple local attempts to fix the bug often indicates a lack of understanding.

    Issuing a fix to a customer that then introduces bugs of its own is very poor customer service and a reason for customer dissatisfaction.

    A solution is required to analyse the fixes that produce further problems and alert an engineer when their fix falls into the same pattern. The cost of not creating this solution is to issue a potentially bad fix that will cause customer dissatisfaction and increase the costs to the service organisation in fixing another problem which could have been avoided when it is cheap to do so.

    This solution provides the end user with a metric (% rank) on how risky / likely it is that they may potentially issue a bad fix by analysing the fix with respect to other fixes which are 'bad' with a set of rules. A fix with a high rank is an indicator to the engineer that the fix should be more deeply reviewed and tested before issuance.

    By using historical data of previous fixes, fix documentation and instructions, current fix package history, and service engineer package history it is possible to heuristically calculate the probability ranking that the newly constructed fix may subsequently lead to the fix being marked as 'bad'. As each newly identified bad fix is analysed, the system learns and adds to its knowledge of what may be a potential "bad" fix. For example in the last 5 fixes that included a change to part Z two were subsequently marked as bad. This cognition will allow the analysis to improve over time.

    This idea will improve customer satisfaction by reducing the incidence of fixes introducing more problems and reduce the costs to organisations servicing their products by being alerted to potential problems early when it is cheaper to fix.

    As part of producing a fix for a problem, meta-data is produced. This includes, but is not restricted to:

    1. Names of parts changed (Where a part is an individual piece of source code that is compiled into a machine readable form).

2. Fix engineer.

    3. Number of times the fix was built for local testing, potentially with differing sets of parts each time.

    4. Language type of parts changed (e.g. Java classes, assembler modules, etc.).


5. Fix documentation and instructions.


Page 02 of 4

6. Number o...