Models

The Waterfall Model
The waterfall is the best known. It consists of 5 phases:
1. Requirements (in which the customer requirements are written).
2. Design (in which the high and low-level design documents are written).
3. Code (in which the code is written and (hopefully) unit tested).
4. System test (which is where we come in).
5. Installation and cutover: (in which the finished (!) system is installed, the users are trained, and the system is put to use).

This is an approach which everyone says is out-of-date and which everyone uses more or less. It suffers from the dangers that:

• Bureaucrats believe such phases are finite and cannot be iterated upon.
• It doesn’t allow for parallel activities such as prototyping or the development of user interface specifications (which in themselves require their own life-cycle) or for safety-critical system issues such as the development of a safety case.
• It makes no mention of contract preparation, project management, reviews, or audits.
• It implies that system testing starts only when coding is finished.
• It says nothing about software reuse.

It has the merit that:
• Each phase generates some baseline deliverable.
• It is well-known.
• It has been used for many years.
• It is very adaptable.
• Each process can be decomposed into others.
• You can add any process you want.

If people can simply accept that:

• Each phase may have to be repeated (as requirements change, as prototypes evolve).
• It needs to be seen in parallel with a number of other life-cycles with which it must stay synchronized.
• It can be modified for prototypes and software reuse.
• Testing input begins at least as early as requirements definition (and arguably it is as well to have the test team review the request for proposal and contract for test implications).
• Any change to requirements, design, or code must be (manually) reflected through all levels of documentation to ensure all documents are consistent (which rarely happens).

then it is perfectly usable.