Determinants of software quality in offshore development – An empirical study
of an Indian vendor
G. Kannabiran
⇑, K. Sankaran
National Institute of Technology, Tiruchirappalli 620 015, India
a r t i c l e
i n f o
Article history:
Received 29 September 2010 Received in revised form 18 April 2011 Accepted 5 May 2011
Available online 17 May 2011 Keywords: Determinants Quality attributes Offshoring Indian organizations
a b s t r a c t
Context: Cost advantage has been one of the primary drivers of successful offshoring engagements of Indian software and services companies. However, the emphasis has shifted to the ability of the vendors to provide high quality over cost advantage in delivering software products and services. Meeting high quality requirements of the clients is a challenge due to the very nature of development and delivery of software through offshoring.
Objective: The objective of this research paper is to identify and evaluate the key determinants of quality in the case of software projects delivered through offshoring model.
Method: A detailed survey was conducted among project managers/project leaders (leads) of a leading midsize Indian IT services company to evaluate the relationship of the determinants on the attributes of quality.
Results: Out of six determinants, our research reveals requirements uncertainty has significant associa-tion with all the attributes of quality. While process maturity and trained personnel have moderate asso-ciation, communication and control, knowledge transfer and integration and technical infrastructure have relatively low association on software quality attributes in the case of offshoring.
Conclusion: It is concluded that the complexities in offshoring necessitates proper capturing of require-ments. In addition high level of process maturity and availability of trained personnel to the project will help vendors to achieve software quality. The paper provides a set of implications for practice and direc-tions for further research.
Ó 2011 Elsevier B.V. All rights reserved.
1. Introduction
The Indian IT (Information Technology) industry has registered a sustained growth over the past decade and has emerged as a glo-bal destination for offshoring. Many Indian software companies have become an acclaimed ‘‘vendor’’ for offshore software develop-ment due to their delivery capabilities, characterized by quality and cost-effective software to the customers across the globe. Primarily driven by cost considerations, increasing number of soft-ware projects have been outsourced by organizations in the US and Europe to firms in countries such as India and China. In recent times, managers of both outsourcing and vendor firms have real-ized that cost considerations, generally assumed to be the primary reason for offshore outsourcing, need to be balanced with the focus on high quality. In the past few years, the Indian software industry has pursued the goal of acquiring the highest standards of quality and has thus created a strong value proposition in the software and services arena.
Researchers have indicated that in view of the decreasing cost advantages, Indian offshore vendors need to change focus from ‘cost’ to the ‘‘quality’’ related measures of the software services provided[12,16]. It is rather this shift of focus towards developing the ability to provide higher quality software services and thus moving up the value chain is a strategic necessity for the vendor
[21]. Therefore, software quality is a very important aspect in evolving strategy for both offshore vendors and customers. Although, offshore software development had gained prominence over the past two decades, even today the subject of software qual-ity has not been addressed adequately[62]. It is reported that there have been only few comprehensive studies on factors that impact software quality; but quantitative survey-based research is lacking on the subject[82]. Software quality research has focused on the technical and engineering aspects of quality control, while paying limited attention to the organizational dimensions [67]. These researchers also admit that there is inadequacy and insufficiency of empirical studies investigating the management and control of quality of software development. Therefore, this paper empirically evaluates the key factors that determine the quality in offshore software development, through a study of leading IT Services Company in India.
0950-5849/$ - see front matter Ó 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.infsof.2011.05.001
⇑ Corresponding author. Tel.: +91 431 2503703; fax: +91 431 2500133. E-mail address:[email protected](G. Kannabiran).
Contents lists available atScienceDirect
Information and Software Technology
The present research study has taken into consideration the ‘software quality’ as defined by the ISO/IEC 9126 model. The re-search work was undertaken by operationalizing the software quality as the ‘dependent variable’ which in turn, consists of five key attributes of quality – Functionality, Reliability, Maintainabil-ity, Usability and Performance. The determinants are considered as ‘independent variables’ include requirements uncertainty (RU), technical infrastructure (TI), knowledge transfer and integration (KTI), process maturity (PM), trained personnel (TP) and communi-cation and control (CC). The paper is organized as follows. The re-view of previous research is presented followed by research objectives and methodology. The next section covers the data anal-ysis and interpretation, followed by the discussion on the relative importance of the determinants. The paper is concluded with implications for practice and directions for future research.
2. Previous research
Both practitioners and academicians claim that software quality as one of the critical issues of the decade[45,87,91]. The impor-tance of software quality has been stressed by authors who ob-served that software quality can determine the success or failure of a software product in today’s competitive market[81,53]. Jalote
[38]observed that software quality represents how well the prod-uct satisfies the customer. The importance of concentrating on quality efforts during the development process was highlighted and the benefits of process standardization through CMM (Capabil-ity Matur(Capabil-ity Model) and similar initiatives of higher process matu-rity levels will lead to higher development quality[75]. The need for quality management in software projects becomes highly rele-vant in this context and quality of software is receiving a great deal of attention. Quality management is one of the methods for reduc-ing the cost of production, by eliminatreduc-ing inefficiencies in the development processes. In an effort to keep costs within budget and simultaneously to meet the scheduled time of delivery, IT firms are adopting various quality management practices[32,84]. The relevant previous research relating to software quality and its determinants are reviewed and presented in the following sec-tion/sub-sections. Further, the literature review for each determi-nants of software quality is presented in the subsequent sections. 2.1. Software quality (SQ)
Assessing software quality in the early stages of design and development is crucial as it helps reduce effort, time and money
[2]. Many definitions of software quality (SQ) are in use, which in general agree on what quality means and it can be enshrined by the phrase ‘satisfaction of customer requirements’ [90]. SQ is a multidimensional measure and it is essential to determine what aspects of quality are important to organizations. There are essen-tially two approaches that can be followed to ensure software product quality, one being assurance of the process by which the product is developed, and the other being the evaluation of the quality of the end product. The state of the art in software technol-ogy does not yet present a well established and widely accepted description scheme for assessing the quality of software products. Much work has been done by a number of individuals to define a SQ model which acts as a framework for the evaluation of attri-butes of SQ[8].
Traditionally, SQ has been defined to be composed of correct-ness, reliability, usability, and maintainability[20]. Quality models have been developed in the past, the most widely known of which being McCall’s and Boehm’s, and more recently the ISO9126. In 1991, International Organization for Standardization introduced a standard named ISO/IEC 9126 software product evaluation-quality
characteristics and guidelines for use[43]. McCall’s model is an early, product-oriented quality model, which shows how external quality factors, such as correctness, reliability, efficiency, etc., re-late to product quality criteria, such as completeness, accuracy, er-ror tolerance, etc. These product criteria can be measured and thus external quality factors may be assessed[56]. Boehm et al. [10]
proposed the same hierarchical structure as McCall’s model, but also put emphasis on users’ expectations and hardware perfor-mance. The complexity of Boehm’s model is equal to that of McCall’s, that is, the quality criteria are related to a variety of qual-ity attributes with relations sharing common attributes. Another model for IS success was proposed by incorporating six interde-pendent measures viz., system quality, information quality, user satisfaction, individual impact and organizational impact [18]. Finally, the ISO 9126 model follows the same approach as the other two aforementioned models, with the main difference being that the level of complexity is lower here as the hierarchy is stricter that each quality characteristic is related only to exactly one attribute, with no common attributes between characteristics.
2.1.1. Software quality attributes
As per ISO 9126 standard, quality is defined as ‘‘the totality of features and characteristics of a product or service that bears on its ability to satisfy given needs’’[1]. Yang[91]identified that qual-ity of the software product could be estimated using its attributes, such as reliability, maintainability, functionality, extensibility, and usability. SQ has also been defined[9]in terms of two types of product characteristics: (i) external quality (how the product works in its environment), like usability and reliability, and (ii) internal quality (how the product was developed), such as, soft-ware structure and complexity [27]. External SQ attributes are being emphasized as they have been already validated through a study carried out in the recent past[40]. A recent study by Gorla and Lin[26]on determinants of SQ through a survey of Information system project managers has found that organizational factors are more important than technical factors in impacting SQ.
According to ISO 9126 model, there are six major characteristics (also sometimes called quality factors), namely, functionality, reli-ability, usreli-ability, efficiency, maintainability and portreli-ability, along with their associated sub-characteristics [4]. However, many researchers have customized these generic quality attributes suit-ing to their context. For example the attribute ‘portability’ is con-sidered applicable only in software products that need to be implemented on multiple platforms[23]. The desirable SQ attri-butes for web applications are reliability, usability, security, avail-ability, scalavail-ability, maintainavail-ability, and time to market [8]. Similarly, efficiency attribute is viewed as an internal quality attri-bute as it deals with time behavior and computing resources con-sumed[26]. The following quality attributes are adapted from on ISO 9126 model for measurement.
2.1.1.1. Functionality. It is the capability of the software product to provide functions which meet stated and implied needs when it is used under specified conditions. It includes the following sub-char-acteristics: suitability, accuracy, interoperability, compliance and security. Functionality expresses the ability of a system to provide the required services and functions, when used under specified conditions[26,57,88].
2.1.1.2. Reliability. A set of attributes that bear on the capability of a software product to maintain its level of performance under stated conditions for a stated period of time. It includes the following sub-characteristics: maturity, fault tolerance and recoverability. Reliability is an indication of the confidence that the software will live up to the expectations[55,13].
2.1.1.3. Maintainability. A set of attributes that bear on the effort needed to make specified changes. It includes the following sub-characteristics: analyzability, changeability, stability and testabil-ity. Maintainability relates to the means provided by the software to be upgraded and customized. In this context, software process improvement (SPI) helps to enhance maintainability of the soft-ware[8,41].
2.1.1.4. Usability. It is the capability of a software product to be understood, learned, used and liked by the user, when used under specified conditions. It includes the following sub-characteristics-understandability, learnability and operability. Usability indicates the understandability of software as well as the easiness to learn and operate it[3,31,44].
2.1.1.5. Performance. A set of attributes that bear on the relation-ship between the level of performance of the software product and the amount of resources used under stated conditions. It in-cludes the following sub-characteristics: time behavior and re-source behavior. In our research, the attribute efficiency is substituted by ‘performance’ of the software in our chosen list of software quality attributes[4,48].
2.2. Requirements uncertainty [RU]
According to Parnas[61], requirements uncertainty (RU) means that within a software system, requirements are not known until it is practically used. Requirements uncertainty emerges from inabil-ity to apply a standardized process to convert requirements into functional specifications[66]. Previous studies[7,59,32,85,30] po-sit RU to be an important source of poor quality in software devel-opment. This uncertainty results from software requirements creating an ill-defined problem. According to Pressman [66], as requirements keep changing in the project life cycle, subsequent changes in the design and rework needs create disruptions in man-aging requirements and provide scope for defects. Unstable requirements lead to sub-optimal design during the initial phases of the project[66].
Ebert and De Man[14]observed that no single technique will be applicable but a combination of techniques need to be applied for managing the RU in software projects. Further, when there is user diversity in requirements, the vendor needs to address and recon-cile the differences [59]. Apart from not meeting the quality requirements, RU leads to projects delays and cost overrun. While most studies have hypothesized the effects of RU in in-house pro-jects, its effects are magnified in the offshore domain due to barri-ers of geographical and organizational boundaries between the client and vendor[25]. Therefore, it may be considered that RU will affect adversely the quality of software in projects. The variable RU was measured based on the construct used by Nidumolu[59]with the additional items arrived through discussion with industry experts.
2.3. Technical infrastructure (TI)
TI refers to interconnecting hardware and software and other devices that are interconnected to support the flow and processing of information[6]. It becomes very vital in the case of software industries, where the technological advancement is experienced at a very rapid pace and the adaptation of technological advance-ment is mandatory for the very survival of software organizations. SQ depends on availability of good tools, good materials, good methods and management techniques, and latest technological developments[52]. Jones[42]identified that the improvement of infrastructure (support facilities) was one of the essential elements of successful development. Many researchers have found
obsoles-cence of technologies as the major risk faced by software compa-nies[7,38,71].
Exposure to latest technology and availability of facilities, including latest hardware and software, play a crucial role with re-spect to SQ. Several authors have expressed the need for telecom-munication, software tools as part of the infrastructural facilities available for software development[15,17,63,77,39]. Rao[70]also claimed that the facilities and work environment would add to the motivational value of the employees. The purpose of the work environment is to establish and maintain physical working condi-tions that allow individuals to perform their tasks efficiently and to concentrate on their tasks without unnecessary distractions. Bah-rami and Evans[6]argued that providing the facilities and stable physical environment could improve the development environ-ment. The variable TI was measured using the construct developed by Rajendran et al.[68].
2.4. Trained personnel (TP)
Availability of TP is a key factor of software quality. Individual capability was found to be the most significant determinant of per-formance among the software developers. Curtis et al.[37] advo-cated that trained individuals are those who have superior application knowledge, communication skills, high levels of moti-vation, team spirit and dependability are ‘essential’ for the success of a software project. Prior research has highlighted the impor-tance of personnel competence in developing high-quality soft-ware. This effect should be particularly true in the offshore development since there is always a supply–demand mismatch with respect to trained professionals[78]. Pressman[66]observed that trained programmers use better design techniques, are more aware of the link between requirements and systems parameters and are able to write better code. Experienced personnel are also more capable in testing and defect prevention activities, thereby resulting in better quality and more productive use of resources
[49].
In offshoring projects, the availability/non-availability of trained personnel is further affected by the continuity in the staff-ing of projects. Frequent staffing changes affect quality because dif-ferent personnel, at difdif-ferent points in times, make changes to the project that may have little relation to earlier choices and specifi-cations. More particularly, it leads to poor design and development of the project, leading to poor quality. Thus, the lack of trained per-sonnel impacts quality of offshore projects in two ways: first, by the staffing of inexperienced and untrained personnel and second, by frequently shifting personnel between projects as managers seek to manage multiple projects with insufficient numbers of trained personnel[25]. The variable TP is measured by the extent to which trained staff were deployed in the project and adopted from Lacity & Hirshheim[64].
2.5. Knowledge transfer and integration [KTI]
Knowledge transfer and integration is defined as the process of absorbing knowledge from external sources and blending it with the technical and business skills, know-how, and expertise that re-side in the business and IS units of a firm[29,60]. The role and importance of knowledge in software development is widely rec-ognized by previous researchers[19,86]. Rus and Lindvall[76]
ob-served two types of knowledge central to the software
development process-technical knowledge that is used to develop a system and knowledge about the business application domain. Technical knowledge refers to knowledge about design (e.g. design patterns, heuristics best practices, technical constraints, and esti-mation models), programming (e.g. programming languages and development tools), and software processes (e.g. methodology,
code testing and debugging procedures). Business application do-main knowledge refers to knowledge about the customer’s busi-ness processes, busibusi-ness rules, activities, stakeholder needs, and the customer’s business objectives for the software.
Internal knowledge Integration refers to the extent to which the development team builds on the knowledge of the stakeholders during the development process. External integration refers to the knowledge relating to market needs, regulatory constraints, external environment and business and technical developments that may affect development project[65]. Adopting the develop-ment project as the focal point, both external and internal integra-tion are considered to be important in achieving quality[54,83]. This variable was measured based on the construct used by Tiwana et al.[92]with the additional items derived through discussions with industry experts.
2.6. Communication and control (CC)
Communication and control (CC) is broadly defined as the pro-active formal and informal sharing or exchange of meaningful and timely information between firms[5]. This definition focuses on the efficacy of information exchange, rather than quantity. Inher-ent in this definition is the notion that communication is a two-way process; the information flow is not unidirectional, and should go beyond day-to-day exchanges of routine operational informa-tion to include open exchanges of desires, needs, and resources that will affect the future of the relationship [33,47]. A control mode is a formal arrangement practiced by both vendors and cus-tomers in software projects facilitating the interaction among the teams. Communication and control mechanisms in offshore devel-opment reduce project uncertainty and thereby improve quality
[24].
Previous researchers[46,58]have suggested the importance of communication in inter-organizational relationship. Communica-tion helps to provide better control of processes, which in turn helps to improve quality [11]. A study of large-scale software development in a major U.S. firm showed the importance of com-munication in the development process [50]. Similarly, Grover et al. [28]found that communication is a main determinant for the success of offshoring. Communication was also found to corre-late positively with offshoring partnership quality[51]. The vari-able CC was measured based on the construct used by Lee and Kim [51]with the additional items derived through discussions with industry experts.
2.7. Process maturity (PM)
Process maturity (PM) is defined as the indication of how close a developing process is to being complete, and capable of continuous improvement through quantitative measure and feedback [79]. Software development process is viewed as vital for getting new products of good quality, quickly into the market [74]. Process improvement enables the same amount of software to be built in less time, with less effort and fewer defects [38]. The efficiency of the software development process is an important issue facing the researchers and practitioners[89]. Hence, to improve the prod-uct quality, the processes need to be improved continuously
[11,35,52]. Huyink [36]observed that the documentation of the processes would help to provide a better control over the pro-cesses, which would lead to quality improvement.
Harter et al.[32]observed that quality improvement; cycle time and effort reduction can be simultaneously achieved by fewer de-fects and rework in software development. Maturity implies a po-tential for growth in capability and indicates both the richness and consistency with which software processes are applied across the
organization [59]. Many researchers have endorsed the view that process improvements are vital for improving software quality [11,38,52]. Hevner [34] observed that development of high-quality software is an essential business activity and improv-ing the quality requires the effective use of a software develop-ment process. Higher level of process maturity, invariably, results in the enhancement of SQ[80]. The variable PM was measured based on the construct used by Ravichandran and Rai [67] by including few more items derived through discussions with industry experts.
3. Research objectives and methodology
Software quality research has focused on the technical and engineering aspects of quality control, while paying limited atten-tion to the organizaatten-tional dimensions[67]. However, current chal-lenges facing software development and quality improvement are largely organizational and not technical in nature[68,25]. It is also found that theories and principles were being drawn from other areas; the empirical research is still in its early stage. Based on the detailed review of the previous research on the factors impact-ing the SQ attributes, in the context of offshore software develop-ment, the objectives of the research are to identify and evaluate the impact of determinants on the specific SQ attributes in the offshor-ing context. The conceptual research model coveroffshor-ing the depen-dent variable, viz., attributes of software quality (SQ) and the independent variables, viz., the determinants listed above, is pre-sented inFig. 1. The factors are observed to influence the software development process, and thereby, the SQ.
The study was carried out in one of the leading midsize IT Ser-vices organizations in India, referred as Helix. The organization is a provider of IT and BPO (Business Process Outsourcing) services and consulting. Founded in 1990, the organization today has seven state-of-the-art development centers - four in India and one each in Germany, USA and Mexico, and offices in North America, Europe and Asia Pacific, and employs around 5200 workers globally. With 159 active clients, Helix has achieved leadership position in indus-tries such as Healthcare and Life sciences, Manufacturing, Travel, Transportation, Hospitality and Logistics, Banking, Finance, Insur-ance, Leasing and in Domains such as HR and Business Analytics. Helix has achieved the rare distinction of having SEI CMMI Level 5, ISO 9001, BS 7799 and SAS 70 Type I certifications. We choose and used a two-stage methodology to meet the objectives of the research.
In the first stage, given the paucity of empirical knowledge on the SQ in the context of offshoring, and the exploratory nature of the study, we carried out a qualitative case-study to validate the variables [93]. Open and semi-structured interviews were con-ducted with few senior executives, heads of Quality and Practice. These interviews, conducted through few site-visits, covered all aspects of SQ in the organization, with specific reference to QM planning and implementation for projects. The case study findings are used to validate the six important drivers of quality in the con-text of offshore software development. Some of the items were used by previous researchers were also found to be relevant to our research[25,67]. The objectives of the research and the con-ceptual research model are translated into six sets of hypotheses as detailed below:
Set-1: Hypotheses related to requirements uncertainty: H1.1: Higher the RU lower will be the functionality.
H1.2: Higher the RU lower will be the reliability.
H1.3: Higher the RU lower will be the maintainability.
H1.5: Higher the RU lower will be the performance.
Set-2: Hypotheses related to technical infrastructure: H2.1: TI facilities will positively influence the functionality.
H2.2: TI facilities will positively influence the reliability.
H2.3: TI facilities will positively influence the maintainability.
H2.4: TI facilities will positively influence the usability.
H2.5: TI facilities will positively influence the performance.
Set-3: Hypotheses related to trained personnel:
H3.1: TP available for the project will positively influence the
functionality.
H3.2: TP available for the project will positively influence the
reliability.
H3.3: TP available for the project will positively influence the
maintainability.
H3.4: TP available for the project will positively influence the
usability.
H3.5: TP available for the project will positively influence the
performance.
Set-4: Hypotheses related to knowledge transfer and integration: H4.1: KTI will positively influence the functionality.
H4.2: KTI will positively influence the reliability.
H4.3: KTI will positively influence the maintainability.
H4.4: KTI will positively influence the usability.
H4.5: KTI will positively influence the performance.
Set-5: Hypotheses related to communication and control: H5.1: CC will positively influence the functionality.
H5.2: CC will positively influence the reliability.
H5.3: CC will positively influence the maintainability.
H5.4: CC will positively influence the usability.
H5.5: CC will positively influence the performance.
Set-6: Hypotheses related to process maturity:
H6.1: Higher level of PM will improve the functionality.
H6.2: Higher level of PM will improve the reliability.
H6.3: Higher level of PM will improve the maintainability.
H6.4: Higher level of PM will improve the usability.
H6.5: Higher level of PM will improve the performance.
The questionnaire was pilot tested with few PMs/PLs and the respondents thoroughly examined the item wording, applicability, readability, understandability and content validity. The question-naire for the survey covered items relating to all the independent and dependent variables shown inFig. 1. The items were measured using a 5-point Likert Scale, ranging from ‘strongly agree’ to ‘strongly disagree’. The data was collected from project managers located in three different sites. The video conferencing sessions were used to brief the project managers/leads (in groups) who were identified as respondents of the survey. However, most of
the responses were collected through e-mails. Out of about 500 projects that were executed during the year, 100 projects were randomly chosen. However, responses from 70 PMs/PLs were re-ceived. The data was collected during May–June 2010. The summa-rized list of questionnaire items is furnished in Appendix A.
4. Data analysis and interpretation
Using the data collected through the survey, a reliability analy-sis of the measure of each variable was performed using Cronbach’s alpha. Thereafter, a Confirmatory Factor Analysis was carried out for all constructs for checking unidimensionality and convergent validity of the constructs. The results of the analysis relating to validity and reliability are presented inTable 1. The reli-ability was tested using and Cronbach’s alpha. It is found that value of Cronbach’s alpha for all the variables is above 0.75, thus verify-ing the reliability of data collected for the study. Confirmatory Factor Analysis (CFA) ensured unidimensionality and convergent validity. The results shown inTable 1indicate that the Compara-tive Fit Index > 0.90 for all variables, supporting unidimensionality. Similarly, convergent validity is checked by the (NFI = Normed Fit Index (Bentler-Bonnet Index) > 0.90) for all the variables of the study.
Spearman and Pearson’s 2-tailed correlation analysis was to check the inter-relationships between the constructs. The bi-vari-ate correlation coefficient factors are presented inTable 2. It can be observed from the results of the bi-variate correlation analysis that most of the correlation coefficients, except few are relatively Requirements Certainty Technology Infrastructure Process Maturity Software Quality FUNCTIONALITY RELIABILITY MAINTAINABILITY USABILITY PERFORMANCE Communication & Control Trained Personnel Knowledge Transfer and Integration
Fig. 1. Conceptual research framework.
Table 1
Reliability, validity and unidimensionality of the constructs.
Factor/construct No. of Items Cronbach alpha CFI* NFI** Functionality 4 0.84 0.99 0.99 Reliability 4 0.80 0.99 0.97 Maintainability 4 0.76 0.93 0.94 Usability 4 0.75 0.92 0.93 Performance 4 0.82 0.99 0.95 Requirements uncertainty 7 0.89 0.96 0.95 Technical infrastructure 4 0.74 0.99 0.98 Knowledge transfer and integration 7 0.75 0.94 0.98
Process maturity 5 0.84 0.93 0.97
Trained personnel 4 0.88 0.96 0.95
Communication and control 5 0.73 0.98 0.93 *CFI = Comparative Fit Index > 0.90 indicates unidimentionality.
** NFI = Normed Fit Index (Bentler-Bonnet Index) > 0.90 indicates convergent validity.
very low. The low correlations among the factors indicate a low de-gree of interdependence among the variables.
In our analysis, multiple regression was employed to study the impact of independent variables, viz., requirements uncertainty, technical infrastructure, knowledge transfer and integration, pro-cess maturity, trained personnel and communication and control on the software quality attributes. The independent variables were regressed on each dependent variable, the quality attributes using the SPSS package and a comprehensive summary of the b, t and p values is presented inTable 3for easy of interpretation of results.
Table 4 provides a summary of ‘supported’ versus ‘rejected’ hypotheses of our research. It is found that out of 30 hypotheses 15 hypotheses were supported.
5. Results and discussion
We found hypotheses H1.1, H1.2, H1.3, H1.4 and H1.5 are
sup-ported and therefore it is found that requirements uncertainty (RU) is associated with all attributes, viz., functionality, reliability, maintainability, usability and performance of SQ. We found sup-port for hypothesis H2.2, showing that the technical infrastructure
significantly associated with the reliability attribute of the SQ. Sim-ilarly, we observed that hypotheses H3.1, H3.2and H3.5 are
sup-ported and therefore trained manpower has significant
relationship with the functionality, reliability and performance of the SQ. We have significant support for the hypothesis H4.1which
confirms that knowledge transfer and integration is related to functionality attribute of SQ. Our results show the support for hypotheses H5.2and H5.4which lead us to the finding that
commu-nication and control is associated with reliability and usability. Fi-nally, we observed significant support for hypotheses H6.1, H6.2and
H6.3showing that process maturity significantly affected the
qual-ity attributes functionalqual-ity, reliabilqual-ity and maintainabilqual-ity of the SQ. In the offshore development, although RU affects all quality attributes, it can be inferred from the b values inTable 3that it is highly related with maintainability and moderate on the usabil-ity, performance and functionality while its association on reliabil-ity is relatively low. In the same manner, we infer that the process maturity has a higher level of association with functionality and reliability while its association is relatively low on maintainability. Extending the same line of arguments, communication and control is related to reliability more as compared the usability attribute. The theoretical implications are in the forthcoming sections.
Table 2
Bi-variate correlation among the constructs of software quality and determinants.
RU TI KTI PM TP CC Funct Relia Maint Usabi Perfo
RU 1.00 TI 0.14 1.00 KTI 0.01 0.08 1.00 PM 0.20 0.283 0.484 1.00 TP 0.270* 0.01 0.13 0.21 1.00 CC 0.282* 0.286* 0.418* 0.599** 0.03 1.00 Funct 0.23 0.19 0.08 0.315** 0.04 0.20 1.00 Relia 0.09 0.18 0.05 0.00 0.13 0.20 0.22 1.00 Maint 0.306** 0.18 0.02 0.18 0.05 0.02 0.579** 0.21 1.00 Usabi 0.249* 0.07 0.04 0.13 0.05 0.06 0.549** 0.18 0.600** 1.00 Perfo 0.298* 0.19 0.04 0.15 0.12 0.08 0.451 0.16 0.456** 0.397** 1.00 *Significant at a level of p < 0.05. ** Significant at a level of p < 0.01. Table 3
Summary of multiple regression results.
Independent Variable Dependent Variable
Functionality Reliability Maintainability Usability Performance Beta t Sig[p] Beta t Sig[p] Beta t Sig[p] Beta t Sig[p] Beta t Sig[p] Requirements uncertainty 0.26 2.27 0.03* 0.20 2.78 0.04* 0.31 2.39 0.02* 0.29 2.15 0.04* 0.27 2.04 0.05*
Technical infrastructure 0.09 0.76 0.45 0.26 2.11 0.04* 0.14 1.10 0.28 0.06 0.44 0.66 0.15 1.21 0.23
Knowledge transfer and integration 0.29 2.44 0.04* 0.14 1.06 0.29 0.05 0.38 0.70 0.06 0.41 0.68 0.02 0.11 0.91
Process maturity 0.33 2.02 0.05* 0.32 2.99 0.03* 0.25 2.54 0.04* 0.23 1.41 0.17 0.15 0.90 0.37
Trained personnel 0.26 2.46 0.01** 0.28 2.57 0.02* 0.00 0.01 0.99 0.02 0.17 0.87 0.25 2.18 0.04*
Communication and control 0.04 0.27 0.79 0.40 2.61 0.01** 0.23 1.51 0.14 0.32 2.45 0.05* 0.13 0.86 0.39
*Significant at a level of p < 0.05. **
Significant at a level of p < 0.01.
Table 4
Summary of hypotheses supported versus rejected.
Sl. No. Variable Functionality Reliability Maintainability Usability Performance
1 Requirements uncertainty H11a H12a H13a H14a H15a
2 Technical infrastructure H21 H22a H23 H24 H25
3 Trained personnel H31a H32a H33 H34 H35a
4 Knowledge transfer and integration H41a H42 H43 H44 H45
5 Communication and control H51 H52a H53 H54a H55
6 Process maturity H61a H62a H63a H64 H65
A
Requirements uncertainty has been identified as a key factor which poses lot of challenges in the project execution, particularly in the case of software projects[7,59,32]. As requirements keep changing throughout the life cycle of the project, subsequent changes to the design and the need for rework creates disruptions in the organization’s processes for managing requirements result-ing in significant scope for defects[66]. Our research further shows that RU relates to all the attributes of quality in the case of offsh-oring. It was due to the fact that requirements are captured by an on-site team, which are typically in the vendor organization. Understanding of business context, processes and end-user expec-tations is likely to get affected by the very approach of gathering requirements and therefore relates to all the quality attributes. Requirements may keep changing and offshoring models limit the possibility of further validations. Moreover, high association of RU on maintainability may be attributed to the limitation of offshoring to understand the future requirements.
Several authors have expressed the need for telecommunica-tion, software tools as part of the technical infrastructure available for software development[15,17,52,63,77,39]. It is found the tech-nical infrastructure is significantly associated to the reliability attribute of the SQ in offshoring. This is due to the fact that most of the projects that are offshored are developed through extensive use of automation tools and reusable codes. Such approaches to software development would have direct impact on the reliability of the software. The availability and cost of connectivity may affect the scope for detailed discussions needed for capturing finer reli-ability requirements. However, it shown that the infrastructure does not relate to functionality, maintainability, usability and the performance of the software in offshored projects.
Previous researchers have posited that the availability of trained manpower is a major challenge experienced by all vendors of Indian IT Industry. Our research outcomes also supported this, as one of the most perennial problems faced by offshore vendors is the increasing difficulty in attracting and retaining trained per-sonnel[25,37,64]. Experienced personnel are more capable in test-ing and defect prevention activities, thereby leadtest-ing to better quality and more productive use of resources [49]. To combat the above, the research reveals that the organization has imple-mented need-based training in order to meet its manpower requirements for various projects. Hence, the presence of trained personnel positively enables the quality software development by the vendor organization as in case of software industry. Our research shows that ‘trained personnel’ is associated with func-tionality, reliability and performance of the software. In respect of maintainability and usability which are not associated with the determinant, it is felt that the users will have a greater role to play as these attributes address the post development needs of the software.
Process maturity is essential for executing the software pro-jects, there by promoting SQ [11,38,52]. The organization was treating the quality processes with high priority as vendors need to adapt to different software development methodologies in line with the requirements of clients. When there are multiple custom-ers from many international ventures, it is important that the soft-ware methodologies are flexible and adaptable to multiple customers[34,69]. Our research reinforces the previous research findings with regard to the role of process maturity in ensuring the SQ. Further, it is also shown that process maturity significantly associated with functionality, reliability and maintainability attri-butes of SQ. When the software is developed in offshoring mode with less interaction among the members of the development teams and the end-users, matured processes ensure achieving key attributes of quality.
Our research reveals that the organizations need to establish effective communication and control mechanism among the
developers and the customers and facilitated development with a view to resolve issues, reduce project uncertainty and improve per-formance[5,24].The study reveals the importance assigned to the communication processes among various teams functioning at both on-site and offshore locations as observed and by many researchers[46,58,11]in the software development projects, par-ticularly, in the context of offshore projects. Thus, the research sub-scribes to the view that communication and control was a key organizational factor, found to have a significant relationship with SQ in the offshoring context. Further, it is found that communica-tion and control is related to reliability and usability attributes of the quality. Better communication with end-users, especially in offshoring, would help to improve the usability of the software. Time zone differences and organizational culture including deci-sion making and reporting styles affect communication.
Our research also shows that knowledge transfer and integra-tion (KTI) as one of the main inputs for quality software develop-ment[22,73,86]. The research reveals that software development can be viewed as a process of integrating technical and business domain knowledge in developing a solution to a business problem
[72,76]. Various project stakeholders including members of the cli-ent and vendors bring a variety of skills, knowledge, and view-points to the software development process. The research also suggests that the organization has successfully implemented pro-cesses to achieve integration of knowledge transfer, by blending both business and technical knowledge acquired by the teams and applied for software development [92]. Further, knowledge transfer and integration shows significant association with the functionality attribute of SQ in offshoring. The very approach of offshoring provides limited window of time for the teams to under-stand the technical and business complexities and therefore affects the functionality of the software.
6. Implications for practice
India has the largest number of companies in the world that are certified for quality standards According to NASSCOM (2006), over 440 Indian companies had acquired quality certifications with 90 companies certified at SEI CMM Level 5 – higher than any other country in the world. This demonstrates the maturity levels achieved in quality by the Indian software industry. This study has attempted to identify and evaluate the key determinants which influence the SQ during the software development by the vendor. In the light of increasing pressures on managers to improve soft-ware quality and the growing importance of quality management systems in vendor organizations this study is both timely and sig-nificant. Our research has many implications for practitioners in this field.
Firstly, all the determinants have significant relationship with SQ in the case of offshoring. It is found that requirements uncer-tainty (RU) is related to all attributes, viz., functionality, reliability, maintainability, usability and performance of SQ. It is evident that RU is the foremost factor that is associated with all the attributes of SQ. Practitioners have to ensure very low requirements uncer-tainty. Use of Agile methodologies and CASE for capturing require-ments would help the managers to achieve high level of certainty in requirements. The association of RU with maintainability is high and moderate on the usability, performance and functionality. The very nature of offshoring has limited scope for repeated validations of the requirements, and therefore it affects all the attributes of quality. Further, practitioners have to concentrate on RU if the fo-cus is on the long-term relevance and usefulness of the software.
It is found the technical infrastructure significantly associated with the reliability attribute of the SQ in the case of offshoring. It is also shown that the infrastructure does not relate to
functionality, maintainability, usability and the performance of the software in the offshoring as there are other determinants which may have better relationship with them. Therefore, prac-titioners may need to focus on TI if the primary requirements are to meet the reliability of the software. This can be achieved by using appropriate development platforms and tools. This is required because most of the projects that are offshored are developed through extensive use of tools for process automation and reusable codes. Such approaches to software development would have direct impact on the reliability of the software. Pres-ence of trained personnel positively enables the software quality in the case of offshoring. It is also shown that ‘trained personnel’ is related to functionality, reliability and performance of the software. Practitioners need to ensure availability of well trained manpower throughout the development of software.
Our research reinforces the previous research findings with re-gard to the importance of process maturity in ensuring the SQ with respect to offshoring. Further, it is also shown that process matu-rity significantly associated with functionality, reliability and maintainability attributes of SQ. Indian vendors with high levels of process maturity are successful in the offshoring markets. However, continued success will depend on further fine-tuning of process to achieve quality expectations in the competitive envi-ronment. Similarly, it is found that communication and control was a key organizational factor, found to have a significant positive association with the reliability and usability attributes of the qual-ity in the offshoring context. Better communication with end-users, especially in offshoring, would help to improve the usability of the software. It would also help to capture the requirements properly and there by ensure reliable software for the customers. Practitioners need to continuously improve the processes to accommodate the changing requirements in the case of offshoring. The research also suggests that knowledge transfer and integra-tion significantly associated with the funcintegra-tionality attribute of SQ in offshoring. Efforts to acquire necessary knowledge and inte-grated with internally developed knowledge would lead to devel-opment of software that meets the requirements of the customer. It will also help offshore vendors to dynamically acquire both business and technical knowledge from the customers in or-der to create new business opportunities. While there are many challenges in offshoring owing to the geographical distances, ven-dors need to identify and manage the determinants to achieve spe-cific attributes of quality.
7. Conclusion
Our study has identified the key factors which influence the SQ when the software is developed through offshoring. Considering the fact that there are only very few empirical research initiatives in the past on SQ, linking the offshore development from vendor’s perspective, our research has explored and identified the key fac-tors which need to be addressed for ensuring high quality software in the case of offshoring. Our research shows that requirements uncertainty has significantly related to all attributes of quality. While process maturity and trained personnel have moderate asso-ciation, communication and control, knowledge transfer and
inte-gration and technical infrastructure have relatively low
association on software quality attributes. Our research has been based on a survey carried out in a single vendor’s site. Neverthe-less, further quantitative research may be undertaken to validate the variables based on survey of more organizations from IT Indus-try. Further, it may be interesting to extend and carry out future studies from different stakeholders’ perspective, especially the quality personnel in the vendor organizations.
Appendix A. Summary of questionnaire items A.1. Software quality
Functionality:
The software developed was fulfilling the specifications of the user.
Response time of the software was meeting the user expectations.
The software developed provided accurate outputs for users The software developed with interoperability features to inter-act with other systems.
Reliability:
The software was stable and unlikely to fail easily. The software coped up well with environmental failures. The software was able to recover data and restore optimal func-tioning during failures.
The software exhibited reliable results to the user under differ-ent conditions.
Maintainability:
The software was developed with features to accommodate changes suggested by the users.
The software was able to adapt easily to new specifications or operating environments.
The software required minimum efforts to make system changes. The software was supported with adequate documentation. Usability:
The software was easily understood by the Users and its usabil-ity was assured.
Users appreciated the software as it was understood well by human–computer interface Software was easily learnt by dif-ferent Users to make use of the software The software enabled its ease of operation by the users.
Performance:
The software was easily installed by users.
The software incorporated adequate security features for its use. The software had the ability to detect and trouble-shoot in case any of its component fails Response time of the software was rated to be good, meeting User expectations.
Requirements certainty:
Proper tools (like Rational Rose) were applied to convert the cli-ent needs to requiremcli-ents specifications.
Most of the needs of the client was known and crystallized into requirements at the early stage itself.
Established processes were applied to develop software as per the client requirements Most of the requirements of the client happened in ‘‘UAT’’ stage only.
Most of the requirements of the client happened in ‘‘DESIGN’’ stage.
Most of the requirements of the client happened in ‘‘BUILD’’ stage.
Specific tools and Practices were in place to ensure require-ments traceability.
Prototypes were created to understand the requirements better. Requirements were signed off by relevant stakeholders on time. Technical infrastructure:
Employees were provided access to production data and other resources at work Licenses relating to different technology were provided.
Access to development tools such as CASE was provided. A corporate library with technical and domain specific books and other resources.
Knowledge transfer and integration:
Existing application/system knowledge impacted the project. Technical knowledge transferred impacted the project.
Country specific needs impacted the project.
Business domain knowledge transferred from the clients impacted the project.
Organization practice such as COE was adequate for the project. Many creative ideas emerged through the unique perspectives of members of project team at both offshore and on-site, lead-ing to better knowledge transfer and integration.
Proper coordination structure with leadership helped to inte-grate the knowledge between offshore and on-site resources. Knowledge transfer documentation prepared, reviewed and approved for use.
Process maturity:
Software development/project management processes were defined to achieve product quality.
Detailed metrics were used for the software development. Quantitative feed back enabled the software development pro-cess level of maturity.
Higher levels of process maturity were set than expected by customers.
Processes for creating unique knowledge were set to make it available when required.
Practices of other methodologies like Agile, Scrum were followed.
Trained personnel:
Trained personnel were available to execute the project. The required man power resources for the project were deployed after cross training.
Additional resources were recruited for taking up the project. The man power resources deployed were not changed till the completion of the project.
Communication and control:
Software Tools were used for communication between the teams.
Proper training of the team resources was undertaken for better communication and control.
Specific governance model was implemented for better com-munication and control.
Effective communication and control was achieved among the team members through regular reviews and interactions. Specific changes were made for the customer for better commu-nication and control between the teams.
Usage of Web 2.0 was made for effective communication and collaboration.
References
[1] M. Agarwal, K. Chari, Software effort quality and cycle time: a study of CMM level 5 projects, IEEE Transaction on Software Engineering 33 (2007) 145–156. [2] D. Azar, H. Harmanani, R. Korkmaz, A hybrid heuristic approach to optimize rule-based software quality estimation models, Information and Software Technology 51 (2009) 1365–1376.
[3] A. Selfah, M. Donyaee, Tex B. Kline, Harkirat K. Padda, Usability measurement and metrics: A consolidated model, Software Quality Journal 14 (2006) 159– 178.
[4] A.S. Andreou, M. Tziakouris, A quality framework for developing and evaluating original software components, Information and Software Technology 49 (2007) 122–141.
[5] J. Anderson, J. Narus, A model of distributor firm and manufacturer firm working partnerships, Journal of Marketing 54 (1) (1990) 42–58.
[6] H. Bahrami, S. Evans, Human resource leadership in knowledge based entities: shaping the context of work, Human Resource Management 36 (1997) 23–28. [7] H. Barki, S. Rivard, J. Talbot, Toward an assessment of software risk, Journal of
Management Information Systems 10 (1993) 203–225.
[8] Behshid Behkamal, Mohsen Kahani, Mohammad Kazem Akbari, Customizing ISO 9126 quality model for evaluation of B2B applications, Information and Software Technology 51 (2009) 599–609.
[9] J. Boegh, A new standard for quality requirement, IEEE Software (March/April) (2008) 57–62.
[10] B.W. Boehm, J.R. Brown, J.R. Kaspar, M. Lipow, G. MacCleod, Characteristics of Software Quality, North Holland, Amsterdam, 1978.
[11] C. Bunse, C. Verlage, V. Giese, Improved software quality through improved development process descriptions, Automatica 34 (1998) 23–32.
[12] E. Carmel, R. Agarwal, The maturation of offshore sourcing of information technology work, MIS Quarterly Executive 1 (2) (2002) 65–78.
[13] R. Chinnaiyan, S. Somasundaram, Evaluating the reliability of component-based software systems, International Journal of Quality &Reliability Management 27 (1) (2010) 78–88.
[14] Christof Ebert, Jozef De Man, Requirements Uncertainty: Influencing factors and concrete improvements, ICSE’05., St. Louis, Missouri, USA, May 15–21, 2005. [15] B. Curtis, W.E. Hefley, S. Miller, People Capability Maturity Model, Software
Engineering Institute, Carnegie Mellon University, Pittsburgh, 1995. [16] G.B. Davis, P. EinDor, W.R. King, R. Torkzadeh, IT offshoring: History Prospects
Challenges, Journal of the AIS 7 (11) (2006) 770–795.
[17] Dedrick J, Kraemer KL. China IT Report, Electronic Journal on Information Systems in Developing Countries, vol. 6, no. 2, 2001, pp. 1–10. <http:// www.ejisde.org>
[18] W.H. DeLone, E.R. McLean, The DeLone and McLean model of Information system success, Journal of Management Information System 19 (4) (2003) 9– 30.
[19] K. Desouza, Barriers to effective use of knowledge management systems in software engineering, Communications of the ACM 46 (1) (2003) 99–101. [20] R.C. Dromey, A model of software product quality, IEEE Transactions on
software Engineering (February) (1995) 146–162.
[21] S.K. Ethiraj, P. Kale, M.S. Krishnan, J.V. Singh, Where do capabilities come from and how do they matter? A study in the software services industry, Strategic Management Journal 26 (1) (2005) 25–45.
[22] S. Faraj, L. Sproull, Coordinating Expertise in Software Development Teams, Management Science 46 (12) (2000) 1554–1568.
[23] R.L. Glass, Defining Quality Intuitively, IEEE Software (May/June) (1998) 103– 107.
[24] A. Gopal, T. Mukhapadhyay, M.S. Krishnan, Role of software processes and communication in offshore software development, Communications of the ACM 45 (4) (2002) 193–200.
[25] A. Gopal, B.R. Koka, Determinants of Service Quality in Offshore Software Outsourcing, in: R. Hirschheim, A. Heinzl (Eds.), Information Systems Outsourcing: Enduring Themes, third ed., New Perspectives and Global Challenges, Springer, 2009.
[26] N. Gorla, S.C. Lin, Determinants of software quality: a survey of information systems project managers, Information and Software Technology (2010). [27] N. Gorla, R. Ramakrishnan, Effect of software structure attributes on software
development productivity, The Journal of Systems and Software 36 (2) (1997) 191–199.
[28] V. Grover, M.J. Cheon, J.T.C. Teng, The effect of service quality and partnership on the outsourcing functions, Journal of Management Information Systems 12 (4) (1996) 89–116.
[29] R. Grant, Prospering in dynamically-competitive environments: organizational capability as knowledge integration, Organization Science 7 (4) (1996) 375– 387.
[30] W.M. Han, S.J. Huang, An empirical analysis of risk components and performance on software projects, The Journal of Systems and Software 80 (1) (2007) 42–50.
[31] Bendik Bygstad, Gheorghita Ghinea, Eivind Brevik, Software development methods and usability: perspectives from a survey in the software industry in Norway, Interacting with Computers 20 (2008) 375–385.
[32] D.E. Harter, M.S. Krishnan, S.A. Slaughter, Effects of process maturity on quality, cycle time, and effort in software product development, Management Science 46 (4) (2000) 461–475.
[33] J. Heide, G. John, Do norms matter in marketing relationships?, The Journal of Marketing 56 (2) (1992) 32–34.
[34] A.R. Hevner, Phase containment metrics for software quality improvement, Information and Software Technology 39 (1997) 867–877.
[35] W.S. Humphrey, Managing the Software Process, Addison Wesley, Reading, MA, 1989.
[36] D.S. Huyink, From ISO 9000 to total quality management: how ISO 9000 makes TQM easier, Annual Quality Congress Transactions by ASQC, vol. 45. Milwaukee, 1996, pp. 613–618.
[37] B. Curtis, H. Krasner, N. Iscoe, A field study of the software design process for large systems, Communications of the ACM 31 (1988) 1268–1287. [38] P. Jalote, CMM in Practice, Addison Wesley, Longman, Massachusetts, USA,
2000.
[39] M.E. Jennex, D. Amroso, O. Adelakun, E-commerce infrastructure success factors for small companies in developing economies, Electronic Commerce Research 4 (3/4) (2003).
[40] Ho-Won Jung, Validating the external quality sub characteristics of software products according to ISO/IEC 9126, Computer Standards & Interfaces 29 (2007) 653–661.
[41] Jie-Cherng Chen, Sun-Jen Huang, An empirical analysis of the impact of Software Development problem factors on software maintainability, The Journal of Systems and Software 82 (2009) 981–992.
[42] C.R. Jones, Customer focused performance improvement: developing a strategy for total quality, International Journal of Technology Management 16 (1998) 494–504.
[43] V. Jovanovic, D. Shoemaker, ISO 9000 standard and software quality improvement, Benchmarking for Quality Management & Technology 4 (1997) 148–159.
[44] N. Juristo, A.M. Moreno, M.I. Sanchez-Segura, Analysing the impact of usability on software design, The Journal of Systems and Software 80 (2007) 1506– 1516.
[45] S.H. Kan, V.R. Basili, L.N. Shapiro, Software quality: an overview from the perspective of Total Quality Management, IBM Systems Journal 33 (1994) 4– 19.
[46] R.M. Kanter, Collaborative Advantage; The art of Alliances, Harvard Business Review 72 (4) (1994) 96–108.
[47] R. Kepper, The management of partnering development in IS outsourcing, Journal of Information Technology 10 (1995) 249–258.
[48] S.R. Khayami, A. Towhidi, R. Ziarati, Measurable characteristics of a software system on software architechture level, International Review on Computers and Software (I.RE.CO.S) 3 (3) (2008) 234–239.
[49] M.S. Krishnan, C.H. Kriebel, S. Kekre, T. Mukhopadhyay, An Empirical analysis of productivity and quality in software products, Management Science 46 (6) (2000) 745–759.
[50] R.E. Kraut, L.A. Streeter, Coordination in large scale software development, Communications of the ACM 38 (7) (1995) 69–81.
[51] Jac-Nam Lee, Young-Gul Kim, Effect of partnership quality on IS outsourcing success: conceptual frame work and empirical validation, Journal of Management Information Systems 15 (4) (1999) 29–61.
[52] E.Y. Li, H.G. Chen, W. Cheung, Total Quality Management in software development process, The Journal of Quality Assurance Institute 4 (2000) 5– 41.
[53] J. Luftman, R. Kempaiah, Key issues for IT executives 2007, MIS Quarterly Executive 7 (2008) 99–112.
[54] K. Lyytinen, L. Mathiassen, J. Ropponen, Attention shaping and software risk – a categorical analysis of four classical risk management approaches, Information Systems Research 9 (3) (1998) 33–255.
[55] Marcantonio Catelani, Lorenzo Ciani, Valeria L. Scarano, Alessandro Bacioccola, Software automated testing: A solution to maximize the test plan coverage and to increase software reliability and quality in use, Computer Standards & Interfaces xxx (2010) xxx–xxx, journal homepage: <http://www.elsevier.com/ locate/csi>.
[56] J.A. McCall, P.K. Richards, G.F. Walters, Concepts and definitions of software quality, Factors in Software Quality, NTIS 1 (1977).
[57] P. Mohagheghi, R. Conradi, An empirical study of software change: origin, acceptance rate and functionality vs quality attributes, in: Proceedings of the 2004 International Symposium on empirical Software Engineering (ISESE’04), 2004, pp. 7–16.
[58] R. Monezka, K. Peterson, R. Handfield, G. Ragatz, Success factors in strategic supplier alliances: the buying company perspective, Decision Sciences 29 (3) (1998) 553–577.
[59] S. Nidumolu, The effect of coordination and uncertainty on software project performance: residual performance risk as an intervening variable, Information Systems Research 6 (3) (1995) 191–219.
[60] G. Okhuysen, K. Eisenhardt, Integrating knowledge in groups: how formal interventions enable flexibility, Organization Science 13 (4) (2002) 70–386. [61] D.L. Parnas, Designing Software for Ease of Extension and Contraction, IEEE
Transactions On Software Engineering 5 (2) (1979).
[62] D.L. Parnas, The role of inspection in software quality assurance, IEEE Transactions on Software Engineering 29 (8) (2008) 674–676.
[63] S.C.J. Palvia, V.K. Vemuri, Global E-Commerce: An Examination of Issues Related to Advertising and Intermediation, Global Information Technology and E-Commerce: Issues for the New Millennium, Ivy League Publishing Limited, 2002.
[64] M. Lacity, R. Hirschheim, The information systems outsourcing bandwagon, Sloan Management Review 35 (1) (1993) 73–86.
[65] C. Prahalad, M. Krishnan, The dynamic synchronization of strategy and information technology, Sloan Management Review (Summer) (2002) 24– 33.
[66] R.S. Pressman, Software Engineering: A Practitioner’s Approach, McGraw-Hill, NY, 2005.
[67] T. Ravichandran, A. Rai, Quality management in systems development: an organizational system perspective, MIS Quarterly 24 (3) (2000) 381–415.
[68] C. Rajendran, G. Issac, R.N. Anantharaman, An instrument for the measurement of customer perceptions of quality management in the software industry: an empirical study in India, Software Quality Journal 14 (2006) 291–308. [69] T.M. Rajkumar, R.V.S. Mani, Offshore software development: the view from
Indian suppliers, Information Systems Management 18 (2) (2001) 63–73. [70] T.V. Rao, HRD Audit, Response Books, New Delhi, 1999.
[71] S. Ravichandran, P.M. Shareef, Managing risk in software projects, Indian Management 40 (2001) 56–62.
[72] Ravi Patnayakuni, Cynthia P. Ruppel, A. Rai, Managing the complementarity of knowledge integration and process formalization for systems development performance, Journal of the Association for Information Systems 7 (8) (2006) 545–567.
[73] P. Robillard, The role of knowledge in software development, Communications of the ACM 42 (1) (1999) 87–92.
[74] J.F. Rockart, J.D. Hoffman, Systems delivery: evolving new strategies, Sloan Management Review (Summer) (1992) 21–31.
[75] M.A. Rothenberger, Yi-Ching Kao, L.N. Van Wassenhove, Total quality in software development: An empirical study of quality drivers and benefits in Indian software projects, Information & Management 47 (2010) 372–379. [76] I. Rus, M. Lindvall, Knowledge management in software engineering, IEEE
Software (May/Jun) (2002) 26–38.
[77] J. Sairamesh, R. Mohan, M. Kumar, T. Hassan, C. Bender, A platform for business to business sell-side: private exchanges and marketplaces, IBM Systems Journal 41 (2) (2002) 242–252.
[78] S. Shah, Dwindling labor, Optimize (September) (2004) 66–71.
[79] Stephan Jones, Toward an acceptable definition of service, IEEE Software 22 (3) (2005) 87–93.
[80] G.H. Subramanian, J.J. James, Gary Klein, Software quality and IS project performance improvements from software development process maturity and IS implementation strategies, The Journal of Systems and Software 80 (2007) 616–627.
[81] J. Tian, Quality-evaluation models and measurements, IEEE Software (May/ June) (2004) 84–91.
[82] J.M. Verner, W.M. Evanco, In-house software development: what project management practices lead to success?, IEEE Software (January/February) (2005) 86–93
[83] G. Verona, A resource –based view of product development, Academy of Management Review 24 (1) (1999) 132–142.
[84] A.A. Wali, A.D. Gupta, S.G. Deshmukh, Quality initiatives in an Indian software organization: a case study, Work Study 49 (2000) 285–291.
[85] L. Wallace, M. Keil, A. Rai, Understanding software project risk: a cluster analysis, Information and Management 42 (2004) 115–125.
[86] D. Walz, J. Elam, B. Curtis, Inside a software design team: knowledge sharing and integration, Communications of the ACM 36 (10) (1993) 63–77. [87] M.G. Weinberg, Quality Software Management, vol. 2, Dorset House, New
York, 1996.
[88] B.J. Williams, J.C. Carver, Characterizing software architecture changes: A systematic review, Information and Software Technology 52 (2010) 31–51. [89] J.L. Wynekoop, D.B. Walz, Investigating traits of top performing software
developers, Information Technology & People 13 (2000) 186–195.
[90] M. Xenos, D. Christodoulakis, Measuring perceived software quality, Information and Software Technology 39 (1997) 417–424.
[91] Y.H. Yang, Software quality management and ISO 9000 implementation, Industrial Management & Data Systems 101 (2001) 329–336.
[92] A. Tiwana, A. Bharadwaj, V. Sambamurthy, The antecedents of information systems development capability, in: Firms: A Knowledge Integration Perspective, Twenty-Fourth International Conference on Information Systems, pp. 246-258.
[93] R.K. Yin, Case Study Research: Design and Methods, Sage, Thousand Oaks, CA, 2003.
