Page 1
qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmrtyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqw
Rapid Application DevelopmentScope, Lifecycle, Milestones, Challenges
Page | 1
Page 2
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
Page 3
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
Page 4
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
Page 5
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
Page 6
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
Page 7
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
Page 8
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
Page 9
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
Page 10
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
Page 11
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
Page 12
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
Page 13
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