Rapid application development - Wikipedia, the free encyclopedia Page 1 of 6

Rapid application development

From Wikipedia, the free encyclopedia

Rapid application development (RAD) is both a general term used to refer to alternatives to the
conventional waterfall model of software development as well as the name for James Martin's approach
to rapid development. In general, RAD approaches to software development put less emphasis on
planning tasks and more emphasis on development. In contrast to the waterfall model, which emphasizes
rigorous specification and planning, RAD approaches emphasize the necessity of adjusting requirements
in reaction to knowledge gained as the project progresses. This causes RAD to use prototypes in
addition to or even sometimes in place of design specifications. RAD approaches also emphasize a
flexible process that can adapt as the project evolves rather than rigorously defining specifications and
plans correctly from the start. In addition to James Martin's RAD methodology, other approaches to
rapid development include Agile methods and the spiral model. RAD is especially well suited (although
not limited to) developing software that is driven by user interface requirements. Graphical user
interface builders are often called rapid application development tools.

Contents
1 History
2 The James Martin RAD Methodology
3 Pros and Cons of Rapid Application Development
4 See also
5 References
6 Further reading

History
Rapid application development is a response to processes developed in the 1970s and 1980s, such as the
Structured Systems Analysis and Design Method and other Waterfall models. One of the problems with
these methodologies is that they were based on a traditional engineering model used to design and build
things like bridges and buildings. Software is an inherently different kind of artifact. Software can
radically change the entire process used to solve a problem. As a result knowledge gained from the
development process itself can feed back to the requirements and design of the solution.[1] The waterfall
solution to this was to try and rigidly define the requirements and the plan to implement them and have a
process that discouraged changes to either. The new RAD approaches on the other hand recognized that
software development was a knowledge intensive process and sought to develop flexible processes that
could take advantage of knowledge gained over the life of the project and use that knowledge to reinvent
the solution.

http://en.wikipedia.org/wiki/Rapid_application_development 10/16/2014
Rapid application development - Wikipedia, the free encyclopedia Page 2 of 6

The first such RAD alternative was developed by Barry Boehm and was known as the spiral model.
Boehm and other subsequent RAD approaches emphasized developing prototypes as well as or instead
of rigorous design specifications. Prototypes had several advantages over traditional specifications:

Risk reduction. A prototype could test some of the most difficult potential parts of the system
early on in the life-cycle. This can provide valuable information as to the feasibility of a design
and can prevent the team from pursuing solutions that turn out to be too complex or time
consuming to implement. This benefit of finding problems earlier in the life-cycle rather than later
was a key benefit of the RAD approach. The earlier a problem can be found the cheaper it is to
address.
Users are better at using and reacting than at creating specifications. In the waterfall model it was
common for a user to sign off on a set of requirements but then when presented with an
implemented system to suddenly realize that a given design lacked some critical features or was
too complex. In general most users give much more useful feedback when they can experience a
prototype of the running system rather than abstractly define what that system should be.
Prototypes can be usable and can evolve into the completed product. One approach used in some
RAD methodologies was to build the system as a series of prototypes that evolve from minimal
functionality to moderately useful to the final completed system. The advantage of this besides the
two advantages above was that the users could get useful business functionality much earlier in
the process.[2]

Starting with the ideas of Barry Boehm and others, James Martin developed the rapid application
development approach during the 1980s at IBM and finally formalized it by publishing a book in 1991,
Rapid Application Development. This has resulted in some confusion over the term RAD even among IT
professionals. It is important to distinguish between RAD as a general alternative to the waterfall model
and RAD as the specific methodology created by Martin. The Martin methodology was tailored toward
knowledge intensive and UI intensive business systems.

The RAD approach also matured during the period of peak interest in business re engineering. The idea
of business process reengineering was to radically rethink core business processes such as sales and
customer support with the new capabilities of Information Technology in mind. RAD was often an
essential part of larger business re engineering programs. The rapid prototyping approach of RAD was a
key tool to help users and analysts "think out of the box" about innovative ways that technology might
radically reinvent a core business process.[3][4]

The James Martin RAD Methodology

The James Martin approach to RAD divides the process into four distinct phases:

http://en.wikipedia.org/wiki/Rapid_application_development 10/16/2014
Rapid application development - Wikipedia, the free encyclopedia Page 3 of 6

1. Requirements Planning phase

combines elements of the system planning
and systems analysis phases of the Systems
Development Life Cycle (SDLC). Users,
managers, and IT staff members discuss
and agree on business needs, project scope,
constraints, and system requirements. It
ends when the team agrees on the key
issues and obtains management
Phases in the James Martin approach to RAD
authorization to continue.
2. User design phase during this phase,
users interact with systems analysts and develop models and prototypes that represent all system
processes, inputs, and outputs. The RAD groups or subgroups typically use a combination of Joint
Application Development (JAD) techniques and CASE tools to translate user needs into working
models. User Design is a continuous interactive process that allows users to understand, modify,
and eventually approve a working model of the system that meets their needs.
3. Construction phase focuses on program and application development task similar to the SDLC.
In RAD, however, users continue to participate and can still suggest changes or improvements as
actual screens or reports are developed. Its tasks are programming and application development,
coding, unit-integration and system testing.
4. Cutover phase resembles the final tasks in the SDLC implementation phase, including data
conversion, testing, changeover to the new system, and user training. Compared with traditional
methods, the entire process is compressed. As a result, the new system is built, delivered, and
placed in operation much sooner.[5]

Pros and Cons of Rapid Application Development

In the modern Information Technology environment many systems are now built using some degree of
Rapid Application Development.[6] Not necessarily the James Martin approach. In addition to Martin's
methodology Agile methods and the Rational Unified Process are often used for RAD development.

The advantages of RAD include:

Better Quality. By having users interact with evolving prototypes the business functionality from a
RAD project can often be much higher than that achieved via a waterfall model. The software can
be more usable and has a better chance to focus on business problems that are critical to end users
rather than technical problems of interest to developers.

http://en.wikipedia.org/wiki/Rapid_application_development 10/16/2014
Rapid application development - Wikipedia, the free encyclopedia Page 4 of 6

Risk Control. Although much of the literature on RAD focuses on speed and user involvement a
critical feature of RAD done correctly is risk mitigation. It's worth remembering that Boehm
initially characterized the spiral model as a risk based approach. A RAD approach can focus in
early on the key risk factors and adjust to them based on empirical evidence collected in the early
part of the process. E.g., the complexity of prototyping some of the most complex parts of the
system.
More projects completed on time and within budget. By focusing on the development of
incremental units the chances for catastrophic failures that have dogged large waterfall projects is
reduced. In the Waterfall model it was common to come to a realization after six months or more
of analysis and development that required a radical rethinking of the entire system. With RAD this
kind of information can be discovered and acted upon earlier in the process.[2][7]

The disadvantages of RAD include:

The risk of a new approach. For most IT shops RAD was a new approach that required
experienced professionals to rethink the way they worked. Humans are virtually always averse to
change and any project undertaken with new tools or methods will be more likely to fail the first
time simply due to the requirement for the team to learn.
Requires time of scarce resources. One thing virtually all approaches to RAD have in common is
that there is much more interaction throughout the entire life-cycle between users and developers.
In the waterfall model, users would define requirements and then mostly go away as developers
created the system. In RAD users are involved from the beginning and through virtually the entire
project. This requires that the business is willing to invest the time of application domain experts.
The paradox is that the better the expert, the more they are familiar with their domain, the more
they are required to actually run the business and it may be difficult to convince their supervisors
to invest their time. Without such commitments RAD projects will not succeed.
Less control. One of the advantages of RAD is that it provides a flexible adaptable process. The
ideal is to be able to adapt quickly to both problems and opportunities. There is an inevitable
trade-off between flexibility and control, more of one means less of the other. If a project (e.g.
life-critical software) values control more than agility RAD is not appropriate.
Poor design. The focus on prototypes can be taken too far in some cases resulting in a "hack and
test" methodology where developers are constantly making minor changes to individual
components and ignoring system architecture issues that could result in a better overall design.
This can especially be an issue for methodologies such as Martin's that focus so heavily on the
User Interface of the system.[8]

http://en.wikipedia.org/wiki/Rapid_application_development 10/16/2014
Rapid application development - Wikipedia, the free encyclopedia Page 5 of 6

Very large systems. RAD typically focuses on small to medium sized project teams. The other
issues cited above (less design and control) present special challenges when using a RAD
approach for very large scale systems.[9][10][11]

See also
List of graphical user interface builders and rapid application development tools

References
1. ^ Brooks, Fred (1986). Kugler, H.J., ed. No Silver Bullet Essence and Accidents of Software Engeineering
(http://www.sci.brooklyn.cuny.edu/~sklar/teaching/s10/cis20.2/papers/brooks-no-silver-bullet.pdf).
Information Processing '86. Elsevier Science Publishers B.V (North-Holland). ISBN 0-444-70077-3.
Retrieved 2 July 2014.
2. ^ a b Boehm, Barry (May 1988). "A Spiral Model of Software
Development" (http://www.dimap.ufrn.br/~jair/ES/artigos/SpiralModelBoehm.pdf). IEEE Computer.
Retrieved 1 July 2014.
3. ^ Drucker, Peter (November 3, 2009). Post-Capitalist Society. Harper Collins e-books. ISBN 0887306209.
4. ^ Martin, James (1991). Rapid Application Development. Macmillan. ISBN 0-02-376775-8.
5. ^ Martin, James (1991). Rapid Application Development. Macmillan. pp. 8190. ISBN 0-02-376775-8.
6. ^ Hotle, Matt (April 1314, 2010). "The Disintegration of AD: Putting it Back Together
Again" (http://www.gartner.com.br/tecnologias_empresariais/pdfs/brl37l_a3.pdf).
http://www.gartner.com.br. Enterprise Integration Summit, Sao Palo, Brazil: Gartner Group. Retrieved 1 July
2014.
7. ^ Beck, Kent (2000). Extreme Programming Explained. Addison Wesley. pp. 37. ISBN 0201616416.
8. ^ Gerber, Aurona; Van der Merwe, Alta; Alberts, Ronell; (2007), Implications of Rapid Development
Methodologies, CSITEd 2007, Mauritius, November 2007 [1]
(http://ksg.meraka.org.za/~agerber/publications.html)
9. ^ Andrew Begel, Nachiappan Nagappan. "Usage and Perceptions of Agile Software Development in an
Industrial Context: An Exploratory Study, Microsoft
Research" (http://research.microsoft.com/pubs/56015/AgileDevatMS-ESEM07.pdf). Retrieved 2008-11-15.
10. ^ E. M. Maximilian and L. Williams. (2003). "Assessing Test-driven Development at IBM". Proceedings of
International Conference of Software Engineering, Portland, OR, pp. 564-569, 2003.
11. ^ M. Stephens, Rosenberg, D. (2003). "Extreme Programming Re factored: The Case Against XP". Apress,
2003.

Further reading

http://en.wikipedia.org/wiki/Rapid_application_development 10/16/2014
Rapid application development - Wikipedia, the free encyclopedia Page 6 of 6

Steve McConnell (1996). Rapid Development: Taming Wild Software Schedules, Microsoft Press
Books, ISBN 978-1-55615-900-8
Kerr, James M.; Hunter, Richard (1993). Inside RAD: How to Build a Fully Functional System in
90 Days or Less. McGraw-Hill. ISBN 0-07-034223-7.
Ellen Gottesdiener (1995). "RAD Realities: Beyond the Hype to How RAD Really Works
(http://ebgconsulting.com/Pubs/Articles/RAD_Realities_Beyond_the_Hype_Gottesdiener.pdf)"
Application Development Trends
Ken Schwaber (1996). Agile Project Management with Scrum, Microsoft Press Books, ISBN 978-
0-7356-1993-7
Steve McConnell (2003). Professional Software Development: Shorter Schedules, Higher Quality
Products, More Successful Projects, Enhanced Careers, Addison-Wesley, ISBN 978-0-321-
19367-4
Dean Leffingwell (2007). Scaling Software Agility: Best Practices for Large Enterprises,
Addison-Wesley Professional, ISBN 978-0-321-45819-3

Retrieved from "http://en.wikipedia.org/w/index.php?

title=Rapid_application_development&oldid=628957336"

Categories: Software project management Software development process

This page was last modified on 9 October 2014 at 18:29.

Text is available under the Creative Commons Attribution-ShareAlike License; additional terms
may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia is a
registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.

http://en.wikipedia.org/wiki/Rapid_application_development 10/16/2014