Rapid-application development (RAD)

Rapid-application development (RAD) is both a general term, used to refer to adaptive software development approaches, as well as the name for James Martin’s approach to rapid development. In general, RAD approaches to software development put less emphasis on planning and more emphasis on an adaptive process. Prototypes are often used in addition to or sometimes even in place of design specifications.

RAD is especially well suited for (although not limited to) developing software that is driven by user interface requirements. Graphical user interface builders are often called rapid application development tools. Other approaches to rapid development include the adaptive, agile, spiral, and unified models.

In software development, RAD (rapid application development) is a concept that was born out of frustration with the waterfall software design approach which too often resulted in products that were out of date or inefficient by the time they were actually released. The term was inspired by James Martin, who worked with colleagues to develop a new method called Rapid Iterative Production Prototyping (RIPP). In 1991, this approach became the premise of the book Rapid Application Development.

A Few RADical Steps

Getting started with rapid application development generally follows a cyclical process that includes four basic steps:

  1. Planning Requirements: During this initial stage designers, developers, and users come to a rough agreement on project scope and application requirements, so that future stages with prototyping can begin.
  2. User Design: User feedback is gathered with heavy emphasis on determining the system architecture. This allows initial modeling and prototypes to be created. This step is repeated as often as necessary as the project evolves.
  3. Rapid Construction: Once basic user and system design has begun, the construction phase is where most of the actual application coding, testing, and integration takes place. Along with User Design, the Rapid Construction phase is repeated as often as necessary, as new components are required or alterations are made to meet the needs of the project.
  4. Cutover: The final Cutover (or Transition) stage allows the development team time to move components to a live production environment, where any necessary full-scale testing or team training can take place.

RAD Model Vs Traditional SDLC

The traditional SDLC follows a rigid process models with high emphasis on requirement analysis and gathering before the coding starts. It puts pressure on the customer to sign off the requirements before the project starts and the customer doesn’t get the feel of the product as there is no working build available for a long time.

The customer may need some changes after he gets to see the software. However, the change process is quite rigid and it may not be feasible to incorporate major changes in the product in the traditional SDLC.

The RAD model focuses on iterative and incremental delivery of working models to the customer. This results in rapid delivery to the customer and customer involvement during the complete development cycle of product reducing the risk of non-conformance with the actual user requirements.

When should your team use RAD?

Unfortunately, James Martin didn’t solve the mystery of application development when he came up with the RAD framework. RAD doesn’t work for every project and, like any organizational methodology, shouldn’t be used indiscriminately. But it does work well in a few specific instances, which we’ll discuss below.

It’s all in the name here. If you’re working on a tight deadline, you should consider using RAD, as you’ll produce a working system more quickly than with more traditional methods such as Waterfall. At the very least, you can produce functioning parts of systems that might be “good enough for now” solutions for clients who needed software yesterday.

Since user feedback is one of the advantages of using RAD, you can’t skip out on that step in the process. RAD depends on constant improvements suggested by users, so you’ll need to make sure they’ll be available to collaborate with your development team throughout the process.

Providing users for testing might be part of negotiating your timeline and budget with your client. The good thing is, since you’re getting your project done quickly, users theoretically won’t need to clear much time in their schedules to test your software iterations.

It should come as no surprise that creating a high-quality application quickly requires skill and precision. That means hiring talented designers and engineers. And that means paying them their deserved higher salaries. If you skip out on hiring a skilled team, you might find that you get what you pay for, as work done hastily but shoddily isn’t likely to meet your clients’ expectations.


Leave a Reply