Path: utzoo!censor!geac!jtsv16!uunet!wuarchive!uwm.edu!mrsvr.UUCP
From: mcilree@mrsvr.UUCP (Robert McIlree)
Newsgroups: comp.software-eng
Subject: Re: Problem Tracking Systems
Message-ID: <1399@mrsvr.UUCP>
Date: 10 Nov 89 15:19:05 GMT
References: <810@ccsrd3.UUCP>
Lines: 71

From article <810@ccsrd3.UUCP>, by chris@ccsrd3.UUCP (Chris Andersen ("The Dangerous Guy")):
> We are currently looking into automating our Problem Tracking System and
> could use any venerable wisdom that might be out there.  I know from past
> experience that this can quickly blow up into a MAJOR project, even for
> a small company, and I would like to hear what other peoples experiences
> with this have been.
> 
> What is the best way to automate the process of bug/problem tracking
> in a software project?  Across several projects?  What, in your experience,
> are the benefits and pitfalls of this kind of automation?  Is there any
> public domain software for doing this?  Any commercially available software?
> If there is, which ones work the best?
> 
> Any suggestions would be mucho appreciated.
> 
> Thanks.
> -- 
> Chris Andersen (..!{sun,tektronix}!sequent!ccssrv!chris)
> Home: (503) 620-4176	Work: (503) 641-8128
> "Join the Danger Patrol!"

The issue you describe depends greatly on the type of development
environment you have, and also on any development methodologies you
follow.

Some of the best approaches I've ever seen were the linking of
bug reports to some sort of deliverable/other response. The
deliverable satisfies the bug report insomuch as it works, if
it doesn't solve the problem described in the bug report, a new
one (and hence, another black mark at the person responsible :+))
is opened.

Linking of a problem description to a deliverable/response can be
automated. Most that I have seen and dealt with use SCCS as a base
to track and manipulate deltas of code and documents, with some
sort of user interface (usually command line) to shield users from
the more arcane nuances of SCCS, and also to keep logical links
from the overlaid software to SCCS sane and stable. I don't know if
any are commercially available; the ones I have used were home-brew
and UNIX-specific. But, given some time and resources, it's not
to difficult to build a basic shell over SCCS and customize it to
met the needs of your problem report format.

Pitfalls: You really must use such a system throughout the entire
lifecycle of a project. The value of such a system degrades if
it's only used for post-ship product problem tracking. Such a
system is valuable to QA people and developers alike during the
product development process as it lets you track deliverables
during the entire lifecycle: requirements, functional, and
architectural specs, designs docs., code, bug reports, and fixes.

The real pitfall is selling your developers on the idea. It creates
more work for them, and If I had a dollar for every developer I've
heard screaming and bitching about automated configuration management
systems and what a pain they are, I would be happily sunning myself
in Rio for the rest of my life. You need management backing to enforce
the system usage.

Benefits: With a robust tracking system, you can trace problem reports
to their source quickly, produce QA results and statistics for
management, allow developers to address problems in software in a
formal way (i.e. Problem report --> developer response --> test of
fix (if needed) --> Problem report satisfied and closed).

Sorry if this was a little general. If you could provide more
information on your development environment and how problems
are currently handled, perhaps we can get more specific. Hope
this helps a little.

Bob McIlree
...well!rmac    ...mrserver.UUCP!rassilon!mcilree