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:Why Creating DFDs Is Very Dangerous From:Tony Markos <ajmarkos -at- yahoo -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Fri, 29 Oct 2004 09:26:58 -0700 (PDT)
Ned Bedinger asks:
Something you said a while back seemed to suggest that
the DFD approach can be risky. What's that about?
Tony Markos responds:
Great question Ned! The answer to that question brings
to light some very important issues required to be
tech comm street smart. (I will answer your other
questions separately.)
But before I answer your question, please bear with
me, as I must first present some pertinent background
material.
Again, properly used, Data Flow Diagrams are a very
powerful technique. Why? As I recently posted, ONLY
DFDs actually prompt you through a task analysis.
How? By following the flows of data as they naturally
combine and split apart, we flush-out essential tasks
that may very well have gone undiscovered otherwise.
And thats what analysis is: a discovery process.
When we are finished with our analysis using DFDs, the
"chunks" of tasks that we have on our diagrams
represent what the gurus in analysis often call a
"natural partitioning" of the system.
Compare this with ALL other task analysis (note: same
as functional analysis) modeling techniques -
including Use Cases, all other UML functional modeling
techniques, the hierarchal task analysis techniques
espoused by the end-user task analysis community,
logical (If-Then-Go-To) flow charts, task analysis
techniques espoused by the QA community, on and on and
on. With ALL these other techniques, we first draw
boxes, or ovals, or stick men, or whatever to
represent whatever tasks (functions) that happen to
pop into our mind at the moment. And then we try to
connect them together. The problems with these
"connect-the-boxes" approaches:
* Unless the task happens to pop into our mind,
there is an excellent chance that in will remain
undiscovered; we are NOT prompted to "flush-out" the
gaps in our understand. This is a killer for larger
scale projects!
* The resulting "chunks" of tasks represent what
analysis gurus often refer to as a "forced artificial
partitioning" of the system. It would take too long
to explain what this means. Let me just say that
anything that is forced and artifical is just plain
wrong. Again, big problem.
So, if DFDs are so powerful, why are they so seldom
used? From what I have seen, and I have seen alot, I
am among the few that have utilized them correctly.
(Note: It is fairly common to see them incorrectly
used, which results in little utility, but thats
another story.)
And Now, the ANSWER TO YOUR QUESTION:
It is very dangerous to be a DFDer because DFDs, like
nothing else, enforce rigorous honesty and open
communications. They get right to the meat of the
issue: rigorous identification of essential procedure.
(See note below on essential procedure.)
Problem is that, in business, knowledge of essential
procedure is turf, and people will defend "their" turf
to the death. The danger that a DFDer faces is that
they are, on one hand, prodded to get the essential
info; but, at the same time, they are prodded, big
time, to ask questions that are often fearful. And
since the analyst is in the discovery phase, he/she
often has no idea that a given question is so potent;
it is very easy for him/her to step on a "political"
land mind!
Another danger of using DFDs revolves around the fact
that they are the only true top-down analysis
technique. Top-down means that the analyst postpones
detail(I said postpones - not forget about - big
difference!) to the appropriate time. We DFDers know
that, in order to learn anything, we must not try to
learn everything - at least not initially.
The danger with postponing detail:
The vast majority of people, including most IT
managers, have always approach there work by jumping
immediately into the details. They think: "Hey Tony
has been doing task analysis for a week now, and he
still does not know about detail X. I was here only a
day when I knew about detail X. Therefore, Tony must
be goofing off."
All the above explains my saying: "It is only by dying
(i.e., following the flow of data) that we are born
again (i.e., come to have a understanding of the
underlying logic of a system)."
**Note On ESSENTIAL procedure: A ways back I read
about a National Science Foundation study that
concluded that only about five percent (5%) of
procedure in any manual and/or automated system
is truly essential. The rest just exists
because of imperfect technology or imperfect
design.
ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl
WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l
---
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.
