You are on page 1of 5

The Waterfall Development Methodology

An excellent methodology when requirements are thoroughly and accurately defined. We've had great success using this method to build large and complex applications.

The Waterfall Model The waterfall model was first defined by Winston W. Royce in 1970 and has been widely used for software projects ever since. Royce's original model is shown on the right. It differs from the agile development model by seeking to fully describe the application in written documents before any code is written (the implementation phase). Our own implementation of the requirements/design phase is to produce a Functional Specification (detailing what the application will do) and a User Interface Specification (detailing how it will do it). Only when these documents are signed off can the actual process of building the application commence (the implementation phase). When using this methodology it is vital that all requirements are captured during the Requirements/design phase as it can be very expensive to re-visit requirements once implementation (coding) has begun.

When done well the waterfall method is excellent for large projects and there are no surprises when the application is finally delivered as all features and even the appearance of the application has been fully specified and understood by future users of the system. We've had great success with large projects using this method and can show potential clients excellent functional specifications produced for previous successful projects. If the requirements phase is done badly (and this is often the case when the business confuses shoddy requirements with faster progress) the waterfall method delivers failure as the end result will only ever be as good as the specifications. Advantages of the waterfall method

Design errors are captured before any software is written saving time during the implementation phase. Excellent technical documentation is part of the deliverables and it is easier for new programmers to get up to speed during the maintenance phase. The approach is very structured and it is easier to measure progress by reference to clearly defined milestones. The total cost of the project can be accurately estimated after the requirements have been defined (via the functional and user interface specifications). Testing is easier as it can be done by reference to the scenarios defined in the functional specification.

Disadvantages of the waterfall method

Clients will often find it difficult to state their requirements at the abstract level of a functional specification and will only fully appreciate what is needed when the application is delivered. It then becomes very difficult (and expensive) to re-engineer the application. The model does not cater for the possibility of requirements changing during the development cycle.

A project can often take substantially longer to deliver than when developed with an iterative methodology such as the agile development method.

Waterfall development in action Our first step is to create the functional specification. This often begins life as a very abstract requirements specification provided by the client. In order to create the functional specification we talk to business experts and examine the business processes currently being catered for by manual or legacy computer systems. When we have a full understanding of the business the functional specification is published and distributed to as many business experts as possible for feedback. When the functional specification is final we often convey a meeting of business experts and work through the final copy together to iron out any errors prior to signoff. When the functional specification is signed off we produce a non working prototype application along with a user interface specification. The non-working application shows business experts how the screens will look and how the functionality defined will be delivered. Users are far better able to provide feedback when they can touch, feel and see the screens that they will use. When everybody is happy that the screens will deliver the functionality required the application can be developed and tested. When the application is complete a beta release is published and provided to the business for testing. Any bugs found are rapidly repaired. When no significant bugs remain and the client is happy with the application it can go live as release version 1.0. What is Waterfall Iterative Model? Waterfall Model is one of the most widely used Software Development Process.It is also called as "Linear Sequential model" or the "classic life cycle" or iterative model. It is widely used in the commercial development projects. It is called so because here, we move to next phase(step) after getting input from previous phase, like in a waterfall, water flows down to from the upper steps. In this iterative waterfall model Software Development process is divided into five phases:a) SRS (Software Requirement Specifications) b) System Design and Software Design c) Implementation and Unit testing d) Integration and System Testing e) Operation and Maintenance

Iterative Waterfall Model with its stages Lets discuss all these stages of waterfall model in detail.

Software Requirements Specifications: This is the most crucial phase for the whole project, here project team along with the customer makes a detailed list of user requirements. The project team chalks out the functionality and limitations(if there are any) of the software they are developing, in detail. The document which contains all this information is called SRS, and it clearly and unambiguously indicates the requirements. A small amount of top-level analysis and design is also documented. This document is verified and endorsed by the customer before starting the project. SRS serves as the input for further phases.

System Design and Software Design: Using SRS as input, system design is done. System design included designing of software and hardware i.e. functionality of hardware and software is separated-out. After separation design of software modules(see what is modularity) is done.The design process translates requirements into representation of the software that can be assessed for quality before generation of code begins. At the same time test plan is prepared, test plan describes the various tests which will be carried out on the system after completion of development.

Implementation and Unit Testing: Now that we have system design, code generation begins. Code generation is conversion of design into machine-readable form. If designing of software and system is done well, code generation can be done easily. Software modules are now further divided into units. A unit is a logically separable part of the software. Testing of units can be done separately. In this phase unit testing is done by the developer itself, to ensure that there are no defects.

Integration and System testing: Now the units of the software are integrated together and a system is built. So we have a complete software at hand which is tested to check if it meets the functional and performance requirements of the customer. Testing is done, as per the steps defined in the test plan, to ensure defined input produces actual results which agree with the required results. A test report is generated which contains test results.

Operation & maintenance: Now that we have completed the tested software, we deliver it to the client. His feed-backs are taken and any changes,if required, are made in this phase. This phase goes on till the software is retired. Keep Reading : http://www.ianswer4u.com/2011/11/waterfall-model.html#ixzz2R63VPXUs Under Creative Commons License: Attribution Non-Commercial Share Alike Follow us: ianswer4u on Facebook

You might also like