HET banner
Home Problem Reports Operations Schedule Weather Data Archive

PRMS Design Requirements

Introduction

The Hobby-Eberly Telescope Operations staff continue to improve telescope control system hardware and software. A Problem Report Management System (PRMS) keeps track of problem reports to: properly assign problems to system maintainers, prioritize tasks, and provide reports to management on current status of problems. The following discussion outlines requirements used for the design and selection process of this system. Terms and definitions are listed in Appendix A.

HET Problem Report Management System

User Requirements

  •  Web based for all new reports as well as searching old reports. The Web is the only interface that all users have in common.
  •  Easy to operate. Minimal actions required to submit or find out status of a report.
  •  Easy to find out who is in charge of your problem and how to contact them.

It is difficult to quantify what easy means for users but, there should be a minimum amount of navigation required to submit a report or to locate a report you want to check the status on. There should be immediate feed back to the user, either email or HTML, with problem report ID, responsible party, and how to check status.

Programmer/Maintainer Requirements

  •  Easy to edit problem report. Minimal authentication.

Programmers can tolerate a bit more navigation. Some authentication mechanism should be available to prevent random persons from editing Problem Reports. If the system is too difficult to use, the system maintainers will not provide updated information to the system, thereby annoying the users and making the system worthless to both users and management.

Management Requirements

  •  Support concept of severity (critical, serious, troublesome, etc)
  •  Support concept of a formal state (submitted, acknowledged, open, closed, etc)
  •  Support concept of a formal responsible party
  •  Easy to get summary reports on current status. (Summary reports should be presented in an easy to access fashion)
  •  Summary reports by status, severity, responsible party, or equipment
  •  Easy to reassign the responsible party
  •  Easy to change a problem report severity, status, etc.

Report generation for management is one of the primary purposes of a Problem Reporting System. Management must be able to: insure problems are being fixed on a timely basis, find out why problems are not being fixed, and prioritize problems so that important work gets done on time.

Daily management of the PRMS should not require a lot of time. A quick review of new reports to see if the priority and responsible party are correctly assigned should be all that is required. A review of outstanding reports should be available under various search criteria, i.e. priority, responsible party, system, severity, etc.

Although a simple Trouble Ticketing system would probably be adequate, the ability to more formally track responsibility, status, as well as to control reporting by responsible parties imply that a more formal Bug Tracking system will be required.

Installer/System Manager Requirements

  •  Easy installation. Minimal configuration and web page development. Documentation on installing and configuring system are required.
  •  Easy to maintain. Minimal action to keep system running once it is set up. Instructions on regular maintenance procedures required by the system are important.
  •  Should use a minimum number of languages. Many system use HTML, perl, C, Tcl/Tk.

General advice

Keep it simple. If it gets in the way people won't use it.
Make it part of your customer support process.
Make it part of your e-mail system.
Make problem management a part of the regular information flow.
Make it part of your design documentation process.
Documentation the original designer supplies, seldom meets maintenance needs. "Change history" augments original documentation.
Get requirements from the European Computer Manufacturers Association (ECMA) reference model.

References:

  • Bug Tracking at Linux. Has a good terms and definitions section. Mostly a description of PRMS that are known to run under Linux.
  • Problem Reporting Tools at Honeywell. The definitive summary, if one can be said to exist, about available problem tracking systems, both commercial and free.
  • FAQ for computer software.config-management

Possible choices

Jitterbug

JitterBug, developed for managing the samba-bugs bug reports and now used on other projects, is web based and written in C. It is released as free software under the GPL. Information may be found at http://samba.anu.edu.au/cgi-bin/jitterbug and a guest interface to the rsync JitterBug provides a reasonable demo at http://samba.anu.edu.au/cgi-bin/rsync. The non-guest interface has many more features, of course.

Gnats and WWW Gnats

GNU GNATS (GNU Problem Report Management System) is copyrighted by Free Software Foundation and freely available according to the terms of GNU General Public License. Commercial support for GNATS (under the name PRMS) is provided by Cygnus Support. Unfortunately there does not seem to be much continuing development of the system.

A web interface and various modifications known as WWW Gnats has been developed by Danks and others. Various authors have modified the system for their own use but again there does not seem to be much recent development. The wwwgnats interface has no documentation.

This product helps track software problems or change-requests. Some of its features include:

  • problems submitted via e-mail
  • uses a file system based database
  • each problem identified by a unique key
  • querying possible
  • can maintain audit trail of all activities concerning a specific problem
  • a GUI interface (via tkgnats)

Users of Gnats:
Nordic Optical Telescope
CERN
Green Bank Telescope
NRAO AIPS++
European Software Institute
BaBar Project at SLAC
FreeBSD Project (version 3.113.1 7 available through this link)

The Debian Bug Tracking System

The Debian Project is a version of the Linux Operating System. They have written their own Bug Tracking System because they found that Gnats was too complex in areas that they were using and at the time they started writing the Debian system, Gnats was entirely email based and they wanted a email/web based system.

HET PRMS Decision Matrix

Parameter JitterBug WWW/Gnats Debian
Web Based web is fully integrated Yes, with email Yes, with email
Simple Forms Yes, interface to email Roll your own CGI interface available Not really, reports by email. We need to build our own pages. No report generation available.
User review Yes Yes Yes
Editing PRs uses server authentication Follow-up email
Summary reports must know regular expressions Yes
Status/Severity No Yes Yes
Changing status No Yes Yes
Responsible party No Yes No
Ease of installation straight forward Complex, much local development and little documentation of the web interface build and add aliases/ Design web pages
Ease of maintenance unknown Once system is built only routine clearing of queues and processing of undecipherable reports required. need to manage undecipherable reports. Summary pages are built by hand.
Number of languages HTML/C C/HTML/Perl HTML/Perl
Year 2000 compliance unknown v3.107 unknown
Comments Appears to be more of an email management system rather than a PRMS. Simplest system but it has the least features. Most complex but also the most features. Appear to be more of an email management system rather than a real database. No concept of responsible party. Scripts available to provide fixed format reports only. No documentation available.



Appendix A: Terms and Definitions

Bug Tracking
Bug-Tracking Systems are similar to Trouble-ticketing systems in that they track independent tasks. However, bug tracking systems usually define a greater number of roles and responsibilities, (e.g. "programmer", "integrator/builder", "tester", "tiger-team manager"), and limit the powers of each role in advancing the task to its next state. Many bug-tracking systems are integrated with version-management or configuration-management suites.
Help-Desk Management/Call Tracking
Most Help-Desk Management systems are similar to Trouble-Ticketing systems, except that they add a mechanism for looking up formulated answers to commonly occurring problems. These systems can also maintain detailed information about the problem originator, provide call tracking (time spend on the phone), time-tracking (hours spent solving the problem), and may include mechanisms to automatically bill the client for hours worked.
Maintainer
A maintainer or programmer is a person who is responsible to maintaining a particular software/hardware system. Problem reports will typically be assigned to a maintainer for resolution.
Responsible Party
The person or persons who have been assigned responsibility for a particular problem report. They are responsible for finding a solution to the problem and reporting back to the person who submitted the report as well as to management what this solution is.
Trouble Ticketing
Trouble-ticketing systems usually confine themselves to the fairly simple domain of tracking independent work items, and possibly assigning them to one of several people. Tasks are treated independently of each other, and usually have a very limited set of states: "open", "in-progress", and "closed". Most are e-mail based; newer ones are web/Java based.
Users
Any person who submits a trouble report. This might be one of the maintainers, the telescope operator, or the resident astronomer.


Top of page

Return to main PRMS page


Created:   11-Dec-1998
Last updated: 01-Oct-2003

Send comments to: webmaster@het.as.utexas.edu
Copyright ©1998, 1999, 2000, 2001, 2002, 2003  The University of Texas at Austin, McDonald Observatory