2 Software development processes

With reference to Rogers’ definition, a software development process is the practice of organising the design and construction of software and its deployment in context.

Effective software development processes remain the holy grail of software development and over the years many contenders have emerged and then gone out of fashion. These vary in the detail of what activities they prescribe, their related artefacts, how the activities should be carried out in relation to one another, and how often each activity should be revisited. There are, however, some fundamental development activities that are well understood and common to most approaches. In very broad terms:

• Analysis involves understanding the problem which the software is intended to solve, i.e., the requirements in context, with validation as the means to check that understanding.
• Design involves describing, conceptually, a software solution that meets the requirements of the problem.
• Implementation involves realising such a solution in software.
• Testing involves making sure that the solution has certain inherent qualities, with verification as a means to check its adequacy with respect to the specified requirements and validation as a means to check that the solution does address the problem.
• Deployment involves making the developed solution available in its context of operation and use.

While this course will focus primarily on software development activities, it is important to remember that the process does not end with a deployed product. The full software life-cycle also includes:

• maintenance: makes sure that the deployed solution continues to address the problem throughout the time it is in operation, and handles its decommissioning at the end of the life-cycle.

In completing Activity 3 you may have encountered some of the following.

The waterfall development process model (or simply, waterfall model; Royce,1970; Benington, 1983) was inspired by manufacturing processes. Historically, this was the earliest software development process to be widely recognised and applied. It relies on the definition of sequential phases of analysis, design, implementation and testing, each starting only after the previous one has finished; in its purest form, all the analysis is done first, followed by all the design, then the implementation, and finally the testing. The waterfall process has been widely used and has yielded many successful software products, and variants of it (e.g. the V-model; see Forsberg and Mooz, 1992) are still in use in some industries, particularly in highly regulated sectors. However, the waterfall process is based on several assumptions that have been questioned. For example, it relies on the existence of a set of requirements that is defined beforehand and remains unchanged during development; it also assumes that all code is designed from scratch, making no allowance for the reuse of existing software. Because the development is carried out as a linear process, the waterfall process does not allow previous phases of the development to be repeated without repeating the whole sequence of steps.

Iterative and incremental processes emerged as a reaction to the recognised limitations of the waterfall process, particularly the latter’s rigidity in the face of change and its lack of support for reuse. With iterative and incremental processes there is still a need for analysis, design, implementation and testing activities, but these activities are carried out in a more flexible way than in the waterfall process. Many iterative and incremental processes exist – for example, the spiral model (Boehm, 1988) or the Unified Process (Jacobson et al., 1999) – and all share some basic features: they are ‘iterative’ in the sense that one or more activities are repeated; and they are ‘incremental’ in the sense that software development proceeds from an initial subset of the requirements to more and more complete subsets, until the whole system is addressed. Hence, an iterative and incremental process consists of several cycles of analysis, design, implementation and testing, each providing feedback for the next cycle, in which evermore refined and enhanced levels of development are achieved.

A popular family of iterative and incremental processes emerged at the start of this century, covered by the umbrella term of Agile development (Cockburn and Highsmith, 2001; Fowler and Highsmith, 2001). These processes encourage continual realignment of development goals with the needs and expectations of the customer, and provide ‘lighter-weight’, faster and ‘nimbler’ software development processes that can adapt to the inevitable changes in customer requirements. Hence, such processes promote frequent, small, incremental cycles of analysis, design, implementation and testing. Also, working code is valued above other types of artefact, such as models or other documentation. Extreme Programming (XP) (Beck, 2000) and Scrum (Schwaber and Beedle, 2001) are two well-known Agile development approaches.

Within the same timescale of Agile development, model-driven-development (Selic, 2003) also arose. This approach sees models and not code as the key artefacts in software development. According to this approach, models allow the developer to work at a much higher level of abstraction than code, and hence be closer to the business and its processes; also, models are platform-independent and hence decoupled from specific technology. Well defined syntax (how models should be defined) and semantics (how they should be interpreted) allow code to be derived from models through transformations and a suite of automated tools are being developed to support the approach. With model-driven development, the boundary between analysis and design becomes blurred, with development progressing seamlessly through transformed models.