in Figure 4.1. 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:
4.1 • Software process models 67
1. Requirements analysis and definition The system's services, constraints and goals are ,established by consultation with system users. They are then defined in detail and serve as a system specification.
2. System and software design The systems design process partitions the require-ments to either hardware or software systems. It establishes an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships.
3. Implementation and unit testing During this stage, the software design is realised as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.
4. Integration and system testing The individual program units or programs are integrated and tested as a complete system to ensure that the software require-ments have been met. After testing, the software system is delivered to the customer.
5. Operationandmaintenance Normally (although not necessarily) this is the longest life-cycle phase. The system is installed and put into practical use. Mainten-anct: involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the syst,em's services as new requirements are discovered.
In principle, the result of each phase is one or more documents that are approved ('signed off). The following phast: should not start until the previous phase has finished. In practice, these stages overlap and fleed information to each other.
During design, problems with requirt:ments are identified; during coding design prob-lems 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 produdng and approving documents, iterations are costly and involve significant rework. Therefore, after a small number of iterations, it is nonnal 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 programmed around. This premature fret:zing of requirements may mean that the system won't do what the user wants.Itmay also lead to badly structured systems as design problems are circumvented by 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 dis-covered. Program and design erron, 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 previous process stages.
The advantages of the waterfall model are that documentation is produced at each phase and that it fits with other engineering process models. Its major problem is its inflexible partitioning of the proJect into distinct stages. Commitments mustbe made at ,an early stage in the process, which makes it difficult to respond to chang-ing customer requirements.
68 Chapter 4 d Software processes
Figure 4.2 Evolutionary development
Concurrent activities
----.. Initial version
Outline Intermediate
description versions
Final ----.. version
Therefore, the waterfall model should only be used when the requirements are well understood and unlikely to change radically during system development.
However, the waterfall model reflects the type of process model used in other engi-neering projects. Consequently, software processes based on this approach are still used for software development, particularly when the software project is part of a larger systems engineering project.
4.1.2
Evolutionary development
Evolutionary development is based on the idea of developing an initial implemen-tation, exposing this to user comment and refining it through many versions until an adequate system has been developed (Figure 4.2). Specification, development and validation activities are interleaved rather than separate, with rapid feedback across activities.
There are two fundamental types of evolutionary development:
I. Exploratory developmentwhere the objective of the process is to work with the customer to explore their requirements and deliver a fmal system. The devel-opment starts with the parts of the system that are understood. The system evolves by adding new features proposed by the customer.
2. Throwaway prototyping where the objective of the evolutionary development process is to understand the customer's requirements and hence develop a bet-ter requirements definition for the system. The prototype concentrates on experimenting with the customer requirements that are poorly understood.
An evolutionary approach to software development is often more effective than the waterfall approach in producing systems that meet the immediate needs of cus-tomers. The advantage of a software process that is based on an evolutionary approach
4.1 • Software process models 69
is that the specification can be devdoped incrementally. As users develop a better understanding of their problem, this can be reflected in the software system.
However, from an engineering and management perspective, the evolutionary approach has two problems:
1. The process is not visible Managers need regular deliverables to measure progress. Ifsystems are developed quickly, it is not cost-effective to produce documents that reflect every vt:rsion of the system.
2. Systems are often poorly structuredContinual,;;hange tends to corrupt the soft-ware structure. Incorporating softsoft-ware changes becomes increasingly difficult and costly.
For small and medium-sized systems (up to 500,000 lines of code), I think that the evoliltionary approach is the bt:st approach to development. The problems of evolutionary development become particularly acute for large, complex, long-life-time sys'cems, where different teams develop different parts of the system.Itis dif-ficult to establish a stable system architecture using this approach, which makes it hard to integrate contributions from the teams.
For large systems, I recommend a mixed process that incorporates the best fea-tures of the waterfall and the evolutionary development models. This may involve developing a throwaway prototype using an evolutionary approach to resolve uncertainties in the system specification. You can then reimplement the system using a more structured approach. Parts of the system that are well understood can be specified and developed using a waterfall-based process. Other parts of the system, such as the user interface, which are difficult to specify in advance, should always be developed using an exploratory programming approach.
Evolutionary development processes and process support are covered in more detail in Chapter 17, along with system prototyping and agile software development.
Evolutionary development is also incorporated in the Rational Unified Process that I discuss later in this chapter.