IS2201/IS2261 – Information Systems Development
1 Rapid Application Development
This lecture will explain what Rapid Application Development (RAD), and aims to
help you better understand how to apply RAD to systems development. You should
also understand when best to apply RAD approaches to software development, and
under what circumstances it is inappropriate.
1.1 Introduction
The concept of RAD was first introduced by James Martin in his book Rapid
Application Development (Martin, 1991). It can be described as “a set of tactics and
techniques to minimize development time” (Miller, 2005). It is expected that 80% of
the functionality of a system can be delivered in 20% of the development time (Miller,
2005), (Avison and Fitzgerald, 2003).
Some early research made claims of very high productivity improvements due to the
application of RAD (see Miller, 2005), which focused on the programming phase of
development. These claims are no longer made, but the reason for this is not clear.
This original approach to RAD (JM-RAD) has been characterized as having the
following properties (Avison and Fitzgerald, 2003):

It is based on an evolutionary/prototyping approach rather than the traditional
SDLC.

It identifies key users and involves them in the early stages of development.

It focuses on obtaining commitment from the business users.

It requires CASE tools and a “sophisticated” repository.
1.2 JM-RAD
RAD was introduced as part of a more general systems development approach
called Information Engineering.
There are four phases in development using JM-RAD
1. Requirements Planning
Gather the high level requirements of the system at the strategic level. This
phase Uses JRP (Joint Requirements Planning) workshops.
2. User Design
Generate some initial designs of the system using prototyping methods. This
is carried out with the users of the system in JAD workshops.
3. Construction
Construction is based on more formal systems development, but is carried
out by SWAT teams (Skilled With Advanced Tools). The idea is that small
teams will have less of a communication overhead and therefore be quicker.
4. Cutover
This stage involves implementation on the target systems or with realistic
data. Training of users and organisational changes are implemented.
Parallel running is often used during this phase until the new system has
proved itself.
©
K. Miller & M. Stanton
Page 1 of 6
IS2201/IS2261 – Information Systems Development
Note: There is no Feasibility phase. With JM-RAD it is assumed that this has already
been carried out during “Business Systems Planning” (a method for the development
of strategic business information systems). Therefore with JM-RAD it is assumed
that all projects have been deemed as feasible and desirable.
1.3 The Dynamic Systems Development Method (DSDM)
DSDM “provides a framework for building and maintaining systems which meet tight
time constraints through the use of incremental prototyping in a controlled project
environment” (DSDM Consortium).
DSDM is therefore a “framework” for RAD.
Figure 1 - DSDM
Framework
Phase 1
Feasibility
Phase 2
Business
Study
Implement
Agree Schedule
Create
Functional
Prototype
Functional
Model
Identify
Functional
Prototype
Review
Business
Train Users
Implement
User Approval
Guidelines
Review Prototype
Phase 4
Phase 3
Identify Design
Prototype
Phase 5
Design
and Build
Agree
Schedule
Review Design
Prototype
Create Design
Prototype
According to Miller (2005), there are 9 guiding principles:

Active user involvement is imperative

Teams must be empowered to make decisions

The focus is on frequent delivery of products rather than the way they are
produced

Every deliverable must be fit for its business purpose

Iterative and incremental development are powerful ways to develop systems

All changes must be reversible

High level requirements are baselined

Testing is integrated throughout the SDLC

A collaborative and co-operative approach between stakeholders is essential
1.4 The DSDM Framework
The DSDM framework defines the general structure of a DSDM project. DSDM is not
intended to be prescriptive (the RUP and traditional SDLC are not prescriptive, but
approaches like SSADM are).
©
K. Miller & M. Stanton
Page 2 of 6
IS2201/IS2261 – Information Systems Development
There are 5 Phases in a DSDM project (shown in Figure 1):
1. Feasibility Study
2. Business Study
3. Functional Model Iteration
4. Design and build Iteration
5. Implementation
Each of phases 3, 4 and 5 are iterative and they may also be carried out
simultaneously for different parts of the system under development.
1.4.1 Feasibility Study
As usual the feasibility study is a quick, short study, probably including a cost/benefit
analysis of the project.
Part of purpose of the feasibility study is to establish if DSDM is an appropriate
development framework for the system in question. Sometimes it is required that all
parts of the system are delivered simultaneously – in which case DSDM is
inappropriate. It is suggested that DSDM is not suited to Real-time applications:
“Its main target is interactive business systems where functionality is clearly
visible at the user interface. DSDM is not recommended for real-time
applications or for computationally complex systems.”
(Howard, 1997)
Also the amount of expertise the team has with DSDM can be a deciding factor
(Avison and Fitzgerald, 2003).
1.4.2 Business Study
In the business study phase, the business functions of the systems are scoped and
prioritised. This phase is intended to be carried out quickly, and Joint Application
Development (JAD) is often used to facilitate this.
The results of this phase are:

A more detailed plan of the project including time scales and deliverables

A more complete definition of the scope if the systems development activity to
come
For the latter, Avison and Fitzgerald (2003) suggest that this can be documented
using DFDs and ERDs, but Use Cases and initial UML Class Diagrams are likely to
be produced more quickly, and support prioritisation more effectively.
1.4.3 Functional Model Iteration
In this iterative phase, the designs are implemented and refined using evolutionary
prototyping. Since there are risks associated with evolutionary prototyping, a large
amount of testing is also required during this phase.
Miller (2005) suggests that this phase should concentrate on the user interface. This
again shows where Use Cases can be used to good effect, although a similar
emphasis can be put on DFD’s. More detailed interactions can be captured using
Interactions Diagrams and these will also provide details of the user interface
requirements of business processes.
©
K. Miller & M. Stanton
Page 3 of 6
IS2201/IS2261 – Information Systems Development
1.4.4 Design and Build Iteration
The system is prepared for delivery. A “minimum usable subset” of requirements
must be delivered (Avison and Fitzgerald, 2003). In other words, each delivery will
provide a fully functional, but possibly incomplete system (See Section 1.3).
1.4.5 Implementation
This is a standard cutover phase, similar to that of JM-RAD. One interesting point to
note here is that documentation is completed during this phase, but this is usually
done by the users, not the developers (Avison and Fitzgerald, 2003).
1.5 Tools and Techniques
1.5.1 Prioritising Development
In many Development Methods, there is a requirement for prioritising increments
(units of development). Prioritisation is part of the RUP, and of DSDM.
One approach to Prioritisation is using MOSCOW:
Must haves – fundamental to the success of the delivered product
Should haves – important but not fundamental to project success
Could haves – could be left out without serious impact on the project
Won’t haves – can be left out of the current iteration and possibly considered later
A practical example of requirements prioritisation process is given by “important
projects.com” (http://importantprojects.com/archives/000071.php).
Other approaches to prioritisation range from considering risks (high-medium-low) to
statistical techniques such as:

Quality Function Deployment (QFD) (http://www.qfdi.org)

Analytical Hierarchy Process (AHP) (http://www.qfdi.org/tut_ahp.htm).
These statistical approaches are useful when it is not easy to distinguish, for
example, between a “Should have” and a “Could have” using MOSCOW.
1.5.2 Joint Application Development
1.5.3 Timeboxing
©
K. Miller & M. Stanton
Page 4 of 6
IS2201/IS2261 – Information Systems Development
2 Questions
1.
Name the Phases of the Dynamic System Development Method, and identify
which phase would incorporate prototyping.
2. Discuss the role of the feasibility study in DSDM. How does it compare to the
role of a feasibility study in JM-RAD.
3. Explain why DSDM can be considered both an incremental approach and in
iterative approach to systems development.
4. Which UML techniques are likely to be most useful in the Business Study
Phase of DSDM?
©
K. Miller & M. Stanton
Page 5 of 6
IS2201/IS2261 – Information Systems Development
3 References
J. Martin, Rapid Application Development, Prentice Hall, 1991
D. Avison and Fitzgerald, G., Information Systems Development (3rd Edition),
McGraw Hill, 2003
K. Miller, “Rapid Application Development” In: Information Systems Development
Lecture Notes, DOCM, 2005
DSDM Consortium (http://www.dsdm.org/ )
A. Howard, “A new RAD-based approach to commercial information systems
development: the dynamic system development method” In: Industrial Management
& Data Systems 97/5, 1997. pp175–177
©
K. Miller & M. Stanton
Page 6 of 6