TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:How do you handle software maintenance releases? From:Tom Herme <hermet -at- DNINEVADA -dot- COM> Date:Thu, 7 Jan 1999 13:59:59 -0800
Hi, All. For those of you who document maintenance releases
of software, here are some questions (and whines) for you.
(1.) If you're on a six-month maintenance/upgrade cycle,
when do you begin your work of updating the manual and
on-line help?
(2.) How are you notified of necessary additions,
deletions, and corrections to the documentation? In our
ever-evolving process, I'm being inundated with software
correction reports, many of which do not directly pertain to
my work with the documentation. In fact, many of these seem
premature given that programmatically they may not be
implemented or implemented differently than currently is
expected.
(3.) What type of system does your company employ to
assist you and others in tracking changes? We have a limited
number of seats of a product called Tracker. I don't have
one (not enought to go around). Since this product isn't
totally loved by all those using it and because of the
expense of upgrading it, the company is looking at other
products that will allow managing the software change
process.
One of the biggest problems I'm facing is duplicating
effort. For example, I get notification of a programmatic
change, so I make the change. Then the same feature will
change again, sometimes to the way it was originally, so I
change again.
Another problem is with relatively new people to the company
who use the manual to learn the product. However, they're
also using it as a product specification, which I argue
should not be. (No, there is no spec., believe it or not.)
What they find is that the manual does not reflect the
behavior of the program because bugs have been introduced
into the program. Consequently these people write two SCRs,
one for the program and one for the documentation. What's
most frustrating is that in the beginning all was good. That
is, all involved agreed that during development the
documentation would reflect the way things were "supposed"
to be, not the way the software currently operated. Somehow
this approach isn't working anymore.
Your thoughts, advice on the these questions and points is
appreciated.
Thanks.
Tom
--
_________________________________
Tom Herme
DNI Nevada, Inc. mailto://hermet -at- dninevada -dot- com