Post on 08-Apr-2018
8/7/2019 Effect of Outsourcing on Software Development Approaches
1/4
1
Effect of Outsourcing on Software Development Approaches
Min Chen
Master of Software Engineering
Carnegie Mellon University
Pittsburgh, PA
amchen@cmu.edu
Abstract
Economic forces are turning national markets into global
markets. Globalization of business has caused companies
to be more competitive and to find less costly ways to
build better products. In the software industry, companies
have been outsourcing software development projects and
using the distributed development model in their quest for
lower costs and availability of skilled resources.
Traditional software development approaches are
conceived with the assumption that teams are collocated.
Hence, they do not address the challenges of having
projects outsourced. Many of these approaches have to be
changed in order to be applied to outsourced projects.
There are two ways to address the challenges of
outsourced projects. The first one is to enable effective
communication and, thereby, coordination. The second is
to rely on methodologies and techniques to enable
coordination while minimizing the need of communication
across distributed teams.
The most effective way of coordination with minimum
communication is the use of shared mental models.
Shared mental models are defined as knowledge structuresshared by team members that enable them to form accurate
explanations and expectations for the task. This helps to
coordinate their actions and adapt their behavior to
demands of the task and other team members.
This paper explains new ways of using traditional software
engineering practices to achieve high coordination by
using shared mental models. Planning, defining a processand managing requirements with shared mental models
allow coordination while minimizing the need forcommunication.
1.IntroductionGlobalization of business has caused companies to be
more competitive and to find less costly ways to buildbetter products. In the software industry, companies have
been outsourcing software development projects and using
the distributed development model in their quest for lower
costs and availability of skilled resources.
Software development projects include three
interdependent dimensions people, process, and
technology. The interaction among these three dimensio
becomes even more complex in outsourced projects
because of the coordination and communication overhead.
The outsourcing model is based on distributed
development teams where team members are scattered indifferent places. The lack of effective communication is a
major concern in distributed teams because of the distance
language, culture, time difference and working
environment. Team members are interdependent even
though they have different roles and responsibilities. In
other words, team members must rely on each others
work to accomplish their own tasks. Therefore
communication and coordination are very important. The
major sources of problems in distributed teams are
interdependencies among work items and difficulties of
coordination.
Traditional software development approaches are
conceived with the assumption that teams are collocated
Hence, they do not address the challenges of outsourcing
Many of these approaches have to be changed in order tobe applied to outsourced projects.
Basically, there are two ways to address the challenges of
outsourced projects. The first one is to enable effective
communication and, thereby, coordination. The second isto rely on methodologies and techniques to enable
coordination while minimizing the need of communication
across distributed teams. For example, softwarearchitecture, process and tools help in the coordination of
teams. A plan is critical in dividing the work to beassigned to different teams. An architecture based on
components with independent functionalities helps divide
the work across sites and reduces the amount of interaction
among teams.
Building on the work of previous researchers about
globally distributed teams, this paper proposes changes in
8/7/2019 Effect of Outsourcing on Software Development Approaches
2/4
2
traditional software approaches to encompass the
challenges of outsourced software projects by reducing the
need of communication.
2.Less Communication but More CoordinationThe lack of communication across sites makes
coordination of the distributed teams difficult. Severalresearchers have proposed the use of architecture, process
and tools to coordinate the work of distributed teams. A
plan with well-defined boundaries is critical in dividing
work, so that it can be assigned to different teams. Also, an
architecture based on components with independent
functionalities helps divide the work across sites and
reduces the necessity of interaction among the teams
[Herbsleb 1999a].
Although architectures, plans and processes are very useful
for coordination, they need to be adapted to a distributed
development environment.
Architectures, plans and processes are all vital
coordination mechanisms in software projects. However,
their effectiveness extends only as far as our ability to seeinto the future. Handling the unanticipated both rapidly
and gracefully requires flexible ad hoc communication.
[Herbsleb 1999b].
Advanced telecommunication and collaborationtechnologies help teams to communicate and collaborate.
However, tools do not guarantee good communication.
Technology merely enhances team effectiveness whenteam members already have established relationships and a
sense of common affinity [Carmel 1999]. Email wasfound weak in managing ambiguous information about
requirements. Its lack of interactivity results in lowered
ability to handle ambiguity [Damian 2003]. In spite of the
collaboration tools, distance increases the coordination and
decreases communication [Carmel 1999][Herbsleb 1999b].
The following sections show how software engineering
approaches can be adapted for a distributed development
environment.
3.Planning a ProjectMany software development plans allow concurrent
execution of tasks in order to use the resources more
efficiently. The drawback of this approach is it creates a
high number of task interdependencies; therefore,coordination is critical to avoid rework. Often,
communication is necessary to have a good coordination,
but we already know that communication is the major
concern in distributed environments. For that reason, we
should not rely on communication to achieve coordination
The following are suggestions to achieve coordination
while minimizing communication.
1)Keep planning cycles short for higher visibility. Highvisibility allows teams to solve problems before theybecome critical. This is a good practice for collocated
development teams but it is necessary for distributed
teams because we cannot rely on communication to
achieve visibility.
2)Avoid dependencies among distributed teams within acycle. In other words, avoid assigning interdepende
tasks to distributed members within a planning cycle
If a team cannot deliver on time, the code of all the
other teams will not work because they depend on the
code of the first team. Furthermore, if there was not aclear understanding in the interfaces, the other teams
may have to modify their code in accordance to theactual interfaces. This rework could have been avoided
if the interdependent tasks are distributed across
different planning cycles. By the time a teams
members begin to code, the modules they depend on
are already available. This allows them to have a clear
understanding of the interfaces and to test their code.
3)Keep coordination centralized. A team or a personmust be responsible for looking after the activities a
the different sites. This team or person should enable
channels of direct communication with each
distributed team.
4)Define a process for coordination. The followingsection of this paper has more details about defining
processes.
4.Using a ProcessProcesses are empirically understood by collocated teams
members. However, they must be defined clearly whenteams are distributed in order to have a good
understanding of the coordination. This is the reason many
organizations choose CMM level 5 companies to
outsource the software project.
Researchers have demonstrated that work familiarity and
shared mental models help teams coordinate. Tools only
go so far in helping distributed teams to increase
communication and productivity. When team membe
are familiar with their work and have shared knowledge of
the process and other team members, they are more
coordinated and perform better [Espinosa 2002].
8/7/2019 Effect of Outsourcing on Software Development Approaches
3/4
3
The following are suggestions when defining a process in
a distributed development environment.
1)Define a global process to be followed by all the
distributed teams to allow coordination without
communication. This global process should only take
care of the high-level tasks, such as a global code
integration process and coding standard. Localprocesses define the low-level tasks. A global process
facilitates the coordination of development by
providing a shared understanding of the purpose and
desired outcomes. It gives all the members of the team
a common direction.2)Define the requirements for local processes. In
addition to being geographically distributed, members
of the distributed teams come from different corporate
cultures, use different tools, follow conflicting
standards, and often speak different languages. Thus, aprocess that works for teams in one place might not
work for teams in other places. Therefore, distributedteams should be allowed to have a local process that is
compliant with the global process. As long as the
teams deliver what is specified in the global process,
they can do whatever works best for them locally. For
example, each team is allowed to have their own
configuration management process, but the team must
follow the rules of the global process when integrating
its code with other teams.
5.Managing RequirementsRequirements engineering is a task difficult enough whendone locally -- but it is even more difficult when cross-
functional stakeholder groups specify requirements acrosscultural, language and time zone boundaries. [Damian
2003].
The lack of informal communication diminishes the
awareness of local work context because it causesinsufficient familiarity with the activities of remote group
members and background information that make work
contexts meaningful. This leads to misinterpretation of
actions, due to stereotyping about cultures and working
styles [Damian 2003]. Hence, it makes more sense to have
a local team gather the requirements from the customer in
order to minimize the misinterpretations. Local team in
this context means a team whose members are original
from the place where the customer is from. The advantage
of using a local team is that the members understand the
local rules, working styles, and culture. Members also
speak the same language as the customer.
Another challenge when dealing with requirements is how
to communicate them in an unambiguous way to the rest of
the teams whose members might be in other countries andspeak different languages.
The most effective way of coordination without
communication is the use of shared mental models
Shared mental models are defined as knowledgestructures held by members of a team that enable them to
form accurate explanations and expectations for the task
and, in turn, to coordinate their actions and adapt their
behavior to demands of the task and other team members
[Cannon-Bowers 1993]. These models help teamembers develop accurate explanations and expectations
about tasks and other members behavior [Espinosa
2002].
An architecture design can be a form of shared mentalmodel if all the team members understand it. Software
architectures describe how a system is decomposed intocomponents, how these components are interconnected
and how they communicate and interact with each other
When poorly understood, these aspects of design are major
sources of errors.
The problem of using an architecture design to
communicate the requirements is that there is no standard
and unambiguous way to do this without writing a
document. Language issues arise regardless of the
language the architecture document is written in.
Members of other teams might not speak the same
language. Furthermore, natural languages, such as Englishand Spanish, are full of ambiguities.
Besides an architecture design, teams can use the projects
programming language to communicate the requirements
In fact, the programming language is the only shared
mental model that all the team members have. The
programming language of a particular project is wel
understood by all the distributed teams.
To use the programming language as a requirements
definition tool, teams should write the testing code before
the functional code. This technique is called Test-DrivDevelopment (TDD).
TDD is also known as test-first programming or test-firs
development. It was introduced by Kent Beck in his
eXtreme Programming (XP) method.
TDD is one way of specifying the acceptance tests. These
tests can form an important part of the requirements
documentation because they define exactly what the
8/7/2019 Effect of Outsourcing on Software Development Approaches
4/4
4
stakeholders expect from system; therefore, they specify
the critical requirements.
6.ConclusionTraditional software engineering practices assume that
development teams are collocated; hence, they rely on
communication among team members to help incoordination. These practices have to be adapted for
outsourced projects because these projects follow the
distributed development teams model.
This paper explained new ways to use traditional software
engineering practices in a distributed development
environments. However, there is no formula to make a
distributed development project successful, but only
general rules of thumb.
References
[Aoyama 1998] Aoyama, M., Agile Software Process and Its
Experience. IEEE, 1998
[Beck 2000] Beck, K., Extreme Programming Explained: Embrace
Change. Addison-Wesley, 2000
[Cannon-Bowers
1993]
Cannon-Bowers, J., Salas, E., and Converse, S., Shared
Mental Models in Expert Team Decision Making.Lawrence Earlbaum and Associates, Inc., 1993
[Carmel 1999] Carmel, E., Global Software Teams. Prentice-Hall, 1999
[Cubranic] Cubranic, D., and Booth, K., Coordinating Open-
Source Software Development. Canada
[Damian 2003] Damian, D., and Zowghi, D., Requirements Engineering
challenges in multi-site software
development organizations. Requirements Engineering
Journal, 2003
[Dustdar 2002] Dustdar, S., and Gall, H., Process Awareness forDistributed Software Development in Virtual Teams.
IEEE, 2002
[Edwards 2002] Edwards, H., and Sridhar V., Analysis of the
Effectiveness of Global Virtual Teams in Software
Engineering Projects. IEEE, 2002
[Espinosa 2001] Espinosa, J., Kraut, R., Lerch, J., Slaughter, S.,
Herbsleb, J., and Mockus, A., Shared Mental Models
and Coordination in Large-Scale, Distributed Software
Development. Twenty-Second International Conferenceon Information Systems, 2002
[Espinosa 2002] Espinosa, J., Kraut, R., Lerch, J., Slaughter, S.,
Herbsleb, J., and Mockus, A., Shared Mental Models,Familiarity, and Coordination: A Multi-method Study of
Distributed Software Teams. Twenty-Third
International Conference on Information Systems
[Goodman 1991] Goodman, P., and Leyden, D., Familiarity and Group
Productivity. Journal of Applied Psychology, 1991
[Grinter 1999] Grinter, R., Herbsleb, J., and Perry, D., The Geography
of Coordination: Dealing with Distance in R&D Work.
ACM, 1999
[Haywood 2000] Haywood, M., Working in Virtual Teams: A Tale of
Two Projects and Many Cities. IEEE, 2000
[Herbsleb 1999a] Herbsleb, J. and Grinter R., Splitting The Organization
and Integrating the Code: Conway's Law Revisited
International Conference on Software Engineering
1999
[Herbsleb 1999b] Herbsleb, J., and Grinter, R., Architectures
Coordination, and Distance: Conway's Law andBeyond. IEEE, 1999
[Herbsleb 2001b] Herbsleb, J., and Moitra, D., Global Software
Development. IEEE Software, 2001
[Herbsleb 2003] Herbsleb, J., and Mockus, A., An Empirical Study of
Speed and Communication in Globally-Distributed
Software Development. IEEE, 2003
[Johansson 1999] Johansson, C., Dittrich, Y., and Justila, A., Softwar
Engineering Across Boundaries: Student Project in
Distributed Collaboration.
[McBreen 2003] McBreen, P., Questioning Extreme Programming
Addison-Wesley, 2003
[Mockus 2001] Mockus, A. and Herbsleb J., Challenges of Globa
Software Development. IEEE, 2001
[Ramesh 2002] Ramesh, G., Managing Global Software Projects
McGraw-Hill, 2002
[Wake 2002] Wake, W., Extreme Programming Explored. Addison
Wesley, 2002
[Williams 2003] Williams, L. and Kessler, R., Pair Programming
Illuminated. Addison-Wesley, 2003