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: Waterfall vs. Spiral development and doc (was: RE: Why is working from a spec like walking on water?)
Subject:Re: Waterfall vs. Spiral development and doc (was: RE: Why is working from a spec like walking on water?) From:"Anthony Markatos" <tonymar -at- hotmail -dot- com> To:Janet_Swisher -at- trilogy -dot- com, techwr-l -at- lists -dot- raycomm -dot- com Date:Wed, 17 Nov 1999 11:58:38 PST
Tony Markatos responds to Janet Swisher (see below):
Janet, in the real world, for larger scale software projects; nobody, but
nobody has been able to develop utilizing a very rigorous waterfall
approach. When was the last time that you saw a complete set of data flow
diagrams, entity relationship diagrams, and a data dictionary? These are
the first outputs created in a waterfall effort. Without them, the whole
appraoch falls apart.
Data flow diagrams and other tools of structured systems analysis are really
just mechanisms utilized to enforce open and honest communication between
software project particpants and end users. People can only withstand so
much honesty; try to trap them into more, and the revolt big-time.
This is not to say that the "spiral" approach is the answer. If it was,
there would be no debate. Nobody can develop software without at least a
fair understanding of end user tasks and data relationships (this is what
SSA techniques try to capture using a very formal process). The spiral
approach just assumes that the designers have already obtained this
understanding, basically, by either having done something simular in the
past or by just "hanging around" and gaining an understanding of the end
users tasks informally. Where this assumtion proves fatal is in larger
scale projects that are not "knock-offs" from something simular.
To the degree that development is successful with the chosen methodology, so
to will be the documentation folks.
Janet Swisher said:
...It seems to me that most of the discussion I've seen of documentation
development assumes a waterfall model for both the product and the
documentation. I would also be very interested in hearing others' comments
on documentation in a spiral-model environment.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
