FW: Keeping track of software changes

Subject: FW: Keeping track of software changes
From: Katherin Stanzler <kstanzler -at- BROOKSOFT -dot- COM>
Date: Tue, 3 Nov 1998 15:26:31 -0500

Kathy Stanzler
Technical Writer
Brooktrout Technology Inc.
Southborough, MA
(508) 786-9182
kstanzler -at- brooksoft -dot- com <mailto:kstanzler -at- brooksoft -dot- com>

-----Original Message-----
From: Mila Bongco [mailto:mbongco -at- pre-print -dot- com]
<mailto:[mailto:mbongco -at- pre-print -dot- com]>
Sent: Tuesday, November 03, 1998 3:13 PM
To: 'kstanzler -at- BROOKSOFT -dot- COM'
Subject: Keeping track of software changes

Hi Kathy:
Regarding your mail:
We have a problem where developers make changes to the GUI without notifying
Doc, and we find out after chapters have gone out for review that the screen
shots are wrong. How do you make sure Doc gets notified of ALL changes to
the GUI? Is there a system or a software product that ensures that this
information isn't lost?

I helped set up the documentation department in our company. One thing we
fought for is to have a standard procedure in place where everyone is
informed about changes to each system in development, not only to the GUI
but functions as well, and the reasons for these changes.
Now, for each product (project), we have a librarian/compiler who receives
all the source codes from the developers and compiles these into a new
version. Depending on the product or delivery schedules, compilation takes
place once/twice a week, even daily. The librarian is then responsible for
informing (via e-mail) all the members of that project whenever a new
*version* is available. Always included in the e-mail is a list of changes,
new *features* or functions (with corresponding Specification or User
Requirement numbers), defect fixes (with corresponding defect log numbers),
and so on.
The list can be an attachment, or the librarian can point you to a folder in
your server. The items in the list come from the various developers who are
checking in new or revised code. Each time they check in something, they
provide an outline of the changes they've made and the reasons for these
changes (bug fixes, new *feature*, approved user requirement, etc.) The
librarian collects all these, and pass it on to the documentation and
testing teams for each new version. If you have a testing department, each
new *version* can also come with a list of the status of the bug fixes or
reported errors that the testing lead can compile. This will help your
documentation team a lot, not only for GUI changes, but for changes to how
the system functions as well.
All the best,
Mila Bongco

(you can post this to the techwhrlr list if you like - I could not do a
straight reply because my mail system locked up when I tried to do that from
your posting).

From ??? -at- ??? Sun Jan 00 00:00:00 0000=

Previous by Author: Keeping track of software changes
Next by Author: Job opening
Previous by Thread: Keeping track of software changes
Next by Thread: Re: Keeping track of software changes

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

Sponsored Ads