RAD_risks (Journal Pendukung)

8/16/2019 RAD_risks (Journal Pendukung)

1/12

COMMUNICATIONS OF THE ACM 177

Proliferating information systems (IS) application development backlogs and ever-escalating business demands for applications software have resulted in a constantsearch by IS organizations for paradigms and tools that accelerate the pace of softwaredevelopment. Along with rapid application development (RAD), technologies suchas CASE, object-oriented development, client/server computing, and flexible mid-dleware are being hailed as potential solutions to the software crisis [11]. Althoughindustry experience with these paradigms is mixed, the benefits of such technologiesare acknowledged—at least with regard to improvements in development productivi-

ty and application delivery times [3]. While no universal definition of RAD exists, it can be characterized in two ways: asa methodology prescribing certain phases in software development (similar in principleto the spiral, iterative models of software construction), and as a class of tools that allow for speedy object development, graphical user interfaces, and reusable code forclient/server applications. Indeed, the tools and methodology are inextricably linked:the tools enable the methodology and circumscribe what is accomplished during a development project. In a world dominated by deadlines and irate users, where com-petitive advantage can depend on how quickly software is developed to support new business, RAD is certainly appealing. The popular press extols its virtues with adjectiveslike “evolutionary,” “iterative,” “interactive,” and “dynamic,” emphasizing the delivery rate increases facilitated by RAD, which range from 25% to 1,000% [4].

But software development does not conclude with speedy application delivery. For

the true benefits of the technology to be realized, the applications must exhibit reusabil-ity and maintainability so that total life-cycle costs are reduced. Surprisingly little timehas been spent determining if the value of RAD tools to business extends beyond the

Ritu Agarwal ([email protected]) is an associate professor at the Robert H. Smith School of Business, University of Maryland, College Park, MD. Jayesh Prasad ([email protected]) is an associate professor in the Department of MIS andDecision Sciences, University of Dayton, Dayton, OH.Mohan Tanniru ([email protected]) is Professor and Director of the Applied Technology in BusinessProgram at Oakland University, Rochester, MI. John Lynch is a senior consultant with Vertechs Software Solutions, Atlanta, GA.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copiesare not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy

otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

© 2000 ACM 0002-0782/00/1100 $5.00

Risks of Rapid Application Development

Ritu Agarwal, Jayesh Prasad, Mohan Tanniru, and

John Lynch


2/12


next deadline or the next deliverable. RAD methodologies are clearly needed to producesoftware quickly, and a compressed development life cycle requires powerful RAD tools.But knowledge of how to incorporate RAD tools into an IS shop’s tool kit and the long-term implications of current usage patterns of RAD is woefully limited. Systems devel-opers are assumed to be receptive to the new tools; indeed, the prevailing view amongstIS management appears to be “If we buy it, they will come.” But mandating technolo-

gy usage has long been recognized as an inappropriate management tactic for obtaining buy-in and commitment from systems developers. Management must identify the typesof developers more likely to respond positively to RAD. Another perhaps unsubstanti-ated claim of RAD technology is its ability to build higher quality systems that are moremaintainable, reusable, and extensible [10]. Questions regarding precisely how RADtools are used remain unanswered. What are the pitfalls of RAD, and will the method-ology truly address the software crisis? Will RAD tools provide business value in thelong-run, or do caveats exist that managers should be sensitive to?

In this article, we focus first on the steps needed to implement RAD tools, including the types of developers more likely to be receptive to the technology and how it shouldbe positioned to maximize acceptance; and second, on usage patterns of RAD tools andtheir relationship to perceived benefits. The research strategy utilized is one of triangu-lation: we use a broad-based cross-company survey to determine patterns of diffusion

and use, and to generate plausible explanations. We then verify explanations using rich-er data through interviews with practicing managers and analysts using the technology.One RAD tool that supports all the features commonly associated with RAD was select-ed to control for possible variance arising from the tool itself. The results are somewhatdisturbing in regard to the changes in the development life cycle being wrought by thetools.

The RAD Phenomenon James Martin coined the term RAD in the early 1990s to distinguish the methodol-ogy from the traditional waterfall model for systems development. “RAD refers to a development life cycle designed to give much faster development and higher quality results than the traditional life cycle. It is designed to take maximum advantage of powerful development software that has evolved recently.” [9]. According to Martin,four fundamental aspects of fast development exist: tools, methodology, people, andmanagement. The quintessential characteristics of RAD tools include the capability for planning, data and process modeling, code generation, and testing and debugging.RAD methodologies encompass three-stage and four-stage cycles. The four-stagecycle consists of requirements planning, user design, construction, and cutover, whilein the three-stage cycle, requirements planning and user design are consolidated intoone iterative activity. In a typical RAD life cycle, the requirements specification anddesign phases consume approximately 30% of the total effort [9].

RAD teams typically consist of individuals with diverse skills and titles, including repository managers, data modeling experts, and construction experts. Effective man-agement of RAD necessitates managing the cultural change and potential resistanceassociated with the implementation of any new technology. First-generation RAD tools

suffered from the limitations inherent in their interpretive nature and inability to scaleup to enterprise-level production applications. Current RAD tools have overcome theseshortcomings and provide a range of varied functionality, including CASE features,visual programming, object creation, remote data access using SQL, and support for


3/12


multitier client/server architectures.

RAD ImplementationRAD technologies incorporate a fundamentally different approach to systems devel-opment than the dominant software development approaches of the last three decades[9]. RAD implies successive iteration, refinement, and an accelerated movement from

a prototype to a production system. As a tool it uses objects and message-passing metaphors, and emphasizes reusability, visual programming, and graphical user inter-faces. Given that the majority of IS professionals in the workforce today did notreceive formal training in such tools, issues exist related to acceptance of the new tech-nology. Extensive research on the acceptance of innovations suggests that imple-menting and managing new technologies poses challenges of considerable magnitude. We undertake an exploration of management interventions that can help facilitatethe assimilation of RAD technology using the research model shown in Figure 1. Themodel identifies three perceptions that have been consistently related to positive usageintentions, which predict actual usage of an innovation [1, 12]:

• Relative advantage assesses the extent to which a developer believes the technology represents an improvement over prior methods.

• Ease-of-use measures the perceived cognitive effort necessary to effectively utilizethe new tool.

• Compatibility measures perceived congruence of new technology with preferredmethods of accomplishing tasks.

The model identifies two additional factors, the study of which can also help formu-late management interventions: individual difference, and method-of-implementionvariables. Prior studies focused primarily on the internal psychological processes thatlead to acceptance of new technologies; few have focused on how management mightproactively influence the process of acceptance (as opposed to compelling technology use by edict). The individual difference variables of a developer include his/her: priormainframe and client/server experience and personal innovativeness with respect tonew information technologies.

Our selection of these variables was based on extensive research in learning theoriesand the diffusion of innovations. In the human-associative view of learning, the law of proactive inhibition suggests that prior experiences can affect the ability to learn new behaviors, depending on the extent of similarity between prior experiences and the new behavior to be learned. Similar experiences promote positive attitudes toward the new object while dissimilar experiences influence learning and attitudes negatively. Researchexamining skills transfer of systems analysts experienced in process-oriented modeling identified a performance deterioration when analysts moved to an OO modeling envi-ronment [2]; thus, empirical support exists for a persistent assumption in the IS com-munity—that developers with significant experience in more traditional systems con-struction methods have more difficulty accepting new development paradigms. Perhapstheir experience with the extensive discipline and structure associated with mainframe-based projects makes them skeptical of the seemingly ad hoc nature of RAD. “Theintroduction of a RAD life cycle is alarming and threatening to professionals comfort-able with an older and slower methodology,” notes Martin [9]. In addition to the priorexperience of a developer, his/her personal innovativeness in the domain of information


4/12


technology, defined as the propensity of an individual to try out any new informationtechnology, has also been shown to significantly influence behavior toward a technolo-gy innovation [8].

The method-of-implementation variable includes a measure of the speed of RADtechnology adoption, as well as a developer’s assessment of the scope of the change—the “radicalness” of its departure from existing software development and delivery par-

adigms. Gallivan et al. point out that strategies for the successful assimilation of any new technology necessitate attentiveness to the speed of its introduction into an orga-nization, as well as to the extent to which the change represents a radical as opposed toan incremental modification of current practice. The items used to measure each con-struct are shown in Table 1.

Understanding RAD Outcomes As noted previously, the goals of RAD use include faster software development, andbetter, more maintainable systems [9]. In addition, given that many RAD tools now incorporate OO design paradigms, IS shops that adopt RAD clearly expect down-stream reusability benefits. But it is not clear exactly how the usage of specific features

Table 1. Constructs and scales.


5/12


of RAD tools relates to benefits, or what features of RAD tools are even being uti-lized. The model presented in Figure 2 is used to explore the relationship betweenRAD tool usage and expected outcomes. Outcomes are categorized into two classesbased on a review of the literature. The global benefits class includes overall applica-tion development productivity, resource consumption, and overall management of software development projects. Specific outcomes represent more micro-level valueslike greater application development flexibility, reduced coding, and code reuse(Table 2). RAD tool features are organized into three categories, based on their rolesin the overall software development process. The project management class includesfeatures such as configuration and version management and team repository man-agement; the development class includes, among others, interactive debugging, screenlayouts and navigation, and GUI code generation; and the modeling class consists of data and business process modeling.

A Field Study of RADIn order to explore the key issues of RAD usage in IS organizations, a field study wasconducted in 1996. One RAD tool that incorporates all the functionality typically associated with such tools was selected as the target technology. This tool, currently available in Version 8, provides features such as an OO 4GL, visual programming tools, support for multiple operating system platforms, multitier capability, databaseindependence, and SQL support. A list of all registered licensees of the tool (173licensees in 39 businesses) was obtained from the vendor of the tool. A total of 36individuals from 19 organizations responded to a survey constructed to elicit the con-structs shown in the two research models mentioned previously, representing a

response rate of approximately 21% at the individual level and 49% at the company level. Sample demographics are provided in Table 3. The majority of the respondentsare systems developers with significant experience (an average of over 11 years) insoftware development, which was the intended target respondent class for RAD tools.

Table 2. Operationalizing the benefits of RAD.


6/12


The organizations using RAD tend to be reasonably large, with an average of approx-imately 2,800 employees, approximately 10% of whom work in IS. The bulk of theindustries represented are service-oriented, and thus their ability to deploy new IT

applications in a timely manner is often a major source of competitive advantage.Iivari points out that some of the early studies of IT process innovations such asCASE tools did not sufficiently ensure reliability and validity of the measures [7]. Theconstructs in the two research models are thus rigorously operationalized using previ-ously validated scales. As Tables 1 and 2 show, multi-item scales were utilized for allresearch constructs, except for two developer characteristics: prior mainframe experi-ence and prior client/server experience. These two were measured by survey questionsthat asked respondents the length of time they worked with both sets of technologies.RAD technology usage was assessed by asking respondents to rate the extent to whichthey utilized each feature of the tool in software development. Usage was scored on a 7-point scale, with the end points anchored at “Not at all used” and “Used wheneverappropriate.” Responses on all features belonging to a particular class were averaged toobtain a feature usage score for the class. A similar procedure was utilized for opera-

tionalizing the global and specific benefits of RAD. Descriptive statistics for all researchvariables, as well as scale reliabilities are shown in Table 4. The reliability values for allscales are indicative of high internal consistency. Multivariate procedures were utilizedto test both research models.

Table 3. Sample characteristics.


7/12


FindingsThe data reveals that on average, developers have neither overwhelmingly negative orpositive perceptions of the RAD tool. Recall that the first research model identifiedthe systems developers most likely to be most receptive to RAD and to transitionfrom old to new skills, and addressed how managers desiring to implement RADshould position it to developers. A multivariate analysis of variance (MANOVA) pro-cedure was utilized with developer characteristics and implementation characteristicsas independent variables, and the three salient perceptions about RAD as dependentvariables. The overall F-test for the MANOVA was significant; univariate testsrevealed that the personal innovativeness of an individual developer in the domain of information technology was a significant determinant of all three perceptions, whileprior client/server experience had a negative effect on perceptions of compatibility (Table 5). Among the implementation characteristics, the scope of the change had a

positive effect on all three perceptions.The second research model was also tested using a MANOVA procedure, because of the expectation that global benefits and specific benefits are likely to be correlated. Although the overall relationship between the two benefit categories and the three fea-ture sets was significant at p < 0.1, a significant coefficient was obtained only for theusage of development related features as a predictor of global benefits (ß = 0.379, t-value= 2.21, p < 0.05).

Discussion Although not reported here, several studies examining technology acceptance indicatethat perceptions about the RAD tool were significant predictors of usage intentions.Clearly, management needs to focus on developing positive perceptions about thenew technology to ensure its successful adoption into the IS organization’s tool kit.

Two developer characteristics among the determinants of perceptions—priorclient/server experience and personal innovativeness—emerged as significant predic-tors. An encouraging finding was the absence of a relationship between prior main-frame experience and perceptions about RAD—this relationship might have been

Table 4. Descriptive statistics.


8/12


predicted as negative because of the potential difficulties associated with moving to a new software construction paradigm. But experienced mainframe programmers donot appear skeptical with regard to the value of RAD. A negative relationship wasfound to exist between prior client/server experience and perceptions about RAD,perhaps because the prior client/server experience of these developers was primarily with non-OO technologies (that dominated early client/server implementations),and not with the OO paradigm. Finally, the positive relationship between personalinnovativeness toward information technology and RAD perceptions is encouraging.Consistent with Martin’s conceptualization of the mix of IT professionals in any orga-nization, the “experimenters” and “early adapters” are more likely to have positive per-ceptions about RAD technology [9]. Results for the speed of change implementationand scope of change suggest that it does not appear to matter how quickly RAD tech-nology is brought into the organization—what is critical is how the technology is pre-sented and positioned for the target developers. More radical changes were found toengender more positive perceptions, a finding that supports the commonly held view that software developers are motivated by work-related outcomes. Perhaps they are sofrustrated with the inability of extant development environments to allow them tomeet their work-related demands (to develop and deliver systems, and to meet criti-cal deadlines), that the more radical a change, the better its perceived ability to fill thegaps in the current technologies.

The relationship between usage of RAD tool features and perceived benefits was

examined to identify the source for the gains from RAD. The fact that only develop-ment-related features were significantly associated with global benefits was disturbing.If, in addition to speed, RAD tools are used to produce high quality, maintainable,reusable software, shouldn’t the usage of features such as project management and mod-

Table 5. Influences on developers’ perceptions about RAD.


9/12


eling emerge as highly correlated with perceived benefits? One explanation is that theseresults suggest a subversion of development methodology, and perhaps systems devel-opers are ignoring or side-stepping crucial phases in the development life cycle. Furthersupport for this explanation can be found in the fact that the difference between usageof development features compared with modeling features was statistically significant.1

Systems developers appear to be utilizing the features of the tool that allow them to

deliver systems in a speedy manner, but are not fully utilizing the features that con-tribute to longer-term quality and maintainability of systems. This confirms the sup-position articulated in a recent debate on RAD that “most RAD projects skip designand rigorous methodology altogether.”[10]

To gain further insight into the underlying issues our findings point to, we gatheredfollow-up data, with the intent of gaining a rich, qualitative understanding of the RADphenomenon as observed by systems developers. Particular emphasis was placed on any changes to the systems development process wrought by the technology. Four organi-zations, Alpha, Beta, Gamma, and Delta were targeted for interviews: two of which uti-lized the same tool that formed the basis for the survey. In order to ensure the resultsobtained were not idiosyncratic to the particular tool being studied, two organizationsusing a different RAD tool for software development were also included. Alpha is a large“information provider” that operates in the financial and insurance sectors. Its primary

line of business is providing information about consumers to retail companies. Forinstance, Alpha provides insurance companies with information about all previousclaims made by a new applicant for an insurance policy. Beta is a mid-sized utility com-pany that provides electricity and gas services to approximately one million customers.Gamma is a large investment bank that provides personal and institutional client bro-kerage services; it is in the top 10 of its kind, ranked internationally. Delta is a largemanufacturing organization that develops highly engineered products for a global mar-ketplace. In each case, interviewees were IS managers with direct responsibility for projects utilizing RAD tools. The interviews were structured around their experiences withRAD and their overall impressions of what changes the technology was instrumental inbringing about.

Comments from the Field All four organizations are developing mission-critical applications using RAD tools. Alpha’s major application under development is a system that will support about 400field offices of insurance companies. Beta is developing a system using a multitierclient/server architecture that will support all calls made to the utility during inclement weather. At Gamma, a broker’s workstation that will provide up-to-dateinformation on all client holdings is under construction. Delta is utilizing RAD forapplications ranging from support systems for product engineers to billing systems.Managers were consistent in their rationale for introducing RAD: “There is a lot of time pressure to deploy applications quickly,” said Beta managers. The project leaderfrom Alpha noted there was a lot of industry pressure to deploy these tools. The ISmanager at Gamma succinctly summarized why they elected to use RAD: “My jobis to satisfy client needs in a timely manner. Whatever I can do to meet these needs

in a more efficient way, I will.” At Delta, management’s expectations about RAD are

1 A t -tes t o f t he dif fere nce between usage of develop ment f eatu res and usage of modelin g feat ure s w as stat ist ica lly sig nif icant(t value = 8.81; p-value < 0.001).


10/12


11/12


must be paid to the developers who are first targeted for RAD and the manner in which the technology is brought into the IS organization. Developers who are per-sonally more innovative with respect to information technology and have greaterexposure to OO technology are inclined to respond to RAD with more alacrity. Theseindividuals can serve as key change agents in diffusing the technology more widely.Because such developers are likely to be more recent entrants into the software devel-

opment world, managers might wish to staff RAD projects with a mix of old and new skills, where the business knowledge and methodology commitment of experiencedstaff combines and diffuses synergistically with the receptivity to new technology of the newer developers. Managers also need to emphasize the magnitude of the changerepresented by RAD over previous approaches to software construction, perhapsthrough the use of information dissemination and training sessions. Training shouldnot focus only on imparting technical knowledge, but on underscoring the radicalimprovement RAD represents.

IS organizations adopt RAD methods and tools in an attempt to realize both pro-ductivity and quality benefits. Our results show that managers need to try to avoid thepitfall of allowing RAD capabilities to subvert good development practices. Martinnotes that “…higher quality, lower cost, and rapid development, thus, go hand in handif an appropriate development methodology is used” [9]. In a study of the factors affect-

ing reuse, Frakes and Fox found that a common software process and reuse education were important determinants of reuse, while the specific programming language orCASE tool were not [5]. The dominant driver of an individual developer’s behavior,only exacerbated by the increasing pressure from users, tends to be the next short-termdeliverable. Convincing such developers of the importance of up-front domain analysisand modeling represents a critical area for managerial emphasis if RAD is truly going tohelp alleviate the software crisis. At the very least, the decision by managers to yield toshort-term business pressures by sacrificing analysis and using RAD for speed alone (todeliver systems quickly that are intended to be fixed in later iterations)—should be aninformed decision, made after consideration of the implications on cost and quality inthe longer term. Clearly, this is an issue that merits widespread debate.

References1. Ajzen, I. and Fishbein, M. Understanding Attitudes and Predicting Social Behavior. Prentice-Hall,Englewood Cliffs, NJ, 1980.

2. Agarwal, R., Sinha, A.P., and Tanniru, M. The role of prior experience and task characteristicsin object-oriented modeling: An empirical study. International Journal of Human-Computer Studies 46 (1996), 639–637.

3. Banker, R. and Kauffman, R.J. Reuse and productivity in computer-aided software engineer-ing: An empirical study. MIS Quarterly 15, 3 (1991), 375–401.

4. Creegan, R.W. RAD may be the answer. Computing Canada 20 , 13 (June, 1994), 43.

5. Frakes, W.B. and Fox, C.J. Sixteen questions about software reuse. Commun. ACM 38 , 6 (June1995), 75–87.

6. Gallivan, M. J., Hofman, J.D. and Orlikowski, W. Implementing radical change: Gradual ver-sus rapid pace. In Proceedings of the 15th International Conference on Information Systems (Dec.14–17, Vancouver, BC) ACM/SIGBIT, New York, 1994, 325–339.

7. Iivari, J. Why are CASE tools not used? Commun. ACM 39 , 10 (Oct. 1996), 94–103.


12/12


8. Leonard-Barton, D. and Deschamps, I. Managerial influence in the implementation of new technology. Management Science 34 , 10 (Oct. 1988) 1252–1265.

9. Martin, J. Rapid Application Development. Macmillan, New York, 1991.

10. Reilly, J.P. and Carmel, E. Does RAD live up to the hype? IEEE Software (Sept. 1995), 24–26.

11. Price Waterhouse. Technology Forecast: 1996. Price Waterhouse Technology Center, Menlo

Park, CA, 1995.12. Tornatzky, L.G., and Klein, K.J. Innovation characteristics and innovation adoption-imple-mentation: A meta-analysis of findings. IEEE Transactions on Engineering Management EM-29 (Feb. 1982), 28–45

Recommendations for IS ManagersRecognize that RAD represents a radical change to the process of software construction

for most IS organizations. The development methodology supported by RAD is signifi-

cantly different from traditional waterfall methods.

Emphasize the magnitude of the change represented by RAD through information dis-

semination and training sessions. Developers appear to respond more positively to RAD

if it is positioned as a fundamental change, possibly because they are frustrated by

existing development approaches.

Allow developers to accept RAD approaches voluntarily and focus on developing posi-

tive perceptions about tools. Mandating their use will result in negative attitudes.

Select developers for initial RAD usage carefully. Choose those with higher personal

innovativeness with respect to information technology or prior OO experience.

Staff RAD projects with a mix of experienced and relatively new developers.Experience with methodology resident in the senior staff can be leveraged with the more

contemporary technology experiences of the new staff.

Avoid the pitfall of permitting the capabilities of RAD tools to subvert good develop-

ment practices. Carefully weigh the long-term implications to cost and quality.

Documents

RAD_risks (Journal Pendukung)