Rapid Application Development
Download
Report
Transcript Rapid Application Development
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