Rapid Application Development Mahir Anwar

Content Introduction Explanation History Example To RAD or NOT to RAD Similarities and Differences with ICSM Relevance to 577 ab Companies using RAD Conclusion

Quotes “Even the best planning is not so omniscient as to get it right the first time.” -- Fred Brooks “In software, we rarely have meaningful requirements.  Even if we do, the only measure of success that matters is whether our solution solves the customer’s shifting idea of what their problem is.” -- Jeff Atwood

Introduction Rapid Application Process (RAD) is a Software Development Methodology that uses - Minimal Planning - Rapid Prototyping - Iterative and Incremental Process

Explanation

History Rapid Application Development was introduced by James Martin It was developed as a response to non-agile processes, such as Structured Systems Analysis and Design Method and the Waterfall Models RAD was inspired by the following process models: - Barry Boehm (spiral model) - Tom Gilb (evolutionary life cycle) - Scott Shultz (RIPP, rapid iterative productive prototyping)

History One major problem with the previously used methodologies was that the application took a long time to build The requirements often changed before the system was complete, resulting in inadequate or even unusable systems Another problem was the assumption that a methodical requirements analysis phase alone would identify all the critical requirements

An Example We consider an example of the loans department in a bank

An Example Analyze the business process and workflow of the loans department Split this into individual smaller components Obtain the business process and workflow for these smaller components Start prototyping (reusing the code if present) and using CASE tools Show the prototype to the client and confirm feasibility Do this for all the individual components and make the changes required Finally integrate all the individual components and start integration testing Can have multiple teams working on different components at the same time

To RAD or Not to RAD ?

When to RAD ? To converge early toward a design acceptable to the customer and feasible for the developers To limit a project's exposure to the forces of change To save development time, possibly at the expense of economy or product quality When we have a focused scope where the business objectives are well defined and narrow. Data for the project already exists (completely or in part). The project largely comprises analysis or reporting of the data The technical architecture is defined and clear and the key technology components are in place and tested. We know the right CASE tools to be used Technical requirements (response times, throughput, database sizes, etc.) are reasonable and well within the capabilities of the technology being used.

When Not to RAD ? The technical architecture is unclear and much of the technology will be used for the first time within the project. Complex and voluminous data must be analyzed, designed and created within the scope of the project. Broad scope where the business objectives are obscure or broad. Client is busy and cannot give to much time to the development Large teams with more than 8 members

Similarities to ICSM RAD was conceived by looking into Barry Boehm’s Incremental Commitment Model, where he introduced prototyping to reduce risk The prototyping and spiral development is seen in both the processes The client’s feedback is considered before moving onto the next spiral (ARB in ICSM and working prototype in RAD) Both processes look to provide a quick prototype to show the client We can incorporate change in requirements and technology in both processes anytime in the development spiral

Differences from ICSM The exploration, valuation and planning phase are very short or rather not present in RAD as compared to ICSM RAD demands a lot more interaction and commitment from the client ICSM is a more sound process as we verify the feasibility of a project in the exploration, valuation move to prototyping in the foundations phase. On the other hand RAD is an iterative and incremental process, hence it can lead to a succession of prototypes that never culminate in a satisfactory production application Development of a product using RAD is a lot faster

Relevance to 577 ab As mentioned before, we do use some form of RAD in ICSM where we try to get a quick working prototype out RAD would be perfect for a one semester project as it satisfies most of the conditions such as: - 6-8 people in a team - short timeframe - quick prototype needed - Focused scope where the business objectives are well defined and narrow In a two semester project, if you start of using the wrong software process, we use a mild form of RAD to get back on track.

Companies using RAD IBM SAP MICROSOFT ORACLE SYBASE etc.

Conclusion Humans hate taking risks and hence love to see working prototypes as they know things are working, this is where RAD excels RAD is perfect for a product that should be out in a short period of time and where we can reuse code/data However, a lot of the big companies like Microsoft and IBM stick to waterfall model with a little bit of spiraling for most of their flagship products as they feel that it is a tried and tested process RAD has its advantages but the one big disadvantage is the time the customer should give. In todays world where time is everything this is a huge commitment from the client

References www.greenbay.usc.edu http://en.wikipedia.org/wiki Rapid_application_development http://searchwindevelopment.bitpipe.com/olist/Rapid-Application-Development.html http://csweb.cs.bgsu.edu/maner/domains/RAD.htm A Survey of System development Software models – University of Albany / SUNY http://www.gantthead.com/content/processes/11306.cfm#Description http://software-document.blogspot.com/2010/11/rapid-application-development-quick.html RAD, Rapid Application Development, MacMillan Publishing Co., New York, 1990. http://www.jamesmartin.com

Questions?

fin