A method of developing information systems which users prototyping to achieve user involvement and faster development compared to traditional methodologies such as SSADM.
Professor Clifford Kettemborough of Whitehead College, University of Redlands,
defines

Rapid Application Development as an approach to building computer
systems which combines Computer-Assisted Software Engineering (CASE) tools and techniques, user-driven prototyping, and stringent project delivery time limits into a potent, tested, reliable formula for top-notch quality and productivity. RAD drastically raises the quality of finished systems while reducing the time it takes to build them.

Online Knowledge defines

Rapid Application Development as a methodology that
enables organizations to develop strategically important systems faster while reducing
development costs and maintaining quality. This is achieved by using a series of
proven application development techniques, within a well-defined methodology.

History

Rapid application development is a term originally used to describe a software development process introduced by James Martin in 1991. Martin’s methodology involves iterative development and the construction ofprototypes. More recently, the term and its acronym have come to be used in a broader, general sense that encompasses a variety of methods aimed at speeding application development, such as the use of software frameworks of varied types, such as web application frameworks.

RAD vs. Waterfall

In the 1970s and 1980s, several sequential software engineering processes were developed that regarded application development as flowing steadily downward through the different phases of the development process.

The first description of such a waterfall model is often cited in an article published in 1970 by Winston W. Royce². However, in this article, Royce presented the model as an example of a flawed, non-working approach. “Waterfall” has in later years become a common term to criticize traditional software development practices. The problem with most waterfall models is the fact that it relies on a methodical requirements analysis phase alone to identify all critical requirements for the application. There is ample evidence that projects using a waterfall approach often fail to provide a useable end product; because projects often exceed their deadlines, the product either fails to meet all requirements or the requirements change during the protracted development phase.

There have been many responses to this problem from the 1980s to today, but almost all of those responses focus on the idea of developing systems in a short timeframe with small teams of highly skilled and motivated staff. It is the iteration step that solves the problems inherent to the inflexible approach of traditional software development.

Why was needed to invent RAD?

The evidence from project failures for projects in the 1980s and 1990s, as evidenced for example by the Standish Group Chaos report (1995), implies that traditional structured methodologies have a tendency to  deliver systems that arrives too late and therefore no longer meet their original requirements. Traditional methods can fail in a number of ways.

• A gap of understanding between user and developers: Users tend to know less about what is possible and practical from the a technology perspective, while developers may be less aware of the underlying business decision -making issues which lie behind the systems development requirement.
• Tendency of developers to isolate themselves from users: Historically, systems developers have been able to hide behind  a wall of jargon, thus rendering the user community at an immediate disadvantages when discussing IS/IT issues. While some jargon may be necessary if points are to be made succinctly, it is often used to obscure poor progress with a particular development project.  The tendency for isolation is enhanced by physical separation of some computer staff in their air-conditioned computer rooms. Developers might argue in their defence that users also have their own domain-specific jargon which adds to the problem of deciphering requirements.
• Quality measured by closeness of product to specification: This is a fundamental difficultly – the observation that ‘ the system does exactly what the specification said it would so’  hides the fact that the system may still not deliver the information that the users need for decision-making purpose. The real focus should be on a comparison of the deliverables with the requirements, rather than of  deliverables  with a specification that was a reflection of a perceived need at a particular point in time.
• Long development times: SSADM and the waterfall model will reveal that the process of analysis and design can be very laborious and time-consuming. Development times are not helped by the fact that and organization may be facing rapidly changing business conditions and requirements may similarly be changing. There is a real risk of the ‘moving goal-post’  of syndrome causing havoc with a traditional approach to systems development.
• Business needs change during the development process: This is alluded to above. A method is needed where successive iterations in the development process are possible so that the latest requirements can be incorporated.
• What users get isn’t necessarily what the want: The first a user may see of a new information system is at the testing or traning stage. At this point , it will be seen whether the system as delivered by the IS/IT professionals in what the user acually needs. An appropriate analogy here is the purchase of a house or car simply on the basis of discussions with an estate  or a garage agent  rather than by actually visiting the house or driving the car. It is unlikely that something purchased  in this way will result in a satisfied customer and there in no reason to suppose that information systems developed is a similar way will be any more successful.

Not only is there pressure from end-user management for faster systems development, IS/IT department themselves increasingly recognize the need to make more effective use of limited human resources within is their departments while at the same time quickly delivering systems that confer business benefits. All this is is a climate of rapid business change and therefore, rapidly changing information needs. Rapid Application Development (RAD) is a method possible solution to these problems and pressures.

Is RAD  appropriate for all projects?

The Rapid Application Development methodology was developed to respond to the need to deliver systems very fast. The RAD approach is not appropriate to all projects – an air traffic control system based on RAD would not instill much confidence. Project scope, size and circumstances all determine the success of a RAD approach. The following categorize indicates suitability for a RAD approach:

Project Scope
Suitable for RAD – Focused scope where the business objectives are well defined and narrow.
Unsuitable for RAD – Broad scope where the business objectives are obscure or broad.

Project Data
Suitable for RAD – Data for the project already exists (completely or in part). The project largely comprises analysis or reporting of the data.
Unsuitable for RAD – Complex and voluminous data must be analyzed, designed and created within the scope of the project.

Project Decisions
Suitable for RAD – Decisions can be made by a small number of people who are available and preferably co-located.
Unsuitable for RAD – Many people must be involved in the decisions on the project, the decision makers are not available on a timely basis or they are geographically dispersed

Project Team
Suitable for RAD – The project team is small (preferably six people or less).
Unsuitable for RAD – The project team is large or there are multiple teams whose work needs to be coordinated.

Project Technical Architecture
Suitable for RAD – The technical architecture is defined and clear and the key technology components are in place and tested.
Unsuitable for RAD – The technical architecture is unclear and much of the technology will be used for the first time within the project.

Project Technical Requirements
Suitable for RAD – Technical requirements (response times, throughput, database sizes, etc.) are reasonable and well within the capabilities of the technology being used. In fact targeted performance should be less than 70% of the published limits of the technologies.
Unsuitable for RAD – Technical requirements are tight for the equipment to be used.

General Characteristics of Rapid Application Development (RAD)

   Sources

• http://en.wikipedia.org/wiki/Rapid_application_development || Date of access: 18^th November 2011 5:35 AM
• http://www.casemaker.com/download/products/totem/rad_wp.pdf || Date of access: 18^th November 2011 12:05 PM
• http://www.gantthead.com/content/processes/11306.cfm || Date of access: 19^th November 2011 05:26 AM
• Paul Bocij, Andrew Greasley, Simon Hickie, 2008. RAPID AAPLICATION DEVELOPMENT (RAD. In Paul Bocij, Andrew Greasley, Simon Hickie. Business Information Systems. 4th ed. Pearson Education Limitied. Ch. 7. pp.305-06.ISBN-978-0-273-71662-4