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

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.