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
of this system. Terms and definitions are listed in
HET Problem Report Management System
- 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
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
- 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.
- 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,
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,
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.
- 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
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
Green Bank Telescope
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
email/web based system.
HET PRMS Decision Matrix
||web is fully integrated
||Yes, with email
||Yes, with email
||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.
||uses server authentication
||must know regular expressions
|Ease of installation
||Complex, much local development
and little documentation of the web interface
||build and add aliases/
Design web pages
|Ease of maintenance
||Once system is built only routine
clearing of queues and processing
of undecipherable reports required.
||need to manage
Summary pages are built by hand.
|Number of languages
|Year 2000 compliance
||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
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.
- 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.
- 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