qwertyuiopasdfghjklzxcvbnmqwertyui opasdfghjklzxcvbnmqwertyuiopasdfgh jklzxcvbnmqwertyuiopasdfghjklzxcvb nmqwertyuiopasdfghjklzxcvbnmqwer tyuiopasdfghjklzxcvbnmqwertyuiopas Rapid Application Development dfghjklzxcvbnmqwertyuiopasdfghjklzx cvbnmqwertyuiopasdfghjklzxcvbnmq wertyuiopasdfghjklzxcvbnmqwertyuio pasdfghjklzxcvbnmqwertyuiopasdfghj klzxcvbnmqwertyuiopasdfghjklzxcvbn mqwertyuiopasdfghjklzxcvbnmqwerty uiopasdfghjklzxcvbnmqwertyuiopasdf

ghjklzxcvbnmqwertyuiopasdfghjklzxc vbnmqwertyuiopasdfghjklzxcvbnmrty uiopasdfghjklzxcvbnmqwertyuiopasdf ghjklzxcvbnmqwertyuiopasdfghjklzxc

Scope, Lifecycle, Milestones, Challenges
Page | 1

CONTENTS
1. Synopsis 2. Introduction 3. Background Study 3.1. Scope 3.1.1. Methodology 3.1.1.1. 3.1.1.2. 3.1.1.3. 3.1.1.4. 3.1.1.5. 3.1.1.6. 3.1.1.7. Development Techniques Prototyping Workshops Development Tools Time-boxing Active Customer Participation RAD Lifecycle 4 5 6 6 6 6 6 7 7 7 7 8 9 9 10 10 10 10 10 11 11 11 11 11 12 13 14

3.1.2. People 3.1.3. Management 3.1.4. Tools 3.2. Rapid Application Development Milestones 3.2.1. Reduced Development Time 3.2.2. Less Costs 3.2.3. Increased Quality 3.2.4. High Flexibility 3.3. Rapid Application Development Challenges 3.3.1. Bias towards System Needs 3.3.2. Scalability Reduction 3.3.3. Reduction of Features 4. Conclusion 5. References 6. Appendix

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