Re: Life Cycle PLanning

Subject: Re: Life Cycle PLanning
From: David Neeley <dbneeley -at- gmail -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Thu, 16 Dec 2004 20:47:47 -0600


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.

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.

This 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.

In these methods, requirements are kept to a reasonable level in the
early stages of development--the project management understands that
there will be customer-mandated changes over time. Thus, the objective
is to have about an 80% grasp of requirements.

Then, these requirements are analyzed from the perspective of what are
the very most difficult problems to be solved--and these are made the
highest priorities in the first iterations. Immediately upon any
object being coded, testing begins.

At the same time, however, it is indeed necessary to understand all
the information resources presently used by the customer...and a
dataflow diagram is useful for this, your "as-is" scenario. However,
as I have maintained from the first, this 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.

In some cases, though, the "as-is" scenario is much less important
than in others. For example, there may be a new function in an
organization--or an existing activity may be in need of a ground-up
revamping (quite often the case with mergers and acquisitions in
putting several organizations together, in my experience). 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.

I can only repeat...I am strongly reminded when you discuss DFDs of
the "when your only tool is a hammer, all problems look like nails"
formulation.

Cordially,

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.



Follow-Ups:

References:
Re: Life Cycle PLanning: From: Ned Bedinger
Re: Life Cycle PLanning: From: Tony Markos

Previous by Author: Re: difficulties with the boss
Next by Author: Re: Seeking counsel - yet another difficult work situation
Previous by Thread: Re: Life Cycle PLanning
Next by Thread: Agile Development And Data Flow Diagrams


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


Sponsored Ads