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:Re: sources From:Suzanne Lee <suzanne -at- AUTOSIM -dot- COM> Date:Wed, 1 Mar 1995 09:22:16 -0700
>Herman Holtz asked:
>What are some of the typical sources of data today--for writing a software
>>manual,
>for example? What would be the worst case--e.g., depending on your ability to
>>read >the code? Do you get bug reports? Beta test results? Etc.
------------
In our (software) company, we used to rely on a list of enhancements and
our interviews with the developers. We would then test the software to see
whether they were telling the truth : )
We recently did two things:
1) started writing specs (what a concept). We are even trying to get SEI
quality programs into place, which will formalize the whole development
process, and guarentee that we have accurate specs to work from. This has
saved me a lot of time already.
2) got an online database to track defects. This has improved the entire
process 500% (not just documentation). First of all, when I test the
software and find a discrepancy or problem, I write it up. It's then in
the database, no way to hide it or shuffle it to the bottom of the pile;
everyone can log in and see that it's there.
The developers can also assign the defects to me after they've been fixed,
so that I am much more current and up to date than ever before. And
there's a written log of who did what about what, which is helpful if you
still have questions after reading the defect. Electronic paper trail, so
to speak. This database (Scopus) saved our skins on our last release.
These things have helped a lot. However, I don't think there'll ever be a
method that's completely perfect and headache-free. One problem that I
still have is that even though developers are now writing specs, most of
them have to be rewritten to be comprehensible. I use the specs more for
my own reference and as a starting place rather than actual docmentation in
most cases. But at least they're trying.
Finally, I have to say that every problem that has been brought up in this
thread is one that I've seen personally to some extent. It's nice to know
that misery does indeed like (and find) company!
******************************************************************************
from Suzanne Lee - suzanne -at- autosim -dot- com - (801)298-1398 ext 333
****************************************************************************
**