BL software 

Rapid Application Development (RAD) techniques enable systems to be developed to the end -user's requirements on time and within budget without a detailed specification. Because of the lack of specification applications developed in this way are generally more suited to completion on day rates than at a fixed price.

The main features of RAD are as follows:

Initial Requirements

Project Plan / Prioritisation

Standard Modules

Reviews and workshops

Reiteration

Testing

Acceptance

Initial Requirements                       Back

Because of the frequent reviews and reiterations during the development of applications using RAD techniques, detailed specifications are unnecessary and in most cases undesirable.

The initial requirements should be a brief description of the functionality required. This can be a series of 'bullet points'.

Project Plan / Prioritisation           Back

Whether the project is time or cost (or both) sensitive it is usually necessary to prioritise the required features, by splitting the application into core functionality and desirable features. The desirable features can then be added in priority order as the remaining time / budget allows.

Standard Modules / Templates     Back

Accelerated development can be achieved by the use of standard modules and templates. These include code, form and report modules. In addition to the 'bolt-on' advantage, standard modules also have the advantage of being fully debugged.

Reviews and workshops              Back

'Early and frequent' is a term often used in relation to RAD reviews. The review should include all interested parties and should take the form of a demonstration of the application, using dummy data if necessary. Reviews should take place whenever a key stage in the application development is reached.

Reiteration                                   Back

Agreed changes to the application as a result of the review / workshop should be incorporated and re-visited at the next review. Reiteration is an important feature of RAD and ensures that the development meets the requirements of all interested parties.

Testing                                       Back

Testing / debugging should be carried out in parallel with development to minimise the amount of rework required as the project progresses. A system of 'buddy' testing can be used on small projects where dedicated testers are not employed.

Acceptance                               Back

Acceptance testing should be carried out using live data (or a copy of the live data), if possible in parallel with whatever application or procedures the new system replaces. Acceptance of systems developed using RAD are generally much more straightforward than conventionally developed applications, because of the frequent reviews / reiterations that take place during the project.