Kyle Hartmann
Introduction
 RAD was created in response to long lead times and low flexibility
 Focuses on communication
 Quicker and better requirements interpretation
 Strict timetable
History: Concept Background
 Software development issues into the 1970s:
 Vast majority of projects used a waterfall model


Low Requirements Flexibility
Unable to go back to make changes unless a large portion of the process was
redone.
 Large amount of time needed to take a project from just an idea to
completion
History: Waterfall Model
 Example:
 After gathering
requirements and moving
through Integration
testing, requirements are
changed.
 To accommodate these
changes, the developer
must start at the top level
and move back down
until they are finally back
at integration testing.
History: RAD (1970s)
 Dan Gielan, System Development Center manager at New York
Telephone Co.
 Saw the trends that the waterfall model produced as inherent flaws with
the process.
 Engineered a new model that allowed design to adapt to changes easier
while shortening time to market.


Gielan believed by the time projects were created technology had changed and
therefore, so had the requirements.
Idea that even the most strenuous initial requirements gathering couldn’t unearth
all important requirements.
 The new process was used by New York Telephone Co. and the result was
cheaper software production with a better time to market.
History: RAD (1970s) cont.
 James Martin – IBM
 Brought the process to IBM to combat the same problems Gielan saw.
 After successful releases, Martin wrote a book, “Rapid Application
Development” giving the new process concept its name.
RAD Concepts





Minimal Planning (Initial Requirements gathering)
Rapid prototyping
Constant client communication
Rigid time schedule
Rigid budget constraints
Result: 80% of a complete system produced in the same
time as it takes for 20% of a system using traditional
methods
RAD Process Breakdown
 Requirements Planning
 Developers meet with clients to formulate a very basic understanding
 Focus on a few key objectives that will remain constant throughout
development

Idea that requirements may change but the scope of the project will remain
relatively the same.
 User Design
 Prototyping of user interaction with system (user interface)

Constant communication with client and/or end user
 Focus on user input
RAD Process Breakdown cont.
 Construction
 Finalized User interface
 Engineers implement backbone (unseen by user) of system
 Sparse communication with client/end user until completion of main
aspects
 Cutover
 Finishing up the software
 Last minute testing and changes
 Validation and Deployment
 Training
Advantages of RAD
 Flexibility
 Converge toward users’ optimal system with frequent changes
 Client inclusion
 Client sees work being done
 Decreased time to market
 Budget constraining
 Quality software through client/user communication
 Bugs can be found before release as prototypes are shown to the user.
Disadvantages of RAD
 Must have very effective communication skills at a developer level as
well as a management level
 Communication breakdown leads to a breakdown in software validity or
the timeline for production breaking down.
 Requires time budgeting skills at a management level
 If timing breaks down, the process becomes cumbersome rather than
efficient.
 Leads to a breakdown in budget constraints.
Branches of RAD
 Rapid Application development started as a concept or a set of ideas for
producing software.
 Early uses of RAD just mixed RAD concepts with traditional methods
 Creating hybrid approaches, more formal processes spun off of RAD
concepts.
Branches of RAD: Agile
 Takes prototyping principle from RAD
 Also focuses on flexible requirements
 Uses iterations for each prototype
 Formal communication with client


Done at end of each iteration
Management appoints a client
representative for communication.
Branches of RAD: Agile
 Microsoft RAD Presentation
Branches of RAD: Extreme
 Focus on flexibility coinciding with very high
quality
 Still maintains formalized requirements
planning
 Uses RAD concept of prototyping but with a
longer timetable
 Each prototype also includes strenuous
testing and other quality initiative (pair
programming, TDD, etc.)
 Changes made after a formal checkpoint at
the end of the process.
Branches of RAD: Joint Application
 Niche Development process
 Information Systems
 Reinforces RAD communication throughout development.
 Focus on Quality while trying to minimize cost and risk
Focuses of Joint
Application
Branches of RAD: Lean
 Mixes RAD for software with Lean
manufacturing principles.
 Process improvement and waste
minimization
 Eliminate wasted code and time
 Typically used as an add-on to other
methods such as the Agile method.
 Result should help improve quality
as well as time to market.
These focuses would usually
be added to whichever
process the development
team decides to use
Conclusion
 RAD is good for:
 Small – Medium sized projects
 Projects with changing technology
 Projects that need high flexibility
 RAD is bad for:
 Projects that need highly formalized standards
 Large projects
Questions