Rapid Application Development
Definition: Also sometimes referred to as Rapid Prototyping, Rapid
Application Development is a method of decreasing the time taken to design
software systems. It uses incremental development and the construction of
prototypes - and encourages constant feedback from users/customers by keeping
lines of communication clear - with the end goal of expediting the development
cycle.
| |
|
|
Rapid Application Development was a software development methodology introduced
in the 1990s and presented in book form by information technology guru James
Martin. A reaction to the then well-established methodologies which emphasised
careful and prolonged requirements gathering before the actual software
development began, Rapid Application Development encouraged the creation of
quick-and-dirty prototype-style software which fulfilled most of the user’s
requirements but not necessarily all. Development would take place in a series
of short cycles, called time boxes, each of which would deepen the functionality
of the application a little more. Features to be implemented in each time box
were agreed in advance and this game plan rigidly adhered to. The strong
emphasis on this point came from unhappy experience with other development
practices in which new requirements would tend to be added as the project was
evolving, caused massive chaos and disrupting the already carefully prepared
plans and development schedules. Rapid Application Development methodology
advocated that development be undertaken by small, experienced teams using CASE
(Computer Aided Software Engineering) tools to enhance their productivity.
Rapid Application Development advocates believed that the development of
rapid prototypes was a good way to flush out customer requirements by
gaining immediate feedback from the client. One of the problems that had
been identified with other software development practices was that clients
often didn’t really know what they wanted or didn’t want until they saw a
practical implementation. It was through the process of customers
commenting on an evolving application that new requirements were teased
out. Usually, this would be seen as an unwelcome development which could
play havoc with agreed schedules. With the Rapid Application Development
methodology, however, it became a standard and accepted part of the
development process.
With its emphasis on small teams and short development cycles, it is not
surprising that, in Rapid Application Development doctrine, code reuse was
also prized as a means of helping get the work done. This caused early
Rapid Application Development adopters to embrace object-oriented
languages and practices before they had really penetrated into the
mainstream.
Today, Rapid
Application Development as a formal methodology is no longer
widely practiced. Some would argue, however, that it is a case of
revolutionaries evolving into statesmen, and once boldly innovative
thinking becoming the new orthodoxy. In its embrace of the object-oriented
paradigm, and the use of software engineering tools to enhance programmer
productivity, it was certainly ahead of its time. And in its emphasis on
small teams, short, iterative development cycles and an avoidance of
prolonged requirements gathering up front, it shares many similarities
with the extreme programming or agile development methodologies which
still remain in vogue.
As well as denoting a formal software development methodology, the
phrase rapid application development became something of a marketing
buzzword and was casually applied to a variety of software development
products. Although hardly hardcore implementations of the methodology’s
ideas, these products did incorporate some of its key concepts. For
example, to facilitate rapid development, strong emphasis was placed on
the idea of software re-use. The notion of software components began to be
nurtured. Supporters believed that complex software systems could be
constructed largely by stitching pre-built software components together.
In this grandiose vision, software components would be re-used from
project to project within a company’s development team or even bought in
from outside. In fact, it was hoped that a healthy market for third-party
software components would develop, allowing even small companies to thrive
by authoring niche software components designed to be used by others.
Although reality never quite fulfilled the aspirations of some of the
visionaries, the ActiveX control and JavaBeans software component
standards did acquire some degree of traction, and a market for
third-party code components written to these standards did emerge, even if
it was never all that vigorous.
Another key element of the Rapid Application Development-lite approach was
visual programming. According to this concept, it should be possible to
construct software with little or no knowledge of programming. The ideal
was that programs could be built by non-programmers hooking components
together in some kind of workshop-like development application. Again,
this ideal was never quite fulfilled, but visual development practices did
become a standard part of the typical programmer’s toolkit and are now
routinely used to develop some parts of software applications, while more
traditional coding accounts for the rest. Graphical interfaces, for
example, are now constructed visually more often than not, with
programmers or user interface designers modifying the desired look of the
user interface from within a visual editor and the Rapid Application
Development tool then generating the appropriate code to create that look
automatically. The automatically-generated code then forms a skeleton
framework for the application as a whole which the software developers
then build upon and edit by hand.
In common use today, the phrase Rapid Application Development has lost
most of its original meaning, and even in the ranks of IT professionals,
many would be unaware that it once referred to a formal software
development methodology. Almost any software tool which is used in the
creation of other software will be described in its marketing literature
as something that facilitates Rapid Application Development. When used
informally in this sense, the phrase Rapid Application Development usually
indicates that the tool in question takes some of the burden from the
programmer’s back by automatically generating part of the program code.
Today the software tools used by the majority of programmers to develop
new software are called Integrated Development Environments (IDEs). Almost
all of them include some Rapid Application Development features. When
creating a new program, for example, the software engineer can indicate
what kind of application it should be, such as a console application, a
program with a graphical user interface or one that is database-driven.
The IDE will then generate a base template of code which the programmer
takes as a starting point for his or her own work.
|