Thursday, November 24, 2011

Waterfall Model - Software Engineering TE[Comp&IT] - Sem 5/ Sem 6

                                 ( Download as PDF )

Waterfall Model

     Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate process phases.


Waterfall development isn't new -- it's been around since 1970 -- but most developers still only have a vague idea of what it means. Essentially, it's a framework for software development in which development proceeds sequentially through a series of phases, starting with system requirements analysis and leading up to product release and maintenance . Feedback loops exist between each phase, so that as new information is uncovered or problems are discovered, it is possible to "go back" aphase and make appropriate modification. Progress "flows" from onestage to the next, much like the waterfall that gives the model its name.
The phases in Waterfall model are: 

Requirement Specifications phase
Software Design
waterfall model

The stages of "The Waterfall Model" are:

Requirement Analysis & Definition:

    All possible requirements of the system to be developed are captured in this phase. Requirements are set of functionalities and constraints that the end-user (who will be using the system) expects from the system. The requirements are gathered from the end-user by consultation, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be development is also studied. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model.

System & Software Design:
Before a starting for actual coding, it is highly important to understand what we are going to create and what it should look like? The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture. The system design specifications serve as input for the next phase of the model.

Implementation & Unit Testing

On receiving system design documents, the work is divided in modules/units and actual coding is started. The system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality; this is referred to as Unit Testing. Unit testing mainly verifies if the modules/units meet their specifications.

Integration & System Testing

As specified above, the system is first divided in units which are developed and tested for their functionalities. These units are integrated into a complete system during Integration phase and tested to check if all modules/units coordinate between each other and the system as a whole behaves as per the specifications. After successfully testing the software, it is delivered to the customer.

Operations & Maintenance

This phase of "The Waterfall Model" is virtually never ending phase (Very long). Generally, problems with the system developed (which are not found during the development life cycle) come up after its practical use starts, so the issues related to the system are solved after deployment of the system. Not all the problems come in picture directly but they arise time to time and needs to be solved; hence this process is referred as Maintenance.

Advantages and Disadvantages


The waterfall model, as described above, offers numerousadvantages for software developers. First, the staged development cycleenforces discipline: every phase has a defined start and end point, andprogress can be conclusively identified (through the use of milestones) by bothvendor and client. The emphasis on requirements and design before writing asingle line of code ensures minimal wastage of time and effort and reduces therisk of schedule slippage, or of customer expectations not being met.
Getting the requirements and design out of the way firstalso improves quality; it's much easier to catch and correct possible flaws atthe design stage than at the testing stage, after all the components have beenintegrated and tracking down specific errors is more complex. Finally, becausethe first two phases end in the production of a formal specification, thewaterfall model can aid efficient knowledge transfer when team members aredispersed in different locations.


Despite the seemingly obvious advantages, the waterfallmodel has come in for a fair share of criticism in recent times. The most prominent criticism revolves around the fact that very often, customers don'treally know what they want up-front; rather, what they want emerges out ofrepeated two-way interactions over the course of the project. In thissituation, the waterfall model, with its emphasis on up-front requirementscapture and design, is seen as somewhat unrealistic and unsuitable for thevagaries of the real world. Further, given the uncertain nature of customer needs, estimating time and costs with any degree of accuracy (as the model suggests) is often extremely difficult. In general, therefore, the model is recommended for use only in projects which are relatively stable and wherecustomer needs can be clearly identified at an early stage.
Another criticism revolves around the model's implicitassumption that designs can be feasibly translated into real products; this sometimes runs into roadblocks when developers actually begin implementation.Often, designs that look feasible on paper turn out to be expensive ordifficult in practice, requiring a re-design and hence destroying the clear distinctions between phases of the traditional waterfall model. Some criticism salso center on the fact that the waterfall model implies a clear division of labor between, say, "designers", "programmers" and"testers"; in reality, such a division of labor in most software firms is neither realistic nor efficient.

Customer needs

While the model does have critics, it still remains usefulfor certain types of projects and can, when properly implemented, produce significant cost and time savings. Whether you should use it or not dependslargely on how well you believe you understand your customer's needs, and howmuch volatility you expect in those needs as the project progresses. It's worth nothing that for more volatile projects, other frameworks exists for thinking about project management, notably the so-called spiral model...but that's a story for another day!


Video Lectures

Overview of Different Models

Waterfall vs Agile