Waterfall Development Methodolgy

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.

• 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.

• 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.

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.