Fwd: Re: Task Analysis & Data Flow Diagrams

[Anthony Markatos <tonymar -at- HOTMAIL -dot- COM>]

>Received: from 207.180.210.148 by www.hotmail.com with HTTP;
>       Mon, 13 Jul 1998 08:41:01 PDT
>X-Originating-IP: [207.180.210.148]
>From: "Anthony Markatos" <tonymar -at- hotmail -dot- com>
>To: utest -at- hubcap -dot- clemson -dot- edu, ebuie -at- csc -dot- com
>Cc: tonymar -at- hotmail -dot- com
>Subject: Re: Task Analysis & Data Flow Diagrams
>Content-Type: text/plain
>Date: Mon, 13 Jul 1998 08:41:01 PDT
>
>
>Tony Markatos said:
>
>DFDs are the most direct means of capturing procedure available.
>
>Elizabeth Buie asks:
>
>I don't understand this.  It seems to me that sequence is a critical
>aspect of procedure -- and we've already agreed that DFDs don't capture
>sequence.  Can you explain why, therefore, they're so good at capturing
>procedure?
>
>Tony Markatos responds:
>
>Do not equate procedure in general with detailed procedure.  Procedure
>can be expressed at a high level (i.e., summary or highly abstract
>level), detailed level, or any level in-between.  At the detailed
level,
>I myself use sequence.  That will work.  What will not work (especially
>for larger scale projects) is trying to specify procedure sequentially
>at higher levels of abstraction.  Here procedure is highly asynchronous
>(i.e., many things happening at the same time) - it defies description
>by sequential (synchronous - one thing happening at a time) techniques.
>Sequential techniques include logical flow charts, task lists,
>heirarchical techniques, and of course text.
>
>You may say, "Well, I'll just work at the detailed level".  Problem
then
>is how do you tie together all of this "ocean of detail".  (Note: it
>goes without saying; but, I will say it anyways. Unless all the
detailed
>procedure is tied together to form an integrated whole, the
>documentation is of little or no use.)
>
>To integrate your detailed procedure into a coherent whole, you need to
>be able to see "the forest through the trees" - to see the "bigger
>picture".  And to do this, you must work at a higher level of
>abstraction.  Again, this is especially true when the scope of the
>procedure is larger scale.
>
>You need to use Data Flow Diagrams.  They are the ONLY tool which can
>capture the "bigger picture" for larger scale procedures documentation
>projects.
>
>Tony Markatos said:
>
>(Often analysts) create something that kind of looks like a DFD, but
>really is not.  These diagrams may have bubbles like a data flow
diagram
>but they only convey information about HOW the system works (i.e.,
>design info), not WHAT the system does from an end users perspective.
>
>Elizabeth Buie asks:
>
>Now wait a minute.  Data flow diagrams can be used to capture data flow
>inside the software system, at a more detailed level than what the end
>user sees.
>
>Tony Markatos responds:
>
>In order to respond to your question, I need to digress here a moment
>and discuss the concept of a mechanism in procedure analysis.  Lets
look
>at a very simple hypothetical task: manipulating two numbers.  And lets
>say that the procedure to accomplish this task is to add the first
>number to the second.  Now, we can utilize a human being to accomplish
>this procedure.  Or, we can utilize a computer, electronic curcuits, or
>a mechanical machine.  Each of these is a different mechanism to
execute
>the procedure of adding the first number to the second.
>
>Data Flow Diagrams are used to capture a system or interrelated
>procedures irregardless of the mechanism used to accomplish each of the
>individual procedures.
>
>So; yes, Data Flow Diagrams can be used to capture procedure
>accomplished within a computer.  But there is nothing that says that
>they have to do such.  You can simply restrict your analysis to only
>that procedure accomplished when the mechanism is a person (i.e., end
>user).
>
>Actually Elizabeth, you bring up a very important issue and another
very
>important unique benefit of Data Flow Diagrams in performing end user
>task analysis.  The scope of what is traditionally referred to as the
>procedure documentation portion of end user task analysis is limited to
>only that procedure in which the mechanism used is a person (end user).
>But ask yourself, if the whole system of procedure consists of a
variety
>of interacting mechanisms, don't we need to look at that portion of the
>procedure accomplished by each of these mechanisms in order to develope
>a coherent understanding of what the users are doing?  In my own task
>analysis assignments, I have ALWAYS found such to be true.
>
>Tony Markatos said:
>
>Properly used Data Flow Diagrams are a tool for capturing procedure.
>Period.
>
>Elizabeth Buie responds:
>
>This strikes me a just a wee bit narrow.  The only proper use is a
>tool for capturing procedure?  Hmmm...  I would say instead that they
>are a tool for capturing the flow of data/information among the various
>pieces of something -- a satellite ground system, an organization, even
>a software application -- and I'd allow for the possibility that they
>might be used for capturing procedure.  But without an understanding of
>how one completes the procedure definition by adding sequence, I'm
>afraid I would be hard pressed to allow for this.
>
>Tony Markatos responds:
>
>I do not understand.  What are you going to do with a bunch of data
>flows?  I can not think of anything (unless you are into data base
>design and need a data dictionary).  Why does an end user task analyst
>need to know about the data flows?
>
>Now an clear and concise understanding of the "bigger picture" of the
>procedure - that's of tremendous vale to a task analyst.  With such an
>understanding, "drilling down" into the details is realatively easy.
>
>Tony Markatos said:
>
>(Data Flow Diagrams) are a very powerfull tool for (performing end user
>task analysis).  I have seen one task analyst using them outperform a
>competing group of analysts trying to use other techniques (actually, I
>was the analyst).
>
>Elizabeth Buie asks:
>
>"Outperform" in what sense?
>
>Tony Markatos responds:
>
>Wow!  This is a real easy one to answer!  Efficiency (i.e., getting
>things done much faster) and Effectiveness (getting the right thing
>done).  Also, end uer friendlyness (i.e., documentation which the end
>users can easily understand) and maintainability (i.e., documentation
>which future generataions of task analysts can understand).  Lets see;
>have I left any performance issue out?  Believe me, if I did, I can
make
>the case for Data Flow Diagrams for that factor.
>
>Eliabeth Suie asks:
>
>And how did you capture sequence?
>
>Tony Markatos responds:
>
>At the detail level - where it belongs.
>
>*Hope this helps*
>
>Tony Markatos
>(tonymar -at- hotmail -dot- com)
>
>
>
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com