“Rapid Application Development (RAD) is an incremental software development process model

that emphasises a very short development cycle [typically 60-90 days].” The RAD model, shown
in Fig. 1.5, is a high-speed adaptation of the waterfall model, where the result of each cycle a
fully functional system.
RAD is used primarily for information systems applications, the RAD approach encompasses the
following phases:

Business modeling
The information flow among business functions is modeled in a way that answers the following
questions:
What information drives the business process?
What information is generated?
Who generates it?
Where does the information go?
Who processes it?

Data modeling
The information flow defined as part of the business modeling phase is refined into a set of data
objects that are needed to support the business. The characteristics (called attributes) of each
object are identified and the relationships between these objects are defined.

Process modeling
The data objects 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
RAD assumes the use of the RAD fourth generation techniques and tools like VB, VC++, Delphi
etc rather than creating software using conventional third generation programming languages.
The RAD works to reuse existing program components (when possible) or create reusable
components (when necessary). In all cases, automated tools are used to facilitate construction of
the software.

Testing and turnover

Since the RAD process emphasizes reuse, many of the program components have already been
tested. This minimizes the testing and development time.

If a business application can be modularized so that each major function can be completed within
the development cycle then it is a candidate for the RAD model. In this case, each team can be
assigned a model, which is then integrated to form a whole.
Disadvantages
· For Large (but scalable) projects, RAD requires sufficient resources to create the right
number of RAD teams.

· RAD projects will fail if there is no commitment by the developers or the clients to ‘rapid-
fire’ activities necessary to get a system complete in a much abbreviated time frame.

· If a system cannot be properly modularized, building components for RAD will be

problematic

· RAD is not appropriate when technical risks are high, e.g. this occurs when a new
application makes heavy use of new technology.

2.

Rapid Application Development (RAD) refers to a type of 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.

Contents
[hide]

• 1 Overview
• 2 History
• 3 The relative effectiveness of RAD
• 4 Criticism
• 5 Practical implications with rapid development methodologies
• 6 See also
• 7 References

• 8 Further reading
 [edit] Overview
Rapid Application Development is a software development methodology that involves
techniques like iterative development and software prototyping. According to Whitten (2004), it
is a merger of various structured techniques, especially data-driven Information Engineering,
with prototyping techniques to accelerate software systems development.[1]

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, generic sense that encompasses a variety of techniques aimed at
speeding application development, such as the use of web application frameworks and other
types of software 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] The relative effectiveness of RAD

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 SDLC.[2] This, coupled with the growing utilization of open source frameworks and
products in core commercial development, has, for many developers, rekindled interest in
finding a silver bullet RAD methodology.

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

All flavors of RAD have the potential for providing a good framework for faster product
development with improved code 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[3] and IBM[4] do not extensively
utilize RAD in the development of their flagship products and for the most part, they still
primarily rely on traditional waterfall methodologies with some degree of spiraling.[5]

The following table contains a high-level summary of some of the major flavors of RAD and
their relative strengths and weakness.

Agile software development

Minimizes feature creep by developing in short intervals resulting in miniature software projects and
Pros
releasing the product in mini-increments.
Short iteration may not add enough functionality, leading to significant delays in final iterations. Since
Agile emphasizes real-time communication (preferably face-to-face), utilizing it is problematic for
Cons
large multi-team distributed system development. Agile methods produce very little written
documentation and require a significant amount of post-project documentation.
Extreme Programming (XP)
Lowers the cost of changes through quick spirals of new requirements. Most of the design activity
Pros
takes place incrementally and on the fly.
Programmers are required to work in pairs (which may be difficult for some developers). There is no
up-front “detailed design”, which could result in more redesign effort in the long run. The business
Cons
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 the team.
Joint Application Development (JAD)
Captures the voice of the customer by involving them in the design and development of the application
Pros
through a series of collaborative workshops called JAD sessions.
The client may create an unrealistic product vision and request extensive gold-plating, leading the team
Cons
to over- or under-develop functionality.
Lean software development (LD)
Creation of minimalist solutions (i.e., needs determine technology) and delivering less functionality
Pros
earlier (as per the paradigm that 80% today is better than 100% tomorrow).
Product may lose its competitive edge because of insufficient core functionality and may exhibit poor
Cons
overall quality.
Rapid Application Development (RAD)
 Promotes strong collaborative atmosphere and dynamic gathering of requirements. Business owner
Pros
actively participates in prototyping, writing test cases and performing unit testing.
Dependency on strong cohesive teams and individual commitment to the project. Decision making
Cons relies on the feature functionality team and a communal decision-making process with lesser degree of
centralized PM and engineering authority.
Scrum
Improvement in productivity in teams previously paralyzed by heavy “process”, ability to prioritize
Pros work, utilization 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 clout to remove impediments and
Cons deliver the sprint goal. Due to its reliance on self-organizing teams and the rejection of the traditional
centralized "process control", internal power struggles may paralyze the team.

Table1: Pros and Cons of various RAD flavors

[edit] 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.

[edit] Practical implications with rapid development

methodologies
When organizations adopt rapid development methodologies, care must be taken to avoid role
and responsibility confusion and communication breakdown within the development team, and
between the team and the 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.[6]

3.

RAD is a linear sequential software development process model that emphasis an extremely
short development cycle using a component based construction approach. If the requirements are
well understood and defines, and the project scope is constraint, the RAD process enables a
development team to create a fully functional system with in very short time period.

RAD model has the following phases:

1. 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.
2. 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.
3. 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.
4. Application Generation: Automated tools are used to facilitate construction of the
software; even they use the 4th GL techniques.
5. 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.

What are the advantages and disadvantages of RAD?

RAD reduces the development time and reusability of components help to speed up
development. All functions are modularized so it is easy to work with.

For large projects RAD require highly skilled engineers in the team. Both end customer and
developer should be committed to complete the system in a much abbreviated time frame. If
commitment is lacking RAD will fail. RAD is based on Object Oriented approach and if it is
difficult to modularize the project the RAD may not work well.

Cinoy M.R is a Computing Engineer, specializing in solution / concept selling

in Information Technology, Wealth Management, as well as Stress
Management.

Read his blogs http://cinoy-tickets.blogspot.com

Article Source: http://EzineArticles.com/?expert=Cinoy_Ravindran

4
RAD Model

Rapid Application development (RAD) is an incremental software development process model

that emphasizes an extremely short development cycle (anywhere from 60-90 days). The RAD
model is a high-speed adaptation of the linear sequential model / Waterfall model. The RAD
approach encompasses the following phases:

[edit]
Business Modeling
The information flow among business functions is modeled in a way that answers the following
questions:

• What information drives the business processes?

• What information is generated?
• Who generates it?
• Where does the information flow?
• Who processes it?

[edit]
Data Modeling
The information flow defined as part of the business modeling phase is refined into a set of data
objects that are needed to support the business. The characteristics called attributes of each
objects are identified and the relationships between the objects are then defined.

[edit]
Process Modeling
The data objects defined in the data modeling phase are transformed to achieve the information
flow necessary to implement the business functions. Processing descriptions are created for
adding, modifying, deleting or retrieving a data object.

[edit]
Application generation
RAD assumes the use of fourth generation techniques. Rather than creating software using
conventional third generation programming languages,

RAD process works to use the automated tools to facilitate the construction of the software.

[edit]
Testing and turnover
Since the RAD processes emphasize reuse, many of the program components have already been
tested. This saves time, money and the overall time to test an application also reduces
considerably.

[edit]
Disadvantages
1. For Large (but scalable) projects, RAD requires sufficient resources to create
the right number of RAD teams.

1. Not all applications are compatible for RAD. If a system cannot be properly
modularized, building components for RAD will be problematic.

1. RAD not appropriate when technical risks are high. This normally occurs when
a new application makes heavy use of new technology or when the new
software requires a high degree of interoperability.

1. It requires equal commitment from both customers and developers. One

sided commitment can be disastrous.