keeping up w/ design

[Melissa Hunter-Kilmer <mhunterk -at- BNA -dot- COM>]

   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                                   *
    \__/  "  \__/    **************************************************