RAD, Rapid Application Development

advertisement
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
Download