A Systematic Literature Review on Global Software Development Life ...

ACM SIGSOFT Software Engineering Notes

Page 1

March 2015 Volume 40 Number 2

A Systematic Literature Review on Global Software Development Life Cycle Ritu Jain

Ugrasen Suman

Research Scholar, School of Computer Science& IT Devi Ahilya University,Indore, M.P., India 91-9630870019

Professor, School of Computer Science& IT Devi Ahilya University,Indore, M.P., India 91-9826953187

[email protected]

[email protected]

ABSTRACT Global software development (GSD) has now become a prominent software development paradigm. Software companies are increasingly adopting GSD approaches in order to produce high quality software. GSD’s popularity has attracted the researchers to investigate this field, but most of the research work related to global software development cycle is scattered. Therefore, there is a need to integrate and compile all research work related to GSD life cycle to provide a consolidated understanding for software practitioners as well as researchers. In this paper, we report our findings through systematic literature review that aimed at identifying the challenges faced by the globally distributed teams during various phases of software development. We have also discussed suggested best practices, and tools that can be helpful in alleviating these challenges.

Categories and Subject Descriptors D.2.9 [Software Engineering-Management]

General Terms Management, Measurement, Documentation, Performance, Design, Languages.

Keywords Global software development, distributed software development, software development life cycle, software engineering, process, systematic literature review, process, problems, challenges, best practices, tools.

1. INTRODUCTION In recent years, geographic distribution of software development has become a prevalent trend. This globalization of software development is in the form of offshore outsourcing, and offshore insourcing. The situation in which the teams are distributed across national boundaries is called Global software development (GSD). The software companies are shifting their development work towards GSD to yield strategic and economic advantages [16]. The prospective strategic and economic benefits of GSD include decreased development cost, reduced cycle time, access to a large pool of competent developers, closer proximity to local market, modularization of code, and improved record of communication [2, 3, 4, 14]. In GSD, vendors can utilize communications infrastructure in their home environment. They also benefit from favorable governmental policies and tax subsidies [12]. Such potential benefits cannot be achieved due to different types of challenges that teams face in GSD. Team members in GSD face many challenges on technical, cultural, political, and social levels [14]. These challenges were due to increased geographical, temporal, socio-cultural, linguistic, and organizational distances. These distances usually result in challenges related to communication, coordination, and collaboration [4, 14]. Due to these problems, distributed development work consumes 2.5 times longer as compared to collocated work [S2].

DOI:10.1145/2735399.2735408

Geographical distance means that different software teams and customers are physically separated. This distance results in lack of informal communication [9, S8], less shared project awareness [S8], information exchange problems [13], and knowledge management difficulties [9]. Other problems caused by this distance include process transparency issues [13], increased cost of communication (implementing communication infrastructure, exchange of team members), and coordination issues [S8]. Temporal distance can be imposed by difference in time zones or in working hours [1]. The problems faced due to temporal distance are restricted synchronous communication, delayed feedback [S8]. Socio-cultural distance negatively impact trust and confidence between sites. It also leads to inconsistent work practices, reduced informal communication due to linguistic difference, diverse usage of terminologies [1, S8]. Different perceptions regarding hierarchy, and dissimilarity in work ethics causes misunderstandings. Team members belonging to higher cost economies feel threatened to train, share information and knowledge with their lower cost economies counterparts [1]. Inconsistent development and build environments (tools, standards, work practices) [5, S8], different process maturity levels and experience, [S3, S7, S20], process mismatch between sites are several problems caused due to organizational distance. User groups belonging to different organizations have different usability and functionality requirements. So, clients face difficulty in consolidating and negotiating requirements. Thus, it is difficult to maintain a common product vision and establish process transparency [S8]. As GSD entails numerous challenges, execution and management of globally distributed software project is a tedious task. In spite of the fact that GSD has become a common norm, effective strategies, tools and practices to successfully organize and implement global software development are not standardized [8]. In collocated environment, software products are developed with the help of various standard process models, whereas in GSD, there is still lack of standard approach to execute software projects and develop software products. The companies have initially applied sequential processes such as waterfall to develop products in a distributed manner. But, as the failure rate of distributed projects has been very high, companies have initiated with iterative approaches, such as agile methodology in GSD [S30]. It is difficult to apply such iterative approaches in distributed environment and some companies have also employed hybrid approach, which encompasses sequential as well as iterative methodology. Traditional software development processes as well as agile methodologies were designed for collocated software development. Therefore, they do not suitably consider these distances and their associated challenges. Therefore, these processes when applied in GSD do not provide desired results. These challenges can be dealt by designing new processes or by modifying these processes to support their practices in GSD [7, 8, 12, 15, 20]. Effective project planning, management, and tracking will further aid in reducing the effect of various distances [20]. There are many challenges in global software development cycle, which can be addressed using social and technical solutions. This paper is organized as follows. Section 2 presents a brief background and summarizes the related work. Section 3 describes the research method, which is used in this study. Section 4 presents the

http://doi.acm.org/10.1145/2735399.2735408

ACM SIGSOFT Software Engineering Notes

Page 2

results from systematic literature review (SLR), listing the challenges and solutions observed in the GSD life cycle. Finally, section 5 provides concluding remarks.

2. BACKGROUND AND RELATED WORK A software process is a set of work activities, actions, and tasks that are required to build software. The aim of a software process is to produce high quality software within budget, and time. The process can be seen as a road map which guides project participants about the necessities to successfully complete the project [19]. A number of studies show that about 40 percent of global software development projects have failed [6]. The reasons behind these failures are high coordination costs, lack of face-to-face communication, and inexperience of distributed development, and cultural misunderstandings [S10]. Other reasons include lack of understanding of requirements, lack of common language [S19], lack of a standard process, and negligence of the challenges of offshore projects [S1]. In GSD, as project participants of different organizations collaborate to develop software, it is often observed that they follow different processes which can lead to synchronization and integration problems. It can also induce frustration, mistrust, and misunderstandings which in turn, introduces rework, delay, defects and poor acceptance level [10]. Jim´enez et al conducted an SLR to investigate challenges and improvements in distributed software development [16]. They have discussed problems and improvements related to communication, group awareness, software configuration management, knowledge management, collaboration, project and process management, process support, quality and measurement, risk management. Lopez et al created a repository of challenges and safeguards for requirements engineering process in GSD [18]. Gomes et al has also conducted a literature review on problems and their solutions in global software development [11]. They have discussed the problems and solutions associated to people, communication, management, process, infrastructure and technology. The proposed SLR focuses on GSD challenges and best practices that are faced during software development life cycle (SDLC).There does not exist any SLR that focuses solely on problems faced during the phases of GSD. This SLR will be useful for practitioners as well as researchers. It could aware practitioners about the problems that they can face during SDLC. It will be helpful for researchers as it provides a consolidated research platform.

3. RESEARCH METHOD “Systematic literature review (also referred to as a systematic review) is a form of secondary study that uses a well-defined methodology to identify, analyse and interpret all available evidence related to a specific research question in a way that is unbiased and (to a degree) repeatable” [17].We have followed the guidelines provided by Kitchenham and Charters. The goal of this SLR is to systematically examine literature, to find the problems confronted and solutions suggested during different phases in GSD. The research questions, data sources, retrieval, and extraction, and study selection are discussed in the following subsections.

3.1 Research Questions In order to develop a complete understanding of the problems and solutions during global software development, we have formulated the following research questions (RQ): RQ1: What are the problems reported regarding the GSD software development life cycle activities and processes? RQ2: What are the best practices suggested for improving GSD software development life cycle activities and processes? RQ3: What are the tools suggested for improving GSD software development life cycle activities and processes?

DOI:10.1145/2735399.2735408

March 2015 Volume 40 Number 2

3.2 Data Sources There are several sources of academic databases. We have chosen the following databases, which are considered as mainstream venues for global software development: • IEEE Xplore ( www.ieeexplore.ieee.org) • ACM Digital library (portal.acm.org/dl.cfm) • Wiley InterScience (www.interscience.wiley.com) • Elsevier Science Direct (www.sciencedirect.com) • SpringerLink (www.springerlink.com)

3.3 Data Retrieval We want to search all the challenges and best practices associated with global software development phases and the tools used in these phases. As, there are several synonyms of GSD, we have included these synonyms in our search. We have specifically included all the phases of SDLC as well as the general terms used for SDLC in our search string. Search string that we have used is as follows: (("global software engineering" OR "global software development" OR "distributed software development" OR "distributed software engineering" OR "offshore software development" OR "offshore software engineering") AND ("requirements" OR “design” OR "coding" OR “construction” OR “testing” OR "integration" OR "process model" OR "framework" OR "software development life cycle" OR "software development activities") AND ("challenges" OR "solutions" OR ”best practices” OR "problems" OR success OR “tools”))

3.4 Studies Selection Primary studies were included according to the following criteria: • Were written in English. • Were available online. • Were published between 2000 and 2013. • Have discussed challenges and solutions regarding GSD process. • Have explicitly targeted one of the phases of SDLC or discussed the global software development life cycle problems or solutions or best practices or tools. Articles were excluded if they: • Were duplicate or repeated studies. • Were not directly related to the objective of the research. • Were related to global software engineering education or global product line engineering. The above mentioned electronic databases are searched using the search string. The search string has been adapted according to the database. In the first review, the title and abstract of the paper is reviewed to decide whether to include it or not. The papers selected in first review are again reviewed by reading their introduction, few pages, and conclusion. Then the subset of the papers, which were found relevant, was selected. In the final review, whole papers were read and verified whether they are satisfying the inclusion criteria. The result of applying search string, first review, and second review, and final selection is shown in Table 1.

http://doi.acm.org/10.1145/2735399.2735408

ACM SIGSOFT Software Engineering Notes

Page 3

March 2015 Volume 40 Number 2

4.2 Phase wise distribution of studies Table 1: Result of application of Search string and reviews Resources

Search Results

Primary Selection

Secondary Selection

Final Selection

IEEE Xplore

212

114

38

34

ACM Digital Library Elsevier Science Direct Springer Link

1614

45

13

10

17

8

3

1

103

10

7

5

Wiley InterScience Total

15

5

2

1

1961

182

63

51

3.5 Data Extraction After secondary selection, 63 papers were fully read. 12 papers out of 63 were rejected, either due to repetition, or the studies have not reported any challenges or solutions or tools of GSD lifecycle. MS-Excel was used for data extraction. Data extraction form contains the following information: title, authors, publication year, database, author’s background, affiliations, countries, phases covered, GSE settings, research methodology, and results. For 51 selected papers, data was recorded. Then, qualitative analysis was performed to categorize the challenges, best practices and tools. These challenges, best practices, and tools are reported in the result section.

The phase wise result of literature review is shown in Table 2. It can be seen that the phase, which is most researched is requirement engineering. Coding is the least discussed phase. Table 2: Phase wise results of literature review Phases

Primary Studies

Total number of studies

Requirement Engineering

[S1], [S2], [S3], [S4], [S5], [S6], [S7], [S8], [S9], [S10], [S11], [S12], [S13], [S14], [S15], [S16], [S17], [S18], [S19], [S20], [S21], [S22], [S23], [S35], [S49], [S51]

26

System Design

[S1], [S3], [S4], [S5], [S6], [S7], [S13], [S24], [S25], [S26], [S27], [S28], [S29], [S30], [S31], [S32], [S44], [S46], [S49], [S50], [S51]

21

Coding

[S8], [S13], [S24], [S27], [S28], [S29], [S33], [S35], [S45], [S47], [S51]

11

Testing

[S1], [S3], [S13], [S30], [S34], [S36], [S37], [S38], [S39], [S40], [S41], [S42], [S50], [S51]

14

Integration

[S1], [S5], [S7], [S9], [S11 [S27], [S30], [S33], [S43], [S44], [S46], [S47], [S48], [S49], [S51]

15

3.6 Threats to Validity We have search limited databases for constructing SLR due to budget and time constraints, but we have covered most of the relevant sources of GSD research. Different databases use different terminologies for GSD, so we have included most of the keywords used to represent GSD and SDLC. The search string has been slightly modified according to the search engines to reduce the number of irrelevant studies. We have sincerely thoroughly and systematically applied the search process for extracting relevant studies. It might be possible that few papers may have not been considered due to rising number of studies in this research field. For ensuring the reliability of search process, the first author has applied the search process and the second author has cross checked the results of search from time to time.

4. RESULTS 4.1 Year wise distribution of studies Figure 1 shows year wise distribution of publications. It can be seen that the number of papers from 2000 to 2005 were less than papers from 2006 to 2013. 44 studies (i.e. 86%) were published after 2005. This shows that the interest in GSD life cycle has increased after 2005.

4.3 Research type wise distribution of studies Figure 2 depicts the distribution of primary studies according to research type. The percentage of case studies (i.e., 45%) and industrial experience reports (i.e., 17%) reveals that interest of researchers as well as practitioners has been constantly increasing in investigating GSD life cycle activities.

2%

Case Studies

4% 4%

Industry Experience Reports Literature review

10% 45%

6%

Quasi Experiments Survey

6%

Theoritical

6%

Ethnographies

17%

Action Research

Number of publications by year

Unclear 10 8 6 4 2 0

Figure 2: Distribution of primary studies according to research type 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013

4.4 Challenges, Best Practices, and Tools The challenges, best practices, and tools in various phases of SDLC with respect to GSD are discussed in the following paragraphs.

Figure 1: Frequency of publications by year

DOI:10.1145/2735399.2735408

http://doi.acm.org/10.1145/2735399.2735408

ACM SIGSOFT Software Engineering Notes

Page 4

4.4.1 Requirement Engineering Communication and collaboration intensive nature of requirement engineering (RE) phase prove it as the most challenging phase of global software development.

4.4.1.1 Challenges Organizational challenges 1. Process, and methodology mismatch causes rework, delays, and increases requirement defects [S11, S13]. 2. Tool mismatch among client and vendor causes loss of data during transfer and thus, increases requirement defects [S3, S11]. 3. Diverse terminologies and different levels of detail causes analysis for conflicts and redundancies complicated, and thus, affect requirement prioritisation and negotiation [S3, S9, S14, S23]. 4. Project team members often lack skills and experience to work in distributed environment [S13]. 5. Problems in tracing requirements are encountered when requirement are elicited using different teams, tools, processes, and media [S13, S18]. 6. Analysts are often unwilling to review work done at another location [S13]. 7. Different organizations have different levels of maturity of RE process [S11]. 8. Low client involvement and insufficiently detailed requirement specifications results in incomplete knowledge, and delay in development [S11, S13]. 9. Clients do not share responsibility for delay with vendors even when the delay is due to late inputs from client side [S11]. 10. Lack of overall leadership and scattered command chain leads to imprecise project management [S13]. 11. Unplanned and sudden expansion and shrinking of team can lead to incomplete or failed software project [S11]. Geographical challenges 1. Slowdown of requirements negotiation and reduction in transparency due to continuous passing of information back and forth between different sites involved in the development [S11]. 2. Developers can not examine the current system in users’ environment. It distresses their understanding of the rationale for requirements [S1, S9, S11]. 3. As, more people are involved in multi-site requirement changes as compared to collocated one, the information about change is often not transmitted timely and effectively to all remote participants, which leads to misunderstandings, requirements conflicts. Thus, it is difficult to get to common consent among different geographically dispersed sites. [S1, S2, S9, S13, S15, S19, S20]. 4. Loss of team cohesiveness as participants cannot trust people whom they have not met [S20]. 5. Unstable requirements are more difficult to handle when teams are geographically dispersed [S7]. 6. A common understanding of customer requirements and architecture is very difficult to achieve among different teams [S7]. 7. It is difficult to share complete information of requirements from multiple sources with the developers [S2, S9, S14, S16]. 8. Remote participants are unaware of the people working on the same or related set of requirements [S2, S15]. Temporal challenges 1. Difficult to discuss issues related to incomplete requirements, therefore, developers work on the basis of assumptions [S12]. 2. Little time overlap for synchronous collaboration [S9, S20, S21]. 3. Synchronous meetings are always uncomfortable for temporally distant sites [S9, S17]. 4. Asynchronous communication slows down decision making, issues clarification, and thus delays project [S2]. 5. Inappropriate participation of system users and field personnel during RE phase lead to incomplete set of requirements [S9].

DOI:10.1145/2735399.2735408

March 2015 Volume 40 Number 2

6. Reduced capability to share RE artefacts affects requirement negotiation [S9, S16]. Socio-cultural challenges 1. Some requirements being meaningful only in the context of certain cultural beliefs and values [S9]. 2. Differences in ways to express dissatisfaction, perceptions regarding punctuality, scheduling, hierarchy, urgency, or risks, often leads to misunderstanding among participants and thus, spoils relationships and reduces trust [S9, S10, S11, S19, S20, S21] . 3. Organizational and functional disparity significantly impedes common understanding and requirement negotiation [S9, S11, S19]. 4. Differences in work hours, lunch breaks, weekends, festivals, and holidays can induce delays, and frustration [S21]. 5. Users belonging to different national and organizational cultures have large and often conflicting set of requirements. Therefore, client faces difficulty in consolidating and negotiating requirements [S8, S16]. Linguistic challenges 1. Client’s requirements were not fully absorbed by vendor team due to restricted flow of contextual or open ended information. Therefore, a part of requirement documentation was based on assumptions [S3, S9, S11]. 2. Different levels of knowledge of a common language, and different style of communication induces misunderstandings, decreased requirement comprehension, low quality requirements elicitation and validation, adversely affects customer’s requirement prioritisation and negotiation for a specific release [S2, S3, S9, S11, S16, S20, S21]. Inadequate communication 1. Limited and indirect interactions between development and system users lead to misinterpreted, and distorted information, thus affect requirement gathering, requirement analysis, system prototyping and requirement validation [S4, S9, S11, S20]. 2. Slow and incomplete propagation of information interrupts timely updating of documentation [S2]. 3. Difficulties in gaining shared understanding of requirements causes rework, and increases delays [S1, S2, S3, S9, S11, S16, S17, S20, S21]. 4. Lack of informal and face-to-face communication reduces awareness about activities at remote sites which in turn increases misunderstanding, negatively affects trust and relationships [S2, S3, S6, S9, S16, S20]. 5. Quality and usage of communication tools affect the communication of requirements [S9]. 6. Slow resolution of issues by onshore team negatively affects commitment establishment, and decrease in trust in offshore team [S6, S9, S11, S16, S20, S21]. 7. GSD requirement changes faces problems related to communicating and propagating changes, conflicting changes, impact of a change, finding relevant persons. Due to all these reasons, requirement change takes longer [S1, S2, S3, S5, S9, S11, S13, S16, S17, S20, S19]. 8. Difficult to convey the urgency of a situation across sites [S2]. 9. Tacit knowledge is very hard to transfer [S14, S46]. Inadequate coordination 1. Vendor team obtain insufficient, incomplete, and distorted information about requirements indirectly through clients IT analysts [S11]. 2. An unsystematic handover without further clarifications provokes frustration [S11, S12, S14]. 3. Companies often fail to follow documented process [S13]. Technical challenges

http://doi.acm.org/10.1145/2735399.2735408

ACM SIGSOFT Software Engineering Notes

Page 5

1. Lack of effective tools for requirement engineering [S1]. 2. Tool mismatch among client and vendor teams increases rework and delays project [S11]. 3. Existing tools such as instant messenger, e-mail, screen sharing are quite ineffective in facilitating handover, when teams are geographically and temporally dispersed [S12]. 4. UML based models do not portray clear and comprehensive picture of requirements to stakeholders [S17].

4.4.1.2 Best practices •

•

• • • • • • • •

• • •

• • •

•

Efficient communication, coordination and collaboration mechanisms can be applied for requirement management, negotiation and specification [S2, S16, S20]. Continuous discussion on requirements among relevant stakeholders is needed to gain a unified interpretation and understanding, which will in turn optimize designs and software components so that they can be effortlessly and quickly integrated [S7]. Language training lessons can be provided to vendors to reduce linguistic distance [S20]. Regular face-to-face formal and informal meetings will enhance trust, keep up motivation, and maintain continuous communication and coordination help in understanding requirements [S11, S20]. A central project artefacts repository can be maintained in which changes incorporated at one site can be seen at other site [S11, S19]. A well-defined process is required for acquiring and managing relevant knowledge [S15, S16]. Documents management can be used as an effective mechanism to combat the effect of cultural difference, reduced communication richness, geographic diffusion and coordination challenges [S20]. A well-defined process, competence management, and tools can be used to acquire requirements knowledge and relevant information from an expert [S12, S15, S16, S20]. All the stakeholders should have a common vision and should be aligned to the same objective [S11]. Additional symbols and relationships can introduced in UML that can aid in requirement traceability, and monitor hazards, and that can portray a clear and comprehensive picture of requirements to stakeholders [S18]. A standard approach to requirement change management should be followed in GSD [S19]. Awareness mechanisms such as requirements visualization can help in effectively propagating change information and increasing understandings [S16, S17]. Collaborative environment based on wikis, for example SoftWiki, ShyWiki, voting, WikiWinWin, SmartWiki, Stakesource, Annotation tool, iRequire are helpful for requirement elicitation [S17]. Training to use communication technology and tools should be provided to team members. Cultural trainings should also be given to team members to increase cultural understanding [S11]. A common process and same tools should be followed by all teams [S11, S22]. A well-defined project structure can be created which clearly depicts the value, deadline, and dependencies of each activity and its associated artefacts. Roles and responsibilities of team members should also be elaborated. Formal standards should be designed for conducting meetings, following processes, commitments, deadlines, usage of tools, and technologies [S11]. Practical metrics for performance, strong reporting mechanism to increase the visibility of the project should be developed. Distributed quality function deployment can be used for prioritizing requirements [S11].

DOI:10.1145/2735399.2735408

• •

•

March 2015 Volume 40 Number 2 Direct communication between key users and developers are necessary for effective requirements gathering [S35]. Telephones, emails, job rotation and chats, instant messaging, video conferencing, human facilitator, and face-to-face kick-off meetings, communication sessions are some of techniques that are used to involve all the associated stakeholders from remote locations [S11, S12, S20]. Sharing of templates related to requirements specification can increase the understanding and ensure that technology should be accessible and compatible to all teams [S11].

4.4.2 System design In GSD, lack of well-defined and modular architecture can lead to high coordination cost, delays and expensive integration [S13, S46].

4.4.2.1 Challenges Geographical challenges 1. It is difficult to manage interdependencies among work items that are being developed at different sites [S32, S44]. 2. Non-textual artefacts make it difficult to highlight and manage changes [S1]. 3. Relationship between software dependencies and task dependencies is difficult to discover at the time of designing of architecture [S3]. 4. Coordination problems occur due to lack of common understandin of the architecture [S5, S7]. 5. Remote teams are unable to understand, evaluate, and reason about software architecture [S32]. Temporal challenges 1. Synchronous meetings of architecture and developers are difficult which impinge building of common understanding of architecture among developers [S6]. Socio-cultural challenges 1. It is difficult to communicate architectural design decisions to geographically and culturally dispersed teams [S26]. Technical challenges 1. Current tools do not offer ample support for concurrency and conflict resolution [S1]. 2. Conventional CASE tools do not support design activities in GSD efficiently [S1]. Process challenges 1. No standard process in GSD by which the architectural rules are captured, distributed, and protected within the organization [S6]. 2. Detection of syntactic and semantic task dependencies in early stage of software development is difficult [S24]. 3. Lack of resources for capturing the architectural rules in archnotes [S6]. 4. Frequency and effectiveness of meetings of architecture team with developers is low [S6]. 5. Incompleteness and inaccuracy related to interface specification can lead to lot of rework [S5]. 6. Status of architecture may not be managed [S7]. 7. Lack of standard method that can proactively verify organizational and architecture fit early in the project [S3, S46]. 8. Lack of documents that describes the overall architecture of the software under development [S5]. 9. Outdated documentation leads to rework [S24]. 10. It is difficult to discover the correlation between architectural decisions and the coordination requirements they will enforce [S3, S31].

4.4.2.2 Best practices: Well defined software architecture can guide development process and reduce the impact of distances of GSD.

http://doi.acm.org/10.1145/2735399.2735408

ACM SIGSOFT Software Engineering Notes •

•

• •

•

• • •

• • • •

• • • • •

• • •

•

Page 6

Plan subsystems and architectural artefacts in such a way that remote teams can work independently but collaboratively to reduce communication and coordination needs [S4, S5, S24, S29, S30, S32]. Architectural knowledge dissemination can be speeded up, if architecture team answer to urgent questions immediately. It will also help in building trust [S32]. Knowledge management tools can be used to store design decisions and its rationale [S26, S32]. Frequency and effectiveness of meetings of architecture team with developers should be increased. Archnotes should be prioritized according to relevance by architecture team [S6]. Clear and updated architecture documentation can be helpful for developers in GSD. For this, documentation should be verified with code in code-review process [S24, S32]. Clearly defined architectural patterns and practices are needed for effective architectural knowledge management [S32]. Architectural framework in GSD should include architectural viewpoint [S32]. Architect should monitor architecture during entire development lifecycle. S/he should adapt architecture according to the availability of resources, and change in dependencies Remote teams should be timely informed about changes in design decisions [S5, S24, S32]. Architect should verify the compliance of architecture rules [S6]. Remote teams should be able to understand, evaluate, and reason about software architecture [S30, S32]. Tailored views of software architectures should be created and distributed to relevant team member at intervals [S27, S32]. In GSD, interdependencies between the activities should be coordinated properly and software architecture should be treated as a coordination mechanism [S5, S6]. A repository for storing architecture artefacts should be established [S26]. Conventional CASE tools can be tailored for GSD [S1]. Early identification of dependencies will be helpful in effective task allocation [S24]. Decentralization of code reviews can be useful in detection of dependencies among modules [S24]. Effective communication and coordination mechanisms are needed to communicate architecture design decisions and rules to developers and to increase organizational awareness. These mechanisms can be adapted according to modifications in schedule [S3, S5, S6, S24, S26, S27]. Plug-in tools should be developed which can easily be integrated with work environment [S25]. Interfaces between system components should be clearly and completely specified [S5]. Three strategies can be used for architectural knowledge management. These are codification, personalization or a hybrid approach [S26]. Cross-site delegation, on-site visits, face to face kick-off meetings, collocated high level architecture phase, introduction programmes for new hires, communication, collaboration intensive tools, e-mail lists are some of the ways by which negative effects of various distances on software design phase can be reduced [S24, S26, S28].

DOI:10.1145/2735399.2735408

•

March 2015 Volume 40 Number 2 Frequent design reviews are necessary for optimizing design in GSD [S30].

4.4.3 Coding With the advent of GSD, coding has now become communication, and collaboration intensive activity. Developers have to keep on communicating with their remote colleagues for sharing ideas, knowledge, artifacts, and resolving confusions.

4.4.3.1 Challenges Organizational challenges 1. Clients have little authority to choose vendor developers from remote sites for the project [S27]. 2. Clients are sometimes dissatisfied with the vendor developer’s proficiency and experience level [S27]. 3. Misinterpretation of technical vocabulary due to dissimilarity in technical cultures causes misunderstandings, rework, and consequently delays the project [S27]. 4. Usage of different process and disparity in process maturity at different sites can cause coordination problems [S8, S27]. 5. Staff members at new offshore site have a tendency to not to reply quickly to emails of onshore members [S27]. 6. Lack of domain knowledge in vendor developers, especially if it is their first collaboration [S13]. Geographical challenges

1. Difficult to track information in distributed development [S27, S29].

2. Preparation overhead for all abnormal time meetings. A person should prepare each and every point that is to be discussed in the meeting as after meetings, clarification is very difficult [S29]. 3. Performance evaluation of remote workers is difficult [S29]. 4. Vendor team usually depends on client team for domain knowledge and business logic and keeps on waiting for an explanation or concerned documentation which eventually delays the project. Interruption by vendor to ask some question or discuss about an issue can be considered as disturbance by clients if they have never met with their offshore counterparts [S45]. 5. Rules and regulations regarding work practices can vary from country to country [S8]. 6. Communicating all the details and norms of the process to be followed to remote teams is very time consuming, and reexplanations of several aspects are often needed [S33]. 7. Some of the doubts often remain unresolved, so developers had to work on the basis of assumptions [S45]. Temporal challenges

1. In case of large time zone difference, it is difficult to arrange meetings of all members of the project as there is no such time that is convenient for all the teams [S27, S29]. 2. Frustration and burn out of offshore developers due to extended late working hours to reduce time zone difference [S47]. Socio-cultural challenges

1. Developers at remote site insufficiently use version control system [S24].

2. Differences in engineering approaches of developers of different countries [S27].

3. Differences in national culture can cause difficulties, as Asian team members hesitate to query and agree to the foreign colleagues even when they know they would not be able to complete the task on deadline [S27]. 4. Insufficient social interaction can degrade performance, lowers motivation, and satisfaction of the developer [S29]. 5. Developers belonging to higher economy countries usually do not help developers of low economy due to fear of job loss [S8]. 6. Due to cultural differences, developers often misinterpret each

http://doi.acm.org/10.1145/2735399.2735408

ACM SIGSOFT Software Engineering Notes

Page 7

other’s actions and thus don’t trust each other [S8].

7. Lack of awareness of remote country’s culture (national holidays and festivals) can create tensions among remote colleagues [S8]. Linguistic challenges 1. Client team was not able to communicate clearly about what is to be built and how different modules developed at different sites will work together [S8, S27]. Inadequate communication

•

1. Communication to vendor team only via project manager creates

•

communication bottlenecks and leads to frustration in client organization and delay of the project [S27]. 2. Intensity and effectiveness of synchronous communication decreases due to linguistic, socio-cultural, temporal, and geographical distance and thus, resolution of problems may take more time [S8]. 3. Developers are unaware of the relevant persons at remote site who can clear their doubts. Due to lack of awareness and reduced synchronous communication, it becomes difficult to coordinate work at different sites [S8]. 4. Lack of team cohesiveness due to reduced informal, face to face conversation [S8]. Technical challenges

• • •

•

1. Inadequate hardware configuration, especially connection speed at remote site [S27]. 2. Divergence in tool usage among different teams causes coordination problems [S8]. Process challenges

1. Delay in the development of one of the dependent modules lead to wastage of time and frustration in developers at other site waiting for the module [S27]. 2. Inadequate experience of developers in the domain of the project and lack of effective documentation can delay or even fail the project [S27]. 3. Over and unplanned communication distracts developers from their regular work [S8, S29]. 4. Developers often have to resolve requirement issues that were not resolved during analysis and design [S13].

4.4.3.2 Best practices •

• • • • • • •

UML analysis models, conveying foundation classes to be used, with other ways of communication mechanism such as phone calls, monthly visits to offshore site by manager to keep the visibility of the project, reduces ambiguity, proved effective in communicating what actually is desired from offshore team and have improved the quality of the product [S8, S27]. Face to face contact is necessary to remove cultural misunderstandings, increases trust, and improves relationships [S27]. To increase the trust of client, vendor team developers should acquire additional certifications which can prove their expertise [S29] It is easy to work with people whom we have already worked. So, it is good and profitable for both client and vendor to have long lasting collaboration [S27]. It would be beneficial for vendor team to acquire knowledge about their client’s proprietary infrastructure, services, products, and technology [S27]. Contracting organization should carefully scrutinize the resumes of vendor team developers to judge their experience, skills, and domain knowledge [S27]. Clients should verify several times that whether the vendor really understands what is to be built [S27]. Effective and vigilant project management is required by client’s project manager. S/he should specify elaborated milestones,

DOI:10.1145/2735399.2735408

• •

• •

• • • • •

• • • •

March 2015 Volume 40 Number 2 deliverables, and metrics and vendor team developers should directly report their status to him/ her daily and manager should check their progress [S27, S29]. To reduce the pain of “awkward time meetings”, global meetings should be scheduled only when it is too essential [S29]. Minor issues can be solved asynchronously [S8, S29]. Roles and responsibilities should be unambiguously allotted to all project participants. Everyone in the project should know about the responsibilities of all persons [S27]. Project participants should respond quickly to every communication from other side. Communication should be planned, continuously examined, and adapted according to the situation in order to avoid communication bottlenecks [S8, S27, S29]. Decision making can be pushed to lower levels to save time and effort [S27]. Setting up a photo gallery of project members help developers to know about their remote counterparts, and therefore increases collaboration [S27]. Communication tools like chat, IM, wikis, and discussion boards; collaboration mechanisms like face to face kick offs, liaisons; coordination mechanisms like status meetings, technical reviews can be used to diminish effect of distances [S27, S36]. A single virtual site should be set up that maintains single branch of code with the communication tools like chat, IM, wikis, and discussion boards; collaboration mechanisms like face to face kick offs, liaisons; coordination mechanisms like status meetings, technical reviews can be used to diminish effect of distances with the help of tools, should have build capabilities at both sides, share change management system. Builds should be frequent to ease error debugging [S27]. Onshore team should support and help offshore team members to learn their processes, culture, ways, and technology especially in the beginning of the project [S27]. Tailored collocated training to remote colleagues should be provided to train them for new technology of the project as well as to make them familiar with their onshore colleagues. This practice will decrease the need of coordination; increases trust and relationship, and thus enhances communication between onshore and offshore staff [S28]. Onshore manager visit will improve project monitoring and visibility of the project [S28]. Cross-site delegation will improve communication as the delegate behaves as a mediator between onshore and offshore site for information exchange. This practice will increase pace of the project [S8, S28]. Incentive scheme can implemented to motivate developers who can efficiently work in distributed environment [S29]. Vendors usually adjust working hours according to the client to reduce time zone difference [S8, S29]. A common knowledge and vocabulary repository, weekly newsletters as well as document management system can increase the awareness [S29]. Developers should be aware of cultural differences and should respect each other culture [S8, S29]. Developers can use instant messenger, emails, and chat to indicate their virtual availability and accessibility continuously. Emails can also act as communication trails of past discussions and decisions [S29]. Well defined processes should be used during development [S29]. Adequate technical compatibility and support is necessary for fast delivery [S8, S29]. Decisions should be clear and unbiased and should focus on the success of the project [S29]. Knowledge management tools can be used to find an expert when needed [S29].

http://doi.acm.org/10.1145/2735399.2735408

ACM SIGSOFT Software Engineering Notes • •

• • •

Page 8

Managers can distribute meeting agenda, a day before the meeting, to all the participants, so that they can prepare for it [S8, S29]. Performance evaluation of remote workers can be done by assigning them clearly separated tasks and verifying how much they have done. Feedback from customer can also be used for performance evaluation [S29]. Necessary infrastructure at each site should be developed for GSD [S8]. Updated and precise documentation should be provided to remote development sites [S8]. Accurate interpretation of product requirements and clear domain knowledge of the customer site is necessary to build correct product [S27].

4.4.4 Testing Testing is the second largest outsourced activity in SDLC, after coding. It is growing at an annual rate of over 20% [S39].

4.4.4.1 Challenges Organizational challenges 1. Customers feel insecure to distribute their real-life data to other organizations. Significant overhead would be imposed on testers, if they have to generate mock database for testing. Mock database may be unable to characterize the complexities and intricacies present in real-life data [S1]. 2. Developers carry out insufficient unit testing, especially when the code is to be delivered to third party for testing by a fixed date. Such practices waste testing organization resources in detecting shallow bugs instead of more subtle bugs [S38]. 3. It is hard to spot the developer of the code where bug was found and to reproduce the bug without assembling the test bed [S38]. 4. Clients and vendors assess productivity differently. Clients measure the productivity in terms of numbers such as number of test cases written. On the other hand, vendor measure it in amount of task completed as requested by the client [S39]. 5. Negligence of clients regarding crucial concerns such as the complexity of tests to be performed resulted in intensification of issues or quality compromises in testing [S39]. 6. Testers are treated as “second class citizens”. Their stressful job was seldom appreciated and motivated [S39]. 7. Testers rarely have authority to take decisions [S39]. 8. High staff turnover in offshore countries can induce problems such as retraining of staff, relocation of work, and amplified workload on onsite members [S34]. 9. Test engineers in vendor countries are not familiar with client’s testing tools and code which is to be tested [S40]. Geographical challenges 1. Face-to-face meetings and difficult and expensive [S34]. 2. Reduced awareness of work due to lack of informal contact and geographical dispersion [S34]. 3. Modules that are developed at different locations face difficulties during integration [S37]. 4. Due to frequent misinterpretation of requirements and interface specifications, confusions and misunderstandings occur among developers regarding modules being developed at different sites. These inconsistencies are not exposed until integration testing where they prove to be very costly [S1, S3]. 5. During acceptance testing, indirect transfer of customer feedback to the developers may cause some vital information to be lost, inadequately documented. Lack of contextual information can decrease the comprehensiveness of the findings. Hence, satisfaction of customer is jeopardized [S41]. Temporal challenges 1. Lots of communication problems exist due to temporal difference [S34]. 2. Unavailability of remote developers for discussion about identified defects causes delay [S36].

DOI:10.1145/2735399.2735408

March 2015 Volume 40 Number 2

3. Test engineers face difficulty in gathering additional data or clarifications for creating test environments from remote colleagues due to time zone difference [S36]. Socio-cultural challenges 1. Knowledge transfer to offsite team often takes much more time than expected [S34]. 2. Due to fear of losing jobs, onshore team members are not interested in sharing the knowledge with the low salaried competitive offshore counterparts [S34]. 3. Offshore testers don’t get sufficient cooperation from onshore members due to misunderstandings [S34]. 4. Generally, little time and resources are planned and allocated for training and competence transfer to offshore test engineers which causes extra maintenance work at onshore site[S40] . In GSD, it is hard to generate feeling of a team due to scarce informal communication between remote colleagues, unawareness of each other’s culture, and fear. Lack of a team essence lead to “them-and-us culture” [S34]. Linguistic challenges 1. Communication is difficult between onshore and offshore teams due to absence of a common native language and different vocabulary [S36, S40]. Technical Challenges 1. Dissimilar tool infrastructure causes loss of data transfer [S34]. 2. Transfer and maintenance of large production database at remote site is difficult [S1]. 3. Testers have insufficient bandwidth for downloading huge production databases from customer site [S1]. 4. Data replication and remote builds are challenged with networking issues [S40]. 5. Problems related to shipment of hardware and delivery [S40]. Process challenges 1. Improper collection and organization of requirements leads to low quality and conflicting requirements. Requirement specification in the form of informal documentation by customers increases communication overhead [S34]. 2. Lack of proper training and system knowledge among new testers [S34]. 3. Designation of roles and duties were poor [S34]. 4. Divergence between offshore unit testing and onsite integration testing increases due to imprecise interface specification [S37]. 5. Obsolete documentation due to high requirements instability leads to inconsistency in functionalities understanding which finally causes deadlock situations between testing and development teams [S34, S36]. 6. Defects reports were generally too long and lacked suitable description of issue which leads to problems in discussion between tester and developer [S36]. 7. During test execution phase, when the pressure of completing the work before deadline is highest, long and inflexible communication chains of onshore and offshore managers cause delay in decision making [S39]. 8. To save service level agreements from breaching, testers were forced to quick fix the bugs instead of fixing it systematically [S39]. 9. Due to insufficient communication and coordination between development team and testing team, test engineer often misunderstands features as defects and inform them to development team, which increases frustration in both teams [S38]. 10. Cyclic communication exists between software development and testing team [S38].

http://doi.acm.org/10.1145/2735399.2735408

ACM SIGSOFT Software Engineering Notes

Page 9

11. Incorrect understanding of requirements by test team leads to a large number of defects [S13]. Monetary challenges 1. Sometimes license cost of tools could not be roofed by the profit earned by the project [S34]. 2. Limited budget restricts communication, coordination and collaboration mechanisms [S34]. Due to all these reasons, the expected quality and economic advantages of offshoring were not achieved. Instead sometimes, clients have to pay higher cost for low quality and delayed software.

4.4.4.2 Best Practices •

• • • • • • • • • • • • • •

A formal communication protocol should be defined which regulate the structure, ways, and tools of communication which will prevent data loss, reduce coordination effort, and helps in improving the quality of project. A person should be appointed who can act as a link between onshore and offshore testing team to avoid excessive and noisy communication [S37]. Availability of project information with details to all team members will increase awareness [S37, S38]. Careful resource planning for testing phase should be done prior to the phase and should ensure that delay of one activity would not affect other [S40]. Traceability among software artefacts should exist to determine which high level requirements are tested [S38]. Problems introduced due to simultaneous changes in interdependent software artefacts can be resolved by precisely detecting semantic interference between them [S38]. A high level change notification should be generated corresponding to several low level modifications to software and transmit only to appropriate test engineer [S38]. Mining can be applied to predict and detect bugs in the modified code on the basis of historical information about probable problematic modifications [S38]. For regression testing, effective test selection, prioritization, augmentation, and minimization methods in GSD should be developed [S38]. Efficient testing methods that attain larger test coverage quickly can aid to the fast development of reliable software [S38]. Effective communication and rapport building mechanisms with customers will improve the relationship of testing team with customer [S39]. Complex tasks should be interleaved with simple ones to achieve task completion deadline [S39]. Effective training should be given to new testers in the starting of project [S40]. Testers can notify the clients about the incompleteness of information by inserting notes to test-case documents [S39]. Frequent design and code review, testing critical areas can effectively reduce bugs [S42]. Design, build, and test components in short iterations which last for a couple of weeks [S30].

4.4.5 Integration In GSD, integrating components developed at different development sites is quite challenging. It is costly to resolve requirement and design defects when they appear during integration [S1].

4.4.5.1 Challenges

synchronization and integration problems [S1]. 3. Unplanned integration without properly assigning responsibilities and specifying mutual deliveries can delay the project [S7]. 4. Communication between remote sites only through a single mediator can become the cause of integration failure [S43]. 5. Lack of centralized management of integration can induce integration problems [S7]. 6. Defined process doesn’t suit the system type or platform, or organizational setting [S46]. Geographical challenges 1. Probability of integration failure of a feature increases as the number and dispersion of teams working on the feature increases [S27, S44]. 2. Implementing different code branches at each development sites can lead to complex integration problems [S27]. 3. Inadequate knowledge and expertise in GSD of integration team can increase risks of integration failure [S7]. Temporal challenges 1. During integration, multiple time zones cause lots of inconvenience and delay the project, as it is very difficult and slow to constantly acquire information from offshore sites to fix errors and assemble code [S27]. Socio-cultural challenges 1. It is difficult to resolve difficulties with unfamiliar remote participants while integrating the code [S47]. 2. Lack of team cohesiveness and cooperation due to feeling of competition between client and vendor. Integration teams often feel that they are integrating components of competitors [S27]. 3. Lack of compliance of defined process and architecture by developers can lead to integration complexities [S46]. Process challenges 1. Inadequate, incomplete interface specifications and documentation cause misinterpretations and wrong assumptions about other subsystems being developed remotely. These problems surface during final integration [S1]. 2. Lack of careful planning can lead to development of incompatible components which when integrated do not satisfy system resource constraints. Such discrepancy can lead to project failure [S46]. 3. Due to impromptu re-planning during development, the actual components do not match the planned ones which create confusion in integration team [S33]. 4. Low coupling between business strategies and defined processes causes problems in implementation of business strategy using the defined process [S46]. 5. Risk of integration failure increases with the increase in interdependencies between modules to be developed [S30, S33, S46]. 6. Time and effort required for integration is often underestimated [S7].

Rework, delays, low quality, and over budget and even failed projects are the some of the negative outcomes associated with poor integration strategy.

4.4.5.2 Best Practices •

Organizational challenges 1. Inadequate communication and lack of domain knowledge lead to lack of understanding in developers about requirements which often lead to misinterpreted and conflicting modules [S1, S9, S11, S27, S47]. 2. Differences in processes followed at different sites can result in

DOI:10.1145/2735399.2735408

March 2015 Volume 40 Number 2

• •

Repeated discussion on requirements and optimal design can remove any misunderstandings and lead to successful integration [S7]. Plan and monitor mechanisms for intense communication [S1, S27]. Precise, detailed interface and requirements specification documents can reduce misinterpretations and thus, integration errors [S1, S33].

http://doi.acm.org/10.1145/2735399.2735408

ACM SIGSOFT Software Engineering Notes •

• • • • • • • • • • • • • •

Page 10

Continuous monitoring and evolution of architecture is needed. The modifications in design decisions should be precisely and timely informed to remote teams to avoid any confusions and integration risks [S1, S7]. Formal specification languages can be enhanced to describe interface specifications precisely [S1]. The order of integrating the components to produce a working system should be efficiently planned and managed [S5]. Modular approach can decrease interdependencies among components and, consequently integration issues [S30]. During final integration, a person from offshore site should remain present at onshore site to immediately resolve the issues without delay [S27]. Incremental integration and regular deliveries can serve as a mechanism for early feedback and avoid delay and complex integration difficulties [S48]. Mining can be applied to predict and detect bugs in the modified code on the basis of historical information about probable problematic modifications [S38]. For regression testing, effective test selection, prioritization, augmentation, and minimization methods in GSD should be developed [S38]. Efficient testing methods that attain larger test coverage quickly can aid to the fast development of reliable software [S38]. Effective communication and rapport building mechanisms with customers will improve the relationship of testing team with customer [S39]. Complex tasks should be interleaved with simple ones to achieve task completion deadline [S39]. Effective training should be given to new testers in the starting of project [S40]. Testers can notify the clients about the incompleteness of information by inserting notes to test-case documents [S39]. Frequent design and code review, testing critical areas can effectively reduce bugs [S42]. Design, build, and test components in short iterations which last for a couple of weeks [S30].

March 2015 Volume 40 Number 2

Design

eRequirements S51]

[S49,

Rational Requirements Composer [S49, S51]

RationalRequisitePro [S49] Eclipse-based global

• Collaboration among dispersed members • Requirements management • Requirement traceability • Functional and nonfunctional requirements management • Building of use cases • Automatic requirement specification document generator • Collaboratively create requirements • Support advanced searches for managing requirements • Integrated requirements management tool through a web-based environment. • Distributed requirement

DOI:10.1145/2735399.2735408

Gliffy [S49, S51]

• Collaborative modification, organization, and tagging of different types of diagrams. • Draw different types of diagrams such as UML, freestyle. • Discuss diagrams. • Record information in design meetings. • Supports more than one types of diagram, commenting, blog creation, and knowledge management. • Supports distributed modelling, and collaboration. • UML 2.1 based collaboration environment. • Facilitate automatic generation of documents and management of test cases. • Supports integration of requirement modeling with embedded development of application.

Creately [S50]

Sysiphus [S51]

Rational Tau [S51]

GroupUML [S51] ADDSS

Most of the studies have urged the requirement of tools to combat the negative effects of various distances in their suggested solutions. Tools can support communication, coordination, and collaboration processes during GSD life cycle. Phase Tool Activities IBM Rational Doors [S49, S51]

management • Change management • Knowledge management • Awareness, • Informal collaboration

Camel[S49, S51]

4.4.6 Tools

Requirement Engineering

requirements tool (EGRET) [S15]

(Architecture Design Decision Support System) [S51] PAKME [S51]

Coding

CollabVS [S51]

COPPER (COllaborative Pair Programming EditoR) [S51]

Github [S51]

• Provides distributed UML modeling. • Provide requirement traceability • Portray development of architecture and design decisions over time. • Describe architectural constructs using data models. • Distributed software development. • Supports chat. • Keep information about the part of code that is being edited. • Provides Work status of online team member. Allows distributed pair programming. • Keep information about the part of code that is being edited by distributed pair. • Contains a distributed source code repository in

http://doi.acm.org/10.1145/2735399.2735408

ACM SIGSOFT Software Engineering Notes

which developers can insert comments. • Provides facility of prerolled post commit hooks. • Web tool containing a central repository.

Google Code [S51]

TUKAN [S51] GForge [S51] Testing

TestLink S51]

Mantis [S37]

[S37,

Bug

S50,

Tracker

FireScrum [S37]

Subversion[S37]

Selenium [S37, S50, S51] OpenSTA [S50]

Integration

Hudson [S49, S51]

Merlin [S49, S51]

Page 11

ToolChain

• Supports distributed extreme programming. • Collaborative source code management tool • Administration of test plans. • Creation of test cases. • Generation of tests execution reports. • Management of defect lifecycle. • Task detailing of sprints. • Measurement and updating task progress. • Information sharing and management among test engineers. • Automation of web application testing on various platforms. • Distributed softwaretesting architecture used for heavy load tests and performance measurement. • Web-based, continuous integration system. • Build and continuously test software projects. • Monitor executions of externally run jobs. • Provide Integration of different management tools pertaining to project, requirements, configuration, and testing.

5. FINAL CONSIDERATIONS 5.1 Discussion about Results • • •

•

The year wise distribution of studies discloses that the interest in investigating life cycle activities of GSD has significantly increased since 2005. The research type distribution of studies (case studies: 45% and industrial experience reports: 17%) unveils the curiosity of researchers as well as practitioners in exploring GSD life cycle. Integration is a challenging phase in GSD, but few challenges are found for integration phase. This shows that a little attention is given to this phase. There is a need to study the challenges associated with integration. In design phase, we have not found any challenges due to organizational distances. This shows the lack of studies that have discussed the impact of organizational distances on design phase. Thus, there is a need to explore the challenges associated with design phase due to organizational distance.

DOI:10.1145/2735399.2735408

• •

March 2015 Volume 40 Number 2 Most of the research on design phase has focussed solely on architecture of GSD. This depicts that there is a need to explore the impact of various distances on other aspects of design phase. Problems due to ‘Obsolete documentation’ and ‘process mismatch among remote sites’ have been discussed in most of the phases. This illustrates that these are the problems that have been faced by team members during entire development cycle.

5.2 Success Factors •

•

• •

• •

• • • • •

Entire project team should have a unified understanding of the entire product that they have to produce. They should have a clear view of requirements, rationale behind requirement changes, architecture, and interface specifications. Roles and responsibilities should be precisely defined and announced in the starting of the project. Mechanism should be implemented to aware all the project participants about the role and responsibilities of other people working on the projects. Any changes in the architecture, requirements, design, interfaces should be propagated to the affected stakeholders timely. Associated documentation should also be timely updated. Communication and coordination mechanisms should be planned at the start of the project. They should be continuously monitored by project managers and should be adapted according to the situation. Lateral communication should be emphasized. Tools that support global software development should be extensively used. Each and every site should follow a single set of processes, tools, and methodologies. All the teams should be informed and trained for the processes and tools to be used. Compliance of process with actual working should be monitored by project managers to avoid rework, delays, and defects. Architecture should be used as a coordination tool. A central artefact repository can be established that stores all artefacts related to the project. There should be language and culture trainings in the start of the project to avoid confusions, misinterpretations, and misunderstandings. Metrics for evaluating performance of each phase should be developed. Trust should be established by respecting each other culture. Crosssite delegation, setting up liaisons, collocated starting of the project are some of the ways to reduce the gap between different sites. Client and vendor both should work strategically and collaboratively towards the success of the project.

5.3 Conclusion GSD has dominated the software development paradigm across the world. In this paper, we have performed systematic literature review to extract the challenges faced by GSD teams during different phases of software development. We have also discussed the best practices for various phases as suggested in the selected studies. A brief overview of software development tools used in GSD is also presented. The results obtained from this SLR can be useful for researchers and practitioners. The results of this SLR provide a comprehensive list of challenges and best practices of GSD life cycle to researchers. It would help researchers to find new research opportunities in GSD process domain. Practitioners can apply these results in their development practices.

6. REFRENCES [1]

Ågerfalk, P.J., Fitzgerald, B., Holmström, H., Lings, B., Lundell, B., Conchúir, E.Ó. 2005. A framework for considering opportunities and threats in distributed software development. In Proceedings of the International Workshop on Distributed Software Development (Paris, August, 2005). 29, Austrian Computer Society, 47–61.

http://doi.acm.org/10.1145/2735399.2735408

ACM SIGSOFT Software Engineering Notes [2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

Page 12

Ågerfalk, P.J., Fitzgerald, B., Olsson, H.H., and Ó Conchúir, E. 2008. Benefits of global software development: the known and unknown. In Proceedings of the Software process, 2008 international conference on making globally distributed software development a success story (ICSP'08), Qing Wang, Dietmar Pfahl, and David M. Raffo (Eds.). Springer-Verlag, Berlin, Heidelberg, 1-9. Ågerfalk, P. J., and Fitzgerald, B. 2006. Flexible and Distributed Software Processes: Old Petunias in New Bowls? Commun. ACM. 49, 10(Oct 2006). 26-34. Ó Conchúir, E., Ågerfalk, P.J., Olsson, H.H., and Fitzgerald, B. 2009. Global software development: where are the benefits? Commun. ACM. 52, 8 (August 2009), 127-131. DOI=http://doi.acm.org/10.1145/1536616.1536648. Atkins, D., Handel, M., Herbsleb, J., Mockus, A., Perry, D., Wills, G. 2001. Global Software Development: The Bell Labs Collaboratory. In Proceedings of the International Conference on Software Engineering (Toronto, Canada, May 15-18, 2001). 681. Betz, S., Makio, J., Stephan, R. 2007. Offshoring of Software Development - Methods and Tools for Risk Management. In proceedings of the SecondIEEEInternational Conference on Global Software Engineering (August27-30, 2007). 280281.DOI=http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arn umber=4299865&isnumber=4299826. Casey, V. 2011. Imparting the importance of culture to global software development. ACM Inroads 1, 3 (September, 2011), 51-57. DOI=http://doi.acm.org/10.1145/1835428.1835443. Damian, D., and Moitra, D. 2006. Guest Editors' Introduction: Global Software Development: How Far Have We Come? IEEE Softw. 23, 5 (September, 2006), 17-19. DOI=http://dx.doi.org/10.1109/MS.2006.126. Ebert, C. 2006. Road Blocks and Enablers for Global Software Engineering Projects. In Proceedings of the International Conference on Global Software Engineering (October 2006).29. Galviņa, Z., Smite, D. 2011. Software Development Processes in Globally Distributed Environment. Scientific Papers. 770 (2011), University of Latvia. Gomes, V., Marczak, S., 2012. Problems? We All Know We Have Them. Do We Have Solutions Too? A Literature Review on Problems and Their Solutions in Global Software Development. In Proceedings of the International Conference on Global Software Engineering (August 27-30, 2012). 154158. DOI= http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=63 37353&isnumber=6337293. Gopal, A., Mukhopadhyay, T., and Krishnan, M.S. 2002. The role of software processes and communication in offshore software development. Commun. ACM 45, 4 (April, 2002), 193-200. DOI=http://doi.acm.org/10.1145/505248.506008. Gumm, D.C. 2006. Distribution Dimensions in Software Development Projects: A Taxonomy. IEEE Softw. 23, 5 (September, 2006). 45-51. DOI=http://dx.doi.org/10.1109/MS.2006.122. Herbsleb, J. D., and Moitra, D.2001. Global software development. IEEE Software (March-April, 2001) 1620. Jaakkola, H., Heimbürger, A., and Linna, P. 2010. Knowledge-oriented software engineering process in a multicultural context. Software Quality Control 18, 2 (June, 2010). 299-319. DOI= http://dx.doi.org/10.1007/s11219-009-9091-x. Jiménez, M., Piattini, M., and Vizcaíno, A. 2009. Challenges and improvements in distributed software development: a systematic review. Adv. Soft. Eng. 2009, Article 3 (January, 2009). DOI=http://dx.doi.org/10.1155/2009/710971.

DOI:10.1145/2735399.2735408

[17]

[18]

[19] [20]

March 2015 Volume 40 Number 2 Kitchenham, B., and Charters, S. 2007. Guidelines for performing Systematic Literature Reviews in Software Engineering. Vol 2.3 EBSE Technical Report, EBSE-200701. Software Engineering Group, School of Computer Science and Mathematics, Keele University, Keele, UK. Lopez, A., Carrillo-de-Gea, J.M., Toval, A. 2009. Risks and Safeguards for the Requirements Engineering Process in Global Software Development. In Proceedings of the 2009 Fourth IEEE International Conference on Global Software Engineering (ICGSE '09). IEEE Computer Society, Washington, DC, USA, 394-399. DOI=http://dx.doi.org/10.1109/ICGSE.2009.62. Pressman, R. S. 2010. Software engineering A Practitioner’s approach. Ed.7. Mc Graw Hill, 2010. Setamanit, S., Wakeland, W., and Raffo, D. 2006. Planning and improving global software development process using simulation. In Proceedings of the 2006 International workshop on Global software development for the practitioner (GSD '06). ACM, New York, NY, USA, 8-14. DOI= http://doi.acm.org/10.1145/1138506.1138510.

Appendix: List of Primary Studies included in the Review [S1]

[S2]

[S3]

[S4]

[S5]

[S6]

[S7]

[S8]

[S9]

Sengupta, B., Chandra, S., and Sinha, V. 2006. A research agenda for distributed software development. In Proceedings of the 28th international conference on Software engineering (2006). ACM, New York, NY, USA, 731-740. DOI=http://doi.acm.org/10.1145/1134285.1134402. Herbsleb, J.D., Mockus, A., Finholt, T.A., and Grinter, R.E., 2001. An empirical study of global software development: distance and speed. In Proceedings of the 23rd International Conference on Software Engineering (2001). IEEE Computer Society, Washington, DC, USA, 81-90. Herbsleb, J.D. 2007. Global Software Engineering: The Future of Socio-technical Coordination. In Future of Software Engineering (2007). IEEE Computer Society, Washington, DC, USA, 188-198. DOI=http://dx.doi.org/10.1109/FOSE.2007.11. Lings, B., Lundell, B., Agerfalk P., and Fitzgerald, B. 2006. Ten strategies for successful distributed development. INT FED INFO PROC. Springer. (2006)119-137. Ovaska, P., Rossi, M. and Marttiin, P. (2003). Architecture as a coordination tool in multi-site software development. Softw. Process: Improve. Pract. 8(2003) 233–247. DOI= 10.1002/spip.186. Clerc, V., Lago, P., van Vliet, H. 2007. Assessing a Multi-Site Development Organization for Architectural Compliance. In Proceedings of the Sixth Working IEEE/IFIP Conference on Software Architecture (January, 2007). IEEE Computer Society, Washington, DC, USA, 10-. DOI=http://dx.doi.org/10.1109/WICSA.2007.16. Kommeren, R., and Parviainen, P. 2007. Philips experiences in global distributed software development. Empir. Softw. Eng. 12, 6 (December, 2007), 647660. DOI=http://dx.doi.org/10.1007/s10664-007-9047-3. Bird, C., Nagappan, N., Devanbu, P., Gall, H., and Murphy, B. 2009. Does distributed development affect software quality? An empirical case study of Windows Vista. In Proceedings of the 31st International Conference on Software Engineering (ICSE '09). IEEE Computer Society, Washington, DC, USA, 518-528. DOI=http://dx.doi.org/10.1109/ICSE.2009.5070550. Damian, D. and Zowghi, D. 2003. RE challenges in multi-site software development organisations. Requirements Engineering, 8, 3(22 July, 2003). Springer-Verlag London Limited, 149–160.DOI= 10.1007/s00766-003-0173-1

http://doi.acm.org/10.1145/2735399.2735408

ACM SIGSOFT Software Engineering Notes [S10]

Page 13

Niazi, M., El-Attar, M., Usma, M., and Ikram, N. 2012. GlobReq: A framework for improving requirements engineering in global software development projects: Preliminary results. In proceedings of the 16th International Conference on Evaluation & Assessment in Software Engineering (EASE 2012). (May 14-15, 2012) 166-170.

[S11]

Bhat, J.M., Gupta, M., Murthy, S.N. 2006. Overcoming Requirements Engineering Challenges: Lessons from Offshore Outsourcing. IEEE Softw. 23, 5 (September 2006), 38-44. DOI=http://dx.doi.org/10.1109/MS.2006.137.

[S12]

Hashmi, S. I., Ishikawa, F., and Richardson, I. 2013. A communication process for global requirements engineering. In Proceedings of the 2013 International Conference on Software and System Process (ICSSP 2013). ACM, New York, NY, USA, 136-140. DOI=http://doi.acm.org/10.1145/2486046.2486070. Berenbach, B. 2006. Impact of organizational structure on distributed requirements engineering processes: lessons learned. In Proceedings of the 2006 international workshop on Global software development for the practitioner (GSD '06). ACM, New York, NY, USA, 15-19. DOI=http://doi.acm.org/10.1145/1138506.1138511. Salger, F., Englert, J., Engels, G. 2010. Towards Specification Patterns for Global Software Development Projects Experiences from the Industry. In Proceedings of the 2010 Seventh International Conference on the Quality of Information and Communications Technology (QUATIC '10). IEEE Computer Society, Washington, DC, USA, 73-78. DOI=http://dx.doi.org/10.1109/QUATIC.2010.12 Damian, D. 2007. Stakeholders in Global Requirements Engineering: Lessons Learned from Practice. IEEE Softw. 24, 2 (March, 2007), 21-27. DOI=http://dx.doi.org/10.1109/MS.2007.55. Damian, D. 2006. Requirements Engineering in Distributed Projects. In Proceedings of the IEEE international conference on Global Software Engineering (ICGSE '06). IEEE Computer Society, Washington, DC, USA, 69-. Duarte, D., Farinha, C., da Silva, M.M., da Silva, A.R. 2012. Collaborative Requirements Elicitation with Visualization Techniques. In Proceedings of the 2012 IEEE 21st International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE '12). IEEE Computer Society, Washington, DC, USA, 343-348. DOI=http://dx.doi.org/10.1109/WETICE.2012.14. Berenbach, B., and Gall, M. 2006. Toward a Unified Model for Requirements Engineering. In Proceedings of the IEEE international conference on Global Software Engineering (ICGSE '06). IEEE Computer Society, Washington, DC, USA, 237-238. Khan, A.A., Basri, S., Dominic, P. D. D. 2012. A propose framework for requirement Change Management in Global Software Development. In Proceedings of the international conference on Computer & Information Science. 2(June 1214,2012). 944-947. DOI=http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumb er=6297161&isnumber=6297086. Alnuem, M.A., Ahmad, A., and Khan, H. 2012. Requirements Understanding: A Challenge in Global Software Development, Industrial Surveys in Kingdom of Saudi Arabia. In Proceedings of the 2012 IEEE 36th Annual Computer Software and Applications Conference (COMPSAC '12). IEEE Computer Society, Washington, DC, USA, 297-306. DOI=http://dx.doi.org/10.1109/COMPSAC.2012.41. Aranda, G.N., Vizcaíno, A., and Piattini, M. 2010. A framework to improve communication during the requirements elicitation process in GSD projects. Requir.

[S13]

[S14]

[S15]

[S16]

[S17]

[S18]

[S19]

[S20]

[S21]

DOI:10.1145/2735399.2735408

March 2015 Volume 40 Number 2

[S22]

[S23]

[S24]

[S25]

[S26]

[S27]

[S28]

[S29]

[S30]

[S31]

[S32]

[S33]

Eng.15, 4 (November, 2010), 397-417. DOI=http://dx.doi.org/10.1007/s00766-010-0105-9. Lopes, L., Prikladnicki, R., Audy, J.L.N., Majdenbaum, A. 2005. Requirements Specification in Distributed Software Development - A Process Proposal. In Proceedings of the 38th Hawaii International Conference on System Sciences(Hawaii, USA. 2005). Damian, D.E., and Zowghi, D. 2003. An Insight into the Interplay between Culture, Conflict and Distance in Globally Distributed Requirements Negotiations. In Proceedings of the 36th Annual Hawaii International Conference on System Sciences (HICSS'03) - Track1 - Volume 1 (HICSS '03), Vol. 1. IEEE Computer Society, Washington, DC, USA, 19.3-. Cataldo, M., Bass, M., Herbsleb, J.D., Bass, L. 2007. On Coordination Mechanisms in Global Software Development. In Proceedings of the International Conference on Global Software Engineering (ICGSE '07). IEEE Computer Society, Washington, DC, USA, 71-80. DOI=http://dx.doi.org/10.1109/ICGSE.2007.33. Boden, A., Nett, B., and Wulf, V. 2007. Coordination Practices in Distributed Software Development of Small Enterprises. In Proceedings of the International Conference on Global Software Engineering (ICGSE '07). IEEE Computer Society, Washington, DC, USA, 235-246. DOI= http://dx.doi.org/10.1109/ICGSE.2007.18. Clerc, V. 2008. Towards architectural knowledge management practices for global software development. In Proceedings of the 3rd international workshop on Sharing and reusing architectural knowledge (SHARK '08). ACM, New York, NY, USA, 23-28. DOI=http://doi.acm.org/10.1145/1370062.1370068. Herbsleb, J.D. Paulish, D.J. and Bass, M. 2005. Global software development at siemens: experience from nine projects. In Proceedings of the 27th international conference on Software engineering (ICSE '05). ACM, New York, NY, USA, 524-533. DOI= http://doi.acm.org/10.1145/1062455.1062550. Lescher, C. 2010. Patterns for global development: how to build one global team? In Proceedings of the 15th European Conference on Pattern Languages of Programs (EuroPLoP '10). ACM, New York, NY, USA. DOI=http://doi.acm.org/10.1145/2328909.2328917. Koehne, B., Shih, P.C., and Olson, J.S. 2012. Remote and alone: coping with being the remote member on the team. In Proceedings of the ACM 2012 conference on Computer Supported Cooperative Work (CSCW '12). ACM, New York, NY, USA, 1257-1266. DOI=http://doi.acm.org/10.1145/2145204.2145393. Cusumano, M.A. 2008. Managing software development in globally distributed teams. Commun. ACM 51, 2 (February, 2008), 15-17. DOI=http://doi.acm.org/10.1145/1314215.1314218. Cataldo, M. 2010. Sources of errors in distributed development projects: implications for collaborative tools. In Proceedings of the 2010 ACM conference on Computer supported cooperative work (CSCW '10). ACM, New York, NY, USA, 281-290. DOI=http://doi.acm.org/10.1145/1718918.1718971. Tekinerdogan, B. Cetin, S., Babar, M.A., Lago, P., and Mäkiö, J. 2012. Architecting in global software engineering. SIGSOFT Softw. Eng. Notes. 37, 1 (January, 2012), 1-7. DOI=http://doi.acm.org/10.1145/2088883.2088900. Mullick, N., Bass, M., Houda, Z., Paulish, P., and Cataldo, M. 2006. Siemens Global Studio Project: Experiences Adopting an Integrated GSD Infrastructure. In Proceedings of the IEEE international conference on Global Software

http://doi.acm.org/10.1145/2735399.2735408

ACM SIGSOFT Software Engineering Notes

[S34]

[S35]

[S36]

[S37]

[S38]

[S39]

[S40]

[S41]

Page 14

Engineering (ICGSE '06). IEEE Computer Society, Washington, DC, USA, 203-212. Tervonen, I., Haapalahti, A., Harjumaa, L., Simila, J. 2013. Outsourcing Software Testing: A Case Study in the Oulu Area. In Proceedings of the 2013 13th International Conference on Quality Software (QSIC '13). IEEE Computer Society, Washington, DC, USA, 65-74. DOI=http://dx.doi.org/10.1109/QSIC.2013.53. Munkvold, B.E., and Zigurs, I. 2007. Process and technology challenges in swift-starting virtual teams. Inf. Manage. 44, 3 (April, 2007). 287-299. DOI=http://dx.doi.org/10.1016/j.im.2007.01.002. Camacho, C., Marczak, S., and Conte, T. 2013. On the Identification of Best Practices for Improving the Efficiency of Testing Activities in Distributed Software Projects: Preliminary Findings from an Empirical Study. In Proceedings of the 2013 IEEE 8th International Conference on Global Software Engineering Workshops (ICGSEW '13). IEEE Computer Society, Washington, DC, USA, 1-4. DOI=http://dx.doi.org/10.1109/ICGSEW.2013.7. Collins, E., Macedo, G., Maia, N., Dias-Neto, A. 2012. An Industrial Experience on the Application of Distributed Testing in an Agile Software Development Environment. In Proceedings of the 2012 IEEE Seventh International Conference on Global Software Engineering (ICGSE '12). IEEE Computer Society, Washington, DC, USA, 190-194. DOI=http://dx.doi.org/10.1109/ICGSE.2012.40 Grechanik,M., Jones, J.A., Orso, A., and van der Hoek,A.2010. Bridging gaps between developers and testers in globally-distributed software development. In Proceedings of the FSE/SDP workshop on Future of software engineering research (FoSER '10). ACM, New York, NY, USA, 149-154. DOI=http://doi.acm.org/10.1145/1882362.1882394. Shah, H., Sinha, S., Harrold, M.J. 2011. Outsourced, Offshored Software-Testing Practice: Vendor-Side Experiences. In Proceedings of the 2011 IEEE Sixth International Conference on Global Software Engineering (ICGSE '11). IEEE Computer Society, Washington, DC, USA, 131-140. DOI=http://dx.doi.org/10.1109/ICGSE.2011.32. Tervonen, I., Mustonen, T. 2009. Offshoring Test Automation: Observations and Lessons Learned. In Proceedings of the 2009 Fourth IEEE International Conference on Global Software Engineering (ICGSE '09). IEEE Computer Society, Washington, DC, USA, 226-235. DOI=http://dx.doi.org/10.1109/ICGSE.2009.30. Liskin, O., Herrmann, C., Knauss, E., Kurpick, T., Rumpe, B., and Schneider, K. 2012. Supporting Acceptance Testing in Distributed Software Projects with Integrated Feedback Systems: Experiences and Requirements. In Proceedings of the 2012 IEEE Seventh International Conference on Global Software Engineering (ICGSE '12). IEEE Computer Society, Washington, DC, USA, 84-93. DOI=http://dx.doi.org/10.1109/ICGSE.2012.34.

DOI:10.1145/2735399.2735408

[S42]

[S43]

[S44]

[S45]

[S46]

[S47]

[S48]

[S49]

[S50]

[S51]

March 2015 Volume 40 Number 2 Ebert,C., Parro, C.H., Suttels, R., and Kolarczyk, H. 2001. Improving Validation Activities in a Global Software Development. In Proceedings of the 10th International Workshop on New Approaches in Software Measurement (IWSM '00), Reiner R. Dumke and Alain Abran (Eds.). Springer-Verlag, London, UK, 83-93. Čavrak, I., Orlić, M., and Crnković, I. 2012. Collaboration patterns in distributed software development projects. In Proceedings of the 34th International Conference on Software Engineering (ICSE '12). IEEE Press, Piscataway, NJ, USA, 1235-1244. Cataldo, M., Herbsleb, J.D. 2011. Factors leading to integration failures in global feature-oriented development: an empirical analysis. In Proceedings of the 33rd International Conference on Software Engineering (ICSE '11). ACM, New York, NY, USA, 161-170. DOI=http://doi.acm.org/10.1145/1985793.1985816. Gotel, O., Kulkarni, V., Scharff, C., Neak, L. 2008. Integration Starts on Day One in Global Software Development Projects. In Proceedings of the 2008 IEEE International Conference on Global Software Engineering (ICGSE '08). IEEE Computer Society, Washington, DC, USA, 244-248. DOI=http://dx.doi.org/10.1109/ICGSE.2008.10. Bosch, J., and Bosch-Sijtsema, P. 2010. From integration to composition: On the impact of software product lines, global development and ecosystems. J. Syst. Softw. 83, 1 (January 2010), 67-76. DOI=http://dx.doi.org/10.1016/j.jss.2009.06.051. Ó Conchúir, E., Holmström, H., Ågerfalk, P.J. and Fitzgerald, B. 2006. Exploring the Assumed Benefits of Global Software Development. In Proceedings of the IEEE international conference on Global Software Engineering (ICGSE '06). IEEE Computer Society, Washington, DC, USA, 159-168. Paasivaara, M., and Lassenius, C. 2006. Could Global Software Development Benefit from Agile Methods? In Proceedings of the IEEE international conference on Global Software Engineering (ICGSE '06). IEEE Computer Society, Washington, DC, USA, 109-113. Rodríguez, J.P., Ebert, C., Vizcaino, A. 2010. Technologies and Tools for Distributed Teams. IEEE Software27, 5 Sept.(October, 2010), 10-14.DOI = http://doi.ieeecomputersociety.org/10.1109/MS.2010.126. Lanubile, F., Ebert, C., Prikladnicki, R., and Vizcaíno, A. 2010. Collaboration Tools for Global Software Engineering. IEEE Softw. 27, 2 (March 2010), 52-55. DOI=http://dx.doi.org/10.1109/MS.2010.39. Rodríguez, J.P., Vizcaino, A., Ebert, C., and Piattini, M. 2010. Tools to Support Global Software Development Processes: A Survey. In proceedings of the IEEE International Conference on Global Software Engineering(ICGSE '10). IEEE Computer Society, Washington, DC, USA. DOI= 10.1109/ICGSE.2010.12. 1322.

http://doi.acm.org/10.1145/2735399.2735408