Rapid Application Development (RAD)

1. WHAT IS RAD
Rapid Application Development (RAD) is a software development methodology that focuses on
building applications in a very short amount of time using Prototypes, Iterative Customization,
and CASE Tools. Using RAD software requires minimum planning, designed and developed (i.e.
within 60-90 days for rapid prototyping with compromises in usability, features and/or execution
speed.

2. HISTORY
Rapid Application Development has been in existence for nearly 20 years, but is as valid today as
it was when it was initially conceptualized.

3. THE PROBLEM
Processes developed in the 1970's, such as the Waterfall development methodology, often resulted
in the development of applications that did not meet client needs because applications took so
long to build that requirements had changed before the system was complete. Thus, for larger
projects, these methodologies frequently resulted in complete, but unusable, systems.

The cause of the problem was identified in the strict adherence to completion of one lifecycle
stage before moving on to the next lifecycle stage. Specifically, building an application based on
requirements that have been frozen at a point in time means that the longer development takes,
the more likely that business needs will change and invalidate the requirements that the system
being developed is based upon.

4. THE RAD SOLUTION

There have been many responses to this problem from the 1980's through today.

In 1986 Barry Boehm wrote A Spiral Model of Software Development and Enhancement, which initially
defined the concepts of prototyping and iterative development and had a focus on risk reduction.

During the late 1980's Scott Shultz and James Martin refined the ideas of prototyping and iterative
development into a methodology called Rapid Iterative Production Prototyping (RIPP) that
focused on developing systems in a short timeframe with small teams of highly qualified,
motivated, and experienced staff.

James Martin (who is frequently called "the Guru of the Information Age") further expanded and
formalized Rapid Iterative Production Prototyping and in 1991 published the book Rapid
Application Development.

5. ADVANTAGES
a. Increased Speed - RAD facilitates organizations in development of software applications faster
and decreased time to delivery.

The goal of delivering applications quickly is addressed through the use of Computer Aided
Software Engineering or CASE tools, which focus on converting requirements to code as
1
 quickly as possible, as well as Time Boxing, in which features are pushed out to future releases
in order to complete a feature light version quickly.
b. Reduced Time - RAD has short development time against traditional development
methodologies or structured development methodologies
c. Reduced Cost - It also helps reduce development cost
d. Increased Quality - It increases quality of software.
In Traditional approach, quality in development was both the degree to which an application
conforms to specifications and a lack of defects once the application is delivered.
In RAD, quality is defined as both the degree to which a delivered application meets the
needs of users as well as the degree to which a delivered system has low maintenance costs.
RAD deliver on quality through the heavy involving of users in the analysis and particularly
the design stages.

6. DISADVANTAGES
(a) Reduced Scalability - Because RAD focuses on development of a prototype that is iteratively
developed into a full system, the delivered solution may lack the scalability (i.e. this denotes
the capability of the system to handle a growing amount of work or its potential to be
enlarged in order to accommodate that growth) of a solution that was designed as a full
application from the start.
(b) Reduced Features - Due to time boxing, where features are pushed off to later versions in
favor of delivering an application in a short time frame, RAD may produce applications that
are less full featured than traditionally developed applications. This concern should be
addressed as soon as possible through clear communication with the client as to what will be
delivered and when.

7. Appropriate RAD Projects

Rapid Application Development is not appropriate for all projects. The methodology works best
for projects where:
 Project Scope is small or work can be broken down into manageable chunks.
 Project team size is small, preferably two to six people, and the team must have experience
with all technologies that are to be used.
 Business objectives are Well-Defined- before the project can begin. So projects that use RAD
should not have a broad or poorly defined scope.
 Decisions can be made Quickly - In order to keep the project within a short time frame,
decisions must be able to be made quickly, so it is imperative that there be very few client
decision makers, preferably only one, and they must be clearly identified up front.
 Team agree to a RAD approach - Client decision makers need to understand and agree to a
RAD approach
 General Client accept a product that is less full featured - ideally Clients should be willing to
accept a product that is less full featured and/or be willing to accept higher development cost
(due to the emphasis on purchasing reusable components over building them) in exchange for
increases in speed.

8. Core Elements of Rapid Application Development

2
RAD has many core elements that make it a unique methodology including prototyping, iterative
development, time boxing, team members, management approach, and RAD tools.

(a) Prototyping
A key aspect of RAD is the construction of a prototype for the purpose of jumpstarting design
and flushing out user requirements. The objective is to build a feature light version of the finished
product in as short an amount of time as possible, preferably days. The initial prototype serves as a
proof of concept for the client, but more importantly serves as a talking point and tool for refining
requirements.

Developing prototypes quickly is accomplished with Computer Aided Software Engineering

CASE tools that focus on:

Capturing requirements → data model → database → and generating code

(→ denotes ‘converting them to a’)

NOTE: CASE tools were popular in the late 80's and early 90's, but as technology has changed
(and COBOL has become obsolete) few tools take full advantage of the full potential of CASE tool
technology.

(b) Iterative Development of Functional Versions

Iterative development means creating increasingly functional versions of a system in short
development cycles. Each version is reviewed with the client to produce requirements that feed the
next version. The process is repeated until all functionality has been developed. The ideal length of
iterations is between one day (which is closer to Agile Methodologies) and three weeks.
Each development cycle provides the user an opportunity to provide feedback, refine
requirements, and view progress (in focus group session meetings).

(c) Time Boxing

Time boxing is the process of putting off features to future application versions in order to
complete the current version in as short amount of time as possible. Strict time boxing is an
important aspect of RAD, because without it scope creep can threaten to lengthen development
iterations, thus limiting client feedback, minimizing the benefits of iterative development, and
potentially reverting the process back to a waterfall methodology approach.

(d) Small Team Members (must include Client)

The RAD methodology recommends the use of small teams that consist of experienced, versatile,
and motivated members that are able to perform multiple roles. As the client plays a vital role in
the development process, dedicated client resources must be available during the initial Joint
Application Development (JAD) sessions as well as Focus Group Sessions conducted at the end of
development cycles.

(e) Active and Involved Management Approach

Active and involved management is vital to mitigate the risks of lengthened development cycles,
client misunderstandings, and missed deadlines. Above all management must be stalwart and
consistent in their desire to use the Rapid Application Development methodology.
3
In addition to enforcing a strict timeline, management must focus on team member selection, team
motivation, and on clearing bureaucratic or political obstacles.

(f) RAD Tools

One of the primary objectives of the Rapid Application Development methodology developed by
James Martin in the late 1980's was to take advantage of the latest technology available to speed
development. Clearly the technology of the 1980's is obsolete today, but RAD's focus of the latest
tools is as important today as it was when the methodology was initially created.

9. LIFECYCLE STAGES of RAD

RAD consists of the following four phases and typical pre and post project activities:
(i) Requirements Planning Phase (by Analysis Team)
(ii) User Design Phase (by Analysis Team)
(iii) Construction phase (Development Team (also known as the SWAT or Skilled Workers with
Advanced Tools team)
(iv) Cutover phases

Pre-Project Requirements Planning Activities

(Focus on the Project Management Plan (PMP))
All parties should agree on:
 potential risks and mitigation strategies,
 a development schedule including resources, milestones and deliverables such as a
completed data model
 types of documentation to deliver
 an approach including standards, tools, and technologies to be used,
 a desired end result,
 terms and constraints and financial considerations including budget and cost of tools.

(i) Requirements Planning (also known as the Concept Definition Stage

The Requirements Planning stage) consists of meetings between a requirements planning team
and key client users. Meetings focus on both developing a high level list of initial requirements
as well as setting the project scope.
The requirements planning team identifies primary business functions (such as "sell widgets to the
Acme corporation") and initially breaks them down into business entities (such as Product, Sale,
Company, Sales Person).
OUTPUT –
 List of entities, processes and data elements
 Action diagrams that define the interactions between processes and data elements
 Project estimation is considered which should take between one and four weeks.

(ii) User Design Phase (also known as the Functional Design Stage) (B/W 3 and 5 weeks)
During the User Design stage the analysis team meets with end users in Joint Application
Development (JAD) Workshops. During the workshops the analysis team
 flushes out the requirements in more detail,

4
  develops the entities developed in the Requirements Planning into a data model (Entity
Relationship Diagram),
 formalizes business rules,
 develops test plans,
 creates screen flows and layouts for essential parts of the system.

During the later half of this stage, the development team (also known as the SWAT or Skilled
Workers with Advanced Tools team) aids the analysis team in activities such as:
 creating a working data model that can be converted to a functional database,
 identifying reusable components (such as Microsoft's Application Blocks, which,
incidentally, are an excellent time saver on Microsoft .Net projects).

Pre-Project Construction Stage Activities

 The Analysis Team flushes out the project plan and focus on effort estimates.
 core requirements are identified and targeted for the initial prototype,
 secondary requirements are identified and targeted for future development iterations.

(iii) Construction Phase (/w between 1 day and 3 weeks)

During the Construction Phase the Design Team develops the application in iterative cycles of
development, testing, requirements refining, and development again, until the application is
complete.
The development team should convert the Data Model that was developed during the User Design
Stage into a functional database (all data modeling tools have this ability). The CASE tool used
(which may be the same as the data modeler or a separate tool) should now generate large sections
of the application, at a minimum data access code, but preferably business functions and user
interface as well.
At Automated Architecture, our Blue Ink product will read information from database that has
been generated, pre-generate answers to meta-data about the project (in other words make a best
guess as to the details of your application that you may then customize in more detail later), and
generate an entire application that can serve as a working prototype without a line of development
code. A prototype developed in this way may reduce the first iteration of development to days
instead of weeks.

It is vital to keep each development iteration on track, and functionality may need to be dropped
to keep development within the time box. Management plays a vital part in ensuring everything is
progressing according to schedule, keeping the customer in the loop regarding changes in the
functionality, and keeping the team motivated.
Once the prototype has been developed (within its time box), the construction team tests the initial
prototype using test scripts
developed during the User Design stage, the design team reviews the application, the customer
reviews the application and finally the
construction team, design team, and customer meet in Focus Group meetings in order to
determine the requirements for the next iteration. Focus group meetings consist of facilitated
sessions that last about two hours. The facilitator should know ahead of time the areas that require

5
discussion and should ensure that each issue receives enough attention, keeping a list of issues
that require additional attention in a separate meeting as appropriate.
After the meeting (additional meetings may be necessary), the development team and design team
should update the requirements, data model, test scripts, and project plan as during the User
Design stage. Again the teams should identify core and secondary requirements, plan out the next
development iteration, keep the user in the loop regarding what will be done, and then start the
next iteration of development over again. As the system approaches a sufficient state the
development team should focus on the system as a finished application rather than a prototype.
During the final iterations of development the design team should update user documentation,
perform User Acceptance Testing and define the steps necessary for deployment/implementation.
Implementation
The Implementation Stage (also known as the Deployment Stage) consists of integrating the new
system into the business. The Development Team prepares data (such as lookup values like States
and Countries) and implements interfaces to other systems. The Design Team trains the system
users while the users perform acceptance testing. and are trained by the Design Team. The Design
Team helps the users transfer from their old procedures to new ones that involve the new system,
trouble shoots after the deployment, and identifies and tracks potential enhancements (read wish
list). The amount of time required to complete the Implementation Stage varies with the project.

Post-Project Activities
 Project Manager review and document project metrics
 organize and store project assets such as reusable code components, Project Plan, Project
Management Plan (PMP), and Test Plan.
 Prepare a short lessons learned document.

Development Environments
The following tools support Rapid Application Development:
 Microsoft Visual Studio.NET 2003,
 Sun Java Studio Creator,
 BEA Web Logic Workshop 8.1,
 Borland C# Builder,
 IBM WebSphere Studio Application Developer 5.1.2.

Requirements Gathering Tools

All stages of the RAD Methodology, particularly the requirements planning stage, specify that
requirements should be captured in a tool rather than an unstructured document. For this reason,
tools that support writing in the Unified Modeling Language (UML) support RAD. There are
numerous tools that support UML notation: Microsoft Visio and IBM's Rational Rose as mentioned
in the Requirements Planning are two of the most popular, while Enterprise Architect 5.0 by Sparx
Systems is another leading UML tool. For more information about UML, which was created by the
Object Management Group (OMG), see the Introduction To OMG's Unified Modeling Language™
(UML®) on their website.

Data Modeling Tools

6
If requirements gathering tools are import for RAD, Data Modeling Tools are vital. Modifying a
database manually with SQL statements or through an IDE goes against RAD because data
modelers capture requirements and speed development by generating the database. Not using data
modeling on even the smallest project is just a terrible idea. Often tools that support requirements
gathering and UML also contain a data modeling tool and everything links together. The
Introduction to Data Modeling site is a detailed practical guide maintained by the University of
Texas at Austin's Information Technology Services. The next most popular after the Microsoft and
IBM tools is probably ERwin by Computer Associates.