Filetype PDF | Posted on 30 Jan 2023 | 3 years ago
Authentication
digital resources
335x Filetype PDF File size 0.14 MB Source: damiantgordon.com
See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/31978101
Rapid application development (RAD): An
empirical review
Article in European Journal of Information Systems · September 1999
DOI: 10.1057/palgrave.ejis.3000325 · Source: OAI
CITATIONS READS
53 4,404
4 authors, including:
Paul Beynon-Davies Hugh Mackay
Cardiff University The Open University (UK)
129 PUBLICATIONS 1,611 CITATIONS 28 PUBLICATIONS 1,056 CITATIONS
SEE PROFILE SEE PROFILE
All content following this page was uploaded by Paul Beynon-Davies on 21 November 2014.
The user has requested enhancement of the downloaded file.
European Journal of Information Systems (1999) 8, 211–223 1999 Operational Research Society Ltd. All rights reserved 0960-085X/99 $15.00
http://www.stockton-press.co.uk/ejis
Rapid application development (RAD): an empirical review
1 1 2 1
P Beynon-Davies , C Carne , H Mackay and D Tudhope
1 2
School of Computing, University of Glamorgan, Wales; Sociology Discipline, The Open University
Rapid application development (RAD) is an approach to information systems (IS) development which is
much discussed in the practitioner literature. However, there is comparatively little research data on this
topic. This paper forms a report of the results of a multi-disciplinary research project which has been
studying this development approach for the last three years. The paper discusses seven case studies of
RAD projects and compares each to issues relating to a number of RAD principles as represented in
methodologies such as the recent open standard known as dynamic systems development method. We
conclude with a discussion of a number of important questions relating to further research on RAD.
Introduction RADas method
Rapid applications development (RAD) appears to have A number of people see RAD as a complete approach
first become topical with the publication of a text by to information systems development in that it covers the
James Martin with the same title (Martin, 1992). Martin entire life cycle, from initiation through to delivery. Not
defines the key objectives of RAD as: high quality sys- surprisingly there are a number of methods available for
tems, fast development and delivery and low costs. RAD—suchas Martin and more recently in the UK, the
These objectives can be summed up in one sentence: the dynamic systems development method (DSDM). The
commercial need to deliver working business appli- DSDM consortium has produced a number of versions
cations in shorter timescales and for less investment. of a public domain RAD method (Consortium, 1995).
RADhas been much discussed in practitioner circles, This method seems particularly directed at melding stan-
but there appears to be very little academic material dard development issues such as project management,
assessing RAD. This is not suprising in the context of quality assurance and software testing with the exigenc-
a systematic survey of the existing literature on infor- ies of rapid development. The expressed aim of the con-
mation system development methodologies (ISDMs) sortium is to remove the ‘hacker’ connotations associa-
conducted by Wynekoop and Russo (Wynekoop & ted with what many people refer to as ‘first generation
Russo, 1997). They found that over half of the 123 RAD’.
research papers examined consisted of normative DSDM can be characterised as an ISDM in that it
research in which concept development was not based provides elements in each of the five areas used to define
on any empirical grounding or theoretical analysis, but an ISDM (Avison & Fitzgerald, 1995):
merely on the authors’ speculations and opinions. Of (1) Model of the development process: DSDM utilises
those which constituted empirical research, almost half an iterative or incremental model of the development
were undertaken to evaluate ISDMs or parts of ISDMs.
Few studies were undertaken to identify how ISDMs are process. This model defines four key phases with
selected or adapted or how they are used. There also iteration both within and between phases.
appears to be little interpretive research and few practice (2) Set of techniques: DSDM emphasises some new
descriptions or case studies of this phenomenon. development techniques such as joint requirements
The main aims of this paper are to address some of planning workshops, joint application design work-
these limitations in terms of one particular ISDM. The shops and time boxing but generally adopts tra-
paper provides a review of the practitioner material on ditional techniques such as entity-relationship dia-
RADandassembles from this material a number of key grams etc. in a contingent way.
features of the RAD approach. It then discusses a num- (3) Documentation method: The method expresses a
ber of case studies of RAD projects and compares each loose set of suggested documentation approaches.
to issues relating to the key principles of RAD as rep- The method generally expects that documentation is
resented in the ISDM Dynamic Systems Development kept to a minimum within IS projects.
Method. We conclude with a discussion of a number (4) Fit between documentation method and techniques:
of important questions relating to further research work Some indication is provided in the DSDM manual
on RAD. of how various techniques and documentation stan-
212 RAD: an empirical review P Beynon-Davies et al
dards can be contingently used in relation to a pro- that no more than six man-years of development effort
ject. should be devoted to any particular RAD project. For
(5) Philosophy: DSDM utilises a standard philosophy example, British Rail (Anonymous, 1996b) conducted a
founded in rational business oriented performance. RAD project on a mixed Oracle/Cobol system for rec-
Unusually for an ISDM, there is also some acknowl- ording time and attendance of staff. It is claimed to have
edgement of cultural issues and organizational learn- completed the project in four months rather than the
ing within its description of the method. expected twelve months.
Stapleton, in her recent book on DSDM (Stapleton,
1997), includes a number of descriptions of projects Clean rooms
taken from the DSDM Consortium’s Early Adopters pro- JADworkshops are usually expected to take place away
gramme. For instance, Scottish National Heritage used from the business and developer environments in ‘clean’
DSDMtooverhaul its administrative systems. In a simi- rooms—thatis, places free from everyday work interrup-
lar manner, Irish Permanent used RAD techniques such tions and full of requisite support facilities such as flip
as joint application design workshops, timeboxing and charts, post-its, coffee, computers etc. The emphasis is
wash-up sessions to build a system to enable branches on highly focused problem solving.
to process loan applications. Sema group built a new
administrative system for the British Midland frequent Time boxing
flyer programme using a RAD approach. Finally, the UK Project control in RAD is seen to involve scoping the
mobile phone operator, Orange, utilised DSDM in a pilot project by prioritising development and defining delivery
to upgrade the functionality of the company’s system for deadlines or ‘timeboxes’. If projects start to slip, the
handling credit card payments. emphasis in RAD projects is on reducing the require-
ments to fit the timebox, not in increasing the deadline.
Components Figure 1 illustrates the relationship between the use of
The following appear to be the common components of timeboxes and the review of development products by
RAD approaches discussed in the literature: teams of users. For instance, the UK Football Associ-
ation (Anonymous, 1996a) developed three inter-linked
Joint application design (JAD) information systems for support of the Euro ‘96 football
RAD seems to be characterised by small development championship in three very short timeboxes: an infor-
teams of typically four to eight persons. Such teams are mation system which stored historical and current infor-
made up of both developers and users who are empow- mation pertaining to the championship for casual users;
ered to make design decisions. This means that all RAD an operational management system to provide
team members must be skilled both socially and in terms accreditation and media ticketing, VIP management, vol-
of the business. Users must possess detailed knowledge unteer management and materials management; the
of the application area; developers must be skilled in the results service which provided information for broad-
use of advanced tools. Hence, ‘team-building’ activities casters of the events. A hybrid system incorporating PCs,
such as team dinners are seen as an important part of a Windows 95, NT, SQL Server and Visual Basic was
RADproject. Most approaches to RAD seem to use joint developed in a matter of a few months.
application development (JAD) workshops at various
points in the development process, particularly to elicit Incremental prototyping
requirements. In such workshops, key users, the client, RADisfrequentlydiscussed in terms of incremental pro-
some developers and a ‘scribe’ produce system scope totyping and phased deliverables. Prototyping is essen-
and business requirements under the direction of a ‘facil- tially the process of building a system in an iterative
itator’. Development teams are usually expected to come way. The developers, after some initial investigation,
up with fully documented business requirements in three construct a working model that they demonstrate to a
to five days. Such requirements may specify a series of representative user group. The developers and the users
phased deliverables over a given time-span. Further then discuss the prototype, agreeing on enhancements
development workshops may be scheduled during the and amendments. This cycle of inspection-discussion-
life of a project to develop jointly each deliverable. amendment is usually repeated at least three times in
RADprojects, until the user is satisfied with the system.
Rapidity of development In RAD, prototyping may be used at any stage of devel-
RAD projects seem to be typically of relatively small- opment: requirements gathering; application design;
scale and of short duration. Also, two to six months is application build; testing; delivery.
frequently discussed as being a normal project length.
The main rationale being that any project taking more Rapid development tools
than six months to complete is likely to be overtaken by It is not surprising to find that modern approaches to
business developments. In total, it has been suggested RADdemandgoodsupportfromtoolsforrapiddevelop-
RAD: an empirical review P Beynon-Davies et al 213
Figure 1 Timeboxes and user reviews.
mental change. This normally means some combination three incremental prototypes. The aim is to continually
of fourth generation languages (4 gls), graphical user refine the prototype into something that is deliverable at
interface (GUI) builders, database management systems the end of timebox.
(DBMS) and computer-aided software engineering
(CASE) tools. Using such tools some changes to proto-
types can be made in situ at user-developer meetings. Dynamic systems development method
Kerr and Hunter (1994), for instance, describe an early (DSDM)
RADproject which utilised Martin’s RAD methodology Dynamic systems development method (DSDM) is a
in the development of a financial system for a US bank. non-proprietary RAD method produced by the DSDM
The book describes the heavy utilisation of CASE tech- consortium, a non-profit-making organization of ven-
nology on this project, as well as a number of interesting dors, users and individual associates of RAD. In
issues such as developer burnout. December1995, the consortium had almost 100 member
Highly interactive, low complexity projects companies (Stapleton, 1997). Its intention is to become
Most RAD projects seem to be conducted on appli- the UK and international standard for RAD work. Many
cations that are highly interactive, have a clearly defined vendors of application development tools are committed
user group and are not computationally complex. For to it and many companies have now adopted it as their
example, the UK financial company, Norwich Union preferred ISDM for RAD projects.
(Anonymous, 1996c), produced an electronic trading
system originally for the motor insurance sector of the DSDM principles
business using an in-house RAD approach. It apparently TheDSDMConsortiummaintainitisbased onnine fun-
took the development team only three months to convert damental principles:
this system for the household sector. (1) Active user involvement is imperative: DSDM sees
The tendency is to rule out the applicability of RAD itself as a user-centred approach. Active involve-
for large-scale, infrastructure projects, particularly the ment by the user community throughout the devel-
construction of large, distributed information systems opment project is therefore seen as crucial.
such as corporate-wide databases. Evidence suggests that (2) DSDM teams must be empowered to make
such infrastructure is best put in place before undertak- decisions: DSDM project teams consist of both
ing RAD projects. Such an infrastructure can then act as developers and users. Both groups must be given the
a feeder to systems developed using RAD. This is per- power to make key decisions. The developers need
haps not surprising when one considers that most RAD to be able to rapidly decide on technical solutions.
tools work off a database in some way. Therefore, the The business users need to be able to decide upon
database needs to be created before application develop- key requirements for the application.
ment begins. (3) The focus is on frequent delivery of products: The
work of a DSDM project is focused on application
Types of RAD project products that can be delivered within agreed periods
There generally appear to be two types of RAD project: of time. This enables the project team to define
the intensive and the phased RAD project. In the highly quickly the optimal approach to achieving the pro-
intensive type of project, a team of developers and users ducts required in the time available.
are closeted away in a clean room for some weeks, and (4) Fitness for business purpose is the essential criterion
are expected to produce a working deliverable at the end for acceptance of deliverables: The focus of a
of that time. A phased project is one spread over a num- DSDMprojectisindelivering business functionality
ber of months. Such projects are normally initiated by a in the required time. This means that a system may
JAD or joint requirements planning (JRP) workshop. be rigorously engineered later if this is felt fit.
The subsequent phases of the project are then normally Traditionally, the focus has been on rigorously
organised in terms of the delivery and demonstration of engineering systems to satisfy a requirements docu-
no reviews yet
Please Login to review.
