jaRapid Application Development (RAD)

The term Rapid Application Development (RAD) was introduced in the literature by James Martin in his book Rapid Application Development in 1991. The rapid potential of RAD arises from the synthesis of currently-available tools and techniques, coupled with fundamentally different management principles that serve to overcome bureaucratic obstacles to faster development. Thus, the mission of RAD is the simple but powerful one of increasing development speed at a reduced cost without sacrificing quality.

Fundamental Principles Underpinning RAD

The principles include active user involvement, small empowered teams, frequent delivery of products which focus primarily on satisfaction of business functionality, iterative incremental development, top-down approach, and the use of integrated CASE wherever possible. These principles are complementary in many respects, and as a whole are extremely powerful.

Active User Involvement The schism between users and developers in traditional development approaches has rightly been condemned. Indeed it is almost an axiom that user involvement is necessary for successful development. However, several studies have found that user involvement is not a simple issue, and the link between user involvement and success is not a simple one. The RAD approach recognizes that user involvement is necessary for intellectual reasons for example, to reduce costly requirements elicitation problems, and for political reasons users may reject systems outright if they have not been sufficiently involved in development. However, the RAD operationalization of the user involvement concept is a very rich one. At the heart of the RAD approach are joint application design (JAD) and joint requirements planning (JRP) workshops. These are extremely intensive sessions of short duration which serve to identify more completely problematic requirement analysis and system design issues. All relevant parties are co-located thus leading to synchronization in the communication process. Also, RAD recognizes that users are not homogeneous and identifies a number of different roles that users may play.

Small Empowered Teams Again, the concept of development team is not new. However, focusing on each of the words, small, empowered, and teams in turn, the advantages which accrue can be seen to be
1

considerable. Firstly, communication channels increase exponentially in relation to team size. Therefore, small team size ensures that the potential for communication distortion and conflict is kept to a minimum. Secondly, the empowerment element helps ensure that bureaucratic delays and shirking of decision-making responsibility, so inherently characteristic of the traditional requirements signoff, are minimized. Teams are empowered to make vital design decisions. Finally, the team aspect serves to ensure that all vital skills for successful development are present. Successful development requires that many varied roles be accommodated, e.g. project manager, technical coordinator, developer, tester, scribe, user, and executive sponsor. The fulfillment of these roles is facilitated by team composition, and their importance has been acknowledged by Microsoft who organizes their software development around various development roles in a similar manner.

Frequent Delivery of Products As mentioned before, traditional development projects can take from 18 months to five years to complete. It is increasingly problematic given the rapidly-changing nature of todays competitive market-place. RAD, by definition, seeks to reduce development time-spans. Thus, shorter time-boxes for development typically 90 days are an important feature. These shorter time-boxes make project management more straightforward in that it is easier to focus on necessary activities, and be more accurate as to what can be achieved. Also, this principle is concerned with delivery of products. Rather than being focused on process, RAD is premised on delivering products which satisfy the essential criterion of addressing some business function.

Iterative Incremental Development Another fundamental principle of RAD is that systems evolve incrementally and are never complete. Rather, new requirements emerge which are then built into the system. Thus, systems emerge through iterative prototyping, with iteration seen as useful and necessary, not as re-work delaying development. It is recognized that requirements specification is a heuristic or learning process which greatly benefits from the deeper insight that both developers and users get from realistic experience with an actual prototype system. Users may not be able to specify in advance exactly what they want in a system but are able to recognize it when they see it recognition is a far easier process than recall. In traditional development, errors in requirements which are not identified before coding or implementation are extremely costly to correct (Boehm, 1981; DeMarco, 1978). In fact, it is now commonly accepted that since the system produced by the traditional life-cycle undergoes a significant maintenance phase, it may be more properly viewed as a prototype
2

anyway. RAD approaches often follow a truncated version of the System Development Life Cycle, including, for example, only the stages of planning, design, development, and cut-over, with much iteration between the phases.

Typically the planning phase is only performed once at the initiation of the development project. Analysis, design coding and implementation are iterated in several chunks or timeboxes. The maintenance activity grows as more and more of the system is developed, as indicated by the growing size of the maintenance component in the above figure. RAD compresses the step-by-step development of conventional methods into an iterative process. The RAD approach thus includes developing and refining the data models, process models, and prototype in parallel using an iterative process. User requirements are refined, a solution is designed, the solution is prototyped, the prototype is reviewed, user input is provided, and the process begins again.

Top-Down Approach As mentioned before, the philosophy of RAD accepts that requirements cannot be completely specified in advance. Rather, they are specified at a level appropriate to the knowledge available at the given time. These are then elaborated through incremental prototyping. Similarly, products fits for business purpose are produced according to an application of the Pareto principle that is, approximately 80% of the functionality may be delivered in 20% of the time. Systems are then elaborated and finessed as knowledge grows, from broad outline to precise detail. Also, being a top-down approach characterized by short time-boxing, all decisions are assumed to be fairly quickly reversible. This also contributes to developers feeling more empowered to assume responsibility and being less likely to shirk decisionmaking.

Integrated Computer Assisted Software Engineering (I-CASE) If dramatic increases in development productivity are to be achieved, it is vital that the more routine and time-consuming aspects of development be automated. These include code generation and documentation. The automation of these tasks may be achieved through the use of I-CASE. The latter provides a single electronic repository for project-related data. Change control and configuration management features vital in an environment of iterative prototyping are also provided. Additionally, I-CASE facilitates reuse by providing assess to previously designed and tested elements. Thus, by increasing the granularity of the development building block, productivity improvement is further enhanced.

Essential Aspects of RAD

Rapid Application Development has four essential aspects: methodology, people, management, and tools. If any one of these ingredients is inadequate, development will not be high speed. Development lifecycles, which weave these ingredients together as effectively as possible, are of the utmost importance.

Methodology The challenges facing software development organizations can be summarized as more, better, and faster. The RAD development path attacks these challenges head-on by providing a means for developing systems faster, while reducing cost and increasing quality. Fundamentals of the RAD methodology thus include: Combining the best available techniques and specifying the sequence of tasks that will make those techniques more effective Using evolutionary prototypes that are eventually transformed into the final product Using workshops, instead of interviews, to gather requirements and review design Selecting a set of CASE tools to support modeling, prototyping, and code reusability, as well as automating many of the combination of techniques Implementing time-boxed development that allows development teams to quickly build the core of the system and implement refinements in subsequent releases Providing guidelines for success and describing pitfalls to avoid. Active user involvement throughout the RAD lifecycle ensures that business requirements and user expectations are clearly understood. RAD takes advantage of powerful application development tools to develop high quality applications rapidly. Prototyping is used to help users visualize and request changes to the system as it is being built, allowing applications to evolve iteratively. RAD techniques are also very successful when faced with unstable business requirements or when developing nontraditional systems. The structure of the RAD lifecycle is thus designed to ensure that developers build the
5

systems that the users really need. This lifecycle, through the following four stages, includes all of the activities and tasks required to scope and define business requirements and design, develop, and implement the application system that supports those requirements. Requirements Planning Also known as the Concept Definition Stage, this stage defines the business functions and data subject areas that the system will support and determines the systems scope. User Design Also known as the Functional Design Stage, this stage uses workshops to model the systems data and processes and to build a working prototype of critical system components. Construction Also known as the Development Stage, this stage completes the construction of the physical application system, builds the conversion system, and develops user aids and implementation work plans. Implementation Also known as the Deployment Stage, this stage includes final user testing and training, data conversion, and the implementation of the application system.

People The success of Rapid Application Development is contingent upon the involvement of people with the right skills and talents. Excellent tools are essential to fast application development, but they do not, by themselves, guarantee success. Fast development relies equally heavily on the people involved. These people must thus be carefully selected, highly trained, and highly motivated. They must be able to use the tools and work together in close-knit teams. Rapid development usually allows each person involved to play several different roles, so a RAD project mandates a great degree of cooperative effort among a relatively small group of people. Each stage of a rapid development project includes activities that need to move fast. As a result, it is critical that management initiates the project quickly, cutting through any political delays or red tape. At the Requirements Planning and User Design stages, key end users must be available to participate in workshops. While the system is being constructed, the Construction Team, which uses the CASE toolset to accomplish detailed design and code generation, must be poised to move quickly. At the end of the development cycle, the Cutover Team, which handles training and cutover, must also be ready to move quickly. The key players in a Rapid Application Development project include:
6

Sponsor A high-level user executive who funds the system and is dedicated to both the value of the new system and to achieving results quickly. User Coordinator A user appointed by the Sponsor to oversee the project from the user perspective. Requirements Planning Team A team of high-level users who participate in the Joint Requirements Planning workshop. User Design Team A team of users who participate in the design workshop. This team should be comprised of both high-level users from the Planning Team and lower-level users with a more detailed knowledge of the system. User Review Board A team of users who review the system after construction and decide whether modifications are necessary before cutover Training Manager The person responsible for training users to work with the new system Project Manager The person who oversees the development effort Construction (SWAT) Team The SWAT (Skilled Workers with Advanced Tools) Team is a small team of two to six developers who are highly trained to work together at high speed. To achieve the fastest possible development, the team members must be highly skilled in the RAD methodology and in using the chosen CASE toolset. Workshop Leader The specialist who organizes and conducts the workshops for Joint Requirements Planning and Joint Application Design.

Management Achieving high-speed development is a complex process. Systems will not be developed and deployed rapidly if bureaucracy and political obstacles stand in the way or if users are not appropriately involved. Management must be totally committed to RAD in order to manage the change in culture. They must be prepared to motivate both users and IT staff, select and manage SWAT teams, and demonstrate through the use of performance measurements that RAD does mean speed, quality, and productivity. Good management and dedication to the ideals of Rapid Application Development are thus essential to faster system building. To successfully introduce rapid development, management must pay careful attention to
7

human motivation. Managers should target those professionals whom they deem as Early Adapters. Early Adapters are those people who see the value of a new methodology and lead the way in making it practical to use. These employees are enthusiastic about the new methodology and they want to make it work well in their environment. Similarly, managers must be aware of the type of motivation that is most effective for each individual employee, whether it be money, pride, prestige, excitement, or some combination thereof. Because Rapid Application Development is such a sweeping change from the conventional development methods, the best way for a manager to introduce new rapid development techniques is to start small. Original Construction Teams of two to four people should be established and their members should be thoroughly trained in the use of the tools and techniques. As these teams gain experience, they will be able to fine-tune the development lifecycle to improve its effectiveness in their environment. Underlying all of this progress, however, managers must remember the importance of comprehensive and quality training in the use of tools. Good training with tools that are exciting to use can have a profound impact on the attitude of IT professionals, as well as ensure the uninterrupted success of the rapid development project.

Tools The RAD methodology uses both computerized tools and human techniques to achieve the goals of high-speed and high quality. The above has been primarily concerned with the goals of Rapid Application Development and the role of organizations and the people within those organizations in the achievement of those goals. The success of any Rapid Application Development project is primarily dependent, however, upon the tools used. The Wall Street Journal lamented that software is one of the two principle obstacles to economic progress. A former U.S. Pentagon Chief commented, If anything kills us before the Russians, it will be our software. Power tools are required to overcome the problems involved with software development. These power tools can change the methods of construction by using design-automation techniques, code generation, and computer aided planning and analysis. The power tools utilized in Rapid Application Development are Computer-Aided Systems Engineering (CASE) tools. Such CASE tools have come a long way over the past twenty years, enabling us to overcome many of our software development problems through process innovations such as Rapid Application Development. Powerfully integrated CASE software is now available, as well as software that goes beyond traditional CASE limitations.

A fundamental principle of RAD tools is that diagrams are employed whenever possible as an aid to clear thinking. Diagrams are used to represent planning information, overview of systems, data models, process models, detailed designs, and program structures. In addition, RAD tools must generate executable code.

The DSDM RAD Method

A RAD method which is of special interest to us is the Dynamic Systems Development Method (DSDM), produced by a consortium of the same name. The primary reason for our interest is because it is a method which has been inductively derived from actual development practice in a large number of organizations. According to the documentation on the DSDM web site (www.dsdm.org), the method comprises the following five generic stages, which are tailored to the specific business and technical needs of the development context: Feasibility Business study Functional model iteration Design and build iteration Implementation These stages follow a spiral life-cycle as depicted below: Feasibility Study In this phase, the focus of concern is whether the proposed development will actually meet the business needs, whether the DSDM method is even suitable for the project, and an estimate of the development time-scale and costs, and a rough project plan is produced. This phase should occupy a few weeks at most.

Business Study This phase identifies the scope of the overall project and provides a sound business and technical basis for all future work. High-level functional and non-functional requirements are base-lined, a high-level model of the business functionality and informational requirements is produced, the system architecture is outlined and the maintainability objectives are agreed. Like the feasibility study, the business study is a short phase, of no more than a month.

The Feasibility and Business Studies are done sequentially and set the ground rules for the rest of the development. Therefore, they must be completed before any work is carried out on a given project.

Functional Model Iteration In this phase, the focus is on refining the business aspects of the system, that is, building on the high-level functional and informational requirements. This phase consists of cycles of four activities: Identify what is to be produced Agree how and when to do it Create the product Check that it has been produced correctly It is estimated that the bulk of development work is in the two iteration phases where prototypes are incrementally built towards the tested system. All prototypes in DSDM are intended to evolve into the final system and are therefore built to be robust enough for operational use and to satisfy any relevant non-functional requirements, such as performance.

10

Design and Build Iteration During the Design and Build Iteration, the focus is on ensuring that the system is of sufficiently high standard to be safely put into production. The major product here is the tested system. The life-cycle does not show testing as a distinct activity because testing is happening throughout both the functional model iteration and design and build iteration. The tested system will satisfy all the agreed requirements, that is the essential requirements plus as many others as the time available allows. This phase comprises the same cycle of four activities as the previous phases, Functional Model Iteration.

Implementation The implementation phase covers the transfer from the development environment to the operational environment. This includes training all users and handing over the system to them. The project review document is also produced and summarizes what the project has achieved. It reviews all the requirements, which were identified during development and the position of the system in relation to those requirements. Because DSDM is incremental there are four possible outcomes: Everything was delivered and there is no need for further development (hence no arrow in figure 4.3) A new functional area was discovered during development and development returns to the business study phase A less essential part of the functionality was missed out due to time constraints. Development returns to the start of the function model iteration and adds the functionality to the delivered system A non-functional requirement has not been satisfied and development returns to the design and build iteration to rectify this.

Critique of DSDM and RAD

RAD (Rapid Application Development, Martin, 1991) approaches began to be adopted in the late 80s and are based on a number of fundamental premises, the most important being the acceptance that business processing requirements will inevitably change during the development cycle of a system. In order to work with this fact of systems development life the RAD approach mandates: the use of 4th Generation Tools (to enable quick delivery); an iterative model of systems development which allows backtracking in the light of changing requirements;

11

the use of evolutionary prototypes (SSADM adopts the adage that a picture is worth a thousand words, RAD goes a step further and advocates that a working model is worth a thousand pictures); a very high level of user involvement in the development process to aid in communications and to encourage feelings of commitment and ownership; the empowerment of highly skilled, multi-disciplinary teams consisting of users, analysts and technical specialists.

The RAD approach has been used successfully in many organizations and is currently gaining more formal support with the advent of DSDM (Dynamic Systems Development Method, DSDM Consortium, 1995), a framework for RAD. The RAD approach however is not without its pitfalls. DSDM advocates that RAD is only suitable for certain kinds of applications, i.e. those which are interactive, with clear functionality at the user interface, have a clearly defined user group, are not computationally complex and have requirements which are not too detailed and fixed. DSDM advocates that RAD is not suitable for real-time or safety-critical applications or for applications where functional requirements have to be fully specified before any programs are written. Thus RAD would only appear to address part of the applications backlog. Applications suitable for RAD and those not would appear to be at opposite ends of a scale. What about the large class of information systems in between, i.e. those which have: a mixture of interactive and non-interactive functionality, a core user group which is clear but an ill-defined group of other users, some elements of computationally complex functionality, a range of requirements, from the detailed and fixed to the unclear and variable. RAD depends on active user involvement in the development process. What happens if the right users are unavailable? It has been stated that the best users to be involved in RAD teams are those which business cant afford to lose! There is a common misconception that RAD is a license to hack, it is not, however the temptation is there. There may also be integration and data sharing problems when a number of RAD project teams are working concurrently on different systems. (It should be noted that integration problems are not peculiar to RAD projects, the possibility also exists within structured environments, however the use of consistent analysis and design techniques reduces the probability of this occurring.)

12

Reference Fitzgerald, B., Russo, N., and Stolterman, E. (2002). Information System Development: Method in Action. McGraw-Hill. http://www.casemaker.com/download/products/totem/rad_wp.pdf http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html

13