Rapid Application Development

1. Rapid Application Development Kyle Hartmann

2. Introduction • RAD was created in response to long lead times and low flexibility • Focuses on communication • Quicker and better requirements interpretation • Strict timetable

3. 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

4. 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.

5. 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.

6. 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.

7. 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

8. 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

9. 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

10. 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.

11. 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.

12. 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.

13. 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.

14. Branches of RAD: Agile Microsoft RAD Presentation

15. 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.

16. Branches of RAD: Joint Application Focuses of Joint Application • Niche Development process • Information Systems • Reinforces RAD communication throughout development. • Focus on Quality while trying to minimize cost and risk

17. Branches of RAD: Lean These focuses would usually be added to whichever process the development team decides to use • 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.

18. 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

19. Questions