Software development processes

The waterfall model is an example of a plan-driven process—in principle, you must plan and schedule all of the process activities before starting work on them. As it is seen on the figure, phases are cascaded from one phase to another, that is while it is known as the ‘waterfall model’.

Figure 1.1. Waterfall model

The principal stages of the waterfall model directly reflect the fundamental development activities:

At least in principle, the result (artifact) of each phase is one or more documents that should be approved and the subsequent phase should not be started until the previous phase has completely been finished. In practice, however, these stages overlap and feed information to each other. During design, problems with requirements can be identified, during coding some of the design problems can be found, etc. The software process therefore is not a simple linear model but involves feedback from one phase to another as it is depicted on the figure. Documents produced in each phase may then have to be modified to reflect the changes made.

In principle, the waterfall model should only be applied when requirements are well understood and unlikely to change radically during development as this model has a relatively rigid structure which makes it relatively hard to accomodate change when the process in underway.

An important variant of the waterfall model is formal system development, where the specification is described using a mathematical model which will later be refined into executable code (possibly through a series of other models) using consistency-preserving mathematical transformations. If the mathematical transformations applied are correct, we have a strong argument that a program generated in this way is consistent with its specification.

Incremental development is based on the idea of developing an initial implementation, exposing this to user feedback and evolving it through several versions until an acceptable system has been developed. Activities of specification, development and validation are not separated but interleaved. There are also lots of feedback across those activities.

Incremental software development, which is a fundamental part of agile approaches, is better than a waterfall approach for most business, e-commerce, and personal systems. Incremental development reflects the way that we solve problems. We rarely work out a complete problem solution in advance but move toward a solution in a series of steps, backtracking when we realize that we have made a mistake. By developing the software incrementally, it is cheaper and easier to make changes in the software as it is being developed.

Each system increment captures a piece of the functionality that is needed by the customer. Generally, the early increments of the system should include the most important or most urgently required functionality. If this is the case then customers can evaluate the system at a relatively early stage in the development to see if it delivers what is required. If not, then only the current increment has to be changed and, possibly, new functionality defined for later increments. Compared to the waterfall model, incremental development has three important benefits:

Incremental development in some form is now the most common approach for the development of application systems. This approach can be either plan-driven, agile, or, more usually, a mixture of these approaches. In a plan-driven approach, the system increments are identified in advance; if an agile approach is adopted, only the early increments are identified but the development of later increments depends on progress and customer priorities.

Reuse is one of the most important concepts of today's software engineering since it can not only save a given amount of work when existing components providing a given funtionality are reused but existing components might have lots of testing received so far so we can possibly build more reliable systems based on them. Nowadays more and more software projects apply reuse to some extent, however, some of them relies more on reused components than others.

Reuse often happens in an informal way when people working on the project know of designs or code that are similar to what is required. They look for these, modify them as needed, and incorporate them into their system. This is basically the application of patterns in the development process.

There are basically three types of software components that can be used in a reuse-oriented process:

One of the most important advabtage of reuse-oriented software engineering is the reduced amount of software to be developed and therefore reduced cost and risks. As a consequence, it can also lead to faster delivery. However, compromises must be achieved on requirements which might lead to a system that does not meet the real needs of users. Some control over the system evolution might also be lost as new versions of the reusable components are not under the control of the organization using them (no influence on what functionalities to include/exclude, etc.).

In this section some of the most important activities and sub-activities of the four general process activities will be discussed very briefly. For a more detailed description of activities, the reader should read some general software engineering textbooks like.

The four basic process activities of specification, development, validation, and evolution are organized differently in different development processes. In the waterfall model, they are organized in sequence while in incremental development they are interleaved. How these activities are performed might depend on the type of software, people involved in development, etc.