Kyle Hartmann

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

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: Concept Background

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: Waterfall Model

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 couldnt 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)

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. History: RAD (1970s) cont.

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 Concepts

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

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 RAD Process Breakdown cont.

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

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: Agile

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: Extreme

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

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

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 Conclusion

Questions