Rapid application development

It might be thought that users would generally welcome the more professional approach that structured methods imply. However, customers of IS/IT are concerned with getting working business applications delivered quickly and at less cost and often see structured methods as unnecessarily bureaucratic and slow. A response to this has been rapid application development (RAD).

The RAD approach does not preclude the use of some elements of structured methods such as Logical Data Structure diagrams but also adopts tactics such as joint application development (JAD) workshops. In these workshops, developers and users work together intensively for, say, three to five days and identify and agree fully documented business requirements. Often, these workshops are conducted away from the normal business and development environments in clean rooms, that is, special conference rooms free from outside interruption and suitably furnished with white boards and other aids to communication. This is based on the belief that communication and negotiation that might take several weeks or months via a conventional approach of formal reports and proposals and counter-proposals can be speeded up in these hothouse conditions.

4.7 The waterfall model

Another practice associated with RAD is time-boxing where the scope of a project is rigidly constrained by a pre-agreed and relatively close absolute deadline. Requirements that have to be omitted in order to meet this deadline are considered in later time-boxes.

Some of these ideas will be considered further in our later discussions on prototyping and the incremental approach.

4.7 The waterfall model

This is the 'classical' model of system development. An alternative name for this model is the one-shot approach. As can be seen from the example in Figure 4.2, there is a sequence of activities working from top to bottom. The diagram shows some arrows pointing upwards and backwards. This indicates that a later stage might reveal the need for some extra work at an earlier stage, but this should definitely be the exception rather the rule. After all, the flow of a waterfall should be downwards with the possibility of just a little splashing back. The limited scope for iteration is in fact one of the strengths of this process model. With a large project you want to avoid having to go back and rework tasks that you thought had been completed. For a start, having to reopen what was previously thought to be a completed activity plays havoc with promised completion dates.

The first description of this approach is said to be that of H. D. Bennington in 'Production of Large Computer Programs' in 1956. This was reprinted in 1983 in Annals of the History of Computing 5(4).

Figure 4.2 The waterfall model.

We contend that there is nothing intrinsically wrong with the waterfall approach, even though more recent writers have suggested different models. It is the ideal that the project manager strives for. The waterfall approach allows project completion times to be forecast with more confidence than is the case with some more iterative approaches and this allows projects to be controlled effectively. However, where there is uncertainty about how a system is to be implemented, and unfortunately there very often is, a more flexible, iterative, approach may be required.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment