RAD, Rapid Application Development

Rapid Application
Mahir Anwar
 Introduction
 Explanation
 History
 Example
 To RAD or NOT to RAD
 Similarities and Differences with ICSM
 Relevance to 577 ab
 Companies using RAD
 Conclusion
 “Even the best planning is not so omniscient as to get it right
the first time.”
-- Fred Brooks
 “In software, we rarely have meaningful requirements. Even
if we do, the only measure of success that matters is whether
our solution solves the customer’s shifting idea of what their
problem is.”
-- Jeff Atwood
 Rapid Application Process (RAD) is a Software
Development Methodology that uses
- Minimal Planning
- Rapid Prototyping
- Iterative and Incremental Process
 Rapid Application Development was introduced by James Martin
 It was developed as a response to non-agile processes, such as
Structured Systems Analysis and Design Method and the Waterfall
 RAD was inspired by the following process models:
- Barry Boehm (spiral model)
- Tom Gilb (evolutionary life cycle)
- Scott Shultz (RIPP, rapid iterative productive prototyping)
 One major problem with the previously used
methodologies was that the application took a long
time to build
 The requirements often changed before the system was
complete, resulting in inadequate or even unusable
 Another problem was the assumption that a
methodical requirements analysis phase alone would
identify all the critical requirements
An Example
 We consider an example of the loans department in a
An Example
Analyze the business process and workflow of the loans department
Split this into individual smaller components
Obtain the business process and workflow for these smaller components
Start prototyping (reusing the code if present) and using CASE tools
Show the prototype to the client and confirm feasibility
Do this for all the individual components and make the changes required
Finally integrate all the individual components and start integration testing
Can have multiple teams working on different components at the same time
To RAD or Not to RAD ?
When to RAD ?
To converge early toward a design acceptable to the customer and feasible for the
To limit a project's exposure to the forces of change
To save development time, possibly at the expense of economy or product quality
When we have a focused scope where the business objectives are well defined and
Data for the project already exists (completely or in part). The project largely
comprises analysis or reporting of the data
The technical architecture is defined and clear and the key technology components
are in place and tested. We know the right CASE tools to be used
Technical requirements (response times, throughput, database sizes, etc.) are
reasonable and well within the capabilities of the technology being used.
When Not to RAD ?
 The technical architecture is unclear and much of the
technology will be used for the first time within the project.
 Complex and voluminous data must be analyzed, designed
and created within the scope of the project.
 Broad scope where the business objectives are obscure or
 Client is busy and cannot give to much time to the
 Large teams with more than 8 members
Similarities to ICSM
 RAD was conceived by looking into Barry Boehm’s Incremental
Commitment Model, where he introduced prototyping to reduce
 The prototyping and spiral development is seen in both the
 The client’s feedback is considered before moving onto the next
spiral (ARB in ICSM and working prototype in RAD)
 Both processes look to provide a quick prototype to show the
 We can incorporate change in requirements and technology in
both processes anytime in the development spiral
Differences from ICSM
 The exploration, valuation and planning phase are very short or
rather not present in RAD as compared to ICSM
 RAD demands a lot more interaction and commitment from the
 ICSM is a more sound process as we verify the feasibility of a
project in the exploration, valuation move to prototyping in the
foundations phase. On the other hand RAD is an iterative and
incremental process, hence it can lead to a succession of
prototypes that never culminate in a satisfactory production
 Development of a product using RAD is a lot faster
Relevance to 577 ab
As mentioned before, we do use some form of RAD in ICSM where we try to
get a quick working prototype out
RAD would be perfect for a one semester project as it satisfies most of the
conditions such as:
- 6-8 people in a team
- short timeframe
- quick prototype needed
- Focused scope where the business objectives are well defined and narrow
In a two semester project, if you start of using the wrong software process, we
use a mild form of RAD to get back on track.
Companies using RAD
 SYBASE etc.
 Humans hate taking risks and hence love to see working
prototypes as they know things are working, this is where RAD
 RAD is perfect for a product that should be out in a short period
of time and where we can reuse code/data
 However, a lot of the big companies like Microsoft and IBM stick
to waterfall model with a little bit of spiraling for most of their
flagship products as they feel that it is a tried and tested process
 RAD has its advantages but the one big disadvantage is the time
the customer should give. In todays world where time is
everything this is a huge commitment from the client
http://en.wikipedia.org/wiki Rapid_application_development
A Survey of System development Software models – University of Albany / SUNY
RAD, Rapid Application Development, MacMillan Publishing Co., New York, 1990.