chris@ccsrd3.UUCP (Chris Andersen ("The Dangerous Guy")) (11/10/89)
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!"mcilree@mrsvr.UUCP (Robert McIlree) (11/10/89)
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!mcilreekcr@netxdev.DHL.COM (Ken Ritchie) (11/11/89)
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. I was once the data base administrator for a large, facilities management system for tracking problem reports, along with equipment moves, repairs, user accounts, system configurations, etc. We concluded that the design (using realtional models) of the data base was generally the same for any size operation -- only the volume of data and rate of transactions change. So, yes, you will have some serious work to do even if it is a small shop. If you are going to "roll your own" ... definitely go for a relational model (get some expert assistance if you don't have somebody in house). Then use software/system products which directly support your designs -- and provide good tools: i.e. screen/report generators and ad hoc (SQL) query access, for the odd questions and "what if" decision support. We used Britton Lee IDM's and VAXen, with Metaphor, Datapoint, Xerox WS's, since our environment included over 500 users, on several bridged LAN's. Software DBMS's like ORACLE, INFORMIX, or even MSDOS DBASE could do it. Otherwise, you might consider a "turnkey" product. Check DATAPRO reports. I think there is one called "Falcon" (somehow I'm thinking of a bird... hmmm... maybe it was "Turkey" or something else)... for UNIX or OS/VS/etc. BENEFITS: You can follow up on every problem -- to be sure it gets resolved. You can spot the trends, trouble spots, and see how the business is doing. It's great for keeping records, and answering questions is a piece of cake. I wouldn't want to run any substantial operation without something like it. PITFALLS: You have to invest either the development or the acquisition, then incrementally invest the time for data entry. You will need a backup system (paper tickets even) if your online tracking system is part of the trouble! And... if you are tempted to use the data to "measure productivity/etc." of your people... watch out for Heisenberg's Uncertainty Principle (physics)!!! [Paraphrase: You can't measure something without disturbing it in some way!] This will have the effect of corrupting (at least biasing) the data you see, so that people are working toward the measurements, rather than impartially keeping an audit trail of the business at hand. SUMMARY: Actually, the benefits win out, just be sure you know WHY you want to do WHAT ever it is you do -- so you'll get what you really WANT from it. I hope this insight helps. The tools are the easy part. Best Regards! P.S: If you were wondering, I've been doing development work over 20 years. There have been some support stints along the way. I'm CDP (1976) and CCP/S. _______________________________________________________________________________ Ken Ritchie (aka KCR) Usenet: ...!uunet!netxcom!netxdev!kcr NetExpress Communications, Inc. 1953 Gallows Rd, Suite 300 FAX: USA (703) 749-2375 Vienna, Virginia (USA) 22182 Voice: USA (703) 749-2268 "Imagination is more important than knowledge." -- Albert Einstein _______________________________________________________________________________
jmi@devsim.mdcbbs.com ((JM Ivler) MDC - Douglas Aircraft Co. Long Beach, CA.) (11/15/89)
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 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
warren@psueea.uucp (Warren Harrison) (11/17/89)
I ran into a dBASE bug tracking system called "TRAKERR" by a company
called Software Engineering Tools. It looks like a pretty good system
for the money. They can be reached at 408/725-1866 (Cupertino, CA).
I heard they were looking into doing a similar system for UNIX, but
I don't know if it ever panned out.
Warren Harrison CSNET: warren@cs.pdx.edu
Department of Computer Science UUCP: {ucbvax,decvax}!tektronix!psueea!warren
Portland State University Internet: warren%cs.pdx.edu@relay.cs.net
Portland, OR 97207-0751