1.

Introduction to
Rapid Application Development

Kasun Ranga Wijeweera

(krw19870829@gmail.com)
 What is RAD?
• Usable systems are built within a short period
of time
• In generic terms RAD is
– “Speedy development”
– “Shorter schedule”
 Principles of RAD
• 20/80 Rule: Usable 80% solution can be
developed in 20% of time required for the total
solution
• System can satisfy all business requirements
even if some operational requirements are not
satisfied
• A system can be accepted if it can satisfy
agreed minimum useful set of requirements
 Traditional Development Issues
• Cost and schedule overruns
• Product not fit for business
• High workload
• Projects get cancelled
• Friction among managers, developers and
customers
 Reasons for Project Failures
• Risks associated with teams
• Risks associated with technology
• Risks associated with requirements
 Conventional Methods!
• Long delay before customer sees the result
• Development takes longer time and business
may change meanwhile
• There is nothing until the entire project is
finished
 History of RAD
• Spiral model
• Evolutionary life cycle
• Rapid iterative productive prototyping
• RAD – Early 90s
 Classic Mistakes
• People related
• Product related
• Technology related
• Process related
 People Related Mistakes
• Undermined motivation
• Weak personnel
• Employee problems
• Heroics
• Unrealistic expectations
• Noisy offices
• Adding people to a late project
• Friction between customers and developers
 Product Related Mistakes
• Requirements gold plating
• Developer gold plating
• Feature creep
– Changes of the requirements occur for a long
period of time
• Push me….Pull me negotiation
• Research oriented development
 Technology Related Mistakes
• Silver Bullet Syndrome
– Too much rely on new technologies
• Switching tools at the middle of the project
– Learning curve, rework
• Overestimated savings from new tools or
methods
• Lack of automated source code control
 Process Related Mistakes
• Lack of risk management
• Contractor failure
• Lack of planning
• Premature convergence
• Planning to catch up later
– Code like hell programming
• Wastage of time at the fuzzy front end
 Why use RAD?
• Converging early to a design acceptable by the
customer
• Saving development time
• Preventing cost overruns
• Preventing runaway schedules
 Choose Most Rapid Model?
• How well the customer and the client
understand the requirements at the beginning
• Level of awareness about the system
architecture
• Amount of reliability
• How much planning ahead?
Thank you!