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.
M J DeAngelis wrote:
>
>
> BTW, WHAT IS A TYPICAL DEVELOPMENT CYCLE? Sorry for asking a "dumb" question
> but I am fairly new to Tech writing that focuses exclusively on software. I
> come from a physics/ biomedicine background.
>
The IEEE offers a lot of good resources on the software development
lifecycle. You should be aware that there are competing schools of
thought, but this will give you a basic vocabulary, at least. Once you
demonstrate you understand that model, the manager is likely to say,
"yes, that's one way; but we do something different," and then stand up
and draw a different sketch. Show the manager you understand the new
sketch and can talk about it, and you've met the requirement handsomely.
Just to give you a broad outline, one fairly cumbersome but rigorous
development cycle works something like this:
1. Capture customer requirements in a document.
2. Translate customer requirements into a functional specification (WHAT
the software has to do).
3. Translate functional specification into design specification (HOW the
software is supposed to do the WHAT).
4. Translate design specification into working code.
5. Meanwhile, use the functional specification to write a test
specification (in order to validate that the WHAT is satisfied), and use
the design spec to write draft user documentation.
6. VERIFY that the code units each match the HOW of the design spec.
7. INTEGRATE the units (i.e., do a test build of the software) and
verify that it all works together and still matches the design spec.
8. VALIDATE the software against the functional spec (i.e., make sure it
calculates correct results).
(What happens in real life, or course, is that there is some looping
back and forth during testing, as the inadequacies of the design spec
become apparent, and this in turn affects the content of the user
documentation.)
And, as I said, there are several other methodologies.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
TECH*COMM 2001 Conference, July 15-18 in Washington, DC
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.com
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
