Waterfall Development Methodolgy

Learn Access VBA With The Smart Method.  Microsoft Access tutorials, Discussion Forums, Training Courses and Support info@learnaccessvba.com
Home Home  Site Map Site Map  Free Tutorials Free Tutorials Application
Development
application development Buy The Book Buy My Book Classroom
Courses
Classroom delivered courses Contact Contact Details
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.

waterfall method
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 sign-off.

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.