© 1997 by Walter Maner (unless otherwise noted)
Revised March 15, 1997
May be reproduced only for non-commercial educational purposes.
The outline below requires Netscape/Microsoft browsers, version 3.x or later, for correct viewing.
a software development process that allows usable systems to be built
in as little as 60-90 days, often with some compromises
PRINCIPLES BEHIND THE DEFINITION
- In certain situations, a usable 80% solution can be produced in
20% of the time that would have been required to produce a total
In certain situations, the business requirements for a system can
be fully satisfied even if some of its operational requirements
are not satisfied.
In certain situations, the acceptability of a system can be
assessed against the agreed minimum useful set of requirements
rather than all requirements.
PROBLEMS ADDRESSED BY RAD
- With conventional methods, there is a long delay before the
customer gets to see any results.
With conventional methods, development can take so long that the
customer's business has fundamentally changed by the time the
system is ready for use.
With conventional methods, there is nothing until 100% of the
process is finished, then 100% of the software is delivered.
WHY USE RAD?
- BAD REASONS FOR USING RAD
- to prevent cost overruns
(RAD needs a team already disciplined in cost management)
to prevent runaway schedules
(RAD needs a team already disciplined in time management)
- GOOD REASONS FOR USING RAD
- to converge early toward a design acceptable to the customer
and feasible for the developers
to limit a project's exposure to the forces of change
to save development time, possibly at the expense of economy or
SCHEDULE versus ECONOMY versus PRODUCT QUALITY
- Tradeoffs determine the pace of development.
- Efficient Development
balances economy, schedule, and quality
- Schedule -- faster than average
Economy -- costs less than average
Product -- better than average quality
- Sensible RAD
tilts away from economy and quality toward fastest schedule
- Schedule -- much faster than average
Economy -- costs a little less than average
Product -- a little better than average quality
- All-out RAD
"code like hell"
- Schedule -- fastest possible
Economy -- costs more than average
Product -- worse than average quality
- For RAD, something other than schedule must be negotiable.
- RAD has a fair chance of success if the customer will negotiate
either economy or quality
RAD has a better chance for success if the customer will
negotiate both economy and quality
NOTE: Negotiating quality does NOT mean accepting a higher
defect rate. It means accepting a product that is less usable,
less fully-featured, or less efficient.
- So, with RAD, one or more of the following goals may be
- the fewest possible defects
(because developers may not have the legal right to modify the
source for some plug-in components)
the highest possible level of customer satisfaction
(because secondary requirements may be sacrificed to stay on
the lowest development costs
(because buying reusable components may cost more than
ABBREVIATED HISTORY OF RAD
- Barry Boehm (spiral model) --->
Tom Gilb (evolutionary life cycle) --->
Scott Shultz (RIPP, rapid iterative productive prototyping) --->
James Martin (RAD, circa 1991)
CHARACTERISTICS OF RAD
- RAD USES HYBRID TEAMS
- Teams should consist of about 6 people, including both
developers and full-time users of the system plus anyone else
who has a stake in the requirements.
Developers chosen for RAD teams should be multi-talented
"renaissance" people who are analysts, designers and
programmers all rolled into one.
- RAD USES SPECIALIZED TOOLS THAT SUPPORT ...
- "visual" development
creation of fake prototypes (pure simulations)
creation of working prototypes
teamwork and collaboration
use of reusable components
use of standard APIs
(because lots of versions will be generated)
- RAD USES "TIMEBOXING"
Secondary features are dropped as necessary to stay on schedule.
RAD USES ITERATIVE, EVOLUTIONARY PROTOTYPING
- JAD (Joint Application Development) MEETING
High-level end-users and designers meet in a brainstorming
session to generate a rough list of initial requirements.
- Developers talk and listen
Customers talk and listen
- ITERATE UNTIL DONE
- Developers build / evolve prototype based on current
Designers review the prototype.
Customers try out the prototype, evolve their requirements.
FOCUS GROUP meeting
Customers and developers meet to review product together,
refine requirements, generate change requests.
- Developers listen.
- Requirements and change requests are "timeboxed".
- Changes that cannot be accommodated within existing
timeboxes are eliminated.
If necessary to stay "in the box," secondary requirements
- Iterations require between 1 day and 3 weeks.
At some stage, exploratory prototypes may evolve into
Focus Group Sessions
- last about 2 hours
are led by an experienced facilitator, who keeps the
group "on focus"
- by having clear goals regarding the kind of
information that needs to be elicited
by preparing an issue-oriented agenda in advance of
by ensuring that adequate discussion is directed
toward each issue
by ensuring everyone has an adequate opportunity to
- are followed by a report from the facilitator
IMPORTANT RAD CONSTRAINTS
From Sun and other sources
- "Fitness for a business purpose" must be the criterion for
acceptance of deliverables.
All constituencies that can impact application requirements must
have representation on the development team throughout the
Customers, developers and management must accept informal
- Paper prototypes rather than full-scale systems
Notes from user workshops rather than formal requirements
Notes from designers' meetings rather than formal design
PRINCIPLE: Create the minimum documentation necessary to
facilitate future development and maintenance.
- Development teams must be empowered to make some decisions
traditionally left to management.
End-to-end timescale must be 6 months or less.
Iteration must be used in such a way that the development process
converges toward an acceptable business solution.
Prototyping must incorporate evolving requirements quickly, in
real time, and gain consensus early.
There must be a "buy before build" bias.
WHEN RAD WORKS AND WHEN IT DOESN'T
- RAD TENDS TO WORK WHEN
- The application will be run standalone.
Major use can be made of preexisting class libraries (APIs).
Performance is not critical.
Product distribution will be narrow (in-house or vertical
Project scope (macro-schedule) is constrained.
Reliability is not critical.
System can be split into several independent modules.
The product is aimed at a highly specialized IS (information
The project has strong micro-schedule constraints (timeboxes).
The required technology is more than a year old.
- RAD TENDS TO FAIL WHEN ...
- Application must interoperate with existing programs.
Few plug-in components are available.
Optimal performance is required.
Product development can't take advantage of high-end IS tools
Product distribution will be wide (horizontal or mass market).
RAD becomes QADAD (Quick And Dirty Application Development).
RAD methods are used to build operating systems (reliability
target too high for RAD), computer games (performance target
too high for RAD).
Technical risks are high due to use of "bleeding" edge
The product is mission- or life-critical.
The system cannot be modularized (defeats parallelism).
EVALUATION OF RAD
- ADVANTAGES OF RAD
- Buying may save money compared to building
Deliverables sometimes easier to port
(because they make greater use of high-level abstractions,
scripts, intermediate code)
Development conducted at a higher level of abstraction
(because RAD tools operate at that level)
(because of prototyping)
(because developers can redesign almost at will)
Greatly reduced manual coding
(because of wizards, code generators, code reuse)
Increased user involvement
(because they are represented on the team at all times)
Possibly fewer defects
(because CASE tools may generate much of the code)
Possibly reduced cost
(because time is money, also because of reuse)
Shorter development cycles
(because development tilts toward schedule and away from
economy and quality)
Standardized look and feel
(because APIs and other reusable components give a consistent
- Buying may not save money compared to building
Cost of integrated toolset and hardware to run it
Harder to gauge progress
(because there are no classic milestones)
(because code isn't hand crafted)
Loss of scientific precision
(because no formal methods are used)
May accidentally empower a return to the uncontrolled practices
of the early days of software development
(because of the "code-like-hell" syndrome)
Prototype may not scale up, a B-I-G problem
(because of timeboxing, software reuse)
Reliance on third-party components may ...
- sacrifice needed functionality
add unneeded functionality
create legal problems
- Requirements may not converge
(because the interests of customers and developers may diverge
from one iteration to the next)
Standardized look and feel (undistinguished, lackluster
Successful efforts difficult to repeat
(no two projects evolve the same way)
(through reuse of existing components)
"In order to ensure high responsiveness, projects are designed with
fixed timescales, sacrificing functionality if necessary. This
allows the development team to focus on the pieces of functionality
that have the highest business value, and deliver that functionality
rapidly. Change is often the reason for delays in application
development. In long linear development processes, changes in
functionality requirements or project scope, particularly after a lot
of time has been invested in planning, design, development and
testing, cause many months to be lost and significant expense to be
incurred for redesigning and redevelopment. RAD combats scope and
requirements creep by limiting the project's exposure to change --
shortening the development cycle and limiting the cost of change by
incorporating it up-front before large investments are made in
development and testing."