can anyone suggest me ,if requirement goes on changing when we are following waterfall model.
The model does not determine whether a requirement changes or not. Hope this helps!
In the traditional waterfall model, all requirements are elicited and documented, then handed over for design and development. JP is right in that the model does not specify if a requirement changes or not - it only determines how you deal with the change.
I have seen a couple of different approaches. One was that "requirements have been approved, so we are not going to allow any changes, even if they are good changes." I don't like that one. The other is "we will do a review, put the requirement change through the change control process. If it is a good change, we will accept it and modify the project scope." I like that one better.
The problem outlined above was one of the driving factors in going toward iterative development models, which, if you look at them closely, are really a series of "rapids" as opposed to a "waterfall".
I'm going to suggest that this topic is in the wrong forum. It should be under requirements management.
One of the challenges of developing software in a dynamic environment is that requirements change all the time. This has nothing to do with using a waterfall model to structure a logical sequence of work to get from project initiation to closure of that project. What change has to do with is a change control process that allows the work in progress to be adapted to emerging needs.
There are development approaches specifically for handling vague requirements that chrystallize as your project evolves. Unfortunately, with respect to changing requirements these approaches have a tendency to become never ending unless you manage the project very carefully (like finding a right moment to exit a whirlpool). That is not to say there is anything wrong with these methods either because the problem is far more fundamental.
Even if a company knew perfectly what it wanted and used a detailed requirements definition with a traditional waterfall based project, when that project is being developed the world turns and it is likely that competitive ideas emerge that make the work in progress obsolete. That is why there is a need for shorter projects that contribute to evolving a software product in stages. You could even create multiple overlapping projects so that you start building the next version of software while the previous version is not yet released, which is why change management is one of the key skills for a project team, and why there are so many different agile approaches as well.
One of the major differences between Waterfall and Agile lies in original estimation. Agile, by it's very nature, requires substantially higher contingency time, frequent change is/should be accounted for(?).
So, what about handling changes in waterfall model?
Every change affects the original estimation.
Minor changes not necessarily so much, major changes dramatically.
So, we must have a formal change control process - one that includes impact analysis, and this in turn includes effort impact across the board from design to test.
Each change must require re-estimation, and often contract renegotiation - especially if you are working 'fixed price' as opposed to 'time and materials'.
A major problem I still have with agile, it is often a disaster waiting to happen on fixed price contracts unless either masses of contingency has been included or rigid controls are in place.
To specifically answer Debarshi's question, I have yet to see a truly complete waterfall model, there is always some iteration.
So yes, in practice requirements usually do change even in the waterfall model.
In the ideal world where trully waterfall applies, no requirements do not change - remember, the model requires each stage to be complete prior to the next commencing.
[ 08-05-2005, 03:33 PM: Message edited by: KBEE01 ]
Referring to the framework documents for the so-called "waterfall" and management of change...
Requirements change is expected throughout the entire process. In order to manage change, CCBs and/or CCBs are called out. Estimating is a big part of the process.
“Waterfall” is a misnomer for an iterative development life-cycle. Today’s understandings and perceptions of the “Waterfall” have no basis in fact. Therefore any comparison of the “Waterfall” to Agile or others, is falsely based. The origins of the myths are quite simple – failure of consumers to read and understand.
MIL-STD-483 and all appendices
DOD-STD-1679 (from MIL-STD-1679)
DOD- STD -2167
DOD- STD –2168
… and all standards related to acquisitions,
… and all relevant DIDs and MCCRs. (These are key documents to understanding the iterative nature of this noname sdlc, cast under the misnomer - "waterfall".)
Having been on both sides of defense contracts operating under combinations of the above, I can attest to the fact that requirements changes are managed throughout – to the point of being rightfully anal about each. I can also safely state that the waterfall is truly a myth.
If commercial companies involved in IT controlled change as well as the DoD, there would be far less pain expressed here at these forums. [img]images/icons/frown.gif[/img] You will never see a biz rep going up to a designer/developer and demanding or getting a change implemented on the spot.
You may find change request forms and successors to the standards and specs referenced above - here:
[ 08-06-2005, 03:13 PM: Message edited by: JakeBrake ]
Re: “Waterfall” is a misnomer for an iterative development life-cycle.
This statement should be chiseled in granite and placed as the headstone on buried myths of many kinds. Of course it is a misnomer, just as it is a fallacy to suggest that some projects do not carry elements of what we consider a "waterfall" life cycle. Let me explain.
So long as projects are projects, defined as some bundle of effort with a defined start and finish, no methodology is iterative, but there may be iterative elements in any methodology. Therefore, it is quite possible to have an agile phase in a waterfall project, depending on the uncertainty underlying what the client wants to develop. Only if you knew 100% in advance everything you wanted to incorporate with no chance of change, only in those rare instances would a "waterfall" project behave according to its prototype. That is like waiting for Satan's brand ice cubes on a blue moon.
What the "waterfall" represents is a breakdown of the total time of a project in logical phases. If you come up with new requirements during a phase dedicated to defining requirements that is good. If you come up with new requirements during later coding phases that causes a big ripple effect of having to potentially undo work that was done earlier. As stated above, that happens all the time and therefore we need to have change control in place to ensure things don't get out of hand.
One of the best uses of the Agile approaches is a focused joint effort between clients, designers, and developers to sort out those things that have to be tried to be defined. Things that are clear as chrystal do not require an Agile approach and can be developed in a single pass, but in a large number of mission-critical projects things aren't quite so black-and-white that JAD sessions might not be useful.
As for the "risk" of Agile approaches on a fixed price contract, frankly speaking I would not even think of a fixed price contract unless I knew the requirements 100% up front. Elements might be on a fixed price basis, but most contracts avoid any firm commitments that are subject to change when the project is underway. In fact, I have used the various Agile approaches especially to manage the risk of hard to pin down requirements, but only under controlled conditions and that does not get into a perceived infinite series of iterations. Like any research, you may not pinpoint the right solution immediately, but in that case you still are a lot cheaper off doing it trial-and-error as opposed to going ahead with an unsatisfactory way of doing things.
In summary, the quest should not be whether one methodology is better than another, it should be to understand different methodologies and to use them in the most effective context.
I think you hit it right on the money, Frits. The "iterative" approaches I have seen used simply make the "waterfalls" much smaller, so that when the inevitable change occurs, the cost of rework is much smaller.
I worked on one project where they tried to rigorously apply the waterfall model. We went through two weeks of requirements elicitation, then the requirements were signed off. No end users were involved. The development was done, beta releases tested and then the users got it for user acceptance. Their response was that the application was a piece of crap, because it literally was doing business the opposite of the way we actually did the work, so it had to be redone. The answer was "the requirements were signed off and we can't go backwards in our SDLC, so you will have to live with the application the way it is." Once we were out of the requirements phase, change control on that project was "there will be no changes allowed."
BTW, this was a contracted development effort, by a brand name company that anyone might recognize because of their involvement with Enron.