EVALUATING FACTORS THAT CHALLENGE
GLOBAL SOFTWARE DEVELOPMENT
Gabriela N. Aranda
1
, Aurora Vizcaíno
2
, Alejandra Cechich
1
and Mario Piattini
2
1
GIISCo Research Group. Computing Sciences Department. Universidad Nacional del Comahue
Buenos Aires, 1400. 8300 Neuquén, Argentina
2
ALARCOS Research Group, Information Systems and Technologies Department
UCLM-INDRA Research and Development Institute, Universidad de Castilla-La Mancha
Paseo de la Universidad 4 - 13071 Ciudad Real, Spain
Keywords: Global Software Development, Requirement Elicitation Process.
Abstract: Usually, some aspects of any Global Software Development (GSD) project strongly impact the
requirements elicitation activities because of the importance of communication to reach a common
understanding about the system under construction. For example, cultural diversity and the impossibility of
running face-to-face meetings dominate the scenario where communication must be done. In this paper, we
analyze aspects that might be a source of communication problems and suggest strategies to reduce
misunderstandings among stakeholders, aiming to help achieve more committed requirements.
1 INTRODUCTION
Global Software Development (GSD) takes place in
scenarios where stakeholders are dispersed in many
distanced sites across the limits of a country, and can be
implemented by means of off-shoring (relocating the
process in another country but as a part of the same
organization) or offshore outsourcing (hiring an
external organization to perform some activity in a
different country than the one where software is
actually developed) practices.
Industry has rapidly adopted these practices in
order to save costs by locating software development
in countries where salaries are lower; but even when
it has many advantages (Lloyd, 2002), geographical
dispersion over multiple sites negatively affect the
team‘s performance (Damian, 2002; Prikladnicki,
2003). One of the most important challenges that
GSD must face is the lack of face-to-face
interaction; however there are other factors that
affect virtual team performance, such as cultural
diversity and time separation, and all of them are
worth of consideration.
As communication is a well-known challenge
during any requirements elicitation process (Al-
Rawas, 1996), we consider that communication in
GSD projects must be specially analyzed and a
methodology for requirements elicitation in
distributed scenarios must be defined.
In order to define such a methodology, we have
analyzed the requirements elicitation methodologies
for co-located projects and adapted the different
phases to a distributed environment, proposing
strategies to minimize the most common problems
that affect communication. In this paper we analyze
such factors and propose a way to evaluate them, as
well as strategies to minimize the problems they can
introduce in communication. Having this idea in
mind, the rest of the paper is organized as follows: in
Section 2 we discuss the main problems that
challenge GSD projects, while in Section 3 we
propose forms to collect related information and
guidelines to evaluate it. Based on such evaluation,
in Section 4, we present some strategies to minimize
the problems introduced for such factors. Finally,
conclusions and future work are addressed in the last
section.
2 COMMON PROBLEMS IN GSD
PROJECTS
Most of the works about GSD mention inadequate
communications as a key problem for requirements
engineering activities (Damian, 2002; Prikladnicki,
355
N. Aranda G., Vizcaíno A., Cechich A. and Piattini M. (2008).
EVALUATING FACTORS THAT CHALLENGE GLOBAL SOFTWARE DEVELOPMENT.
In Proceedings of the Third International Conference on Software and Data Technologies, pages 355-363
DOI: 10.5220/0001889603550363
Copyright
c
SciTePress
2003), which is mainly due to the loss of
communication richness as a consequence of the
lack of face-to-face interaction. In addition, there are
other problems that challenge communication and
are related to the fact that stakeholders are spread
over different countries. The first one is the time
difference which causes that timetables do not
overlap or overlap just for a short period. Then,
because of the lack of synchronous collaboration,
some delays in the project can happen (Damian,
2002). Similarly, time separation also refers to
timetables that do not overlap enough, but time
separation considers not just the time difference but
also the result of cultural issues like different
working hours, lunch breaks, weekend or holidays
times (Espinosa, 2003). Cultural diversity is another
problem when team members are distributed on
different countries, since they use to have diverse
religions, languages, and customs (Damian, 2002)
(MacGregor, 2005). Finally, knowledge management
in GSD projects becomes more difficult in
distributed settings since there is a huge amount of
information from multiple sources that needs to be
appropriately shared among all the stakeholders
(Damian, 2002).
Having such problems in mind, we will try to
identify some factors that are related to them. We aim
to define strategies that minimize the problems they
cause, as we will explain in the following two sections.
3 FACTORS THAT INTRODUCE
PROBLEMS IN GSD
Based on the main problems detected in GSD
projects, we looked for related factors that can be
evaluated and used as a guide to suggest strategies to
minimize such problems.
The factors we chose to evaluate are: working
timetable overlap, language difference, cultural
difference and stakeholders’ cognitive
characteristics. Their relationship with the main
problems in GSD is shown in Table 1, and can be
summarized as follows:
Timetable overlap is related to time difference
between sites but also to cultural issues like
habits. It affects communication as it is related to
the possibility or not of synchronous interaction.
Language difference affects communication as
well as knowledge management, because of the
importance of a common vocabulary.
Cultural difference is a natural consequence of
cultural diversity. Having an indicator about
cultural difference allows knowing about the
need of implementing a strategy to minimize
problems due to cultural diversity.
Stakeholders’ cognitive aspects refer to the way
people behave according to innate
characteristics. This behaviour has influence on
the way people interact with the world and
especially on their communication with other
stakeholders.
Having an indicator about each one of these
factors will allow us to define when strategies to
minimize the problems related to them are needed.
Then, we determined a manner of obtaining a value
for each factor from a set of easy-to-remember
linguistic tags, giving us the chance of reusing our
functions among different projects by adjusting
different parameters. The tags we defined for each
factor are shown in Table 2. In the following
sections we will explain how the different linguistic
tags are obtained for each factor.
Table 1: Relationship between factors and problems in GSD.
Inadequate
communication
Time
separation
Cultural
diversity
Knowledge
management
Timetable overlap √ √
Language difference √ √ √
Cultural difference √ √
Stakeholders’ cognitive
characteristics
√
Table 2: Linguistic tags defined for each factor.
Factor Linguistic tags
Time overlap low, medium, high
Knowledge about a
common language
low, low-intermediate, medium,
high-intermediate, high
Cultural difference low, medium, high
Stakeholders’ cognitive
characteristics
type 1, type 2, type 3
3.1 Timetable Overlap Evaluation
We consider a virtual team is the minimal group of
people that must interact during the software
requirements elicitation process, then, we propose
evaluating how much time they share to interact
synchronously. To do so, we propose using a form
where timetable for each stakeholder is converted
into Greenwich Time (GT), and calculating the
overlap between all the stakeholders’ timetables.
ICSOFT 2008 - International Conference on Software and Data Technologies
356
Form 6: Timetable overlap
Greenwich time
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
S1’s name
S2’s name
S3’s name
Overlap
Figure 1: Timetable overlap evaluation.
As an example consider three stakeholders (S1,
S2, S3) where S1 and S2 are in Spain and S3 in
Argentina. Spanish time is +1 and Argentinean Time
is -4, according to GT. Then, considering their
normal timetable: S1’s from 8 to 16 (that would be 7
to 15 for GT), S2’s from 10 to 18 (9 to17 GT), and
S3 from 8 to 16 (12 to 20 GT). Such information is
filled in the form 6 (as it is shown in Figure 1) and
the overlap is calculated. Then, for this example, the
total overlap is 4 hours, which is the 50% of the total
time.
In order to obtain the tags “low”, “media”, and
“high” for the overlap factor, we propose the
following formulas for a n hours working-day:
(n+1)/3 is the lowest limit for the “media” tag
n-(n+1)/3 is the highest limit for the “media” tag
The highest limit for the “low” tag: ((n+1)/3)-1
The lowest limit for the “high” tag: (n-
(n+1)/3)+1
For our previous example, the results are shown
in Figure 2.
1 7 3 5
Low Medium High
2
4
6 8
1
Figure 2: Fuzzy function for the overlap timetable variable.
3.2 Language Difference Evaluation
Language difference is a common factor in global
environments as a consequence of the interaction
among people from different countries. Analyzing
the probable scenarios, we have identified three
cases:
Same language: For example, in a project
involving organizations from Spain and
Argentina the language is the same (Spanish) but
differences in pronunciation, intonation, use of
different words for the same concept or, on the
contrary, the same word for different concepts,
may introduce misunderstandings and confusing
situations.
Different language (native language for one of
the sites): For example, in a project involving
people from Spain and USA, the languages will
be completely different. Since English is widely
spread all over the world as a second language, it
will probably be chosen as the common
language.
Different language (non native language for
none of the sites): For example, in a project
involving people from Spain and The
Philippines, their languages will be completely
different. Again, as English is widely spread all
over the world as a second language, it will be
probably chosen as the common language. The
difference with the previous case is that, as
English is a second language for people in both
sites, stakeholders share a similar difficulty when
dealing with the foreign language, which is
supposed to generate more empathy.
In this case, instead of using a scale to evaluate the
language difference, we preferred a scale that
evaluates the degree of knowledge of a common
language. In this scale the tag “High” is the best
choice (which means that there is no language
difference), and then High-Intermediate,
Intermediate, Low-Intermediate and Low. Then, we
propose a form (shown in Figure 3) to gather the
information related to knowledge about a given
language and propose a scale to classify such
difference. We propose filling a form for each
language that can be considered as a possible
common language and analyze which one obtains
the highest mark according to the tags we have
previously defined.
EVALUATING FACTORS THAT CHALLENGE GLOBAL SOFTWARE DEVELOPMENT
357
Form 7: Degree of knowledge of a common language
Possible common
language
Language: ……………………………………………………………………………………...
All the stakeholders are from the same country
Stakeholders don’t share the mother language but they have a high level of
knowledge about the chosen common language.
High
Stakeholders share the mother language but they are from different
countries.
Stakeholders don’t share the mother language but they a high-intermediate
level of knowledge about the chosen common language.
High-
Intermediate
Stakeholders don’t share the mother language but they have at least an
intermediate level of knowledge about the chosen common language.
Intermediate
Stakeholders don’t share the mother language but they have at least a low-
intermediate level of knowledge about the chosen common language.
Low-
Intermediate
Choose the
options closer to
your virtual team
Stakeholders don’t share the mother language and all of them have a low
level of knowledge about the chosen common language.
Low
Figure 3: Language difference evaluation form.
3.3 Cultural Diference Evaluation
Culture is defined as a set of key values, norms and
beliefs that are shared between members of a
society, and can be described in terms of a series of
dimensions (Nataatmadja, 2007). The Hofstede’s
model is the most widely used to analyze cultural
differences in GSD projects (Egan, 2006;
MacGregor, 2005), and applies to many situations,
such as analysing behaviour between bosses and
employees, the way in which people privilege
individualism or collectivism, etc (Hofstede, 1996).
The five dimensions for the Hofstede’s model are:
Power Distance Index (PDI): the degree of
equality, or inequality, between people in the
country's society.
Individualism (IDV): the degree the society
reinforces individual or collective, achievement
and interpersonal relationships.
Uncertainty Avoidance Index (UAI): the level of
tolerance for uncertainty and ambiguity within
the society - i.e. unstructured situations.
Masculinity (MAS): the degree the society
reinforces, or does not reinforce, the traditional
masculine work role model of male achievement,
control, and power
Long-Term Orientation (LTO): the degree the
society embraces, or not, long-term devotion to
traditional, forward thinking values
Values for the first four dimensions were defined by
means of surveys in 53 different countries, while the
fifth dimension was defined by means of a survey in
23 countries. In Table 3, values for some of those
countries are shown (Hofstede, 1996).
Table 3: Hofstede’s model values for some countries.
Country PDI IDV UAI MAS LTO
Argentina 49 46 56 86
Australia 36 90 61 51 31
Austria 11 55 79 70
Belgium 65 75 54 94
Brazil 69 38 49 76 65
Canada 39 80 52 48 23
Chile 63 23 28 86
China 118
Spain 57 51 42 86
In order to obtain a value for cultural difference
between two countries in a scale (low, medium,
high), we propose the following formula, where:
i is a dimensions (1: PDI, 2: IDV, 3:UAI,
4:MAS, 5:LTO)
v
i
is a value for the i-th dimension for a given
country
d
i
(A,B) is the distance for the i-th dimension,
calculated as |v
i
(A) – v
i
(B)|
D
A,B
is the cultural distance between countries A
and B, calculated as:
5
D
A,B
=
∑
d
i(A,B)
i=1
For example, based on the values for Argentina and
Spain obtained from Table 3, we have calculated:
Argentina 49 46 86 56
Spain 57 51 86 42
Cultural difference 8 5 0 14
D
Argentina,Spain
= (8+5+0+14) = 27
Applying this formula to each pair of countries,
we have obtained an indicator for cultural difference
between them. In Table 4 we show the values
ICSOFT 2008 - International Conference on Software and Data Technologies
358
calculated for the countries we have presented in
Table 3. We used the symbol “-” to mark the cells
that correspond to the same country. The table is
symmetric since D
A,B
= D
B,A
, since the formula uses
the absolute value to calculate the difference for
each dimension, and addition is commutative.
Finally, we marked with a “*” the cells that are not
possible to calculate because the values known for
both countries do not match (for example, for
Argentina we know the first four dimensions and for
China only the fifth one, then calculation is not
possible).
Table 4: Cultural differences for countries in Table 3.
Argentina
Australia
Austria
Belgium
Brazil
Canada
Chile
China
Spain
Argentina
- 97 86 55 45 86 65 * 27
Australia
97 - 97 94 156 33 162 87 114
Austria
86 97 - 123 111 102 151 * 103
Belgium
55 94 123 - 64 79 88 * 52
Brazil
45 156 111 64 - 145 52 53 42
Canada
86 33 102 79 145 - 143 95 95
Chile
65 162 151 88 52 143 - * 48
China
* 87 * * 53 95 * - *
Spain 27 114 103 52 42 95 48 * -
13
248 90
170
Low Medium High
1
Figure 4: Fuzzy function for cultural difference variable.
Finally, based on the indicators for cultural
difference for all the pairs of countries, we define
the values for the linguistic tags for cultural
difference considering the lowest difference between
to countries (D
min
= 13; which correspond to West
Africa and Indonesia), and the highest difference
between to countries (D
max
= 248; which correspond
to Sweden and Japan). Doing so, we divided the
distance between D
min
and D
max
in similar parts and
defined the values for tags “low”, “medium”, and
“high”, and the corresponding fuzzy function, as it is
shown in Figure 4. In our example between
Argentina and Spain, since the cultural difference
indicator is 27, we can talk about a “low” cultural
difference.
3.4 Stakeholders Cognitive
Characteristics Evaluation
In order to know more about stakeholders, we have
analyzed some instruments from the field of
cognitive psychology designed to measure human
characteristics and explain differences between
people (Miller, 2004). Specifically, we chose a
learning style model, called Felder-Silverman (F-S)
(Felder, 1988 (and author preface written in 2002)),
which analyses the way people receive and process
information, with the aim of making the
environment closer to their cognitive profile.
Stakeholders’ F-S learning styles are obtained by
means of a test that catalogues their preferences
about four categories (perception, input, processing,
and understanding) as slight, moderate and strong
between two opposite subcategories. For instance,
for the category “input”, people are catalogued as
verbal or visual on the scale (slight, moderate,
strong). Then, if people are verbal they would prefer
perceiving information by means of spoken words,
while visual people would prefer graphics. The form
used to gather the test results is similar to the one
that is shown in Figure 5.
-11 -9 -7 -5 -3 -1 1 3 5 7 9 11
Active
√
Reflexive
Sensitive
√
Intuitive
Visual
√
Verbal
Sequential
√
Global
Strong Moderated Slight Moderated Strong
Figure 5: Analyzing cognitive styles with F-S test.
In order to define the types of virtual teams
regarding the stakeholders’ learning style, we focus
on the strongest preferences (values -11, -9, 9, and
11). For example, in the case shown in Figure 5, the
stakeholder is strongly active and strongly intuitive.
In Form 8 (Figure 6) information gathered about
the virtual team members’ cognitive profile is
summarized. Since when preferences are stronger
people may have difficulty when learning in an
environment that does not support their preference
(Felder, 2005), we decided to classify teams
according to the occurrence of strong preferences, as
follows:
Type 1: There are no strong preferences in the
team.
Type 2: There are strong preferences but not at
the opposite sides of the same category. For
instance: if there are strongly visual people in the
team, and there are no strongly verbal people,
communication should be based on diagrams and
EVALUATING FACTORS THAT CHALLENGE GLOBAL SOFTWARE DEVELOPMENT
359
Form: Defining the Virtual Team type
Calculate the number of
stakeholders with strong
preferences for each
subcategory and fill the
middle columns
Nº Nº
Strongly ACTIVE (-11,-9) Strongly REFLEXIVE (11,9)
Strongly SENSITIVE (-11,-9) Strongly INTUITIVE (11,9)
Strongly VISUAL (-11,-9) Strongly VERBAL (11,9)
Strongly SEQUENTIAL (-11,-9) Strongly GLOBAL (11,9)
¿All cells have been filled with zeros? Type 1 (non-strong preferences group)
¿Is there one or more non-zero cells and
their adjacent (in the same row) are always
zero?
Type 2 (strong preferences without conflict
group)
Verify each row and
choose the question whose
answer is “YES”. The
team type is on the right
column
¿Is there one or more non-zero cells and one
of their adjacent (in the same row) is non-
zero, too?
Type 3 (strong preferences with conflict
group)
Figure 6: Virtual team evaluation regarding stakeholders’ cognitive characteristics.
written words, since that would increase the
involvement of visual people, and people with
slight and moderate preferences can be easily
accustom to them.
Type 3: If there are strong preferences at the
opposite sides of the same category, then there is
a conflict of preferences. For example, if there
are one or more strongly visual people, and also
some strongly verbal people, communication
should give support to both kinds of styles, as we
will discuss later.
Rationale behind our decisions is supported by
research results in the field. In the following sections
we will analyze the possible strategies to be used by
a given virtual team, once all these factors have been
evaluated.
4 DEFINING STRATEGIES TO
MINIMIZE GSD PROBLEMS
Once values for time overlap, cultural difference,
language difference and team type regarding
cognitive aspects have been obtained (as we
explained before), we recommend three main
strategies to minimize the problems introduced by
such factors.
For example, regarding cultural difference, the
main problems are related to people’s behaviour. For
instance, USA ranks high about individualism while
collectivism is a common characteristic of Latin
culture (Hofstede, 1996), then interaction between
such countries can be problematic, giving Latin
people the idea that Americans are not compromised
with the group (Audy, 2004) or Americans thinking
that Latin people spent too much time building an
unnecessary social relationship. Since such kind of
misunderstanding about behaviour can be source of
frustration for team members, we propose a first
strategy, called A, which focuses on learning about
the other cultures:
Strategy A: Learning about Cultural Diversity.
Cultural differences cannot be avoided, but
stakeholders can learn about the differences of the
other culture. Being trained about cultural diversity
is crucial for stakeholders to be aware of normal
behaviour in other cultures as well as being
conscious of their own behaviour, especially for
things that can be offensive or misunderstood. To
minimize such kind of problems, we have classified
used strategies as follows:
Literature review, seminars, courses, etc.
Cultural mediation: taking advantage of people
who have visited the other site before – and
therefore they know about customs and normal
behaviour related to the foreign culture – that
become referents for communication with people
at the other site. Those people are called
mediators, bridgeheads (Carmel, 1993) or liaisons
(Herbsleb, 1999).
Virtual mentoring: based on simulation and
virtual actors and it can become an interesting
way for motivating stakeholders in foreign
language training and cultural familiarization
(Sims, 2007).
In addition to cultural diversity, GSD projects
also must deal with language differences. Language
difference can happen in a wide variety of levels,
considering if stakeholders share or not the same
mother language. When people do not share the
native language, English is usually the language
chosen for interaction and it is crucial having a clear
understanding of domain concepts and relationships.
But also when people share the native language, if
they come from different countries, idiomatic
differences are a challenge for communication. For
ICSOFT 2008 - International Conference on Software and Data Technologies
360
instance, people from Argentina and Spain share
Spanish as their native language, but pronunciation
and the use many words can have different meanings
in both sites. Since during the requirements
elicitation process it is crucial having a common
understanding about the system domain, our strategy
to minimize the idiomatic differences is using
ontologies to help communication, as follows:
Strategy B: Using Ontologies as Communication
Facilitators. When stakeholders are not from the
same country of origin, even if they share the mother
language, misunderstanding can arise because some
words have more than one meaning, or different
words refer to the same concept, etc. Sharing a
common vocabulary, especially referring to the
domain components is crucial, and to help to build
it, we propose a domain ontology. In addition,
ontologies play a natural role in supporting
knowledge management, which is very important
during requirements elicitation where a lot of data is
collected from many distant sources. Then,
ontologies make possible clarifying the structure of
knowledge and allow a clear specification of the
concepts and the terms used to represent them
(Chandrasekaran, 1998).
Finally, but not less important, we have
considered the fact that people in GSD projects
apply requirements elicitation techniques by means
of groupware tools. Then, in order to improve
people communication, we have focused on
analyzing how technology selection can influence
people performance. Based on such analysis we
propose a third strategy:
Strategy C: Selection of Suitable Technology.
There are two types of technology that are used
during requirements elicitation: groupware and
requirements elicitation techniques. By analysing the
factors we measured, we aim at choosing the most
suitable technology according to the characteristics
of the virtual team.
There are different points of views to select
technology. The first one is time overlap. In this
case, it is obvious that when time overlap is low
synchronous interaction will be difficult, so we
recommend using asynchronous groupware tools
and avoiding requirements elicitation techniques
based on synchronous interaction (like
brainstorming). Also when the stakeholders’ mother
language is not the same, and the degree of
knowledge of a common language is intermediate or
less, we propose restricting communication to
asynchronous tools, in order to give people the
chance to read and write with greater care.
Finally we propose using knowledge about the
stakeholders’ cognitive characteristics for
technology selection. As we explained
before, one of the factors that it is possible to
know in a virtual team is the cognitive
characteristics that are innate to people and
are related to the way people perceive the
information and understand it. Since
communication in GSD projects is done by
means of groupware tools and requirements
elicitation techniques, we have proposed a
model to obtain preference rules at the
individual level (Aranda, 2005) as well as
strategies to combine the technology
according to the type of virtual team (type 1,
2, or 3), which depends on the occurrences of
people with strong preferences in the given
virtual team (Aranda, 2006). Such strategies
can be summarized as follows:
Strategy for Type 1 (non-strong preferences)
groups, called C
1
, is expressed:
C
1
({g}, GS
1
, GS
2
, …, GS
n
)
→
g
i
∈
{g}
where GS
i
represents the groupware tool that fit
the i-th stakeholder’s preferences (which have been
defined by mechanisms based on fuzzy logic and
fuzzy sets), and g
i
∈ {g} is the tool that appears
more times.
Strategy for Type 2 (strong preferences without
conflict) groups, called C2, is:
C
2
({g}, ({GS
1
}, ws
1
), ({GS
2
},ws
2
), …,
({GS
n
},ws
n
)) → g
i
∈ {g} ∧ g
i
∈ {GS
j
}
∧ ws
j =
max(ws
1
,
ws
2
,…
,
ws
n
)
where GS
i
represents the groupware tool that fit the i-
th stakeholder’s preferences and ws
i
is the weight –
meaning how strong the preferences are—, and the
resulting g
i
is a tool that is appropriate for the stakeholder
whose personal preferences are the strongest.
Strategy for Type 3 (strong preferences with
conflict) groups, called C3, improves the process
by using a different machine-learning algorithm.
To do so, we aim to develop an algorithm that
for each rule returns a ranking of output
variables, instead of only one. Then, when a
conflict is detected, as we have a ranking for
each person, we can browse the ranking for those
people with the strongest preferences, and the
tool that is located higher for all of them will be
the best choice for the team, even though it
would not be the first choice for some, or even
none of them.
In Table 5 we show the strategies suggested for a
combination of factors. Because of space limitations
we show the table only for the “low” cultural
difference, but rows for the “medium” and “high”
values, can be added just filling the strategy A
column with a “”character.
In order to abbreviate the technology selection
strategies names in Table 5, we have used the names
C1, C2, and C3 for strategies according to the group
type, and similarly, we called C4 the technology
EVALUATING FACTORS THAT CHALLENGE GLOBAL SOFTWARE DEVELOPMENT
361
Table 5: Possible scenarios according to the values obtained for each factor.
Same
Country
Cultural
difference
Timetable
Overlap
Degree of knowledge of a
common language
Virtual team
type
Strategies
Y N L M H L M H H HI I LI L 1 2 3 A B C1 C2 C3 C4
Abbreviations: Y=YES, N=No, L=Low, M=Medium, H=High, I=Intermediate
selection strategy based on asynchronous
interaction, which is related to wide time separation
or low knowledge about the common language.
To illustrate the use of this table with an
example, let us consider the case we have analyzed
in a controlled experiment we have recently carried
out. In this experiment we counted on 24 computer
sciences students and teachers from Spanish and
Argentinean universities. Then the value for “Same
Country” was “NO”, and the cultural difference (as
we explained the formula before in Section 3.3) was
27, then the value for this factor was “Low”. Virtual
teams were conformed by 2 Spanish students and 1
Argentinean teacher and their time overlap has been
used as an example in section 3.1, then, the value for
this factor was “Medium”. Finally, as we had
enough people with strong preferences for visual
subcategory, we formed similar Type 2 groups (one
or more people with strong preference without
conflict). As it can be seen in Table 5 (with a
different colour) the strategies suggested to
minimize communication problems in our
experiment where: (1) using a domain ontology to
minimize misunderstandings and (2) choosing the
groupware technology by means of the selection
strategy for Type 2 groups previously explained.
Preliminary results of such experiment indicate that
stakeholder perception about communication is
better in groups that applied the strategy (2), which
is expected to be related to improvement in
requirements quality. In order to corroborate such a
relationship, we asked a group of software
engineering teachers to analyze the requirements
specifications written during our experiment, and we
are currently analyzing such data.
5 CONCLUSIONS
Many organizations have adopted GSD because of
the advantages it represents to minimize costs, but
the cultural diversity and the time difference present
in such kind of projects, challenge the team
performance, especially during requirements
ICSOFT 2008 - International Conference on Software and Data Technologies
362
elicitation when communication is crucial for a
common understanding of de problem.
To help minimize such problems, in this paper
we propose a method to evaluate the factors that are
related to them and we propose a set of strategies
that can be used in each case. Our current work is
focused on analyzing the results of a controlled
experiment that we carried out to test performance
when using domain ontologies and groupware
technology selection in groups with strong
preferences without conflict (type 2). Preliminary
results indicate that groups that used the most
suitable groupware tools, according to our selection
strategy for type 2 groups, felt more comfortable
about communication than groups that did not use
them. Nevertheless more experiments should be
performed in order to be more conclusive.
ACKNOWLEDGEMENTS
This work is partially supported by the MELISA
(PAC08-0142-3315), MISTICO (PBC06-0082-
8542), and MECENAS (PBI06-0024) projects, Junta
de Comunidades de Castilla-La Mancha, Consejería
de Educación y Ciencia, in Spain. It is also
supported by the ESFINGE project (TIN2006-
15175-C05-05) Ministerio de Educación y Ciencia
(Dirección General de Investigación)/ Fondos
Europeos de Desarrollo Regional (FEDER) in Spain;
the CompetiSoft project (506AC0287, CYTED
program); and the 04/E072 project, Universidad
Nacional del Comahue, from Argentina.
REFERENCES
Al-Rawas, A. y Easterbrook, S. (1996): Communication
problems in requirements engineering: a field study. In
First Westminster Conference on Professional
Awareness in Software Engineering, London, p. 47-60.
Aranda, G., Vizcaíno, A., Cechich, A., y Piattini, M. (2005):
A Cognitive-Based Approach to Improve Distributed
Requirement Elicitation Processes. In 4th IEEE
International Conference on Cognitive Informatics
(ICCI'05), Irvine, USA, p. 322-330.
Aranda, G., Vizcaíno, A., Cechich, A., Piattini, M., y
Castro-Schez, J.J. (2006): Cognitive-Based Rules as a
Means to Select Suitable Groupware Tools. In 5th IEEE
International Conference on Cognitive Informatics
(ICCI'06), Beijing, China.
Audy, J., Evaristo, R., y Watson-Manheim, M.B. (2004):
Distributed Analysis The Last Frontier? In 37th Annual
Hawaii International Conference on Systems Sciences
(HICSS), Big Island, Hawaii.
Carmel, E., Whitaker, R.D., y George, J.E. (1993): PD And
Joint Application Design: A Transatlantic Comparison.
Communications of the ACM, Special issue on
graphical user interfaces: the next generation, 36 (6), p.
40-48.
Chandrasekaran, B., Josephson, J.R., y Benjamins, V.
(1998): Ontology of Tasks and Methods. In KAW'98,
Alberta, Canada.
Damian, D. y Zowghi, D. (2002): The impact of
stakeholders geographical distribution on managing
requirements in a multi-site organization. In IEEE Joint
International Conference on Requirements Engineering,
RE'02, Essen, Germany, p. 319-328.
Egan, R.W., Tremaine, M., y Fjermestad, J. (2006): Cultural
Differences in Temporal Perceptions and its Application
to Running Efficient Global Software Teams. In ICGSE
2006, IEEE Intemational Conference on Global
Software Engineering, Vol. 55-61.
Espinosa, J.A. y Carmel, E. (2003): The impact of time
separation on coordination in global software teams: a
conceptual foundation. Software Process: Improvement
and Practice, Wiley InterScience, 8 (4), p. 249-266.
Felder, R. y Silverman, L. (1988 (and author preface written
in 2002)): Learning and Teaching Styles in Engineering
Education. Engineering Education, 78 (7), p. 674-681.
Felder, R. y Spurlin, J. (2005): Applications, Reliability and
Validity of the Index of Learning Styles. International
Journal of Engineering Education, 21 (1), p. 103-112.
Herbsleb, J.D. y Grinter, R.E. (1999): Splitting the
Organization and Integrating the Code: Conway’s Law
Revisited. In 21th International Conference on Software
Engineering (ICSE’99). ACM Press, New York, p. 85-
95.
Hofstede, G. (1996): Cultures and Organizations, Software
of the Mind: Intercultural Cooperation and its
Importance for Survival. 1 ed: McGraw-Hill. I.S.B.N.
978-0070293076,279.
Lloyd, W., Rosson, M.B., y Arthur, J. (2002): Effectiveness
of Elicitation Techniques in Distributed Requirements
Engineering. In 10th Anniversary IEEE Joint
International Conference on Requirements Engineering,
RE'02, Essen, Germany, p. 311-318.
MacGregor, E., Hsieh, Y., y Kruchten, P. (2005): Cultural
patterns in software process mishaps: incidents in global
projects.
ACM SIGSOFT Software Engineering Notes,
30 (4), p. 1-5.
Miller, J. y Yin, Z. (2004): A Cognitive-Based Mechanism
for Constructing Software Inspection Teams. IEEE
Transactions on Software Engineering, 30 (11), p. 811-
825.
Nataatmadja, I. y Dyson, L.E. (2007): The Role of
Information and Communication Technology, In
Information Resources Management, Wai K. Law,
Editor, IDEA Group, p. 283-304.
Prikladnicki, R., Audy, J., y Evaristo, R. (2003): Global
software development in practice lessons learned.
Software Process: Improvement and Practice, Wiley
InterScience, 8 (4), p. 267-281.
Sims, E.M. (2007): Reusable, lifelike virtual humans for
mentoring and role-playing. Computers & Education,
49 (1), p. 75-92.
EVALUATING FACTORS THAT CHALLENGE GLOBAL SOFTWARE DEVELOPMENT
363
