introduction to rapid application development
DESCRIPTION
Provides an introduction to RADTRANSCRIPT
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!