keeping up w/ design

Subject: keeping up w/ design
From: Melissa Hunter-Kilmer <mhunterk -at- BNA -dot- COM>
Date: Mon, 23 Jan 1995 12:40:50 EST

On 17 Jan 1995, Scott McDaniel <mcdaniel -at- USPTO -dot- GOV> said:

Subject: Keeping up w/ design

> When I started this job a couple of months ago, I inherited
> a System Administrator's manual for a LAN database that manages
> a CD-ROM library. About two thirds of the manual was already
> written (though it needed heavy editing), with one third remaining.

> My company developed the system before I arrived, and it is now
> maintaining and updating the system for the client. <snip>

> The problem I'm wrestling with: the system is still in development,
> and features change as fast as I can keep up with them. It is not
> evolving toward a specific final form. How have you dealt with
> situations like this?

<snip>

> Finally, the document is between 300 and 400 pages, and it is
> currently on WordPerfect 5.1. Initially it was one HUGE file, but
> I've broken it down into a master document with sub-documents.

Scott,

Glen Accardo's suggestions are right on target. In addition, we are using
another tactic at our company.

The developers were getting more and more flak about the applications,
which kept changing without warning until nobody knew what was going to be
in the apps from day to day. In response, a few of them worked up a
bug-tracking system. It has two main purposes: to facilitate the
reporting and fixing of bugs and to disseminate information about changes
to the current version of the application. You're probably concerned only
with #2, but #1 is crucial, too.

Any developer, user, documentation specialist, or trainer may submit a bug
report to this system. The bug report states the problem, the priority
for fixing it, where it's found (screen and application), how to reproduce
it, and who should fix it. The designated bug-fixer works on the bug and
fixes it, entering a note in the bug-tracking system. Then the bug report
is routed back to the originator of the bug report. The originator checks
it out and, if it's fixed, signs off on it. If it isn't, the whole cycle
starts again.

The bug reports are maintained like a database. Each one can be viewed
from start to finish, and they can also be pulled up in groups meeting
specified criteria.

The bug-tracking system also included release notes, and this is probably
what you want to hear about. Each week, when the new release of the
applications comes out, we can call up a list of new features included.
No excavation! No covert interviews! (Of course, if you notice that a
new feature *isn't* included, you should submit a bug report.)

You didn't ask, but I find that PageMaker 5.0 does wonderful things with
our documents, which we also have in little pieces making up a whole of
several hundred pages. You might want to consider doing that.

Good luck. I have documented a moving system, and it is very educational.
Sometimes I would rather have been ignorant. %)

//\ /\\ **************************************************
|| * \ . . / * || * Melissa Hunter-Kilmer (mhunterk -at- bna -dot- com) *
\\____\X/____// * Bureau of National Affairs (NOT the government!) *
/ * /O\ * \ * Washington, DC *
\__/ " \__/ **************************************************


Previous by Author: Re: "Arbor Text" and SGML
Next by Author: Re: Articles with Acronyms
Previous by Thread: Re: Keeping up w/ design
Next by Thread: Time Tracking


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads