Does Rapid Application Development reduce the quality of Information Systems?

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.

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 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”.

Abbildung in dieser Leseprobe nicht enthalten

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 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.