qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmrtyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqw

Rapid Application DevelopmentScope, Lifecycle, Milestones, Challenges

Page | 1

CONTENTS

1. Synopsis 4

2. Introduction 5

3. Background Study 6

3.1.Scope 6

3.1.1. Methodology 6

3.1.1.1. Development Techniques 6

3.1.1.2. Prototyping 6

3.1.1.3. Workshops 7

3.1.1.4. Development Tools 7

3.1.1.5. Time-boxing 7

3.1.1.6. Active Customer Participation 7

3.1.1.7. RAD Lifecycle 8

3.1.2. People 9

3.1.3. Management 9

3.1.4. Tools 10

3.2.Rapid Application Development Milestones 10

3.2.1. Reduced Development Time 10

3.2.2. Less Costs 10

3.2.3. Increased Quality 10

3.2.4. High Flexibility 11

3.3.Rapid Application Development Challenges 11

3.3.1. Bias towards System Needs 11

3.3.2. Scalability Reduction 11

3.3.3. Reduction of Features 11

4. Conclusion 12

5. References 13

6. Appendix 14

Page | 2

1. SYNOPSIS

The process of developing a software system is very complex and demands a

considerable amount of time to be invested. Moreover, software requirements continue

to evolve and are becoming more complex with each day that passes. This is because

users worldwide have now particularly become more demanding when it comes to

quality, expenditure and the time-frame allocated towards the development of a

particular software product. Keeping in mind the three (quality, cost, time), the software

development process can be optimized by adopting a sound software development

method such as Rapid Application Development (RAD). Severson (2006) states that a

method of this type provides a framework that gives guidelines as to how the software

development process can be optimized. In that respect, the ultimate objective of this

discussion is to deliberate on RAD. Precisely, the discussion attempts to clearly define

the scope, lifecycle, milestones and challenges that are associated with IT projects

which use the RAD methodology.

Page | 3

2. INTRODUCTION

Hughes and Cotterell (2006) define RAD as an object oriented, team-based software

development method that fuses customers, new and existing project management

strategies, various developmental practices and development tools in an effort to create

high quality systems within a fixed space of time. It was introduced by IBM during the

1980s and its ultimate goal is cutting down on time and costs incurred in a project by

ensuring constant customer participation in all stages of the system development

lifecycle. In essence, the RAD methodology dictates that as soon as the requirements

gathering process is completed, developers should swiftly move on to start creating a

fully operational model (prototype) of the intended system. The model is then used as a

demonstration tool to the users and also serves to solicit feedback from customers

about the system. What actually happens is that the users get a chance to examine the

model at the earliest possible time and establish if the system meets their requirements.

The feedback that the customers provide is used in the amendment and enhancement

of the prototype with the aim of refining the prototype to produce a deliverable that will

cater to as much customer requirements as possible. This process is done iteratively

until the developers and clients agree on a final solution, thus RAD is a continuous

developmental process (Futrell et al, 2006).

Page | 4

3. BACKGROUND STUDY

3.1 Scope

RAD is aimed at producing high quality software in a reasonably short space of time

(normally between 2 - 6 months). To achieve this, processes and guidelines have been

formulated to help provide a standard and systematic approach to rapid software

development. RAD has four elementary characteristics which include methodology,

people, management and tools as illustrated in appendix 1 (Beynon-Davies et al, 1999).

3.1.1 Methodology

The ultimate challenge facing most organizations that develop software is being able to

produce high quality software, faster and at less cost. According to Severson (2006),

RAD addresses these challenges by providing a methodology that makes it possible to

speed up the development time whilst not compromising on quality and cost. The

essentials of this methodology will be discussed throughout this document and they

include the following:

3.1.1.1 Development Techniques

RAD merges the finest techniques available and also dictates how best those

techniques can effectively be used to achieve optimum results in systems development.

For example concepts like iteratively developing systems and prototyping have been

inherited from other methodologies such as the spiral model of development. However,

RAD goes further to put more emphasis on shorter time-frames and reducing costs and

increasing quality (Beynon-Davies et al, 1999).

3.1.1.2 Prototyping

RAD is heavily dependent on incremental prototyping methods that in the end produce

a final product. Prototypes play a pivotal role in ensuring that the customer’s

expectations are met before a solution is finalized. What actually happens is that

developers carry out investigations, create a fully functional model and then discusses

the model with the customer. Refinements are then made and more reviews take place

until an agreement is reached about the final solution (Fitzgerald et al, 2002).

Page | 5

3.1.1.3 Workshops

Traditional methods of development used methods like interviewing to gather

requirements. RAD uses Joint Application Development (JAD) workshops as a means

of collecting requirements and design review feedback. During such workshops, the

customer, key users and developers lock themselves into discussions, and establish the

requirements and the scope of the system. The workshops are however not limited to

the requirements planning phase only and is therefore used in the various stages of the

project lifecycle (Fitzgerald et al, 2002).

3.1.1.4 Development Tools

It goes without saying that RAD heavily relies on Computer Aided Software Engineering

(CASE) tools to speed-up the activities that involve tasks like system modeling, the

creation of prototypes, and the provision for support of features like re-use of code.

Therefore a right selection of these modern tools like Database Management Systems

(DBMS) and GUI builders is very important in the successful completion of RAD

projects (Fitzgerald et al, 2002).

3.1.1.5 Time-boxing

RAD allows the rapid construction of systems through a technique called time-boxing. A

time-box can simply be defined as a deadline for delivering the final working deliverable.

What this means is that, during a project, more priority is given to developmental

activities and in the event that the project starts to lag behind; requirements are reduced

so that the project activities do not go beyond the stated deadline. In short, instead of

extending the deadline to allow more time for the project, requirements are reduced so

that the project fits into the specified time-box (Fitzgerald et al, 2002).

3.1.1.6 Active Customer Participation

Traditional approaches to software development like the waterfall model compromised

the issue of user involvement during the process of developing a software system.

However the RAD approach views the aspect of active customer participation as a basic

necessity for successfully completing a project. The reasons for this perspective include

practical reasons (for example reducing costs associated with eliciting requirements)

Page | 6

and opinionated reasons (for example customers may not accept a system that is

developed without their constant contribution) (Hughes and Cotterell, 2006).

3.1.1.7 RAD Lifecycle

According to Aggarwal and Singh (2008), RAD has a lifecycle that a software

development organization can follow to develop their products. Thus the structure of the

lifecycle is crafted to make sure that the end product of a project caters for almost all the

users’ needs. It consists of four phases which are namely requirements planning, user

description, construction and cut over. Appendix 2 illustrates the interaction amongst the

phases.

Requirements Planning

This phase is also referred to as the Concept Definition phase. It is characterized by

intensive meetings between key customers and a team responsible for planning

requirements. The purpose of the meetings is to scope the project as well as capturing

the initial high level requirements for the intended system. The phase typically lasts

between 1 – 4 weeks and its end result is a number of action diagrams which explicitly

define the relationships that exist between business processes and other data

elements. Structured tools like Microsoft Visio may be used in this phase for

requirements modeling purposes (Beynon-Davies et al, 1999).

User Design

In this Functional Design phase, an interaction between users and system analysts

happens through JAD workshops. During the workshops, models and prototypes are

developed to capture critical processes involved in the system. This stage is very crucial

because it allows the users a chance to understand the system through a working

prototype, suggest modifications and eventually accept a functional model that

addresses their business requirements (Beynon-Davies et al, 1999).

Construction

This is the phase that focuses on developing the actual system. It compresses the

detailed design, coding and testing stages that are found in the waterfall model into this

one phase. However, unlike in other SDLC models, RAD dictates that users must

Page | 7

continue their participation throughout the entire project. Therefore, the users continue

to post their suggestions at the same time the system is being developed. Once a

product is developed, it is released to the user so as to gather feedback on how best to

refine the system (Beynon-Davies et al, 1999).

Cut over

This is the final stage of the lifecycle. The activities involved in this stage are analogous

to those of the implementation phase of the SDLC. Some of the activities involved are

acceptance tests by users, installing the system, and training of users (Beynon-Davies

et al, 1999).

3.1.2 People

RAD is dependent on exceptional tools to achieve rapid system development. However

exceptional these tools can be, they cannot on their own, warrant success. They require

people with the right skill-set and the ability to use these tools to achieve optimum

results in projects. Therefore, RAD commands that the people involved in projects

should be well trained and greatly motivated. Most importantly they must be able to

work as part of a team and complement other members’ skills (Fitzgerald et al, 2002).

The key stakeholders in RAD projects include sponsors, requirements planning team,

user design team, project manager, training manager, workshop manager, and

construction team.

3.1.3 Management

It is very difficult to rapidly develop and deploy a system if there are administrative

obstacles hindering the smooth flow of a project. Therefore a sound administrative

system is needed to oversee the project from conception to completion. To achieve this,

those involved in the management of the project must be fully dedicated to RAD. They

should ensure that all stakeholders involved in the project play their roles to the best of

their abilities. Most importantly, they should ensure that everyone involved understands

the RAD methodology and hence adapt to the new culture that comes with the

methodology. For example, members should be intensively trained on how to use tools

so as to gain the much needed experience in RAD (Beynon-Davies et al, 1999).

Page | 8

3.1.4 Tools

At this point in the discussion, it is undoubtedly clear that RAD employs computer-based

tools and people to meet the objective of high quality products at high speeds. RAD,

however, primarily depends on the type of tools used in a project to determine the

success of that project. The tools help in ensuring that repetitive tasks like code

generation and project documentation are automated. This greatly reduces the time

consumed by these activities and thereby speeding up the development. Examples of

tools that can be used in RAD projects are CASE tools. These tools play a pivotal role in

eradicating some problems that exist in other models of software development. For

example, CASE tools can be used to develop models (using e.g. UML diagrams) and

directly generate code based on those models instead of hard coding (Beynon-Davies

et al, 1999).

3.2 Rapid Application Development Milestones

3.2.1 Reduced Development Time

The use of power tools ensures that a system is developed faster and thereby reducing

the product cycle time. This means that the system is delivered to the customer in a

lesser time-frame compared to the other development models like the waterfall model.

This resultantly brings business value to the customer (Futrell et al, 2002).

3.2.2 Less Costs

Since project teams consist of members who are skilled and experienced in their project

domain, fewer developers (typically 2 – 6) are needed to work on a RAD project.

Therefore this reduction in the number of developers, coupled with a reduction in the

development time means less expenditure for the customer (Hughes and Cotterell,

2006).

3.2.3 Increased Quality

Constant customer participation increases the chances of producing a product that

satisfies almost all the requirements of the customer. That in-turn means that the risks

of developing a system that does not bring business value are greatly reduced and

hence a product of highest quality is produced (Severson, 2006).

Page | 9

3.2.4 High Flexibility

By virtue of being able to build prototypes as early as possible in the RAD lifecycle, it is

possible to make amendments to the system at an earlier stage of development. It is

also possible to stop and abort development in the case of a system that is unworkable.

Most importantly early prototyping and demonstration ensure that the final deliverable

meets almost all specified requirements (Futrell et al, 2002).

3.3 Rapid Application Development Challenges

3.3.1 Bias towards System Needs

RAD places more emphasis on the dynamics of the system only and it fails to address

needs at the business level. The disadvantage of this is the higher risk of producing a

functional system which is capable of serving the business in the short term and fail to

address the long-term goals of the system (Futrell et al, 2002).

3.3.2 Scalability Reduction

As previously noted, RAD focuses on developing prototypes that are refined iteratively

to end up becoming a fully functional system. The problem with this approach is that a

product developed in this fashion may lack the scalability that exists on a system that

was developed from start as a full application using traditional methods like waterfall

model (Severson, 2006).

3.3.3 Reduction of Features

As noted earlier in the discussion, time-boxing sacrifices certain application features in

place of producing a deliverable within the specified time-box. This means that RAD has

the likelihood to produce an application that has fewer features when compared to a

product which is developed using some traditional methods like the spiral model

(Severson, 2006).

Page | 10

4. CONCLUSION

The conclusions emanating from the findings of this deliberation are suggestive of the

fact that Rapid Application Development has brought about a new dimension in the

software system development. The main points to be noted include the following:

RAD has successfully achieved the objective of reducing costs on projects whilst not

compromising on quality by effectively reducing the project time-frame and the

number of people involved in such project.

It has also been successful in encouraging the involvement of customers in the

entire process of its development lifecycle. This proves advantages in many

respects but most importantly this improves the development process by ensuring

full acceptance from the customer whilst the system is still being created.

RAD has also demonstrated strength in being able to speed up the development

process by appropriately fusing its methodology, people, management and high-tech

computer-aided tools.

RAD has also proven to have challenges. Amongst these challenges are the fact

that it tends to lean too much on emphasizing more on delivery deadlines and then

compromising on other features that could have been added if there was not a

deadline set.

Having said all that, it can be noted that the advantages of RAD outweigh the

disadvantages and hence that means RAD has successfully met its objective to create

quality systems, faster and at minimum cost.

Page | 11

5. REFERENCES

Aggarwal, K. K. and Singh, Y. (2008), Software Engineering, 3rd Ed., New Delhi: New

Age International Publishers

Beynon-Davies, P. et al, Rapid Application Development (RAD): an empirical review

[http://www.stockton-press.co.uk/ejis] 1999. Accessed 19/09/2010

Fitzgerald, B.; Russo, N. and Stolterman, E. (2002). Information System Development -

Method in Action. New Delhi: McGraw-Hill.

Futrell, R. T. et al (2002), Quality Software Project Management, Low Price Ed., New

Delhi: Pearson Education

Hughes, B. and Cotterell, M. (2006), Software Project Management, 4th Ed., New Delhi:

Tata McGraw-Hill Publishing Company

Severson, R., Rapid Application Development: Race against the Clock

[http://www.atmel.com] 2006. Accessed 17/09/2010

Page | 12

APPENDIX 1

Typical Design Structure for RAD (Courtesy of Beynon-Davies et al, 1999)

APPENDIX 2

RAD Lifecycle Phases (Courtesy of Beynon-Davies et al, 1999)

Page | 13