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.
Re: How do you handle software maintenance releases?
Subject:Re: How do you handle software maintenance releases? From:Carol Anne Wall <mmpc0014 -at- PCLINK -dot- COM> Date:Fri, 8 Jan 1999 08:07:25 -0600
Tom Herme wrote:
>(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?
We're on a three-month maintenance/upgrade cycle. I start asking questions
about the next cycle about two weeks after the new release goes out the
door. (I'm a nag, but a friendly nag.) I have about 6 weeks to put
together my drafts, then another week for edits.
>(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.
We use a Word document for our Project Modification List (PML). Each
product in our quarterly releases has a PML. Within the PML, there is a
section for online help bugs found in post-production testing or
enhancements requested for future releases. On one of our larger products
that has several modules, there's a Help PML. All comments, testing
sign-offs, etc. are made within the PML. The PML is owned by the Testing
unit. Its simple, only one person at a time can use the PML. It's worked
for us for over 7 years.
In addition, I also am on the software distribution list. When a new
testing version of one of the products is available, I'm notified by the
programmer. I also pass this information on to my supervisor, so she's
aware of the new releases. The programmers are good about summarizing
their changes. The Testing area keeps us informed as well, even if it's to
say "I'll know more later this week".
I also have a good relationship with the Testing and Marketing areas, as I
use to belong to these groups. But the other TWs also find it pretty easy
to get information as well. Our organization communicates well, we are a
team.
Carol Anne
Carol Anne Wall, FMLI
Technical Writer, Minnesota Mutual Life - Individual Business Technology
St. Paul, MN USA
mmpc0014 -at- pclink -dot- com
