A multi-level analysis of factors affecting software developers’ intention to reuse software assets: An empirical investigation

Information & Management 44 (2007) 613–625 www.elsevier.com/locate/im

A multi-level analysis of factors affecting software developers’ intention to reuse software assets: An empirical investigation Vidhya Mellarkod a, Radha Appan b, Donald R. Jones a,*, Karma Sherif c a b

Area of Information Systems and Quantitative Sciences, Rawls College of Business, Texas Tech University, Lubbock, TX 79409, USA Department of Computer and Information Science, Nance College of Business, Cleveland State University, Cleveland, OH 44130, USA c Information System, Jesse H. Jones School of Business, Texas Southern University, Houston, TX 77004, USA Received 16 December 2004; received in revised form 25 January 2007; accepted 31 March 2007 Available online 17 September 2007

Abstract Reuse of software assets in application development has held promise but faced challenges. In addressing these challenges, research has focused on organizational- and project-level factors while neglecting grass-root level adoption of reusable assets. Our research investigated factors associated with individual software developers’ intention to reuse software assets and integrated them in TAM. Towards that end, 13 project managers were interviewed and 207 software developers were surveyed in India. Results revealed that the technological-level (infrastructure), and individual-level factors (reuse-related experience and self-efficacy) were major determinants. Implications are discussed. # 2007 Elsevier B.V. All rights reserved. Keywords: Software reuse; Technology acceptance; Behavioral intention; Software developers

1. Introduction Software reuse focuses on the development and integration of reusable software assets to benefit the development of applications within a specific domain [10]. Reusable software assets are often prefabricated blocks of code that are assembled to provide new software solutions. They range from source code, development plans, requirement analysis, and design documents to test cases. The development and integration of reusable software assets have been recommended to solve the problems due to budget overrun, late delivery, and project failure [10]. Proponents of reusability believe that the approach is an effective strategy for improving the efficiency and quality of software systems, and * Corresponding author. Tel.: +1 806 742 1988; fax: +1 806 742 3193. E-mail address: [email protected] (D.R. Jones). 0378-7206/$ – see front matter # 2007 Elsevier B.V. All rights reserved. doi:10.1016/j.im.2007.03.006

reducing the time to market [23,25]. Companies have invested millions of dollars to populate libraries of reusable software assets and train employees to generate and use these assets. Prior research on reusable assets has explored different forms of assets [29]; steps in initiating, implementing, developing, and integrating them [4,5]; and barriers to their development and use [21]. Past experiences have shown that the non-technical issues are difficult to resolve [17] at both the organizational and individual levels. Nonetheless, research has often failed to identify risks in adopting a technology or determine organizational contexts in which the technology is doomed to fail. Such knowledge is important due to the cost of building a reuse repository [22] and the risks associated with resistance to adopting the methods [13]. The objective of our study was therefore to identify and assess factors that influence individual developers’

614

V. Mellarkod et al. / Information & Management 44 (2007) 613–625

intentions to reuse software assets. We sought to develop a more thorough understanding of how developers’ intend to reuse software assets as an important link in the causal chain between management initiatives to reuse software and its outcomes.

It is therefore imperative to understand the behavior of software developers. The key to successful reuse programs obviously depends on its acceptance by the users. We therefore decided to explore such factors to aid in improving the process.

2. Literature review and hypotheses

2.2. Primary effects on the intention to reuse software assets

2.1. Prior research on software reuse The concept of formal software reuse was introduced in the late sixties by McIlroy [19]. While initial efforts focused primarily on code, the reuse of all deliverables of the development cycle was later seen as a means to exploit the full potential of the technology [16]. The first formal program at an organization level was established at the Raytheon Missile Division [18], where the effort led to a 50% gain in productivity. The US Department of Defense estimated that it could save US$ 300 million annually by increasing reuse practices by 1%. Companies have also reported major productivity and quality gains from its use. Still, mixed results have shown that positive outcomes cannot be taken for granted [14]. To generate support for reusable assets, standards and guidelines have been proposed, incorporating reuse into the development lifecycle, and providing tools for the storage and retrieval of reusable assets. Cost-benefit models for assessing gains have been developed [3]. But despite efforts to prescribe normative methods for the adoption of software reuse, organizations have still experienced problems in implementing the methods. In an attempt to resolve inconsistencies in findings, the barriers and antecedents to successful implementation of software reuse have been studied. At the organizational level, important factors seem to include top management support [12], the development of a reuse compatible infrastructure [1], the allocation of adequate resources, and the promotion of assets throughout the organization. Several advances have been made in the development of library systems, classification, frameworks, architectures, etc. [26]. The general belief with regard to nontechnical factors is that they remain a problem and that efforts to manage them are challenging. Individual attitudes have emerged as an important determinant of success in reuse [28]. The motivation for studying individual factors is because deeply held beliefs result in resistance from the developers. Antidotes have included incentives as a way to shift attitudes in favor of reusable assets [6], as well as educating stakeholders on economic benefits and dynamic learning.

As discussed in many prior articles, Fishbein and Ajzen’s [9] TRA motivated TAM [8] to explain user acceptance of IT, where behavioral usage is primarily predicated by intention to use IT. Perceived usefulness and perceived ease-of-use have also been shown to shape the intention to use. Over time, many modifications have been made and tested to show the effect of such factors. We decided to add software reuse to this body of research, considering factors identified through qualitative interviews with software project managers, to add the behavioral intention to reuse software assets into TAM. This required consideration of relevant reuse experience, self-efficacy, resource allocation by management, social factors, and reuse infrastructure. The conceptual model is shown in Fig. 1. 2.2.1. Perceived usefulness [PU] PU has consistently been a strong determinant of the intention to use a technology. In the context of reusable assets, it signifies software developers’ perceptions of the impact of reusing software assets, user satisfaction [24], and quality of the software developed. We hypothesized that the perceived usefulness would be positively associated with the intention to reuse the software assets: H1. Perceived usefulness of reusable software assets positively influences intentions to reuse software assets. 2.2.2. Perceived ease of use [PEU] PEU has been found to have a significant effect on the intention to use a technology. Given the multiple challenges of understanding, adapting, and integrating reusable assets, PEU is likely a salient determinant of the developer’s intention to reuse software assets. We defined PEU as the individual assessment of the mental effort required to reuse a software asset, the ease of understanding the reusable assets, and the ease of integrating the asset in software applications. Thus, H2. Perceived ease of reusing software assets is positively related to intentions to reuse software assets.

V. Mellarkod et al. / Information & Management 44 (2007) 613–625

615

Fig. 1. Conceptual model.

2.2.3. Predetermined mindset regarding reuse A predetermined negative feeling against the use of assets was considered to be one instance of the not invented here (NIH) syndrome. Developers resist reuse of software because of their egos, including concerns about quality and reliability of the assets. Possibly, developers gain personal satisfaction from the creative act of building software artifacts. Nonetheless, empirical studies have found no significant evidence of the syndrome. Frakes and Fox [11] found that most software developers rejected the notion of the syndrome. Studies have reported that developers prefer using software written by others than developing their own; existing software helps leverage the experience of senior developers and results in a better understanding of domain knowledge. We therefore included a construct in the model to test the effect of NIH on intentions to reuse: H3. A positive predetermined mindset towards reusable assets is positively related to intentions to reuse software assets. 2.2.4. Self-efficacy Socio-cognitive theory (SCT) [2] and its extensions, which emphasized the potential of perceived selfefficacy as an important determinant of technology acceptance, have found strong empirical support. Selfefficacy is a person’s self-judgment of his or her ability to use a technology to accomplish a task. Compeau and Higgins [7] examined it as a determinant of actual usage, and Venkatesh et al. [31] posited it as a

determinant of behavioral intention. In sophisticated organizational technologies, where intentions to adopt is influenced by self-efficacy, we posited that individuals would intend to adopt a technology only if they believed that they would be able to assimilate the practices in daily work activities. Thus, self-efficacy would affect the developer’s perception about incorporating reusable assets when developing software. Thus, H4. Perceived self-efficacy is positively related to intentions to reuse software assets. 2.3. Factors affecting usefulness and ease-of-use 2.3.1. Perceived ease of use Some TAM studies have reported an indirect relationship of ease-of-use and PU and stated that perceived ease-of-use was an important causal antecedent to PU. Subsequent studies found that for an effective computer system, its PU is largely dependant on whether end users perceive it as easy-to-use. Therefore, we hypothesize that H5. Perceived ease of reusing software assets is positively related to the perceived usefulness of software assets. 2.3.2. Resource allocation In the context of software reuse, perceptions of resource allocation consider the degree to which an individual perceives that the organizational resources

616

V. Mellarkod et al. / Information & Management 44 (2007) 613–625

are adequate for the development and integration of reusable assets. Prior research on reuse found that it was important to allocate additional time for the development and integration of reusable assets [30]. Additional funds were also required to cover the staffing and technological support required. In a comparative study of reuse practices in successful and unsuccessful firms, the availability of resources was found to positively influence perceptions regarding the usefulness of the software assets [27]. Therefore, we posited that the developers’ perceptions about appropriate allocation of resources were likely to affect the developers’ perception of usefulness of the software assets. It was hypothesized that H6. Perceptions about the appropriateness of resource allocations to software reuse are positively related to the perceived usefulness of software assets. 2.3.3. Social factors In the context of reuse, senior management, departmental co-workers, and immediate supervisors such as project managers are the major members of the relevant social group providing the social environment. Managers’ encouraging and supporting reuse, as well as co-workers’ perceptions of the technology and their degree of involvement in its development, are important factors. In our study, we took a comprehensive view and examined the influence of workers at different hierarchical levels on the developers’ perception of the usefulness of software assets. Thus, H7. Perceptions about social support for software reuse are positively related to the perceived usefulness of software assets. 2.3.4. Technical infrastructure Technical infrastructure refers to methodologies, frameworks and standardized processes that support the adoption of a technology. Previous research found that it was essential for the success of reuse programs [15]. Given that development and reuse of software assets was considered ‘‘a paradigm shift’’ in application development methods, the successful reuse of software assets and its acceptance by the developers’ community would be influenced by the availability of reuse compatible methodologies and frameworks, which incorporate reusable assets into all phases of software development. Therefore, we hypothesized: H8. Perceptions about the availability of reuse compatible infrastructure are positively related to the perceived usefulness of software assets.

H9. Perceptions about the availability of reuse compatible infrastructure are positively related to perceptions regarding the ease of reusing software assets. 2.3.5. Previous experience The early stages of developing and reusing assets represent a knowledge barrier and high learning cost for the developers. As they accumulate experience, they are likely to understand the value of the software assets and their potential impact on the quality and cost of development. Thus, experienced developers should perceive software assets as easy and useful to adopt. Therefore, H10. Reuse-related experience is positively related to the perceived usefulness of software assets. H11. Reuse-related experience is positively related to perceptions regarding the ease of reusing software assets. 2.3.6. Self-efficacy While prior research has not studied the effect of self-efficacy on the development and reuse of software assets, it was essential to consider the relationships between it and perceptions of usefulness and ease of implementing the reuse technology. Furthermore, interviews with software developers suggested that their perceptions regarding ‘‘how ready’’ they were in terms of the availability of skills for developing and reusing assets determined whether reusing assets would be useful to them. When developers believed that they had acquired the necessary skills to reuse assets, they reported that reusable assets would improve their job performance. Therefore, H12. Self-efficacy is positively related to perceptions regarding the usefulness of software assets. H13. Self-efficacy is positively related to perceptions regarding the ease of reusing software assets. Despite the evidence that incentive schemes positively impacted the development and reuse of software assets in the US, they were not included in our study. Initial interviews with project managers in India indicated that none of the organizations had any kind of incentive schemes in place to promote reusable assets. In fact, some project managers questioned the need for such schemes. Thus, incentive schemes were not considered.

V. Mellarkod et al. / Information & Management 44 (2007) 613–625 Table 1 Demographics of participants Gender Male (Na) Female (N)

157 59

Age

26.25 years (average)

Software development related experience

3.33 years (average)

a

A total of 216 persons participated in the survey, but nine surveys were dropped because they were incomplete, leaving 207 surveys on which the analysis was conducted.

3. Research method To investigate factors that influenced software developers’ intentions to reuse and to examine the nomological validity of the conceptual model, a structured questionnaire was developed and administered to software professionals working in multinational IT companies headquartered in India. Table 1 presents information relating to the demographics of participants participating in this study. 3.1. Instrumentation The survey instrument consisted of both validated and new items developed for the purposes of our study. Accordingly, behavioral intention, PU, PEU, social factors, experience, and self-efficacy were measured using questions adapted from preexisting scales (see Table 2). Scales for resource allocation, technical infrastructure and pre-determined mindset regarding reuse were adapted and/or developed to meet the objectives of this study as existing scales were not appropriate for software reuse. After its preliminary development, two experts (an expert in software reuse and an expert in survey development) examined the instrument to assess its face validity. They suggested minor changes to the wording Table 2 Operationalization of variables Construct

Number of items

Source

Behavioral intention Perceived usefulness Perceived ease of use Resource allocation Infrastructure Social factors Previous experience Self-efficacy Positive mindset regarding reuse

3 4 3 5 11 7 2 3 3

Prior research Prior research Prior research New scale New scale Prior research Prior research Prior research Prior research and two new items

617

of five questions adapted from prior studies. Suggestions from these experts were incorporated in the first draft of the instrument. Since part of the instrument included new scales, validating the instrument through pre-testing and/or piloting was essential to ground the central constructs. We pilot-tested the instrument with the help of five experienced systems developers to assess the clarity of instructions, the amount of time required to complete the survey, the thoroughness and relevance of the items, and the psychometric properties of the scales. The pilot study revealed the need to revise the wordings of two questionnaire items in order to remove ambiguities pointed out by the participants, remove ten items, since analysis of the data revealed that they did not load on the relevant constructs, and add four items to improve the reliability and validity of the constructs. Some minor changes to the structure of the questionnaire were also made. The revised instrument was re-tested with 15 software developers in an IT organization. Analysis of the responses was satisfactory and hence this instrument was used in the final study without further modification. The survey instrument is presented in Appendix A. 3.2. Sample We administered the survey to 50 companies which were randomly selected from a list of 850 software companies provided by National Association of Software Table 3 Profile of participating organizations Measure

Frequency

Average number of employees

4711 employees

Organizational size (based on revenue for 2003) Large (revenue > US$ 1 billion) Medium (revenue > US$ 0.5 billion but <1 billion) Small (revenue < US$ 0.5 billion)

4 6 5

Organizational profile Software development Software implementation Software maintenance Software re-engineering Business process outsourcing

15 15 15 12 13

Ownership Private sector Public sector

5 10

Span of operation Domestic Multinational

1 14

618

V. Mellarkod et al. / Information & Management 44 (2007) 613–625

Table 4 Factor analysis rotated component matrix Variablea

bi1 bi2 bi3 puse1 puse2 puse3 puse4 eou1 eou2 eou3 seff1 seff2 seff3 inf1 inf2 inf3 inf4 inf5 inf6 inf7 inf8 inf9 inf10 inf11 ra1 ra2 ra3 ra4 ra5 sf1 sf2 sf3 sf4 sf5 sf6 sf7 pexp1 pexp2 pmrr1 pmrr2 pmrr3

Componentb 1

2

3

4

5

6

7

8

9

.032 .033 .086 .075 .097 .154 .189 .208 .204 .249 .093 .105 .103 .825 .869 .801 .818 .866 .829 .857 .844 .861 .838 .830 .307 .422 .454 .300 .292 .146 .086 .186 .251 .413 .258 .333 .127 .053 .119 .065 .093

.128 .177 .157 .155 .121 .096 .200 .063 .056 .048 .241 .099 .127 .060 .129 .195 .135 .217 .299 .191 .093 .158 .189 .133 .192 .088 .117 .132 .153 .736 .837 .790 .713 .654 .793 .766 .275 .164 .104 .057 .039

.133 .092 .114 .022 .070 .016 .014 .044 .163 .173 .188 .006 .085 .103 .172 .197 .193 .101 .147 .187 .204 .206 .150 .206 .779 .771 .686 .779 .829 .013 .013 .126 .189 .228 .148 .133 .137 .215 .280 .215 .071

.346 .282 .447 .840 .759 .777 .726 .004 .121 .300 .137 .147 .072 .087 .079 .062 .068 .023 .071 .091 .092 .112 .040 .121 .022 .050 .031 .053 .004 .264 .172 .134 .059 .056 .069 .071 .134 .163 .030 .034 .181

.797 .781 .684 .206 .323 .205 .041 .045 .133 .050 .197 .079 .388 .016 .025 .050 .055 .004 .005 .064 .096 .084 .086 .083 .028 .063 .254 .168 .034 .109 .106 .125 .212 .032 .044 .008 .034 .043 .494 .517 .006

.009 .103 .099 .010 .019 .196 .125 .807 .824 .626 .022 .075 .001 .053 .107 .226 .283 .086 .067 .031 .026 .054 .109 .061 .045 .052 .002 .156 .063 .081 .004 .019 .071 .210 .131 .141 .201 .098 .051 .108 .089

.044 .036 .021 .090 .087 .153 .001 .112 .018 .187 .110 .030 .430 .117 .074 .035 .005 .109 .090 .147 .101 .006 .067 .133 .069 .038 .185 .089 .139 .220 .137 .065 .111 .085 .010 .005 .802 .850 .223 .173 .072

.002 .204 .101 .023 .096 .038 .221 .086 .028 .040 .724 .829 .529 .073 .079 .017 .045 .027 .069 .062 .079 .106 .035 .007 .162 .060 .070 .018 .007 .068 .112 .043 .088 .089 .159 .147 .040 .028 .254 .113 .037

.077 .080 .012 .031 .082 .031 .159 .012 .026 .118 .076 .082 .015 .039 .022 .006 .002 .017 .042 .043 .009 .082 .052 .009 .056 .072 .022 .079 .116 .047 .041 .082 .128 .028 .052 .116 .065 .000 .560 .594 .853

Extraction method: principal component analysis. Rotation method: varimax with Kaiser normalization. a Variables correspond to the items on Section A of the survey shown in the Appendix. b Items loading on a factor are indicated in bold.

and Service Companies (NASSCOM),1 which is India’s premier trade body and the chamber of commerce of the IT software and services industry. The companies were primarily involved in conducting business in IT software, IT services, Internet, e-commerce, or ITenabled services, etc. Companies that lacked interest in the study and those

1

www.nasscom.org.

that did not have a software reuse program were eliminated, leaving 15. All of them were involved in software development, maintenance and re-engineering activities and almost all had operations in more than one country. They varied, however, in size, products, and services offered, and also in their employee turnover rate (see Table 3 for their demographics). At each company, we explained the purpose and procedures involved in the administration of the survey.

V. Mellarkod et al. / Information & Management 44 (2007) 613–625

We promised to deliver an analysis of the results, with recommendations to improve the success of the reuse program to participating firms. The survey was administered to individual software developers within each company. Random selection of participants, though desired, could not be achieved because of the schedules and workloads. On average, the participants worked on the survey for 15 min. At the end of this process, 216 surveys were obtained; out of these nine surveys were incomplete and thus, excluded from the analysis, resulting in a usable sample of 207 surveys. 3.3. Instrument validity Factor analysis, using varimax rotation with principal components analysis. was applied to reduce the set of 41 items to nine constructs being investigated in our research. The result of this factor analysis is shown in Table 4. All items loaded on the appropriate constructs and no items were dropped in the initial model. Cross loadings were below 0.30 for most of the items. Hence, the construct validity of all the scales for the variables was strong. Next, the reliability of the constructs was analyzed. In our study, reliability of the items for each construct was computed using Cronbach alpha. These results are shown in Table 5. Cronbach alpha averaged 0.82 for the nine constructs, ranging from 0.66 to 0.97, which is acceptable according to Nunnally [20] (two constructs had reliabilities less than 0.70 but were very close to this lower limit and were included in our study). The newly developed scales for technical infrastructure (INF, 11 items) and resource allocation (RA, five items) had Cronbach alpha of 0.97 and 0.92, respectively. The reliabilities for these two constructs were the highest of the reliability scores indicating that they captured a relatively high level of variance of their measures.

619

Table 6 Goodness of fit indices for the initial and revised measurement model

Total number of items Chi-square (x2) Degrees of freedom (d.f.) x2/d.f. GFI AGFI Standardized RMR RMSEA NFI CFI

Initial model

Revised model

Desired levels

33 1105 459 2.4 0.75 0.70 0.074 0.083 0.86 0.91

25 426 240 1.8 0.86 0.81 0.05 0.06 0.91 0.96

Smaller – <3.0 >0.9 >0.8 <0.05 0.05–0.08 >0.90 >0.90

4. Data analysis and results Structural equations modeling (SEM) was used for testing the empirical model. A two-step approach of first testing the measurement model and then the structural model was adopted and LISREL 8.7 was used. 4.1. Measurement model The measurement properties of the constructs were assessed using confirmatory factor analysis (CFA), which allowed the a priori specification of the relationships between the constructs and their indicators. In our study, the infrastructure was conceptualized as a formative construct with three parcels (availability of processes, framework, and methodologies). Therefore, a summate of items within each dimension of infrastructure was created prior to testing of the measurement model. The full measurement model with nine constructs and 33 items was tested. The initial model indicated poor model fit. The results of the initial model are shown in Table 6. To improve the overall fit of the measurement model, each factor was scrutinized to isolate misspecification within each factor. The measurement properties tested

Table 5 Construct

Cronbach alpha

Number of items

Behavioral intention (BI) Perceived usefulness (PUSE) Perceived ease of use (PEOU) Self-efficacy (SEFF) Infrastructure (INF) Resource allocation (RA) Social factors (SF) Previous experience (PEXP) Predetermined mindset regarding reuse (PMRR)

0.87 0.85 0.75 0.67 0.97 0.92 0.66 0.84 0.72

3 4 3 3 11 5 7 2 3

Table 7 Reliabilities of constructs Construct

Reliability

Behavioral intention Perceived usefulness Perceived ease of use Self-efficacy Infrastructure Resource allocation Social factors Reuse experience Predetermined mindset about reuse

0.85 0.83 0.71 0.61 0.91 0.92 0.91 N/A (one item) 0.70

620

V. Mellarkod et al. / Information & Management 44 (2007) 613–625

Table 8 Factor loadings of items in the revised measurement model BI Bi1 Bi2 Bi3 Puse1 Puse2 Puse3 Puse4 Peou1 Peou2 Peou3 Seff1 Seff2 Infs1 Infs2 Infs3 Ra1 Ra2 Ra3 Ra5 Sf6 Sf7 Rexp1 Pmar1 Pmar2 Pmar3

PUSE

PEOU

SEFF

INFS

RA

SF

REXP

PMAR

0.86 0.79 0.78 0.75 0.80 0.81 0.62 0.74 0.78 0.53 0.85 0.51 0.86 0.89 0.90 0.85 0.91 0.85 0.83 0.87 0.96 1.0 0.90 0.72 0.38

All factor loadings were significant at p = 0.10.

for each factor were the unidimensionality, convergent validity, reliability and discriminant validity. For each construct, refinement of the scale was performed using an iterative procedure where only one item was changed in each step. The modifications were made based on the factor loadings and the modification indices, where such modifications were theoretically justified. In the revised model, eight items were dropped to improve reliability and validity of different constructs. The revised measurement model contains 25 items measuring nine constructs of the model. Table 7 shows the items retained. The revised model was re-tested after each factor met

the reliability and validity criteria. The reliability analysis was used to test the internal consistency of each factor. Table 7 shows the reliabilities of the constructs with their items retained in the revised model, which was satisfactory and showed good model parameters (the revised model column is shown in Table 6). Further, the convergent validity of the constructs was apparent, as all the item loadings were significant (Table 8). The discriminant validity was tested using pair-wise correlations, which differed from 1.0 by at least three standard deviations. Table 9 lists the estimated correlations among the constructs.

Table 9 Correlation matrix

BI PUSE PEOU SEFF INFRA RA SF REXP PMAR

BI

PUSE

PEOU

SEFF

INFRA

RA

SF

REXP

PMAR

1 0.72 0.19 0.38 0.14 0.12 0.23 0.21 0.51

1 0.33 0.41 0.30 0.08 0.28 0.31 0.25

1 0.03 0.38 0.23 0.22 0.33 0.01

1 0.27 0.27 0.29 0.08 0.15

1 0.60 0.48 0.25 0.17

1 0.29 0.23 0.30

1 0.18 0.03

1 0.20

1

V. Mellarkod et al. / Information & Management 44 (2007) 613–625 Table 10 Structural analysis results

2

Chi-square (x ) Degrees of freedom (d.f.) x2/d.f. GFI AGFI Standardized RMR RMSEA NFI CFI

Structural model

Desired level

443.26 248 1.79 0.86 0.81 0.06 0.06 0.91 0.96

Smaller – <3.0 >0.9 >0.8 <0.05 0.05–0.08 >0.90 >0.90

4.2. Structural model Using the final measurement model, the structural model was analyzed. The results and the structural fit indices showed an adequate model fit (Table 10). The model explained a significant portion of the variance in behavioral intention (0.66), perceived usefulness (0.32) and perceived ease of use (0.21). Of the proposed 13 hypotheses, eight showed correct directional signs and significant t-values at p < 0.01 and one more hypothesis was significant at p < 0.05 (see Table 11). As hypothesized, the perceived usefulness was positively related to behavioral intention (b = 0.64), supporting Hypothesis H1. Likewise, predetermined mindset about reuse (b = 0.37) and self-efficacy (b = 0.18) were both Table 11 Structural model coefficients and variance explained Path

Coefficients

t-Value

BI PUSE ! BI PEOU ! BI SEFF ! BI PMAR ! BI

0.64* 0.1 (ns) 0.18* 0.37*

6.74 0.12 2.49 6.70

PUSE PEOU ! PUSE SEFF ! PUSE INFRA ! PUSE RA ! PUSE SF ! PUSE REXP ! PUSE

0.23* 0.26* 0.14** 0.19* 0.08 (ns) 0.15*

2.49 3.74 1.77 2.77 1.24 2.64

PEOU SEFF ! PEOU INFRA ! PEOU REXP ! PEOU

0.05 (ns) 0.25* 0.19*

0.88 3.83 3.19

SMC (variance explained) 0.66

0.32

0.21

ns: not significant. * Significant at p < 0.01. ** Significant at p < 0.05.

621

positively related to behavioral intention, supporting Hypotheses H3 and H4. Hypothesis H2 was not supported. Perceived ease of use (b = 0.23), self-efficacy (b = 0.26), infrastructure (b = 0.14), reuse experience (b = 0.15) were each positively related to perceived usefulness, supporting Hypotheses H5, H12, H8, and H10. The relationship between the social factors and perceived usefulness was not significant. Therefore, Hypothesis H7 was not supported. Resource allocation was negatively associated with perceived usefulness (b = 0.19), which was a surprising result. Hypotheses H9 and H11 were supported as infrastructure (b = 0.25) and reuse experience (b = 0.19) were positively related to perceived ease of use. However, the relationship between self-efficacy and perceived ease of use was not significant, failing to support hypothesis H13. 5. Discussion and conclusion Our results highlighted the perspective that individual perceptions of software reuse are important determinants of the behavioral intention to adopt a technology; the core components, in which perceived usefulness (directly) and perceived ease of use (indirectly), and the predetermined mindset regarding reusable assets and self-efficacy, proved to be important determinants of the behavioral intention to reuse the software assets. Our results have important implications. One is that individual perceptions of the usefulness of software reuse are determined by factors at both technological and individual levels. The development of an infrastructure, self-efficacy, and reuse experience emerged as factors that shaped an individual’s perception of the value of software assets. Managers must provide the infrastructure, policies, training, and career paths that enable growth in the field of software assets. Nonetheless, acceptance of reuse also needs attention to individual aspects; perceived self-efficacy and experience are associated with perceived usefulness requiring effective training and mentoring. Our study had some limitations. One was that the survey did not distinguish among the types of software assets the developers may have recently used or intend to use. The type of software asset could affect respondents’ answers. A second limitation is that the survey was conducted in a single country. While India certainly has a growing software industry, other countries could be different. For example, the importance of incentive schemes might be important elsewhere. Finally, the degree of variance explained by antecedent factors is moderate, suggesting that additional factors may have improved the explanatory power of our model.

622

V. Mellarkod et al. / Information & Management 44 (2007) 613–625

1 All the information you give will be anonymous. 2 The questionnaire will take no more than 15 min of your time to complete. 3 In order to ensure that we have the same understanding about the subject of this study, we would like to define a few terms for you. Please keep these definitions in mind when completing this questionnaire.

Our intent in undertaking this study was to contribute to an understanding of the individual intentions to reuse software assets. By considering the effect of PU, PEU, and a predetermined mindset, we found that developers who perceived assets as useful and who have a positive mindset towards software assets had greater intention to reuse the assets.

Software reuse refers to the use of previously developed software assets (from any of the phases of the software development lifecycle like analysis, design, implementation, testing, documentation and maintenance) in new applications. The software assets might have been created by any systems developer (programmers, analysts or designers) within the organization but can be used by other systems developers who might not have created those assets. Software assets include source code, documentation, design patterns, test case, test plan and even requirements.

Acknowledgements We are grateful to participants at the Second Annual Big XII Information Systems Research Symposium, Ames Iowa, 2004, for comments on an early presentation of this research. Appendix A Thank you for agreeing to participate in this survey. This survey is conducted by the XXX College of Business, XXX University. We are interested in knowing your opinion about various issues related to software reuse. Your thoughtful answers will provide important insight to our research. So it is important for us that you answer all the questions to the best of your ability (i.e. please do not skip any questions). Also, please note that

Section A In this section we would like to understand your perception about various software reuse-related issues. If you are not aware of any part of a question or want to mention something in addition to the answers provided, please indicate so near the question.

Your intention to reuse software assets

Strongly disagree

Disagree

Somewhat disagree

Neutral

Somewhat agree

Agree

Strongly agree

Assuming I had access to reusable software assets, I intend to use them when developing future applications Given that I have access to reusable software assets, I predict that I would make use of them when developing future applications I intend to increase my use of reusable software assets in the future development of application

1

2

3

4

5

6

7

1

2

3

4

5

6

7

1

2

3

4

5

6

7

Your perception about the usefulness of reusing software assets

Strongly disagree

Disagree

Somewhat disagree

Neutral

Somewhat agree

Agree

Strongly agree

Reusing software assets improves my job performance Reusing software assets in my job increases my productivity Reusing software assets enhances my effectiveness on the job Using reusable software assets improves the quality of the work I do

1 1 1 1

2 2 2 2

3 3 3 3

4 4 4 4

5 5 5 5

6 6 6 6

7 7 7 7

Your perception about the ease of reusing software assets

Strongly disagree

Disagree

Somewhat disagree

Neutral

Somewhat agree

Agree

Strongly agree

I feel reusing software assets does not require a lot of my mental effort I find it easy to reuse software assets when developing application It is easy for me to understand reusable software assets

1

2

3

4

5

6

7

1

2

3

4

5

6

7

1

2

3

4

5

6

7

V. Mellarkod et al. / Information & Management 44 (2007) 613–625

623

Your perception about your ability to reuse software assets

Strongly disagree

Disagree

Somewhat disagree

Neutral

Somewhat agree

Agree

Strongly agree

I would reuse software assets, if I could call someone for help if I got stuck I would reuse software assets, if someone helps me get started I would reuse software assets in the future, even if I had not reused software assets in the past

1

2

3

4

5

6

7

1 1

2 2

3 3

4 4

5 5

6 6

7 7

Your perception about the software reuse infrastructure in your organization

Strongly disagree

Disagree

Somewhat disagree

Neutral

Somewhat agree

Agree

Strongly agree

My organization has appropriate standardized processes for Analyzing a domain 1 2 Developing reusable designs 1 2 Developing reusable code 1 2 Integrating reusable assets 1 2

3 3 3 3

4 4 4 4

5 5 5 5

6 6 6 6

7 7 7 7

My organization has relevant domain reuse framework that helps Developing reusable designs 1 2 Developing reusable code 1 2 Integrating reusable assets 1 2

3 3 3

4 4 4

5 5 5

6 6 6

7 7 7

My organization provides relevant methodologies for Analyzing a domain 1 Developing reusable designs 1 Developing reusable code 1 Integrating reusable assets 1

3 3 3 3

4 4 4 4

5 5 5 5

6 6 6 6

7 7 7 7

2 2 2 2

Your perception about the resources allocated for reuse by your organization

Strongly Disagree Somewhat Neutral Somewhat Agree Strongly disagree disagree agree agree

Adequate funds have been allocated to implement software reuse Sufficient staff has been allocated to build reusable software assets Enough time has been provided to promote software reuse Sufficient tools are available to build reusable software assets Sufficient tools are available to reuse software assets

1 1 1 1 1

2 2 2 2 2

3 3 3 3 3

4 4 4 4 4

5 5 5 5 5

6 6 6 6 6

7 7 7 7 7

Your perception about your level of reuse-related experience you possess

Strongly disagree

Disagree

Somewhat disagree

Neutral

Somewhat agree

Agree

Strongly agree

I have a great deal of experience with software reuse I believe that I have sufficient experience for reusing existing software assets

1 1

2 2

3 3

4 4

5 5

6 6

7 7

Your perception of reuse practice in your organization

Strongly disagree

Disagree

Somewhat disagree

Neutral

Somewhat agree

Agree

Strongly agree

The proportion of departmental co-workers who reuse software assets is high The senior management of this business unit has been helpful in promoting reuse of software assets My boss is very supportive of reuse of software assets in my job In general, the organization supports reuse of software assets My project manager wants me to reuse software assets My project manager supports my reusing of software assets Overall, management has encouraged the reuse of software assets

1

2

3

4

5

6

7

1

2

3

4

5

6

7

1 1 1 1 1

2 2 2 2 2

3 3 3 3 3

4 4 4 4 4

5 5 5 5 5

6 6 6 6 6

7 7 7 7 7

Your beliefs regarding software reuse in general

Strongly disagree

Disagree

Somewhat disagree

Neutral

Somewhat agree

Agree

Strongly agree

I dislike reusing software assets In my opinion reusing software assets is undesirable It is more fun to write my own software than to try to reuse

1 1 1

2 2 2

3 3 3

4 4 4

5 5 5

6 6 6

7 7 7

624

V. Mellarkod et al. / Information & Management 44 (2007) 613–625

References [1] U. Apte, C.S. Sankar, M. Thakur, J.E. Turner, Reusability-based strategy for development of information systems: implementation experience of a bank, MIS Quarterly 14 (4), 1990, pp. 420–433. [2] A. Bandura, Social Foundations of Thought and Action: A Social Cognitive Theory, Prentice Hall, Englewood Cliffs, NJ, 1986. [3] B. Barnes, T. Durek, J. Gaffney, A. Pyster, A framework and economic foundation for software reuse, in: W. Tracz (Ed.), IEEE Tutorial: Software Reuse-Emerging Technology, IEEE Computer Society Press, 1988. [4] B.H. Barnes, T.B. Bollinger, Making reuse cost-effective, IEEE Software 1991, pp. 13–24. [5] T.J. Biggerstaff, An assessment and analysis of software reuse, Advances in Computers 34, 1992, pp. 1–57.

[6] D.N. Card, E.R. Comer, Why do so many reuse programs fail? IEEE Software 11 (5), 1994, pp. 114–115. [7] D.R. Compeau, C.A. Higgins, Computer self-efficacy: development of a measure and initial test, MIS Quarterly 19 (2), 1995, pp. 189–211. [8] F.D. Davis, R.P. Bagozzi, P.R. Warshaw, User acceptance of computer technology: a comparison of two theoretical models, Management Science 35, 1989, pp. 982–1003. [9] M. Fishbein, I. Ajzen, Belief, Attitude, Intention, and Behavior: An Introduction to Theory and Research, Addison-Wesley, Reading, MA, 1975. [10] L.Y. Fok, W.M. Fok, S.J. Hartman, Exploring the relationship between total quality management and information system development, Information & Management 38 (6), 2001, pp. 355–371.

V. Mellarkod et al. / Information & Management 44 (2007) 613–625 [11] W.B. Frakes, C.J. Fox, Sixteen questions about software reuse, Communications of the ACM 58 (6), 1995, pp. 75–115. [12] W.B. Frakes, S. Isoda, Success factors of systematic reuse, IEEE Software 11 (5), 1994, pp. 15–19. [13] J.W. Hooper, R.O. Chester, Software Reuse: Guidelines and Methods, Plenum Press, 1991. [14] S. Isoda, Experience report on software reuse project: Its structure, activities and statistical results, in: Proceedings of the 14th Annual International Conference on Software Engineering, 1992, pp. 320–326. [15] R. Joos, Software reuse at Motorola, IEEE Software 1994, pp. 42–47. [16] J. Karimi, An asset-based systems development approach to software reusability, MIS Quarterly 1990, pp. 179–197. [17] Y. Kim, E.A. Stohr, Software reuse: survey and research directions, Journal of management information systems 14 (4), 1998, pp. 113–147. [18] R.G. Lanergan, C.A. Grasso, Software engineering with reusable designs and code, IEEE Transactions Software Engineering 1984, pp. 498–501. [19] M.D. McIlroy, Mass-produced software components, Software Engineering Concepts and Techniques 1969, pp. 88–98. [20] J.C. Nunnally, Psychometric Theory, McGraw-Hill, New York, 1978. [21] R. Prieto-Diaz, Status report: software reusability, IEEE Software 1993, pp. 61–66. [22] J.S. Poulin, J.M. Caruso, D.R. Hancock, The business case for software reuse, IBM Systems Journal 32 (4), 1993, pp. 567–594. [23] T. Ravichandran, M.A. Rothenberger, Software reuse strategies and component markets, Communications of the ACM 46 (8), August 2003, pp. 109–114. [24] D.C. Rine, R.M. Sonnemann, Investments in reusable software. A study of software reuse investment success factors, The Journal of Systems and Software 41, 1998, pp. 17–32. [25] D.C. Rine, N. Nada, An empirical study of a software reuse reference model, Information and Software Technology 42, 2000, pp. 47–65. [26] M.A. Rothenberger, Project-level reuse factors: drivers for variation within software development environment, Decision sciences 2003, pp. 83–107. [27] K. Sherif, A. Vinze, A qualitative model for barriers to software reuse adoption, International Conference on Information Systems 1999. [28] K. Sherif, A. Vinze, Barriers to adoption of software reuse: a qualitative study, Information and Management Journal 2002. [29] M.E. Swanson, S.K. Curry, Results of an asset engineering program, Information & Management 16 (4), 1989, pp. 207–217. [30] W. Tracz, Software Reuse: Motivators and Inhibitors, Digest of Papers COMPCON, IEEE Catalog Number 87CH2409-1, Computer Society Order Number 764, Computer Society Press of the IEEE, Washington, D.C., 1987, pp. 358–363. [31] V. Venkatesh, M. Morris, G. Davis, F. Davis, User acceptance of information technology: toward a unified view, MIS Quarterly 27 (3), 2003, pp. 425–478.

625

Donald R. Jones, Ph.D., is an associate professor of management information systems, Texas Tech University. His Ph.D. is in information systems from the University of Texas at Austin. His principal research interest is how information technology affects decision making. He has published in journals such as Organizational Behavior and Human Decision Processes, Decision Support Systems, Journal of Information Systems, and Auditing: A Journal of Practice and Theory. He is currently on the editorial board of the Journal of Information Systems. Karma Sherif is an associate professor at the Jessie H. Jones School of Business, Texas Southern University. She received her Ph.D. degree in management information systems from Texas A&M University. She also holds an M.S. degree in MIS from Texas A&M and a B.A. in Business Administration from The American University in Cairo. Before pursuing her doctoral studies, Karma worked as an Information Systems consultant at DATACOMP, a leading IT consulting firm. Karma has articles in journals such as MIS Quarterly, Decision Support Systems, Journal of the Association of Information Systems, Information & Management, and Journal of Knowledge Management. She has taught courses on object-oriented programming, electronic commerce, systems design, knowledge management systems, and MIS research methods. Her research interests focus on the adoption of new software development processes and their effect on intra-organizational relationships. Radha Appan is an assistant professor of computer information science at Cleveland State University. She received her Ph.D. in information systems from Texas Tech University. Her research interests include software reuse, systems analysis, online auction markets, human decision making, and e-commerce related trust issues. She has taught courses such as IT for managers, knowledge management, database management, systems analysis and production and operations management. She has published papers in refereed journals such as Decision Support Systems, International Journal of Information Management, and Journal of Information Technology. She has also published her work in several conferences. Vidhya Mellarkod is a doctoral student at Texas Tech University. She is currently working as the Manager of Performance Insights at Kohl’s Department Stores-Corporate Office. Her primary research interests include the psychology behind the relationships between the user teams and IS teams, the reuse of knowledge assets, and website usage behavior. She has published her work in many conferences.