Application Series 15

SIR HEAL THYSELF

Head Office, in Sydney, Australia, use SIR's text retrieval application to record, monitor and fix their SPRs. The new releases suggest that it is working.

Background

How do you store extremely different types of connected information, such as categorised data, free text, PQL programs, source code etc and still be able to select this collection via any number of vague methods? How can you easily combine a conglomeration of reporting methods which include written reports, summary tables, batch input data, and electronic mail? These are the questions we were asking ourselves at SIR and the answer we came up with was 'Use SIR/TEXT!'

We were in this exact dilemma when we reviewed our Software Performance Report (SPR) monitoring system. SPRs are the reports users send us when they are having problems with the software. We were not happy with the feedback and support our users were getting and not convinced that all reported bugs were being permanently removed from the software.

We did not want this unsatisfactory situation to continue so we decided to do something about it.

What needs to be done

If a user reports an SPR we need to know if the problem has been reported before. If so we might already have a solution for the user. So ease of identification is important.

Some specific information is required when we record the bug, such as the user reporting the bug and their distributor, the platform and module it effects, the date of reporting as well as its status and severity.

It is also important to be able to easily keep distributors informed and up-to-date on SPRs so that they can provide good quality assistance to their users. This means many and good output features.

When a bug is reported we need to be able to reproduce the bug before we can offer an effective workaround and before we can guarantee to fix it. So it is important to keep a record of sample programs with instructions to reproduce the bug.

A workaround is important to allow our users to get on with their work straight away without having to wait for a new release containing the fix. It is also important to store this workaround for other users with the same problem.

Once we know what the bug was and have provided the workaround, we must get on with the business of fixing it. Some sort of monitoring facilities are needed to keep track of this progress.

Finally, the bug is fixed and the new release goes out. How do we guarantee that the fix incorporated for this bug doesn't disappear when some other alterations are made to the software? We want to associate a test number and a fix with the SPR so that we can quickly identify and correct such a situation.

We reviewed SIR/TEXT because of its good query features and found that it could also accommodate the other requirements we set.

What SIR/TEXT offers

SIR/TEXT has as its main data structure a document which consists of three types of data: a title; a description area and a free text area. Secondary to the document is the index which allows for specific selection on all areas.

The application consists of a query program which allows for complex logical combinations of selection criteria. sequential querying, backing up and viewing and reporting of selected queries. In addition there are stand-alone reporting programs and update and maintenance programs.

These are all incorporated in a user defined system menu, which offers a selection of functions directly to the user, making it unnecessary to call the programs explicitly. This menu also provides access to program editing and running if the user desires.

How we use it

We incorporate an SPR number and brief description in the title area of the document. The description area contains categories of our own choice such as customer, distributor, date, platform, module, status and severity. The free text area is divided up into groups. The first contains a written description of the SPR as well as a sample program. The workaround, either text or commands, make up the second group. The third and fourth groups comprise of notes on the bug and activities as well as the source code fix.

The update routines in SIR/TEXT automatically index on all words bar selected stop words in all areas of the document. So we can find documents when a user might give us a symptom, when a distributor asks us for all those SPRs reported by their customers or when our R & D want all bugs with fixes in a particular module.

SIR/TEXT provides reports which listed the titles, the full documents or summaries, of those documents selected in a query. Other reporting features include a collection of reports on the full set of documents. All of these are automatically available with the SIR/TEXT application.

We were also able to include some our own reports which specifically relate to the SPR database, using the Full Report Generator. These are easily incorporated as items in the user defined system menu .

SIR's TABULATE procedure gives us the facility to produce a collection of tables on any combination of our description categories

SIR's ESCAPE facilities enables us to email documents automatically to our maintenance programmers, or anyone else who wants them via the internet.

Conclusion

Now that we have set up the SPR database system and entered all of the known SPRs, we are able to easily keep track of these and any new ones and offer quick advice to our distributors and users. The database has also helped us to improve the quality of our software and keep track of any problems.

We introduced this system with version 3.2 beta testing and have been using it ever since. I think the quality of the software since the introduction of this system is pretty good evidence of its effectiveness.

For more information on the use of SIR/TEXT in SPR monitoring and fixing contact:

Heather Goldsmith
Director International Support,
SIR Pty Ltd
1/10-18 Cliff St
Milsons Point NSW 2061 Australia

Back Sir Home