Effect of Outsourcing on Software Development Approaches

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

[email protected]

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


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].


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


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

Effect of Outsourcing on Software Development Approaches

Documents

Transcript of Effect of Outsourcing on Software Development Approaches