Open Access
ARTICLE
Offshore Software Maintenance Outsourcing Process Model Validation: A Case Study Approach
1 Faculty of Ocean Engineering Technology and Informatics, University Malaysia Terengganu, Kuala Terengganu, Malaysia
2 Department of Computer Science & Information Technology, Faculty of Information Technology, The University of Lahore, Lahore, 54000, Pakistan
3 Department of Computer Science, College of Computer Science and Information Systems, Najran University, Najran, Saudi Arabia
4 Department of Software Engineering, Faculty of Information Technology, The University of Lahore, Lahore, 54000, Pakistan
* Corresponding Author: Atif Ikram. Email:
Computers, Materials & Continua 2023, 74(3), 5035-5048. https://doi.org/10.32604/cmc.2023.034692
Received 24 July 2022; Accepted 30 September 2022; Issue published 28 December 2022
Abstract
The successful execution and management of Offshore Software Maintenance Outsourcing (OSMO) can be very beneficial for OSMO vendors and the OSMO client. Although a lot of research on software outsourcing is going on, most of the existing literature on offshore outsourcing deals with the outsourcing of software development only. Several frameworks have been developed focusing on guiding software system managers concerning offshore software outsourcing. However, none of these studies delivered comprehensive guidelines for managing the whole process of OSMO. There is a considerable lack of research working on managing OSMO from a vendor’s perspective. Therefore, to find the best practices for managing an OSMO process, it is necessary to further investigate such complex and multifaceted phenomena from the vendor’s perspective. This study validated the preliminary OSMO process model via a case study research approach. The results showed that the OSMO process model is applicable in an industrial setting with few changes. The industrial data collected during the case study enabled this paper to extend the preliminary OSMO process model. The refined version of the OSMO process model has four major phases including (i) Project Assessment, (ii) SLA (iii) Execution, and (iv) Risk.Keywords
Software maintenance is the totality of pre and post-delivery activities to provide cost-effective support to a software system [1]. Literature divides maintenance into four categories named as corrective (bug fixing), adaptive (to cope with environmental change), perfective (changes originated from user request), and preventive maintenance (to make the software more maintainable) [2,3]. Software maintenance is known as the most expensive activity approximately 70% of the total cost of software and the longest phase of the software development lifecycle [4,5]. The term Outsourcing is used when a client purchases goods, services, or something from a foreign or outside supplier, especially instead of an internal source [6]. Software companies, both large and small, are motivated to outsource different phases of the software lifecycle (including maintenance) to reduce costs and improve efficiency. Software maintenance outsourcing is concerned with subcontracting software maintenance and other related activities to a third party, at any level, either onshore or offshore. Outsourcing software maintenance for a product creates special difficulties, particularly when the product is constructed from components that were also outsourced [7]. Software maintenance outsourcing is increasing every year. The studies reveal that this trend of OSMO is rising with every passage of time [8,9]. Most software companies want to outsource their software maintenance process so that they can focus on their core competencies. This helps to gain some specific expertise and knowledge and to get benefit from such capabilities or processes which are not available inside the organization and finally to improve the effectiveness and efficiency of the organization [10]. If outsourcing is properly executed, organizations can improve their daily operations along with competitive and strategic advantages (such as new product research) [11]. The use of a process model can help out the stakeholders to execute the OSMO process properly. Unfortunately, there exists only a handful of publications discussing the OSMO process model. The existing studies describe the OSMO process model or related areas at a general level. Further detail is given in Section 2.
The current study deals with industrial feedback to validate and refine an earlier proposed OSMO process model [12]. This paper contributes a refined OSMO process model based on IT industrial data collection by applying a case study research methodology. The remaining paper is as follows. Section 2 presents the related work, Section 3 discusses the background. Moreover, Section 4 presents the research methodology. Besides, Section 5 describes the results and finally, Section 6 presents the conclusion.
Global outsourcing of software development and maintenance has been on the rise for decades. It is generally acknowledged that offshore software maintenance, whether carried out internally or externally, is an arbitrage strategy intended to reduce costs, obtain access to talents, quality, and flexibility. This concept has been covered in a lot of published literature. The literature can be enhanced with cloud and machine learning areas [13–17]. There exist different related studies which are close to the current research work. The study [18] provides a conceptual framework to deal with the challenges of software maintenance outsourcing in the global context. Although the study in question is very close to the current research work but it has only five interviewees. Also, there may be a risk of influence of any individual who is doing the coding of qualitative data. Besides, the study [19] presented a model in the field of offshore software maintenance outsourcing but it covers only one cluster or area that is decision-making. Moreover, the work [20] provides a model focusing on one cluster or area which is risk assessment. Hence, the existing work highlights the importance of an enhanced OSMO process model and guides us to examine the applicability of the preliminary proposed OSMO Process model.
During Offshore Software Maintenance Outsourcing (OSMO), the customers gain benefits like cost savings, quality-oriented software, and time savings. The authors have already proposed a preliminary version of the OSMO process model in the study [12]. While OSMO is an attractive business, the OSMO vendor still experiences different challenges including the selection of the right project and client, having a fair service level agreement, proper execution of the OSMO process, and mitigation of the risks related to the OSMO process [21,22]. There exist several studies related to addressing such issues but very few have the exact focus on software maintenance outsourcing in an offshore context. The studies [23,24], for example, highlighted the offshore issues related to software maintenance outsourcing and suggested that it is inevitable to have such a process model which can handle issues of software outsourcing. The current study aims to validate the preliminary version of the OSMO process model presented in the study (see Fig. 1).
Case studies are an appropriate research method in the domain of software engineering to investigate current phenomena in the natural environment. They have proven to be the most powerful tool for authenticating empirical software engineering [25]. The current research work has selected a relevant case study. No doubt, it provides an appropriate evidence in a real industrial settings. This method also provides underground perspicacity for problem-solving and evaluation [26]. The research methodology used in this study is shown in Fig. 2.
As the preliminary OSMO process model was developed for use in real-world industrial environments, so case study is a good technique for the OSMO model validation. The focus of this case study is the following:
1. To examine the applicability of the preliminary version of the OSMO process model.
2. How much this version of the OSMO process model is suitable or fit for the software maintenance and development industry.
3. The areas where the preliminary version of the OSMO process model craving enhancements.
Case Study Objectives
This study aims to reduce the gap between industry and academia, in the context of the OSMO process model in such a way that is acceptable and accessible to both practitioners and researchers. The main objective of the case studies is to validate the OSMO process model.
This study addresses two important research questions.
RQ1: Is the existing preliminary OSMO process model applicable in industrial settings?
RQ2: How can the preliminary model be refined as per industrial applied practices?
4.1 Questionnaire Development and Selection of Companies
This study engaged such OSMO vendor organizations which have good experience with OSMO projects and have no objection to releasing the results of the case studies while keeping the organization’s name confidential. An invitation was sent to 13 OSMO vendor organizations including small, medium, and large sizes. The vendor organizations were using agile methodology for software development, maintenance, and delivery. Before the actual implementation of the case study, authors shared our questionnaire [Appendix A] with the targeted organizations. This questionnaire is derived from the six clusters, reported in our preliminary proposed OSMO process model [12]. The proposed OSMO process model [12] consists of six clusters. The authors conducted a pilot study to evaluate our questionnaire. The research labeled this activity as ‘pilot testing of questionnaire’. The pilot test was conducted with the discussion and help of academic and industry experts from Najran University, Najran, Saudi Arabia. These academic experts are also practicing offshore software outsourcing activities. Similarly, the questionnaire was shared and evaluated by three industry experts. These industry experts belong to such vendor organizations which are providing OSMO services from Pakistan to advanced countries like the UK, USA, UAE, etc. The experts demanded to change the structure of the questionnaire. So, the questionnaire has been modified and improved according to the feedback and recommendations obtained from the experts.
At the beginning of the questionnaire, authors asked about some demographics-based information. It is followed by the six clusters, each having a different number of questions. The first cluster has been labeled as ‘Decision-Making’, the second cluster as ‘Proposal Assessment’, the third cluster as ‘Service Level Agreement’, the fourth as ‘Handover’, the fifth as ‘Risk’, and the sixth as the ‘Execution’.
The authors arranged an introductory session with the participants in every company before starting the interviews. The interviews were semi-structured. The authors gave the participants a presentation about the research background, explained the preliminary proposed model, and elaborated on the questions of the questionnaire used in this survey along with a data privacy statement. The participants valued this introductory session and agreed that now they are in a good position to respond. The answers given by the interviewee were recorded in audio files.
As the first step of data analysis, the interview audio files were transcribed into word documents. The research used templates to organize the data that was transcribed earlier. The authors performed the content analysis to identify the similarities and differences with our preliminary OSMO process model. The authors used a coding technique to group the related information. This step made the data useful for the OSMO process model extension. The coded data were stored in tables together with the reference to the individual interview statements to ensure full traceability.
This section presents the results from the case studies conducted in 13 organizations. The overall goal of this research work was to examine the applicability of the OSMO process model in industrial settings and to extend the model based on industrial feedback. The scope of this research work was restricted to the activities performed on the OSMO vendor side. The findings are presented below.
Regarding RQ1 the authors found out that the selected organizations fully implemented four out of six clusters. These are (i) Proposal Assessment (ii) SLA (iii) Risk and (iv) Execution. Regarding Decision-Making cluster, the studied organizations claimed that this activity is purely performed on the client side and is out of the scope of the vendor side. Regarding Handover, the studied organizations suggested that it should be the part of Execution cluster as Handover is performed in parallel to the OSMO Execution phase.
Table 1 presents the applicability of OSMO process clusters in the studied organizations.
Table 2 presents some important attributes like size, domain, and the number of respondents who replied in the interview process.
Table 3 presents information regarding the size and frequency of the organizations involved.
Regarding the Decision-Making cluster, 12 organizations claimed that this activity is performed on the OSMO client side and is not relevant to the vendor side. However, one organization claimed that they are partially involved in decision-making as they facilitate the client side in this process. Regarding the Proposal Assessment cluster, 9 organizations performed the Proposal Assessment activities in full capacity. However, two organizations claimed that they partially performed this activity and two organizations did not perform the activity. The organizations that didn’t not perform the proposal assessment are small-scale organizations and they didn’t have a choice to pick and choose between different OSMO projects due to the financial crunch. The studied organizations suggested that the cluster should be renamed Project Assessment rather than Proposal Assessment. The rationale behind this suggestion is that the client never uploads the proposal rather he uploads the project.
Regarding SLA, ten organizations agreed that they developed a comprehensive SLA. They consider it an important activity as it defines the scope of maintenance activities to be conducted by the vendor side. The organizations that do not fully develop and follow SLA claim that they focus on short-term projects and perform all maintenance activities required by the customer.
Regarding Handover, the majority (8) of the organizations consider it an important activity. They dedicate special resources to taking over the project during the handover phase. However, five studied organizations claimed that they maintain small-scale projects that do not require a comprehensive handover activity. A formal meeting with the client side is enough to take over the project. In case, any issue arises during handover they discuss it informally with the client side. The studied organizations suggested that ‘Handover’ should be the part of ‘Execution’ cluster as the handover process is performed in parallel to OSMO ‘Execution’ phase.
Regarding the Risk cluster, all studied organizations consider it an important activity. However, four organizations partially perform this activity. These four were small-scale organizations struggling for their survival due to a financial crunch. Therefore, they don’t have the luxury to do a risk assessment of projects.
Regarding the Execution cluster, it is the core activity of the OSMO process and all studied organizations agreed that they perform this activity. This is the critical phase of the OSMO process as the vendor organization starts providing maintenance services to the client side. Especially, the first three months of this phase are crucial as the maintenance team receives a huge flux of maintenance requests from the client side. Their reputation might be at stake if they could not be able to provide efficient and satisfactory maintenance services.
Concerning RQ2: How can the preliminary model be refined as per industrial applied practices?
The authors compared our preliminary model with the data collected from the industry. The authors found that three clusters of our model are applicable in an industrial setting as they stand in the preliminary model. These three are Service Level Agreement (SLA), Execution, and Risk. However, in the Risk cluster, the practitioners believe that the risk is an umbrella activity and should be embedded in all clusters. Regarding the Decision-making cluster, the studied organizations believe that this activity is performed on the client side and is out of the scope of vendor side activities for the OSMO process. As for as the handover cluster is concerned, our results showed that handover activities are implemented in parallel to Execution cluster activities. Therefore, it was felt natural to merge both clusters under the Execution cluster. So, now our hybrid or enhanced OSMO process model consists of four clusters including (i) Project Assessment, (ii) Service Level Agreement, (iii) Execution, and (iv) Risk (see Fig. 3). Below the paper, briefly discuss the clusters of refined OSMO process model.
Project Assessment: The Project Assessment cluster deals with vendor-related issues. The vendor (third party maintainer) needs to examine whether he has the experience and resources to serve the required services of the customer or not. The major factor that needs to be considered are customer attitude, the environment of the customer organization, the age of software, the complexity of software, the number of functionalities in a program, the average number of lines in a code, etc.
Service Level Agreement: The Service Level Agreement (SLA) helps the stakeholders involved in clearly mentioning the required services over fix time slot with involved legalities, roles, and responsibilities of involved parties, etc. A well-established SLA can prevent the OSMO process from ultimate damage.
Execution: The Execution cluster, deals with challenges like weaknesses and strengths of processes and products, integration of overall activities, change in code/documentation and keeping its track, setting priorities to received requests by different stakeholders, the impact of change, providing solutions in time without compromising user satisfaction, etc.
Risk: Certain risks are associated with every cluster of the OSMO process model. Therefore, the Risk cluster is integrated with all other clusters. The OSMO process may face undesirable events. These events occur due to different factors like lack of experience and expertise of involved parties in SMO, interdependencies of activities, uncertainty in contracts, uncertainty in legal environments, unstable (financial context) suppliers, Task complexity, measurement problems, the unclear scope of required services, etc.
This work validated the preliminary OSMO model in industrial settings. In particular, this task refined the preliminary OSMO model based on industrial feedback. The refined model consists of four clusters. Our results showed that the model is applicable in the industrial setting. However, it is the large-scale organizations that implement this model comprehensively. Some medium-scale and small-scale organizations utilize a sub-set of clusters depending upon their project needs. This paper focused on outlining the clusters of the OSMO process model. However, there is a need to elicit the activities performed during offshore maintenance in detail and mapping of those activities on the logically relevant clusters of the OSMO process model. This research work is beneficial in two ways. The industry can use our model for the implementation of offshore maintenance projects. On the other hand, academia can use our model as a base and extend it in the alternative contexts of offshore maintenance. The current research paper is also aligned with the published articles [27,28]. The reader may consult these articles as well. The present study was based on data collection from 13 organizations. There is a need to conduct a large-scale case study with more organizations. The model presented in this paper should be implemented in a real-life longitudinal study format.
Acknowledgement: The authors would like to thank and acknowledge Universiti Malaysia Terengganu (UMT) Malaysia and every individual who has been a source of information, support, and encouragement on the successful completion of this manuscript.
Funding Statement: This research is fully funded by Universiti Malaysia Terengganu under the research Grant (PGRG).
Conflicts of Interest: The authors declare that they have no conflicts of interest to report regarding the present study.
References
1. M. E. Micheni, “ERP software maintenance,” in Metrics and Models for Evaluating the Quality and Effectiveness of ERP Software, IGI Global, USA, pp. 307–329, 2020. [Google Scholar]
2. N. Chapin, E. J. Hale, M. K. Khan, F. J. Ramil and G. W. Tan, “Types of software evolution and software maintenance,” Journal of Software Maintenance and Evolution: Research and Practice, vol. 13, no. 1, pp. 3–30, 2001. [Google Scholar]
3. Y. Ren, T. Xing, X. Chen and X. Chai, “Research on software maintenance cost of influence factor analysis and estimation method,” in Proc. ISA, Chaves, Portugal, IEEE, pp. 1–4, 2011. [Google Scholar]
4. S. R. Wahono and N. Suryana, “Combining particle swarm optimization based feature selection and bagging technique for software defect prediction,” International Journal of Software Engineering and Its Applications, vol. 7, no. 5, pp. 153–166, 2013. [Google Scholar]
5. A. F. Fontana and M. Zanoni, “A tool for design pattern detection and software architecture reconstruction,” Information Sciences, vol. 181, no. 7, pp. 1306–1324, 2011. [Google Scholar]
6. A. V. Troacă and A. D. Bodislav, “Outsourcing the concept,” Theoretical and Applied Economics, vol. 6, no. 6, pp. 51–58, 2012. [Google Scholar]
7. S. U. Khan, M. Niazi and R. Ahmad, “Factors influencing clients in the selection of offshore software outsourcing vendors: An exploratory study using a systematic literature review,” Journal of Systems and Software, vol. 84, no. 4, pp. 686–699, 2011. [Google Scholar]
8. H. U. Rahman, M. Raza, P. Afsar, M. Khan, N. Iqbal et al., “Making the sourcing decision of software maintenance and information technology,” IEEE Access, vol. 9, pp. 11492–11510, 2021. [Google Scholar]
9. S. Ali, H. Li, S. U. Khan and Z. Yang, “Practices in software outsourcing partnership: Systematic literature review protocol with analysis,” J. Comput., vol. 13, no. 7, pp. 839–861, 2018. [Google Scholar]
10. R. E. Ahmed, “Software maintenance outsourcing: Issues and strategies,” Computers & Electrical Engineering, vol. 32, no. 6, pp. 449–453, 2006. [Google Scholar]
11. M. A. Ahmed and W. Zhu, “Outsourcing software testing activities: A case study for eastern ocean solutions (eos)—China,” in Proc. ICCSN, Xi’an, China, pp. 742–744, 2011. [Google Scholar]
12. A. Ikram, M. A. Jalil, A. B. Ngah and A. S. Khan, “Towards offshore software maintenance outsourcing process model,” International Journal of Computer Science and Network Security, vol. 20, no. 4, pp. 6–14, 2020. [Google Scholar]
13. H. U. Rahman, M. Raza, P. Afsar and H. U. Khan, “Empirical investigation of influencing factors regarding offshore outsourcing decision of application maintenance,” IEEE Access, vol. 9, pp. 58589–58608, 2021. [Google Scholar]
14. H. U. Rahman, M. Raza, P. Afsar, H. U. Khan and S. Nazir, “Analyzing factors that influence offshore outsourcing decision of application maintenance,” IEEE Access, vol. 8, pp. 183913–183926, 2020. [Google Scholar]
15. V. Rajasekar, P. Jayapaul, S. Krishnamoorthi and M. Saračević, “Secure remote user authentication scheme on health care, IoT and cloud applications: A multilayer systematic survey,” Acta Polytechnica Hungarica, vol. 18, no. 3, pp. 87–106, 2021. [Google Scholar]
16. K. Hamid, M. W. Iqbal, E. Arif, Y. Mahmood, A. S. Khan et al., “K-banhatti invariants empowered topological investigation of bridge networks,” Computer, Materials & Continua, vol. 73, no. 3, pp. 5423–5440, 2022. [Google Scholar]
17. A. Ikram, M. A. Jalil, A. B. Ngah, A. S. Khan, N. Iqbal et al., “Encryption algorithm for securing non-disclosure agreements in outsourcing offshore software maintenance,” Computer, Materials & Continua, vol. 73, no. 2, pp. 3827–3845, 2022. [Google Scholar]
18. B. Ulziit, Z. A. Warraich, C. Gencel and K. Petersen, “A conceptual framework of challenges and solutions for managing global software maintenance,” Journal of Software: Evolution and Process, vol. 27, no. 10, pp. 763–792, 2015. [Google Scholar]
19. H. U. Rahman, M. Raza, P. Afsar, A. Alharbi, S. Ahmad et al., “Multi-criteria decision making model for application maintenance offshoring using analytic hierarchy process,” Applied Sciences, vol. 11, no. 18, 2021. [Google Scholar]
20. Y. M. Hsieh, Y. C. Hsu and C. T. Lin, “Risk assessment in new software development projects at the front end: A fuzzy logic approach,” Journal of Ambient Intelligence and Humanized Computing, vol. 9, no. 2, pp. 295–305, 2018. [Google Scholar]
21. W. A. Khan, I. Hussain and M. Zamir, “Analytic hierarchy process-based prioritization framework for vendor’s reliability challenges in global software development,” Journal of Software: Evolution and Process, vol. 33, no. 3, pp. 2310, 2021. [Google Scholar]
22. A. Ikram, H. Riaz and S. A. Khan, “Eliciting theory of software maintenance outsourcing process: A systematic literature review,” Int. J. Comput. Sci. Netw. Secur., vol. 18, no. 4, pp. 132–143, 2018. [Google Scholar]
23. S. Naciri and J. M. Idrissi, “Third-party application maintenance management,” International Journal of Computer Applications, vol. 103, no. 6, 2014. [Google Scholar]
24. H. Liang, J. J. Wang, Y. Xue and X. Cui, “IT outsourcing research from 1992 to 2013: A literature review based on main path analysis,” Information & Management, vol. 53, no. 2, pp. 227–251, 2016. [Google Scholar]
25. P. Runeson and M. Höst, “Guidelines for conducting and reporting case study research in software engineering,” Empirical Software Engineering, vol. 14, no. 2, pp. 131–164, 2009. [Google Scholar]
26. S. Phelan, “Case study research: Design and methods,” Evaluation & Research in Education, vol. 24, no. 3, pp. 221–222, 2011. [Google Scholar]
27. A. Ikram, M. A. Jalil, A. B. Ngah, A. S. Khan and Y. Mahmood, “An empirical investigation of vendor readiness to assess offshore software maintenance outsourcing project,” IJCSNS, vol. 22, no. 3, pp. 229, 2022. [Google Scholar]
28. A. Ikram, M. A. Jalil, A. B. Ngah, A. S. Khan and T. Iqbal, “Offshore software maintenance outsourcing predicting clients proposal using supervised learning,” arXiv preprint arXiv, 2021. [Google Scholar]
A Appendix
This questionnaire has two goals
1- We are interested in evaluating the applicability of our preliminary model in an industrial setting by obtaining industrial feedback.
2- We are interested in extending our model by obtaining industrial feedback. This will help us in developing a hybrid model.
Offshore Software Maintenance Outsourcing Process Model Evaluation Questionnaire
1. Do you perform Offshore Software Maintenance Outsourcing in your company?
If the answer is yes, only then proceed with the rest of the questionnaire.
2. The interviewee’s data
i. What is your email?
ii. What is your telephone number?
3. What is the name of your company?
4. What is the number of employees at your company?
5. What is your role within the organization?
6. What types of products do you develop in your organization?
7. What development model is followed in your organization?
Waterfall, Agile, Other models (please specify)
1. Decision-Making
2. Proposal Assessment
• What kind of risks do you face in this cluster? How do you mitigate these risks?
• Do you perform any other activities which are not listed here?
• What are those activities?
3. Service Level Agreement
• What kind of risks do you face in this cluster? How do you mitigate these risks?
• Do you perform any other activities which are not listed here?
• What are those activities?
4. Handover
• What kind of risks do you face in this cluster? How do you mitigate these risks?
• Do you perform any other activities which are not listed here?
• What are those activities?
5. Risk
• What kind of risks do you face in this cluster? How do you mitigate these risks?
• Do you perform any other activities which are not listed here?
• What are those activities?
6. Execution
• What kind of risks do you face in this cluster? How do you mitigate these risks?
• Do you perform any other activities which are not listed here?
• What are those activities?
Cite This Article
This work is licensed under a Creative Commons Attribution 4.0 International License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.