Вы находитесь на странице: 1из 11

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220773173

Software Configuration Management in Global Software Development: A


Systematic Map

Conference Paper · November 2010


DOI: 10.1109/APSEC.2010.53 · Source: DBLP

CITATIONS READS
26 959

3 authors, including:

Shukor Sanim Mohd Fauzi Paul L. Bannerman


Universiti Teknologi MARA The Commonwealth Scientific and Industrial Research Organisation
23 PUBLICATIONS   108 CITATIONS    33 PUBLICATIONS   671 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Architecting with Blockchain View project

Halal Food Tracking and verification View project

All content following this page was uploaded by Paul L. Bannerman on 22 May 2014.

The user has requested enhancement of the downloaded file.


2010 Asia Pacific Software Engineering Conference

Software Configuration Management in Global


Software Development: A Systematic Map

Shukor Sanim Mohd Fauzi1,2,3 Paul L Bannerman2,3 Mark Staples2,3

(1) Faculty of Computer and (2) NICTA (3) School of Computer Science
Mathematical Sciences, 13 Garden St, Eveleigh, and Engineering,
Universiti Teknologi Mara, NSW 2015, Australia University of NSW,
Malaysia {shukorsanimbinmohd.fauzi, NSW 2052, Australia
paul.bannerman, mark.staples}
@nicta.com.au

However, GSD also presents many issues, caused by


Abstract—Many companies use Global Software Development temporal distance, geographic distance and socio-cultural
(GSD) to access skilled people, reduce costs and utilize around distance. This affects communication, coordination and
the clock development. GSD has numerous social and technical control in projects [9]. GSD challenges have been classified as
difficulties, but most literature only examines social difficulties. non-technical, technical and hybrid [9]. Technical factors
Few studies concern technical difficulties or address Software relate to technical knowledge used in software development
Configuration Management (SCM) issues. SCM is widely used,
[10]; non-technical challenges relate to social and cultural
and supports the infrastructure and practices that enable change
management and version control. SCM has potential to support factors [7] [10], language [10-12], communication [13], and
more effective GSD, but is more difficult in GSD, because time zone differences [14]; and hybrid factors are challenges
coordination and synchronization are more complex. This paper that relate to a combination of technical and non-technical
presents our findings of a systematic mapping study of SCM in knowledge. Challenges have been identified in GSD for
GSD. Systematic mapping is a methodology to discover and process areas such as Software Configuration Management
categorize research on a topic, and can be used to identify (SCM) [5] [15] [16], Risk Management [16] [17], Project
common themes and areas requiring further study. We find most Management [18], and Validation and Verification [19].
research on SCM in GSD has used case studies, and there has Substantial attention has been given to non-technical issues
been little empirical validation. The lack of coordination and
such as managing cultural diversity [20], different time-zones
group awareness causes difficulties for SCM in GSD, but no SCM
process has been proposed to address this. More research is [6], trust [21], distance [22-25], and social-cultural and
required on Software Configuration Control for GSD. geographical differences [26]. However, in GSD research less
attention has been given to technical areas such as SCM. The
Keywords–Global Software Development, Software purpose of this paper is to present a systematic mapping study
Configuration Management, Configuration Management, of the literature to identify the SCM issues faced by GSD
Distributed Software Development, Systematic Map projects, and the solutions used for each issue. The map is
intended to inform both practice and research on SCM issues
I. INTRODUCTION
that arise in the GSD environment.
Global Software Development (GSD) has attracted The paper is organized as follows. We first describe the
widespread attention and has had a significant impact on systematic mapping methodology and its use in this study.
software development. It has extended software development Next, we present the results of our study: maps of the issues
beyond collocated environments to geographically dispersed and the solutions identified from this literature. Finally, we
locations. Many large companies have adopted GSD [1] [2] present conclusions and opportunities for future work.
[3], and GSD has also had a positive impact on the economies
of many countries as development hubs or centers for GSD II. THE SYSTEMATIC MAPPING PROCESS
projects [4]. In GSD, the software development, project team A systematic mapping study (SMS) is “a defined method
and resources are dispersed across sites located in two or more to build a classification scheme and structure a software
different countries (and even continents) [5], usually separated engineering field of interest” (p1) [27]. A SMS is intended to
by different time zones [6]. Benefits of GSD to the onshore encompass an exhaustive search, and aims to provide a
organization include: access to qualified and skilled resources thorough and repeatable analysis of all relevant literature. The
at a lower cost [3] [5] [7] [8]; proximity to markets and access five main steps in the method are: definition of research
to local knowledge about customers and conditions; and questions, searching for relevant papers, screening papers, key
flexibility in responding to local opportunities [5]. wording of abstracts, and data extraction and mapping. The

1530-1362/10 $26.00 © 2010 IEEE 404


DOI 10.1109/APSEC.2010.53
outcome is a high level map visualizing the status of the field with the current research topics in GSD. No further papers
with respect to the research questions. were found beyond those identified by the search in stage 1.
As in stage 1, we looked at any full papers focused on
A. Definition of Research Questions
SCM and GSD written in English within the last 10 years.
With the objective of developing an understanding of the Research in GSD has arguably been conducted for more than
state of research on SCM-related issues and solutions in GSD, 20 years, but formal definitions for GSD emerged only in
the following research questions drive this study: 1999 [29] and 2001 [5]. The journals searched were:

RQ1: What empirical research methods are used? - Empirical Software Engineering
RQ2: What types of research contribution are found? - Software Process Improvement and Practice
RQ3: (a) What SCM-related issues are faced by developers in - Lecture Notes in Computer Science
GSD? - IBM Systems Journal
(b) What solutions are used for these problems? - IEEE Transactions on Software Engineering
RQ4: Which SCM areas of responsibility have major - IEEE Software
problems? - ACM Transaction on Software engineering and
B. Searching and Keywording Criteria Methodology
- Advances in Software Engineering
The literature search comprised two stages. In stage 1, the - Communications of ACM
following electronic databases were searched using the GSD
and SCM keywords listed in Table I. Keywords in each Other well known journals such as MIS Quarterly (MISQ),
category were combined using a Boolean “OR” operator, and Information System Research (ISR), European Journal of
then both categories were combined using a Boolean “AND” Information System (EJIS), have published articles on GSD,
operator. The databases searched were: but were excluded from the search because they do not cover
SCM. The conference proceedings searched in stage 2 were:
- IEEE Xplore (http://ieeexplore.ieee.org)
- ACM Digital Library (http://www.portal.acm.org/dl.cfm) - International Conference on Global Software Engineering
- Elsevier ScienceDirect (http://www.sciencedirect.com) - International Conference on Software engineering
- Compendex EI (http://www.engineeringvillage2.org) - International Conference on Software Process
- INSPEC (http://www.engineeringvillage2.org) - International Workshop on Global Software Development
- Google Scholar (http://scholar.google.com) - Software Configuration Management Workshop
TABLE I. KEYWORDS USED IN THIS STUDY
- Workshop on Accountability and Traceability in Global
Software Engineering
Category Keywords - Asia Pacific Software Engineering Conference
Global Software Global software development - ACM SIGSOFT International Symposium on Foundations
Development Global software engineering of Software Engineering
Globally distributed development - ACM Conference on Computer Supported Cooperative
Geographically distributed development
Distributed software development
Work
Collaborative software development - International Workshop on Cooperative and Human
Collaborative software engineering Aspects of Software Engineering
Offshore software development - Mining Software Repository
Off shoring
Dispersed locations
- International Symposium on Empirical Software
Dispersed teams Engineering and Measurement
Software Configuration management
- International Advanced School of Empirical Software
Configuration Software configuration management Engineering
Management Software change management - Australian Software Engineering Conference
Software change request - European Conference on Software Process Improvement
Change management
Change request
- International Conference on Automated Software
Change control Engineering.
Version control Selected papers were stored in RefWorks, an online
Versioning
Modification request
bibliographic management tool.
C. Screening Papers
Next, we screened the papers for relevance to the research
In stage 2, to verify the search quality and to confirm no questions. This involved applying inclusion and exclusion
studies were missed, a manual search was conducted of criteria.
several journals and conference proceedings and a related First, we analyzed the title, abstract and keywords of each
book [28]. The search also enabled us to familiarize ourselves paper. In some cases, we had to read the whole paper to

405
determine its relevancy. The following inclusion (I) and Journals had 33% of the studies, with most in Software
exclusion (E) criteria were applied: Process Improvement and Practice (38%), and IEEE
Transactions on Software Engineering (13%), Empirical
I1. Papers published should directly relate to SCM and the Software Engineering (13%), IBM Systems Journal (13%),
studies should have some focus on the GSD context. IEEE Software (13%), and Advances in Software Engineering
I2. Papers that consist of opinions, claims, personal (13%) accounting for the remainder.
evaluation and reported recommendations should also be
considered because of the lack of empirical studies B. Study classifications
focusing on SCM in GSD contexts.
We classified the papers according to various focus
E1. Posters, panels, abstracts, presentations and article categories. Table III shows the papers on the basis of the
summaries. issues or solutions focus. Of the 24 papers, 17% mainly
III. RESULTS AND DISCUSSION
discuss SCM issues in GSD, 38% focus on strategies to solve
issues, and 46% highlight issues and also propose solutions for
A. Overview of studies the identified issues.
We found 24 papers from the two-staged search described
in the previous section. For a full list of the primary papers see TABLE III. STUDY FOCUS
Appendix A. Table II shows the publication frequency of the Outcome of Paper Percentage (%) Frequency
selected papers from 1999 until 2010. Studies on SCM in GSD Issues 17 4
have increased in recent years, particularly from 2006. The Strategies 38 9
number of publications in 2010 is likely to be understated as Mixed 46 11
the data was collected in March 2010.
Table IV summarizes the GSD contexts represented in the
TABLE II. PUBLICATION TENDENCY (BY YEAR) 24 papers. The issue dimension reflects the challenges that
motivated the studies in terms of temporal, geographical, and
Year Percentage (%) Frequency socio-cultural distance (as defined by [30]). The majority of
1999 4 1 studies focus on challenges relating to geographical distance in
2000 4 1 software development across more than two sites. The number
2001 4 1 of the developers involved is not listed because most of the
2002 4 1 studies do not report this.
2003 13 3
2004 4 1 TABLE IV. GSD CONTEXTS OF THE STUDIES
2005 0 0 Categorization Description Percentage Frequency
2006 17 4 (%)
2007 21 5 Issue Temporal distance 4 1
2008 13 3 dimension Geographical distance 92 22
2009 13 3 Socio cultural distance 0 0
2010 4 1 Unclear 4 1
Number of Two 29 7
Figure 1 maps the source of the publications. The majority sites More than two 46 11
of the studies are from conference proceedings (58%). The Unclear 25 6
breakdown by conference is: ICGSE (38%), ICSE (23%), Number of Two 17 4
CSCW (15%), ASE (8%), ATGSE (8%) CHASE (8%), and teams More than two 58 14
SCM-9 (8%). Unclear 25 6
Team size Less than 100 17 4
More than 100 29 7
Unclear 54 13
Domain Automation 13 3
Open source 4 1
Electronic 4 1
Financial 8 2
Web application 8 2
Telecommunication 8 2
Unclear 54 13

We classified each publication according to the setting of


Figure 1. Publications by Source Type the study: academic, industrial, government or mixed [31].
Table V indicates that almost 88% of the studies are industrial

406
experience reports, 8% are academic, and 4% are in mixed TABLE VIII. RESEARCH CONTRIBUTION TYPES
study settings. So, the majority of the findings from this
Research type facet Percentage (%) Frequency
mapping study are from GSD practice environments.
Validation research 8 2
Furthermore, as might be expected, the majority of studies
Evaluation research 50 12
relate narrowly to project contexts rather than organizational
Solution proposal 8 2
contexts (shown in Table VI).
Philosophical papers 0 0
Opinion papers 17 4
TABLE V. STUDY SETTINGS 17 4
Experience papers
Study setting Percentage (%) Frequency
Academic 8 2 E. What SCM-related issues face developers in GSD and
Industrial 88 21
0 0
what solutions are used for them (RQ3)?
Government
Mixed 4 1 SCM is a well-established software engineering discipline.
SCM addresses the core practices to manage, control and track
changes to software artifacts in any software development
TABLE VI. STUDY CONTEXTS environment [34]. Software development artifacts can include
Study focus Percentage (%) Frequency source code, software project documentation (Software Project
Project 96 23 Plan (SPP), Software Requirement Specification (SRS),
Organization 0 0 Software Design Description (SDD), Software Test Plan
Unclear 4 1 (STP) and etc.), memos, minutes of meetings, review forms,
and checklists. Software artifacts that are key to maintaining
the integrity of the development are identified as
C. What empirical research methods are used (RQ1)? Configuration Items (CI); with an identification scheme set by
We then classified the studies according to the research the Configuration Manager (CM). Although SCM is not
method used. We used a previously proposed classification always recognized by name, most companies today follow at
[32] consisting of five research methods: 1) experiment least basic SCM practices [35].
(studies that apply specific controls and measure any effect); In a collocated development environment, projects can
2) case study (investigation of real world situations); 3) more easily establish a common SCM system, development
experience reports (record of an industrial experience and and test environment, and good awareness of other team
lessons learned); 4) observational study (observation of one or members. [36]. Problems can be addressed through direct or
more elements with a specific outcome); and 5) systematic face to face communication in a formal meeting or informally
review (a formularized evaluation of existing literature). From [37]. However, the situation is different in the GSD
Table VII, it can be seen that half of the studies used a case environment, where coordination and synchronization [5] [38]
study method (71%), 13% were experience reports, 4% used is more complex and time consuming, because of team size
experiments, 4% were systematic reviews, and 8% are unclear. [38], dispersed location [38] [39], unreliable networks,
This result answers the first research question (What empirical insecure environments, higher response time or delay [5] [9]
research methods are used?). [19] [38] [40] [41], and lack of group awareness [42] [43].

TABLE VII. RESEARCH METHOD USED Compared to collocated development, GSD creates
Research Method Percentage (%) Frequency complexities and issues for SCM, as described below.
Experiment 4 1 Issue 1: Dispersed software teams do not get
Case study 71 17 information on what other teams are doing [9] [28], so it is
Experience reports 13 3 difficult to know the traceability of each module [44] and
Observational study 0 0
Systematic review 4 1
the definition of modifications or problems to be handled is
Unclear 8 2 unclear [3]. These issues are classified as group awareness
problems, where group awareness is defined as an
understanding of the activities of others [45]. Group awareness
D. What types of research contribution are found (RQ2)? provides team members with important information that can
Table VIII classifies the primary research contribution of ensure smooth collaboration. In GSD, it is vital for all team
the studies according to a classification scheme originally members in order to avoid: 1) direct conflict (changes made by
developed for requirements engineering research [33]. We two or more developers on the same artifact); and 2) indirect
found that 50% of the papers comprise evaluation research. conflict (changes in one artifact that affect concurrent changes
Other types were experience papers (17%); opinion papers in another artifact) [46]. Both problems can substantially
(17%); solution proposals (8%), and; validation research (8%). impact project scope, schedule and budget.
This result answers the second research question (What types Other factors contribute to this issue: 1) software changes
of research contribution are found?). can lead to new dependencies on other artefacts [47]; 2)
changes to artefacts may not be consistent [48], and; 3)

407
resolving identified conflicts can sometimes make conflicts or delay. A two year study [51] revealed no consistent reduction
issues more complex. To avoid these issues, dispersed team in interdependency between of the changes in across GSD
members need current and accurate information on who and sites. Thus, this suggests that work is tightly-coupled between
what is involved in the project, where in the code they are GSD projects. This might be caused by other activities
working, and what other team members are doing [42]. performed by the team members such as error-checking, back
Otherwise, team members only become aware of other team merges, partial check-in, formal code reviews, informal code
members’ activities when they: 1) retrieve an artefact; 2) place reviews or holding onto check-ins [54]. In this simple
an artefact in the repository or; 3) query the repository [49]. situation, the inter-dependency between delay and
Strategies: Two techniques have been proposed [28] to dependencies contributes to the increasing time required to
increase group awareness: 1) well-defined tasks (specifying complete the MR (these interrelationships are shown in Figure
certain tasks or roles for certain parts in the development), 2). We consider time required as the time from when the MR
and; 2) exclusive areas of responsibility (splitting team is raised until the changes are completed. The delays and
members’ work based on product parts or modules; this is dependencies may be worse if the situation involves more
especially useful during new development). Both techniques developers, major changes, and large numbers of files or
can be used to increase awareness among team members. source code affected by the changes, significantly impacting
However, a lack of real-time awareness can still lead to the time to complete the MR.
misunderstandings. It takes 2.5 times longer to complete an MR in a GSD
Another way to get information about other team environment in comparison to a collocated environment [40].
members’ activities is by introducing documentation such as Three main factors contributing to the delay were identified as
SPP, SRS, SDD, and STP to share knowledge about the size (how large the changes are); diffusion (number of the files
project [12] [50]. However, this strategy will become affected by the changes), and; number of people (involved in
ineffective if developers are reluctant to constantly update the making the changes) [40]. Large differences in communication
documentation. Team members also can establish group pattern were also found, such as communication barriers,
mailing lists [42] and use instant messenger tools to improve difficult to find an expert and establish contact, and lack of
communication between individuals. Another approach is to collaborative sessions [40]. Managing the impact of
implement cross workspace analysis of ongoing changes and dependencies and delays can be aided by three techniques
with notification to other workspaces when indirect conflicts [54]: 1) impact network (find the network of developers that
are found [46] [49]. Finally, a method has been proposed [44] might affect other’s work); 2) forward impact management
[51] to perform correlation analysis in GSD environments by (assess the impact of the work done to other developers and
collecting and analyzing historical data accumulated in SCM inform them of the impact), and; 3) backward impact
and bug repositories. management (assess the impact of the work performed by
Issue 2: Dependency, delay and increased time required developers in one’s impact network on one’s own network).
to complete MRs [3] [39] [40] [50]. Traditionally, the
Modification Request (MR) or Change Request (CR) process
starts with a request by the client or team members related to Delay Dependencies
requirements, features, functions or problems. Once the MR
has been raised, the Configuration Manager records and
reviews the MR before bringing the issues to the Software
Configuration Control Board (SCCB) for evaluation. The
SCCB then decides whether to accept or reject the MR, and Time required
assigns a priority and severity to the MR, if it is approved [52].
Once the SCCB has approved the MR and it has been assigned Figure 2. Relationships between delay, dependencies and time required
to a developer (assume Developer A), the following situation
may occur. After an analysis of Source Code I by Developer Strategies: Time required to complete a MR can be
A, he or she finds that other code is affected by the changes. reduced by several strategies, such as locating all the
Unfortunately, Developer A does not know about other code development at one site and/or improving communication
since they have not worked on it. Therefore, Developer A has across the GSD environment [40] using traditional techniques
to ask for help from another developer, Developer B, located such as telephone calls, mailing lists [42], instant messaging
at another development center. and video conferencing [55]. Other strategies that can be used
The time from when Developer A requests Developer B are splitting work or tasks across sites by handing off the work
for help to solve the problem represents a delay. A delay is by process phase to other sites when it is completed [40]. An
associated with a dependency, whereby development is Experience Browser has been proposed to identify experts
suspended waiting for a dependent to complete a task [53]. based on the change history in the artifacts [56]. This can
The situation described above is a dependency because reduce the time required to search for an expert to solve a
Developer A has to wait for Developer B to complete the task problem. Also, dependencies can be minimized when
before Developer A can proceed with the changes. constructing the work breakdown structures (WBS) [39].
Dependency in completing the changes also contributes to Other strategies that can be applied are similar to resolving

408
group awareness issues: 1) well-defined tasks; 2) exclusive phase is related to SCM. In this phase, the GSD team members
areas of responsibility [28], and; 3) use of documentation [50] determine the infrastructure for their project, including
[12]. In a study conducted in an industrial setting, it was found preparing for SCM. However, the author does not provide
that individual developers used a number of common information on the specific tasks that need to be performed.
dependency management patterns which can be used to Logically, SCM infrastructure may consist of initial
increase group awareness; hence, at the same time, can reduce preparation such as constructing a SCMP before the GSD
the dependency between each developer [57]. project starts.
Issue 3: Working in different SCM environments [39] Issue 6: Artifacts with different versions and content at
[58] [59], which leads to MRs being handled at various each site [9] [15]. Software under development undergoes
levels in the project [3]. This issue arises when several team multiple changes to satisfy initial and evolving requirements.
members use an SCM repository while others store software These may affect all major project artifacts, source code,
artefacts on their own local workstation. Failure to use the project documentation (such as SRS and SDD), creating new
same SCM repository will reduce awareness about what are versions for each artifacts. This can create confusion,
developers doing and what other developers are working on. especially for GSD project developers, leading to difficulties
Working in different SCM environments can lead to broken during integration. Therefore, an appropriate process to
builds, difficulties merging changes, and remote teams control versions for each document is vital.
reporting bugs in code that has already been updated by other Strategies: To date, commercial tools such as Clearcase
teams [59]. [63], Visual Source Safe (VSS) [64] and open source version
Strategies: Research suggests that all team members control tools are used widely in GSD projects, including Git
involved in GSD should agree on a common management [65], Darcs [66], Bazaar [67], Mercurial [68], Subversion [69],
process [39]. Replicating the source control system may help CVS [70], Jira [71] and Bugzilla [72]. Other tools developed
[58] [36], but may also lead to an unsynchronized environment are Palantir [49], ADAMS [73], FASTDash [74], CHIME
resulting in inaccuracies, misunderstanding and defective code [75], Syde [76], WAV [77], Ariadne [77] and CollabVS [78].
development. However, we argue that: 1) the tools developed are not always
Issue 4: Lack of a planned baseline [39]. One of the main equipped with a function to provide accurate information to
parts of an SCM Plan (SCMP) is to identify a baseline for each increase GA among developers, and; 2) although some of the
development artefact. This provides a basis for development tools (WAV, Ariadne [77], CHIME [75], Syde [76]) can detect
work. Researchers have found [39] that baselines are always and provide accurate information on conflicts and
requested on demand by the team members. This can cause dependencies in real time, the literature also argues that: a)
initial delays to other developers’ work, since the GSD some artefacts are not understood by tools [79], and; b) the
developers need to lodge a formal MR and follow the change tools do not really focus on people’s activities [80].
management procedure [60]. In sum, the literature argues that SCM is challenged in
Strategies: Before development starts, essential SCM GSD due to the geographic distances encountered [30].
concepts should be explained [39], to help to establish and Geographic distance limits team awareness [28] [9] [43] [39]
clarify the main concepts of SCM for each developer. The [58] [59], due to a decreased ability to communicate with
SCM manager and project manager should also properly plan other project developers. Geographic distance also increases
baselines and document them in the SCMP [39]. coordination and synchronization process complexity [38] [5]
Issue 5: SCM process management [34] is a category of due to the number of dispersed team members [38], and
issues that includes, lack of coding standards, code problems of process ownership [17]. No SCM process was
ownership, unclear flow of development, and tool selection found that is specifically designed for GSD projects.
[9] [15]. While these issues are generic to SCM, they can be Therefore, a research gap exists in the SCM literature. SCM
even more problematic in GSD contexts if the developers are should be implemented early in the software development
not aware of what coding standard to use, the flow of the process as most development is dependent on artifact control
development, and which tools to use. These issues can arise [3]. While, an SCM process is not a silver bullet for GSD, the
when a GSD project does not have a well-defined process or evidence found in this study suggests that there is a need to
proper planning of SCM practices at an early stage of the extend SCM processes to apply to GSD environments.
project. F. Which SCM areas of responsibility have major problems
Strategies: It has been suggested that a well-defined (RQ4)?
process tailored to GSD can increase effectiveness in GSD [9].
Recent models that have been developed for GSD are Global To develop an understanding of the areas of responsibility
Teaming [61] and GSD Implementation Model [62]. Global for the SCM-related issues in GSD (as described above, in
Teaming [61] focuses on the cultural, social, geographical and Section E), we mapped the issues against responsibilities as
temporal differences in GSD. The GSD Implementation identified in the Software Engineering Body of Knowledge
Model [62] can be used to provide GSD projects with a (SWEBOK) [34]. This mapping is shown in Table IX.
systematic approach to address key activities, infrastructure From Table IX, it can be seen that most of the issues
and support. It comprises five phases: initiating, provisioning, (‘problems’) are in the responsibility areas of Management of
establishing, managing and leveraging. The provisioning the SCM Process (Mgmt) and Software Configuration Control
(SCC). Management of SCM is concerned with the

409
preparation of SCM infrastructure before starting a project. It SCSA – Software Configuration Status Accounting
includes selection of the tools to be used and preparing the SCA – Software Configuration Auditing
SCMP. SCC is concerned with MRs during software SRMD – Software Release Management and Delivery
development. Based on SWEBOK, SCC covers the process for
determining what changes to make, the authority for IV. CONCLUSION
approving certain changes, and support for the implementation This paper explores the SCM issues faced by GSD project
of those changes. Major processes involved in SCC are: 1) team members and the strategies proposed based on a
requesting, evaluating and approving software changes, and; systematic mapping study of current literature. The paper has
2) implementing software changes. also mapped trends in published research studies by year,
This finding informs researchers about opportunities for publication type and research methods used, and classified the
research on SCM processes. Lack of SCM process support for studies according to focus, setting and contexts. This research
GSD projects is likely to impact the effectiveness and value of is important because it highlights the gaps and opportunities in
SCM in GSD and contribute to suboptimal project outcomes. evidence on SCM in GSD environments. Our systematic
mapping study found 13 issues with SCM in GSD and
TABLE IX. MAPPING OF ISSUES TO SCM AREAS OF RESPONSIBILITY identified current solutions proposed in the literature. These
Issues SCM Areas of Responsibility
proposed issues and solutions need empirical investigation and
(Based on SWEBOK) validation in future research.
Mgmt SCI SCC SCSA SCA SRMD Based on our systematic mapping study, the following
P1 √ √ conclusions can be drawn:
P2 √ √ √
P3 √
P4
Conclusion #1: Most of the studies related to SCM in GSD
√ √
P5 √ contexts are based on case studies
P6 √
P7 √ Our study found that most studies related to SCM in GSD
P8 √ √ are based on case studies, which means that researchers tend
P9 √ to discover the problems faced by team members in practice
P10 √
P11 √
rather than propose theory-based solution.
P12 √
P13 √ √ Conclusion #2: There is a lack of validation research
associated with SCM within GSD

Legend: There are two plausible reasons for the lack of validation
√ - This issue is within this area of responsibility research: 1) although mature in collocated development, SCM
may not be able to be readily applied to GSD because of
Issues: significant differences in the project context, and thus
[P1] Dispersed software teams do not get information on what researchers in the SCM field may still be trying to identify
other teams are doing [28] [9] appropriate solutions; or 2) researchers are not yet broadly
[P2] Difficult to know the traceability of each module [44] aware of the difficulties related to SCM in GSD.
[P3] The definition of modifications or problems to be handled
is unclear [3] Conclusion #3: Lack of coordination and group awareness
[P4] Dependency [39] [50] has contributed to SCM difficulties. Moreover, no SCM
[P5] Delay and increase time required to complete MR [3] process has been proposed to improve coordination and group
[39] [40][50] awareness in GSD
[P6] Working in different SCM environments [39] [58] [59]
[P7] MRs are handled at various levels in the project [3] We found that lack of coordination and group awareness in
[P8] Lack of a planned baseline [39] GSD has resulted in SCM related challenges. Lack of
[P9] Lack of coding standards [9] [15] coordination creates dependency delays among project
[P10] Code ownership [9] [15] developers, leading to increased time required in completing
[P11] Unclear flow of development [9] [15] MRs in GSD. In addition, lack of coordination can also result
[P12] Tool selection [9] [15] in each site working in a different SCM environment, which
[P13] Artifacts with different versions and content at each site causes SCM process management issues in GSD. We also
[9] [15] found group awareness makes it more difficult for project
developers to get information from other sites, to understand
SCM Areas (based on SWEBOK): the traceability of each module, and to get a clear view of the
Mgmt – Management of the SCM Process changes that should be made. These SCM challenges can also
SCI – Software Configuration Identification arise in a collocated environment. However, in GSD, they are
SCC – Software Configuration Control exacerbated by coordination and group awareness

410
complexities. Solutions used in collocated environments may NICTA is funded by the Australian Government as
not be directly applicable in a GSD environment, with represented by the Department of Broadband, Communications
different locations and time zones, and where different and the Digital Economy and the Australian Research Council
processes are employed at each site. through the ICT Centre of Excellence program.
Some researchers have proposed strategies to reduce or
REFERENCES
eliminate the issues identified in this study. For instance, [1] J.D. Herbsleb and R.E. Grinter, "Splitting the organization and integrating
strategies suggested by prior researchers relate to the use of the code: Conway's law revisited," in ICSE '99: Proceedings of the 21st
documentation to enhance communication and awareness international conference on Software engineering, pp. 85-95, 1999.
among project developers, the use of instant messenger to [2] R.D. Battin, R. Crocker, J. Kreidler and K. Subramanian, "Leveraging
resources in global software development," IEEE Software, vol. 18, pp. 70-77,
communicate, verbal agreement at the early stage of the 2001.
development, and the use of versioning tools and expert [3] R. Kommeren and P. Parviainen, "Philips experiences in global distributed
browser tools to identify an expert to solve problems. software development," Empirical Software Engineering, vol. 12, pp. 647-660,
Nonetheless, our study found that no SCM process has 12/01. 2007.
[4] Software and Information Industry Association and Symphony Services,
been designed for the GSD environment in order to improve "SIIA Global software development survey report," Software and Information
coordination and group awareness. The introduction of tools Industry Association., 2006.
and techniques not properly tied to a well-defined software [5] J.D. Herbsleb and D. Moitra, "Global software development," IEEE
process can limit their effectiveness. New GSD process Software, vol. 18, pp. 16-20, 2001.
[6] J.A. Espinosa and E. Carmel, "The impact of time separation on
models such as the Global Teaming and GSD Implementation coordination in global software teams: a conceptual foundation," Software
Model are more related to the managerial perspective and to Process: Improvement and Practice, vol. 8, pp. 249-266, 2003.
prepare GSD project developers at the start of the project, but [7] S. Komi-Sirviö, P. Abrahamsson and T. Huomo, "Guest editorial for the
have not addressed the technical process and SCM, special section on distributed software development," Information and
Software Technology, vol. 48, pp. 765-766, 9. 2006.
specifically. The use of Capability Maturity Model (CMM) [8] B. Boehm, "Some future trends and implications for systems and software
and its successor Capability Maturity Model Integration engineering processes," Systems Engineering, vol. 9, pp. 1-19, 2006.
(CMMI) in GSD projects has been debated by several [9] R. Prikladnicki, J.L.N. Audy and R. Evaristo, "Global software
researchers as the model has been less well tested in the GSD development in practice lessons learned," Software Process: Improvement and
Practice, vol. 8, pp. 267-281, 2003.
environment. [10] K.E. Nidiffer and D. Dolan, "Evolving distributed project management,"
Software, IEEE, vol. 22, pp. 63-72, 2005.
Conclusion #4: There is a need for more studies focusing [11] C.R.B. De Souza, "Global Software Development: Challenges and
on the Software Configuration Control (SCC) areas of Perspectives," Available on Line Http://citeseer.Ist.Psu.edu/457465.Html,
2001.
responsibility in GSD environments [12] E.Ó. Conchúir, H.H. Olsson, P.J. Ågerfalk and B. Fitzgerald, "Benefits of
global software development: exploring the unexplored," Software Process:
The mapping shown in Table IX indicates that one of the Improvement and Practice, vol. 14, pp. 201-212, 2009.
SCM areas of responsibility that is particularly affected by a [13] J.A. Laredo and R. Ranjan, "Continuous Improvement through Iterative
Development in a Multi-Geography,". IEEE International Conference on
lack of coordination and group awareness is Software Global Software Engineering, pp. 232-236, 2008.
Configuration Control (SCC). Six issues associated with SCC [14] A. Begel and N. Nagappan, "Global Software Development: Who Does
that arise in GSD are: artifacts with different version and It?" IEEE International Conference on Global Software Engineering, pp. 195-
content in each site; development being suspended waiting on 199, 2008.
[15] R. Prikladnicki, A. Jorge and R. Evaristo, "A Reference Model for Global
dependent modules; no clear definition of MRs; MRs being Software Development: Findings from a Case Study," International
handled at various levels; increased delay and time required to Conference on in Global Software Engineering, pp. 18-28, 2006.
complete MRs; and also traceability issues. These issues can [16] C. Ebert, B.K. Murthy and N.N. Jha, "Managing Risks in Global
impact the time and budget required to complete GSD Software Engineering: Principles and Practices," IEEE International
Conference on Global Software Engineering, pp. 131-140, 2008.
projects. [17] J.S. Persson and L. Mathiassen, "A Process for Managing Risks in
Distributed Teams," IEEE Software, vol. 27, pp. 20-29, 2010.
V. FUTURE WORK [18] Valentine Casey and Ita Richardson, "Project Management within Virtual
Our paper has identified a number of SCM challenges Software Teams," International Conference on Global Software Engineering,
pp. 33-42, 2006.
resulting from coordination and group awareness issues in [19] B. Sengupta, S. Chandra and V. Sinha, "A research agenda for distributed
GSD. Our future work will develop an SCM process that can software development," in ICSE '06: Proceedings of the 28th international
be applied to GSD environments in order to reduce conference on Software engineering, pp. 731-740, 2006.
coordination and group awareness complexities in GSD. The [20] A. Avritzer, "Coping with Cultural Diversity in GSE Environments,"
International Conference on Global Software Engineering , pp. 199-199, 2006.
SCM process will be designed to be incorporated within GSD [21] N.B. Moe and D. Scaronmite, "Understanding a lack of trust in Global
projects, and to help GSD project developers to improve Software Teams: a multiple-case study," Software Process: Improvement and
coordination and group awareness activities in a practical way. Practice, vol. 13, pp. 217-231, 2008.
[22] T. Nguyen, T. Wolf and D. Damian, "Global Software Development and
ACKNOWLEDGMENTS Delay: Does Distance Still Matter?" IEEE International Conference on Global
Software Engineering, pp. 45-54, 2008.
We gratefully acknowledge the support of the Universiti [23] T. Wolf, T. Nguyen and D. Damian, "Does distance still matter?"
Teknologi Mara (UiTM) and Ministry of Higher Education, Software Process: Improvement and Practice, vol. 13, pp. 493-510, 2008.
Malaysia for sponsoring the first author to purse his study at [24] Suling Zhang, Marilyn Tremaine, Jerry Fjermestad, Allen Milewski and
The University of New South Wales (UNSW), Australia. Patrick O'Sullivan, "Delegation in Virtual Team: the Moderating Effects of

411
Team Maturity and Team Distance," International Conference on Global workspaces," in ASE '07: Proceedings of the twenty-second IEEE/ACM
Software Engineering, pp. 62-68, 2006. international conference on Automated software engineering, pp. 94-103,
[25] E. Carmel and R. Agarwal, "Tactical approaches for alleviating distance 2007.
in global software development," IEEE Software, vol. 18, pp. 22-29, 2001. [47] R.E. Grinter, J.D. Herbsleb and D.E. Perry, "The geography of
[26] Helena Holmstrom, Eoin O Conchuir, Par J Agerfalk and Brian coordination: dealing with distance in R&D work," in GROUP '99:
Fitzgerald, "Global Software Development Challenges: A Case Study on Proceedings of the international ACM SIGGROUP conference on Supporting
Temporal, Geographical and Socio-Cultural Distance," International group work, pp. 306-315, 1999.
Conference on Global Software Engineering, pp. 3-11, 2006. [48] A. Mockus and D.M. Weiss, "Predicting risk of software changes," Bell
[27] K. Petersen, R. Feldt, S. Mujtaba and M. Mattsson, "Systematic mapping Labs Technical Journal, vol. 5, pp. 169-180, 2000.
studies in software engineering," in 12th International Conference on [49] A. Sarma, Z. Noroozi and A. van der Hoek, "Palantir: raising awareness
Evaluation and Assessment in Software Engineering (EASE), 2008. among configuration management workspaces," in ICSE '03: Proceedings of
[28] R. Sangwan, N. Mullick, M. Bass, D.J. Paulish and J. Kazmeier, Global the 25th International Conference on Software Engineering, pp. 444-454,
software development handbook, Auerbach Publications Taylor & Francis 2003.
Group, 2006, . [50] M. Cataldo, M. Bass, J.D. Herbsleb and L. Bass, "On Coordination
[29] E. Carmel, Global software teams: collaborating across borders and time Mechanisms in Global Software Development," Second IEEE International
zones, Prentice Hall Upper Saddle River, NJ, 1999. Conference on in Global Software Engineering, pp. 71-80, 2007.
[30] P.J. Ågerfalk, B. Fitzgerald, H. Holmström, B. Lings, B. Lundell and E.Ó. [51] M. Ohira, R. Yokomori, M. Sakai, K. Matsumoto, K. Inoue and K. Torii,
Conchúir, "A framework for considering opportunities and threats in "Empirical project monitor: A tool for mining multiple project data," in Proc.
distributed software development," in International Workshop on Distributed of Int. Workshop on Mining Software Repositories, 25th May 2004.
Software Development, pp. 47–61, 2005. [52] S.S.M. Fauzi, N. Ramli and M.H.N.M. Nasir, "Software Configuration
[31] N. Condori-Fernandez, M. Daneva, K. Sikkel, R. Wieringa, O. Dieste and Management - A Result from the Assessment and Its Recommendation," in
O. Pastor, "A systematic mapping study on empirical evaluation of software 2009 International Conference on Information Management and Engineering
requirements specifications techniques," in Proceedings of the 2009 3rd , pp. 416-419, 2009.
International Symposium on Empirical Software Engineering and [53] J.D. Herbsleb, A. Mockus, T.A. Finholt and R.E. Grinter, "Distance,
Measurement, pp. 502-505, 2009. dependencies, and delay in a global collaboration," in CSCW '00: Proceedings
[32] P. Tonella, M. Torchiano, B. Du Bois and T. Systä, "Empirical studies of the 2000 ACM conference on Computer supported cooperative work, pp.
in reverse engineering: state of the art and future trends," Empirical Software 319-328, 2000.
Engineering, vol. 12, pp. 551-571, 10/01. 2007. [54] C.R.B. de Souza and D.F. Redmiles, "An empirical study of software
[33] R. Wieringa, N. Maiden, N. Mead and C. Rolland, "Requirements developers' management of dependencies and changes," in ICSE '08:
engineering paper classification and evaluation criteria: a proposal and a Proceedings of the 30th international conference on Software engineering, pp.
discussion," Requirements Engineering, vol. 11, pp. 102-107, 2006. 241-250, 2008.
[34] A. Abran, P. Bourque, R. Dupuis, J.W. Moore, L.L. Tripp, A. Abran, P. [55] T. Niinimaki and C. Lassenius, "Experiences of Instant Messaging in
Bourque, R. Dupuis, J.W. Moore and L.L. Tripp, Guide to the Software Global Software Development Projects: A Multiple Case Study," IEEE
Engineering Body of Knowledge - SWEBOK, Piscataway, NJ, USA: IEEE International Conference on Global Software Engineering, pp. 55-64, 2008.
Press, 2004, pp. 1-202. [56] A. Mockus and J.D. Herbsleb, "Expertise browser: a quantitative
[35] Forrester Research Inc, "The Challenges Of Software Change approach to identifying expertise," in ICSE '02: Proceedings of the 24th
Management In Today’s Siloed IT Organizations," Forrester Consulting., International Conference on Software Engineering, pp. 503-512, 2002.
2006. [57] L.D. Panjer, D. Damian and M. Storey, "Cooperation and coordination
[36] U. Asklund, B. Magnusson and A. Persson, "Experiences; Distribution concerns in a distributed software development project," in CHASE '08:
Development and Software Configuration Management," System Proceedings of the 2008 international workshop on Cooperative and human
Configuration Management, pp. 794-794, 1999. aspects of software engineering, pp. 77-80, 2008.
[37] A. Sarma, Palantir: Enhancing Configuration Management Systems with [58] J. Treinen and S. Miller-Frost, "Following the sun: Case studies in global
Workspace Awareness to Detect and Resolve Emerging Conflicts, 2008. software development," IBM Systems Journal, vol. 45, pp. 773-784, 2006.
[38] M. Jiménez, M. Piattini and A. Vizcaıno, "Challenges and Improvements [59] N. Mullick, M. Bass, Z. Houda, Paulish Paulish and M. Cataldo,
in Distributed Software Development: A Systematic Review," Advances in "Siemens Global Studio Project: Experiences Adopting an Integrated GSD
Software Engineering, vol. Volume 2009, pp. 14 pages, 2009. Infrastructure," International Conference on in Global Software Engineering,
[39] L. Pilatti, J.L.N. Audy and R. Prikladnicki, "Software configuration pp. 203-212, 2006.
management over a global software development environment: lessons [60] Alexis Leon, A Guide to Software Configuration Management, USA:
learned from a case study," in Proceedings of the 2006 international workshop Artech House Computing Library, 2000.
on Global software development for the practitioner, pp. 45-50, 2006. [61] I. Richardson, V. Casey, J. Burton and F. McCaffery, "Global Software
[40] J.D. Herbsleb and A. Mockus, "An empirical study of speed and Engineering: A Software Process Approach," Collaborative Software
communication in globally distributed software development," IEEE Engineering, pp. 35-56, 2010.
Transactions on Software Engineering, vol. 29; 29, pp. 481-494, 2003. [62] V. Casey and I. Richardson, "Implementation of Global Software
[41] S. Komi-Sirvio and M. Tihinen, "Lessons learned by participants of Development: a structured approach," Software Process: Improvement and
distributed software development," Knowledge and Process Management, vol. Practice, vol. 14, pp. 247-262, 2009.
12, pp. 108-122, 2005. [63]"Clearcase," Internet: http://www-1.ibm.com/software/awdtools/clearcase/,
[42] C. Gutwin, R. Penner and K. Schneider, "Group awareness in distributed [Aug 11, 2010]
software development," in CSCW '04: Proceedings of the 2004 ACM [64]"Visual Source Safe," Internet: http://msdn.microsoft.com/en-
conference on Computer supported cooperative work, pp. 72-81, 2004. us/library/aa302175.aspx, [Aug 11, 2010]
[43] A. Sarma, D. Redmiles and A. van der Hoek, "Empirical evidence of the [65] "Git" Internet: http://git-scm.com/, [Feb 11, 2010]
benefits of workspace awareness in software configuration management," in [66] "Darcs" Internet: http://darcs.net, [Feb 11, 2010]
SIGSOFT '08/FSE-16: Proceedings of the 16th ACM SIGSOFT International [67] "Bazaar" Internet: http://bazaar.canonical.com/en/, [Feb 11, 2010]
Symposium on Foundations of software engineering, pp. 113-123, 2008. [68] "Mercurial" Internet: http://mercurial.selenic.com/, [Feb 11, 2010]
[44] M. Nagura and H. Iida, "Correlation Analysis for Distributed [69] "Subversion" Internet: http://subversion.tigris.org/ , [Feb 11, 2010]
Development based on Configuration Management and Bug Report," in [70] "CVS" Internet: http://www.nongnu.org/cvs/ [Feb 11, 2010]
Workshop on Accountability and Traceability in Global Software Engineering [71] "Jira" Internet: http://www.atlassian.com/software/jira/ [Mar 17, 2010]
(ATGSE2007), pp. 15-16, 2007. [72] "Bugzilla" Internet: http://www.bugzilla.org/ [Mar 17, 2010]
[45] P. Dourish and V. Bellotti, "Awareness and coordination in shared [73] Bernd Bruegge, Andrea De Lucia, Fausto Fasano and Genoveffa Tortora,
workspaces," in Proceedings of the 1992 ACM conference on Computer- "Supporting Distributed Software Development with fine-grained Artefact
supported cooperative work, pp. 114, 1992. Management," International Conference on in Global Software Engineering,,
[46] A. Sarma, G. Bortis and A. van der Hoek, "Towards supporting pp. 213-222, 2006.
awareness of indirect conflicts across software configuration management

412
[74] J.T. Biehl, M. Czerwinski, G. Smith and G.G. Robertson, "FASTDash: a international workshop on Cooperative and human aspects of software
visual dashboard for fostering awareness in software teams," in CHI '07: engineering, pp. 1-4, 2008.
Proceedings of the SIGCHI conference on Human factors in computing [78] P. Dewan and R. Hegde, "Semi-synchronous conflict detection and
systems, pp. 1313-1322, 2007. resolution in asynchronous software development," ECSCW 2007, pp. 159-
[75] S.E. Dossick and G.E. Kaiser, "CHIME: a metadata-based distributed 178, 2007.
software development environment," in ESEC/FSE-7: Proceedings of the 7th [79] Igor Scaliante Wiese and Elisa Hatsue Moriya Huzita, "IMART: An
European software engineering conference held jointly with the 7th ACM Interoperability Model for Artifacts of Distributed Software Development
SIGSOFT international symposium on Foundations of software engineering, Environments," International Conference on Global Software Engineering, pp.
pp. 464-475, 1999. 255-256, 2006.
[76] L. Hattori and M. Lanza, "Syde: A Tool for Collaborative Software [80] C. Gutwin, K. Schneider, D. Paquette and R. Penner, "Supporting Group
Development," in Proceeding of the 32nd ACM/IEEE International Conference Awareness in Distributed Software Development," Engineering Human
on Software Engineering, pp 235-238, 2010. Computer Interaction and Interactive Systems, pp. 383-397, 2005.
[77] B. Al-Ani, E. Trainer, R. Ripley, A. Sarma, A. Van Der Hoek and D.
Redmiles, "Continuous coordination within the context of cooperative and
human aspects of software engineering," in Proceedings of the 2008

Appendix A : List of primary paper used in this study


Type of Study
Paper Year Source Method used Type of research
publication setting
1 2006 ICGSE Proceeding Mixed Case study Evaluation research
2 2008 ICGSE Proceeding Industrial Case study Evaluation research
3 2007 ASE Proceeding Industrial Experiment Evaluation research
4 2007 ATGSE Proceeding Academic Unclear Solution proposal
5 2004 CSCW Proceeding Industrial Case study Evaluation research
6 2003 ICSE Proceeding Industrial Case study Solution proposal
7 2007 Empirical Software Engineering Journal Industrial Experience reports Experience paper
8 2003 Software Process Improvement & Practice Journal Industrial Case study Evaluation research
9 2006 IBM Systems Journal Journal Industrial Experience reports Experience paper
10 2003 IEEE Transaction on Software Engineering Journal Industrial Case study Evaluation research
11 2009 Software Process Improvement & Practice Journal Industrial Case study Opinion paper
12 1999 Springer-Verlag Proceeding Industrial Case study Experience paper
13 2007 ICGSE Proceeding Industrial Case study Evaluation research
14 2006 ICGSE Proceeding Industrial Case study Opinion paper
15 2006 ICGSE Proceeding Industrial Case study Evaluation research
16 2007 Taylor & Francis Group Book Industrial Unclear Opinion paper
17 2002 ICSE Proceeding Industrial Case study Validation research
18 2001 IEEE Software Journal Industrial Experience reports Experience paper
19 2009 Software Process Improvement & Practice Journal Industrial Case study Evaluation research
20 2010 Springer-Verlag Book chapter Industrial Case study Evaluation research
21 2009 Advances in Software Engineering Journal Academic Systematic review Opinion paper
22 2000 CSCW Proceeding Industrial Case study Evaluation research
23 2008 ICSE Proceeding Industrial Case study Validation research
24 2008 CHASE Proceeding Industrial Case study Evaluation research

413

View publication stats

Вам также может понравиться