The outline below requires Netscape/Microsoft browsers, version 3.x or later, for correct viewing.
Revised March 15, 1997
PICTURE
DEFINITION
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 solution.
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 product quality
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 unachievable.
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 schedule)
the lowest development costs (because buying reusable components may cost more than building)
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
multiple languages
team scheduling
teamwork and collaboration
use of reusable components
use of standard APIs
version control (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
requirements.
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.
Customers talk.
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
are dropped.
NOTES
Iterations require between 1 day and 3 weeks.
At some stage, exploratory prototypes may evolve into
operational prototypes.
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
the meeting
by ensuring that adequate discussion is directed
toward each issue
by ensuring everyone has an adequate opportunity to
participate
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 process.
Customers, developers and management must accept informal deliverables.
Paper prototypes rather than full-scale systems
Notes from user workshops rather than formal requirements documents
Notes from designers' meetings rather than formal design documents
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 market).
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 systems) market.
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 (e.g., 4GLs).
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 technology.
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)
Early visibility (because of prototyping)
Greater flexibility (because developers can redesign almost at will)
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 appearance)
DISADVANTAGES
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)
Less efficient (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
More defects (because of the "code-like-hell" syndrome)
Prototype may not scale up, a B-I-G problem
Reduced features (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 appearance)
Successful efforts difficult to repeat (no two projects evolve the same way)
Unwanted features (through reuse of existing components)
SUMMARY From Sun "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."