RE: Example of a good DFD

Subject: RE: Example of a good DFD
From: "Walden Miller" <wmiller -at- vidiom -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Fri, 29 Oct 2004 00:16:18 -0600


Nice example... simple and illustrative. A more complex DFD might be more
useful in showing their power. I will look around for one to post or point
to.

I have used data flow diagrams often as a first step toward requirements and
use case development and design...

So I've been reading this thread on and off today and wondering when use
case development and analysis would come into the discussion (eric
mentioned it and didn't follow up on it). Since no one else is discussing
it, I will throw it in. I think that DFD's and Use cases and flowcharts are
extremely useful design tools. Tony is handling the DFD discussion, most
people seem to understand a flowchart (though most don't really use them
much anymore--I was brought up in comp sci dept that required all programs
to be flowcharted before coding (dating myself)). I will throw out some
observations about use cases.

(For Eric) I work in the CableTV/Sat software industry. We write middleware
and interactive TV applications for set-tops. Many of our projects start
with use case development and analysis. The use cases are used in a variety
of ways by various team members:

Use cases become the roadmaps for test cases
Use cases become the roadmaps for requirements/architecture/design/GUI
Use cases become the roadmaps for documentation of process or use scenarios
Use cases often will generate code stubs to jump start development.

Use cases, for those that haven't used them before, essentially walk through
scenarios in as little or great detail as you have time for. For example, we
might walk through the up-purchase of a cable service starting at the tv
viewer attempting to watch a on-demand movie they could watch if only they
subscribed to HBO. The use case would follow the remote control input, the
data flow, the interactions, the API calls, etc. between the viewer, the
set-top, the local headend, the billing system, the VOD server (national?),
etc. There is a whole vocabulary of use cases. Many tools use UML to
generate/create the use cases. They generally get so large (if detailed)
that only plotters can print them usefully. So we view them online, of
course.

I participate in use case development discussions, but I am tool agnostic
(other than not liking Rational products--but I will use them if the client
requires it). Right now we are using TogetherSoft, but we may start using
MagicDraw. We have used Visio for some projects because it is already on
everyone's computer and it was easier than getting licenses and/or
installing new software. The important issue for us is to use a tool we can
all use together and share. Writers and Testers and Architects develop and
comment on Use Cases as a team. Paper copies don't cut it here (although
there is a percentage of "old-school" staff that prefer using Word to write
out use cases instead of making pretty pictures--yow)

So what is this discussion about? Use of diagrams to help develop projects
and documentation (as a subset of a project or as the full project).

I don't think anyone debates the practicality of using diagrams or use cases
or outlines (verbal diagrams) or flowcharts or quick brainstorming on white
boards. OR combinations of the above. Does this save money or time?
Project organization saves time/money. Often diagramming helps organize.
Project understanding saves time/money. Often diagramming helps
understanding. Etc.

Perhaps some of the discussion is just lack of familiarity with DFD's or
other similar design tools/methodologies.

Personally, I do most of my outloud thinking on whiteboards (I have an 8' x
12' whiteboard on one wall of my office). On any given day, you might find
large tables of data or DFD's or flowcharts on my board. The last company I
contracted to used digital cameras to capture white board sessions. I just
don't know how germane that is to anyone else's style. As Kat observed this
afternoon, Tools is tools.

Throwing my .02 into the hat
walden

Kat also said Fiddlesticks, which I find quite refreshing :)



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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.



Follow-Ups:

References:
Example of a good DFD: From: Tony Markos

Previous by Author: RE: I need a user-friendly term
Next by Author: Managing help when multiple tools are in one GUI
Previous by Thread: Example of a good DFD
Next by Thread: RE: Example of a good DFD


What this post helpful? Share it with friends and colleagues:


Sponsored Ads