360 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 47, NO.
3, AUGUST 2000
Drivers for Software Development Method Usage
Mohamed Khalifa and June M. Verner
Abstract—In this research, we examine factors affecting the use
of product development methods. Based on established behavioral
theories, we develop and test a model that can explain, and hence
predict, the extent of use of development methods. Although our
model can be adapted to any development process, we apply it to
software development. To test our model, we examine the com-
bined effects of a number of important usage factors that con-
tribute to the depth and breadth of use of two software develop-
ment approaches: the waterfall model and prototyping. Two main
constructs, process quality and facilitating conditions, are found to
be the drivers of method usage. The dominating “facilitating con-
ditions” and “process quality” indicators vary from one method to
another. Product quality was not found to be a statistically signifi-
cant factor in explaining usage. Our results are consistent with the
view taken by the software process improvement movement, i.e.,
that a quality process will result in a quality product.
Index Terms—Development method adoption and usage, process
quality, product/software development method, prototyping, soft-
ware development.
I. INTRODUCTION
T HE INITIAL adoption of a software development ap-
proach or method (e.g., a waterfall approach, prototyping,
the spiral model, iterative development, or object oriented,
etc.), is normally an organizational decision [17]. Oftentimes,
however, multiple methods are adopted and used together for
the same project, but at different phases of the development
life cycle. The extent of use of a particular method, however,
is an individual decision made by the developers or with a
significant input from the developers. By “extent of use,” we
mean the degree to which the methodology is applied at the
different phases of the development life cycle and to different
application areas (e.g., transaction processing systems versus
decision support systems). Developers may use different
methodologies for different development stages or different
types of applications. Researchers have investigated factors
or attributes that contribute to the use of a particular software
development method (e.g., [4]–[6], [8], [25], [27], [29]),
and they have identified a number of such factors, e.g., the
perceived effects of the development method on the quality
and maintainability of the software and a high level of control
of the development process. Most of the reported factors have
been examined separately, and for this reason, the relationships
among them have not been explored. Furthermore, no drivers
or dominating factors have been identified as the main moti-
Manuscript received July 20, 1998; revised September 27, 1999. Review of
this manuscript was arranged by Editor-in-Chief D. F. Kocasglu.
M. Khalifa is with the Department of Information Systems, City University
of Hong Kong, Kowloon, Hong Kong (e-mail: iskhal@cityu.edu.hk).
J. M. Verner is with the School of Information Science and Technology,
Drexel University, Philadelphia, PA 19104 USA.
Publisher Item Identifier S 0018-9391(00)06634-4.
0018–9391/00$10.00 © 2000 IEEE
vators for using a software development methodology. Some
of the factors identified as having a significant effect on usage
when considered separately may become insignificant when
grouped together with other factors. In order to determine what
factors really drive the extent of use of a software development
method, we need to examine the combined effects of these
factors. This represents the main motivation for this study.
Our primary objectives are to develop and test a model that
explains the effects of important “usage factors” reported in
the literature, and to determine the relative importance of these
factors in explaining the extent of use of a particular software
development method. A secondary objective is to apply the
model in comparing the use of prototyping to that of a waterfall
approach.
We are specifically interested in the developers’ overall moti-
vation, as well as important facilitating conditions for the use of
software development methods. Gaining a better understanding
of the social context of the software development process to-
gether with the beliefs of the individuals involved is impor-
tant in better understanding the use of software development
methods. In this study, we are particularly interested in the de-
velopers’ beliefs regarding the potential impact of the develop-
ment method on both the quality of the product and the quality
of the process. In terms of environmental factors, we examine
the effects of team size, organizational support, and the inno-
vation (i.e., speed of adoption of new technologies). This study
should be of interest to both researchers and practitioners. In
particular, researchers who are interested in developing a com-
prehensive model to explain the use of product development
methods will find the proposed model and our preliminary re-
sults useful. Also, this study provides practitioners in general
and project mangers in particular with a better understanding of
how to motivate the use of a particular software development
method.
II. LITERATURE REVIEW
Since, in this study, we are particularly interested in the
waterfall and prototyping approaches, we limit our literature
review to these two methods, and the general factors that have
been suggested as contributors to their usage. The waterfall
method is a linear process consisting of sequential development
phases, i.e., system feasibility study, requirement analysis and
project planning, system design, detailed design, coding, testing
and integration, installation, and maintenance. Each phase is
documented in a report that must be formally validated before
moving to the next phase. Although widely used, the waterfall
model is believed to have the following limitations [19]:
• System requirements are frozen before the design begins.
For some projects, however, the users do not know the
requirements beforehand.
KHALIFA AND VERNER: DRIVERS FOR SOFTWARE DEVELOPMENT USAGE
• Hardware technology is usually chosen early in the de-
velopment process as part of the requirements specifica-
tion. Given the speed with which hardware technology is
evolving, large projects that take a few years to complete
may end up with hardware specifications that are on the
verge of becoming obsolete.
• The process is document driven. Heavy documentation is
not practical, and sometimes not suitable, particularly for
interactive applications where developing elaborate docu-
mentation of the user interface is not feasible.
• Waterfall does not allow for iterative enhancements, as
system requirements must be completely specified before
the design can start.
Because of its limitation, the waterfall method is rather suited
for routine types of projects where the requirements are well de-
fined. The prototyping method addresses some of the limitations
of waterfall. Instead of freezing the requirements, a throwaway
prototype is built to help elicit the requirements from the users.
The development of the prototype involves design, coding, and
testing, but each of these phases is not done very thoroughly or
formally. Through the interaction with the prototype, the user
can get an actual feel of the system, and better understand the
requirements. This usually leads to more stable requirements
that change less frequently. Prototyping is believed to be suit-
able for demonstrating the feasibility of a certain approach, and
to be an appropriate method for complicated and large systems
for which requirements are difficult to determine beforehand.
However, prototyping is often not used, as it is perceived to be
more costly than waterfall [19].
There is much literature that discusses the advantages and
disadvantages of waterfall and prototyping in practice (e.g.,
[4], [5], [8], [15], [27], [38]). Prototyping has become popular
due to a need to improve software development efficiency
and effectiveness, increasing user influence in these projects,
the wider availability of tools, and the success stories being
reported [11]. Prototyping is frequently used as a risk-reduction
technique, and Boehm [6] has included it as an important part
of his spiral model. Prototyping is often used within or instead
of a waterfall approach to reduce certain project risks where
it is used to buy knowledge [6]. Although prototyping may
be used on its own (evolutionary prototyping), it is frequently
used within a waterfall approach, and may replace or augment
any of the development phases. It is also frequently used to
determine feasibility or to clarify requirements [32]. Palvia and
Nosek [27] evaluated prototyping and the waterfall approach
with a questionnaire to computing professionals in mainly
small departments, and reported mean ratings for ten attributes
for both approaches. They suggest that prototyping provides
better communication between development personnel, better
communication with users, earlier problem detection, more
flexible designs, and is less costly than a waterfall approach.
Guimaraes and Saraph [15] highlight the benefits of proto-
typing, including improved user/developer communication,
greater system flexibility, and higher quality systems. Boehm
et al. [5] suggest that although prototyping produces more
flexible systems, a waterfall approach results in systems that
are more robust with greater functionality. Prototyping pro-
vides a communication basis for discussions among all groups
361
involved in the development process, especially between users
and developers [24]. Sometimes, poor communication between
users and developers and a lack of user involvement has led
to acceptance problems that prevent systems from being in-
stalled [24]. Some organizations have focused on development
productivity and the possibility of improving it through proto-
typing [31]. As prototyping frequently clarifies requirements,
it thus allows development to approach closer to user needs
than, for example, does a conventional waterfall development.
Prototyping should increase useful functionality, and therefore,
even with an increase in cost over not prototyping, it may also
increase productivity [31].
Developers do not always believe that the development ap-
proach chosen is necessarily the appropriate approach. In their
research, Verner and Cerpa [36] found that some practitioners
had been involved in developments that should have used pro-
totyping, but a waterfall approach was used instead; other de-
velopers were involved in developments where prototyping was
used, even though the developers thought that a waterfall model
would have been more appropriate.
Although a number of factors motivating the use of a waterfall
approach or prototyping have been reported in the literature, no
attempt has been made to develop a causal model explaining the
effects of these factors and their relative importance. What really
does drive developers to use a particular development method
more extensively than another remains a question that needs to
be answered.
III. PROPOSED MODEL AND HYPOTHESES
In order to explain the use of a particular software develop-
ment method, one must first understand the organizational (i.e.,
social) context of the software development process, together
with the intentions and actions of the practitioners involved. In
this research, we investigate the effects of certain context vari-
ables (facilitating conditions) and the beliefs of software de-
velopers regarding the consequences of particular software de-
velopment methods on the extent of their use of these method.
While the adoption decision (for a particular development ap-
proach) is usually organizational, the extent of use (i.e., depth
and breadth) is often decided by one or more individuals in-
volved in the development process. For this reason, our research
focuses on explaining the behavior of developers.
The use of a software development method is a behavior that
can be explained by well-established behavioral models such as
the theory of reasoned action proposed by Fishbein and Azjen
[14], its extension: the theory of planned behavior (TPB), pre-
sented by Azjen [2], and the model of Triandis [35]. Although
relatively overlooked, Triandis’ model is more comprehensive
than TPB in that it includes more constructs. In this research,
we adopt the Triandis model because it is well suited for ex-
plaining individual behavior as opposed to organizational be-
havior. Thompson et al. [33], [32] have demonstrated the value
of Triandis’ model in predicting usage of computers at the indi-
vidual level.
As illustrated in Fig. 1, the Triandis model [35] shows that
an individuals’ behavior is determined by what they have usu-
ally done (habits), by what they think they should do (social
362 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 47, NO. 3, AUGUST 2000
Fig. 1. Triandis’ model of human behavior.
Fig. 2. Proposed model.
norms), and by the consequences that they associate with a be-
havior (perceived consequences). It includes aspects, which are
directly related to an individual (genetic factors, personality,
habits, attitudes, behavioral intentions, and actual behavior), and
other aspects that are related to an individual’s environment
(culture, social situation, social norms, facilitating conditions,
etc.).
In this research, we focus on a particular subset of the
Triandis model (Fig. 2). More specifically, we investigate the
causal model relating facilitating conditions and developers’
beliefs with regard to the consequences of using a particular
software development method to the developers’ behavior (use
of the software development method). Since we are interested
in studying the actual behavior of developers rather than their
intentions, we removed the mediating variable “intentions”
and related “perceived consequences” (or beliefs) directly to
“behavior.” Furthermore, like other studies [1], [3], we are
more interested in explaining usage rather than just predicting
it. In this particular case, we explain developers’ use of the pro-
totyping and waterfall approaches as a function of facilitating
conditions and developers’ beliefs.
Facilitating Conditions: These are objective factors in the
environment that facilitate the performance of an act [35]. Their
importance in explaining human behavior stems from the fact
that an individual who has the intention of performing a certain
act may not be able to do so because his or her environment
prevents the act from being accomplished. The presence of cer-
tain facilitating conditions may favor a particular behavior. The
existence of individuals or groups that investigate new software
development methodologies and tools, for instance, represents
a form of organizational support to developers. Organizational
support was used by Thompson et al. [33] and Bergeron et al.
[3] to measure facilitating conditions. The size of the develop-
ment team and its structure, the speed of adoption of innovative
methodologies, and emerging technologies by the organization
and organizational support are all factors that may favor the use
of one software development method over another. We there-
fore expect “facilitating conditions” to have a significant posi-
tive effect on “use,” and accordingly, we propose the following
hypothesis:
1: There is a positive relationship between facilitating
conditions and developers’ use of a software develop-
ment method.
Perceived Consequences/Beliefs: Each act or behavior is
perceived by the individual as having a potential outcome that
can be either positive or negative [35]. An individual’s choice of
behavior is based on the probability that an action will cause a
specific consequence. Consequences which developers usually
associate with their preferred software development method are
improvements of the quality of both the development process
and the products of this process. These two dimensions (devel-
opment control-efficiency and product quality-maintainability)
correspond to what Orlikowski [26] refers to as the locus of
change. It is important to emphasize that we are not interested
in developers’ beliefs prior to the adoption of the software
development method, but rather more temporal beliefs, as these
are the ones that influence the extent of use and its continuation.
2a: There is a positive relationship between the perceived
improvement of the quality of development process re-
sulting from a software development method and a de-
veloper’s use of that method.
2b: There is a positive relationship between the perceived
improvement of the quality of a software product re-
sulting from a development method and a developer’s
use of that method.
IV. METHODOLOGY
A questionnaire was administered to 82 senior software
developers from Australia and Hong Kong. The targeted de-
velopers had extensive software development experience, and
came from well-established organizations. All organizations
have been in business for a long time with many years of soft-
ware development experience. They had large IS departments
(average IS staff number: 200). More information about the
profile of the respondents is described in Table I. 52.6% of
the respondents used prototyping, almost 91% used waterfall,
and 44.7% used both methods. This implies that slightly over
KHALIFA AND VERNER: DRIVERS FOR SOFTWARE DEVELOPMENT USAGE
TABLE I
RESPONDENTS’ PROFILE
42% used waterfall solely, and only about 8% used prototyping
exclusively. Developers were not separated into groups of
waterfall users versus prototyping users, as the purpose of the
survey was not to explain exclusive use of a particular software
development method, but rather the extent of use of the method.
A. Measures
In the operationalization of our constructs, we relied on pre-
vious research that used the Triandis model as well as the proto-
typing and waterfall literature. The questionnaire and the coding
of the different variables are presented in the Appendix.
Use: As explained earlier, we are not interested in predicting
or explaining the adoption of software development methods,
but rather in the extent of their use. Since the same developer
can use different methods for different types of systems or even
multiple methods for the same system, different methods for
different phases of the development life cycle, we consider two
dimensions of use: depth and breadth.
363
Depth of Use: This refers to the extent that a prototyping
or waterfall approach is used in the various phases of the soft-
ware development life cycle. Researchers who investigated the
use of prototyping and the waterfall model within the various
phases of the life cycle reported that prototyping was frequently
used for a single phase within a phased or waterfall approach [8].
They found that the greatest use of prototyping was in the design
phase, although it was also used for analysis and construction.
The lowest use of prototyping was found in the implementa-
tion phase [8], [27]. Boehm [6] incorporated prototyping in all
phases of his spiral model, and suggested that the degree of use
depended on the risks identified. We measured this variable by
the number of different stages (i.e., analysis, design, construc-
tion, and implementation) where either a prototyping or a wa-
terfall approach is used by our respondents.
Breadth of Use: This refers to the extent to which a partic-
ular method is used in the development of different types of ap-
plications (i.e., operational information systems, management
information systems, decision support systems, executive in-
formation systems, expert systems, and interorganizational sys-
tems, e.g., EDI). We measured this variable by the number of
different types of applications that are developed with a proto-
typing or a waterfall approach.
Facilitating Conditions: Variables under this construct
include the size of the development team, organizational
support (support provided to the development team regarding
for using software development methods), and innovation
(speed of adopting new technologies/ methodologies by the
organization.)
Size of Development Team: The size of the development
team is measured by the number of staff. Palvia and Nosek
[27], who surveyed small teams, found that communication be-
tween the team members was better with prototyping than with
a waterfall approach. However, Cerpa and Verner’s [8] research,
which was done with large teams, did not support these results.
Verner and Cerpa [36] later reported that the use of prototyping
or a waterfall approach within an organization could be affected
by the size of the development team. Their research suggests
that developers in small teams prefer prototyping, while devel-
opers in larger teams prefer a waterfall approach because it pro-
vides a better control over the development process.
Organizational Support: Organizational support can
be indicated by the existence of individuals or groups in the
organization that investigate development methods and advise
on the usefulness of these methods. Lack of familiarity of the
development methodology is an obvious impediment to its use
[11].
Innovation: This variable refers to the speed of adoption
of new technologies by the department or organization. Re-
spondents had four different choices for this variable: leader,
follower, conservative, and static organizations/departments.
Leaders take on board new technologies and techniques faster
than followers. Conservative organizations only use techniques
that have been proven in the marketplace, while static organi-
zations are less likely to change their development techniques
and tools. Leading-edge organizations are more likely to have
fourth-generation languages, modern CASE tools, object-ori-
ented technology, and to be trained in using such tools and
364 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 47, NO. 3, AUGUST 2000
Fig. 3. Results of PLS analysis for prototyping.
techniques. Tate [31] expected that prototyping would continue
to grow in popularity as high-productivity tools proliferate
and produce more effective and efficient prototypes more
effectively and efficiently. Followers should also have these
tools, but may not be quite as advanced as the leading-edge
organizations with respect to development techniques and
technology, although they are probably experienced with their
current level of technology.
Perceived Consequences/Beliefs: As explained earlier, this
construct includes two dimensions: product quality and process
quality.
Product Quality: This dimension refers to the overall ef-
fect of the software development method on the quality of the
product (software). It includes two indicators: software quality
and software maintainability. In previous research, Guimaraes
and Saraph [15] reported higher quality for software developed
with prototyping, while Cerpa and Verner [8] reported that de-
velopers perceived that software developed with a waterfall ap-
proach was more maintainable. Software quality and software
maintainability are measured with a Likert-type scale with five
levels (1 = very poor to 5 = very good).
Process Quality: This dimension refers to the overall ef-
fect of the software development method on the quality of the
development process. It includes communication with users,
project control, early detection of problems, and development
cost. Communication with end users is of critical importance in
clarifying the requirements and essential features of a system
[20], [24]. Improved communication with users is cited in the
literature as one of the main benefits of prototyping over a water-
fall approach [7], [15], [20]. Project control is another indicator
of the quality of the software development process. A waterfall
approach is perceived to provide better control of the schedule,
cost, and project as a whole than prototyping [8], [27]. Clear
deadlines, deliverables, and milestones make everyone involved
with the project aware of their goals and commitments. Early
detection of problems is also an important indicator of process
quality. Boehm [4] noted that, “Finding and fixing a software
problem after delivery is 100 times more expensive than finding
and fixing it during the requirements and early design phases.”
The last indicator, cost, is one of the main risk factors in soft-
ware development. Prototyping has been suggested as a means
for buying knowledge in order to reduce such a risk [31], and to
improve systems development efficiency and effectiveness [11].
All indicators are measured on Likert-type scale with five levels.
B. Data Analysis
We used the partial least squares (PLS) procedure [37] to an-
alyze the data. PLS has been gaining interest and use among
researchers in recent years because of its ability to model latent
constructs under conditions of nonnormality and its suitability
for small to medium sample sizes [9], [10]. PLS allows the
specification and testing of the structural model (relationships
among constructs) and the m easurement models (measures un-
derlying each construct) simultaneously. Testing the measure-
ment model determines how well the measures relate to the con-
struct, while testing the structural model determines whether
there is empirical evidence for the hypothesized relationships
among the constructs. PLS-Graph version 2.91.02 was used to
perform the analysis. Tests of significance for all paths were
conducted using the bootstrap resampling procedure [13].
All constructs in our model (see Figs. 3 and 4) have forma-
tive measures, except for the construct “use” which has reflec-
tive measures. For reflective measures (arrows pointing to items
represented by squares in Fig. 3), all items are viewed as parallel
KHALIFA AND VERNER: DRIVERS FOR SOFTWARE DEVELOPMENT USAGE
Fig. 4. Results of PLS analysis for waterfall.
measures capturing the same construct of interest. The standard
approach for evaluating such a measurement model is to con-
sider the significance of the path loadings from construct to mea-
sures. In the case of formative measures (arrows pointing to con-
structs represented by circles in Fig. 3), all item measures can be
independent of one another since they are viewed as items that
create the emergent factor. Under this situation, Chin and Gopal
[9] suggest that the weights of each item be used to assess how
much an item contributes to the overall factor.
V. RESULTS AND DISCUSSION
The results are illustrated in Fig. 3 for prototyping and Fig. 4
for waterfall. The estimated path effects (standardized), weights
(for formative measures), and loadings (for reflective measures)
are given with the associated standard error and value. All
statistically significant path coefficients , loadings,
and weights are indicated with an asterisk. The data support
Hypotheses 1 and 2a, but not Hypothesis 2b for both prototyping
and waterfall.
Hypothesis 1: As stipulated in Hypothesis 1, the coeffi-
cient of the path from “facilitating conditions” to “use” is
positive and significant for both the prototyping and waterfall
approaches, implying that the extent of use of a particular
software development method is positively affected by facili-
tating conditions. The verification of the hypothesis for both
the prototyping and waterfall approaches strengthens our con-
fidence in the results. While the path coefficient is significant
for both development methods, the “facilitating conditions”
items significantly contributing to this relationship vary from
one method to the other. While, for prototyping, both innova-
tion and size of the development team contribute significantly
365
to use, for a waterfall approach, only the indicator size of the
development team makes a significant contribution. Further-
more, the contribution of the size of the development team
is positive for waterfall and negative for prototyping. These
results imply that innovative and small teams favor proto-
typing over a waterfall approach. Developers in organizations
or departments that adopt new technologies relatively faster
seem to make more extensive use of prototyping. These results
confirm Tate’s [31] prediction that, as high productivity tools
proliferate, prototyping will continue to grow in popularity.
Also, the smaller the size of the development team, the more
extensive the use of prototyping. These results are consistent
with those of Verner and Cerpa [36]. Organizational support,
on the other hand, does not seem to affect use. A possible
explanation is that, unlike other research in this area which
dealt with computer users who were computer novices and
needed some organizational support (e.g., technical support),
in this research, the users are software developers who do not
rely as much on this type of organizational support.
Hypothesis 2a: Like Hypothesis 1, this hypothesis is also
verified. The coefficient of the path from “process quality”
to “use” is positive and significant for both development
approaches. This implies that the perceived positive effect
of a particular software development method on the quality
of the development process significantly affects the extent
of use of that method by the developer. For prototyping, the
only process quality indicator with a significant effect on use
is communication with users. For the waterfall approach, on
the other hand, the only significant process quality indicator
is project control. These results suggest that, from a process
improvement point of view, the main motivation for developers
to use prototyping is the improvement of communication with
366 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 47, NO. 3, AUGUST 2000
users, and the main motivation to use a waterfall approach
is better control of the development process. Early detection
of problems and development costs does not seem to matter
as much to developers. A possible explanation of the lack of
significance of these factors is that such factors are usually of
greater concern to managers.
Hypothesis 2b: This is the only hypothesis that is not ver-
ified, neither for prototyping nor for waterfall. The perceived
consequences of a software development method on the quality
of the product do not have a significant effect on the extent of
use of the method. One possible explanation is that the respon-
dents are developers, and do not care about the quality of the
products as much as the end users. A more likely explanation
is that the quality of the product depends, to a large extent, on
the quality of the process, and that is what really matters for
developers. Such an explanation is consistent with process im-
provement models, e.g., capability maturity model, SPICE, and
bootstrap [12], [16], [22], [28], which are based on the premise
that a good quality process will result in good quality software.
It is important to notice, however, that the perceived effects
of the waterfall approach on product quality and maintainability
are significantly correlated with the usage depth of a waterfall
approach (a correlation of 0.25 with for software
quality and a correlation of 0.26 with for software
maintainability). These results illustrate the importance of ex-
amining factors that may influence use collectively rather than
separately. Although developers’ beliefs concerning the effects
of a software development method on the product quality are
significantly correlated with the depth of use of the method, they
do not appear as use drivers when considered together with other
factors.
Having established that both process quality and facilitating
conditions drive the use of the waterfall and prototyping ap-
proaches, the next task is to investigate the relative importance
of these two constructs. As illustrated in Fig. 3 for prototyping,
the path coefficient for process quality (0.24) is smaller than the
path coefficient for facilitating conditions (0.30). However, the
difference between the two coefficients is not significantly dif-
ferent from zero (as determined by a test at 95% significance
level). Hence, we cannot conclude that facilitating conditions
contribute significantly more than perceived effects on process
quality to the use of prototyping. For the waterfall approach,
however, the results are different. As illustrated in Fig. 4, the
path coefficient of process quality 0.46) is greater than the path
coefficient of facilitating conditions (0.20). This difference is
significant (as determined by a test at the 95% significance
level), implying that the perceived consequences of using a wa-
terfall approach, as perceived by developers, contribute more
significantly to the use of this method than facilitating condi-
tions.
VI. CONCLUSION
In this research, we have developed and tested a model that
depicts the effects of possible motivators for using a partic-
ular software development method on the extent of use (depth
and breadth of use) of that method. The hypothesized effects
are based on a well-established behavioral model, the Triandis
model [35]. We also examined the relative importance (path co-
efficients) of these effects. We applied the model to two software
development methods (prototyping and waterfall).
Two out of the three hypothesized relationships are verified.
More specifically, the extent of use of the software develop-
ment method was significantly influenced by facilitating condi-
tions (i.e., organizational support and size of development team)
and developers’ beliefs concerning the effect of the software
development method on the quality of the software develop-
ment process. On the other hand, the extent of use was not sig-
nificantly influenced by the developers’ beliefs concerning the
quality of the product. Furthermore, for a waterfall approach,
the contribution of perceived effects on process quality is more
important than the contribution of facilitating conditions.
1) Facilitating Conditions: The extent of use of software
development methods is positively affected by this con-
struct. However, the dominating “facilitating conditions”
indicators contributing significantly to the usage relation-
ship vary from one method to another. Innovation in the
IS department or organization contributes significantly to
the use of prototyping, but not to the use of a waterfall ap-
proach. For both development approaches, the size of the
development team has a significant effect on usage. How-
ever, its effect is positive for the waterfall approach and
negative for prototyping; this implies that developers in
small teams favor prototyping, while developers in larger
teams favor a waterfall approach. Furthermore, the overall
effect of facilitating conditions on the use of prototyping
is the most important effect. For a waterfall approach,
however, even though this factor is significant, its overall
contribution to use is less important.
2) Developers’ Beliefs/Perceived Consequences: We in-
vestigated two dimensions of this construct: perceived
effects on the process quality, and perceived effects on
product quality. We found that, for both software devel-
opment approaches, only the perceived consequences
of the development method on the quality of the devel-
opment process have a significant effect on the extent
of use of the method. Furthermore, different indicators
of process quality emerged for different development
approaches. While, for a waterfall approach, control of
the process is the dominant indicator, for prototyping, it
is communication with users.
It is interesting to note that the perceived consequences of
these software development approaches on the quality of the
product do not have a significant effect on the usage of either
method. Developers obviously believe that process quality is
more important than the quality of the product. This result is
consistent with the stance taken by the software process im-
provement movement [12], [16], [22], [28], i.e., that a quality
process will result in a quality product.
In future research, we would like to make the proposed model
more comprehensive by including additional constructs from
Triandis’ model, e.g., affect and habit. Additional indicators
for the existing constructs will also be considered. In addition,
the applicability of the model to other development approaches
needs to be investigated.
KHALIFA AND VERNER: DRIVERS FOR SOFTWARE DEVELOPMENT USAGE 367

APPENDIX
QUESTIONNAIRE and CODING

Extent of Use of Software Development Method

Phases of system development life cycle where development method is used:

Prototyping Waterfall

Systems analysis

Systems design

Systems construction

Systems implementation

Coding: The number of boxes ticked for each method is used as measure of usage depth for that method.

Types of applications developed using either or both types of methods:

Prototyping Waterfall

Operational information systems

Management information systems

Decision support systems

Executive information systems

Intercorporate (e.g., EDI)

Others (please specify)

Coding: The number of system types ticked/added for each method is used as measure of usage breadth for that method.

Facilitating Conditions

Coding: The measure of this variable is simply the number of members of the development team.

Existence of an individual/group investigating Yes No

software development methodologies

Coding: Binary variable.

Description that best fits the organizational adoption of new technologies:

368 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 47, NO. 3, AUGUST 2000

Choices Coding

Market leader

Market follower

Conservative (only follows when technology proven)

Static—seems like it never moves

Perceived Consequences
(Two Items: Software Quality and Software Maintainability):
How good is the waterfall methodology in producing maintainable systems?

1) very poor 2) poor 3) moderate 4) good 5) very good

How good is the overall quality of a system produced mainly through waterfall?

1) very poor 2) poor 3) moderate 4) good 5) very good

How good is the prototyping methodology in producing maintainable systems?

1) very poor 2) poor 3) moderate 4) good 5) very good

How good is the overall quality of a system produced mainly through prototyping?

1) very poor 2) poor 3) moderate 4) good 5) very good

(Four Items: Project Control, Communication with Users, Early Detection of Problems, Development Cost):
How good is the level of project control achieved with the waterfall methodology?

1) very poor 2) poor 3) moderate 4) good 5) very good

How good is a waterfall methodology for communicating with users?

1) very poor 2) poor 3) moderate 4) good 5) very good

How good is a waterfall methodology for early discovery of problems?

1) very poor 2) poor 3) moderate 4) good 5) very good

Cost of using a waterfall methodology in comparison with other methodologies

1) very low 2) low 3) moderate 4) High 5) very high

How good is the level of project control achieved with prototyping?

1)very poor 2) poor 3) moderate 4) good 5) very good

How good is a prototyping methodology for communicating with users?

1) very poor 2) poor 3) moderate 4) good 5) very good

How good is a prototyping methodology for early discovery of problems?

1) very poor 2) poor 3)moderate 4) good 5) very good

Cost of using a prototyping methodology in comparison with other methodologies

1) very low 2) low 3) moderate 4) high 5) very high

KHALIFA AND VERNER: DRIVERS FOR SOFTWARE DEVELOPMENT USAGE
REFERENCES
[1] D. A. Adams, R. Nelson, and P. Todd, “Perceived usefulness, ease of
use, and usage of information technology: A replication,” MIS Quart.,
vol. 16, pp. 227–247, June 1992.
[2] I. Azjen, “The theory of planned behavior: Some unresolved issues,” Or-
ganiz. Behavior and Human Decision Processes, vol. 50, pp. 179–211,
1991.
[3] F. Bergeron, L. Raymond, R. Reix, and S. Gara, “Understanding EIS
use: An empirical test of a behavioral model,” presented at the Hawaii
Int. Conf. on Syst. Sci., Koloa, HI, Jan. 1992.
[4] B. W. Boehm, Software Engineering Economics. Englewood Cliffs,
NJ: Prentice-Hall, 1981.
[5] B. W. Boehm, T. E. Gray, and Seewaldt, “Prototyping versus specifying:
A multiproject experiment,” IEEE Trans. on Software Eng., vol. SE-10,
no. 3, pp. 290–302, 1984.
[6] B. W. Boehm, “A spiral model of software development and enhance-
ment,” IEEE Comput., pp. 26–37, May 1988.
[7] J. M. Carey and J. D. Curry, “The prototyping conundrum,” Datamation,
pp. 29–33, June 1, 1989.
[8] N. Cerpa and J. M. Verner, “Prototyping: Some new results,” Inform.
Software Technol., vol. 38, pp. 743–755, Dec. 1996.
[9] W. W. Chin and A. Gopal, “Adoption intention in GSS: Importance of
beliefs,” Data Base Adv., vol. 26, no. 2/3, pp. 42–64, 1995.
[10] D. R. Compeau and C. A. Higgins, “Application of social cognitive
theory to training for computer skills,” Inform. Syst. Res., vol. 6, no.
2, pp. 118–143, 1995.
[11] E. R. Doke and N. E. Swanson, “Decision variables for selecting pro-
totyping in information systems development: A Delphi study of MIS
managers,” Inform. Manage., pp. 173–182, Oct. 1995.
[12] A. Dorling, “SPICE: Software process improvement and capability de-
termination,” Software Qual. J., vol. 2, pp. 209–224, 1993.
[13] B. Efron and R. J. Tibshirani, An Introduction to the Bootstrap. New
York: Chapman and Hall, 1993.
[14] M. Fishbein and I. Azjen, Belief, Attitude, Intention and Behavior: An
Introduction to Theory and Research. Boston, MA: Addison-Wesley,
1975.
[15] T. Guimaraes and J. V. Saraph, “The role of prototyping in executive
decision systems,” Inform. Manage., vol. 21, pp. 257–267, 1991.
[16] W. Humphrey, “Characterizing the software process: A maturity frame-
work,” IEEE Software, pp. 73–79, Mar. 1988.
[17] J. Iivari, “Why are CASE tools not used?,” Commun. ACM, vol. 39, no.
10, pp. 94–103, 1996.
[18] J. Iivari and M. Karjalainen, “Impact of prototyping on user information
satisfaction during the IS specification phase,” Inform. Manage., vol. 17,
pp. 31–45, 1989.
[19] P. Jalote, An Integrated Approach to Software Engineering, 2nd
ed. Berlin: Springer-Verlag, 1997.
[20] K. Kautz, “Communication support for prototyping projects,” Inform.
Software Technol., vol. 35, no. 11–12, pp. 647–651, 1993.
[21] A. Kieback, H. Lichter, M. Schneider-Hufschmidt, and H. Zullighoven,
“Prototyping in industrial software projects: Experiences and assess-
ment,” Inform. Technol. People, vol. 6, no. 2/3, pp. 109–143, 1992.
[22] P. Kuvaja, J. Simila, L. Krzanik, A. Bicego, S. Saukkonen, and G.
Koch, Software Process Assessment and Improvement: The Bootstrap
Approach. Oxford, England: Blackwell Business, 1994.
[23] K. Lantz, The Prototyping Methodology. New York: McGraw-Hill,
1986.
[24] H. Lichter, M. Schneider-Hufschmidt, and H. Zullighoven, “Prototyping
in industrial software projects—Bridging the gap between theory and
practice,” IEEE Trans. Software Eng., vol. 20, no. 11, pp. 825–832, Nov.
1994.
[25] J. Martin and J. J. Odell, Object-Oriented Analysis and De-
sign. Englewood Cliffs, NJ: Prentice-Hall, 1992.
[26] W. J. Orlikowski, “CASE tools as organizational change: Investigating
incremental and radical changes in system development,” MIS Quart.,
pp. 309–340, Sept. 1993.
369
[27] P. Palvia and J. T. Nosek, “An empirical evaluation of system develop-
ment methodologies,” Inform. Resources Manage. J., vol. 3, no. 3, pp.
23–32, 1990.
[28] M. Paulk, B. Curtis, and M. Chrissis et al., “Capability Maturity Model
for Software, Version 1.2,” Software Eng. Inst., Carnegie Mellon Univ.,
Pittsburgh, PA, CMU/SEI-93-TR-24, Feb. 1993.
[29] S. R. Schach, Classical and Object-Oriented Software Engineering, 3rd
ed. Homewood, IL: Irwin, 1996.
[30] D. W. Straub, M. Limayem, and E. Karahanna-Evaristo, “Measuring
system usage: Implications for IS theory testing,” Manage. Sci., vol. 41,
no. 8, pp. 1328–1342, 1995.
[31] G. Tate, “Prototyping: Helping to build the right software,” Inform. Soft-
ware Technol., vol. 32, pp. 237–243, May 1990.
[32] G. Tate and J. M. Verner, “Case study of risk management, incremental
development, and evolutionary prototyping,” Inform. Software Technol.,
vol. 32, no. 3, pp. 207–214, 1990.
[33] R. L. Thompson, C. A. Higgins, and J. M. Howell, “Personal computing:
Toward a conceptual model of utilization,” MIS Quart., vol. 15, pp.
125–143, Mar. 1991.
[34] , “Influence of experience on personal computer utilization: Testing
a conceptual model,” J. Manage. Inform. Syst., vol. 11, pp. 167–187,
Summer 1994.
[35] C. H. Triandis, “Values, attitudes and interpersonal behavior,” presented
at the Nebraska Symp. Motivation, 1979: Beliefs, Attitudes and Values,
Lincoln, NE, 1980, pp. 159–295.
[36] J. M. Verner and N. Cerpa, “Prototyping: Does your view of its advan-
tages depend on your job?,” J. Syst. Software, vol. 36, pp. 3–16, Jan.
1997.
[37] H. Wold, “Introduction to the second generation of multivariate anal-
ysis,” in Theoretical Empiricism, H. Wold, Ed. New York: Paragon
House, 1989, pp. vii–xi.
[38] T. R. Young, “Superior prototypes,” Datamation, pp. 152–158, May
1984.
Mohamed Khalifa was educated at the Wharton
Business School of the University of Pennsylvania,
and received the M.A. degree in decision sciences
and the Ph.D. degree in information systems.
His work experience includes four years as a Busi-
ness Analyst and over ten years as an Academic in
the United States, Canada, China, and Hong Kong. At
present, he is an Associate Professor at the Informa-
tion Systems Department, City University of Hong
Kong. His research interests include innovation adop-
tion, electronic commerce, and IT-enabled innovative
learning.
June M. Verner was educated at Massey, University, New Zealand, and re-
ceived the B.S. degree in pure mathematics, the Master of Business Studies de-
gree in information systems, and the Ph.D. degree in software engineering.
Her work experience includes nearly 20 years as a University Lecturer in New
Zealand, Australia, Hong Kong, and the United States. She served as Program
Cochair for STEP’99, and is on the Editorial Board of the Journal of Systems
and Software, Information and Software Technology, and the Journal of Empir-
ical Software Engineering Research. At present, she is Professor of information
systems in the College of Information Science and Technology, Drexel Univer-
sity, Philadelphia, PA. Her research interests are in software project manage-
ment, software quality, software measurement, and software process improve-
ment. Dr. Verner is a member of ACM and the Executive Committee of IEEE’s
Technical Council on Software Engineering.