Rapid Application Development: A Brief Overview

Morton A. Hirschberg - U.S. Army Research Laboratory

Introduction

Rapid Application Development (RAD), a revolutionary software archetype of the 1990's, while living up to its promise is still a fertile area for continued research and additional capitalization. This is evidenced by recent workshops at the University of Southern California; Center for Software Engineering (June 1997 and March 1998), the Software Productivity Consortium Workshop in Herndon, VA (November 1997), the Software and Systems Engineering Productivity Project of the Microelectronics and Computer Technology Corporation, Austin, TX, and the Software Technology Conference Panel (April 1998). With little variation the tenets of RAD are essentially those of software development in general: methodology or choice of architectures and tools, requirements and design analyses, selection of personnel and management, construction, and implementation and support. What then sets RAD apart is a very structured approach typically relying on small well trained teams, use of evolutionary prototypes, and rigid limits on development time frames. In summary, the goals of RAD are: faster, better, cheaper.

The Search for the Universal Architecture

Much as the search for the Holy Grail, software developers are continually seeking the universal architecture. One of the strategies of RAD is an up front investment in producing a suitable architecture and populating it with just the right tool suite. At the core of development is utilization, and although not a strict dictum, the use of the Spiral Model allows incremental and repetitive development. The use of Object-Oriented methods is encouraged to speed development and allow for reduced rework and possible reuse. Automated code generators such as the Computer-Aided Prototyping System (CAPS) replaces slow hand written code and minimizes coding errors. RAD also allows for users to employ their own query and update languages, report generators, decision support languages, as well as specification languages. This tailoring and flexibility in the rapid production of prototypes, products, and systems is mitigated by domain specificity which brings order out of apparent chaos.

Will my Ship Sail on Land as Well as the Sea

One of my favorite fairy tales revolves around manufacturing a ship that will sail on land as well as the sea. The successful inventor clearly states the requirements in the problem statement or statement of work (SOW) and then focuses on the design and then construction of such a vehicle. He stays on the critical path throughout the development without any sacrifice of high quality. In the end, the user's needs are fully met. Formal requirements establish a clear definition of the tasks. They also are used to communicate the system capabilities among the customer, user, and developer. Requirements should include design features, performance goals, and schedule and cost estimates. The use of the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) can be an invaluable resource in suggesting what should be done by having a well defined and well understood processes. An important goal of RAD is to keep the time between design and delivery as short as possible. So the use of cost estimators such as the COCOMO model, to name but one, and PERT charts to stay on the critical path, to name another, are highly encouraged.

Who's on First

RAD depends upon continuous, high quality, production. The optimal is a team of users, acquirers and developers who can communicate effectively and successfully develop their products without schedule delays or cost over runs. To this end, as Dr. Cross points out, experience counts. Similarly, it is management's function to eliminate unnecessary tasks, streamline activities, and increase work time while the staff reduces time per task, and reduces or eliminates backtracking. Having a well trained, fully collaborative team is an essential ingredient for success. The core of the team should be full participants in project planning. The core of the team should stay together from start to finish. Support tools should be provided to those skilled in using them. Quality and configuration management should be imposed from within, anytime, anywhere development and the use of virtual offices provides an atmosphere for employee satisfaction.

Construction

This is the phase where prototypes are formed, products developed, and systems produced. It is the crucible of the architecture and tools and the staff and managers who mold and construct them. This is what we have been waiting for, the answers to our questions. We can see the effects of inputs on outputs and marvel at sometimes unexpected but correct results. We also see faults and shortcomings as well. We can determine how robust our products and systems are and if prototypes should be further developed. We can assess risk with far greater accuracy and project the shelf life of our efforts. We can see the quality of our work. We can mark our progress towards meeting time to market, determine our status relative to our competitors, record the time to mature new processes and estimate if our efforts will scale if they are prototyped. We can save elements which can be reused. We can consider how new systems can improve our business and streamline our processes and procedures. We can see if we are truly generating new and valuable information.

It's Not Over Until It's Over

Once we have crossed the construction hurdle and decided to continue we enter the implementation and support phases. In other words, coding, use and maintenance. The latter, as we know, can be 90% of the entire life cycle cost. It is here where we continue our metrics collection but with the counsel of our users. It is here where we continue to respond to requirements and design changes, make modifications, corrections, and improvements. It is here where we assess our true costs and profits (hopefully no losses) and calculate our Return On Investment (ROI). It is here where we begin to plan for the future.

Conclusions

RAD has proven to be a valuable software strategy. It is not without pitfalls and risks. It requires the right mix of methodologies, tools, personnel and management. Its use depends upon complexity of the domain or application, the organizational environment, the skills of staff and management and the architectures and infrastructures available. RAD Is worthy of continued research and capitalization.

About the Author Mr. Hirschberg has over 40 years experience in Software Engineering, 25 years in the government sector. He has authored over 50 papers. Morton A. Hirschberg U.S. Army Research Laboratory Aberdeen Proving Ground, Maryland 21005 Voice: (401) 278-6661; Fax: (401) 278-5078 E-mail: [email protected]

www.arl.mil/

---