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:Agile Development And Data Flow Diagrams From:Tony Markos <ajmarkos -at- yahoo -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Sat, 18 Dec 2004 10:32:48 -0800 (PST)
--- David Neeley <dbneeley -at- gmail -dot- com> wrote:
When you go on to such length about "top down"
analysis, I believe you fall into a fairly serious
trap: you seem to assume that a perfect understanding
is feasible.
Tony Markos:
Couple of very important points:
1.) I always say "Proceed in as top down as fashion
as possible". I never say proceed (strickly) top
down. Big difference! The only person who can
proceed in a pure top down fashion is someone who
already has a very rigorous understanding of the
domain - and that person often does not exist.
However, it is imperative to proceed in as top down a
fashion as possible, or else the analyst will, as
DeMarco says, "Drown in an ocean of detail".
2.) Perfection is too costly. But Data Flow Diagrams
result in a much superior understanding of functional
requirements for your money.
David Neely:
In practical fact, customers dictate many of their
requirements--and often some of the key requirements
do not emerge until fairly late in a project.
Tony Markatos:
I don't understand your point? Look at a currently
hot topic in IT - Agile Development - which includes
Extreme Programming. Agile Development is
specifically meant to address the situation of late
emerging requirements. A sub-component of Agile
Development is Agile Modeling. Modeling (Data Flow
Diagramming is modeling) is just as appropriate in a
rapidly changing requirements project as it is
anywhere else!
Agile modeling proproses no new modeling techniques.
It is just guidelines that basically state that no
matter which modeling techniques you chose, use them
minimally - but also use them where essential.
Data Flow Diagrams are superior to all other
functional modling techniques - including all the UML
stuff - in rapdily changing requirments situations!
David Neely:
This [the need to address frequent late customer
requirements] is a key to the methodologies that
*throw out* the top-down model, building upon
object-oriented analysis through iterative programming
methods including the "Rational Unified Process" and
the "Extreme Programming" variant.
Tony Markatos:
Who is throwing out "top down"? Try researching
abstract use cases - for one. You are getting
techniques that are poor at supporting "top down"
confused with the - still widely recognized - need for
"top down".
Other important points:
1.) OOA is an oxymoron! The UML techniques (of which
the Rational Unified Process is just an implementation
of) is especially poor for the all important
requirements discovery phase of analysis. Why: They
all utilize a forced artifical partitioning
("chunking" to us TWs) of the system.
2.) As I previously stated, Agile Developement (of
which Extreme Programming is just a variant) fully
supports modeling (Data Flow Diagrams).
David Neely:
...as I have maintained from the first, this [Data
Flow Diagrams} is only a part of the picture...if it
were all, there would be little if any requirement for
a newly developed program or methodology to begin
with.
Tony Markos:
I don't understand you here. To me you are saying
that if we plan for a system, then there is no need
for the system.
David Neely:
In some cases, though, the "as-is" scenario is much
less important than in others. ...In these cases,
knowing how the system should work when finished is by
far the most significant--and existing data and logic
flow is sometimes rather incidental.
Tony Markos:
Maybe with SOME small-scale systems, but to quote what
my Yourdon DFD instructor drilled into our heads:
"Ninty-eight percent (98%) of the required work in ANY
systems project is to come with a rigorous 'As Is'
model.". I have always found this to be true.
Tony Markos
Show Me Your DFDs
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
ROBOHELP X5 - SEE THE ALL NEW ROBOHELP X5 IN ACTION!
RoboHelp X5 is a giant leap forward in Help authoring technology, featuring all new Word 2003 support, Content Management, Multi-Author support, PDF and XML support and much more! View an online demo: http://www.macromedia.com/go/techwrldemo
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.