Adopting A Rapid Application Development Methodology Copyright 1992 CAUSE From _CAUSE/EFFECT_ Volume 15, Number 3, Fall 1992. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, the CAUSE copyright and its date appear,and notice is given that copying is by permission of CAUSE, the association for managing and using information technology in higher education. To disseminate otherwise, or to republish, requires written permission.For further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301, 303-449-4430, e-mail info@CAUSE.colorado.edu ADOPTING A RAPID APPLICATION DEVELOPMENT METHODOLOGY by David W. Koehler ************************************************************************ David Koehler has been Director of Information Resources at Cornell University since July 1989. The Information Resources Division of Cornell Information Technologies has the responsibility for development and maintenance for the central administrative systems at the University. Koehler has bachelor's and master's degrees in engineering and an M.B.A. from Cornell. Before his current assignment at Cornell he was Assistant Director for Business and Financial Systems there for five years. He is Vice Chair of CAUSE92 in Dallas and will chair CAUSE93 in San Diego. ************************************************************************ ABSTRACT: Cornell University's information resources division has determined that its traditional way of developing information systems will be inadequate to meet the demands of the 90s. The division is changing the way it does business to deliver applications better and faster. This article describes the Rapid Application Development (RAD) methodology Cornell is adopting to meet those goals. In 1981, the Division of Information Resources of Cornell Information Technologies--responsible for most of the central administrative information systems at Cornell University[1]--invested in a fourth- generation programming language (Natural) and a database management system (ADABAS) from Software AG.These products were a key ingredient in Cornell's plan to develop new online systems. The goal was to acquire tools to make the most effective use of staff resources during the development process. These products served us very well during the 80s. Since installation, we have developed approximately fifty application systems, including over 7,400 programs and 2.4 million lines of code. Between the online systems and the batch processes, we run over 10 million ADABAS commands per day; ADABAS now stores over 10 billion characters of University data. By quantitative measures, our staff has done very well. Over the last five years, we have averaged over 50 percent of our staff time on development projects, as compared to the industry norm of 20 percent for development time. This higher level of development productivity is one of the benefits of a fourth-generation programming environment; it would not be possible if we were programming in COBOL or PL/1. Why, then, is our division adopting an entirely new application development methodology? In The Prince, Machiavelli wrote, "There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success than to take the lead in the introduction of a new order of things." Since change is so demanding and our jobs often tenuous, why bother? Our answer: because we have to! NATIONAL TRENDS To help understand why it is imperative to change the way we do business, we should look at some trends that will affect the information systems (IS) profession in the years ahead: Demographics One national trend that has made an impact on the higher education community over the past few years has been the decline in the number of high school graduates--a decrease of nearly half a million since 1979, according to the U. S. Department of Education. There is also a decline in the number of students who have chosen information systems as a career. The Bureau of Labor Statistics estimates that 40,000 new technical jobs will open up each year. In 1989, only 29,000 IS professionals graduated from college. The estimate is for 15,000 in 1993 (see Figures 1 and 2).[2] [FIGURES 1 & 2 NOT AVAILABLE IN ASCII TEXT VERSION] The combination of these two trends is now being felt in our labor pool. Cornell tends to hire college graduates with little or no experience. We cannot compete with industry wage scales. A shortage of competent programmers is a real possibility. Fiscal responsibility Clearly, higher education is going through a period of adjustment (a.k.a. retrenchment). All colleges and universities are examining themselves to determine their mission and objectives. The funds will not be available to make dramatic increases in IS budgets; rather, there have been cuts that will continue. Colleges and universities are learning from the corporate sector. There is a recognition that we must get better, not bigger; there will be a greater acceptance of initiatives that focus on quality. Higher education will be stressing business reengineering[3] to take advantage of information technology and obviate useless paperwork. There is little doubt that the recommendations from quality improvement teams or reengineering efforts will affect the major administrative systems of our institution. IS departments must not be viewed as impediments to change. "Time to market" will be a critical success factor for evaluating our performance. Outside pressure Outsourcing is an issue in the IS community today. Large corporations like Eastman Kodak have negotiated contracts with IBM and Digital Equipment to manage their data centers and network infrastructure. The success of these contracts puts pressure on internal IS staff to consider all types of outsourcing possibilities. As long as outsourcing is confined to non-strategic systems there is potential for real cost savings. The IS department must always maintain staff who know the core business of the institution. To delegate this responsibility to outside consultants would leave the institution vulnerable. Already some colleges and universities have hired contract vendors to replace a large portion of their IS staff. To prevent this, we have to make dramatic improvements in our ability to deliver quality systems, and be prepared to market ourselves accordingly. As with any good product, you prevent future competition by making the "barrier to entry" very large. This is accomplished by producing high quality systems at lower cost. Systems complexity With the operational systems of the past, it was possible for one analyst to keep the whole system in his/her mind at one time. Directing a team of programmers was a task of project management, not a feat of genius. With today's information systems, it is not humanly possible to understand all of the details of an entire application. No longer do we deal with one operational department; we are now automating business functions that serve multiple departments. We need to break functions down into component parts. " Software applications are designed to model human activity, and whether word processing, paying invoices, or steering a missile is modeled, the activity is always complex." [4] Client/server architecture As our information technology delivery evolves to distributed computing, our customers' expectations will be raised considerably. As information becomes more readily available at the desktop, the demand for different types, slices, and aggregations will increase exponentially. Considering these trends, is it time for a career change? Certainly maintaining the status quo is no longer acceptable. We can be passive and let the future be decided for us, or we can be proactive. To be able to develop systems much faster and better we must be willing to use some of the methods and tools that are at our disposal today. We have been catalysts of change, but reactionaries to change. Now we are forced to change to survive. We need to make quantum improvements in two specific areas: productivity and quality. Changing our processes to achieve 5-10 percent gains is unacceptable. Our goals should begin at 100 percent improvement. PRODUCTIVITY AND QUALITY As a profession, we have been working on ways to increase our staff productivity for years. Most of the IS industry's effort to improve the effectiveness of staff has been directed at the programming activity. We have gone from assembler to third-generation languages (COBOL or PL/1) to fourth-generation languages (see Figure 3), but we have done very little to improve the effectiveness of our analysis function. That is the improvement necessary during the 90s. [FIGURE 3 NOT AVAILABLE IN ASCII TEXT VERSION] We need to build a staff of information architects. Although information engineering is stressed in some circles today, it is really information architecture that is important. Consider the building of a house. It is the architect who talks to you about the possible functions for the building, the needs and size of the family, and so forth. The engineer (builder) is more concerned with the size and dimension of the structural components. The building is then constructed from many known standardized parts. We, as information architects, must get the requirements right the first time. We cannot hide behind the functional specifications documents and remind our clients to "be careful what you ask for, you just might get it." It is our fault if the specifications are not correct; we just didn't ask the right questions the right way. The system must meet the business functional requirements at the time the system is delivered, not when it was analyzed. This is a true measure of the quality of a delivered system. Our institutions cannot afford the continuous iterative development we now call "maintenance." According to Russell Jones,IS staff within many organizations now spend upwards of 80 percent of their time maintaining old computer systems. ... Most people term that burdensome 80 percent "maintenance. "For the most part, however, it is not. Rather, it is the "correction"of often gross errors perpetuated during the initial--"business"--stages of systems analysis.[5] We can now define another important measure of IS quality: prevention of software defects. In arguing the merits of using CASE (computer assisted software/systems engineering) tools, Ray Falkner says: "Research has confirmed that the cost of preventing mistakes is only one-tenth the cost of finding mistakes and one-hundredth the cost of correcting mistakes. This is where CASE provides its real productivity savings: by improving the quality of software through preventing mistakes."[6] Is technology the answer? Certainly we read about the promise of adopting new technology and application development methodologies. The trade magazines feature articles about RAD, JAD, ERDs, and DFDs. For the uninitiated those stand for Rapid Application Development, Joint Application Development, Entity Relationship Diagrams, and Data Flow Diagrams. Are these three-letter acronyms important to our future or only fads? We have to be able to separate the hype from the reality. No institution can afford to follow each of the latest technology offerings without having a clear indication of potential payoff. However, there is no doubt that we should explore and implement as many tools as necessary to make our staff more productive. There is not enough money to allow for mistakes. CORNELL'S ANSWER: RAD How do we make the quantum improvement in productivity and quality that is necessary? At Cornell we have decided that Rapid Application Development (RAD) has all the components that are required. Its theme is "High Speed, High Quality, and Low Cost." James Martin defines Rapid Application Development as "a development life cycle designed to give much faster development and higher quality results than the traditional life cycle."[7] In general, RAD describes an environment that puts much more emphasis on analysis and design. User involvement is critical to the success of the project. The process is enhanced by using a CASE tool. The application is then "constructed" using a fourth-generation language, an application generator, and modules of reusable code. Changes are then made to the model designs and the application is regenerated. Although we have just recently embarked on the long journey necessary to change our development methodology, the early results have been encouraging. We are making the change despite some environmental factors that make it difficult. Some corporations have advocated making the transition to RAD by revolution. They contend that the movement should be to CASE, but that is only a part of the RAD equation. It is estimated that it costs up to $25,000 per developer to launch this new technology. Since the University is experiencing drastic budget reductions, we are forced to make the transition through evolution. THE CASE FOR CASE In our efforts to experiment with RAD and CASE tools, we invited a consultant from Washington State University to come and work with us. He performed a two-day CASE-readiness seminar with our management team in March of 1990. Some good ideas came from this retreat. We learned that we were not as far from starting as we thought, that our methodology needed attention (i.e., major change), and that we had management commitment to begin. We chose Software AG's Natural Architect as our CASE tool. The advantages of this particular product for Cornell were that: * it created data dictionary entries in our format, * it had the potential of passing specifications to a Natural application generator, and * it ran on the Apple Macintosh, our desktop standard. We began with a search for appropriate methodology training. Too many attempts to implement CASE tools have been aborted for lack of a formal methodology. Software AG proposed a set of courses on application analysis and design using a new methodology. (Actually, we later found out that the series was prepared because of our request.) How important is methodology? It is the glue that holds the whole process together. "Handing a CASE tool to an analyst without a methodology is like giving a cave dweller a chainsaw without any guidance on what to do with it."[8] It is a mistake to try to implement RAD without a standardized methodology. It should be flexible enough to allow individual creativity, but still make sure that the desired goals (deliverables) are being met. Ken Orr says that what methodologies provide are "frameworks in which complex problems can be attacked systematically by groups of people. A good methodology, like a good checklist, helps you stay organized and on track."[9] However, according to Richard Richards, "the gains achieved with CASE tools ... are often not leveraged. Instead of investing these gains into ways to further manage complexity and improve quality (e.g., by investing in a new methodology that emphasizes thorough analysis and design processes), many managers plow ahead with the same methodology, which neglects analysis and design."[10] Although there are packaged methodologies for sale, we chose to develop our own and formed a committee to work on that task. Some of the features of the newly drafted methodology were: * phased project deliverables, * erector-set life cycle (chosen based upon the project), * 90-day deliverables, * separation of the methodology from the technological environment, * cost/benefit analysis revision after each phase, and * commitment to continuous methodological improvement. Since the new methodology required some things that we had never done before, training was imperative. With a limited training budget it was difficult to anticipate how we would get all of our staff to feel comfortable with our new methodology. FASTRACK TRAINING During November of 1990, we were informed of a new offering of Software AG called Fastrack. This product provides eight weeks of intensive hands-on training in any of Software AG's tools. We were most interested in the CASE tool and the application generator. Since one of our additional goals was to produce a fully functional system, Fastrack sounded like a great way to start our training and test the concepts. Unfortunately, the price was beyond the reach of our training budget. We thought that the University might be willing to contract for a Fastrack if a working system could be delivered. We chose to consider a new financial aid system for three reasons: (1) the current financial aid software package was no longer being supported by the vendor; (2) the environment (CICS/COBOL) was difficult for our staff to maintain; and (3) a unified student services function was being held back by the lack of financial aid data in ADABAS. Our intention in contracting to do a Fastrack was to get a double win--receive some intensive training and deliver a new system. Knowing that we could not produce an entire financial aid system in eight weeks, we chose 40 percent as our target. Since the methodology required continuous user involvement, we were fortunate to have the associate director of financial aid assigned for the project duration. Trying not to leave too much to chance, we appointed a "pre-Fastrack" group to make sure that the Software AG products were installed and tested in our environment. The ones of primary interest were Natural Architect (the CASE tool) and CONSTRUCT (the application generator). Each had its own "product manager" to be responsible for testing and recruiting additional volunteers for testing. As part of the pre-Fastrack process, a Software AG trainer came to Cornell to meet with the methodology group and discuss the course planned for the beginning of Fastrack. His full staff session served to build awareness of the new methodology and get the staff enthusiastic about the new products. In July of 1991, the nine members of our staff, the associate director of financial aid, and a Software AG facilitator moved to a room in another building to begin the Fastrack. The first week consisted of the Application Analysis and Design Course, which taught the methods that would be used for the remainder of the Fastrack. Participants then understood what was expected for the next seven weeks. The group grew more as a team and gained momentum, and the eight weeks went by quickly. WERE WE SUCCESSFUL? There were several areas in our experience that we felt were successful. (1) Training. This was the primary stimulus in moving us toward a new development methodology. Nine staff members had extensive training in the methodology and the new tools, and an additional eleven staff members were able to attend the training courses. These staff members were then able to " seed" the organization with their knowledge and abilities. (2) Educated clients. The financial aid director and associate director clearly understood the value of the new process for designing and developing systems. Our staff used the entity relationship and data flow diagrams extensively to communicate with them and the remaining financial aid staff. The financial aid director communicated to the University the value of user involvement and the quality design that resulted, commenting, " The process not only encourages but forces a complete analysis of the business functions before any specs are written. This has resulted in a high quality design." (3) Financial aid system. The original goal was to complete 40 percent of the entire system. Because of the size and complexity, a partially functioning system was not attained; however, the design and analysis as deliverables themselves were extremely valuable. The project continues with a smaller staff. The estimated effort that will go into the project when finished is 248 person-weeks. This compares with a 1989 estimate of over 400 person-weeks using the then-prevailing methods. Several areas failed to meet our expectations. They were: (1) Functionality. Our main disappointment was not being able to deliver functionality to the clients at the end of the eight weeks. The system was just too large. A decision had to be made to concentrate on the design and analysis instead of trying to deliver a portion of the system. (2) Expectations. Our staff never really saw any of their efforts come to fruition. They had to take on faith that the process would indeed produce a better result. Without a proven product, it was more difficult for them to convince their peers of the value of using these new tools. (3) Staff stress. A by-product of the process that wasn't fully anticipated was the effect on the rest of the staff. We chose not to interrupt any of the Fastrack team during the eight-week session. This left the others with the burden of all of the system maintenance during the summer vacation period. WHERE ARE WE NOW? After our initial experience, we contracted with Software AG to train the rest of our staff in the new methodology. Our project leaders were also trained in new project management skills. The goal was to quickly create a critical mass of staff members who were trained in the methodology and could communicate using common terminology. Our current plan is to do all new development using the new Cornell RAD methodology. Although it is still new and we are not fully experienced, our staff is committed to the change and can see the benefits. We are expanding the scope beyond the Natural/ADABAS environment and using it for some Acius Fourth Dimension projects for the Macintosh as well.[11] Our goal now is to increase our productivity by 100 percent. This would mean that we will deliver new systems in half the time that it takes today. As we become familiar with writing standard code modules, we can reuse those modules to provide further leverage for the development process. One of the added benefits of the new methodology is reduced maintenance expense. Since we will have models for each system, it will be easy to change functionality by changing the models and regenerating the application. We should be able to transfer responsibility for each system among staff since we will be dealing with standardized models. The ability to communicate with our clients using these models will be greatly enhanced. We are seeing successes in other functional areas, as well, as we use the methodology on many other projects. For example, we were able to complete a capital project tracking system and a summer session system using the new tools. Modeling is under way with our human resources, development, bursar, graduate school, and sponsored programs offices. Although it is sometimes difficult for our users to commit the time to these exercises, they have found that it is extremely worthwhile for making changes in their business processes before a system is developed. CONCLUSION We must not lose sight of the reason that we are undertaking this change. There will be a time in the not-too-distant future when we will be unable to keep up with the demand for system enhancements if we do not reengineer our own business processes. By adopting a Rapid Application Development methodology we are beginning to make a dramatic improvement in the quality of our work and the productivity of our staff. Our systems will do a better job of supporting University business functions because more time will be spent with the user in the analysis and design phases. We will deliver these applications faster by using automated tools, and our level of maintenance will be reduced substantially. We must be ready to respond quickly to the changes that will occur in our institutions in the 90s. If we cannot, historians will describe us as the horse and buggy departments of the information age. By using a Rapid Application Development Methodology, we can ensure that our function adds value to our institutions. ======================================================================== Footnotes: 1 Cornell University is a private research university with 12,400 undergraduates, 6,100 graduate students, and 1,600 faculty, located in Ithaca, New York, on a 745-acre site with about 250 major buildings. The University has six national research centers. Cornell is a billion- dollar enterprise, with tuition and fees providing 23 percent of revenues, federal support 15 percent, and state support 15 percent. The rest of Cornell's funds come from sales and services, investment income, group medical practice at the Medical College, and gifts, grants, and contracts. 2 Richard Brandt, Evan I. Schwartz, and Neil Gross, "Can the U.S. Stay Ahead in Software?" Business Week, 11 March 1991, pp. 98-105. 3 In a Harvard Business Review article (July-August 1990), "Reengineer Work: Don't Automate, Obliterate," Michael Hammer defines business reengineering as using " the power of modern information technology to radically redesign our business process in order to achieve dramatic improvements in their performance." 4 Richard F. Richards, "Managing Systems Quality Improvement,"Software Engineering, March/April 1992, p. 7. 5 Russell Jones, " Software Report, March 1990, p. 28.CASE for Quality," Software Engineering, January/February 1992, p. 36. 7 James Martin, Rapid Application Development (New York: MacMillan Publishing Co., 1991), p. 2. 8 Catherine O. Bendure, "Case Study: The CASE Experience at Howard Hughes Medical Institute," Software Engineering, January/February 1992, p. 6. 9 Ken Orr, "Understanding Software Engineering Methodologies," CASE Trends, September/October 1991, p. 20. 10 Richards, p. 7. 11 Fourth Dimension is a database management and applications development environment for the Apple Macintosh. ======================================================================== For further reading: Ernst & Young. "A Case for Practical Solutions." Information Week (White Paper), 25 November 1991. Martin, Wolfgang . "More than Mere Efficiency." Software Report, March 1990. Pastore, Richard. "Proving the CASE." CIO, October 1991. Watson, Steve. "CASE before the Word Existed." Software Report, April 1989. ************************************************************************ Adopting A Rapid Application Development Methodology