Rapid Application Development: Methodology, Concepts & E-Commerce

Introduction: RAD Definitions

Information technology has become an increasingly common presence across most domains of life. The business sector uses it for various purposes, such as increasing shareholder value, improving customer satisfaction, consolidating market position, and registering higher profits. A relevant strategy used to meet these goals is RAD, or Rapid Application Development, which is most commonly used within web-based applications destined for online commerce. This paper begins with a short presentation of the methodology and the concepts involved, examines its application in e-commerce, and concludes with an overview of RAD's advantages and limitations.

The introduction of Rapid Application Development (RAD) in the early 1990s—James Martin, in 1991, is generally credited as the scientist who introduced it—marked an essential phase in software development history. RAD increased the speed with which applications were developed while also improving their capacity to better fit customers' requirements. Additionally, the development process could be changed and adapted along the way, which made for a very flexible development structure.

The RAD methodology is generally defined as "a software development process that allows usable systems to be built in as little as 60–90 days, often with some compromises." The RAD methodology is based on three essential elements:

Prototyping relies on the creation of deliverable prototypes of the final product, which can then be gradually refined as feedback from customers and end users is obtained.

Iteration implies continuous improvement and development based on the refinement of previously obtained prototypes.

Timeboxing is the applied managerial technique that coordinates the previous two elements and ensures that the final product is delivered on time and to the required standards.

RAD vs. Structured Systems Analysis and Design Method

Prior to Rapid Application Development, the software development industry had been dominated by non-agile processes, including the Structured Systems Analysis and Design Method (SSADM) and several Waterfall models. The SSADM was a static development framework based on logical data modelling or data flow modelling.

The SSADM also included several strictly determined development stages: analysis of the current system prior to actual development (known as the feasibility stage), a descriptive outline of the business specifications, followed by a detailed business specification process, a logical system specification stage, and the physical design of the final product.

The SSADM methodology was part of a larger software development framework referred to as Waterfall models, mainly because one stage preceded the next and each subsequent stage was dependent on the outcome of the previous one. No secondary stage could be completed until the previous primary stage was fully finished. There was a strict dependency between all development stages in the software product's lifecycle. The concept of sequential development is central to Waterfall models and all frameworks based on this concept.

The main problem that Waterfall models introduced was that clients' feedback could generally not be incorporated into the final product until it reached the last stages of development. By that time, several complications could arise: (1) the client's specifications may have changed, especially if development took a long period of time, or (2) the client's input would have implied significant changes, which in turn increased financial and human resource costs.

The agile software development methodology emerged in an attempt to solve these problems. With a higher degree of open collaboration and greater flexibility and adaptability, the agile approach encouraged communication both within the development team and with the customer. This meant that requirements could be better matched to the product, and the final deliverable—shaped by changes made along the way—more accurately reflected the customer's needs. Rapid Application Development fit precisely within this methodological framework.

Basic Concepts of RAD

As its name clearly implies, Rapid Application Development aims to increase the speed with which software programs are developed. "RAD projects have fast delivery of finished work as a primary goal." The author of Rapid Application Development with Mozilla identified five major concepts related to RAD: less time with the same effect, visual prototypes, vertical solutions, COTS software versus home-grown software, and destructured testing.

Less Time with the Same Effect

This RAD concept emphasizes that the most adequate solution to a problem is often the quickest solution. The idea is reinforced by the increased flexibility of rapid application development, meaning that projects can be improved over time and the primary requirement is simply for a project to work. "This is an essential characteristic of RAD projects—there is no allegiance to any rigid rules. Whatever does the job fastest, wins. Even if the technique you chose isn't that beautiful, isn't that sophisticated, and maybe isn't even flexible, the fact that it gets the job done is essential." As such, the effect will be the same regardless of the methodology chosen, and applications will work. In the case of RAD, however, the work will be completed in less time, generating multiple positive effects such as reduced costs with resource allocation and increased customer satisfaction.

Visual Prototypes

McFarlane explains the visual prototypes characteristic with an analogy between software applications and human interaction. He states that it takes considerable time for a software engineer to become accustomed to the interface of an application, and only after that accommodation occurs will the engineer be able to program effectively. In the case of RAD methodologies, the user is able to configure the interface multiple times in order to reach maximum comfort. The visual prototypes characteristic therefore enhances the flexibility of the applications and methodologies used, increasing the satisfaction and creativity of software engineers.

This characteristic is not only beneficial for developers, but also for the final client, who can request a user-friendly interface generally adapted to their unique characteristics and requirements. "The use of videos, story boards, and prototypes demands that the final software has smooth functionality and an easy-to-use interface." In other words, the visual feature of rapid application development not only eases the work of programmers but also increases the satisfaction felt by end consumers.

Vertical Solutions

The characteristic of vertical solutions means that RAD projects are "used to build products that have a narrow purpose, whether it be a museum catalogue or a stock analysis package. Those products are so-called vertical solutions. There is usually no need to make the product so flexible it can be applied to other uses. That can be a later goal if the product works as it is." In other words, RAD projects are developed with a specific task and to meet a clearly established goal. Over time, they can be further developed vertically to meet the same or highly similar goals, but they will not diverge significantly from the initial objective. For instance, a stock analysis program for a local market could later be enhanced to analyze the national stock market, but would never need to support the database management of a museum.

COTS Software vs. Home Grown

A basic analysis of commercial off-the-shelf (COTS) and home-grown applications reveals several advantages and limitations of each type. Commercial off-the-shelf projects are easily procured and imply reduced financial resources; however, since they are developed by third parties, they offer limited customization and the buyer has limited control over future developments. Home-grown projects are more costly in both time and financial resources, but benefit from full adaptation to the needs of the organization and its customers, along with extensive control over future developments.

Destructured Testing

The ability to conduct destructured testing is demonstrated by software engineers' capability to break a project down into various smaller components, analyze and test them individually, and retrieve the desired results. This ability is largely enabled by the flexibility of RAD projects. Since the primary goal of RAD projects is simply to function, the attention placed on formal testing is reduced. A special compiler has been developed to handle much of this work automatically, requiring minimal assistance from software engineers.