SDLC, JAD, and RAD: Finding the Right Hammer

1995 Charles S. Osborn Assistant Professor, Information Systems Babson College Center for Information Management Studies Working Paper 95-07 Babson Hall 323 Babson Park, MA 0257-0310 Tel. 617.239.5585 Fax 617.239.6416 Osborn@babson.edu Table of Cont ent s Abstract Introduction The systems development problem Figure 1: The Systems Development Cycle Sequencing Figure 2: Systems Development Sequencing Figure 3: Key Activity Comparison Requirements definition Approval processes Organizational coordination Design techniques in context Figure 4: Technology and Methodology Evolution Economic and organizational background Figure 5: Key Trends SDLC vs. JAD vs. RAD: different strengths, different limitations Figure 6: A Comparison of Development Techniques
PDFmyURL.com

A framework for development portfolios Figure 7: Choosing Methodologies Figure 8: Methodologies and Project Characteristics Interlinked development: an example Conclusion

Abstract
This report considers the trends underlying three major systems development techniques: SDLC (Systems Development Life Cycle), JAD (Joint Application Development), and RAD (Rapid Application Development). It discusses how the three methodologies, often seen as mutually exclusive, really represent solutions that place differential emphasis on common elements of the system design problem. Understanding the similarities and differences between these approaches can help managers understand the strengths and limitations of each. Each methodology's strengths demonstrate the technology, economics, and organizational issues current at the time that it was first defined. SDLC provides tools for controlling details within large development projects that solve structured problems. JAD enables the identification, definition, and implementation of information infrastructures. RAD supports the iteration and flexibility necessary for building robust business process support. As business problems become increasingly cross-functional and unstructured, RAD may prove increasingly useful. RAD's success in practice, however, may depend on the quality of the systems architecture and information infrastructure already in place within an organization. Architecture and infrastructure project success, in turn, may benefit from the strengths of SDLC and JAD rather than RAD. For information systems managers, matching projects with appropriate development techniques has become a more complex problem. This report suggests ways to distinguish development project characteristics that assist in identifying an appropriate development technique. These include (1) analyzing the structure inherent in a business problem by asking how readily system requirements can be defined, and (2) inquiring carefully into the system's role as specialist technical infrastructure or generalist process support. These two dimensions provide a framework for making choices between SDLC, JAD, and RAD. A carpenter would not use a sledgehammer to remove a fly, nor a tackhammer to drive a wedge. I/S managers have an increasing variety of choices available in selecting methodologies for their development portfolios. This report can assist in finding the right hammer.

SDLC, JAD, and RAD: Finding the right hammer

Three acronyms -- SDLC (Systems Development Life Cycle), JAD (Joint Application Development), and RAD (Rapid Application Development) -- describe emerging trends of increasing importance to CIOs and information systems (I/S) managers. The three labels refer to systems development methodologies typically perceived as so dramatically different that arguments between their advocates sometimes resemble
PDFmyURL.com

religious war. Examining the economic, organizational, and technical trends underlying the evolution of these techniques, however, suggests a different perspective -- one that understands these three approaches as largely interrelated and complementary. Awareness of these connections can help technology and business managers shape decisions that improve the financial and operational success of large development projects. This report builds a framework for comparing SDLC, JAD, and RAD in order to understand the strengths and weaknesses of each approach. It asks two questions: (1) what are the meaningful differences between these techniques, and (2) in what contexts will each be most successful? Using the framework can assist managers in structuring their systems development portfolios to best fit the business and system contexts of the problems that individual development projects are trying to solve.

The systems development problem

At a relatively high level of abstraction, all systems development projects attempt to solve the same problem -- the definition, construction and delivery of a business-purpose computing application -- and use a phased approach to do so. Over time, the phases of this approach have become enshrined in the familiar development cycle that includes (1) defining requirements, (2) designing an information system to fit those requirements, (3) building the code to deliver that system, and (4) testing to see whether the code works and the system does the job it was intended to do. Researchers, consultants, and industry observers tend to have their own lists for these phases; some have more steps that those listed above (sometimes hundreds more), but most compress to some version of define/design/build/test cycle. Figure 1 shows this cycle as a schematic that emphasizes lessons learned early by practicing software engineers: development is iterative and circular, easier to start than to finish, and often evolutionary in nature. Figure 1: The Syst ems Development Cycle

SDLC, JAD, and RAD offer different responses to these development cycle characteristics. Each method approaches the development cycle with different assumptions about sequencing, different expectations about activities that occur in each phase, and different presumptions about organizational collaboration.
PDFmyURL.com

Sequencing Traditional SDLC techniques carefully defined each phase of the development cycle into multiple project activities that were strictly sequenced. In this so-called "waterfall" approach, the outputs of all prior development work were prerequisites for each step in the process. The classic waterfall approach focused great effort on ensuring that all details of requirements definition were documented before design began, that design was completely finished before code was produced, and that testing was exhaustive before code was released. JAD approaches relied more heavily on data modeling and prototyping techniques to compress development time by overlapping what had been sequential steps. Modeling was seen as an intellectual common ground on which developers and users could meet to negotiate system details. Prototyping played an increasingly important role in translating model attributes into system features. RAD compresses all phases of the cycle into intensive work delivered by small, cross-functional teams. Prototyping receives primary emphasis, superseding both written specifications and data models. Iteration evolves into collaboration across parallel activities using techniques similar to concurrent engineering. Figure 2 suggests the degree to which resequencing enables RAD teams to shrink development schedules. Figure 2: Syst ems Development Sequencing

Within this range of sequencing options, each approach places different emphasis on activities in each phase of development work. Three areas in which contrasting methods imply different activity are requirements definition, approval processes, and organizational coordination. Figure 3 summarizes this comparison. Figure 3: Key Act ivit y Comparison

PDFmyURL.com

Requirement s def init ion SDLC emphasizes formal requirements definition documents that build a detailed description of the system on paper before any code is produced. These documents normally include narrative descriptions, data definitions, and sample screens. Producing a thorough, often multivolume description of system requirements can become such a time-consuming task that it begins to extend the expected life of a development project. JAD tends to rely on data models to provide requirements definition and prototypes to capture final design details. In theory, data modeling can produce thorough system specifications more quickly than SDLC narratives, especially through the use of computer-aided software engineering (CASE) tools. In practice, a modeling effort can expand to fill the time that used to be occupied by SDLC requirements definition. This is especially true in an information systems department whose analysts were originally trained by SDLC to collect and resolve all details of all requirements before proceeding further. RAD relies on a series of iterative prototypes to specify and document requirements. The technique reverses the scheduling emphasis normally found in SDLC projects by setting a rolling series of release dates and dynamically adjusting system features to fit. Iterating prototypes gives requirements the opportunity to evolve and the flexibility to change: the more rapid the iterations, the more flexibility available for requirements definition. Using a "time-boxed" implementation plan means that features which prove too difficult to add to one release can be added to future releases. In practice, a working prototype can provide a large amount of information about system design details in a concise fashion, especially when used with component-based development tools whose third-party modules are to some degree pre-documented. Approval processes SDLC tends to rely on formal approvals that signify the handoff of project materials from one specialized organizational function to another. The approval often takes the form of negotiation over the content of documents describing design promises about system features. Building consensus around the commitments that these promises represent is often a difficult and political task. The fact that there is often a large volume of material to review and understand, some of it relating to technical details that can have unexpected implications for how the final system functions, only makes it more difficult to reach agreement at each approval point. JAD uses data models to encapsulate knowledge of and promises about system design. Models can provide an elegant and concise way to capture system characteristics, especially when paired with semi-automatic code generation facilities found in many CASE tools. When used
PDFmyURL.com

as the basis for approval cycles, however, they carry the potential risk of being more readily understood by systems designers than by system sponsors. Asking system sponsors to study pages (and sometimes volumes) of models is not always a successful strategy for negotiating the consensus needed for well-informed system design approval. RAD replaces formal documents and models with working prototypes. The focus on working code concatenates the consensus-building needed for approving system features. It is easier for a system sponsor to look at a prototype and understand whether it will work than it is for him or her to read a description (whether narrative or model-based) and extrapolate its success. It is easier for a developer to understand the full infrastructure implications of a process interface once he or she sees that interface in action. Presumably, it is also easier to understand exactly what features are most appropriate for a given business process if a working prototype of the system can be applied directly to the process while being analyzed for strengths and shortfalls. When this approach works successfully, especially as applied in small RAD teams, approval can become a formality that occurs after consensus has been reached, rather than an extended negotiation process for adjudicating agreements. Organizat ional coordinat ion The differences between SDLC, JAD, and RAD design described here indicate some key differences in the organizational assumptions underlying each method. SDLC builds systems based on a presumption of full specialization of tasks, with each participant a representative of an organizational specialty. Connections between specialties -- between system sponsors and system designers, for example -- are managed on an arms-length basis using the mechanism of a formal approval process based on extensive documentation. The same is often true within I/S departments when system designers and system builders use SDLC to apportion responsibilities and, retroactively, sometimes assign blame. JAD's use of modeling is intended to support direct collaboration during system design. That collaboration is expected to produce documentation that can be satisfactorily delegated and specialized during building and testing. Model-building, as a collaborative exercise involving both system designers and system sponsors, can effectively capture system requirements in a relatively short time. In practice, however, the potential complexity of modeling methods and the time-consuming discussions needed to verify models sometimes mean that this task is handled with a delegation/reporting/negotiation/approval cycle, leading to many of the pitfalls of SDLC. RAD's use of small teams and tight prototyping schedules forces a different approach. Here, in effect, representatives of all the organizational functions that need to decide on system features are locked in a room until they reach agreement. Reaching agreement means moving through enough prototypes so that both technical and business-process problems are solved. Since sponsors, analysts, coders, and testers are all working in the same place at all times, they share a project history that can contribute to resolving disputes. Since prototypes are incremental and frequent, large "show-stopping" problems either surface very early or don't accumulate. Although the teambased model requires giving very careful consideration to the knowledge and authority of team members, it provides what one system development manager calls an "in-your-face accountability" that is very difficult to duplicate otherwise.

Design techniques in context

PDFmyURL.com

To understand the evolution of three so apparently different system methodologies it may be useful to review the economic and organizational contexts within which each developed. Doing so suggests that SDLC, JAD, and RAD actually represent a natural progression of methods that respond to different technologies and organizational needs. Economic constraints, influenced by the characteristics of new technology, have also played a role. Consider three broad trends in hardware and software that have evolved over the past four decades. In the 1960s, mainframes provided the only computing alternative. With mainframes came proprietary operating systems and system-specific software compilers. In the 1970s, minicomputers began to make inroads into mainframe markets. With minis came proprietary operating systems such as VMS and quasi-open systems such as UNIX. Third-party applications began to emerge. In the 1980s, personal computers and workstations made their appearance, bringing open, third-party operating systems such as MS-DOS. Shrink-wrapped software became a commercial reality. In the 1990s, concepts of client-server computing have developed from this mix of hardware and operating systems. SDLC, JAD, and RAD each developed as methodologies soon after a new wave of hardware and software became prominent (see Figure 4). SDLC developed to build mainframe-based systems using customized code developed in-house by large teams of analysts and programmers. These projects, born of the data processing era, often focused on capturing and recording large numbers of transactions as a first step towards organizing corporate data (although the term used at the time was "automation"). By contrast to many managerial systems being developed today, the automation of existing transactions represented a relatively structured problem: the challenge was to ensure that the system adequately captured the details of transactions and accounting systems that were already reasonably well understood. Figure 4: Technology and Met hodology Evolut ion

JAD developed in an era when minicomputers had made the promise of departmental computing a reality and organizations were challenged to build infrastructure systems that could capture corporate information in flexible, reusable data structures. For this purpose, modeling was a useful solution. The advent of third-party CASE tools (partly supported by the graphics technology available on minicomputers) assisted in
PDFmyURL.com

applying systematic techniques to modeling data designs. JAD supplied mechanisms for articulating the abstractions needed to understand enterprise information needs: often a problem whose full implications were discovered as or after models were completed. Code generation, however, still tended to be done in-house. RAD emerged as companies attempted to build client/server applications that leveraged existing infrastructure through the use of layered hardware architectures and distributed databases. In many cases RAD provided an application-focused front end to architectural solutions whose components were built with SDLC and JAD. RAD projects made heavier use of third-party tools for both design and for code generation. Where SDLC mainframe projects in the late 1960s tended to represent fully customized code developed in-house, RAD teams could begin to rely on a broader spectrum of commercially-available software, to the degree that some RAD projects now spend more time stitching together third-party code components than writing new software. Economic and organizat ional background Changes in technology have altered the economics of systems development at the same time that organizations have identified new needs for systems support. Each trend has influenced the perspectives and assumptions behind SDLC, JAD, and RAD methodologies. These changes are summarized in Figure 5. When SDLC developed, each increment of computing power (e.g., a mainframe) cost millions of dollars apiece, and only technical specialists understood the black art of programming. The installed base of machines was too small to support widely-available software tools, especially considering the fragmentation caused by proprietary operating systems. The result of high investment costs and custom craftsmanship meant that correcting mistakes encountered in the field was prohibitively expensive. SDLC developed to minimize the occurrence of mistakes at the time of system implementation. Figure 5: Key Trends

The goal of SDLC's lengthy review process was to ensure that code ran successfully when installed. Errors in system design, especially interface design, were of secondary importance. So long as transactions were captured correctly, the system "worked" -- and then-current technology offered a fairly short list of interface options for capturing data. To the degree that automation contributed to streamlining
PDFmyURL.com

operations and cutting costs, it often was easier to redesign operations around the computer system than to design the system to fit tightly within an organizational process. Minicomputers lowered the incremental investment for I/S support from millions to hundreds of thousands of dollars and generated a larger installed base of machines. For a departmental system whose costs were an order of magnitude lower than its mainframe-based predecessors and whose design was assisted by semi-automated CASE documentation, correcting a programming error upon application delivery no longer represented a risk of organizational paralysis. Instead, the risk shifted from code management to data management as organizations began to understand the dangers of departmental data proliferation. JAD evolved partly as a response to the emerging need for functional corporate data infrastructures that enabled both data control and data distribution. Minicomputers provided useful distribution points, and experience with departmental applications began to spread system design experience beyond the technical specialists who understood mainframes. JAD's focus on data modeling provided useful tools for data architecture design, and JAD prototypes assisted in delivering consistent applications based on a shared data resource. The commercial success of microprocessor-based workstations (including PCs) in the 1980s and the proliferation of networks in the early 1990s changed the context within which systems were developed. As networks connected multi-layered hardware architectures of mainframes, minicomputers, and personal computers, it became necessary to focus on both infrastructure and interface. Personal computers (PCs) and workstations provided enough desktop computing power to enable new approaches to interface design. Data-aware infrastructures, where these existed, enabled the delivery of information to interface engines at the time and place where the information was most needed by key business processes. At the same time, business trends popularized by such concepts as reengineering increased competitive pressures to improve corporate response times and improve cost structures. Equipped with workstation-based technology whose incremental investment cost was only in the tens of thousands of dollars rather than the millions, and exploiting newly-commercialized software that offered the opportunity to design consistent graphical user interfaces (GUIs) for new applications, business units began to focus on using information systems to implement new, cross-functional business process designs. The relationships between process and computing power that had existed in the mainframe world reversed: no longer did the process have to conform to the computing power that supported it. Now it was possible to design an interface specifically intended to adapt to a new business process design, and use computing power to deliver data to that interface when and as needed. In many respects, moreover, this approach offered the opportunity to support less-structured management processes that resulted in dramatic performance improvements and stronger competitive position. This shift soon revealed that (1) cross-functional process designs were not well served by system designs that insisted on the formal separation of specialists, and (2) the time required to prepare and document formal SDLC analyses - especially for applications that contributed to defining unstructured problems -- was unacceptably long. After several years of experience with PC-based software and databases, managers in line departments often emerged with more understanding of the potential (and limitations) of information systems than had been the case when corporate processing power had remained centralized in the mainframe's glass house. As client/server tools began to emerge that promised the scalability required to expand working prototypes to production volumes in a controlled fashion, organizations began to recognize the value of small, cross-functional development teams that immersed a carefully-selected group of skilled practitioners in close proximity for a relatively brief but intensive project period, leading to systems that could perform real work within
PDFmyURL.com

months -- and that could be expanded to encompass new features on a scheduled basis. All that remained was to find a catchy title, and RAD became recognized as a trend.

SDLC vs. JAD vs. RAD: different strengths, different limitations

From this perspective, then, SDLC, JAD, and RAD represent different points along a continuum of system design choices. Each has its strengths and each its weaknesses. SDLC provides the care and precision needed to computerize large volumes of well-understood transactions, but does not necessarily provide the flexibility to match system development speed to process redesign efforts. JAD provides the tools for understanding data infrastructures and building the abstractions necessary for articulating organizational information flows, but does not necessarily capitalize on the need to develop and deliver interfaces that align closely with cross-functional process requirements. RAD can build interfaces and roll prototypes into production code at speed and under acceptable control, and is well-suited for developing systems to support high-level, unstructured processes. RAD tends, however, to provide neither the control needed to build large transaction systems nor the tools and time needed to implement broad infrastructures. Figure 6: A Comparison of Development Techniques

Figure 6 summarizes this comparison. It suggests that RAD's strengths lie in building interface-oriented systems that support unstructured business problems and already have a data infrastructure and transactions source to build upon. It emphasizes the importance of JAD and SDLC in providing the foundation of architecture and data without which RAD teams seldom deliver useful product. At the same time, it suggests retaining JAD and SDLC techniques for those areas where their development strengths can be put to best use. In this sense, this perspective suggests that the best systems development approach is not any one method but rather a carefully chosen mix of techniques.
PDFmyURL.com

perspective suggests that the best systems development approach is not any one method but rather a carefully chosen mix of techniques.

A framework for development portfolios

If SDLC, JAD, and RAD are methods best suited to different development problems, they should be applied where their strengths can provide the greatest leverage. In different contexts, different techniques are likely to increase the chances of success. Figure 7 suggests some of the contexts in which SDLC, JAD, and RAD would be a productive choice. Figure 7: Choosing Met hodologies

What criteria determine when to use RAD and when to use other techniques? A useful analysis suggests focusing on the characteristics of the business problem to be solved and the characteristics of interface to be defined. This notion takes concepts familiar to systems designers and adapts them slightly to emphasize differentiating between techniques. Business problems can distinguished according to the requirements criteria familiar to SDLC practitioners, but rather than asking what requirements are, this analysis suggests asking how readily requirements can be defined . Applications whose requirements are obvious are reasonably well-understood and so can be considered relatively structured. Applications whose requirements are likely to change frequently during development are not well understood and should be considered unstructured. As structure decreases, the likelihood that RAD techniques will prove useful increases. The second dimension focuses on interface questions, but again shifts the perspective typically found in traditional development. Instead of asking what the (user) interface needs to be, it suggests focusing on the role of the system as an organizational interface . This means asking what role the system will play in (a) supporting an organization's information infrastructure vs. (b) supporting an organization's business processes. A specialist infrastructure project will probably support business processes indirectly; a generalist business process application does so directly. From the point of view of the organization, determining whether the system under consideration going to provide an
PDFmyURL.com

architectural interface or a process interface is usually fairly straightforward. Both architecture and business process applications play a key role in providing information support for organizational activities, and neither are productive without the other -- but the two represent very different kinds of projects. Infrastructure projects are largely technical in nature: for example, they ensure that a network performs to selected engineering parameters, they build data models that deliver information on demand, they define information architecture. Process projects support specific workflows and provide an interface to business processes in order to leverage the work of organizational participants. They tend to be closer to what are commonly considered "applications-specific" projects. RAD teams provide the cross-functional contacts and focus to build process-oriented applications that are generalist -- they tend to focus on business problems more than technical problems. RAD prototyping techniques provide a mechanism for cycling through multiple requirements definitions quickly. RAD's time-boxed release strategy provides tactics for managing the complexity of business applications as they evolve, raising the possibility of a virtuous cycle in which business processes and information support evolve in complementary directions. RAD's strengths, however, are potential weaknesses for highly technical infrastructure projects. Such projects require modeling because they must prepare data for multiple future uses, even unforeseen uses. Identifying the structure within such projects can be difficult and time-consuming because it requires careful analysis at potentially difficult levels of abstraction. For such projects a JAD or SDLC approach might be more productive. Figure 8: Met hodologies and Project Charact erist ics

Figure 8 compares the suitability of development techniques across different types of development projects, using the criteria of business
PDFmyURL.com

problem structure and organizational interface role. The result suggests the important role that RAD can play in supporting interfaces for key business processes, but the necessity of maintaining expertise in SDLC and JAD in order to provide the infrastructure and architecture on which RAD projects can build. In practice, successful RAD-built systems are often constructed atop infrastructures and legacy systems that are best developed by SDLC and JAD. In many instances, RAD would not have a high probability for success without the base of systems built using the other techniques. Int erlinked development : an example Consider, as an example, the case of a large Northeastern insurance company which provided world-class customer service using a reengineered client teleservicing facility at its home office. To provide this service, each customer service representative fielded questions from clients over the telephone, sometimes answering as many as 40 calls a day. Reps were supported by a sophisticated information system that provided all of the company's knowledge about any client (e.g., name, address, policies held, past contact history, prior questions) in less than 10 seconds after the telephone rang. The system that supported the reps was designed, built, and implemented by a RAD team which delivered the first release of the system in less than twelve months. The system collected legacy data from multiple mainframe sources and added to it call tracking information from newly-designed custom databases, using a graphical user interface that decreased the number of screens reps had to use and reduced training time for new reps. RAD advocates would call this an unquestioned victory for their technique. They would be wrong. It was true that the RAD team was very successful in defining and delivering the system and its user interface in a short time. The RAD-built system, however, employed a specific client file structure that enabled reps to collect information about all known policies for any given client. This client file represented a data model that took two years to build and that had required careful JAD modeling to complete. Prior to the client file project, the only way that the insurance company had been able to retrieve information about a client was by policy number. Developers associated with the RAD team reported that it was highly unlikely that the RAD project would have been successful if response time had depended on access by policy number. Furthermore, they believed that the client file structure would have been difficult to develop using RAD techniques because it encompassed technical requirements that were beyond the experience and interest of system sponsors, represented work that relied heavily on the internal expertise of the information systems department, and required long hours of abstract data analysis involving legacy systems. The moral of the story? RAD pays off -- if you have the infrastructure in place. Developing that infrastructure, however, requires system development techniques that are in some ways the opposite of RAD: modeling-oriented where RAD is prototype-oriented, exhaustive where RAD focuses on time-boxed features, and thorough where RAD is iterative. Using SDLC to deliver structured systems and JAD to assist in building infrastructure, an organization can exploit the advantages of RAD techniques. Without infrastructure support in place, RAD projects may surface more costly problems. Conclusion
PDFmyURL.com

This report considers the trends underlying three major systems development techniques: SDLC (Systems Development Life Cycle), JAD (Joint Application Development), and RAD (Rapid Application Development). It discusses how the three methodologies, often seen as mutually exclusive, really represent solutions that place differential emphasis on common elements of the system design problem. Understanding the similarities and differences between these approaches can help managers understand the strengths and limitations of each. Each systems development methodology demonstrates the influence of the technology, economics, and organizational issues current at the time that it was first defined. This paper traces SDLC to the use of expensive mainframes to understand transactions, JAD to the need for managing data distribution following the advent of minicomputers, and RAD to the development of business process support based on networked client/server workstations. Each methodology exhibits different strengths and weaknesses. SDLC provides tools for controlling details within large development projects that solve structured problems. JAD enables the identification, definition, and implementation of information infrastructures. RAD supports the iteration and flexibility necessary to building robust business process support. As business problems become increasingly crossfunctional and unstructured, RAD proves increasingly useful. RAD's success in practice, however, may depend on the quality of the systems architecture and information infrastructure already in place within an organization. Architecture and infrastructure project success, in turn, may benefit from the strengths of SDLC and JAD rather than RAD. For information systems managers, matching projects with appropriate development techniques has become a more complex problem. This report suggests ways to distinguish development project characteristics that assist in identifying an appropriate development technique. These include (1) analyzing the structure inherent in a business problem by asking how readily system requirements can be defined, and (2) inquiring carefully into the system's role as specialist technical infrastructure or generalist process support. These two dimensions provide a framework for making choices between SDLC, JAD, and RAD. RAD proves most useful for systems support of unstructured business processes, SDLC best for highly structured specialist systems, and JAD for semi-structured data infrastructure projects. A carpenter would not use a sledgehammer to remove a fly, nor a tackhammer to drive a wedge. I/S managers face similar decisions of scale and scope as they apply development methodologies to their systems portfolios. The key is to understand the characteristics of a development project well enough to understand which development technique is likely to meet with greatest success. Find the right hammer.

PDFmyURL.com