RAD

Rapid application development (RAD) is a family of software development approaches that emphasize speed and adaptability over the plan-driven, sequential working of the waterfall model. Where plan-driven methods attempt to fix requirements and design before construction begins, RAD treats software development as a knowledge-intensive activity and uses prototyping and continuous user involvement to discover and refine requirements during the project itself.

The term carries two related senses. As a general label it describes any adaptive, prototype-led approach to building software, of which Barry Boehm’s spiral model was the earliest formal example. As a specific method it refers to the four-phase process formalized by James Martin at IBM during the 1980s and published in his 1991 book Rapid Application Development. The two senses are often conflated, even among practitioners, and it is worth distinguishing them when reading the literature.

Origins

RAD emerged in the 1970s and 1980s as a reaction to heavyweight, plan-driven methods such as the Structured Systems Analysis and Design Method (SSADM), which adapted the engineering model used for bridges and buildings to software. Software, however, can change the process used to solve a problem, and knowledge gained during development can feed back into requirements and design. Plan-driven methods resisted that feedback. RAD embraced it.

Boehm’s spiral model, published in 1988, was the first formal RAD-style approach. It framed each iteration as a cycle of risk reduction, using prototypes to test the most difficult parts of a system early, when problems are cheapest to fix. Martin built on this work and on the practice of computer-aided software engineering (CASE) to codify a method tailored to knowledge- and UI-intensive business systems.

The Martin method

Martin’s RAD divides a project into four phases.

  • Requirements planning. Users, managers, and IT staff agree on business needs, scope, constraints, and system requirements. The phase ends when the team has consensus and management authorization to proceed.
  • User design. Users and analysts work together to build models and prototypes that represent every process, input, and output. Joint application design workshops and CASE tools translate user needs into a working model that users can understand, modify, and approve.
  • Construction. Programmers build the system while users continue to react to working screens and reports. Coding, integration, and system testing happen here, but user feedback still shapes the result.
  • Cutover. The new system is delivered. Data is converted, final tests run, the system is cut over, and users are trained. Compared with traditional methods the whole sequence is compressed, so the system ships sooner.

Strengths and weaknesses

RAD’s strengths are the ones the spiral model introduced. Prototypes surface the hardest parts of a system early, when risk is cheapest to retire. Users react to a running system far more usefully than to an abstract specification, so the software that emerges tends to fit the real business problem. And because work proceeds in increments rather than one long pass, the project is less likely to discover, six months in, that the whole design must be rethought.

The weaknesses are the mirror of those strengths. RAD demands sustained time from the very domain experts whose time is scarcest, and projects fail without that commitment. The flexibility that lets a team adapt quickly also means less control, which makes RAD a poor fit for safety-critical systems where control matters more than agility. The emphasis on visible, working software tends to crowd out non-functional requirements – security, portability, scalability – whose absence is not obvious to end users in normal operation. And the prototype-led style can degenerate into "hack and test", in which minor changes accumulate without attention to overall architecture. RAD is also hard to scale beyond small and medium-sized teams.

Legacy

RAD’s emphasis on iterative cycles, prototypes, and continuous user involvement fed directly into the agile software development movement of the late 1990s and early 2000s. DSDM was created specifically to bring discipline to RAD, and the broader iterative and incremental development tradition that RAD joined is the foundation on which the agile methods were built. In modern practice RAD is rarely named as a method, but its assumptions – that working software is the primary measure of progress and that requirements are best discovered by building – survive in nearly every contemporary delivery process.

See also

References

  • Boehm, Barry W. (1988). A Spiral Model of Software Development and Enhancement. IEEE Computer, 21(5), pp. 61–72.
  • Kerr, James M.; Hunter, Richard (1993). Inside RAD: How to Build a Fully Functional System in 90 Days or Less. McGraw-Hill.
  • Martin, James (1991). Rapid Application Development. Macmillan.