Interpretation of RAD

When it comes to the customisation of development methodologies, RAD is an interesting case in point. RAD is a prototype-based approach covering the analysis, design and development of computer-based information systems. In many ways it shares

the characteristics of the methodological framework used by traditional structured approaches, having:

• a core set of recognised tools and techniques;

• a framework within which the outputs of tools and techniques can be co-ordinated; • a mechanism by which the progress of a project can be evaluated.

The main difference between RAD and traditional approaches is a much looser methodological framework. Evolutionary and iterative development is encouraged; the emphasis is clearly a process rather than product-centred approach to development. The mechanisms for managing and evaluating RAD projects are also clearly different. The time to carry out a task is the prime criterion in planning and managing a RAD project. Quality assurance tasks have to be focused on the criterion of usability alone (Herzlich,1994) - often because of the lack of other evaluation sources given that design documentation is often kept to a bare minimum. Because of these characteristics, RAD projects are very much influenced by the characteristics of the development context.

Proponents of RAD are quick to advertise its advantages: evidence of the success of RAD projects litters the pages of professional publications in the software development arena. A number of projects, almost exclusively concerned with small-scale information systems, have been put forward as RAD successes and tentative heuristics have often been put forward as evidence of the success of the approach and the huge leaps in programmer productivity that it encourages:

" System developer productivity on RAD projects, as measured on hundreds o f projects, exceeds productivity on traditionally managed projects by a factor o f 10

to 25. "p.3 (Kerr & Hunter, 1994).

Critics of RAD have been quick to draw on what they see as methodological short­ comings In particular, the manner in which quality is addressed within a RAD framework has come in for attention. Criticism of the validity of informal user tests as an indicator of quality have been raised:

''On a RAD project, prototypes are assessed by demonstrating the prototype to a user and then taking that user's reactions as a cue for modifications. In this way Theory and Practice o f System Development Methodologies: A Conceptual Framework 118

the user's wants and preferences are built into the design. Unfortunately, this rather haphazard process has little objectivity. The elements o f a successful assessment are realism and measurement against targets'^ p. 153 (Browne, 1994) The quality dimension is an important focus for argument. RAD proponents defend the approach by pointing out that 'fitness for purpose' and a focus on what ultimately benefits users should be seen as the prime criterion in considerations of quality (Herzlich, 1994), and concerns about the objectivity of the testing process are therefore less of a concern. Rather than robust metrics for determining quality, the considerably less objective measure of the "smile on the user's face" (Kerr & Hunter, 1994) should be a consideration if a RAD project is to succeed. Taking such an approach can undoubtedly reduce the amount of time spent on verification and validation and is essential if time constraints are to be met, even if they produce potential compromises in the long-term quality and re-usability of portions of system functionality (Herzlich, 1994).

Other concerns have been raised about the manner in which the quality of the underlying system model is assessed. RAD depends on small teams of experienced developers to carry out implementation work. The belief here is that small teams are more productive, partly because they are working on smaller problems, but primarily because individuals in small teams have a more complete model of the project and are less reliant on seeking clarification for their actions from senior members of the project or on formal documentation and communication (Chudge & Fulton, 1996). As the focus for development effort moves from the integrity of the design model to ensuring quick delivery, the effort spent on producing design documentation is reduced, in some cases to the point where the prototype itself becomes the design model (Bowen, 1994). As the granularity and scope of design documentation and other (written) products of development are reduced, then the ability of management and quality assurance representatives to validate changes to the design or implementation are curtailed. The alterations in work-practice that such changes demand can often cause problems, particularly if they go against accepted organisational norms:

" So basically what started out as something reasonably controlled in terms o f requirements analysis and the requirements spec, degenerated through pressure and misunderstanding to a point where basically people were ringing up, saying T want it to do this and I want it to do that' and 'we didn't mean it to do this, what we mean is that it should do that' and obviously there is no control, no path we Theory and Practice o f System Development Methodologies: A Conceptual Framework 119

can trace things back from, and that explains how the project ended up in its final stages. It was totally user driven. I have heard the phrase 'participative design' with people coming in with articles trying to justify that, but I'm not entirely sure i f I agree with it or not. Certainly the user got what they wanted. But they were putting changes into the system less than a week before it was committed to this hard media.... You need a happy medium, you need some way o f controlling requests. Yes, we went to one extreme...." Software Engineer in a large financial house. Extract from the PROTEUS project (Fulton, 1993)^.

It is in this regard that RAD becomes a bitter pill to swallow for some organisations that develop information systems. The manner in which work is carried out largely bypasses the structures of inquiry and decision-making that are typical of modem system development projects. RAD projects are seen to require intense communication on a peer-to-peer basis. Such a need fits poorly with the hierarchical nature of most communication on system development projects, with their elaborate and time- consuming overlays of approval and validation entities and procedures. Structures within an organisation using RAD need to be sufficiently fluid in order to support the RAD process.

Traditional management structures are not the only victim of the adoption of RAD. The manner in which processes are carried out within an organisation are also affected. Company procedure documents and quality standards are difficult to interpret within a structure where the speed of development is prioritised and the breadth, depth and quality of project-related documentation is relegated to a supporting role. The impact of RAD has to be considered in the manner in which the structures and processes of the organisational context are affected by its adoption.

Other criticisms of RAD have concentrated less on the ‘customer-driven’ lack of objectivity in design evaluation and more on the stmctural integrity of the RAD methodology. ‘Putting rigor back into RAD’ (Editorial, Database Programming & Design, 1994) is a call being taken up by some interested parties, critical of the loose structure of the RAD approach. In many ways, this echoes earlier reservations about prototypical approaches (e.g. Ince(1991)). The wide degree of variation in interpretations of RAD by practitioners has led to the formation of the dynamic systems development method (DSDM) consortium. DSDM was formed in part as a reaction to the increase of ^Extract from Fulton, D. (1993) Positions, Procedures and Practice - Requirements Change in British Industry, Unpublished MSc Thesis, Loughborough University of Technology.

interest in the RAD approach and the confusion about how frameworks for RAD can be implemented. The aim of the DSDM consortium is to produce a generic framework for a RAD method in order to produce a de-facto standard for RAD development (DSDM consortium, 1995). In doing this, the DSDM consortium hope that some of the uncertainties concerning the implementation of RAD can be reduced.

Resistance to change takes many forms and, in a number of cases, has led to the revision or abandonment of approaches which over time have failed to adapt to the restrictions present within a particular organisational context. There are a number of forms of resistance:

• Manager's right to manage: Rejection by authority figures within an organisational group who see their influence eroded (Hirschheim, 1989);

• A failure to maintain structures for ensuring creativity (Poltrock & Grudin, 1994); • Lip-service paid to the use of novel concepts (Hornby & Clegg, 1992);

• Poor fit with quality assurance procedures (Herzlich, 1994);

• Insufficient resources being made available to fulfil project goals (Stone, 1994).

When resistance occurs, the available options involve fitting the organisational context to the needs of the approach or fitting the approach to the needs of the organisational context. The former requires long-term training and education, whilst the latter requires reductions in the ambition for change.

" The further systems' designers move....

to plan fo r the possible social, cultural and organizational impact o f these technologies, the more tentative and incomplete relevant theories and techniques inevitably prove to be. "p. 182 (Blacker, 1991)

The increasing adoption of RAD within sections of the software development community has led to a wide variation in the manner in which RAD is practised. Poor fit with organisational context is not the only possible interpretation of such an event; the fashionable status of the RAD approach within industry has led to a number of vendors rebadging existing tool products as 'RAD-ready' and a corresponding number of practitioners identifying the existing work that they carry out, particularly if they are using prototypes, as RAD projects. The result is confusion about whether RAD is a tool Theory and Practice o f System Development Methodologies: A Conceptual Framework 121

characteristic, a characteristic o f an approach, or a stand-alone systems development methodology. This can be explained, in part, by the existing texts on the RAD approach being superfluous: up to this point in time the benefits of the approach are still being highlighted and, although guidance is given on implementing RAD within an organisation - usually based on the results of spectacular successes reported in individual case studies - that guidance is at a suitably high-level to ensure that interpretation often depends on the individual.

6,2.4 Process of Analysis

The process of analysis consisted of three steps:

• Identification of suitable case study subjects; • The Interview process;

• and. Analysis of case study material.

In order to gather credible data, it was important to define in advance the criteria by which organisations and individuals were selected. The main criteria used for selecting organisations was based on the level of experience an organisation had with RAD. If an organisation explicitly labelled its projects as RAD projects and had carried out more than one RAD project, it was considered to be a suitable source of research subjects. The section of individuals within organisations required similar criteria. Individuals could be selected by the contributing organisation, but the roles they carried out on a RAD project did not have to be limited to development roles - the only restriction in that regard being that they had to work within a main project grouping. They were also expected to have been involved with and completed at least one RAD project.

In all, ten subjects were interviewed. With the exception of the water quality management system"*, there was one interviewee per project. The interview process used visual indexing as a guide, and concentrated, initially, on requirements change processes within projects, in order to start with a scenario which could be expanded as the

The findings of which are summarised in Table 6.2b.

interview progressed^ Each interview took between 1 to 2 V2 hours to complete.

Interviews were followed by group review meetings, in which each of the contributors to the research could get together and discuss outcomes, largely by reviewing and discussing visual indexing models generated in each interview. Although there was no formal agenda for these meetings, initial attempts at some of the categorisations in section 6.6 were developed, in particular the categorisation outlined in Figure 6.4.

The main product of the interview process was a taped transcript of each interview. The interview transcripts were analysed according to similar criteria to those used for analysing case study material, namely that the focus was on identifying areas where decisions, events or restrictions had an impact on the development process. More than 300 statements were identified, all of which were initially grouped under the same entities (or categorisations) as used for the research in chapter 5. The high number of statements identified required that the development of category labels had to be expanded. The following criteria were used in developing note definitions:

• Identifying groupings of statements that reflected the internal nature of an entity; • Identifying groupings of statements that reflected the relationships between entities; • Identifying groupings of statements that reflected changes in the characteristics of an

entity as a response to determinants.

This data was transformed into the conclusions reported in section 6.3 in two ways. The first was that in building relationships between entities, care was taken to avoid forcing a note definition to be defined as a determinant. Whilst some note definitions fitted well into the expanded model^, others described the internal behaviours of entities or referenced the possible workings of determinants, neither of which were represented on the graphical model at this stage^. The other use of the data was in guiding the development of a categorisation layer, whereby the internal nature of entities could be described at a coarse level of detail. This process worked by verification or exploration. In the case of the former, the data could be used to check whether the basic principles of existing models that could be used to describe the workings of entities, were applicable. ® As outlined in Figure 4.3.

^ Card 4, the Impact of Development Paradigm on Strategy being an example (see Appendix C).

^ Although some of these were later added after the survey results were analysed and the model expanded.

In the case of the latter, the data could be used in order to draw comparisons between projects and describe what later became categorisations. The differences in the initial approaches of projects that started with explicit requirements and those which started with none at all helped in the development of the categorisation of the initial statement o f objectives entity.