Re: Life Cycle PLanning

[David Neeley <dbneeley -at- gmail -dot- com>]

Tony,

Generally, when a program is to be developed, it is not only to
memorialize what are the present practices, but what the customer
wants them to be.

I would agree that getting an understanding of the present
circumstances is obviously part of the analysis phase, and diagrams
may be very helpful...but it is not necessarily the most effective
method of eliciting where perceived improvements can be found.

Thus, part of my work involves determining where the "points of pain"
are that are, after all, the frequent reason that a program is
requested to begin with.

It can easily be that a diagram can be helpful for this--but my point
has been all along that it is not the only method, nor necessarily the
place to begin.

You asked "who my users are." In three decades, they have ranged from
a facilities maintenance department at the El Segundo facility of
Xerox Corporation to manufacturing to engineering to graphic arts
departments....with stops in between automating mail rooms and
insurance offices and many others, and in doing both original
documentation and updates for industries such as telecomm.

What I have learned through nearly three decades is that there is no
single, fixed rule that fits all situations. What is "state of the
art" methodology today can be very much behind the times tomorrow--or
vary from field to field at any given time.

If in your work *you* prefer to use diagrams as your own method of
getting a handle on a customer's situation--go for it! However, the
diagram itself comes from what you learn from the customers--it
doesn't appear magically in a fully-formed state. For this
information, you must obviously ask questions and examine processes.

There are times, for instance, that we must examine existing database
structures to determine what data is captured and what is done with
it...often as only one part of a complex process. This can, indeed, be
a classic use of diagramming.

For example, in one manufacturing project, a partner and I had to
analyze how the existing line worked and how it could be upgraded for
more efficient operation. We were also charged with being sure that
"hooks" were designed in for an ERP application that had not even been
chosen at that point. By the time we were finished, we had developed
*many* diagrams as part of our work--both of the existing situation
and what we believed could and should be done to re-engineer the whole
process then in use to reduce inventories and merchandise handling
substantially.

However, getting to a meaningful state of understanding was the work
of many, many months and required a large amount of ingenuity, tact,
and patience. Our final report, I assure you, was "rigorous" in any
sense of the term. Getting there, though, was the result of a panoply
of techniques and experiences...not just an exercise in diagramming.

Before the diagram you must learn the questions to ask--and those
questions may vary from situation to situation.

David

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

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.