Advantages and Disadvantages of Rapid Application Development (RAD)

Advantages of RAD Software Development
  • The time required to develop the software is drastically reduced due to a reduced requirement analysis business requirements documentation and software requirement specification) and planning stage.
  • All the software prototypes produced can be kept in a repository for future use. The re-usability of the components also enhances the speediness of the process of software development.
  • It is much easier for a project manager to be accurate in estimating project costs which of course means that project cost controls are easier to implement and manage as well.
  • It is a big cost saver in terms of project budget as well as project time and cost due to re-usability of the prototypes.
  • If a component is being picked for the repository, it is already tested and hence need not be tested again. This helps in saving time required for testing.
  • The project management requirements are collected in a dynamic manner. Every time there is a prototype ready, requirements are studied and matched. If there are any additional requirements, these are then included in the next prototype built.
  • There is a strong and continuous participation of the project sponsor who keeps giving feedback in the whole process. Hence the end user satisfaction level is higher when the end result is produced.
  • It promotes better documentation through written test cases.
Disadvantages of RAD Software Development
  • This method may not be useful for large, unique or highly complex projects
  • This method cannot be a success if the team is not sufficiently motivated and nor is unable to work cohesively together.
  • Success depends on the extremely high technical skills of the developers.
  • There are times when the team ignores necessary quality parameters such as consistency, reliability and standardization. Hence this can make project quality management hard to implement during the project management life cycle

Source

General Characteristics of Rapid Application Development (RAD)

Rapid Application Development Methodology

Incremental development

An important element of the philosophy of RAD is the belief that not all a system’s requirements can necessarily be identified and specified in advance. Some requirements will only emerge when the users see and experience the system in use, others may not emerge even then, particularly complex ones. Requirements are also never seen as complete but evolve and change over time with changing circumstances . Therefore, trying fully to specify a system completely in advance is not only a waste of time but often impossible. So why attempt to do it? RAD starts with a high-level, rather imprecise list of requirements, which are refined and changed during the process, typically using toolsets . RAD identifies the easy, obvious requirements and, in conjunction with the 80/20 rule , just uses these as the starting point for a development, recognizing that future iterations and timeboxes (see below) will be able to handle the evolving requirements over time. Hough (1993) suggests using the technique of functional decomposition and each function identified and the requirements listed, but, he says,

the precise design specifications, technical issues, and other concerns should be deferred until the function is actually to be developed

Time-boxing

The system to be developed is divided up into a number of components or timeboxes that are developed separately. The most important requirements, and those with the largest potential benefit, are developed first and delivered as quickly as possible in the first time box. Some argue that no single component should take more than 90 days to develop, while others suggest a maximum of six months. Whichever timebox period is chosen, the point is that it is quick compared with the more traditional systems development timescale.

Systems development is sometimes argued to have three key elements. In tradi- tional development two are typically variable: time and resources (see Figure 6.3). In traditional development when projects are in difficulty, either the delivery time is extended or more resources are allocated or both but the functionality is treated as fixed. In RAD the opposite applies, resources and time are regarded as fixed (allocating more resources is viewed as counterproductive although this does sometimes happen), and so that only leaves functionality as a variable. So, under pressure and when projects are in difficulty, time and resources remain constant but the functionality is reduced.

Traditional development -time and resources

Figure 1.1: Traditional development -time and resources

RAD compartmentalizes the development and delivers quickly and often. This provides the business and the users with a quick, but it is hoped, useful part of the system in a refreshingly short timescale. The system at this stage is probably quite limited in relation to the total requirements, but at least something has been delivered. This rapid delivery of the most important requirements also helps to build credibility and enthusiasm from the users and the business. Often for the first time they experience a system that is delivered on time. This is radically different from the conventional delivery mode of most methodologies which is a long development period of often two to three years followed by the implementation of the complete system. The benefits of RAD development is that users trade off unnecessary (or at least initially unnecessary) requirements and wish lists (i.e. features that it would be ‘nice to have’ in an ideal world) for speed of development. This also has the benefit that, if requirements change over time, the total system has not been completed and each timebox can accommodate the changes that become necessary as requirements change and evolve during the previous timebox. It also has the advantage that the users become experienced with using and working with the system and learn what they really require from the early features that are implemented.

Comparison of timebox development and traditional development

Figure 1.2: Comparison of timebox development and traditional development

Figure 1.2 illustrates three chunks of development and, although the overall time to achieve the full implementation could be the same as with a .traditional development, the likelihood is that the system actually developed at the end of the three timeboxes will be radically different from that developed at the end of one large chunk as a result of the learning and evolving processes which leads to change being made to each specification at the beginning of each timebox.

Some RAD proponents argue that, if the system cannot be divided into 90 day timeboxes, then it should not be undertaken at all. Obviously such an approach requires a radically different development culture from that required for traditional or formalized methodologies. The focus is on speed of delivery, the identification of the absolutely essential requirements, implementation as a learning vehicle, and the expectation that the requirements will change in the next timebox. Clearly such radical changes are unlikely to be achieved using conventional techniques.

Once the duration of the timebox has been decided it is imperative that the system is delivered at the end of it without slippage, as timeboxes are fixed. So how is this achieved? Well, first, by hard work and long hours and, secondly, by the use of the other RAD techniques discussed below. But also if slippage is experienced during development of a timebox then the requirements are reduced still further (i.e. some of the things that the system was going to do will be jettisoned).

The Pareto principle

This is essentially the 80/20 rule and is thought to apply to requirements. The belief of RAD proponents is that around 80 per cent of a systems’ functionality can be delivered with around 20 per cent of the effort needed to complete 100 per cent of the requirements. This means that it is the last, and probably most complex, 20 per cent of requirements that take most of the effort and time. Thus why do it? – just choose as much of the 80 per cent to deliver as possible in the timebox, or at least the first timebox. The rest, if it proves necessary, can be delivered in subsequent time boxes.

MoSCoW rules

In RAD the requirements of a project are prioritized using what is termed the MoSCoW Rules:

  •  M = ‘the Must Haves’. Without these features the project is not viable (i.e. these are the minimum critical success factors fundamental to the project’s success).
  • S = ‘the Should Haves’. To gain maximum benefit these features will be delivered but the project’s success does not rely on them.
  • C = ‘the Could Haves’. If time and resources allow these features will be delivered but they can easily be left out without impacting on the project.
  • W = ‘the Won’t Haves’. These features will not be delivered. They can be left out and possibly, although not necessarily, be done in a later timebox.

The MoSCoW rules ensure that a critical examination is made of requirements and that no ‘wish lists’ are made by users. All requirements have to be justified and categorized. Normally in a timebox all the ‘must haves’ and at least some of the ‘should haves’ and a few of the ‘could haves’ would be included. Of course, as has been mentioned, under pressure during the development the ‘could haves’ may well be dropped and even possibly the ‘should haves’ as well.

JAD workshops

RAD requires high levels of participation from all stakeholders in a project as a point of principle and achieves this partly through the JAD workshop. JAD (Joint Application Development) is a facilitated meeting designed to overcome the problems of traditional requirements gathering (see Section 16.2), in particular interviewing users. It overcomes the long time that the cycle of interviews take by getting all the relevant people together in a short period to hammer out decisions. Normally in the context of RAD, a JAD workshop will occur early on in the development processto help establish and agree the initial requirements, the length of the timebox, what should be included and what excluded from the timebox, and most importantly to manage expectations and gain commitment from the stakeholders. Sometimes a subsequent JAD workshop is used to firm up on the details of the initial requirements, etc. In some RAD approaches the whole process is driven by a series of JAD meetings that occur throughout the timebox.

The fourth element is the presence of an executive sponsor. This is the person who wants the system (or whatever the focus of the meeting is), is committed to achieving it and is prepared to fund it. This person is usually a senior executive who understands and believes in the JAD approach and who can overcome the bureaucracy and politics that tend to get in the way of fast decision making that usually bedevils traditional meetings

Prototyping

Prototyping is an important part of RAD and is used to help establish the user requirements and in some cases the prototype evolves to become the system itself. Prototyping ;helps speed up the process of eliciting requirements, and speed is obviously important in RAD, but it also fits the RAD view of evolving requirements and users not knowing exactly what they want until they see or experience the system. Obviously the prototype is very helpful in this respect.

Sponsor and Champion

Having a committed sponsor and a champion of the systems is an important requirement for RAD and for its success. We have discussed the sponsor above. A champion is someone, often at a lower level of seniority, who is also committed to the project, who understands and believes in RAD, and is prepared to drive the project forward and overcome some of the bureaucracy and politics.

Toolsets

RAD usually adopts, although not necessarily, the use of toolsets to help speed up the process and improve productivity. In general it is usually argued that the routine and time-consurning tasks can be automated as well as using available tools for change control, configuration management, and even code reuse. Reuse of code is another way that RAD speeds the development process. However, it is not just about speed but also quality because existing code or modules have usually already been well tested, not just in development, but in real use. RAD searches for shortcuts and reuses code, maybe clones existing code and modifies it, or utilizes commercial packages, etc. where applicable. This may be code within the organization or bought from outside. Sometimes more than just a little piece of code is used; for example, complete applications may be used and the developers use this as the basis of the new system and change the interface to produce the desired results. Many ‘new’  e-commerce or Internet applications have been developed in this way using the legacy systems and then providing a new ‘umbrella’ set of applications and user interfaces on top. The idea is to leverage existing code, systems, experience, etc.

Specific RAD productivity tools have been around for some time and are developing fast, and existing tools and languages are being enhanced for RAD, particularly for rapid development of Internet and e-business based applications.

Source

  • David Avison & Guy Fitzgerald, 2006. Rapid application development (RAD). In David Avison & Guy Fitzgerald Information Systems Development. 4th ed. Pearson Education Limitied. Ch. 7. pp.128-132.ISBN-13 978-0-07-711417-6

Rapid Application Development Methodology

A method of developing information systems which users prototyping to achieve user involvement and faster development compared to traditional methodologies such as SSADM.
Professor Clifford Kettemborough of Whitehead College, University of Redlands,
defines

Rapid Application Development as an approach to building computer
systems which combines Computer-Assisted Software Engineering (CASE) tools and techniques, user-driven prototyping, and stringent project delivery time limits into a potent, tested, reliable formula for top-notch quality and productivity. RAD drastically raises the quality of finished systems while reducing the time it takes to build them.

Online Knowledge defines

Rapid Application Development as a methodology that
enables organizations to develop strategically important systems faster while reducing
development costs and maintaining quality. This is achieved by using a series of
proven application development techniques, within a well-defined methodology.

History

Rapid application development is a term originally used to describe a software development process introduced by James Martin in 1991. Martin’s methodology involves iterative development and the construction ofprototypes. More recently, the term and its acronym have come to be used in a broader, general sense that encompasses a variety of methods aimed at speeding application development, such as the use of software frameworks of varied types, such as web application frameworks.

RAD vs. Waterfall

In the 1970s and 1980s, several sequential software engineering processes were developed that regarded application development as flowing steadily downward through the different phases of the development process.

Traditional development vs. Rapid Application Development

Traditional development vs. Rapid Application Development

The first description of such a waterfall model is often cited in an article published in 1970 by Winston W. Royce2. However, in this article, Royce presented the model as an example of a flawed, non-working approach. “Waterfall” has in later years become a common term to criticize traditional software development practices. The problem with most waterfall models is the fact that it relies on a methodical requirements analysis phase alone to identify all critical requirements for the application. There is ample evidence that projects using a waterfall approach often fail to provide a useable end product; because projects often exceed their deadlines, the product either fails to meet all requirements or the requirements change during the protracted development phase.

There have been many responses to this problem from the 1980s to today, but almost all of those responses focus on the idea of developing systems in a short timeframe with small teams of highly skilled and motivated staff. It is the iteration step that solves the problems inherent to the inflexible approach of traditional software development.

Why was needed to invent RAD?

The evidence from project failures for projects in the 1980s and 1990s, as evidenced for example by the Standish Group Chaos report (1995), implies that traditional structured methodologies have a tendency to  deliver systems that arrives too late and therefore no longer meet their original requirements. Traditional methods can fail in a number of ways.

  • A gap of understanding between user and developers: Users tend to know less about what is possible and practical from the a technology perspective, while developers may be less aware of the underlying business decision -making issues which lie behind the systems development requirement.
  • Tendency of developers to isolate themselves from users: Historically, systems developers have been able to hide behind  a wall of jargon, thus rendering the user community at an immediate disadvantages when discussing IS/IT issues. While some jargon may be necessary if points are to be made succinctly, it is often used to obscure poor progress with a particular development project.  The tendency for isolation is enhanced by physical separation of some computer staff in their air-conditioned computer rooms. Developers might argue in their defence that users also have their own domain-specific jargon which adds to the problem of deciphering requirements.
  • Quality measured by closeness of product to specification: This is a fundamental difficultly – the observation that ‘ the system does exactly what the specification said it would so’  hides the fact that the system may still not deliver the information that the users need for decision-making purpose. The real focus should be on a comparison of the deliverables with the requirements, rather than of  deliverables  with a specification that was a reflection of a perceived need at a particular point in time.
  • Long development times: SSADM and the waterfall model will reveal that the process of analysis and design can be very laborious and time-consuming. Development times are not helped by the fact that and organization may be facing rapidly changing business conditions and requirements may similarly be changing. There is a real risk of the ‘moving goal-post’  of syndrome causing havoc with a traditional approach to systems development.
  • Business needs change during the development process: This is alluded to above. A method is needed where successive iterations in the development process are possible so that the latest requirements can be incorporated.
  • What users get isn’t necessarily what the want: The first a user may see of a new information system is at the testing or traning stage. At this point , it will be seen whether the system as delivered by the IS/IT professionals in what the user acually needs. An appropriate analogy here is the purchase of a house or car simply on the basis of discussions with an estate  or a garage agent  rather than by actually visiting the house or driving the car. It is unlikely that something purchased  in this way will result in a satisfied customer and there in no reason to suppose that information systems developed is a similar way will be any more successful.
Rapid Application Development Model

Rapid Application Development Model

Not only is there pressure from end-user management for faster systems development, IS/IT department themselves increasingly recognize the need to make more effective use of limited human resources within is their departments while at the same time quickly delivering systems that confer business benefits. All this is is a climate of rapid business change and therefore, rapidly changing information needs. Rapid Application Development (RAD) is a method possible solution to these problems and pressures.

Is RAD  appropriate for all projects?

The Rapid Application Development methodology was developed to respond to the need to deliver systems very fast. The RAD approach is not appropriate to all projects – an air traffic control system based on RAD would not instill much confidence. Project scope, size and circumstances all determine the success of a RAD approach. The following categorize indicates suitability for a RAD approach:

Project Scope
Suitable for RAD – Focused scope where the business objectives are well defined and narrow.
Unsuitable for RAD – Broad scope where the business objectives are obscure or broad.

Project Data
Suitable for RAD – Data for the project already exists (completely or in part). The project largely comprises analysis or reporting of the data.
Unsuitable for RAD – Complex and voluminous data must be analyzed, designed and created within the scope of the project.

Project Decisions
Suitable for RAD – Decisions can be made by a small number of people who are available and preferably co-located.
Unsuitable for RAD – Many people must be involved in the decisions on the project, the decision makers are not available on a timely basis or they are geographically dispersed

Project Team
Suitable for RAD – The project team is small (preferably six people or less).
Unsuitable for RAD – The project team is large or there are multiple teams whose work needs to be coordinated.

Project Technical Architecture
Suitable for RAD – The technical architecture is defined and clear and the key technology components are in place and tested.
Unsuitable for RAD – The technical architecture is unclear and much of the technology will be used for the first time within the project.

Project Technical Requirements
Suitable for RAD – Technical requirements (response times, throughput, database sizes, etc.) are reasonable and well within the capabilities of the technology being used. In fact targeted performance should be less than 70% of the published limits of the technologies.
Unsuitable for RAD – Technical requirements are tight for the equipment to be used.

General Characteristics of Rapid Application Development (RAD)

   Sources