Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!uunet!mdcbbs!system
From: jmi@devsim.mdcbbs.com ((JM Ivler) MDC - Douglas Aircraft Co. Long Beach, CA.)
Newsgroups: comp.software-eng
Subject: Re: Problem Tracking Systems
Message-ID: <449.25604813@devsim.mdcbbs.com>
Date: 14 Nov 89 17:14:58 GMT
References: <810@ccsrd3.UUCP> <1666@netxcom.DHL.COM>
Followup-To: comp.software-eng
Organization: McDonnell Douglas M&E, Cypress CA
Lines: 81

In article <810@ccsrd3.UUCP> chris@ccssrv.UUCP (Chris Andersen) writes:
>We are currently looking into automating our Problem Tracking System...
>What is the best way to automate the process of bug/problem tracking...
>What... are the benefits and pitfalls of this kind of automation?  
>Is there any ...software...?  Any suggestions would be mucho appreciated.

Well...

Here at DAC I am the project leader for an automated lyfecycle system. It
includes software configuration management, status accounting, automatted
problem reporting and tracking and a developers shell that integrates the
entire system. 

I would "type in the specs" but that would take about a day and a half :-).
Instead I will provide and overview of the area you seem interested in.

The problem reporting and tracking system associates problem reports from
anyone to a specific product that has been developed. This is done online and
the information required is entered by the users with a mail message generated
to the product leader of the product being reported on. The original problem,
text is stored in a text library and the non-text information is stored in a
ISAM file for that product.

The product leader has 30 days to respond to the initial problem report. There
are three types of responses available. They are: Problem closed, Problem
suspended, and PAI generated. In all cases an analysis must be perfored and
that analysis is then placed in a text library with the appropriate entries
made in the ISAM database. If the product leader doesn't respond in 30 days a
PAI is automaticly generated.

A PAI is a "Problem Action Item" and these items must be presented to the
Configuration Control Board (CCB) for review. This generates a need to respond
top the problem within the 30 day period since no product leader wants to go
before the CCB on a PAI that was not analyzed. The CCB then establishes a
person responsible for closing the item and the item is automatically passed
off to that person (usually the product leader) with a return/completion date
associated to it. 

The database is updated and the person responsible is sent a mail message that
advises them of the assignment. This person can then reassign the PAI to a
developer with an associated return date for the problem to be fixed. The
developer then gets a copy of the PAI by mail.

The developer then accesses a CMS library and reserves code from it. The code
is taged with the PAI number for the problem being fixed. Once the fix is
completed the developer replaces the code in the library and craetes a
"elements-modified" file that lists all the elements modified and places them
in a text library with the associated pointers being added to the database. The
developer is also responsible for documenting the fixs made in a text file and
that file will be placed in a text library and the database will be updated.
The PAI then is closed out and sent back up the tree. The product leader then
can reopen the PAI or agree that it is closed after he has reviewed the
solution and the files changed text files. If it is closed he will refer it
back to the CCB as a completed item.

If the developer has not closed the PAI 5 workdays before it is due to the
product leader, he will be sent a reminder message via the mail facility. He
will also recieve one of these 2 workdays prior to the closure date. On the
closure date, if the PAI is not sent up the tree a mail message is sent to the
product leader advising that the PAI is past due. A copy of that message is 
also mailed to the developer.

Once the CCB has all the fixs that are due to go into the next release they
advise the Product Configuarion Managers (PCMs) to create the release and tell
them what PAIs are included in the release. The PCM then uses tools that
permit them to pull of the elements-modified from the text library and use that
to create the releases.

As you can see, this is a totally integrated product. After checking for both
freeware and purchasable software to meet our users needs, we were unable to
find any product that met the stated requirements and are currently writing our
own. Once completed, some form of this should show up on the DECUS SIG tapes.

This product is designed to run on a VAX, it uses 5.0 runtime library calls to
SMG (the screen manger) and system services. It uses no "databases" in order to
be generic enough to run on any standard VAX under VMS.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| J.M. Ivler at Douglas Aircraft in Long Beach, CA  - VOICE: (213) 496-8727 |
| INTERNET:  jmi@devsim.mdcbbs.com  | UUCP:  uunet!mdcbbs!devsim.mdcbbs!jmi |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~