NEWI

Department of Computing

Computing Undergraduate Programme

Level:

Module:

Systems Analysis 3

Assignment:

2

Issue Date:

26 September 2005

Review Date:

10 February 2006

Final Submission Date:

Easter 2006

Estimated Completion time: Hours

To be completed by

Name:

Christian Manfred Wimmer

student:

Student Number

Date Submitted: 10/02/2006

Student Signature:

---

Does RAD reduce the quality of

Information Systems?

Christian Wimmer

School of Computing and Communications Technology, North East Wales Institute,

United Kingdom

1. Introduction

Few words have been more used and misused today then quality (Jansen and Ølnes

2004). Two definitions of the quality of an Informaton System (IS) are (Dahlbom and

Mathiassen, 1993, Braa and Øgrim, 1995):

· a system′s capability to satisfy needs, expectations and requests

· the proportion between expected and experienced yield of a system

It is the aim of this paper to see if RAD can meet these quality definitions and if RAD

can be used to produce high quality IS ­ or if it is really only `quick and dirty′ as some

claim.

2. RAD: one word, many meanings

Originally the acronym RAD stands for Rapid Application Development. The term

appears to have first been used by James Martin in 1991 (Avison & Fitzgerald, 2003

p 94). Nowadays RAD is used to describe a variety of things.

James Martin′s RAD (JMRAD)

: This is the original RAD methodology developed by

James Martin (Martin, 1991). This methodology is not based on the traditional life

cycle but uses an evolutionary approach.

page 2 of 8

---

Dynamic Systems Development Method (DSDM):

This methodology is non-

proprietary RAD-like approach created by the DSM consortium, a union of vendors

and users and individual associates of RAD (Beynon-Davies et al, 1999). DSDM is

being developed in the UK and provides a framework for RADish software projects.

In a way DSDM can be seen as a "grown-up" JMRAD.

Marketing RAD

: The term Rapid Application Development is often used in marketing

literature such as brochures to praise the effectiveness of the software tool in

question. Typical marketing phrases are used, promising development speed

increases of "up to 50%" (Richardson, 2005) however this tools rarely implement all

aspects for RAD and therefore the term RAD is often misused.

Therefore RAD can be categorized as two ways: A methodology, whether it is classic

JMRAD or the more modern DSDM, and a class of tools that allow `speedy′

application development (Agarwal et al, 2000).

3. RAD and quality

RAD ­ Rapid application development. That is,

developing software faster

than

normally. This alone can be seen as quality criteria. The IS is what the organisation

needs right now ­ and not in 2 years when the whole environment changed. A,

maybe unperfected, system that is exactly what is needed in 6 months can be seen

as having a certain level of quality ­ a perfect system in 3 years that fails to meet the

business needs is useless and will be seen as having low quality.

CASE tools

are often used within RAD projects. This kind of tools enables one to

create relatively good code in a fraction of the time it normally takes (Butler, 2000).

They make reuse of code easier and because the existing code has usually been

tested in real use it has a certain level of quality (Avison & Fitzgerald, 2003).

RAD relies heavily on

user involvement

whether it is in the initial JAD/JRP

workshops or in the ongoing prototyping. This ongoing process builds user

commitment and allows the system to be "closer to the user" (Jones and King, 1998).

One of the principles of DSDM is `fitness for purpose′. This term describes the user

acceptance of the IS deliverable, and this is what, from a users point of view, is what

page 3 of 8

---

quality is. In other words, quality will be built into the IS when DSDM is used as the

methodology of choice.

James Martin (1991) believes that RAD will lead to higher quality systems developed

faster and therefore cheaper than systems that use the traditional lice cycle

approach. A decade later Howard (2002) however suggests that: "For some RAD,

will always stand for "

Rough and dirty

" development ­ an excuse for sidetracking

the discipline of software engineering standards". Yourdon (2000) feels that in

nowadays projects the temptation to

skip these standards

is even greater,

particularly while developing e-business IS.

Daniels(1996) argues that RAD

ignores the long term

and only focuses

on the business functionality at that time. Reilly and Carmel (1995) found

that "most RAD projects

skip design

and rigorous methodology

altogether". Palermo (2006) also thinks this is cause for concern and

compares RAD with tobacco products: Soothing in short-term, addictive

and deadly in the long term, while causing irreparable damage along the way.

McConnelll (1996 p366) goes as far as saying that "RAD has become more of a

rallying cry for faster development than a meaningful methodology".

But is RAD really "anti-quality" (Howard, 2002) or can it be used to produce quality

systems in reality? A look at the available case RAD case studies might shine some

light on this situation.

4. RAD projects: A Classification

Beyon-Davies et al (2000) identified two different types of RAD projects which they

call highly intensive or phased respectively. In simple terms in

highly intensive

projects developers and users are "locked away" in a room for some weeks and are

expected to produce a working deliverable at the end of the time. On this type of

projects the emphasis clearly lies at the rapid part of IS development.

A

phased project

on the other hand is one that is spread over several of months (or

even years). This kind of projects is a much more classic example of projects

page 4 of 8

---

following a methodology with phases, however RAD techniques such as JAD

workshops, timeboxing and prototyping are used along with CASE tools to speed up

the development.

A different approach to classify RAD type projects is to differentiate what the

deliverable will be (Howard, 2002).

Rapid Program Development (RPD)

focuses on

implementing a given program based on a program specification as fast as possible.

Experienced Programmers are required to code nearly bug-free code under strict

time constrains. Communication with the users is hardly ever required, if at all and

therefore the interpersonal skills of the RPD staff doesn′t need to be as highly

evolved. The typical picture of a coder locked in a dark room who produces lines and

lines of code is one that can come to ones mind when looking at this kind of rapid

development.

Rapid System Development (RSD)

is a much more chaotic process than RPD.

Projects start with a set of ideas for a new or updated Information System (IS). This

ideas need to be refined to a system specifications with all the details necessary.

Extensive user involvement is required therefore developers need technical as much

as interpersonal skills. This kind of development relies heavily on a good

development team that can adapt the initial system specification and create a

working system that `adds value to the business operation′. Howard (2002) classifies

RAD as value engineering, reasoning that value is the operative word in RSD.

Case Study: BT Face

This project was conducted within the company BT and is the second iteration of a

Intranet for intra-organizational communication (Beynon-Davies et al, 2000). The

case study is especially useful as it follows the main RAD principles.

In the project a small team of users and developers where working in a remote

location, far way from their normal working place and they where expected to deliver

a working IS after 3 weeks ­ a typical intensive project. Their working environment

was what the literature calls a `clean room′ ­ places free from everyday work

equipped with supporting equipment such as flip-charts, coffee, computers and such.

One member of the team described their project as "It′s a Lot of Bits of Paper and

page 5 of 8

---

Ticks and Post-It Notes and Things" which sounds pretty chaotic therefore this

project can be classified as being Rapid System Development (RSD).

The case study doesn′t clearly state if the project produced a quality IS, however it is

noted that the team didn′t work overtime and that the project presentation at the end

of the project went well so it can be concluded that the system met the users and

management expectations. It is also interesting that the people involved in the project

said that it was the purest they ever took part in.

5. Conclusion

The material available on the quality of RAD projects is inconclusive. On the one

hand there is evidence that RAD is being successfully used with small to middle size

projects on the other hand there is a lot of material that claim RAD projects are `quick

and dirty′. In the end it probably depends on the quality of the people involved in the

project and how well RAD is being used. Looking at the case studies and the often

mentioned maximum size of a RAD team it can be said RAD is suitable for small to

middle size projects and the quality of the deliverable can be quite good. However,

except for one inconclusive case study (Berger et al, 2004), there is little evidence

that RAD can be used in big projects. Maybe project managers are just too afraid of

using a "new" methodology that is said to produce `anti-quality′ systems for mission

critical projects. If an organization isn′t ready for RAD it shouldn′t be forced upon it as

the cultural changes that go along with it are quite extensive. In the end it probably

comes down to what you expect from a systems and how far this expectations are

met. If project managers choose RAD only because it promises faster IS

development and forget about all the good practices of normal methodologies the

quality of the IS is sure to suffer.

RAD isn′t one size fits all and it clearly isn′t

the

solution of the quality problem,

however if it used like its meant to be and the people involved in the process now

what they are doing it can be used to produce quality Information Systems.

`It′s a Lot of Bits of Paper and Ticks and Post-It Notes and things... you′ll get to

understand it, it′s not that

bad

really′ (Beynon-Davies et al, 2000)

page 6 of 8

---

6. References

Agarwal Ritu, Prasad Jayesh, Tanniru Mohan and John Lynch (2002)

`Risks of Rapid Application Development′.

Communications of the ACM

, vol. 43,

Issue 11, p177

Avison, D. & Fitzgerald, G. (2003)

Information systems development:
methodologies, techniques and tools

(3rd edn) London: McGraw-Hill

Berger, H., Beynon-Davies, P. and Cleary, P. (2004)

The utility of a rapid
application development(RAD) approach for a large complex information
Systems development

[paper presented at the 13th European Conference on

Information Systems, ECIS 2004, Turku, Finland, June 14-16, 2004] University of

Wales

Beynon-Davies, P., C. Carne, et al. (1999

) `

Rapid Application Development: an

empirical review′

European Journal of Information Systems

. 8(2), 211-223.

Beynon-Davies, P., McKay, H. and Tudhope H. (2000) `It′s a Lot of Bits of Paper and

Ticks and Post-It Notes and Things: A Case Study of a rapid application development

project′

Info Systems

J(2000) 10, 195-216

Braa, K. and L. Øgrim (1995): "Critical View of the Application of the ISO Standard for

Quality Assurance", Avison & Fitzgerald (1995) Information Systems Journal

Butler, T. (2000) `Transforming information systems development through computer-

aided systems engineering (CASE): lessons from practice′

Information Systems
Journal 2000

, Volume 10, 167-194

Casemaker Inc. (2000)

What is Rapid Application Development?

[corporate

whitepaper] http://www.casemaker.com/download/products/totem/rad_wp.pdf

[Electronically accessed 30th March 2006.]

Dahlbom, B. and L. Mathiassen (1993):

Computers in Context

, Basil Blackwell

Daniels, J. (1996)

Why RAD is Bad!

Presentation to the British Computer

Society Requirements Engineering Specialist Group, July 10th 1996, Imperial

College, London. Cited by Jones and King(1998)

Howard, A. (2002) ′Rapid Application Development: Rough and Dirty or Money

Engineering?′.

Communications of the ACM

, vol. 45, no. 10, p27

Jansen, A. and Ølnes, S. (2004)

Quality Assessment and Benchmarking of
Norwegian Public Web Sites

[paper to be presented at 4th European Conference

on EGovernment, Dublin, 17-18.6.2004] Western Norway Research Institute

Sogndal,

Norway

Jeffrey Palermo (2006)

RAD kills. . . software - level 200

http://codebetter.com/blogs/jeffrey.palermo/archive/2006/02/20/138778.aspx

[Electronically accessed 31th March 2006.]

page 7 of 8

---

Jones, T. and King, SF. (1998) `Flexible systems for changing organizations:

implementing RAD′ European Journal of Information Systems (1998) 7, pp 61­73

Martin, J. (1991)

Rapid Application Development

, Prentice Hill, Eaglewood Cliffs,

New Jersey.

McConnell, S. (1996)

Rapid Developmenmt ­ Taming Wild Software Schedules

,

Microsoft Press, Redmond, Washington

Reilly, J.P. and Carmel, E. `Does RAD live up to the hype?′

IEEE Software

(Sept.

1995), vol. 12, no. 5, pp. 24-26

Richardson, Lee (2005)

Cracking the Code

[online article]

http://www.gantthead.com/article.cfm?ID=227410 [Electronically accessed 30th

March 2006.]

Yourdon, E. (2000)

Computerworld,

21. August, Vol. 34, Issue 34, 36. Cited by

Avison & Fitzgerald (2003) p99

page 8 of 8

---