Re: Full life cycle development


> Collecting all the requirements itself is an ongoing activity because
> of changes in business in time.

Our customers do not see this. They see requirements gathering and
requirements clarification as two different things. To them, the
requirements didn't really change, just because the analyst finally
understood enough to ask a good question that elucidates a ten-page
response. The fact that that response changes an underlying assumption is
not their fault. The fact that a known problem that wasn't important
yesterday has become important today is also not a change in their eyes.
After all, we knew it was a problem.

The other problem is how the technical community has reacted. Instead of
building processes that can adapt, we have traditionally built processes
based on planning and better requirements gathering. Dozens of books, many
considered "classics," have been written about the right way to gather and
document all of the requirements. Note: ALL of the requirements. Few books
say "gather SOME of the requirements" and "here is how to find out more
after development begins..."

This is an education process. We have to start with ourselves.

>
> I think water fall is more of academic exercise which could never would
> have materialized at any time

I disagree. I have seen "get the requirements right, first" in nearly every
organization I've worked in for over 20 years. It has happened naturally in
every one. Some folks were taught that waterfall was the right approach (in
college) and didn't question it (why should they?), while others reacted to
the failure of a past project by increasing the emphasis on getting the
up-front requirements correct.

Even organizations that "say" that they use iterative processes often do
not. It would be funny if it weren't so sad.

It is also a very real problem that has led to a huge failure rate for new
software development projects. If it hasn't affected you personally, talk
to your co-workers. You won't have to go far to find someone who has had to
live with a project failure on a waterfall project.
..
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--


.

Relevant Pages

  • Re: Moral dilemma at work....
    ... employer when it shows you were terminated for failure to follow a ... That's why I suggested keeping a copy of your memo. ... An employer worth ...
    (rec.crafts.metalworking)
  • Re: Moral dilemma at work....
    ... "Steve B" wrote: How would it look to your next prospective ... employer when it shows you were terminated for failure to follow a direct ... He'll just see red flags that this employee will copy down internal memos ...
    (rec.crafts.metalworking)
  • Re: Moral dilemma at work....
    ... "Steve B" wrote: (clip) How would it look to your next prospective ... employer when it shows you were terminated for failure to follow a direct ...
    (rec.crafts.metalworking)