Rapid Application Development Kyle Hartmann Introduction RAD was

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 1970 s: �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 (1970 s) �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 (1970 s) 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