Chapter 19 Rapid Application Development
Chapter 19
Rapid Application Development
Chapter Overview
The purpose of this chapter is to present an overview of one of the more popular approaches to systems development that differs from the traditional systems development life cycle, Rapid Application Development. The key aspect of RAD that makes it so quick is its combined use of CASE tools, rapid prototyping, and Joint Application Design, with heavy user involvement throughout the process. This chapter presents an introduction to RAD, the components of RAD, several approaches to RAD, several success stories, and the advantages and disadvantages of RAD. Martin’s approach to RAD, as well as the McConnell approach, is overviewed in this chapter. To help students see the application of RAD, three RAD success stories are presented. This chapter concludes with a discussion of the advantages and disadvantage of RAD.
Instructional Objectives
Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to:
1. Explain the basic concepts of Rapid Application Development.
2. Compare and contrast RAD with the traditional systems development life cycle.
3. Explain the advantages and disadvantages of the RAD approach, such that students develop a general idea of when to use RAD.
4. Identify several approaches to RAD.
Classroom Ideas
1. Use Figure 19-1 to compare and contrast the RAD systems development life cycle to the traditional SDLC.
2. James Martin has written extensively on the subject of RAD. Ask your students to locate and read several of James Martin’s articles. Also, require your students to find related RAD articles from other authors. These articles can be obtained from the library, trade publications, and the Web. Ask your students to present their findings to the class.
3. Ask your students to research other alternatives to the SDLC; have your students report their findings in class and discuss how these alternatives compare to RAD.
4. Use a code-generating CASE tool and JAD sessions to conduct a mock RAD in class. This classroom idea requires a great deal of preparation to present the salient aspects of the process during a single class period. An alternative approach is to have students use the RAD approach in their semester projects.
5. Encourage your students to visit the Inprise/Borland Delphi Web site and read several of the cases presented there. Have the students summarize their findings in written or verbal form.
6. If possible have a systems analyst speak to your class about how his company utilizes RAD.
Answers to Key Terms
Suggested answers are provided below. These answers are presented top-down, left to right.
2. JAD / 1. Code generators3. Prototyping / 4. Rapid Application Development (RAD)
Answers to Review Questions
1. The four phases of Martin’s RAD life cycle are requirements planning, user design, construction, and cutover. High-level end users determine system requirements during the requirements planning phase. During user design, end users and information systems professionals participate in JAD workshops and use integrated CASE tools to support rapid prototyping. During construction, the same users and IS professionals involved in user design now build a working system, relying heavily on CASE code generators. System implementation occurs during cutover.
2. Both Martin and McConnell present differing views of the four RAD pillars. Martin’s four pillars include tools, people, management, and methodology. Tools refers to the software development tools; people refers to individuals having the right skills; methodology identifies the tasks and the ordering of these tasks; management provides facilitation and support. Martin further suggests that an organization should “grow into” the RAD development approach. McConnell’s four pillars of RAD include avoiding classic mistakes, applying development fundamentals, managing risks, and applying schedule-oriented practices. McConnell’s RAD approach has a more conservative management flavor, stressing the avoidance of mistakes such as the silver-bullet syndrome, requirements gold plating, and feature creep. He also stresses the application of development fundamentals and risk management. After “efficient development” has occurred, then schedule-oriented practices can be developed.
3. Prototyping, JAD, integrated CASE tools with code generators, CASE tool repositories, and/or visual development environments are important components. JAD sessions can be used to facilitate the prototyping process, where users and analysts are working together to define requirements and design new systems. Integrated CASE tools and code generators can be utilized to design and implement the new production system. The CASE tool repository is beneficial in that it promotes the reuse of templates, components, or previous systems described in the repository.
4. The two trends mentioned in the text are the increased speed and turbulence of doing business in the late 1980s and early 1990s and the ready availability of high-powered computer-based tools to support systems development and easy maintenance.
5. Scalability, when applied to systems development, means that a given system designed for use on one level may need to be expanded for another level (or conversely, may need to be reduced.) This sometimes happens when a system designed by an end user for his personal use becomes used by several people in the user’s department. Later the same system may end up being used for employees with similar needs throughout the organization. In this case, the system has to be scaled upward so that it meets the usage demands of more people and more situations. When a system is designed through RAD, it obviously starts out small, although the production system may end up being much larger. Facilitating such scalability is not always easy to do, but it is much easier to accomplish if planned for during systems analysis and design.
6. The primary advantage of RAD is speed, which leads to economic savings as well as a production system put into use earlier than would normally be the case. Smaller design teams also save money and are easier to manage. System quality should be increased due to the reliability of the code generators used. Code generators also allow new system features or other changes to be included more quickly. Finally, the system should closely match business conditions, since the time between initial design and production is greatly shortened and communication between users and developers is often improved. Disadvantages include the chance that developers will sacrifice a good understanding of the business area for speedy development. This may lead to an ill-defined project that is difficult to manage (for example, cost and time estimates). Also, certain basic aspects of good systems development may be overlooked, including consistency, programming standards, reusability, scalability, interfaces with other systems, and planning for systems administration for the production system.
7. The problem situation will dictate when RAD should be used; however, the primary advantage of RAD can be used to answer part of this question. Systems requiring rapid development are prime candidates for this approach, thus systems responding to new government regulations, opportunities for competitive advantage, or changing business conditions fall in this category. Total reliance on RAD for all systems development can pose problems with nonconformance to standards, lack of reusability between system components, and lack of consistency between systems modules. Systems requiring tight integration with other systems would most probably benefit from a more traditional systems development approach.
8. JAD is one component that is useful during the RAD process. Analysts and users rely on JAD-like sessions to facilitate the prototyping process.
9. In many cases, the rapid deployment of Web-based systems is crucial to an organization’s continuing success. RAD tools and software are available to support the quick development and deployment of these Web-based systems. Additionally, the essential RAD components, particularly JAD and prototyping, encourage the active involvement of end users. As we have seen in previous chapters, interface design is an important element of building Internet-based electronic commerce applications. One of the best ways to address interface design is through prototyping, which is a key RAD component.
Answers to Problems and Exercises
1. Since prototyping is used within RAD, there are obvious similarities between these two methods. A primary difference is that the results of prototyping within RAD (that is, the code) are used within the working system, whereas the result of pure prototyping is a model for the working system. RAD also differs from prototyping in that RAD has a more formal requirements definition phase. It is also typical with RAD that there are several users, whereas prototyping is often applied when there is one or a few users. Also, prototyping may not use a CASE tool but may use 4GLs instead. Both RAD and prototyping emphasize iterative development and direct user involvement in a process driven by the user.
2. Since the RAD four-phase life cycle resembles the SDLC, these are complementary methodologies. RAD can be used to accelerate the SDLC steps of analysis through installation. RAD could be used on selected modules of a new system--modules that need to be developed quickly and that are more stand-alone.
3. It is difficult to conceive of doing RAD without 4GLs, code generators, and CASE tools. Manual programming in a 3GL simply would not support the rapid rebuilding of prototypes implicit within RAD. Object-oriented and visual development environments would also be of great help in RAD. RAD could also utilize packaged software, especially for core modules of a new system, with RAD development concentrating on the customization and extensions of the package.
4. A RAD-developed system can be out of alignment with the direction of the business because the requirements planning phase tends to concentrate only on the needs of the requested application, without consideration of business direction and systems beyond the scope of the project. Thus, analysis of the business area, and the potential reengineering of the area, are not considered. A way to overcome this potentially serious flaw of RAD is to include on the RAD team a few users and senior managers who know the direction of the business. Another option is not to duplicate data into a new database but use existing databases and the agreed-upon data model of the business. A third approach is to use reusable code and centrally maintained models as much as possible. Thus, as these modules are updated in response to new business conditions, so will be the RAD-developed system.
5. As mentioned in the text, RAD is a shortened, yet similar, version of the traditional SDLC. The RAD planning and design phases concentrate work efforts on system functional and user interface requirements, at the detriment of a detailed business analysis and concern for system performance issues. The new system is often developed in isolation from other systems, thus coordination with existing standards and systems is often not done. RAD makes heavy use of prototyping and performing tasks in parallel, and the bulk of the work is done during the design and development phases. Since users have been very involved in the RAD process, the new system, when delivered, should be more readily accepted by them.
6. One approach to this question is to encourage students to visit the Inprise/Borland Delphi Web site (the URL is provided in the chapter references). Ask your students to review several of the cases and identify what characteristics of these cases made the usage of RAD appropriate. In general, systems that require rapid development because of cost, time, and necessity are prime candidates.
7. Both approaches are necessary for understanding the successful application of RAD. The McConnell approach stresses the necessity of management, while the Martin approach stresses the importance of the correct combination of tools, people, methodology, and management.
8. McConnell’s approach stresses the management of RAD projects. The project should be carefully planned and managed, utilizing many of the skills presented in Chapter 3. An open communication with end users can also be used to address the unrealistic expectations that these users may have.
Guidelines for Using the Field Exercises
1. Most of the major systems consulting firms have a RAD alternative in their standard systems development methodology. So, if it is more convenient to have students investigate another specific firm, like Andersen Consulting, or to explore several different firms, the objectives of this question are still met. Typically, systems developers have their favorite techniques, tools, and methodologies, so it is likely that not everyone has embraced the approved RAD method. For many consulting firms, their RAD method is not separate from but rather works with their traditional, well-tested methods. This combination of traditional methods and RAD tends to minimize the potential hazards of a pure RAD approach. Have your students present their findings in class. Ask your students to show how the methodology they investigated differs from the RAD method outlined in the chapter. If the students have investigated several firms, try to draw out the differences between the methods.
2. The difficulty with this question is that there are so many different implementations of RAD, most firms will say they have used RAD but with vastly different processes and results. Thus, the reasons for project selection will likely vary. What is important is to understand how an organization chooses to use the methods, techniques, and tools it does under what circumstances. Students will likely find that there are many common influential factors, but that the history of information systems successes and failure in each organization causes certain factors to dominate. Have your students present their findings and try to draw comparisons across organizations.
3. Students will likely provide a variety of answers. However, most will mention integrated CASE tools with code generators and prototyping facilities as being extremely beneficial. As an extension of this exercise, consider asking the students to compare and contrast three CASE products and the abilities of each to support a RAD approach.
4. This is a very practical approach to presenting the many benefits of RAD. Since several cases are presented at this site, one way to handle this field exercise is to assemble the students into groups, assign each group one of the cases at the Inprise/Borland Delphi Web site to review, and ask each group to present its review to the class. By using this approach, several of the cases can be overviewed, outlining the successes of each.
219