The first published model of the software development process was derived from other engineering processes (Royce, 1970). Because of the cascade from one phase to another, this model is known as the `waterfall model’ or software life cycle. The principal stages of the model map onto fundamental development activities:
• Requirements analysis and definition: The system’s services, constraints and goals are established consultation with system users. They are then defined in detail and serve as a system specification.
• System and software design: The systems design process partitions the requirements to either hardware or software systems. It establishes overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships.
• Implementation and unit testing: During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.
• Integration and system testing: The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer.
• Operation and maintenance: Normally (although not necessarily) this is the longest life- cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the system’s services as new requirements are discovered.
• In principle, the result of each phase is one or more documents which approved (`signed are off’). The following phase should not start until the previous phase has finished. In practice, these stages overlap and feed information to each other. During design, problems with requirements are identified, during coding design problems are found and so on. The software process is not a simple linear model but involves a sequence of iterations of the development activities.
• Because of the costs of producing and approving documents, iterations are costly and involve significant rework. Therefore, after a small number of iterations, it is normal to freeze parts of the development, such as the specification, and to continue with the later development stages. Problems are left for later resolution, ignored or are programmed around. This premature freezing of requirements may mean that the system won’t do what the user wants. It may also lead to badly structured systems as design problems are circumvented implementation tricks.
• During the final life-cycle phase (operation and maintenance) the software is put into use. Errors and omissions in the original software requirements are discovered. Program and design errors emerge and the need for new functionality is identified. The system must therefore evolve to remain useful. Making these changes (software maintenance) may involve repeating some or all previous process stages.
• The problem with the waterfall model is its inflexible partitioning of the project into these distinct stages. Commitments must be made at an early stage in the process and this means that it is difficult to respond to changing customer requirements. Therefore, the waterfall model should only be used when the requirements are well understood. However, the waterfall model reflects engineering practice. Consequently, software processes based on this approach are still used for software development, particularly when this is part of a larger systems engineering project.