From Wikipedia, the free encyclopedia
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.
[edit]Overview
In rapid application development, structured techniques and prototyping are especially used to define users'
requirements and to design the final system. The development process starts with the development of preliminary
data models and
business process models using structured techniques. In the next stage, requirements are verified using prototyping, eventually to refine the data and process models. These stages are repeated iteratively; further development results in "a combined business requirements and technical design statement to be used for constructing new systems".
[1]RAD approaches may entail compromises in functionality and performance in exchange for enabling faster development and facilitating application maintenance.
[edit]History
Rapid application development is a term originally used to describe a
software development process introduced by
James Martin in 1991. Martin's methodology involves iterative development and the construction of
prototypes. 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 was a response to non-
agile 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
[citation needed] 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.
[edit]Four phases of RAD
- Requirements Planning phase – combines elements of the system planning and systems analysis phases of the System 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.
- 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.
- 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.
- 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. Its tasks are data conversion, full-scale testing, system changeover, user training.
[edit]Another version of RAD phases
- Business Modeling: The information flow among business functions is defined by answering questions like what information drives the business process, what information is generated, who generates it, where does the information go, who process it and so on.
- Data Modeling: The information collected from business modeling is refined into a set of data objects (entities) that are needed to support the business. The attributes (character of each entity) are identified and the relation between these data objects (entities) is defined.
- Process Modeling: The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting or retrieving a data object.
- Application Generation: Automated tools are used to facilitate construction of the software; even they use the 4th GL techniques.
- Testing and Turn over: Many of the programming components have already been tested since RAD emphasis reuse. This reduces overall testing time. But new components must be tested and all interfaces must be fully exercised.
[edit]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.
[2] 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.
This table contains a high-level summary of some of the major types of RAD and their relative strengths and weaknesses.
Pros and cons of various RAD types
| 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[clarification needed] 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 under-develop 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 inprototyping, writing test cases and performing unit testing. | Dependence on strong cohesive teams and individual commitment to the project. Decision making relies on the feature functionalityteam and a communal decision-making process with lesser degree of centralized project management and engineering authority. |
|---|
| Scrum | 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 master who may lack the political skills to remove impediments and deliver the sprint goal. Due to relying on self-organizing teams and rejecting traditional centralized "process control", internal power struggles can paralyze a team. |
|---|
