ArticlePDF Available

Risks of Rapid Application Development



Proliferating information systems (IS) application development backlogs and ever- escalating business demands for applications software have resulted in a constant search by IS organizations for paradigms and tools that accelerate the pace of software development. Along with rapid application development (RAD), technologies such as CASE, object-oriented development, client/server computing, and flexible mid- dleware are being hailed as potential solutions to the software crisis (11). Although industry experience with these paradigms is mixed, the benefits of such technologies are 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: as a methodology prescribing certain phases in software development (similar in principle to 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 for client/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 adjectives like "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 time has been spent determining if the value of RAD tools to business extends beyond the
Proliferating information systems (IS) application development backlogs and ever-
escalating business demands for applications software have resulted in a constant
search by IS organizations for paradigms and tools that accelerate the pace of software
development. Along with rapid application development (RAD), technologies such
as CASE, object-oriented development, client/server computing, and flexible mid-
dleware are being hailed as potential solutions to the software crisis [11]. Although
industry experience with these paradigms is mixed, the benefits of such technologies
are 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: as
a methodology prescribing certain phases in software development (similar in principle
to 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 for
client/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 adjectives
like “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 time
has been spent determining if the value of RAD tools to business extends beyond the
Ritu Agarwal ( is an associate professor at the Robert H. Smith School of
Business, University of Maryland, College Park, MD.
Jayesh Prasad ( is an associate professor in the Department of MIS and
Decision Sciences, University of Dayton, Dayton, OH.
Mohan Tanniru ( is Professor and Director of the Applied Technology in Business
Program 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 copies
are 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
next deadline or the next deliverable. RAD methodologies are clearly needed to produce
software quickly, and a compressed development life cycle requires powerful RAD tools.
But knowledge of how to incorporate RAD tools into an IS shops 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 amongst
IS 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 types
of 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 more
maintainable, reusable, and extensible [10]. Questions regarding precisely how RAD
tools 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 the
long-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 should
be positioned to maximize acceptance; and second, on usage patterns of RAD tools and
their 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 somewhat
disturbing in regard to the changes in the development life cycle being wrought by the
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, and
management. 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-stage
cycle consists of requirements planning, user design, construction, and cutover, while
in the three-stage cycle, requirements planning and user design are consolidated into
one iterative activity. In a typical RAD life cycle, the requirements specification and
design 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 resistance
associated with the implementation of any new technology. First-generation RAD tools
suffered from the limitations inherent in their interpretive nature and inability to scale
up to enterprise-level production applications. Current RAD tools have overcome these
shortcomings and provide a range of varied functionality, including CASE features,
visual programming, object creation, remote data access using SQL, and support for
multitier client/server architectures.
RAD Implementation
RAD 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 not
receive 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 facilitate
the assimilation of RAD technology using the research model shown in Figure 1. The
model identifies three perceptions that have been consistently related to positive usage
intentions, 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 utilize
the new tool.
• Compatibility measures perceived congruence of new technology with preferred
methods 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-implemention
variables. Prior studies focused primarily on the internal psychological processes that
lead to acceptance of new technologies; few have focused on how management might
proactively influence the process of acceptance (as opposed to compelling technology
use by edict). The individual difference variables of a developer include his/her: prior
mainframe and client/server experience and personal innovativeness with respect to
new information technologies.
Our selection of these variables was based on extensive research in learning theories
and 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. Research
examining 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. Perhaps
their experience with the extensive discipline and structure associated with mainframe-
based projects makes them skeptical of the seemingly ad hoc nature of RAD. “The
introduction 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 prior
experience of a developer, his/her personal innovativeness in the domain of information
technology, defined as the propensity of an individual to try out any new information
technology, 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 RAD
technology 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 to
an 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, and
better, 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.
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 between
RAD tool usage and expected outcomes. Outcomes are categorized into two classes
based 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 values
like greater application development flexibility, reduced coding, and code reuse
(Table 2). RAD tool features are organized into three categories, based on their roles
in the overall software development process. The project management class includes
features such as configuration and version management and team repository man-
agement; the development class includes, among others, interactive debugging, screen
layouts and navigation, and GUI code generation; and the modeling class consists of
data and business process modeling.
A Field Study of RAD
In order to explore the key issues of RAD usage in IS organizations, a field study was
conducted 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, database
independence, and SQL support. A list of all registered licensees of the tool (173
licensees in 39 businesses) was obtained from the vendor of the tool. A total of 36
individuals 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 respondents
are systems developers with significant experience (an average of over 11 years) in
software development, which was the intended target respondent class for RAD tools.
Table 2. Operationalizing the benefits of RAD.
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 the
industries 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 as
CASE tools did not sufficiently ensure reliability and validity of the measures [7]. The
constructs 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 all
research constructs, except for two developer characteristics: prior mainframe experi-
ence and prior client/server experience. These two were measured by survey questions
that 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 which
they 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 whenever
appropriate.” Responses on all features belonging to a particular class were averaged to
obtain 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 research
variables, as well as scale reliabilities are shown in Table 4. The reliability values for all
scales are indicative of high internal consistency. Multivariate procedures were utilized
to test both research models.
Table 3. Sample characteristics.
The data reveals that on average, developers have neither overwhelmingly negative or
positive perceptions of the RAD tool. Recall that the first research model identified
the systems developers most likely to be most receptive to RAD and to transition
from old to new skills, and addressed how managers desiring to implement RAD
should position it to developers. A multivariate analysis of variance (MANOVA) pro-
cedure was utilized with developer characteristics and implementation characteristics
as independent variables, and the three salient perceptions about RAD as dependent
variables. The overall F-test for the MANOVA was significant; univariate tests
revealed that the personal innovativeness of an individual developer in the domain of
information technology was a significant determinant of all three perceptions, while
prior 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 the
usage of development related features as a predictor of global benefits (ß = 0.379, t-value
= 2.21, p < 0.05).
Although not reported here, several studies examining technology acceptance indicate
that perceptions about the RAD tool were significant predictors of usage intentions.
Clearly, management needs to focus on developing positive perceptions about the
new technology to ensure its successful adoption into the IS organizations tool kit.
Two developer characteristics among the determinants of perceptions—prior
client/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.
predicted as negative because of the potential difficulties associated with moving to a
new software construction paradigm. But experienced mainframe programmers do
not appear skeptical with regard to the value of RAD. A negative relationship was
found 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 personal
innovativeness toward information technology and RAD perceptions is encouraging.
Consistent with Martins 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 implementation
and 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 to
engender more positive perceptions, a finding that supports the commonly held view
that software developers are motivated by work-related outcomes. Perhaps they are so
frustrated with the inability of extant development environments to allow them to
meet 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 the
gaps 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, shouldnt the usage of features such as project management and mod-
Table 5. Influences on developers’ perceptions about RAD.
eling emerge as highly correlated with perceived benefits? One explanation is that these
results suggest a subversion of development methodology, and perhaps systems devel-
opers are ignoring or side-stepping crucial phases in the development life cycle. Further
support for this explanation can be found in the fact that the difference between usage
of 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 design
and rigorous methodology altogether.”[10]
To gain further insight into the underlying issues our findings point to, we gathered
follow-up data, with the intent of gaining a rich, qualitative understanding of the RAD
phenomenon 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 results
obtained were not idiosyncratic to the particular tool being studied, two organizations
using 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. For
instance, Alpha provides insurance companies with information about all previous
claims 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 large
manufacturing organization that develops highly engineered products for a global mar-
ketplace. In each case, interviewees were IS managers with direct responsibility for pro-
jects utilizing RAD tools. The interviews were structured around their experiences with
RAD and their overall impressions of what changes the technology was instrumental in
bringing about.
Comments from the Field
All four organizations are developing mission-critical applications using RAD tools.
Alphas major application under development is a system that will support about 400
field offices of insurance companies. Beta is developing a system using a multitier
client/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-date
information on all client holdings is under construction. Delta is utilizing RAD for
applications 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 leader
from Alpha noted there was a lot of industry pressure to deploy these tools. The IS
manager at Gamma succinctly summarized why they elected to use RAD: “My job
is 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
1A t-test of the difference between usage of development features and usage of modeling features was statistically significant
(t value = 8.81; p-value < 0.001).
“unreasonably high.” For example, a project that required about 35 screens, an inter-
face to a Sybase database, and a mainframe Cobol database was estimated to be of
medium size by the project team—this estimate was halved by management.
Regarding assimilation and implementation of RAD, respondents noted that people
with linear C experience had the most difficulty in making the transition. Even devel-
opers with client/server experience did not adapt to the tool very quickly, simply
because of the paradigm shift from procedural to OO development. The Beta manag-
er explained that he did not feel he could mandate use of the tool, but he was attempt-
ing to influence his staffs’ attitude by emphasizing benefits such as its multitier capabil-
ity, potential impacts on reusability, and database independence.
Perhaps the most disturbing aspect of the tools revealed by the interviews, consistent
with what the survey data suggested, was the profound impact that RAD tool use was
having on development methodology. The Gamma manager was particularly con-
cerned; in his view, the most alarming change he witnessed since RAD’s adoption into
his IS organization was the declining emphasis on requirements planning and model-
ing. “We are already under the gun to deliver applications quickly. Now the tools let you
show users something very quick and very dirty—there’s immediately an expectation
that the system is ready. There’s very little incentive for the developer now to say let’s go
back to the drawing board and see if we have the domain model nailed down accurate-
ly. The attitude is that the tools make changes and multiple iterations so easy that errors
and mis-specifications can always be caught down the road and fixed. To me this poses
a very great danger—how are we going to realize the benefits of reusability if we keep
shrinking the analysis phase?” This sentiment was echoed by the manager at Beta, who
noted that the rapid prototyping capability of these tools had resulted in the use of a
“seat of the pants” methodology. The key concerns about RAD that surfaced through
the survey and field interviews are:
• Development-related features of RAD tools used more extensively than modeling
• Declining emphasis on requirements planning and modeling;
• Potential subversion of development methodology; major emphasis on system
construction, not enough on domain analysis;
• Developer tendency to not seek out errors and misspecifications early in the devel-
opment cycle;
• Benefits of reusability cannot be obtained with a shrinking analysis phase;
• Unrealistic management expectations about how quickly systems can be con-
structed using RAD approaches; and
• Developers with linear C experience have difficulty making the transition to
object-based RAD tools.
Implications and Recommendations
Growing evidence supports RAD as an “order of magnitude” improvement in the
speed of software construction. Several pragmatic implications emerge from the
results of this study and allow us to make recommendations to managers desirous of
exploiting RAD as a methodology and as a class of tools (see the sidebar
“Recommendations for IS Managers”). First, it is important to recognize that RAD
represents a radical change to the process of software construction for most IS orga-
nizations. As substantiated by extensive prior work, mandating technology usage is
unlikely to produce beneficial results in the long run. Accordingly, careful attention
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 greater
exposure to OO technology are inclined to respond to RAD with more alacrity. These
individuals 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 experienced
staff combines and diffuses synergistically with the receptivity to new technology of
the newer developers. Managers also need to emphasize the magnitude of the change
represented by RAD over previous approaches to software construction, perhaps
through the use of information dissemination and training sessions. Training should
not focus only on imparting technical knowledge, but on underscoring the radical
improvement 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 the
pitfall of allowing RAD capabilities to subvert good development practices. Martin
notes that “…higher quality, lower cost, and rapid development, thus, go hand in hand
if 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 or
CASE 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-term
deliverable. Convincing such developers of the importance of up-front domain analysis
and modeling represents a critical area for managerial emphasis if RAD is truly going to
help alleviate the software crisis. At the very least, the decision by managers to yield to
short-term business pressures by sacrificing analysis and using RAD for speed alone (to
deliver systems quickly that are intended to be fixed in later iterations)—should be an
informed decision, made after consideration of the implications on cost and quality in
the longer term. Clearly, this is an issue that merits widespread debate.
1. 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 characteristics
in 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 (June
1995), 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.
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 Managers
Recognize 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.
... Metode RAD [6], [7], terdiri dari 3 fase: 1. Requirement Planning, penentuan tujuan dan kebutuhan data dan informasi. Bagian ini telah dibahas pada sub bagian sebelumnya. ...
Kegiatan diskusi mahasiswa Tuli dengan mahasiswa lain, mahasiswa Tuli membutuhkan alat bantu dalam mengikuti kegiatan diskusi, dimana selama ini, mahasiswa Tuli hanya mengandalkan kemampuan membaca bibir lawan bicaranya. Penelitian ini menghasilkan sebuah teknologi bantu atau asistif yaitu aplikasi MVTe (Mobile Voice To Text) berbasis Android dimana aplikasi ini secara sederhana merubah suara dalam bentuk tulisan. Aplikasi ini dikembangan menggunakan metode RAD (Rapid Application Development). Metode RAD mempercepat proses pengerjaan dikarenakan proses kerjanya yang ringkas. Uji coba aplikasi dilakukan kepada seorang ahli IT, 5 mahasiswa Tuli, dan 5 Dosen yang ada di lingkungan Fakultas Teknologi Informasi Universitas Merdeka Malang. Rata-rata hasil uji sebesar 81,3% dengan kategori layak untuk digunakan.
... Next, the responsibility of the Charge control is control the energy which coming from the Solar Panel and it will store energy in the 12 volts battery, which is called Lead Acid Battery to supply entire circuit of robot by 12v. The main microcontroller of the project is Arduino will control all operations of robot [6,9]. Therefore, the Arduino will get the signal of pictures from the PIXY2 camera, which take the pictures and processing the image, which allow the Arduino to follow the track line. ...
Conference Paper
In many economies around the world, countries focus on developing their agricultural field and activity. The agricultural sector is one of the most important sectors because it meets the world's requirements for providing food. Often time's workers in the agricultural sector face hard work all day. In addition, there are bulldozers and various agricultural machines, which take a long time to work, which increases the cost of workers directly. The aim of this research is to design Solar Powered Robot for different agricultural applications such as spraying the fertilizers on the fields. In addition, cutting the excess grass near the crops, and proper way to sowing seeds and planting the plants whatever crops of large or small area. This robot consists of the solar panel to charging the battery, four motors, multiple sensors, pixy2 camera to analyze the images and support the robot to move in the tracking line a most important part of robot is Arduino UNO. Finally, the robot was tested in agricultural land and able to achieve the objectives of the design. This robot will do several operations such as cutting the excess grass and distributing seeds on the surface of agricultural land and the sprayer will spraying the paper fertilizer all of these operations done by different sensors.
... In the event that a framework can't be precisely elasticized developing the required components for RAD will challenge and requires more endeavors and time for making stubs and drivers in unit testing [20]. The RAD model recognizes three discernments that have been reliably identified with positive utilization expectations, which anticipate the real use of a development [21]: • Relative favorable position evaluates the degree to which an engineer trusts the innovation speaks to a change over earlier techniques.  Kano questionnaire helps to identify with the importance of requirements which are available in product or impact of absence of a requirement. ...
Full-text available
In the Modern Digital advancement age, Software development minimizes the manual exertions towards user requirements where software developers employ the quality models and tools to extract requirements from the users. Requirement Elicitation Process is an imperative phase of the Software Product Development which impeccably delineating the successful execution of the product. User requirements are very hard to explain individually, so collective user participation plays a major role in the requirement elicitation and analysis process. This study aims to implement a new Integrated Approach model named Software User Review Defect Corrective Framework (SURDCF) which complements to the Rapid Application Development (RAD) model. RAD encourages the user participation during product development. The SURDCF is a combination of Rapid Application Development (RAD) model, Kano Model, Quality Function Deployment (QFD), and Software FMEA (SWFMEA) with a couple of assumptions and its detailed steps. The utilization of SURDCF is investigated in Software product development. The Implementation of the model is at first connected to extricate, evaluate and prioritize the user's requirements. This initial phase of SURDCF model delineates a strategy for amalgamation of the Kano model in the QFD. Generally, QFD utilizes information about the value of the product/service and consumer gratification with various fulfillments to recognize the properties that ought to be consolidated or enhanced in an item. Kano permits the distinguishing identity of astonishing specifications, for the most part, connected with advancement. This amalgamation process can enable inventive prerequisites to get the essential consideration in the software development or advancement.
... Rapid Application Development (RAD) model is chosen in this project. It is because the suitability as it designs to produce a high-quality output in a shortest time compare to traditional lifecycle software development [4,7,8]. Besides that, RAD methodology can provide some output of the product in very limited time and getting feedback from the end users regarding their requirements [9,10] (Fig.1). ...
This research aims to develop and implement a type of smart room temperature controller especially for the small industries and home who are not afford to spent a lot of money to install the high technology room temperature controller system in the market. SRTCIoT is proposed with the objectives to implement with lower cost. Furthermore, it is developed to connect to internet connection and provide a real-time notification if any temperature changes in the room that exceeds the set limit. The system is based on LM35 temperature sensor, LCD, LED, DC Fan, and NodeMCU ESP8266 Microcontroller, and implemented using Arduino IDE and ESP Notify Android Application for the notification.
... Whereas RAD can be characterized in two ways, namely (a) as a methodology that determines certain phases in software development, and (b) as a method that allows for rapid object development, and code that can be re-used for client / server applications. (Agarwal et al. 2000). ...
Full-text available
The use of information systems in the era of industry 4.0 has now developed so rapidly that the production process runs with internet technology as the main support. At present, information technology has been widely used in various circles because it can simplify and shorten time required for daily tasks. Because of this the sales program is designed to support current business processes so as not to lag behind other business competitors.
... RAD can be identified as a study methodology in particular stages for developing software. This model provides a set of tools that enable rapid object development [44]. If each project's requirements and restrictions are clearly defined, the RAD method allows a developer team to create a fully functional system in a short-term software development process [45] [46]. ...
This article presents the architecture, design and validation of a microservice orchestration approach, that improves the flexibility of heterogeneous microservice-based platforms. Improving user experience and interaction, for time-critical applications are aspects that were primary objectives for the design of the architecture. Each microservice can provide its own embedded user interface component, also decentralizing it and, in consequence, improving the loosely coupled approach to the architecture. Obtained results are promising, with high throughput and low response times. Also, a key finding was the introduction of benchmarking as a new step in the development lifecycle of performance-critical software components, with an example of how it can be applied within an Agile methodology. Further research is proposed to improve the results and raise the final technology readiness level of the system. Obtained results already make the approach a candidate and viable alternative to classical service composers.
Full-text available
A review and meta-analysis was performed of seventy-five articles concerned with innovation characteristics and their relationship to innovation adoption and implementation. One part of the analysis consisted of constructing a methodological profile of the existing studies, and contrasting this with a hypothetical optimal approach. A second part of the study employed meta-analytic statistical techniques to assess the generality and consistency of existing empirical findings. Three innovation characteristics (compatibility, relative advantage, and complexity) had the most consistent significant relationship to innovation adoption. Suggestions for future research in the area were made.
Full-text available
The author examines attitudes toward CASE usage in a wide variety of organizations.
Full-text available
In the implementation of an organizational innovation, managers are usually presumed to influence the extent to which the innovation is adopted and used by their subordinates. However, the findings presented in this paper suggest that the managerial influence is not equally perceived by all subordinates. Rather, certain context-specific characteristics of individual employees mediate the managerial influence. Users of the expert system studied herein who were low in personal innovativeness toward this class of innovations, for whom the subjective importance of the task being computerized was low, whose task-related skills were low or who were low performers in their sales job---all these user groups perceived their management had encouraged them to adopt. In contrast, users who rated high on any of these measures did not perceive any management influence in their adoption decision. Moreover, although access to the innovation was in fact highly similar for all users, high performers also were inclined to perceive the system as more accessible than were low performers. These findings suggest that the diffusion of an innovation within an organization perhaps could be viewed as a two-step managerial process. Employees whose characteristics incline them to adopt an innovation will do so without management support or urging if it is simply made available. Employees low on these characteristics will await a managerial directive before adopting. Implications for future research are discussed.
Full-text available
Software reuse is the use of existing software knowledge or artifacts to build new software artifacts. Reuse is sometimes confused with porting. The two are distinguished as follows: Reuse is using an asset in different systems; porting is moving a system across environments or platforms. For example, in Figure 1 a component in System A is shown used again in System B; this is an example of reuse. System A, developed for Environment 1, is shown moved into Environment 2; this is an example of porting.
Growing competition in the investment bankingindustry has given rise to increasing demand forhigh functionality software applications that canbe developed in a short period of time. Yet deliveringsuch applications creates a bottleneck insoftware development activities. This dilemmacan be addressed when firms shift to developmentmethods that emphasize software reusability.This article examines the productivityimplications of object and repository-based integratedcomputer-aided software engineering(ICASE) software development in the context ofa major investment bank's information systemsstrategy. The strategy emphasizes softwarereusability. Our empirical results, based on datafrom 20 projects that delivered software for thebank's New Trades Processing Architecture(NTPA), indicate an order of magnitude gain insoftware development productivity and the importanceof reuse as a driver in realizing this result.In addition, results are presented on the extent of the learning that occurred over a two-year period after ICASE was introduced, and on the influence of the link between application characteristics and the ICASE tool set in achieving development performance. This work demonstratesthe viability of the firm's IS strategy andoffers new ideas for code reuse and softwaredevelopment productivity measurement that canbe applied in development environments that emphasizereuse.
The object-oriented methodology for systems analysis and design has generated considerable interest recently. Object-orientation represents a fundamental shift in focus from the traditional process-oriented approaches that have dominated software development for over two decades. Although there is anecdotal evidence to suggest that systems analysts experienced in process-oriented modeling approaches will find it difficult to apply objective-oriented methodologies, there is no empirical work investigating the relationship between a procedural mindset and an ability to learn and apply object-oriented concepts. Prior research in human problem solving, however, suggests that the efficacy of a systems analysis and design methodology should be judged in the context of the task to which it is applied. To explore the effects of prior experience and task characteristics on performance in systems analysis and design, we conducted an experiment in which two groups of subjects applied the object-oriented methodology to two types of tasks, one process-oriented and the other object-oriented. One group had significant prior experience in process-oriented methodologies, while the other group had no formal experience. Both groups were provided identical training in object-oriented analysis and design prior to the experiment. The results of the study suggest that both prior experience and task characteristics play a role in determining performance. The implications that follow for research and practice are discussed.