list.910/Problem Database

This is for Glen Sjoberg of BYU in response to list.910 posting. ----------------------------------------------------------------- Here at TRW Financial Systems an Informix database such as you seem to want was put together here for one of our projects and has since been "borrowed" by the project I am working on. Below find your list of desired features and if I think we meet those: -Logging problems > adding to database done via user-menu interface -Appending to problems > This problem database is a two screen one where the problem is described on screen and responses are put on screen two. -recognize Logger, Reporter, Assignee, interested parties > This database does all of this except for the interested parties on either of the two screens. See e-mail about this possibility. -Priority/Severity > Done on first screen and can be modified at any time. -occurance date, Target date, completion date > Covered by this database. -E-mail interface for notification, appending, logging(?) > There was a mail program developed to notify by group what problems were occuring for a particular system flow(capture, print, billing). Basically the group was notified and then any appending or logging about the problem was done in the database. -Client/Server Architecture > I am not sure what you expect here so I can't comment on it at this time. A lot of work went into this database and so there are quite a few scripts that were developed as well as reports about the problems. Here is how the fields were descibed when the use of this database was descibed to me: First Screen --- Initial entry fields ---- Problem # unique identifier for a problem. Assigned automatically. Starts out as 0. Gets set when you add a record. Date This is the date of the problem. It defaults to today. Reported By Enter your name. You get credit for it. Environment This is to help identify the circumstances. Begin with the runtime environment number, rt0, rt1, etc, and then list the machines involved. SW/Version Enter the "baseline" date, and should be well known by testing and integration group. In case the baseline number is not known, run ls -l in the run/ directory. The date of the files is the date of the baseline. Subsystem Will add more values as necessary... Procedure # This is for the QA and Integration group to enter the test number or procedure number they were running. They will rerun this test to verify the fix. Severity Enter your judgement about the severity of the problem. This is a guide for the Devt Mgrs to prioritize the fix. Three values: LOW, MED, and HIGH. HIGH should be assigned to show-stoppers; MED to problems that severely degrade the expected result; LOW to anything that can be worked around (things like permissions, ownership, bad paths, etc). description Enter the problem description. You have nine lines. You can do a little editing here. Type ctrl-w to get editing control keys. It is NOT vi. Include information about the circumstances, and any immediate corrective action, and any immediate diagnosis. --- Devt Mgr update fields --- status Values are NEW, OPEN, REPEAT, READY (for testing), TEST, QA (may be superfluous), and CLOSED. Initially defaults to NEW. When a devt mgr examines the record, he will update this to OPEN, and assign an engineer, and enter a target fix date. The status OPEN means that the problem has been acknowledged by the devt manager. If the problem is a repeat of another, then the status is set to REPEAT and the problem number of the original is indicated in the followup section. When the developer hands off the program(s) to integration, the status is changed to READY and then to TEST when it is being tested. When the QA cycle becomes important we could use that status to differentiate from integration testing. When a problem is closed out by integration and QA, the development manager sets the status to CLOSED. priority This is the priority assigned to the problem. It has three values: LOW, MED, and HIGH, which relate the importance given to fixing it (not the same as its effect on testing). devt mgr Their name here(ex: glen) engineer This is whoever is assigned to look at the problem. Target fix date This is an estimate of when to expect the solution to pass UNIT TEST. Actual fix date When the code is checked in, RCS made and ready for retesting. (Assigned READY status). closed date This is the date that the problem is closed. That means that integration and QA have accepted the fix. Second Screen ----------- Developer entries ---------------- Developer Response This is for followup comments and notes on open problems. Diagnosis, problem cause, development status, etc, go here. What Changed The names of executables that changed Source The source modules, one entry per line. Well that's about it in a nutshell. If you are interested in knowing more about what we have please let me know. ------------------------------------------------------------------------ Michael Fischer Voice Mail 1 510 704 3111 TRW Financial Systems 2118 Milvia Berkeley, CA 94704 Internet: mikey@tfs.com