faculty.babson.edu osborn cims rad.htm

8/2/2019 Faculty.babson.edu Osborn Cims Rad.htm

1/14

SDLC, JAD, and RAD:Finding the Right Hammer

1995 Charles S. OsbornAssistant Professor, Informat ion Systems

Babson College

Center f or Information Management StudiesWorking Paper 95-07

Babson Hall 323Babson Park, MA 0257-0310

Tel. 617.239.5585Fax 617.239.6416

[email protected]

Table of Contents

AbstractIntroductionThe systems development problem

Figure 1: The Systems Development CycleSequencing

Figure 2: Systems Development SequencingFigure 3: Key Activity Comparison

Requirements definitionApproval processesOrganizat ional coordination

Design techniques in contextFigure 4: Technology and Methodology EvolutionEconomic and organizational background

Figure 5: Key TrendsSDLC vs. JAD vs. RAD: different strengths, different limitations

Figure 6: A Comparison of Development Techniques

PDFmyURL.com
http://faculty.babson.edu/osborn/cims/rad.htm#SDLCvsJADvsRADhttp://faculty.babson.edu/osborn/cims/rad.htm#Fig2http://pdfmyurl.com/?otsrc=watermark&otclc=0.01http://pdfmyurl.com/?otsrc=watermark&otclc=0.01http://faculty.babson.edu/osborn/cims/rad.htm#Fig6http://faculty.babson.edu/osborn/cims/rad.htm#SDLCvsJADvsRADhttp://faculty.babson.edu/osborn/cims/rad.htm#Fig5http://faculty.babson.edu/osborn/cims/rad.htm#EconOrglBackgroundhttp://faculty.babson.edu/osborn/cims/rad.htm#Fig4http://faculty.babson.edu/osborn/cims/rad.htm#DesignTechniquesInContexthttp://faculty.babson.edu/osborn/cims/rad.htm#OrgCoordnhttp://faculty.babson.edu/osborn/cims/rad.htm#ApprovalProcesshttp://faculty.babson.edu/osborn/cims/rad.htm#ReqDefnhttp://faculty.babson.edu/osborn/cims/rad.htm#Fig3http://faculty.babson.edu/osborn/cims/rad.htm#Fig2http://faculty.babson.edu/osborn/cims/rad.htm#Sequencinghttp://faculty.babson.edu/osborn/cims/rad.htm#Fig1http://faculty.babson.edu/osborn/cims/rad.htm#SysDevelProblemhttp://faculty.babson.edu/osborn/cims/rad.htm#Introductionhttp://faculty.babson.edu/osborn/cims/rad.htm#Abstract


2/14

A framework for development port foliosFigure 7: Choosing MethodologiesFigure 8: Methodologies and Project CharacteristicsInterlinked 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 asmutually 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 ofeach.

Each methodo logy's strengths demonstrate t he technology, economics, and organizat ional issues current at the t ime that it was firstdefined. SDLC provides tools for controlling details within large development projects that solve structured problems. JAD enables theidentif icat ion, definition, and implementat ion of information infrastructures. RAD supports the iteration and f lexibility necessary for buildingrobust business process support .

As business problems become increasingly cross- funct ional and unstructured, RAD may prove increasingly useful. RAD's success in practice,however, may depend on the quality o f the systems architect ure and information infrastructure already in place within an organization.Architect ure and infrastruct ure project success, in turn, may benefit f rom the strengt hs of SDLC and JAD rather than RAD. For informationsystems managers, matching projects with appropriate development techniques has become a more complex problem.

This report suggests ways to dist inguish development project characteristics that assist in identifying an appropriate developmenttechnique. These include (1) analyzing the st ructure inherent in a business problem by asking how readily system requirements can bedefined, and (2) inquiring carefully into the system's role as specialist technical infrastructure or generalist process support. These twodimensions provide a framework fo r making choices between SDLC, JAD, and RAD.

A carpenter would not use a sledgehammer to remove a f ly, nor a tackhammer to drive a wedge. I/S managers have an increasing variety ofchoices 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 systemsdevelopment methodologies t ypically perceived as so dramatically diff erent that arguments between their advocates somet imes resemble

PDFmyURL.com
http://pdfmyurl.com/?otsrc=watermark&otclc=0.01http://pdfmyurl.com/?otsrc=watermark&otclc=0.01http://faculty.babson.edu/osborn/cims/rad.htm#Conclusionhttp://faculty.babson.edu/osborn/cims/rad.htm#Examplehttp://faculty.babson.edu/osborn/cims/rad.htm#Fig8http://faculty.babson.edu/osborn/cims/rad.htm#Fig7http://faculty.babson.edu/osborn/cims/rad.htm#FrameworkDevelPortfolios


3/14

religious war. Examining the economic, organizational, and technical trends underlying the evolution of these techniques, however, suggestsa diff erent perspective -- o ne that understands t hese three approaches as largely interrelated and complementary. Awareness of theseconnections can help technology and business managers shape decisions that improve the financial and operational success of largedevelopment 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 t he meaningful diff erences between t hese techniques, and (2) in what context s will each be mostsuccessful? Using the f ramework can assist managers in structuring their systems development portf olios to best f it t he business and

system contexts o f the problems that individual development projects are t rying to solve.

The systems development problem

At a relatively high level of abst raction, all systems development projects at tempt t o so lve the same problem -- t he definit ion, const ructionand delivery of a business-purpose comput ing application - - and use a phased approach to do so . Over time, the phases of this approachhave become enshrined in the familiar development cycle that includes (1) defining requirements, (2) designing an information system to fitthose requirements, (3) building the code to deliver that system, and (4) testing to see whether the code works and the system does the jobit was intended to do.

Researchers, consultants, and industry observers tend to have their own lists for t hese phases; some have more steps that t hose listed

above (sometimes hundreds more), but most compress t o some version of define/design/build/test cycle. Figure 1 shows this cycle as aschematic that emphasizes lessons learned early by practicing software engineers: development is iterative and circular, easier to start thanto f inish, and of ten evolut ionary in nature.

Figure 1: The Syste ms Development Cycle

SDLC, JAD, and RAD offer different responses to these development cycle characteristics. Each method approaches the development cyclewith diff erent assumptions about sequencing, diff erent expectat ions about act ivit ies that occur in each phase, and diff erent presumptionsabout organizat ional collaboration.

PDFmyURL.com
http://pdfmyurl.com/?otsrc=watermark&otclc=0.01http://pdfmyurl.com/?otsrc=watermark&otclc=0.01


4/14

Sequencing

Traditional SDLC techniques carefully defined each phase of the development cycle into multiple project activities that were strictlysequenced. In t his so-called "waterfall" approach, the outputs of all prior development work were prerequisites f or each step in the process.The classic waterfall approach focused great eff ort on ensuring that all details of requirements def inition were documented before designbegan, that design was completely finished before code was produced, and that test ing 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 systemdetails. Protot yping played an increasingly important role in translat ing model att ributes into system features.

RAD compresses all phases of the cycle into intensive work delivered by small, cross-functional teams. Prototyping receives primaryemphasis, superseding both written specifications and data models. Iteration evolves into collaboration across parallel activities usingtechniques similar to concurrent engineering. Figure 2 suggests the degree to which resequencing enables RAD teams to shrinkdevelopment schedules.

Figure 2: Systems Development Sequencing

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

Figure 3: Key Activity Comparison

PDFmyURL.com


5/14

Requirements def inition

SDLC emphasizes formal requirements definition documents that build a detailed description of the system on paper before any code isproduced. These documents normally include narrative descriptions, data definitions, and sample screens. Producing a thorough, often multi-volume description o f system requirements can become such a time-consuming task that it begins to extend the expected life of adevelopment project .

JAD tends to rely on data models to provide requirements def init ion and protot ypes to capture f inal design details. In theory, data modelingcan produce tho rough system specifications more quickly t han SDLC narratives, especially through t he use of computer-aided soft wareengineering (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 detailsof all requirements befo re proceeding further.

RAD relies on a series of iterative prototypes to specify and document requirements. The technique reverses the scheduling emphasisnormally found in SDLC projects by setting a rolling series of release dates and dynamically adjusting system features to fit. Iteratingproto types gives requirements t he opportunity to evolve and the f lexibility to change: the more rapid the iterations, the more flexibilityavailable for requirements def inition. Using a "time-boxed" implementation plan means that f eatures which prove to o dif ficult t o add to o nerelease can be added to future releases. In practice, a working protot ype can provide a large amount of information about system designdetails in a concise fashion, especially when used with component-based development too ls whose third-party modules are to some degreepre-documented.

Approval processes

SDLC tends to rely on formal approvals that signify the handof f of project materials from one specialized organizational funct ion to another.The approval of ten takes the form of negotiat ion over the content o f do cuments describing design promises about system features.Building consensus around the commitments that t hese promises represent is of ten a diff icult and political task. The fact t hat t here is of tena large volume of material to review and understand, some of it relating to technical details that can have unexpected implications f or howthe final system f unctions, only makes it more diff icult t o 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 tocapture system characteristics, especially when paired with semi-automatic code generation facilities found in many CASE tools. When used

PDFmyURL.com


6/14

as the basis for approval cycles, however, they carry the potential risk of being more readily understood by systems designers than bysystem sponsors. Asking system sponsors t o study pages (and sometimes volumes) of models is not always a successful strategy f ornegot iating the consensus needed for well-info rmed system design approval.

RAD replaces fo rmal documents and models with working prot ot ypes. The f ocus on working code concatenates the consensus-buildingneeded for approving system features. It is easier for a system sponsor t o look at a protot ype and understand whether it will work than it isfor him or her to read a description (whether narrative or model-based) and extrapolate its success. It is easier for a developer tounderstand 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 f eatures are most appropriate f or a given business process if a working prot ot ype of the system can be applieddirectly to the process while being analyzed for strengths and shortfalls. When this approach works successfully, especially as applied insmall RAD teams, approval can become a fo rmality that occurs aft er consensus has been reached, rather than an extended negot iationprocess for adjudicating agreements.

Organizational coordination

The differences between SDLC, JAD, and RAD design described here indicate some key differences in the organizational assumptionsunderlying each method. SDLC builds systems based on a presumption of full specialization of tasks, with each participant a representativeof an organizational specialty. Connections between specialties -- bet ween system sponsors and system designers, for example -- aremanaged on an arms-length basis using the mechanism of a f ormal approval process based on extensive documentation. The same is of tentrue within I/S departments when system designers and system builders use SDLC to apportion responsibilities and, retroactively, sometimesassign blame.

JAD's use of modeling is intended to support direct collaboration during system design. That co llaboration is expected t o producedocumentation that can be satisfactorily delegated and specialized during building and testing. Model-building, as a collaborative exerciseinvolving both system designers and system sponsors, can effectively capture system requirements in a relatively short time. In practice,however, the pot ential complexity o f modeling methods and the t ime-consuming discussions needed to verify models sometimes mean thatthis task is handled with a delegation/reporting/negot iation/approval cycle, leading to many of the pitf alls of SDLC.

RAD's use of small teams and t ight proto typing schedules forces a dif ferent approach. Here, in effect, representat ives of all theorganizat ional functions t hat need to decide on system features are locked in a room unt il they reach agreement. Reaching agreementmeans moving through enough protot ypes so t hat 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. Sinceproto types are incremental and f requent, large "show-stopping" problems either surface very early or don't accumulate. Although t he team-based model requires giving very careful consideration to the knowledge and authority of team members, it provides what one systemdevelopment manager calls an "in-your-face accountability" t hat is very diff icult t o duplicate ot herwise.

Design techniques in context

PDFmyURL.com


7/14

To understand the evolution of three so apparent ly dif ferent system methodologies it may be useful to review the economic andorganizational contexts within which each developed. Doing so suggests that SDLC, JAD, and RAD actually represent a natural progressionof methods t hat respond to dif ferent technologies and organizat ional needs. Economic constraints, influenced by the characteristics of newtechnology, have also played a role.

Consider three broad trends in hardware and sof tware that have evolved over the past four decades. In the 1960s, mainframes provided theonly 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 theirappearance, bringing open, third-party operating syst ems such as MS-DOS. Shrink-wrapped sof tware became a commercial reality. In the1990s, concepts of client-server computing have developed from t his 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 Figure4). SDLC developed to build mainframe-based systems using customized code developed in-house by large teams of analysts andprogrammers. These projects, born of the data processing era, of ten focused on capturing and recording large numbers of t ransactions as af irst st ep towards organizing corporate data (although the t erm used at t he time was "automation"). By contrast to many managerialsystems being developed to day, the auto mation o f existing t ransactions represented a relat ively structured problem: the challenge was toensure that t he system adequately captured the details of t ransactions and accounting systems that were already reasonably wellunderstood.

Figure 4 : Technology and Methodology Evolution

JAD developed in an era when minicomputers had made the promise of departmental computing a reality and organizations were challengedto build infrastructure systems that could capture corporate information in flexible, reusable data st ructures. For this purpose, modeling wasa useful so lution. The advent of third-party CASE too ls (partly supported by the graphics technology available on minicomputers) assisted in

PDFmyURL.com


8/14

applying systematic techniques to modeling data designs. JAD supplied mechanisms for articulating the abstractions needed to understandenterprise 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 at tempted to build client/server applications t hat leveraged existing infrastructure through the use of layeredhardware architect ures and distributed databases. In many cases RAD provided an application-f ocused f ront end to architectural solutionswhose components were built with SDLC and JAD. RAD projects made heavier use of third-party too ls fo r both design and for codegeneration. 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 sof tware, to the degree that some RAD projects now spend more timestitching 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 o rganizations have ident ified new needsfor systems support. Each trend has influenced the perspectives and assumptions behind SDLC, JAD, and RAD methodologies. Thesechanges are summarized in Figure 5.

When SDLC developed, each increment of comput ing power (e.g., a mainframe) cost millions of dollars apiece, and only t echnical specialistsunderstood t he black art o f programming. The installed base of machines was too small to support widely-available sof tware tools,

especially considering the f ragmentat ion caused by proprietary operat ing systems. The result of high investment costs and customcraftsmanship meant that correcting mistakes encountered in the field was prohibitively expensive. SDLC developed to minimize theoccurrence of mistakes at the time of system implementat ion.

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, especiallyinterface design, were of secondary importance. So long as t ransactions were captured correct ly, the system "wo rked" - - and t hen-currenttechnology off ered a fairly short list o f interface opt ions for capturing data. To the degree that automation cont ributed to st reamlining

PDFmyURL.com


9/14

operations and cutt ing costs, it of ten was easier to redesign operations around the computer system than to design the system to f itt ight ly within an organizat ional process.

Minicomputers lowered the incremental investment for I/S support f rom millions t o hundreds of thousands of dollars and generated a largerinstalled base of machines. For a departmental system whose costs were an o rder of magnitude lower than its mainframe-basedpredecessors and whose design was assisted by semi-automated CASE documentation, correcting a programming error upon applicationdelivery no longer represented a risk of organizational paralysis. Instead, the risk shifted from code management to data management asorganizat ions began to understand the dangers of departmental data proliferation.

JAD evolved part ly as a response to t he emerging need for functional corporate data infrastructures that enabled both data cont rol anddata distribution. Minicomputers provided useful distribution points, and experience with departmental applications began to spread systemdesign experience beyond the technical specialists who understood mainframes. JAD's focus on data modeling provided useful tools fordata 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 early1990s changed the context within which systems were developed. As networks connected multi-layered hardware architectures ofmainframes, minicomputers, and personal computers, it became necessary t o focus o n bot h infrastructure and interface. Personalcomputers (PCs) and workstat ions provided enough desktop computing power to enable new approaches to interface design. Data-awareinfrastructures, where these existed, enabled the delivery of information t o interface engines at t he t ime and place where the information

was most needed by key business processes.

At the same time, business trends popularized by such concept s as reengineering increased competitive pressures to improve corporateresponse times and improve cost structures. Equipped with wo rkstat ion-based technology whose incremental investment cost was only inthe tens of thousands of do llars rather than the millions, and exploiting newly-commercialized sof tware that o f fered the opportunity t odesign consistent graphical user interfaces (GUIs) for new applications, business units began to focus on using information systems toimplement new, cross-functional business process designs. The relationships between process and computing power that had existed in themainframe world reversed: no longer did the process have to conform to the computing power that supported it. Now it was possible todesign an interface specifically intended to adapt t o a new business process design, and use computing power to deliver data to thatinterface when and as needed. In many respects, moreover, this approach of fered the o pportunity to support less-structured managementprocesses that resulted in dramat ic performance improvements and st ronger competitive position.

This shif t soon revealed that (1) cross-funct ional process designs were not well served by system designs that insisted on t he fo rmalseparation of specialists, and (2) the time required to prepare and document formal SDLC analyses - especially for applications thatcont ributed t o defining unstructured problems -- was unacceptably long. Af ter several years of experience with PC-based sof tware anddatabases, managers in line departments oft en emerged with more understanding of the potential (and limitat ions) of information systemsthan had been the case when corporate processing power had remained centralized in the mainframe's glass house. As client/server toolsbegan to emerge that promised the scalability required to expand working protot ypes to production volumes in a controlled fashion,organizat ions began to recognize t he value of small, cross-functional development teams that immersed a carefully-selected group o fskilled practitioners in close proximity for a relatively brief but intensive project period, leading to systems that could perform real work within

PDFmyURL.com


10/14

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

SDLC vs. JAD vs. RAD: different st rengths, diff erent limitations

From this perspective, then, SDLC, JAD, and RAD represent different points along a continuum of system design choices. Each has itsstrengths and each its weaknesses. SDLC provides the care and precision needed to computerize large volumes of well-understoodtransactions, but does not necessarily provide the f lexibility t o match system development speed to process redesign eff orts. JAD provides

the to ols fo r understanding data infrastructures and building the abst ractions necessary for articulating organizat ional info rmat ion flows,but does not necessarily capitalize on the need to develop and deliver interfaces that align closely with cross-funct ional processrequirements. RAD can build interfaces and roll prototypes into production code at speed and under acceptable control, and is well-suitedfor developing systems t o support high-level, unstructured processes. RAD tends, however, to provide neither the cont rol needed to buildlarge transaction systems nor t he to ols and time needed to implement broad infrastructures.

Figure 6: A Comparison of Development Techniques

Figure 6 summarizes t his comparison. It suggests that RAD's strengths lie in building interface-oriented systems that support unstructuredbusiness problems and already have a data infrastructure and transactions source to build upon. It emphasizes the importance of JAD andSDLC in providing the foundation of architecture and data without which RAD teams seldom deliver useful product. At t he same time, itsuggests retaining JAD and SDLC techniques for those areas where their development strengths can be put to best use. In this sense, thisperspective su ests that the best s stems development approach is not an one method but rather a carefull chosen mix of t echniques.

PDFmyURL.com


11/14

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 canprovide the greatest leverage. In diff erent contexts, diff erent t echniques are likely to increase the chances of success. Figure 7 suggestssome of the contexts in which SDLC, JAD, and RAD would be a productive choice.

Figure 7: Choosing Methodologies

What criteria determine when to use RAD and when to use other techniques? A useful analysis suggests f ocusing on the characteristics ofthe business problem to be solved and the characteristics of interface to be def ined. This not ion takes concepts familiar to systemsdesigners and adapts them slight ly to emphasize differentiating between t echniques.

Business problems can distinguished according to the requirements criteria familiar to SDLC practitioners, but rather than asking whatrequirements are, this analysis suggests asking how readily requirements can be defined. Applications whose requirements are obvious arereasonably well-understood and so can be considered relatively structured. Applications whose requirements are likely to change frequentlyduring development are not well understood and should be considered unstructured. As structure decreases, the likelihood that RADtechniques will prove useful increases.

The second dimension f ocuses on interface questions, but again shifts the perspective typically found in traditional development. Instead ofasking what t he (user) interface needs to be, it suggests f ocusing on the role of the system as an organizational interface . This means askingwhat role the system will play in (a) supporting an organization's information infrastructure vs. (b) supporting an organization's businessprocesses. A specialist inf rastructure project will probably support business processes indirectly; a generalist business process applicationdoes so directly. From the point o f view of the organizat ion, determining whether t he system under consideration go ing to provide an

PDFmyURL.com


12/14

architectural interface o r a process interface is usually f airly straightforward.

Both architecture and business process applications play a key role in providing information support for organizational activities, and neitherare productive without the o ther -- but the two represent very dif ferent kinds of projects. Infrastructure projects are largely technical innature: for example, they ensure that a network perfo rms to selected engineering parameters, they build data models that deliverinformation o n demand, they def ine info rmat ion architect ure. Process projects support specif ic workflows and provide an interface tobusiness processes in order to leverage the work of organizat ional participants. They tend to be closer to what are commonly considered"applicat ions-specif ic" projects.

RAD teams provide the cross-functional contacts and focus to build process-oriented applications that are generalist - - t hey tend to f ocuson business problems more than technical problems. RAD prototyping techniques provide a mechanism for cycling through multiplerequirements definitions quickly. RAD's time-boxed release strategy provides tactics for managing the complexity of business applications asthey evolve, raising the possibility of a virtuous cycle in which business processes and information support evolve in complementarydirections.

RAD's strengths, however, are potential weaknesses for highly technical infrastructure projects. Such projects require modeling becausethey must prepare data f or multiple future uses, even unforeseen uses. Identifying the structure within such projects can be diff icult andtime-consuming because it requires careful analysis at potentially difficult levels of abstraction. For such projects a JAD or SDLC approachmight be more productive.

Figure 8: Methodologies and Project Characteristics

Figure 8 compares the suitability of development t echniques across diff erent types of development projects, using the criteria of business

PDFmyURL.com


13/14

problem structure and organizat ional interface role. The result suggests t he important role that RAD can play in supporting interfaces forkey business processes, but the necessity of maintaining expertise in SDLC and JAD in order to provide the infrastructure and architectureon which RAD projects can build.

In practice, successful RAD-built systems are of ten const ructed atop infrastructures and legacy systems t hat are best developed by SDLCand JAD. In many instances, RAD would not have a high probability f or success without the base of systems built using the othertechniques.

Inte rlinked deve lopment: an example

Consider, as an example, the case of a large Northeastern insurance company which provided world-class custo mer service using areengineered client teleservicing facility at its home office. To provide this service, each customer service representative fielded questionsfrom clients over the telephone, sometimes answering as many as 40 calls a day. Reps were supported by a sophisticated informationsystem that provided all of the company's knowledge about any client (e.g., name, address, policies held, past contact history, priorquestions) in less than 10 seconds af ter the t elephone rang. The system that supported t he reps was designed, built, and implemented by aRAD team which delivered the f irst release of the system in less than twelve months. The system collected legacy data f rom mult iplemainframe sources and added to it call tracking information from newly-designed custom databases, using a graphical user interface thatdecreased the number of screens reps had to use and reduced training time for new reps.

RAD advocates wo uld call this an unquestioned victory fo r their technique. They would be wrong. It was t rue that the RAD team was verysuccessful in defining and delivering the system and its user interface in a short time. The RAD-built system, however, employed a specificclient file structure t hat enabled reps to collect information about all known policies for any given client . This client f ile represented a datamodel that t ook two years to build and that had required careful JAD modeling to complete.

Prior to the client f ile project , the only way that the insurance company had been able to ret rieve info rmation about a client was by policynumber. Developers associated with the RAD team reported that it was highly unlikely that the RAD project would have been successful ifresponse time had depended on access by policy number. Furthermore, they believed that the client file structure would have been difficultto develop using RAD techniques because it encompassed technical requirements that were beyond the experience and interest o f systemsponsors, represented work that relied heavily on the internal expert ise of the information systems department, and required long hours ofabstract data analysis involving legacy systems.

The moral of the sto ry? RAD pays off -- if you have the infrastructure in place. Developing that infrastructure, however, requires systemdevelopment techniques that are in some ways the opposite of RAD: modeling-oriented where RAD is protot ype-oriented, exhaustive whereRAD focuses on time-boxed features, and thorough where RAD is iterative. Using SDLC to deliver structured systems and JAD to assist inbuilding infrastructure, an organization can exploit the advantages of RAD techniques. Without infrastructure support in place, RAD projectsmay surface more costly problems.

Conclusion

PDFmyURL.com


14/14

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 asmutually 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 ofeach.

Each systems development methodology demonstrates t he influence of the technology, economics, and organizat ional issues current atthe time that it was f irst defined. This paper traces SDLC to the use of expensive mainframes to understand t ransactions, JAD to the need

for managing data distribution following the advent o f minicomputers, and RAD to the development o f business process support based onnetworked client/server workstat ions.

Each methodology exhibits different strengths and weaknesses. SDLC provides tools for controlling details within large developmentprojects that solve structured problems. JAD enables the ident ification, definition, and implementation of information infrastructures. RADsupports the iteration and flexibility necessary to building robust business process support. As business problems become increasingly cross-functional 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 placewithin an organizat ion. Architect ure and infrastructure project success, in turn, may benefit from the strengths o f SDLC and JAD rather thanRAD. For information systems managers, matching projects with appropriate development techniques has become a more complex problem.

This report suggests ways to dist inguish development project characteristics that assist in identifying an appropriate developmenttechnique. These include (1) analyzing the st ructure inherent in a business problem by asking how readily system requirements can bedefined, and (2) inquiring carefully into the system's role as specialist technical infrastructure or generalist process support. These twodimensions provide a framework for making choices between SDLC, JAD, and RAD. RAD proves most useful for systems support ofunstructured business processes, SDLC best for highly structured specialist systems, and JAD for semi-structured data infrastructureprojects.

A carpenter would not use a sledgehammer to remove a f ly, nor a tackhammer to drive a wedge. I/S managers face similar decisions of scaleand scope as they apply development methodologies to their systems portf olios. The key is to understand the characteristics of adevelopment project well enough to understand which development technique is likely to meet with greatest success. Find the right hammer.

PDFmyURL.com

faculty.babson.edu osborn cims rad.htm

Documents