Project Proposal: Helpdesk Software

Proposed by: Hugh Sasse <hgs@dmu.ac.uk>

Introduction | Requirements | Requirements of the student | Deliverables | Web Resources

Introduction

Unix systems do not run themselves, unfortunately. There are always problems with disks becoming full, mail not going where it should, compilers not handling code correctly. Then there are demands fpr the system to do more: people want to print images, and manipulate them, they want better web browsers, other languages to support different tools. Often many things interact: Mail Transfer Agents use databases, Web pages use Java. For these reasons and for security reasons, there is an ongoing process of ugrading and expanding the software available to people. All of this means that the administrator has to hold a lot of knowledge about problems with programs and their fixes, and when one has to manage more than one system, this becomes more problematic.

However, these problems are not new, and any organisation with a large number of PCs faces the same problem, as do those with many types of workstation (Sun, HP, DEC) on the same site. Usually in a large commercial organisation there is a help desk, and they will have software to assist in the problem management. However, most of this software is prohibitively expensive for a university department. Prices range from £990 to £15,000. Surprisingly there is virtually nothing available as free software.

This project is an attempt to create something to fill the gap at least for us at DMU.

Requirements

These are a tentative list of requirements, with explanations. There may be others that come to light later.

Trouble Ticketing: This is the most basic level that will help users and administrators. Each problem should be given a job number (or alphanumeric code) so that it can be called up quickly. Information should be available on those jobs still incomplete.
Priority Management: It should be possible to prioritise jobs so that effective use is made of staff in solving problems.
Records of solutions: When a problem is solved, its solution should be stored, so that if it crops up again it can be found. Identical problems should be able to be cross-referenced easily so that the solution is not written into the databases many times.
Searchable: It should be possible to search the database for similar looking problems, possibly by using keywords in the problem text. This will allow similar problems and their solutions to be found
Statistical information: It should be possible to find out which problems, sharing one solution, come up the most, to allow user education, the creation of FAQs for users, the identification of problem pieces of software which should have priority for upgrading (or patching), etc.
Performance: People should not have to wait a long time to lookup solutions to problems. It is almost certainly necessary to have the utilities compiled to native code, i.e. Java is probably too slow.
Minimal package prerequisites: If the program depends on six languages, two database formats, and a specific Web server, you can bet that one component will need to be upgraded and it will then become incompatible with the rest of the system.

Requirements of the student

The student should have a knowledge of, or an ability to become familiar with

coding theory: The database must be compact, and the trouble ticket codes should have error correction components in them, so that mistakes over the telephone won't matter
databases: existing dtabases for Unix should be used, (ndbm, gdbm, or the Berkeley database sendmail uses.)
Human Computer Interaction: The system may be used by people in times of stress, so it should do what they expect, not make them more frustrated

Deliverables

In the first instance, at least the trouble ticketing system should work. If only the plans exist for the other features, at least the next student should be able to carry on to produce a useful system.

Documentation, documentation and documentation. Too many projects are left in a state where they cannot be used, there is insufficient information for the next student to build on the project (so they end up starting from scratch), and details on how the system works are missing. The documentation should explain:

the thinking behind the user interface as well as how to use it
Why the algorithms in the code were chosen
What areas need further work and what foundations already exist if any.

In other words, external and internal documentation of the program, and suitable suggestions for further work.

Web Resources

Web-based problem tracking tools for Unix, Help Desk FAQ, Teacup - A Problem Report Management System, The Tech Tracker Project, about which more information is available in this e-mail the author sent to me. Nebula Freelancer seems to be in its early stages, and is not so geared to help desk work, but could be of use there, Request Tracker. MHD is a sourceforge project with similar aims to this. It includes equipment inventory and a loans system for equipment. It is based on PHP, an area I have not ventured into yet. Reqtool. The openTicket project is a javascript based tracking system.

last Modified on 11-FEB-2002 by Hugh Sasse <hgs@dmu.ac.uk>