an influence model for factors in outsourced software maintenance

JOURNAL OF SOFTWARE MAINTENANCE AND EVOLUTION: RESEARCH AND PRACTICEJ. Softw. Maint. Evol.: Res. Pract. 2006; 18:385–423Published online in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/smr.339

Research

An influence model for factors inoutsourced softwaremaintenance

Pankaj Bhatt1,∗,†, Gautam Shroff1, C. Anantaram1 andArun Kumar Misra2

1Tata Consultancy Services Ltd, New Delhi, India2Department of Computer Science and Engineering, National Institute of Technology, Allahabad, India

SUMMARY

The rapid growth of the Internet in the recent past has encouraged global deployment of work by anincreasing number of organizations around the world, and they are now in a better position to outsourcetheir IT functions to specialist vendors. With the passage of time, we find more and more softwaresystems moving into the maintenance phase. Such software systems have become an increasingly significantexpenditure for businesses. Consequently, these are often potential candidates for outsourcing. Inadequateinformation regarding the size, complexity, reliability, maintainability, etc., of these systems often makesthe task of estimating the maintenance effort a challenge. Other human and organizational factors, typicalto maintenance activities, such as organization climate, customer attitude, engineers’ attitude, the needfor multi-location support teams, etc., make the situation even more complex. In this paper we presentthe results of an empirical study carried out to identify such factors and study their influence on themaintenance effort. We classify these factors in four categories, namely system baseline, maintenance team,customer’s attitude and organizational climate. We also propose a model which can help a practitioner topredict and control the impact on maintenance effort, based on the strengths of these factors. Copyright c©2006 John Wiley & Sons, Ltd.

Received 11 April 2006; Revised 30 September 2006; Accepted 1 October 2006

KEY WORDS: software maintenance; factors; influence model; effort; outsourcing

1. INTRODUCTION

Outsourcing [1] of software engineering functions (such as development, maintenance, qualityassurance, etc.) is mainly catalyzed by two drivers: the need for rationalization of costs associated

∗Correspondence to: Pankaj Bhatt, Tata Consultancy Services Ltd, 249 D/E Udyog Vihar, Gurgaon 122016, Haryana, India.†E-mail: [email protected]

Copyright c© 2006 John Wiley & Sons, Ltd.

386 P. BHATT ET AL.

with these activities, and corporate houses’ increasing tendency to focus on their core competencies.Slaughter et al. [2] argued that environmental turbulence encourages firms to focus on their corebusiness and outsource non-critical work. In the past, distance and lack of communication actedas deterrents to this. However, the declining prices of telecommunications bandwidth and the rapidspread of the Internet has made global deployment of work a reality. Today, more corporate housesare in a position to outsource their IT functions to specialist vendors. Over the next ten years,Russia, China and India are likely to emerge as hubs for outsourced services especially in areassuch as software engineering [3]. In recent years we have also seen a trend of organizations hivingoff their captive IT operations to specialist IT services vendors [4]. Although outsourcing initiallystarted as a cost reduction operation, today corporations are regularly contemplating outsourcing toa third-party specialist to improve operational performance [5]. Today, virtually all companies inevery business sector are dependent on software systems. These systems range from routine softwarefor desktop computers to more sophisticated and customized software for complex and proprietarybusiness systems. These systems require customization, maintenance and updating on a regular basis.Such software systems have become an increasingly significant expenditure for businesses in developedcountries, and companies are actively trying to control these costs. With the passage of time, we alsofind more and more software systems move into the maintenance phase. These systems are oftenpotential candidates for outsourcing. In [6], Aspray et al. have highlighted the current trends forthe division of labor between the industrialized and offshore countries (potentially carrying out theoutsourced work). Their study clearly highlights the fact that a very high percentage of outsourced workpertains to software maintenance. However, more often than not, adequate information regarding thesize, complexity, reliability, maintainability, etc., of these systems is not available to the organizationundertaking the outsourced maintenance activities. Consequently, estimating the required maintenanceeffort becomes a difficult task both for the organization outsourcing the system, as well as forthe software services vendor bidding to undertake the maintenance job. Add to this human andorganizational factors typical to maintenance activities, such as organization climate, customer attitude,engineers’ attitude, the need for multi-location support teams, etc., and the situation becomes muchmore complex.

1.1. Software maintenance and outsourcing

The IEEE [7] defines software maintenance as:

‘The modification of a software product after delivery, to correct faults, to improveperformance or other attributes, or to adapt the product to a modified environment.’

Software maintenance broadly includes error corrections, changes (amendments or enhancements) andimprovements to operational software. Lienz and Swanson [8,9] categorize software maintenance intofour categories: corrective, adaptive, perfective and preventive. While traditional maintenance oftenmeans restoring something to its original shape, software maintenance deals with fixing problems inthe original system and bridging the gaps between the operational system and the specifications (whichmay mean additional effort in the beginning of roll-out). With end-users using the software, there isalways scope for improvements in the operational system or technical improvements from a softwareefficiency perspective. Changes to the operational environment (e.g., software or hardware platform)also make it necessary to make appropriate changes to operational software.

Copyright c© 2006 John Wiley & Sons, Ltd. J. Softw. Maint. Evol.: Res. Pract. 2006; 18:385–423DOI: 10.1002/smr

AN INFLUENCE MODEL FOR FACTORS IN OUTSOURCED SOFTWARE MAINTENANCE 387

Chaudhary et al. [1] define outsourcing as follows:

‘The contracting of various information systems functions such as managing ofdata centers, operations, hardware support, software maintenance, network, and evenapplication development to outside service providers’.

While outsourcing of software maintenance has been growing, the field is also becoming increasinglycompetitive due to new players entering the arena. Earlier, one saw customers engaging IT servicescompanies on a time-and-material basis, where the services were paid for on the basis of the numberof engineers engaged in the maintenance activities. Now one can see a definite shift in this trend, withcustomers asking for fixed-price bids for maintenance of software over a specified time period and itis imperative for the vendors to have a fair assessment of the total effort involved. At times the vendorcompany bidding for the work has no prior experience with the software. It is therefore important toidentify and understand the factors that have an impact on the maintenance of outsourced softwaresystems.

2. MOTIVATION

Software projects pass through different stages of evolution such as requirement analysis,specifications, design, coding and unit testing, integration testing and maintenance, which arecollectively referred to as the software lifecycle.

Zelkowitz [10] noted that software development represents only 25–33% of the total effort expendedduring the complete lifecycle of the software system. This highlights the importance of the maintenancephase in the software lifecycle. Statistically, the argument could be to calculate the maintenanceeffort based on the effort expended in the other phases of the software lifecycle, but in reality thisin not possible due to the lack (or absence) of such data for the development phases [11]. Moreover,software development and maintenance are also different types of activities and have different inherentcharacteristics [12].

Polo et al. [13] have captured the evolution of maintenance costs as perceived by various researches(see Table I). As is evident, there is a significant variation in various researchers’ perception of theeffort attributable to maintenance activities in the software lifecycle. However, there is unanimity inaccepting the fact that maintenance possibly accounts for maximum effort in the lifecycle.

The software industry has, for many years, been depending on models for estimation and this hasbeen a popular subject of debate in academic and industrial circles for a long time now. These modelsare to a certain extent dependent on quantitative measurements that are still immature due to either(a) incorrect implementation or (b) improper usage. Collection of the data required by most of thesemodels is a tedious and time-consuming activity. Therefore, despite significant research activity in thearea of effort estimation, predicting effort for software projects remains an elusive and challenginggoal, and this is especially true in the case of maintenance projects. Ferens [14] argued that no modelis accurate for estimating maintenance effort. Estimation is also dependent on human interpretationand therefore prone to errors due to a host of technical, social and political reasons [11]. Tsoi [15]challenges the rationale of using only technical aspects to improve the reliability of size/cost estimatesand highlights the existence of unpredictable factors in the software development cycle contributing


388 P. BHATT ET AL.

Table I. Evolution of maintenance costs (from [13]).

Reference Date Maintenance (%)

Pressman 1970s 35–40Leinz and Swanson 1976 60Pigoski 1980–1984 55Pressman 1980s 60Schach 1987 67Pigoski 1985–1989 75Frazer 1990 80Pigoski 1990s 90

to schedule/effort overruns. We submit that such factors also play a dominant role in softwaremaintenance projects.

Our research brings out the results of a study of some such factors, their interrelationship and theirinfluence on software maintenance activities and effort. While some of these factors may be relevant inan in-house maintenance context, for our study we have focused on outsourced software maintenanceprojects only.

3. CONTEXT OF RESEARCH

We define some terms that we use in our discussion.

• Customer. By Customer we refer to an organization as a whole that is engaged in a businessin any domain. This organization requires some software system (referred to as a System in ourdiscussion) to be maintained and funds the maintenance activities for the System.

• Business. In our context, Business is a logical view of users, internal as well as external to theCustomer’s organization, which use the System to support their business activities.

• Vendor. We define the Vendor as the organization engaged in the outsourced maintenanceactivities for the System.

• System. We define the System as an accumulation of the software and the documentation thatautomates (partially or completely) a Customer’s business processes to help the Business.The System is maintained by the Vendor. For the purpose of this research, we have excludeditems such as infrastructure, hardware, network, system software, middleware, etc., from thisdefinition. A System is designed to meet certain organizational objectives (for example, businessprocess automation, performance, throughput, technology, etc.) as specified by the Customer.

• Users. We define Users as a set of individuals who use the System to efficiently conduct theirbusiness. Users could be internal or external to a customer’s organization. Users interface withthe Customer’s IT team to raise maintenance requests for the System. Users have their ownunderstanding of the objectives of the System.



Figure 1. Entities and relationships.

• Customer’s IT team. In our context, the Customer’s IT team is a set of individuals within theCustomer’s organization that is responsible for the ownership and operation of the System.This team may also contain business users who are domain experts and liaise with end-users(Users in our context) of the System on behalf of the IT team. The IT team has its understandingof the objectives of the System.

• Maintenance team. We define the Maintenance team as a set of individuals within the Vendororganization, engaged in day-to-day maintenance of the System. This team interfaces with theCustomer’s IT team. The Maintenance team has its understanding of the objectives of the System.

• Operational age. Operational age is defined as the number of days that the System has been inoperation.

• Outsourced age. Outsourced age is defined as the number of days since System was outsourcedfor maintenance to the Maintenance team.

Figure 1 depicts the various entities and their interrelationships.

3.1. Scope of research

We define the assumptions for our research as follows.

1. Our focus is on factors in the maintenance of business information systems. While this studymay apply to other types of systems such as mission-critical systems and research systems, wehave not included such systems in our study at the present point in time.

2. The systems under study necessarily belong to outsourced maintenance activity. We have nottaken into consideration systems maintained in-house.


390 P. BHATT ET AL.

3. Although the age of the system is not binding, our research has taken only those systems intoconsideration which are operational in a live operating environment, and have been writtenin a language for which one can hire or train people. For example, we have not taken intoconsideration systems written in old and outdated platforms. This assumption has been madebecause the context is maintenance and not reengineering [16–18].

4. Domain specialists are available who are well versed with the functional (business) aspects of thesystem. These specialists could be (a) internal to the vendor organization, (b) from the customer’steam or (c) external consultants.

5. The maintenance is being carried out in an environment which provides a stable political climatewith a higher education system leading to internationally recognized graduate and post-graduatedegrees in engineering and computer science. The environment also provides software projectmanagement experience levels in excess of five years. This additionally assumes the presence ofthe necessary infrastructure required to carry out outsourced maintenance work, namely officespace, desktop computers, servers, stable telecommunication links, stable power, approach roads,etc.

6. The system under maintenance is written in assembly, third- or fourth-generation language whichcould be procedural or object oriented. This does not include systems written in declarative(e.g., Prolog), functional (e.g., Haskel), synchronous (e.g., Esterel) and specification (e.g., SDL,UML etc.) languages.

7. The systems code baseline size is in excess of 7.5 KLOC [19] and 80 function points (FPs)[20–22]. That is, we are examining the factors associated with the maintenance of medium tolarge systems.

In [23], we proposed a relationship model for high-level factor categories influencing themaintenance effort for a software project. This model describes the relationships between various factorcategories as shown in Figure 2.

Our research presents the results of a study of the factors grouped in these factor categories and theireffect on the effort involved in the maintenance of existing software systems. Many of these pertainto the human elements and their impact is either undermined or ignored in most studies, resulting in askewed view of the maintenance effort.

The four main factor categories hypothesized in our model are as follows.

System baseline (B). The system baseline forms the basis or the primary work item for any maintenanceproject. Consequently, the quality of the existing code has a high degree of influence on the effortexpended on maintenance. It also has an impact on the efficiency and quality of the maintenanceprojects. A poor architecture and program structure of the code baseline is always a limitation forthe efficiency of the maintenance project. Similarly, poor documentation (not available, not updatedor unreadable), and the absence of guidelines or standards, makes it extremely difficult to study theimpact of changes.

Customer attitude (A). The importance of active involvement of the customer must be emphasizedin any maintenance project. Sometimes customer cooperation is lacking. Often, turnover in customerteams is a common cause. Another factor at times is the perception of the existing programmers ina customers’ team that the lack of maintainability of the system would make them indispensable andadd to their job security. Both of these situations lead to the software system being prone to repeated



Figure 2. Relationship model.

misinterpretation of specifications. This may also lead to errors being reported due to misunderstoodspecifications.

Organizational climate (C). It has been observed that the organizational climate plays a major role insetting the tone for the maintenance environment. Very often, due to time and budget pressures, lessthan adequate study of the system under maintenance is carried out. Consequently, managers tend to setunreasonable targets for carrying out the changes. This leads to high work pressure and demotivationin the maintenance team. The tendency of management to assign development projects as rewards forgood work (that is, escape from maintenance) can also affect the morale of the maintenance team.Organizational commitment in terms of making adequate programming and support tools [24] and(in cases where the same organization has been involved with development and maintenance of asoftware system) person(s) involved in the development team [24] also plays a significant role in theoverall health of the maintenance project.

Maintenance team (T). This factor category relates to the engineering team working on the maintenanceproject. Often, programmers adopt an indifferent or detached approach to maintenance assignments,and therefore focus only on a purely technical approach to maintenance, without relating it tothe business needs of the customer. This attitude is linked to the perception that maintenancejobs lack glamour [24,25], and are perceived as being less creative, by the programmer fraternity.As maintenance invariably involves working with the technologies of yesteryears, programmers oftendo not see a career path through maintenance work, and simply bide their time. This lack of motivationleads to a lackluster performance, and a disgruntled team, with possibly higher turnover [25,26] thanthe organization’s average. There are also issues related to programmer aptitude, which may be due tolack of technical experience, domain knowledge, application knowledge and skills in the programminglanguages used. This gets compounded as, very often, there is a steep learning curve to gain expertise


392 P. BHATT ET AL.

in these areas. In situations where multi-tiered support teams may be distributed geographically andpeople handling different levels of support may not be co-located, the communication gap betweendifferent tiers adds to overall effort. Cross-cultural understanding in the maintenance team is alsoessential to achieve a good working relationship with the customer [4,27].

Factor category Customer attitude (A) forms an important part of our research as this brings inthe dimension of outsourcing into the problem under study and differentiates it from the in-housemaintenance context.

4. RELATED RESEARCH

While significant work has been carried out in the area of effort estimation for development projects,there is limited published work in the area of maintenance and especially directed at factors affectingthe maintenance activities. Leinz [28] highlighted the main issues in software maintenance as (a) theneed for more hardware, software and data communication resources for maintaining the old systems,(b) non-availability and turnover of personnel causing reduced support to the existing applicationsand (c) lack of tools that act as maintenance enablers. Managerial pressures to achieve more inless time and costs also tend to make the existing system increasingly complex and difficult tomaintain over time. Leinz [28] also grouped the problems faced in maintenance into six major areas:user knowledge, programmer effectiveness, product quality, programmer time availability, machinerequirements and system reliability. Banker et al. [29] characterized the software maintenance costs tosoftware complexity into three dimensions: module size, procedure size and branching complexity.

Some other models that have taken factors into consideration for evaluating the maintenance effortare described in the following.

4.1. SMPEEM Model

Ahn et al. [30] have described the Software Maintenance Project Effort Estimation Model (SMPEEM).SMPEEM extends the concept of FPs by introducing a new concept of the value adjustment factors(VAFs). The VAFs of this model are related to the attributes of each characteristic group such as theengineer’s skill, technical characteristics and the maintenance environment. The authors suggest anexponential function model that can estimate how much effort is required for the software maintenanceproject.

Ahn et al. introduced the following VAFs for their model.

Characteristic groups VAFs

Engineer’s skill • Knowledge of application domain (KAD)• Familiarity with programming language (FPL)• Experience with system software (ESS)

Technical characteristics • Structuredness of software modules (SSS)• Independence between software modules (ISM)• Changeability/readability of the program language (CRP)• Reusability of legacy software modules (RLS)

Maintenance environment • Uptodateness of documentation (DOC)• Conformity with software engineering standards (SES)• Testability (TST)



We map these factors to our model as in the following table.

VAF Factor category

KAD TFPL TESS TSSS BISM BCRP BRLS BDOC BSES BTST B

4.1.1. Limitations of SMPEEMSMPEEM is based on internal software projects and excludes all outsourced maintenance work fromthe study. The validation of the model has been carried with a small sample size (32 for part 1 and 44for part 2) and also the size of the maintenance projects is very small (average 9.5 man-weeks), whichdoes not sufficiently address the problem domain. Based on the mapping of these factors, we submitthat the authors’ research considers only two out of the four factor categories we propose in our model.They have not considered two factor categories, namely Organizational climate (C) and Customerattitude (A). The primary reason appears to be the limiting of their study to in-house projects only.

4.2. CMU/SEI-93-TR-8During 1992, Dart et al. [24] carried out a study for the Software Engineering Institute (SEI), withina government agency, which investigated the application of computer-aided software engineering(CASE) technologies to software development. As part of this study, one task was to examine thedevelopment processes and the software tools used within maintenance (lifecycle support) projects.The examination was carried out through interviews with appropriate project managers and technicalpersonnel associated with eight projects within this agency.

Dart et al. [24] presented their findings in 15 categories. We map these to the following factorcategories in our model.

Dart et al. category Factor category

Reverse engineering and re-engineering tools CTesting BConfiguration management issues CDocumentation BCASE tools CIntegration BTooling for maintenance and new software development CSharing knowledge of tools CTraining of technical personnel CMaintenance teams TContractor management TCorporate culture CCorporate communications CQuality assurance and standards CHardware C


394 P. BHATT ET AL.

4.2.1. Limitations of CMU/SEI-93-TR-8

This study is based on in-house maintenance activities within a government organization and thereforeit does not cover outsourced maintenance work and the factors related to factor category Customerattitude (A). While the report addresses maintenance activities in general, the main focus is CASEtools. The study makes recommendations only; it does not propose any model for effort estimation.

4.3. Predictive effort model

In [31], Basili et al. presented a predictive effort model for software maintenance releases in the FlightDynamics Division (FDD) of NASA Goddard Space Flight Center (GSFC). Their study consolidatesthe observations in 29 releases of 11 different systems. Based on a linear regression model, Basiliet al. [31] propose an equation as follows:

Effort in hours = (0.36 ∗ SLOC) + 1040

where SLOC is the number of lines of code added, changed or deleted as the result of the maintenanceactivity.

4.3.1. Limitations of Basili et al.’s model

The data collected are from a single division of a large organization which implies a limited viewof the systems under maintenance. The business domain of the systems under study is also limited,primarily in the area of control of earth-orbiting scientific satellites and also space shuttle flights.The system sizes considered were moderate, the largest system being 250 KLOC. Also the languagesused for the systems under maintenance were primarily FORTRAN (85%), Ada (10%) and others (5%)which do not completely address the problem domain. The platforms for system implementation wereconcentrated largely around IBM mainframes (90%) and PC/Unix (10%). The proposed model takesonly enhancements into consideration and the error correction activities have not been taken intoaccount. It takes only one factor (enhancement size) into consideration.

5. OUR APPROACH AND DESIGN OF EXPERIMENT

We have used an empirical approach based on observation and measurement to conduct our research.The research employed a longitudinal study approach and we had two waves of measurement.We have used a combination of descriptive and analytic research. While the descriptive approach isused to present the data collected using the questionnaire, the analytic approach is used to identifythe relationships between the various factors. For our study, we used a structured questionnairemostly posing definite and preordained questions to collect inputs pertaining to various factors.The questionnaire used for our research is shown in Appendix A.

Our research included a study of 127 projects spanning 28 customer accounts. Overall 392 responseswere collected from 12 software delivery locations. The projects were selected on the basis of the stagethey were in, such as: (a) transition stage, where a vendor seed team develops a quick understandingof the product under maintenance to facilitate effective knowledge transition; (b) knowledge transfer



stage, where the initial seed team imparts knowledge gained at the customer location to the rest of themaintenance team; and (c) steady state, where the vendor is engaged in maintenance activities on anongoing basis with minimal involvement of the customer.

We also looked at projects involved in different types of maintenance activities such as:(a) production support, involving monitoring and resolving program crashes and solving problemtickets raised by the users; (b) small enhancements, typically under 50 person-days of effort and usuallycatering to adaptive changes in the system; (c) large enhancements, more than 50 person-days of effortaddressing extensions to requirements; and (d) preventive changes, such as performance optimization.

The projects were selected from various customer accounts spanning different business domains,geographies and technologies. The selection criteria also included the level of evolution in themaintenance cycle such as the age of the system and vendor’s experience with the system undermaintenance.

The target group for the questionnaire consisted of people involved in the maintenance activities.These people had different levels of experience and also different roles such as team members, projectleads and relationship managers. A fair level of anonymity was maintained in collecting the responsesto avoid any skew due to fear of reprisal among the respondents. The questionnaire was fairly detailed,to ensure collection of relevant details.

The questionnaire collected information pertaining to the following areas.

Demographics. This section collected details about the person who was responding to the survey.The questions included details such as gender, age, experience in IT industry, experience withmaintenance projects, etc.

Objective information. This section solicited information about the project that was unarguably known.The objective parameters such as (a) size of the system (in KLOC or FPs), (b) maturity of the system(years in operation), (c) number of end-users of the system, (d) experience of project team (in years)and (e) technology stack for the system (operating system, language), were collected using this sectionof the questionnaire.

Subjective information. This section consisted of questions related to various factors. These factorswere grouped into four factor categories defined earlier in this paper namely System baseline (B),Customer attitude (A), Maintenance team (T) and Organizational climate (C).

The subjective factors in the questionnaire were rated on a scale of 1 to 5 (Likert scale).Guidelines were given for answering any questions that showed ambiguity in the testing stages ofthe questionnaire. The following tables show the grouping of these subjective factors under the fourfactor categories described earlier. Table II lists the factors related to the System baseline (B), Table IIIlists the factors related to Customer attitude (A), Table IV lists the factors related to the Organizationalclimate in the maintenance team (C) and Table V lists the factors related to the Maintenance team (T).

6. DATA ANALYSIS

Figure 3 depicts complete details in terms of the number of responses, projects and accounts. C1, C2,C3 and C4 are the four cities where the data collection was carried out. Some accounts were present inmore than one city.


396 P. BHATT ET AL.

Table II. B-factors (11 factors).

Factor code Definition

BCX Complexity of code.BDD Domain complexity of the system. Li and Delugach [32] define Application Domain

Complexity as ‘The complexity in understanding the behavior of the program’.BDN Quality of documentation (at present).BDS Availability of information on defect statistics at the start of the project.BDX Deployment complexity of the system. This factor is related to the number of disparate sites

that the system is deployed in.BFQ Frequency of failure in the system at the initiation of the project. This is the average rate of

failures in the system during its operational life.BIF Interfaces with other systems. Interfacing with other systems, manual as well as automated,

adds to the complexity of the system under maintenance.BLX Locale complexity of the system. Support for additional locales adds to the complexity of the

system under maintenance.BNU Average number of end-users of the system.BSL Average SLA compliance in the first month of maintenance.BSS Stability of the system at the initiation of the project.

Table III. A-factors (10 factors).


AAL Alignment of customer IT and business teams. The alignment between the business usersand customer’s IT teams plays a significant role in determining the software maintenanceeffort. We define alignment as the level of congruence in understanding of the objectives ofthe system by these two teams.

ACI Closeness of interaction between end-users and IT team of the customer.AEP Experience level of the customer is IT team. We define the experience level of a team member

as the familiarity level of the person with the objectives and number of years of familiarity withthose objectives. For varying familiarity levels for a person with respect to an objective, weconsider the average level of familiarity with respect to an objective. The collective experienceof the team is defined as the sum of individual experience levels of the team members.

AFA Customer team’s ability to minimize false alarms. A false alarm is an alarm which does notpertain to a failure in the system meeting any of its objectives.

AFI Familiarity of the customer’s IT team with the system. This is the ability of the customer’s ITteam to understand/implement an objective.

AFU Familiarity of end-users with the system. This is the ability of end-users to understand anobjective.

AQT Quality of training given to the end-users. The training given to end-users is meant to improvetheir ability to understand the objectives of the system.

ARP Responsiveness to queries raised by the maintenance team. Relates to the time taken to respondto a question related to objectives.

ASB Customer team stability. The stability of customer team plays an important role in theirunderstanding of the objectives of the system.

ATS Tolerance to slippage (up to 10%).



Table IV. C-factors (10 factors).


CCF Ease of availability of tele/video-conferencing facilities.CFB Fairness in bonus distribution. This is a factor based on the perception of the maintenance

team.CFR Fairness in review. This is a factor based on the perception of the maintenance team.CLS Leadership of supervisor. This is a factor based on the perception of the maintenance team.CPT Project-specific training opportunities. This is training provided to the maintenance team to

help them perform work related to the present maintenance project.CPW Pressure at the work place. This is a factor based on the perception of the maintenance team.CRS Timely availability of resources (PC, desks). The maintenance team would need resources

such as desktops, servers, etc., to carry out their project effectively. Often there is a delay inmeeting the request for a resource after it is raised.

CSP Space availability. This pertains to the availability of sitting space, conference rooms, serverspace or any other project specific space requirement for the maintenance team.

CTG Difficulty of targets set for the maintenance team.CUS Level of understaffing in the project.The maintenance project would need people to carry out

the maintenance activities. At times, the project may not be able to get all of the people it hasrequested, leading to understaffing in the team.

Table V. T-factors (9 factors).


TCU Ease of communication with the customer (cultural affinity).TDV Involvement of the development team in maintenance. The development team’s involvement

helps the maintenance team have a smoother knowledge transition.TEX Availability of experts to the maintenance team. Expertise could be in any area related to the

objectives of the system. Experts could be from the vendor’s organization, customer’s IT teamor external consultants.

TKM Strength of knowledge management. Whether the vendor maintenance team has access torequired infrastructure for knowledge management.

TKS Level of knowledge (pertaining to domain, technology, platform) at the start of the project.TKT Handling of knowledge transfer (transition team to maintenance team).TRO Desire to move to non-maintenance projects. The maintenance team may have people who

want to move to non-maintenance work due to a perception that maintenance work is non-value adding to their career profile.

TSB Stability of the maintenance team.TTX Handling of transition phase.


398 P. BHATT ET AL.

Phase I

C2

C3

9 Accounts

18 Projects

90 Responses

14 Accounts

62 Projects

220 Responses

3 Accounts

7 Projects

21 Responses

C1

+

Ph

ase

II

6 Accounts

40 Projects

61 Responses

C4 =

28 Accounts

127 Projects

392 Responses

Figure 3. Data collection.

Table VI. Significance levelsof correlations.

Number ofcorrelations p-value

281 ≤0.01480 ≤0.05

2522 >0.05

The data were summarized and subsequently the rankings given by the respondents to various factorswere aggregated. An analysis was performed to find the relationship between various data points.This was carried out by studying the correlations between various data points.

Overall, more than 3000 correlations were present in our analysis. The spread of these correlations issummarized in Table VI. For our analysis, we have only considered correlations which have a p-valueless than or equal to 0.01 as significant.

6.1. Profile of the participants

Figure 4 shows the age distribution of the participants. Figure 5 depicts the experience of participants intheir present project. Figure 6 shows the role-wise IT experience (in years) of the participants. Figures 7and 8 show the role profiles and qualification spread for the participants. Figures 9 and 10 show thespecialization and experience in maintenance (in number of projects) for the participants.

6.2. Customer profiles

Figures 11 and 12 show the geographical spread and the business domain spread of the customers.

6.3. Project profiles

Figures 13 and 14 depict the technology mix and platform-wise breakup (as a percentage) for variousprojects.



28.61

57.82

11.21

1.47 0.88

0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

20-25 25-30 30-35 35-40 40+

Age (years)

Perc

en

tag

e

Figure 4. Participants’ age profile.

36.95

43.40

17.89

0.88 0.88

0.00

10.00

20.00

30.00

40.00

50.00

0-2 2-5 5-10 10-15 15+

Experience (years)

Perc

en

tag

e

Figure 5. Participants’ years on current project.

7. INTERPRETATION OF RESULTS

We analyzed the hypothesis presented in [23] based on the data gathered during this research. As isevident, there are eight relationships presented in the interaction model. Our research was able tovalidate six of these with the help of the data gathered in our research. We also discovered someadditional relationships, which seem to have an impact on software maintenance effort. The analysisalso indicates that the relative strengths of these relationships vary, where the strength of therelationship is directly proportional to number of factors correlated in two factor categories. We definea relationship as very strong if there are ten or more correlations, strong if there are five to ninecorrelations, moderate if there are two to four correlations and light if there is only one correlation.

Table VII summarizes the validation results of the model. In addition to the relationships proposedin [23], we also found that more relationships emerge between various factor categories. Table VIIIlists these additional relationships.


400 P. BHATT ET AL.

53.17

68.42

56.25

4.693.1310.53

75.00

35.9440.00

25.00

6.83

21.05

0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

PL/P

M/G

L

Team

Mem

ber

Module

Lead/T

ech L

ead

Specia

list/

Oth

ers

Role

Pe

rce

nta

ge

0-2 years

2-5 years

5-10 years

10-15

years

Figure 6. Participants’ total role-wise IT experience.

18.21

62.96

16.36

1.23 0.31 0.93

0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

Pro

ject

Leader

Team

Mem

ber

Module

Lead

Tech

Lead

Specia

list

Oth

er

Role

Perc

en

tag

e

Figure 7. Participants’ role profile.

7.1. Customer attitude and Maintenance team capability

We find very strong correlation between the factor categories relating to customer attitude and thecapability of the vendor maintenance team. For outsourcing organizations where the IT teams arestrongly aligned with the end-users (in understanding the objectives of the system), we observe theavailability of a higher degree of knowledge to the maintenance team at the start of the project whichalso helps in better knowledge transfer and knowledge management. Such strongly aligned customerteams also facilitate a stable vendor maintenance team. For example, we see a clear positive correlationbetween factors such as the level of experience of the customer IT team and the knowledge availablefor the maintenance team. Similarly, factors such as an experienced customer IT team and its degree



0.60

16.9620.24

1.79

60.12

0.30

0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

PhD

MT

ech/M

E

MC

A/M

Sc

MB

A/C

A

BT

ech/B

E

Oth

ers

Perc

en

tag

e

Figure 8. Participants’ qualification spread.

42.12

20.30

36.06

1.52

0.005.00

10.0015.0020.00

25.0030.0035.0040.0045.00

Computer

Science

Electronics/

E&C

Other

Engineering

Others

Specialization

Pe

rce

nta

ge

Figure 9. Participants’ specialization spread.

55.95

33.93

7.442.68

0.00

10.00

20.00

30.00

40.00

50.00

60.00

1 2-3 3-5 5+

Projects Worked On

Pe

rce

nta

ge

Figure 10. Participants’ experience in maintenance.


402 P. BHATT ET AL.

50.00

13.64 13.64 15.91

6.82

0.00

10.00

20.00

30.00

40.00

50.00

60.00

USA Europe

(excluding

UK)

UK APAC India

Geography

Perc

en

tag

e

Figure 11. Customers’ regional spread.

28.57

3.57

10.71

3.57

17.86

7.14

21.43

7.14

0.00

5.00

10.00

15.00

20.00

25.00

30.00

Bankin

g/F

inance

Educatio

n

Insura

nce

Life

Scie

nces

Manufa

ctu

ring

Reta

il

Tele

com

munic

atio

n

Tra

nsport

atio

n

Domain

Perc

en

tag

e

Figure 12. Customers’ business domain spread.

42

36

8

14

0

5

10

15

20

25

30

35

40

45

Mainframe Unix Windows Others

Platform

Perc

en

tag

e

Figure 13. Projects’ platform.



30

18

6 7 6

34

0

5

10

15

20

25

30

35

40

Cobol Java C C++ VB Others

Language

Perc

en

tag

e

Figure 14. Projects’ implementation language.

Table VII. Validation results for the original model.

Relationship Validated Strength

A → C Yes ModerateA → T Yes Very strongA → B Yes LightT → A No N/AT → B No N/AT → E Yes ModerateC → T Yes Very strongB → E Yes Moderate

Table VIII. Additional relationships observed.

Relationship Validated Strength

B → C Yes StrongA → E Yes StrongC → E Yes StrongB → A Yes ModerateC → A Yes ModerateT → C Yes ModerateB → T Yes Light


404 P. BHATT ET AL.

of interaction with the end-users of the system have a positive correlation with the smoothness ofknowledge transfer and transition of the system.

7.2. Software baseline and Organizational climate

We observe a strong correlation between the baseline factors and organizational climate factors.Our analysis shows a positive correlation between the B-factors such as complexity of code andnumber of high-severity errors in the system with a C-Factor such as pressure in the work place for themaintenance team. We observe that the complexity of code and domain, stringent SLAs and number ofhigh-severity errors also have direct correlations with the difficulty of targets set for the maintenanceteam.

7.3. Customer attitude and Maintenance effort

This is a strong relationship and indicates that greater experience of customer IT team has a correlationwith the maintenance effort. It also shows that customer end-users and IT teams with higher familiaritywith the system lead to less overtime work for the maintenance teams. However, customer teams withlower tolerance to slippage contribute to larger maintenance teams (thereby higher effort).

7.4. Software baseline and Maintenance effort

These factor categories also have a moderate correlation and baseline factors such as higher domainand deployment complexity, higher number of end-users and higher frequency of the use of the systemhave a direct correlation with time spent at work by the maintenance team (and, thereby, higher effort).

7.5. Organizational climate and Maintenance team

We find a very strong correlation between these two factor categories. Good leadership on the partof the maintenance team management leads to a motivated maintenance team with higher levelof expertise, higher level of stability, lower desire to move out of the current project or to moveout of the maintenance projects in general. We also find that the availability of facilities such asaudio/video conferencing help the maintenance team to get more participation from development teams(where applicable) and facilitates better knowledge transfer. Further investment in training (for themaintenance team), which is once again an indicator of higher organizational commitment correlatedwith a better and more stable maintenance team.

7.6. Customer attitude and Organizational climate

We find correlations between a responsive customer team and positive organizational climate. In ouranalysis, a maintenance team working with responsive customer teams has better opportunities fortraining on various tools, technologies, processes pertaining to the project as well as other generictraining.



7.7. Customer attitude and System baseline

This relationship comes out lighter in the analysis. However, there is a direct correlation betweenexperienced (customer) IT team and a stable system. We also observe a positive correlation between anexperienced (customer) IT team and good supporting documentation for the system under maintenance.

7.8. Maintenance team and Maintenance effort

This relationship shows correlations between factors such as domain knowledge of the vendormaintenance team (at the beginning of the project) with less time spent in the routine maintenanceactivities (and, thereby, less overall effort).

7.9. Organizational climate and Maintenance effort

The correlations here indicate that higher pressure in the workplace, higher levels of understaffing andtougher targets for the maintenance team lead to increased overall effort in maintenance.

7.10. System baseline and Customer attitude

The correlations for these two factor categories indicate that a complex code baseline as well as asystem requiring complex deployment scenario are often supported by an experienced IT team fromthe customer. It also indicates that the support hours required of the maintenance team are directlycorrelated to the number of users using the system.

7.11. Organizational climate and Customer attitude

Correlations for these categories indicates that maintenance teams with stronger leadership help inbetter training of end-users. This also helps the customer teams to develop better appreciation ofthe severity levels for the errors in systems. A related correlation indicates that understaffing in themaintenance team adversely affects the end-user training.

7.12. Maintenance team and Organizational climate

Correlations in these categories relate to the involvement of developers (if applicable) of the systemin the maintenance team. These indicate that if there is greater involvement of developers in themaintenance work, the maintenance team members have better opportunities to train themselves inproject-related and other areas.

7.13. System baseline and Maintenance team

The correlations between these factor categories indicate that systems with higher quality of associateddocumentation have a greater positive impact on the morale of the maintenance team.


406 P. BHATT ET AL.

Software

Maintenance

Effort (E)

System Baseline

Characteristics

(B)

Maintenance

Team Capability

(T)

Customer

Attitude

(A)

Organizational

Climate

(C)

Figure 15. Updated relationship model.

7.14. Maintenance team and Customer attitude

We did not observe any direct relationship between these two factor categories.

7.15. Maintenance team and System baseline

We did not observe any direct relationship between these two factor categories.

Figure 15 represents a model for relationships between these factor categories taking all relationshipsinto consideration.

7.16. Influence map

Figure 16 depicts the influence map for all of the factors studied during our research. This map depictsthe influence of a factor on effort in a tiered manner. We have taken the factors with direct influenceon effort in tier one and have evolved the map from there analyzing the other factors which influencethe tier one factors. Therefore, a factor finds place in a tier (for example, n + 1) in the first instance ofit having an influence on another factor in a lower tier (for example, n). The factors in this map appearonly once. Hence, if a factor has already appeared in tier n, it does not appear in tiers above n eventhough it may be influencing factors in those tiers.

7.17. Influence model

Based on the influence map depicted in Figure 16, we carried out multiple linear regressions for factorsat each tier which have been observed to have an influence on other factors. This analysis comes upwith the equations for factors at various tiers as shown in Table IX.



AEP AFU AQT ATS BDD BDX CPW CTG CUS TKS TTX

AFI ASB AAL CLS AFA BSV BCX CFR BIF BDS BSL CCF CRS TDV TEX TCU TKM CPT TKT

E

CFB BFQ BLXBSS ARP TSBBDN CSP

ACI TRO

Tier 1

Tier 2

Tier 3

Tier 4

Figure 16. Factor influence map.

We have built a model using these equations which helps to predict the possible impact on effort(in percentage) if the strengths for some or all of these influencing factors are provided. For thosefactors which are not specified, the model uses the median values derived during our study. We chosemedian over mean as an indicator of central tendency as our data are a qualitative description of thefactors [33] and the distribution has a limited rage (1–5). The median values for various factors are asspecified in Table X.

The model calculates the relative impact on effort by using the equations derived in our study.The algorithm used for calculating the impact is as follows.

1. Initialize the factors with their median values as given in Table X.2. Input factor values from the user.3. For all of the factors where the user has specified the value, replace the median value by the

value specified by the user.4. Calculate the factor values using the equations specified in Table IX.5. Calculate E using the equation in Table XI.


408 P. BHATT ET AL.

Table IX. Regression equations for various factors.

ARP = 2.417854 + 0.331422 × ACITSB = 3.98093 − 0.1069663 × TROCLS = 2.84805 + 0.25653 × CFBCRS = 0.7662166 + 0.3530151 × CFB + 0.4716356 × CSPBSV = 1.255281 + 0.6346453 × BFQBDS = 1.1837668 + 0.3517692 × BDN + 0.1901365 × BSSBSL = 2.402857 + 0.4392308 × BLXCCF = 2.532892 + 0.2625779 × ARPTKM = 2.404482 + 0.2736129 × TSBAFU = 2.0419831 + 0.3419955 × AFI + 0.0886839 × ASBAQT = 0.4847521 + 0.4248388 × AFI + 0.1187341 × ASB + 0.1883169 × AAL + 0.1138943 × CLSTKS = 0.9761657 − 0.0451741 × AAL + 0.1229417 × CCF + 0.0608361 × CRS + 0.1796968 × TDV +0.275311 × TEXATS = 3.243271 + 0.189303 × AFACPW = 2.422032 + 0.1268766 × BSV + 0.2242494 × BCX − 0.1367781 × CFRCTG = 1.1282625 + 0.0748359 × BSV + 0.3007583 × BCX + 0.0488538 × BIF + 0.095496 × BDS +0.0768772 × BSLTTX = 0.6033688 + 0.0786978 × TDV + 0.0150864 × TCU + 0.2596054 × TKM + 0.020211 × CPT +0.441985 × TKTE = 1.7410987 − 0.0486134 × AEP − 0.0028806 × AFU − 0.1316346 × AQT + 0.006913 × ATS +0.1166804 × BDD + 0.1324859 × BDX + 0.263351 × CPW + 0.1053646 × CTG + 0.018927 × CUS −0.157362 × TKS + 0.0477569 × TTX

Table X. Median values for various factors.

Factor Median Factor Median Factor Median Factor Median

AAL 3 BCX 3 BSV 3 CUS 3ACI 4 BDD 4 CCF 4 TCU 4AEP 4 BDN 3 CFB 3 TDV 3AFA 3 BDS 3 CFR 3 TEX 3AFI 4 BDX 3 CLS 4 TKM 3AFU 4 BFQ 3 CPT 3 TKS 3AQT 4 BIF 3 CPW 3 TKT 3ARP 4 BLX 3 CRS 4 TRO 4ASB 3 BSL 4 CSP 4 TSB 4ATS 4 BSS 3 CTG 3 TTX 3



Table XI. Impact on effort.

E Possible impact on effort

1 −12.5%–0%2 0%–12.5%3 12.5%–25%4 25%–37.5%5 More than 37.5%

0

20

40

60

80

100

120

140

-60 -40 -20 0 20 40

Variance (%)

Insta

nces

Figure 17. Model validation.

The calculated value of E provides the expected effort impact as specified in Table XI. We validatedour model with experimental data set and noted the variance in the calculated value of E with thatspecified by the respondents to the questionnaire. The results of this validation are as shown inFigure 17. The model generates results, 88% of which are within ±20% of the actual value. About42% of the results are same as the actual result, where no variance was observed.

Table XII provides the tier-wise distribution for various factors. We observe that out of the tier 1factors, some factors play a significant role on the impact on effort. We summarize these factors inTable XIII. We submit that by having an understanding of these factors, a project manager can make abetter assessment of impact on the effort on maintenance activities for any system.

Table XIV provides the factor category-wise break up of factors across various tiers. This tablehighlights the relative impact of the factor categories on maintenance effort. These results indicate thatthere is a fair distribution of factors belonging to each factor category in each tier of our influencemodel. This indicates the influence of these factor categories on maintenance effort.


410 P. BHATT ET AL.

Table XII. Tier-wise distribution of factors.

Factor Tier Factor Tier

AEP 1 CFR 2AFU 1 CLS 2AQT 1 CPT 2ATS 1 CRS 2BDD 1 TCU 2BDX 1 TDV 2CPW 1 TEX 2CTG 1 TKM 2CUS 1 TKT 2TKS 1 ARP 3TTX 1 BDN 3AAL 2 BDS 3AFA 2 BFQ 3AFI 2 BLX 3ASB 2 BSS 3BCX 2 CFB 3BIF 2 CSP 3BSL 2 TSB 3BSV 2 ACI 4CCF 2 TRO 4

8. DISCUSSION AND FUTURE WORK

Statistically speaking, correlations do not always imply causation and it would be wrong to deducecausation solely from statistical correlation. However, we believe that strong correlations can havecausal explanations. To reach this inference, we need to (a) get rid of nonsensical correlations and(b) establish the direction of the correlations. To have a consistency in responses, our experimentwas carried out in groups which were strongly similar to each other in terms of their understandingof variables (the participants in the survey were professionals involved in outsourced softwaremaintenance). The correlation selected for analysis had a confidence level of 99% and above. The setof correlations were further reviewed by a group of experienced professionals in the field of softwaremaintenance in outsourced environments to establish the presence of a reasonable explanation of thecause and effect and its direction. Only those correlations that were found to pass these tests were usedin our ultimate analysis.

Our study has only focused on business systems of medium to large size and hence the results mayhave a skew in this direction. We also have not taken in-house maintenance projects into consideration.Our research has taken inputs from projects belonging to different business domains to arrive at themodel. We believe this can be extended by focused studies which are domain specific and thus evolvemodels which possibly are closer to the observations in that specific domain.



Table XIII. High-impact tier 1 factors.

Factorstrength Impact on

Factor Remarks direction effort

Quality of training given tothe end users (AQT)

The end-users are the beneficiaries, so theircomfort with the system to a great degreefacilitates its optimal use. Better training providedto these end-users can help them to understandthe system functionality and raise less concernsnot related to system functionality or performance.This has a decremental effect on the effort.

↑ −−

Domain complexity of thesystem (BDD)

As discussed earlier, the domain difficulty relatesto complexities involved in understanding thebehavior of the program. For business domainswith higher levels of complexity (which may meanmore business rules) one may see an incrementaleffect on the maintenance effort.

↑ ++

Deployment complexity ofthe system (BDX)

Deployment complexity is related to the numberof sites that the system is installed in. Highernumbers of installations are likely to increase themaintenance effort.

↑ ++

Pressure in the work place(CPW)

Unrealistic pressure on the maintenance team mayhave an incremental effect on the maintenanceeffort.

↑ ++

Level of knowledge at thestart of the project (TKS)

Higher levels of knowledge of the maintenanceteam pertaining to domain, technology andplatform related to the system may have adecremental effect on the effort.

↑ −−

9. CONCLUSIONS

We have defined four factor categories that have an impact on maintenance effort. We have alsodefined various factors belonging to these categories and analyzed the influence of these factors on theeffort in software maintenance. While our research has primarily focused on outsourced maintenancework, some of these factors will be applicable for in-house maintenance jobs as well. Our researchalso brings out the factors which have a direct impact on the maintenance effort and which canbe used as leverage points to contain the overall effort in software maintenance activities. We havebuilt an influence model which can help project managers to assess the possible impact of variousfactors in a maintenance project. We submit that this model can provide a useful tool in the handsof project managers to assess the impact of various factors on effort in the context of a maintenanceproject.


412 P. BHATT ET AL.

Table XIV. Category-wise distributionof factors across tiers.

Factor Tier Factor Tier

AEP 1 BSS 3AFU 1 CPW 1AQT 1 CTG 1ATS 1 CUS 1AAL 2 CCF 2AFA 2 CFR 2AFI 2 CLS 2ASB 2 CPT 2ARP 3 CRS 2ACI 4 CFB 3BDD 1 CSP 3BDX 1 TKS 1BCX 2 TTX 1BIF 2 TCU 2BSL 2 TDV 2BSV 2 TEX 2BDN 3 TKM 2BDS 3 TKT 2BFQ 3 TSB 3BLX 3 TRO 4

APPENDIX A. SURVEY QUESTIONNAIRE

Demographics

1. Gendera. Male b. Female

2. Agea. 20–25 years b. 25–30 yearsc. 30–35 years d. 35–40 yearse. over 40 years

3. Total Experience in IT Industrya. 0–1 years b. 1–5 yearsc. 5–10 years d. 10–15 yearse. over 15 years

4. Experience with Present Companya. 0–1 years b. 1–5 yearsc. 5–10 years d. 10–15 yearse. over 15 years



5. Experience in Current Projecta. 0–1 years b. 1–2 yearsc. 2–3 years d. 3–5 yearse. over 5 years

6. Role in Current Projecta. Project Lead b. Team Memberc. Module Lead d. Tech Leade. Specialist f. Other

7. Highest Educational Qualificationa. PhD b. MTech/MEc. MCA/MSc d. MBA/CAe. BTech/BE f. Other

8. Specializationa. Computer Science b. Electronics/E&Cc. Other Engineering d. Others

9. Number of Maintenance Projects Worked ona. 1 b. 2–3c. 3–5 d. More than 5

Application Information

10. Application Name

11. Computer Language(s) used in Application

12. Domain of Application

13. Tool(s) Used

14. Platform(s)

15. Experience of your organization with the application months

16. Time since application went live years

17. Size of code maintained by your team FP/KLOC

18. Size of code maintained by one person in the team FP/KLOC

19. Location of the client’s IT team (country)

20. Fixes to be done in a week by one team member

21. Does the team have any internal target (driven by Project Lead or yourcompany) towards which it is working? Please explain.


414 P. BHATT ET AL.

System Baseline—where a scale is given, rate the item on a scale of 1–5 (5 being the highest)

Language of the Application

22. Time taken to learn (Language #1) for a fresher days

23. Difficulty of maintaining an application in it 1 2 3 4 5Guideline—Difficulty of maintaining any application written in the language

24. Time taken to learn (Language #2) for a fresher days

25. Difficulty of maintaining an application in it 1 2 3 4 5Guideline—Difficulty of maintaining any application written in the language

Domain of the Application

26. Time taken to learn domain by a fresher days

27. Difficulty level of the domain 1 2 3 4 5Guideline—Difficulty in understanding the domain

Platform and Tools used in the Application

28. Time taken to learn (platform tool #1) by a fresher days

29. Difficulty of maintaining an application in it 1 2 3 4 5Guideline—Difficulty of maintaining any application on that platform

30. Time taken to learn (platform tool #2) by a fresher days

31. Difficulty of maintaining an application in it 1 2 3 4 51 2 3 4 5

Guideline—Difficulty of maintaining any application on that platform

‘5’ represents high—Maximizes Effort in Maintenance

32. What is/are the main source(s) of complexity in your application? (Tick ALL that apply)� Complexity deriving from language of application (GOTO statements etc.)� Complexity deriving from the domain (protocols, regulations etc.)� Algorithmic complexity of application� Sheer size of code� Others

33. Time taken to learn the application by a fresher days

34. Complexity of application code 1 2 3 4 5



35. Difficulty of complying with the client SLA (Service Level Agreement) or client specifieddeadlines in:a. 1st month of the project 1 2 3 4 5a. 2nd month of the project 1 2 3 4 5a. 3rd month of the project 1 2 3 4 5

36. Severity of errors in application, at start of project 1 2 3 4 5

37. Frequency of errors in application, at the start of project 1 2 3 4 5

38. Complexity in locales of deployment 1 2 3 4 5Guideline—Rate the difficulty in languages (Chinese, Russian etc.) to be supported,currency–date formats etc

39. Complexity of system deployment 1 2 3 4 5Guideline—Complexity of end-user requirements, operational difficulties, sites to besupported, scalability issues, performance expectations etc.

40. Interfaces with other applications 1 2 3 4 5Guideline—How severely will a change in the application data/code affect otherapplications of the client?

41. Business Criticality of application 1 2 3 4 5Guideline—What, in your view, is the importance of the application to client?

‘5’ represents high—Minimizes Effort in Maintenance

42. Usefulness of the #1 Tool (specify) 1 2 3 4 5



45. Usefulness regression test library 1 2 3 4 5

46. Availability of information on defect statistics, 1 2 3 4 5at initiation of project

47. Stability of application, at start of the project 1 2 3 4 5Guideline—Factor in the frequency and severity of errors being reported

48. Quality of documentation, at start of the project 1 2 3 4 5Guideline—Factor in the currency, exhaustiveness and understandability of thedocumentation

49. Quality of documentation, now 1 2 3 4 5


416 P. BHATT ET AL.

50. What are the top 3 factors (from above list—System Baseline) that decide effort in amaintenance project? (Please mention new factors if you wish)1. 2. 3.

Maintenance Team‘5’ represents high—Minimizes Effort in Maintenance

51. Team morale 1 2 3 4 5

52. Cultural affinity with client 1 2 3 4 5Guideline—How easy was it to communicate with the client?

53. Knowledge Management 1 2 3 4 5Guideline—Can the existing information be passed onto a trainee easily?

54. Handling of Transition phase 1 2 3 4 5Guideline—How well were the issues resolved in transition phase?

55. Handling of Knowledge Transfer/Buildup phase 1 2 3 4 5Guideline—How well was knowledge transferred from the Transition team to theMaintenance team?

56. Development team involvement in Maintenance 1 2 3 4 5Guideline—What is the involvement of people who developed the application in themaintenance effort?

57. Stability in the team 1 2 3 4 5Guideline—5 if attrition (from the team) is 0-5% per month, 4 if 5–10%, 3 if 10–15%, 2 if15–25% and 1 if >25%

58. Level of knowledge before initiation of project 1 2 3 4 5Guideline—Factor in knowledge about the application and its domain, technology andplatform

59. Level of experts availability to the project 1 2 3 4 5

60. % of people wanting to move out of project

61. % of people who cannot work during night time

62. % of people whose permanent residence is in/nearthe city where they work

63. What are the top 3 factors (from above list—Maintenance Team) that decide effort in amaintenance project? (Please mention new factors if you wish)1. 2. 3.



Client Team

Rate the following on a scale of 1 to 5 (5 being highest)

64. Relevance of end users to your maintenance team 1 2 3 4 5Guideline—To what extent do the end-users of the application drive the work given to themaintenance team?

65. Relevance of client’s IT team to maintenance team 1 2 3 4 5Guideline—To what extent does the IT team of client drive the work given to themaintenance team?

66. Closeness of interaction between end-users andIT team of client 1 2 3 4 5

‘5’ represents high—Minimizes Effort in Maintenance

67. Familiarity of end-users with the application 1 2 3 4 5

68. Quality of training given to end-users 1 2 3 4 5

69. Familiarity of client’s IT team with application 1 2 3 4 5

70. Level of experienced people in IT team 1 2 3 4 5

71. Responsiveness to queries raised by your team 1 2 3 4 5Guideline—How quickly do they respond & clarify requests for information?

72. Alignment of client’s IT team 1 2 3 4 5Guideline—Is the IT department of the client interfaced well with their business side? Dothey put up roadblocks to their senior management goals like outsourcing?

73. Team stability of client 1 2 3 4 5Guideline—Does the people interacting with you at the client side change often?

74. Understanding of the severity level of tickets 1 2 3 4 5Guideline—Do they strictly follow the priority level of tickets agreed upon in the contract?

75. Tolerance of the client to SLA or deadline slippage when the slippage isa. 0–10 % 1 2 3 4 5b. 10–25% 1 2 3 4 5c. 25–50% 1 2 3 4 5d. 50–100% 1 2 3 4 5e. More than 100 % 1 2 3 4 5Guideline—How flexible are they in tolerating slippages in meeting the SLA targets?


418 P. BHATT ET AL.

76. Stays within the scope of contract 1 2 3 4 5Guideline—Does the client give you work which may not be covered in the originalcontract?

77. Ability to minimize false alarms 1 2 3 4 5Guideline—‘False alarms’ are issues raised by the client which are actually not requiredto be solved

78. What are the top 3 factors (from above list—Client Team) that decide effort in amaintenance project? (Please mention new factors if you wish)1. 2. 3.

Climate at Workplace

Rate the following on a scale of 1 to 5 (5 being highest)

79. Difficulty of Targets set for the team by PL 1 2 3 4 5

80. Leadership of your supervisor 1 2 3 4 5

81. Project specific training 1 2 3 4 5

82. Other training opportunities available 1 2 3 4 5

83. Level of understaffing in the project 1 2 3 4 5

84. Pressure in the workplace 1 2 3 4 5

85. Space (cubicle, etc.) available for working 1 2 3 4 5

86. Interruptions and distraction level in office 1 2 3 4 5

87. Video/tele conferencing facilities 1 2 3 4 5

88. Desire to move to non-maintenance work 1 2 3 4 5(Rate for the team as a whole)

89. Fairness in bonus (Variable Allowance) distribution 1 2 3 4 5

90. Fairness in your performance review 1 2 3 4 5

91. Timely availability of resources (PCs, desks) 1 2 3 4 5

92. What are the top 3 factors (from above list—Climate at workplace) that decide effort in amaintenance project? (Please mention new factors if you wish)1. 2. 3.



Final Ranking

93. Rank the following (from 1 to 4) according to the influence they haveon effort in a maintenance project.

Factor Category RankOrganizational Climate �

Maintenance Team �

Customer Team �

System Baseline �

Effort

94. How many hours at work do you put in every week?a. 35–40 hours b. 40–45 hoursc. 45–50 hours d. 50–55 hourse. More than 55 hours

95. Productive hours spent at office in a day

96. Total hours spent at office in a typical day

97. % of weeks when you worked over 40 hoursin this project

98. What can increase the ratio of the productive hours to the total hours at office?

99. What can increase your productivity during the productive hours?

Production Support100. Fraction of correct fixes‡ achieved

101. Fraction of tickets that were not requiredto be solved/already solved (false alarms)

102. Do you have a call history (containing instructions on steps to take in case of specificissues)?

a. Yes b. No

103. % of times issues raised are well known problemswith specific workarounds

‡Fixes which passed QA, production and regression testing/Total fixes that were actioned in the period.


420 P. BHATT ET AL.

104. % of effort involved in handling these wellknown problems

105. Number of cases handled by you in a month

106. Average time taken to resolve a case

107. % of time you spent, without an issue to deal with

108. % of effort spent in diagnosis

109. % of effort spent in fixing

110. % of effort spent in testing

Small Enhancements (Category I and II—Less than 50 person-days)

111. Number of cases handled

112. Average effort per case

113. Average % of effort spent in analysis

114. Average % of effort spent in coding/fixing

115. Average % of effort spent in testing

Large Enhancements (Category III and IV—Larger than 50 person-days)

116. Number of cases handled

117. Average hours per FP (or) KLOC

118. Average % of effort spent in analysis

119. Average % of effort spent in coding/fixing

120. Average % of effort spent in testing

Interaction Information

121. How often do you interact with the end-user/client?a. Frequently b. Oftenc. Sometimes d. Rarelye. Never



122. If it is not always easy to communicate with the customer, please explain the difficulty youface.

REFERENCES

1. Chaudhary A, Nam K, Rao HR. Management of information systems outsourcing: A bidding perspective. Journal ofManagement Information Systems 1995; 12(2):131–159.

2. Slaughter S, Ang S. Employment outsourcing in information systems. Communications of the ACM 1996; 39(7):47–49.3. The Economist. A World of Work (survey: outsourcing).

http://www.economist.com/surveys/displaystory.cfm?story id=E1 PPVTQTG [29 September 2006].4. The Economist. Men and Machines (survey: outsourcing).

http://www.economist.com/surveys/displaystory.cfm?story id=E1 PPVTQDN [29 September 2006].5. Craig D, Willmott P. Outsourcing grows up. McKinsey on Finance 2005; 14(4):1–6.6. Aspray W, Mayadas F, Vardi MY (eds.). Globalization and Offshoring of Software—A Report of the ACM Job Migration

Task Force. ACM Press: New York NY, 2006; 245 pp.7. IEEE. Standard for Software Maintenance, IEEE Std 1219-1998, 1998; 47 pp.8. Lientz BP, Swanson EB. Software Maintenance Management. Addison-Wesley: Reading MA, 1980; 214 pp.9. Swanson EB. The dimensions of maintenance. Proceedings of the 2nd International Conference on Software Engineering.

IEEE Computer Society Press: Los Alamitos CA, 1976; 492–497.10. Zelkowitz MV. Perspectives in software engineering. ACM Computing Surveys 1978; 10(2):197–216.11. Shepperd M, Cartwright M. Predicting with sparse data. IEEE Transactions on Software Engineering 2001;

27(11):987–998.12. Lucia AD, Pompella E, Stefanucci S. Effort estimation for corrective software maintenance. Proceedings of the 14th

International Conference on Software Engineering and Knowledge Engineering. ACM Press: New York NY, 2002;409–416.

13. Polo M, Piattini M, Ruiz F. Advances in Software Maintenance Management: Technologies and Solutions. Idea GroupPublishing: Hershey PA, 2003; 300 pp.

14. Ferens DV. The conundrum of software estimation model. IEEE AES Systems Magazine 1999; 14(3):23–29.15. Tsoi HL. A framework for management software project development. Proceedings of the 1999 ACM Symposium on

Applied Computing. ACM Press: New York NY, 1999; 593–597.16. Periyasamy K, Mathew C. Paradigm shift in software re-engineering: An experience report. Proceedings of the 1996

Conference of the Centre for Advanced Studies on Collaborative Research. IBM Press: Toronto ON, 1996; 32.17. Philip T, Ramsundar R. A reengineering framework for small scale software. ACM SIGSOFT Software Engineering Notes

1995; 20(5):51–55.18. Arnold RS. Software Reengineering. IEEE Computer Society Press: Los Alamitos CA, 1993; 675 pp.19. Park RE. Software size measurement: a framework for counting source statements. Technical Report CMU/SEI-92-TR-20,

Software Engineering Institute, Carnegie Mellon University, Pittsburgh PA, 1992; 242 pp. Available at:http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.020.html [10 September 2006].

20. International Organization for Standardization (ISO). Software Engineering—IFPUG 4.1 Unadjusted Functional SizeMeasurement Method—Counting Practices Manual, ISO/IEC 20926:2003, 2003; 342 pp.

21. UKSMA. MK II Function Point Analysis Counting Practices Manual Version 1.3.1. The United Kingdom Software MetricsAssociation: Edenbridge, Kent, U.K., 1998; 100 pp.

22. Common Software Measurement International Consortium. COSMIC-FFP Measurement Manual, Version 2.1.The Common Software Measurement International Consortium: Montreal, Canada, 2001; 59 pp. Available at:http://www.cosmicon.com/ [10 September 2006].

23. Bhatt P, Shroff G, Misra AK. Dynamics of software maintenance. ACM SIGSOFT Software Engineering Notes 2004;29(5):1–5.

24. Dart S, Christie AM, Brown AW. A case study in software maintenance. Technical Report CMU/SEI-93-TR-8, SoftwareEngineering Institute, Carnegie Mellon University, Pittsburgh PA, 1993; 58 pp.

25. Perry WE. Managing Systems Maintenance. Q.E.D. Information Science, Inc.: Wellesley MA, 1981; 372 pp.26. Parikh G. Handbook of Software Maintenance. Wiley: New York NY, 1986; 421 pp.


422 P. BHATT ET AL.

27. Goles T, Chin WW. Information systems outsourcing relationship factors: Detailed conceptualization and initial evidence.The DATA BASE for Advances in Information Systems 2005; 36(4):47–67.

28. Lientz BP. Issues in software maintenance. ACM Computing Surveys 1983; 15(3):271–278.29. Banker RD, Datar SM, Kemerer CF, Zweig D. Software complexity and maintenance costs. Communications of the ACM

1993; 36(11):81–94.30. Ahn S, Suh J, Kim S, Kim H. The software maintenance project estimation model based on function points. Journal of

Software Maintenance and Evolution: Research and Practice 2003; 15(2):71–84.31. Basili V, Briand L, Condon S, Kim Y-M, Melo WL, Valett JD. Understanding and predicting the process of software

maintenance releases. Proceedings 18th International Conference on Software Engineering (ICSE-18). IEEE ComputerSociety Press: Los Alamitos CA, 1996; 464–474.

32. Li W, Delugach H. Software metrics and application domain complexity. Proceedings Asia–Pacific Software Engineeringand International Computer Science Conference (APSEC’97/ICSC’97). IEEE Computer Society Press: Los Alamitos CA,1997; 513–514.

33. Levin RI, Rubin DS. Statistics for Management. Prentice-Hall: Englewood Cliffs NJ, 2005; 91–95 pp.

AUTHORS’ BIOGRAPHIES

Pankaj Bhatt received his Bachelors Degree (with honours) in Computer Science fromRegional Engineering College, Allahabad, India. Presently he is a Principal Consultantwith Tata Consultancy Services with experience in various facets of software lifecycle.His research interests include software engineering, software evolution and maintenanceand software architecture. Earlier, he has also worked in the area of computer networking,operating systems and solution architecture for business systems.

Gautam Shroff received his Bachelors degree in Electrical Engineering from IndianInstitute of Technology, Kanpur, India and his PhD degree in Computer Science fromRensselaer Polytechnic Institute, NY, U.S.A. He is a Vice President with Tata ConsultancyServices. His present research focus is open architectures, Grid computing, service-oriented computing, semantic computing and human–computer interfaces. Prior to joiningTata Consultancy Services, he was a member of the faculty at California Institute ofTechnology, Pasadena, CA, U.S.A. and later at the Department of Computer Science andEngineering at Indian Institute of Technology, Delhi, India.

C. Anantaram received his Masters Degree in Computer Science from BITS, Pilani,India and his PhD degree in Computer Science from IIT Bombay, Mumbai, India. He isa Senior Consultant in Tata Consultancy Services. His areas of interest are knowledgerepresentation and reasoning, knowledge base verification and validation, softwareengineering, natural language interfaces and integrating AI in business applications. He isa member of the Government of India’s Working Group on Metadata and Data Standardsfor e-Governance Applications.



Arun Kumar Misra received his Bachelors degree in Electrical Engineering fromUniversity of Roorkee, India and Masters and PhD degree from Regional EngineeringCollege Allahabad, India. Presently he is a Professor and the head of the Departmentof Computer Science and Engineering at National Institute of Technology (earlierRegional Engineering College), Allahabad, India. His research areas include softwareengineering, programming methodology, artificial intelligence and data mining. He hasseveral publications in various national and international conferences and journals.


an influence model for factors in outsourced software maintenance

Documents