1 / 19
Télécharger la présentation

Rapid Application Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related