Global sourcing of software development – a review of tools and services
Robert Martignoni PlixoS GmbH
[email protected]
Abstract
Software services in a globally distributed environment face significant management challenges.
All phases of the software life-cycle need to be aligned to the distributed development environment. This challenge has been led to the development of a variety of tools and services. This paper identifies tools and services aiming at the optimisation of the globally distributed software development. Software-as-a- service seems to be a promising approach to optimise the globally distributed software development. The characteristics and advantages of Software-as-a-sevice in regards to globally distributed software development are discussed. The paper concludes with a closing discussion of the identified tools and services.
1. Introduction
Global sourcing of software services can be a significant source of competitive advantage. Global sourcing means leveraging globally distributed resources. The main motivation for global sourcing are the access to competencies, resource availability and costs benefits [1]. Global Sourcing recently gained he attention of IT managers [2]. In the context of this paper, software services are referred to as all software related services such as software development, integration, and maintenance.
Global sourcing has a major impact on the technical development process in terms of software services. The development process is distributed among organisations and locations. As a result the collaboration and responsibilities of the distributed teams need to be managed [3]. Several tools and services have been developed to solve this issue. This paper elaborates the different approaches and the contribution to optimise globally distributed software development.
1.2 Global sourcing of software development
Global sourcing of software development has a major impact on the technical software development process. The terms and conditions of the contract between the involved organisations define the framework of the technical development.
Naturally, both parties follow primarily their own business objectives. The service provider aims at minimizing the resource investment for developing software, while the client expects that the software development fulfills all requirements – even the implicitly expected requirements. This structural issue results in a lack of transparency since every project member filters and alters information in regards to the objectives of his organisation.
Traditional development tools do not sufficiently connect processes over different organisation. For example a traditional requirements management system is deployed to manage the requirements of a software project. The requirements management focuses on the storage and reporting of the client requirements. In the case that the service provider strictly develops a software according to the initially specified requirements conflicts can still arise. For instance the client recognises that specified functions do not adequately cover business requirement and the client changes or adds requirements. The management of the change requests needs to be managed along the development process. In addition, and this is a departure to the traditional development setting, the business impact on the commercial agreement needs to be elaborated. This should be implemented in a way that it is traceable and minimizing bureaucratic effort.
This anecdotal example discussed a specific issue regarding change requests in the globally distributed software development process. The example demonstrates the need to identify clear requirements for tools and services aligning business and technical 2009 Fourth IEEE International Conference on Global Software Engineering
1.2. Alignment of business and technical requirements
The alignment of the technical challenges of globally distributed software development and the business requirements are the foundation of this analysis. On a technical level the globally distributed development process needs to be managed. This addresses the management of requirements, the source code, and the documentation as well as the testing, bug fixing, and quality assurance of project deliverables.
This means primarily that each party has access to the required functions and information, but also that the user rights and tasks are correctly assigned to the role of the user.
The requirements are formulated by the client and implemented by the service provider. Since the requirements are a contractual issue, it is important that the requirements, change requests as well as clarification of both are well documented.
The combination of technical development and business requirements lead to the following key issues that need to be considered in a global sourcing project:
end-to-end transparency
sustainable documentation of activities
communication over different organisations and cultures
shared business objectives.
These key issues are used to evaluate the tools and services in regard to the suitability in the globally distributed development environment.
1.3. Method
The analysis in this paper is primarily based on the software life-cycle. Tools and services along the development process are identified and clustered. In a second step, additional approaches (for instance services) and enhancements of tools with respect to supporting globally distributed development are included in the analysis. The foundation of the analysis was an extensive market analysis, a literature research on globally distributed software development, and the examination of existing taxonomies of software development tools. All development tools found in this process have been gathered, analysed, and then categorised. The result of the analysis is a framework of categorisation of tools. These categories are again the basis to describe the paradigms in optimizing globally distributed software development.
1.4. Structure
This paper starts with the identification of new requirements regarding software development due to global sourcing. Existing tools and services for project support will be identified and categorised. For each category the paradigm will be identified and discussed.
This paper will close with an assessment of the paradigms and an outlook of tool development.
3. Tools and services along the software life-cycle
All software development projects follow an explicit or implicit software development process model. There are a number of process models such as the code-and- fix model, the stage-wise model and the waterfall model, and many more [4]. The different frameworks reflect different philosophies (formal vs. agile) and scope (development vs. software life-cycle). However, in global sourcing, the practical experience has shown that rather formal models are preferred. Hence as foundation and structure for the further analysis the waterfall model is used. The waterfall software development model is based on the following sequential phases: system/software requirements, analysis, program design, coding, testing and operations [5].
For the analysis all tools and services that either support a specific phase or parts of the in the software development process have been identified and analysed by a thorough market analysis. The identified tools and services were grouped and the result was the emergence of four distinct groups, which are development tools, integrated development environments, Software-as-a-service offerings as well as consulting and services.
The identified tools and services and their categorization is shown in figure 1.
Figure 1 demonstrates that there is a wide variety of approaches, which leads to the conclusion that there is
certainly the need to optimise globally distributed software development, but the ultimate solution has not be found yet. Each of the main groups is discussed in the following sections.
3.1. Development tools
Tools have been developed to address specifically one ore more phases of the development process. The following types of tools have been identified that support specific aspects of software development:
Figure 1. Tools and services along the software life-cycle
Document Management System: A database to store and share project related documents, eg.
MS Sharepoint, Docushare
Testing tools: Tool supporting the testing of software, eg. HP Quality Center, Junit
Software Quality assessment: Tools to automatically evaluate the quality of a software, eg. CAST, CheckStyle, EMMA
Performance Monitoring: Tools to measure the performance of the software, eg. Digite, Borland BMS
Source Code Management: Central database to manage the different versions of a source code, eg. Subversion, CVS, Virtual Safe
All this tools support a specific task of the software development process. The sophistication and the applicability of these tools in regard to a global distributed environment can be evaluated based
analysing the scope (task or process) and setting (user or team). As a result of this analysis the development tools can be distinguished into single task tools, supporting a specific task (eg. quality assessment) and single process tools, supporting the management of a specific process involving a team (eg. bug tracking).
However, the single task tools can be used in a globally distributed environment, but do not add any additional functionality or support the globally distributed environment. The single process tools are prepared for a distributed setting, and address specific task dependent issues. The limitation is simply the focus on a specific task. In some scenarios, the value of the tool could be enhanced by integrating it into the overall process.
3.2. Integrated development environment
Integrated development environments (IDE) traditionally are incorporating tools such as compilers, linkers, and debuggers [6]. More recently additional functions such as source code management have been integrated. In regards to IDEs three different types can be identified. Firstly, stand-alone IDE that are optimized for a single programmer to fulfil his task.
Secondly, the enhanced IDEs supporting team features such as issue tracking and source code control. Thirdly, collaborative IDEs integrate collaboration functionality into the development environment. Collaborative IDEs offer a great range of functionalities. They are based on traditional client/server architecture in the closes environment of an organisation.
3.3. Software-as-a-Service
Software-as-a-Service (SaaS) is based on the idea to provide ’software’s functionality as a set of distributed services that can be configured and bound at delivery time can overcome many current limitations constraining software use, deployment, and evolution’
[7]. The main advantage of this model in regard to the development process in a globally distributed environment is the centralised development environment for the distributed team. The SaaS concept minimises the requirement to synchronise or convert data due to the single application and single location approach.
Especially the open source community has shown that the SaaS approach can be applied to successfully develop software in a globally distributed environment.
The SourceForge.net portal claimed to host a minimum of 75,000 open source projects [8]. SourceForge.net is a source code repository, which acts as a centralized location for software developers to control and manage open source software development and is based on the SaaS concept.
Augustin et al. identified the following differences between open source software and commercial software development: mobility of resources, culture of sharing, and peerage [9]. Just as well, commercial issues of software development (approval processes, extensive management reporting, resource allocation, etc.) are not regarded.
3.4. Consulting and Services
The development processes can be also supported by consultancies or service providers. Both types of organisation provide proprietary tools, the
adoption/configuration of commercial tools, manpower, or a project framework to optimise the development process. Usually the scope of this approach is a particular project. Depending on the business parameters of the project (importance, risk, volume, etc.) different approaches are selected. Smaller projects might be only governed by a small internal team, while a bigger project might be supported by a large external consulting team. However, from an organisation point of view, this approach is not a sustainable solution for globally distributed software development.
4. Paradigms of approaches
The number of tools and services is impressive.
Instead of discussing each individual tool and service, a further abstraction is suggested by elaborating the paradigms. Each group represents a certain paradigm of addressing the challenges of globally distributed software development. In the following sections each of the paradigms is introduced and discussed.
4.1 Optimising the overall technical software development
The paradigm of optimizing the overall technical software development by applying an integrate tool suite has been followed by all major commercial software development tool vendors. The development tools are very powerful to support the work of a programmer. But the tools not necessarily provide the functionality required for a distributed development.
4.2. Support of technical development
The paradigm of supporting the technical development refers to tools that address a specific issue in software development, eg. testing of software or managing. These tools are developed to optimise a certain aspect in software development. Furthermore, some of the tools are even specifically designed for a globally distributed environment.
4.3. Project optimization
Thirdly, in regard to the project optimisation external support is sought to optimise selected aspects of the project. This can take the form of providing technical resources for the project, project governance, or consulting services for project management.
4.4. Optimizing globally distributed software development
Fourthly, the approach to optimise globally distributed software development following the software-as-a-service approach addresses all issues of software development on a strategic level
4.5. Analysis of paradigms
The analysis of the paradigms shows that the different paradigms are determined by the scope and level of problem perception. Scope refers to the phases of the development process. There are solutions that cover a particular phase of the development process, and there are other solutions that address specificially the overall development process. Level refers to the impact of the solution on the development process. The tools or services either an impact on the functional level or the strategic level. Functional level refers to the technical development process and strategic level refers to the way how the software is developed.
As a result, figure 2 shows the overview of paradigms based on the two dimensions.
Furthermore, the requirements stated in the beginning of this paper are the foundation for an evaluation of suitability of tools and services. All the stated requirements can be only achieved by tools and services on a strategic level with a comprehensive scope. The tools and services based on another paradigm only partial fulfil these requirements. The tools with a dedicated scope have are limited, and cross functional dependencies are not considered. Tools and services on the functional level can solve particular challenges, but do not adequately consider the business environment of global sourcing.
5. SOFTWARE-AS-A-SERVICE
The analysis of the previous chapters has shown that software development in global sourcing projects lead to new requirements. Existing tools and services have not been primarily developed to be applied in this setting. Collaborative IDEs offer much of the required functionality and consider key challenges of a globally distributed software development. However, the traditional client/server architecture does not fully support global distributed teams. Very often the collaborative IDEs are set-up in the high-security IT area of a company, and cannot be reached by external parties. In addition, the management of roles and rights in terms of the sourcing relationship is not adequately
reflected. The focus of these tools is clearly set on the technical development.
Further analysis has shown that software-as-a- service seems to be most suitable concept. The advantages of the SaaS concept are based on the SaaS architecture. SaaS in the context of globally distributed software development means the central provisioning of a service to support the software development process. In a globally distributed environment this approach solves several issues that are related to access, availability, and synchronisation of information and data. The SaaS concept stands for a shared development environment in contrast to operate different on-site and off-site development environments.
In some global sourcing project, the service provider works on the on-site development environment of the client. This leads to the requirement for the client to provide a development environment that is secured and logically fully separated of the internal development environment. The separation of development environments can result into a major effort and time-consuming challenge, since the client needs to manage access from an uncertain, external entity into the own protected IT landscape. For each project the client needs to set-up the development environment that suits the project requirements.
Furthermore, the availability of a development environment is in many projects an additional issue, since there is no standard development environment for external provider. The customisation requires resources and time that negatively impact the business case of the
Figure 2. Paradigms of tools supporting globally distributed development
project. The separation of development environments also lead to challenges regarding the synchronisation of the environments. The technical challenges are well- known and have not been fully resolved.
In addition, a soft factor that supports the SaaS concept in globally distributed software development can be summarised by the term best practises. Best practise can be developed based on the experience collected in projects and implementing solutions to optimise discovered optimization potentials (learning by doing). In global sourcing projects, unequal knowledge distribution between service provider and clients exists. While the core business of the service provider is the globally distributed software development in different environments and hence the service providers have gained experience from a supply-side perspective, clients have comparable little experiences in best practises in global sourcing global sourcing projects. The result is a project setup that not necessarily supports the objectives of the client. SaaS, operated as an independent service, provides the clients with a neutral instance for managing global sourcing projects. In addition, the SaaS concept provides a shared set of best practises among the users of the service – considering the requirements of service providers and clients.
In summary, SaaS and thereby the concept of a shared development environment promises to solve major issues in globally distributed software development. Shared best practises among the users of the service could further optimise globally distributed software development.
6. Conclusion
This paper has shown the requirements to optimise the software development in global sourcing projects. The cooperation across different organisations are the origin of new requirements in regard to development tools and services. Existing tools and services have been identified and categorised along the scope and level dimensions. Four different categories have been identified: integrated development environments, development tools, software-as-a- service, and consulting & services. Furthermore, for each of the four categories the paradigms are identified and discussed to show their impact on the development process and organisation. As a result, it is suggested that especially software-as-a-service is a suitable concept in a global sourcing environment.
7. References
[1] C. Bozarth, R. Handfield, and A. Das, “Stages of global sourcing strategy evolution: an exploratory study,” Journal of Operations Management, vol. 16, no. 2-3, pp. 241–255, 1998.
[2] E. Carmel and R. Agarwal, Information Systems Outsourcing. Springer Berlin Heidelberg, 2006, ch. The Maturation of Offshore Sourcing of Information Technology Work, pp. 631–650.
[3] J. Y. Murray, M. Kotabe, and A. R. Wildt, “Strategic and financial performance implications of global sourcing strategy: A contingency analysis,” Journal of International Business Studies, vol. 26, no. 1, pp. 181–202, 1995.
[4] B. W. Boehm, “A spiral model of software development and enhancement,” Computer, vol. 21, no. 5, pp. 61–72, May 1988.
[5] W. W. Royce, “Managing the development of large software systems: concepts and techniques,” in ICSE ’87:
Proceedings of the 9th international conference on Software Engineering. Los Alamitos, CA, USA: IEEE Computer Society Press, 1987, pp. 328–338.
[6] S. Hupfer, L.-T. Cheng, S. Ross, and J. Patterson,
“Introducing collaboration into an application development environment,” in CSCW ’04: Proceedings of the 2004 ACM conference on Computer supported cooperative work. New York, NY, USA: ACM, 2004, pp. 21–24.
[7] M. Turner, D. Budgen, and P. Brereton, “Turning software into a service,” Computer, vol. 36, no. 10, pp. 38–
44, Oct. 2003.
[8] A. Rainer and S. Gale, “Sampling open source projects from portals: some preliminary investigations,” Sept. 2005, pp. 10– 27.
[9] L. Augustin, D. Bressler, and G. Smith, “Accelerating software development through collaboration,” 2002, pp.
559–563.
