Rapid application development

Graphical user interface builders are often incorrectly called rapid application development tools

For Scottish ERP vendor, see RAD Software.

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

Rapid Application Development (RAD) Model

Rapid application development (RAD) is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

History

Rapid Application Development (RAD) is a term originally used for describing a software development process first developed and successfully deployed during the mid-1970s by the New York Telephone Co's Systems Development Center under the direction of Dan Gielan. Following a series of remarkably successful implementations of this process, Gielan lectured extensively in various forums on the methodology, practice, and benefits of this process.

RAD involves iterative development and the construction of prototypes. In 1990, in his book RAD, Rapid Application Development, James Martin documented his interpretation of the methodology. More recently, the term and its acronym have come to be used in a broader, general sense that encompasses a variety of methods aimed at speeding application development, such as the use of software frameworks of varied types, such as web application frameworks.

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 problem with previous methodologies was that applications took so long to build that requirements had 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. Ample evidence attests to the fact that this is seldom the case, even for projects with highly experienced professionals at all levels.

Starting with the ideas of Brian Gallagher, Alex Balchin, Barry Boehm and Scott Shultz, 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.

Four phases of RAD

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 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.

Relative effectiveness

The shift from traditional session-based client/server development to open sessionless and collaborative development like Web 2.0 has increased the need for faster iterations through the phases of the software development process. This, coupled with the growing use of open source frameworks and products in core commercial development, has, for many developers, rekindled interest in finding a silver bullet RAD methodology.

Rapid Application Development (RAD) can be considered as a type of Agile technique or vice-a-versa. Some may, however, choose to separate these two based on the fact that RAD focuses on developing what is interesting instead of what is needed, as in conventional Agile. But it can be argued that end users are eventually going to need what interests them, thus making it hard to differentiate between the two methodologies.

Although most RAD methodologies foster software re-use, small team structure and distributed system development, most RAD practitioners recognize that, ultimately, no one "rapid" methodology can provide an order of magnitude improvement over any other development methodology.

All types of RAD have the potential for providing a good framework for faster product development with improved software quality, but successful implementation and benefits often hinge on project type, schedule, software release cycle and corporate culture. It may also be of interest that some of the largest software vendors such as Microsoft and IBM do not extensively use RAD in the development of their flagship products and for the most part, they still rely primarily on traditional waterfall methodologies with some degree of spiraling.

This table contains a high-level summary of some of approaches that can be thought to have their roots in RAD:

Pros and cons of RAD and Agile methodologies:

Name	Pros	Cons
Agile	Minimizes feature creep by developing in short intervals resulting in miniature software projects and releasing the product in mini-increments.	Short iteration may add too little functionality, leading to significant delays in final iterations. Since Agile emphasizes real-time communication (preferably face-to-face), using it is problematic for large multi-team distributed system development. Agile methods produce very little written documentation and require a significant amount of post-project documentation.
Extreme	Lowers the cost of changes through quick spirals of new requirements. Most design activity occurs incrementally and on the fly.	Programmers must work in pairs, which is difficult for some people. No up-front "detailed design" occurs, which can result in more redesign effort in the long term. The business champion attached to the project full-time can potentially become a single point of failure for the project and a major source of stress for a team.
Joint application	Captures the voice of the customer by involving them in the design and development of the application through a series of collaborative workshops called JAD sessions.	The client may create an unrealistic product vision and request extensive gold-plating, leading a team to over- or underdevelop functionality.
Lean	Creates minimalist solutions (i.e., needs determine technology) and delivers less functionality earlier; per the policy that 80% today is better than 100% tomorrow.	Product may lose its competitive edge because of insufficient core functionality and may exhibit poor overall quality.
RAD	Promotes strong collaborative atmosphere and dynamic gathering of requirements. Business owner actively participates in prototyping, writing test cases and performing unit testing.	Dependence on strong cohesive teams and individual commitment to the project. Decision-making relies on the feature functionality team and a communal decision-making process with lesser degree of centralized project management and engineering authority.
Scrum	Agile framework. Improved productivity in teams previously paralyzed by heavy "process", ability to prioritize work, use of backlog for completing items in a series of short iterations or sprints, daily measured progress and communications.	Reliance on facilitation by a scrum-master who may lack the political skills to remove impediments and deliver the sprint goal. Due to reliance on self-organizing teams and rejection of traditional centralized "process control", internal power struggles can paralyze a team.

Criticism

Since rapid application development is an iterative and incremental process, it can lead to a succession of prototypes that never culminate in a satisfactory production application. Such failures may be avoided if the application development tools are robust, flexible, and put to proper use. This is addressed in methods such as the 2080 Development method or other post-agile variants.

Furthermore, there is a phenomenon behind a failed succession of unsatisfactory prototypes: End-users intuitively and primarily look to the Graphical User Interface (GUI) as a first measure of software qualities. The faster they "see" something working, the more "rapid" they perceive the development cycle to be. This is because the GUI has a strong natural directly viewable presence, while other problem domain code must be deduced or inferred, going largely unnoticed.

As programmers are generally software end-users first and programmers later, this natural gravitation towards "seeing" is engrained from the beginning (e.g. "Hello World" is not about the data or business domain, but is about "seeing" something on a screen). Programmers without clear training towards understanding this deceptive quality of software also tend to gravitate their measurement of "rapid" in RAD by how quickly the GUI progresses. The tendency is further strengthened by the fact that end-users hold the financial reward programmers seek, leading them to ignorantly cater to the measurement mind-set of the end-user rather than a suitable and more realistic alternative. Consequently, many software development tools strongly and primarily focus on the application GUI as well. This tendency to measure "rapid" by means of the GUI is strengthened further by programmers who (in turn) become RAD tool producers. They also have a strong financial interest and cater to the software development community GUI-centric model. Finally, an anecdotal review of RAD tools reveals the strong GUI focus, where "Hello World" and other GUI-centric examples abound and a dearth of data or business problem domain examples exist.

Ultimately, the triad of players (e.g. end-users, programmers, tool-developers), each with a strong and misplaced focus on the GUI aspects of software applications leads to a cultural underemphasis of the bulk of what the software text is actually about: The business and data problem domains. Furthermore, the culture of RAD (and indeed of software in general), with the central GUI emphasis, presents a multifaceted problem for engineers who recognize the problem and seek to overcome and engender an opposite environment (end-users, developers and tools).

First, there is the lack of rapid application development tools that emphasize the appropriate problem domain. Next, appropriately trained engineers have the task of training and educating end-users to see the counter-intuitive data and business code as the appropriate measure of how well or rapidly a software product is being developed. Finally, there is a lack of project engineers who understand the misplaced problem domain and are trainable and capable to the task of reorienting themselves to the counter-intuitive viewpoint.

Practical implications

When organizations adopt rapid development methodologies, care must be taken to avoid role and responsibility confusion and communication breakdown within a development team, and between team and client. In addition, especially in cases where the client is absent or not able to participate with authority in the development process, the system analyst should be endowed with this authority on behalf of the client to ensure appropriate prioritisation of non-functional requirements. Furthermore, no increment of the system should be developed without a thorough and formally documented design phase.

Further reading

• 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" 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