Defference Between Iterative and Waterfall Processes

One of the biggest debates about process is that between waterfall and iterative styles. The terms
often get misused, particularly as iterative is seen as fashionable, while the waterfall process seems
to wear plaid trousers. As a result, many projects claim to do iterative development but are really
doing waterfall.

Defference :

The essential difference between the two is how you break up a project into smaller chunks. If you
have a project that you think will take a year, few people are comfortable telling the team to go
away for a year and to come back when done. Some breakdown is needed so that people can
approach the problem and track progress.

WaterFall Process:

• The waterfall style breaks down a project based on activity. To build software, you have to do
  certain activities: requirements analysis, design, coding, and testing. Our 1-year project might thushave a 2-month analysis phase, followed by a 4-month design phase, followed by a 3-month coding
  phase, followed by a 3-month testing phase.
• With waterfall development, there is usually some form of formal handoff between each phase,butthere are often backflows. During coding, something may come up that causes you to revisit the analysis and design. You certainly should not assume that all design is finished when coding begins. It's inevitable that analysis and design decisions will have to be revisited in later phases. However, these backflows are exceptions and should be minimized as much as possible
• The Waterfall Model is the classic software life cycle model. According to Schach [1999], this model was the only widely accepted life cycle model until the early 1980s. This model represents the software life cycle using processes and products. Each process transforms a product to produce a new product as output. Then the new product becomes the input of the next process. The table below lists the processes and products of the Waterfall Model.
   

                                                    

• Notice that the output product on the right becomes the input product on the left of the process at the next lowest level. The general formula for describing the transformation of products by processes can be written as follows:
                                                               
  
  

• Each product is represented by a gray box and each process is represented by a solid arrow connecting the boxes.

Iterative Process:

• The iterative style breaks down a project by subsets of functionality. You might take a year and
  break it into 3-month iterations. In the first iteration, you'd take a quarter of the requirements and do the complete software life cycle for that quarter: analysis, design, code, and test. At the end of the first iteration, you'd have a system that does a quarter of the needed functionality. Then you'd do a second iteration so that at the end of 6 months, you'd have a system that does half the functionality.
• With iteration, you usually see some form of exploration activity before the true iterations begin. At the very least, this will get a high-level view of the requirements: at least enough to break the requirements down into the iterations that will follow. Some high-level design decisions may occur during exploration too. At the other end, although each iteration should produce production-ready integrated software, it often doesn't quite get to that point and needs a stabilization period to iron out the last bugs. Also, some activities, such as user training, are left to the end.
• You may well not put the system into production at the end of each iteration, but the system should be of production quality. Often, however, you can put the system into production at regular intervals; this is good because you get value from the system earlier and you get better-quality feedback. In this situation, you often hear of a project having multiple releases, each of which is broken down into several iterations.
• Iterative development has come under many names: incremental, spiral, evolutionary, and jacuzzi spring to mind. Various people make distinctions among them, but the distinctions are neither widely agreed on nor that important compared to the iterative/waterfall dichotomy.

                                                                 

       Prefer Iterative Process Over Waterfall Process

• Most writers on software process in the past few years, especially in the object-oriented community, dislike the waterfall approach. Of the many reasons for this, the most fundamental is that it's very difficult to tell whether the project is truly on track with a waterfall process. It's too easy to declare victory with early phases and hide a schedule slip. Usually, the only way you can really tell whether you are on track is to produce tested, integrated software. By doing this repeatedly, an iterative style gives you better warning if something is going awry.
• For that reason alone, I strongly recommend that projects do not use a pure waterfall approach. You should at least use staged delivery, if not a more pure iterative technique. 
• The OO community has long been in favor of iterative development, and it's safe to say that pretty much everyone involved in building the UML is in favor of at least some form of iterative development. My sense of industrial practice is that waterfall development is still the more common approach, however. One reason for this is what I refer to as pseudoiterative development: People claim to be doing iterative development but are in fact doing waterfall. Common symptoms of this
  are:
  • · "We are doing one analysis iteration followed by two design iterations. . . ."
  • · "This iteration's code is very buggy, but we'll clean it up at the end."
  It is particularly important that each iteration produces tested, integrated code that is as close to
  production quality as possible. Testing and integration are the hardest activities to estimate, so it's important not to have an open-ended activity like that at the end of the project. The test should be that any iteration that's  

References: UML DISTILLED