ARQUITETURA DISTRIBUÍDA DE SOFTWARE PARA AMBIENTE DE DESENVOLVIMENTO DISTRIBUÍDO

1. PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL
FACULDADE DE INFORMÁTICA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DE COMPUTAÇÃO
ARQUITETURA D ISTRIBUÍDA DE SOFTWARE PARA
AMBIENTE DE DESENVOLVIMENTO DISTRIBUÍDO
ESTEVÃO RICARDO HESS
Orientador: Prof. Dr. Jorge Luis Nicolas Audy
Porto Alegre
2010

2. 2
Arquitetura Distribuída de Software para Ambiente de Desenvolvimento
Distribuído
RESUMO
No ambiente em que estamos vivendo atualmente, o processo de
globalização está se destacando, o que está gerando grande desafio para a área
de Engenharia de Software (ES), tornando o desenvolvimento de software cada
vez mais distribuído e global. Em busca de vantagens competitivas, tais como
baixo custo, ganho de produtividade e qualidade, as organizações optam por
distribuir o processo de desenvolvimento de software em outros países com custo
de produção mais acessível. Cada vez mais projetos estão sendo desenvolvidos
em ambientes geograficamente distribuídos, caracterizando o desenvolvimento
distribuído de software (DDS), que está tornando-se uma tendência na indústria.
Entretanto, os desafios apresentados pela distribuição das equipes envolvidas no
processo de desenvolvimento de software são significativos. Portanto, torna-se
cada vez mais importante encontrar maneiras de atenuar estas dificuldades. Este
trabalho apresenta diversos tipos de arquiteturas de softwares. Após fazer uma
análise sobre as necessidades de DDS em relação à arquitetura de software,
mostra que uma arquitetura de software orientada a serviço pode suavizar
diversos problemas inerentes ao DDS.
Palavras Chave: Desenvolvimento distribuído de software, Engenharia de
software, Arquitetura de Software, Arquitetura Orientada a Serviço

3. 3
Arquitetura Distribuída de Software para Ambiente de Desenvolvimento
Distribuído
ABSTRACT
Nowadays, in the environment we are living, the globalization process is
getting emerging, what is generating huge challenges to the software engineering
area, making the software development more distributed and global. Looking for
the competitive advantages as low coast, productivity gains and quality,
organizations choose to distribute their software development process to other
countries with production costs more affordable. Increasingly, projects are being
developed in geographically distributed environments, featuring the distributed
software development, which is becoming a trend in the industry. However, the
challenges posed by the involved teams’ distribution in the software development
are significant. Therefore, it becomes increasingly important to find ways to
alleviate these difficulties. This paper presents some different types of software
architectures. After an analysis on the needing for distributed software
development in relation to software architecture, it is posed that service oriented
architecture can alleviate many problems inherent to distributed software
development.
Keywords: Distributed Software Development, Software Engineer,
Software Architecture, Service Oriented Architecture.

4. 4
LISTA DE TABELAS
Tabela 1. Integração Central ..................................................................... 33
Tabela 2. Agrupamento de Releases......................................................... 33
Tabela 3. Release Trains ........................................................................... 34
Tabela 4. Comparação entre trabalhos realizados .................................... 43

5. 5
LISTA DE FIGURAS
Figura 1. AS baseado em camadas, adaptado de [CUR08] ...................... 11
Figura 2. Arquitetura de software cliente-servidor ..................................... 12
Figura 3. Simples esquemático de Arquitetura Orientada a Serviços ........ 14
Figura 4. Estrutura WSDL, adaptado de [DIA08] ....................................... 16
Figura 5. Relacionamento entre empresas, adaptado de [AUD07]............ 21
Figura 6. Nível de confiança durante projeto [AUD07] ............................... 24
Figura 7. Estrutura definição de serviço [BIN07]........................................ 38
Figura 8. Estrutura de uma tarefa [MOC01] ............................................... 40

6. 6
LISTA DE ABREVIATURAS E SIGLAS
AS Arquitetura de Software
DDS Desenvolvimento Distribuído de Software
ES Engenharia de Software
ESB Enterprise Service Bus
GSD Global Software Development
IDE Integrated Development Environment
MVC Model-View-Controller
SOA Service-Oriented Architecture
SOAP Simple Object Access Protocol
SQA Software Quality Assurance
UDDI Universal Description, Discovery and Integration
VPN Virtual Private Network
WSDL Web Services Description Language
XML Extensible Markup Language

7. 7
SUMÁRIO
1 INTRODUÇÃO ............................................................................................... 8
2 BASE TEÓRICA .......................................................................................... 10
2.1 Arquitetura de Software ......................................................................... 10
2.1.1 Arquitetura de Software Orientada a Serviço (SOA) ....................... 14
2.2 Desenvolvimento Distribuído de Software ............................................. 19
2.3 Relacionando DDS e AS ....................................................................... 28
3 TRABALHOS RELACIONADOS .................................................................. 32
3.1 Abordagem de Bosch e Bosch-Sijtsema (2010) .................................... 32
3.2 Abordagem de Martignoni (2009) .......................................................... 36
3.3 Abordagem de Xu (2007) ...................................................................... 37
3.4 Abordagem de Mockus e Weiss (2001) ................................................. 39
3.5 Abordagem de Herbsleb e Grinter (1999).............................................. 41
3.6 Análise comparativa .............................................................................. 42
4 CONSIDERAÇÕES FINAIS ......................................................................... 45
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................... 46

8. 8
1 INTRODUÇÃO
No ambiente em que estamos vivendo atualmente, o processo de
globalização está se destacando, o que está gerando grande desafio para a área
de Engenharia de Software (ES), tornando o desenvolvimento de software cada
vez mais distribuído e global [AUD07]. Hoje em dia, mais projetos estão sendo
desenvolvidos em ambientes geograficamente distribuídos, caracterizando o
Desenvolvimento Distribuído de Software (DDS), que está tornando-se uma
tendência na indústria [DAM06]. O DDS é caracterizado sempre que um ou mais
recursos envolvidos no projeto estiver fisicamente distante dos demais [AUD07].
Pode-se dizer também que uma equipe global de desenvolvimento de software
está tipicamente em países diferentes, porém colaborando em um mesmo projeto
de qualquer naturalidade (criação ou manutenção de software) [LAN08].
A arquitetura de software (AS) pode ser considerada uma importante área
dentro da área de ES, pois é uma etapa que une a especificação funcional dos
requisitos de um software e a sua codificação, resultando no produto final. A AS,
segundo Kruchten, Obbink e Staford [KUR06], pode ser definida como a estrutura
pela qual componentes e subcomponentes de sistemas interagem entre si, com o
objetivo de formar um sistema. Para apoiar o DDS, o mais apropriado seria a
utilização de arquiteturas de softwares modulares [AUD07]. Dentre as diversas
arquiteturas de software utilizadas atualmente, podemos citar Arquitetura
Orientada a Serviço (SOA, do inglês Service-Oriented Architecture), uma
arquitetura modular, a qual será um dos objetivos deste trabalho. Esta arquitetura,
largamente difundida, é caracterizada por utilizar serviços para suportar o
desenvolvimento de aplicações de baixo acoplamento, grande interoperatibilidade
e de distribuição em massa [PAP07]. Seus serviços podem ser autônomos, com
entidades independentes de plataforma e de sistema operacional, podem ser
descritas, publicadas e encontradas na rede, os serviços podem executar desde
pequenos processamentos para responder a uma requisição até a execução de
complexas regras de negócio [PAP07]. Qualquer parte do código ou componente
instalado no sistema pode ser reutilizado e transformado em um serviço
disponível na rede.

9. 9
Dentro desta área de estudo, este trabalho será desenvolvido com o
objetivo de relacionar duas áreas distintas dentro de um mesmo contexto:
Desenvolvimento Distribuído de Software (DDS) e Arquitetura de Software
Orientada a Serviços (SOA).
Este tema torna-se relevante devido aos trabalhos recentes que
demonstram o crescimento do uso do DDS na indústria de desenvolvimento de
software. Conforme [DAM06, HER01], a busca das vantagens competitivas
encontradas no desenvolvimento distribuído direciona as organizações no
caminho do DDS, o que está tornando-se uma norma no mercado atual. A
justificativa do tema, ainda pode ser constatada devido ao fato de diversos
autores afirmarem que a arquitetura orientada a serviço está crescendo muito
rapidamente no mercado nos últimos anos e tornando-se uma tendência nos
projetos de desenvolvimento de software [HON09, PAP07, DIA08, KUA08,
WAU09, SHR05].
Para alcançar os objetivos citados, este trabalho estará estruturado da
seguinte forma: a seção dois destinada a apresentar a Base Teórica envolvendo
as áreas de Arquitetura de Software, com foco em SOA, e desenvolvimento
distribuído de software; a seção três aborda os Trabalhos Relacionados,
mostrando estudos já realizados nesta área; e, finalmente, na seção quatro será
exposto as Considerações Finais, onde será realizada uma análise crítica da
pesquisa em desenvolvimento.

10. 10
2 BASE TEÓRICA
Com equipes cada vez maiores, e com a grande complexidade dos
sistemas de informação que são construídos atualmente, a padronização nos
processos de desenvolvimento de software torna-se vital para o sucesso dos
projetos. Neste sentido, emerge a área de Arquitetura de Software (AS). Sendo
assim, neste capítulo apresentam-se detalhes sobre AS e o processo de
Desenvolvimento Distribuído de Software (DDS). Na seção 2.1 são apresentadas
definições de arquiteturas de software. Na seção 2.1.1 será abordada em
profundidade a arquitetura orientada a serviços. Na seção 2.2 são apresentados
detalhes sobre desenvolvimento distribuído de software, e finalmente na seção
2.3 será mostrado a importância da arquitetura de software no DDS.
2.1 Arquitetura de Software
Arquitetura de Software (AS) pode ser definida de diversas formas.
Valipour, Amirzafari, Maleki e Daneshpour [VAL09] definem arquitetura de
software como sendo um conjunto de planos os quais ajudam na construção,
manutenção e o uso de sistemas de informação que objetivam a resolução de
diversos problemas das empresas.
Já segundo Kruchten, Obbink e Staford [KUR06], pode ser definida como a
estrutura pela qual componentes e subcomponentes de sistemas interagem entre
si, com o objetivo de formar um sistema.
Para o desenvolvimento deste trabalho, adotaremos a definição
apresentada por Kruchten, Obbink e Staford [KUR06]. Esta escolha foi realizada
devido ao fato dos autores mostrarem que a interação entre componentes é
utilizada para a construção de um sistema, o que nos remete a arquiteturas
modulares, como por exemplo, arquitetura orientada a serviços.
Atualmente, existem inúmeros tipos de AS. O objetivo desta seção é
apresentar os principais tipos de arquitetura encontrados na literatura de
processos de desenvolvimento de software:

11. 11
- Arquitetura de Software Baseado em Camadas
Um exemplo de AS baseada em camadas, é o MVC (do inglês, Model-
View-Controller). O MVC caracteriza-se por separar o sistema em models, que
representam a funcionalidade principal de sistema, views que exibem os modelos
aos usuários do sistema e, finalmente em controllers que permitem ao usuário
fazer modificações nos models [MAH99], ou seja, representam as regras de
negócio da aplicação.
Esta AS tem nível baixo de acoplamento, pois acesso a dados, regras de
negócios, e a interação com o usuário estão localizadas em diferentes camadas
[CUR08]. A arquitetura MVC é mais comumente encontrada em aplicações
desenvolvida para a internet. Nestes tipos de aplicações é comum separar dados,
interface com o usuário e regras de negócio em diferentes camadas, conforme
mostrado pela Figura 1.
Figura 1. AS baseado em camadas, adaptado de [CUR08]
Dentre os pontos fortes da arquitetura baseada em camadas, pode-se
destacar, o baixo nível de acoplamento entre as camadas [CUR08] e a facilidade
de ser implementada nas linguagens de programação mais utilizadas atualmente,
normalmente com auxílio de ferramentas de desenvolvimento de software que
dão suporte a este tipo de sistema [MAH99].
Apesar de ser altamente utilizada, este tipo de arquitetura de software
possui alguns pontos fracos, dentre eles, é possível destacar a dificuldade de

12. 12
separar totalmente a camada view e camada controller, pois as ferramentas de
programação mais utilizadas atualmente (IDEs) normalmente misturam as
entradas e saídas destas duas camadas [MAH99]. Outro ponto fraco a ser
destacado é o desempenho desta arquitetura que devido a grande interação entre
as camadas pode acabar sendo um problema difícil de ser tratado [MAH99].
- Arquitetura Cliente-Servidor
A arquitetura cliente-servidor caracteriza-se pela troca de mensagens entre
quem solicita a execução de uma tarefa (cliente) e quem irá, de fato, executar
esta tarefa (servidor) [RAV89]. O funcionamento acontece do seguinte modo: os
processos que implementam os serviços, são chamados servers. Os servers
expõem uma visão abstrata dos seus serviços, onde ficam descritas as suas
operações (também conhecidos como stubs). Os clientes têm acesso a essas
visões abstratas e, a partir delas, é possível fazer as requisições aos servers
[RAV89].
Os servers podem, em determinados momentos, ser ao mesmo tempo
servidor e cliente. Isso acontece quando o serviço solicitado a um servidor, está
implementado em outro servidor, onde o mesmo é chamado para realizar a tarefa
[RAV89].
O esquema mostrado na Figura 2 apresenta uma maneira como essa
arquitetura pode ser implementada, incluindo o caso onde um servidor pode ser
considerado cliente e servidor ao mesmo tempo.
Figura 2. Arquitetura de software cliente-servidor

13. 13
Dentre os pontos fortes desta arquitetura, podemos citar a centralização do
processamento e armazenamento de dados, o que facilita o controle do acesso às
informações do sistema. Como o controle de segurança é realizado no lado do
servidor, o sistema tem maior facilidade no controle aos dados e recursos,
garantindo assim que apenas os clientes com as permissões apropriadas possam
acessar e alterar dados. Outra vantagem desta arquitetura está na manutenção,
pois é possível reparar, realizar upgrades ou substituir servidores, com um baixo
impacto para os clientes. Apenas determinados serviços serão afetados.
Alguns pontos fracos da arquitetura cliente-servidor que podemos destacar
é que, conforme o número de clientes cresce, o número de chamadas
simultâneas para um mesmo servidor pode ocasionar uma sobrecarga. Outro
ponto importante a ser destacado é que ao acontecer uma falha no servidor, os
clientes não terão os serviços deste servidor disponível, ou seja, algumas (ou até
mesmo todas) requisições não serão mais processadas.
- Arquitetura Orientada a Serviços
Arquitetura Orientada a Serviço (SOA, do inglês Service-Oriented
Architecture), é uma arquitetura largamente difundida, caracterizada por utilizar
serviços para suportar o desenvolvimento de aplicações de baixo acoplamento,
grande interoperatibilidade, por ser altamente escalável e por sua facilidade de
distribuição [PAP07]. Seus serviços podem ser autônomos, com entidades
independentes de plataforma e de sistema operacional, podem ser descritas,
publicadas e encontradas em uma rede (intra ou extranet). Os serviços podem
executar desde pequenos processamentos para responder a uma requisição até a
execução de complexas regras de negócio [PAP07]. Qualquer parte do código ou
componente instalado no sistema pode ser reutilizado e transformado em um
novo serviço disponível na rede.
SOA é uma arquitetura para sistemas distribuídos. Através do uso de
interfaces previamente definidas entre os vários componentes da aplicação,
também chamados de serviços, os sistemas integram estes serviços com o
objetivo de alcançar requisitos do sistema. A Figura 3 mostra um esquema muito
simples que ilustra este comportamento, apenas para dar uma idéia como é o
funcionamento de uma arquitetura orientada a serviço. Nesta figura é possível

14. 14
observar que existem três serviços expostos na rede, onde tem duas aplicações
que poderiam combinar estes componentes de diversas maneiras, para que os
seus requisitos sejam alcançados de forma satisfatória. Por exemplo, a Aplicação
ABC que foi implementada usando tecnologia Java precisa consultar um
componente que foi implementado em .Net, que está exposto na rede, e logo
após realizar uma consulta ao banco de dados. Enquanto que a Aplicação XYZ
realizará apenas uma consulta à base de dados. A regra de negócio das duas
aplicações é completamente diferente, porém conforme ilustrado, para ambos os
casos, esta arquitetura seria suficiente para resolver o problema, apenas
combinando de maneira correta as chamadas aos componentes. A próxima seção
2.1.1 irá discutir com maior profundidade o funcionamento desta arquitetura, suas
formas de implementação e as principais vantagens e desvantagens desta
arquitetura.
Figura 3. Simples esquemático de Arquitetura Orientada a Serviços
2.1.1 Arquitetura de Software Orientada a Serviço (SOA)
Conforme apresentado nos objetivos deste trabalho, pretende-se mostrar o
relacionamento de uma arquitetura de software orientada a serviço (SOA) com o
desenvolvimento distribuído de software (DDS). Neste sentido, esta seção irá
mostrar, buscando na literatura, as principais definições para SOA. Será
mostrado, ainda, como SOA pode ser utilizado, as melhores práticas na utilização

15. 15
desta arquitetura e, finalmente, as principais vantagens e desvantagens na
utilização de SOA.
Existem várias maneiras de definir SOA. Diferentes autores mostram
definições distintas, porém todas convergem para uma mesma direção. Para Xie
Dan et al [DAN08], SOA é uma arquitetura de software desenvolvida para criar um
ambiente dinâmico de serviços dispostos em rede, possíveis de serem usados
como componentes. Definindo de uma forma abstrata, SOA pode ser descrita
como um conjunto de componentes que podem ser utilizados, e os quais, suas
definições de interfaces podem ser descritas na rede para que os mesmos
possam ser encontrados [DAN08]
Segundo Hongqi Li et al [HON09], SOA é um modelo de arquitetura de
software para sistemas distribuídos, a qual utiliza padrões e interfaces bem
definidas dentre todas as unidades funcionais, conhecida como serviços ou
componentes. As junções destes diversos serviços criam um sistema através da
rede. Estes serviços devem estar dispostos na rede de forma que os mesmos
possam ser encontrados e utilizados [HON09].
Já para Michael Papazoglou et al [PAP07] SOA pode ser definida como
uma arquitetura que utiliza serviços para suportar o desenvolvimento de
aplicações de forma mais rápida, com menor custo, baixo acoplamento, grande
interoperatibilidade e de distribuição em massa. Seus serviços podem ser
autônomos, com entidades independentes de plataforma e de sistema
operacional, podem ser descritas, publicadas e encontradas na rede, os serviços
podem executar desde pequenos processamentos para responder a uma
requisição até a execução de complexas regras de negócio. Qualquer parte do
código ou componente instalado no sistema pode ser reutilizado e transformado
em um serviço disponível na rede [PAP07].
Conforme visto anteriormente, sistemas orientado a serviços mostram a
idéia de acomodar componentes de uma aplicação em uma rede de serviços com
o objetivo de criar aplicações flexíveis, com processos dinâmicos de negócios e
de rápida implementação. Este tipo de arquitetura pode ser desenvolvida de
inúmeras maneiras, porém, a mais utilizada no mercado atualmente é através de
web-services [HON09, DIA08].

16. 16
Para que a construção desta arquitetura seja realizada de forma correta e
padronizada, é necessário o conhecimento de alguns dos principais protocolos
que os serviços devem utilizar [HON09, DIA08].
- SOAP:
Para assegurar que as trocas de mensagens entre componentes
aconteçam de forma correta, é utilizado o protocolo SOAP (do inglês, Simple
Object Access Protocol) [PAP07]. Este mecanismo consiste da definição de um
modelo de mensagem XML que deverá ser trocada entre os serviços [DIA08].
- WSDL:
Para garantir o baixo acoplamento entre os componentes, é utilizado um
XML que descreve o funcionamento do serviço, denominado de WSDL (do inglês,
Web Services Description Language) [PAP07, DIA08]. Neste XML, estão descritos
as assinaturas dos métodos expostos, seus parâmetros e tipos de retorno. O
WSDL pode ser considerado um contrato entre os provedores e os consumidores
dos serviços [DIA08]. A Figura 4 mostra o conteúdo que esta mensagem deve
possuir.
Figura 4. Estrutura WSDL, adaptado de [DIA08]
- UDDI:
Para que os serviços expostos possam ser encontrados, utiliza-se o UDDI
(do inglês, Universal Description, Discovery and Integration) [OAS10]. Este padrão
descreve como as informações de um serviço devem ser armazenadas para que

17. 17
a publicação e a descoberta destas informações sejam realizadas de forma
correta [DIA08].
Para a construção de um software baseado em serviços é necessário que
haja uma estrutura de comunicação interligando todos os componentes ou
serviços e a essa estrutura é dado o nome de Enterprise Service Bus (ESB)
[HON09]. Nesse tipo de arquitetura, o software é dividido em módulos, que são
empacotados como componentes ou serviços e fornecem funcionalidades bem
definidas e são independentes dos outros serviços existentes [HON09].
Finalmente estes componentes são instalados no ESB. A utilização deste tipo de
estrutura ao sistema agrega grandes vantagens. Os benefícios que mais se
destacam, além dos já citados anteriormente são [DAV08]:
- Transparência de localização: não é necessário que o cliente tenha o
conhecimento onde o serviço está fisicamente. O cliente precisa saber apenas um
endereço lógico para o serviço. Desta maneira, o gerenciamento dos serviços
pode ficar mais flexível. É possível adicionar, mover ou remover serviços sempre
que necessário sem que haja a necessidade de qualquer alteração nos clientes
[DAV08].
- Mediação: como o ESB fica entre os clientes e os provedores de serviço,
uma grande vantagem deste artefato é a possibilidade de adicionar valor à
arquitetura sem alterar nem os serviços nem os clientes. Como as chamadas são
realizadas através desta camada, as mensagens recebidas e envidas podem, de
forma apropriada, sofrer transformações, ou serem enviadas a outros serviços e
criando assim, uma composição de serviços, mantendo a transparência para os
clientes [DAV08].
- Composição de serviços: o ESB pode fazer o papel de um roteador de
mensagens, fazendo assim a chamada de inúmeros serviços, fazendo a
composição dos resultados, e finalmente retornando a mensagem para o cliente.
Para o cliente será apenas uma única chamada [DAV08].
- Segurança: sendo o ESB uma camada intermediária entre os serviços e
os clientes, fica apropriado que a segurança resida nesta camada. Toda a
requisição recebida passará obrigatoriamente pela segurança [DAV08].

18. 18
- Monitoramento: como todos os serviços disponíveis estão expostos para
os clientes através do ESB, é possível que o monitoramento destes serviços seja
realizado por esta camada. Existem duas principais formas de realizar o
monitoramento através do ESB: proativa e reativa. Na proativa, é monitorado
como está o desempenho do sistema e é possível através desses dados obtidos
saber o momento de fazer um aumento da capacidade do sistema.
Diferentemente, na abordagem reativa, o administrador do sistema define
métricas para monitorar e para cada uma destas métricas são definidas condições
que poderiam gerar problemas. Ao alcançar estas condições, o sistema dispara
alarmes e os envia para os administradores analisarem os problemas.
Atualmente, diversas empresas disponibilizam implementações comerciais
de Enterprises Service Bus, entre as mais conhecidas estão Oracle e JBoss
[DAV08, JBO10].
Diversos autores afirmam que a arquitetura orientada a serviço está
crescendo muito rapidamente no mercado nos últimos anos, tornando-se uma
tendência nos projetos de software [HON09, PAP07, DIA08, KUA08, WAU09,
SHR05]. Esse crescimento está diretamente ligado às vantagens que esta
arquitetura disponibiliza. A relação de vantagens a seguir, mostra as mais citadas
pelos autores e, certamente, não é uma lista definitiva: baixo acoplamento,
possibilidade do reuso, a modularidade [HON09, DAV08, DIA08], possibilidade de
compor serviços para gerar um novo serviço [HON09, DIA08], baixo custo na
construção de serviços, ou até mesmo utilizando a compra de componentes de
terceiros [PAP07, WAU09], flexibilidade [DIA08].
Apesar das inúmeras vantagens que esta arquitetura oferece, algumas
desvantagens podem ser identificadas. Segundo Hongqi Li et al [HON09] a
utilização de um Enterprise Service Bus, pode dificultar o sucesso do projeto. A
justificativa do autor para esta afirmação é que a utilização do ESB pode
aumentar o custo do projeto, prejudicar a flexibilidade do sistema como um todo e,
finalmente, por ser um ponto centralizador da arquitetura, ao causar falhas,
poderia comprometer todo o sistema.

19. 19
2.2 Desenvolvimento Distribuído de Software
No ambiente em que estamos vivendo atualmente, o processo de
globalização está se destacando, gerando um grande desafio para a área de
engenharia de software (ES). Na busca de vantagens econômicas na construção
de softwares [PRI09], empresas estão tornando o desenvolvimento cada vez mais
distribuído e global. Hoje em dia, mais projetos estão sendo desenvolvidos em
ambientes geograficamente distribuídos, caracterizando o Desenvolvimento
Distribuído de Software (DDS), o qual está tornando-se uma norma na indústria
de software [DAM06, HER01].
As empresas de software são levadas ao uso de DDS, pois a construção
de software torna-se cada vez mais cara, e a competitividade da empresa diminui
[PRI09]. Desta maneira, empresas utilizam o DDS com o objetivo de reduzir seus
custos de produção de software e, portanto, aumentar a sua competitividade no
mercado [PRI08]
O DDS não é um conceito novo. DDS surgiu nos anos 90, onde as
empresas começaram a desenvolver software com times distribuídos [LAN08]. O
DDS é caracterizado sempre que um ou mais recursos envolvidos no projeto
estiver fisicamente distante dos demais [AUD07]. Quando a distância física entre
os elementos dos times do projeto abrange mais de um país, caracteriza-se o
Desenvolvimento Global de Software (GSD, do inglês Global Software
Development) [LAN08].
As formas de distribuição das equipes em DDS podem variar entre as
companhias. A escolha da forma de utilização do DDS deve ser realizada com
base no tipo de projeto a ser desenvolvido. Com isso, torna-se relevante a
definição de alguns conceitos utilizados para realizar esta caracterização:
Outsourcing e Insourcing (formas de relacionamento entre empresas); Inshore e
Offshore (distribuições geográficas).
Outsourcing: também conhecido como terceirização é a contratação de
uma empresa para realizar um serviço. É encontrado no momento em que uma
empresa designa uma tarefa a ser realizada por uma empresa contratada [PRI09].

20. 20
Alguns autores defendem que esta é a forma mais fácil e rápida de
implementação [AUD07, BIN07].
Insourcing: conceito que surgiu em oposição ao outsourcing [PIL06]. Este
conceito é caracterizado quando as empresas criam os seus próprios centros de
desenvolvimento. Dentre os motivos que levam a utilização do insourcing está o
maior controle sobre os negócios da empresa, a maior flexibilidade e o menor
custo a longo prazo [AUD07]. Este modelo é considerado o que possui maior
complexidade e que demanda mais tempo para sua implementação.
Offshore: consiste em enviar serviços ou projetos para uma companhia
localizada em um país diferente da localização da matriz [PIL06]. Pode ser uma
empresa contratada ou até mesmo uma subsidiária da matriz [AUD07]. Países
componentes do grupo econômico BRIC estão cada vez mais tornado-se uma
alternativa atraente para este tipo de serviço, pois apresentam baixos custos
comparados com Estados Unidos e Europa. A motivação para a utilização deste
modelo está na redução de custos, capacidade de ampliar e reduzir a equipe
conforme a demanda e o acesso a profissionais com habilidades específicas
[PIL06]. Esta forma de distribuição é mais indicada para projetos que possuem
plano de projeto bem definido e com requisitos de sistemas completamente
entendidos [AUD07].
Onshore: ocorre quando a matriz e o cliente estão localizados no mesmo
país. Duas situações distintas podem ocorrer neste modelo. Todo o
desenvolvimento é realizado na empresa contratada, em um local fisicamente
distinto da empresa contratante, o que caracteriza o offsite. Outra situação é
quando o desenvolvimento é realizado fisicamente no mesmo local onde o cliente
está, e assim caracterizando o onsite [PRI09].
A Figura 5 mostra a combinação dos modelos de negócio mais adotados
pelas empresas [AUD07] em relação ao modelo de trabalho entre as empresas e
as suas distribuições geográficas.

21. 21
Figura 5. Relacionamento entre empresas, adaptado de [AUD07]
A Figura 5 nos remete a quatro principais modelos de desenvolvimento
distribuído, os quais são caracterizados a seguir:
Onshore insourcing: o modelo mais simples e conhecido. É basicamente
uma demanda interna da empresa, onde a partir da necessidade da construção
de um software, um departamento dentro da própria empresa, ou até mesmo uma
subsidiária é responsável pelo seu desenvolvimento. Como temos o termo
Onshore, vale destacar que este departamento ou subsidiária deve estar
geograficamente localizada no mesmo país.
Onshore outsourcing: é um modelo semelhante ao onshore insourcing, a
única diferença é que ao invés de um departamento interno da empresa ou uma
subsidiária desenvolver o projeto, neste modelo, o desenvolvimento é realizado
por uma empresa terceirizada. Como novamente temos o termo onshore, deve
ficar claro que a companhia que desenvolverá o projeto deve estar localizada
fisicamente no mesmo país que a contratante.
Offshore insourcing: este modelo implica na criação de um centro de
desenvolvimento da própria empresa. Devido ao uso do termo offshore, está
implícito que esta subsidiária criada deve estar obrigatoriamente em um país
distinto da matriz. Esta subsidiaria é responsável por executar serviços de
desenvolvimento de software para a matriz (insourcing).
Offshore outsourcing: o termo outsourcing nos leva a definir que uma
empresa terceira será contratada, e offshore remete a diferente localização
geográfica da contratante. Então, este modelo representa a contratação de uma

22. 22
empresa terceira, localizada em um país diferente para prover serviços de
desenvolvimento de software.
O DDS apresenta muitos fatores motivadores que levam as empresas a
utilizar cada vez mais este conceito em seus negócios. A seguir são apresentados
alguns destes fatores. Optou-se por apresentar as vantagens mais citadas por
diferentes autores.
- Redução de custos [LAN08, DAM06, PRI08, AUD07, MAR09]:
organizações procuram alternativas para que o custo de produção seja cada vez
menor. Desta maneira, contratam mão de obra de outro país ou localidade onde o
custo de produção seja mais baixo [KNO07], e assim alcançam o objetivo de
reduzir custos;
- Ganho de proximidade com o cliente [LAN08]: como a demanda de
software cresce em diversos países [KNO07], uma empresa que esteja
expandindo seus negócios para uma nova região poderia iniciar uma operação de
DDS nesta localidade e, assim, estaria se aproximando dos seus clientes.
- Redução do tempo de projeto [LAN08, DAM06, PRI08]: também chamado
de time-to-market, incluir um produto no mercado antes do concorrente pode ser
vital para o sucesso do mesmo. Sendo assim, com mais recursos trabalhando nos
projetos, o tempo de desenvolvimento pode ser reduzido. Ainda é possível citar a
vantagem que é alcançada através da diferença de fuso horário entre os
diferentes centros de desenvolvimento da empresa, que torna possível o uso do
chamado desenvolvimento follow-the-sun, onde a qualquer momento do dia
haverá uma equipe trabalhando [KNO07].
- Recursos especializados [LAN08] e globais [DAM06, PRI08, AUD07,
MAR09]: com o DDS é possível obter a disponibilidade da mão de obra tão
especializada quanto em projetos tradicionais, porém com a vantagem de manter
o baixo custo.
Apesar de todas as vantagens que o DDS disponibiliza para as
organizações, o processo de desenvolvimento de software continua sendo uma
atividade complexa. Utilizando o DDS, adiciona-se ao processo outros inúmeros

23. 23
problemas, como a distância física, diferenças de fusos horários e diferenças
culturais [PRI09, AUD07, DAM06], os quais tornam este tipo de projeto
extremamente complexo de ser gerenciado. Portando, diversas dificuldades são
adicionadas ao processo de desenvolvimento de software, e essas novas
adversidades devem ser conhecidas e gerenciadas para alcançar o sucesso no
DDS. Segundo alguns autores, as adversidades encontradas no DDS podem ser
divididas em algumas categorias [AUD07, PRI09, KNO07, PIL06], as quais afetam
determinadas áreas do processo. Procuram-se listar algumas das dificuldades
encontradas no DDS mais citadas por diferentes autores:
Problemas relacionados a Pessoas [PRI09], também identificado como
problemas sociais [PIL06, KNO07] dizem respeito aos problemas que afetam
diretamente os recursos envolvidos no projeto [PRI09], alguns exemplos são
[PRI09, PIL06, KNO07, HER01, DAM06, BIN07]:
- Confiança:
Sendo o processo de desenvolvimento de software uma tarefa que
geralmente depende da cooperação de vários membros dentro da equipe, a
confiança torna-se fundamental. Esta relação é essencial para o bom
funcionamento da equipe, resultando em diversos benefícios, como melhora no
desempenho, redução de custo e maior sociabilidade entre os membros da
equipe [AUD07, PRI09]. Algumas formas de interação podem facilitar o aumento
da confiança entre os elementos dos times distribuídos, dentre elas, podemos
citar: reuniões de kick-off e encontros em determinados milestones do projeto
[OSH07]. O gráfico da Figura 6 demonstra como o nível de confiança tende a cair
com o passar tempo, por esta razão, torna-se importante encontros no decorrer
do projeto.

24. 24
Figura 6. Nível de confiança durante projeto [AUD07]
- Conflitos:
Como em qualquer projeto de desenvolvimento de software, conflitos
podem acontecer. Em alguns casos, eles podem ser benéficos para o projeto e
podem ser resolvidos no próprio processo de desenvolvimento. Porém podem
acontecer problemas maiores, o que poderia acarretar na perda da produtividade.
Neste caso, é interessante que seja definido a figura de um líder no início do
projeto. Este teria o papel de sanar os conflitos, tomando a decisão que julgar
mais adequada. Deve ser a autoridade central do projeto [AUD07, PRI09].
- Diferenças culturais:
Diferenças culturais fazem parte do cotidiano no DDS. Com times
distribuídos ao redor do globo, os problemas relacionados à cultura emergem
muito rapidamente. Culturas diferentes pensam, comunicam-se e agem de formas
distintas [BIN07]. Em um país, algo que possa ser trivial e corriqueiro, em outro
local pode ser algo completamente incomum. Neste sentido, é recomendado que
as equipes compreendam cada cultura, e que adéquam suas expectativas em
relação as diferenças existentes. Algumas companhias utilizam o conceito de
liaison, que consiste em ter um membro da equipe que age como uma ponte entre
culturas diferentes [AUD07, HER99, HOL06, LAN08, LIN07]. Normalmente esta
pessoa já conviveu com essa cultura e por isso pode fazer este papel. Por
exemplo, um brasileiro trabalhando nos Estados Unidos auxiliando o lado
brasileiro do time distribuído a compreender comportamentos da equipe
americana [AUD07].

25. 25
- Liderança:
Questões relacionadas a liderança são tratadas de forma diferente
dependendo da cultura. Algumas culturas tratam a liderança com menos rigor do
que em outras, ou seja, encorajam a participação do time nas tomadas de
decisões. Enquanto que outras culturas utilizam uma estrutura mais hierárquica e
tomam as decisões de maneira autônoma, sem permitir que seus comandados
expressem suas opiniões.
- Diferentes fusos horários:
As diferenças de fusos horários podem afetar os projetos de DDS de
diferentes formas. Para equipes separadas por uma pequena diferença de
horário, podem passar a maior parte do dia trabalhando ao mesmo tempo. Neste
modo a comunicação fica mais fácil, pois é possível usar a comunicação síncrona,
como ferramentas de mensagens instantâneas, ligações telefônicas, vídeo
conferências, etc. Como exemplo, podemos citar uma equipe localizada na cidade
de Nova Iorque, e outra em São Paulo. Para este caso a diferença seria de
apenas uma hora na maior parte do ano. Os problemas relacionados ao fuso
horário começam a ficar mais evidentes na medida em que a diferença começa a
aumentar. Por exemplo, quando essa diferença atinge algo em torno de cinco
horas, a possibilidade de trabalhar juntos na maior parte do tempo já não é mais
válida. Então, para este caso, a comunicação síncrona tende a diminuir e a
comunicação assíncrona aumenta. Para este exemplo, poderíamos citar uma
equipe localizada em Nova Iorque e outra em Londres. Para este caso a diferença
seria de cinco horas na maior parte do ano. Finalmente temos o caso em que as
equipes distribuídas nunca trabalham no mesmo horário. Neste caso, quando
uma equipe está terminando o seu dia de trabalho a outra está começando. Neste
caso além da falta de comunicação síncrona, torna-se vital que a comunicação
assíncrona seja realizada de forma clara e efetiva. Qualquer dependência de uma
resposta de algum membro do outro time pode demorar no mínimo um dia. Com
esta diferença de fuso horário, alguns autores defendem que seja possível utilizar
o desenvolvimento follow-the-sun – desenvolvimento 24 horas por dia, porém este
conceito é pouco utilizado na indústria [HOL06, LIN07]. Para este exemplo,

26. 26
poderíamos citar uma equipe localizada em São Paulo e outra em Tóquio, onde a
diferença será de doze horas na maior parte do ano.
Quanto aos problemas relacionados a Organização [PRI09, HER01, PIL06,
KNO07], mostram dificuldades que afetam as definições estratégicas de
processos [PIL06, KNO07] e métodos de gestão de uma organização [PRI09].
Alguns exemplos são [PIL06, LOP04, PRI09]:
- Legislação:
Algumas questões importantes dizem respeito às diferenças legais entre os
locais envolvidos (principalmente em casos de distribuição global). Essas
diferenças implicam em maior complexidade no estabelecimento de contratos,
bem como a necessidade de cautela com questões de sigilo e propriedade
intelectual [KAR98].
- Gerenciamento de portfólio de projeto:
Este tipo de gerenciamento tem surgido como um importante aliado no
gerenciamento de projetos. O principal objetivo deste tipo de gerenciamento não é
executar projetos de desenvolvimento de software corretamente. Seu principal
objetivo é realizar os projetos corretos, nos momentos adequados, baseado nas
estratégias da empresa. Os desafios desta área estão em determinar através de
diversas análises como os projetos de DDS serão desenvolvidos, definir como o
projeto será realizado e para quais localidades será realizada a distribuição
[PRI09, PIL06].
- Modelos de negócio:
Conforme pode ser visto na Figura 5, pode-se optar por diversos modelos
de negócio. Não existe o modelo correto, mas existe o modelo mais adequado ao
problema a ser resolvido. Para fazer a decisão sobre qual modelo será utilizado,
as empresas devem realizar uma análise e identificar suas reais necessidades
com a utilização do DDS, e quais os tipos de projetos que pretende distribuir
geograficamente. A partir desses dados, uma decisão mais precisa pode ser
tomada. A prática demonstra que um bom planejamento tem determinado o
sucesso no modelo escolhido [PRI09].

27. 27
Problemas relacionados à Projetos [PRI07, HER01] também identificados
por [PIL06, KNO07] como problemas técnicos, contemplam dificuldades
relacionados a forma como o projeto será desenvolvido, incluindo o uso de
ferramentas e métodos [PRI09]. Dizem respeito ainda as adversidades
relacionadas com a gerência de requisitos, integração, gerência de configuração,
dificuldades no acompanhamento do projeto e na utilização de ferramentas
[PIL06, KNO07]. Exemplos destas adversidades são [PRI09, LOP04, PIL06,
BOS10, HER99]:
- Arquitetura de Software:
Um dos fatores decisivos para o sucesso de um projeto de DDS é a
escolha da arquitetura de software [BOS10]. Uma AS apropriada para este tipo de
projeto deve ser uma arquitetura modular, pois desta forma é possível alocar
tarefas complexas de forma distribuída [AUD07, PRI09, HER99]
- Processos de desenvolvimento:
A utilização de um processo de desenvolvimento único no ambiente DDS é
fundamental [AUD07]. Com a distribuição de tarefas, a falta de sincronização
pode tornar-se um fator decisivo. Para contornar este problema, a utilização de
uma metodologia de desenvolvimento de software impõe rigor à equipe. Neste
sentido, é possível verificar que cada vez mais as companhias buscam excelência
na qualidade do desenvolvimento de software. Para comprovar esta excelência,
submetem-se a diversas avaliações tais como ISO e CMMI [AUD07, PRI09]
- Telecomunicações:
A coordenação entre equipes distribuídas envolve alto custo. Neste
sentido, é fundamental a existência de uma boa infra-estrutura de comunicação. É
essencial a existência de conexões confiáveis e de alta velocidade para todas as
formas de conexões que possam ser utilizadas. Atualmente a maior parte das
localidades já possui esta infra-estrutura. A segurança nesta comunicação
também é um fator importante. Hoje em dia, existe grande diversidade de opções
tecnológicas que garantem esta segurança. Ultimamente tem crescido a opção

28. 28
pelo uso de VPN (do Inglês, virtual private network) devido ao baixo custo,
confiabilidade e alta disponibilidade [AUD07].
- Gerência de configuração:
O gerenciamento da configuração de software também apresenta desafios.
O controle das modificações dos artefatos em localidades distintas, juntamente
com o gerenciamento dos processos de desenvolvimento do sistema pode ser
complexo. Para diminuir esta dificuldade é recomendada a utilização de um
repositório central, para que o controle seja realizado de forma única [MAR09].
- Gerenciamento de projetos:
De forma a diminuir os impactos inerentes ao DDS, o gerenciamento de
projeto deve sofrer adaptações em relação ao modelo tradicional utilizados em
time co-localizados. É recomendada a utilização de técnicas mais formais de
gerenciamento [PRI09].
Com as informações apresentadas na seção 2.1, onde foi abordada a
arquitetura de software, e na seção 2.2, onde o tema tratado foi DDS. A próxima
seção visa fazer o relacionamento entre estas duas áreas e demonstrar a
importância deste relacionamento.
2.3 Relacionando DDS e AS
Na busca das vantagens competitivas encontradas no desenvolvimento
distribuído, muitas organizações estão seguindo o caminho do DDS, o que está
tornando-se uma tendência no mercado atual [DAM06]. Porém, estas empresas
ainda encontram muitas adversidades na implementação deste modelo de
processo de desenvolvimento de software. Conforme apresentado anteriormente,
uma maneira para contribuir na redução de algumas destas dificuldades está na
utilização de uma arquitetura de software adequada [AUD07, PRI09, HER99,
BOS10]. Neste sentido, a escolha de uma AS ideal é considerado um dos fatores

29. 29
determinantes para o sucesso de um projeto de desenvolvimento distribuído de
software [AUD07, PRI09, BOS10].
A arquitetura escolhida deve possuir algumas características especiais.
Para que seja possível alocar tarefas complexas de forma distribuída, o princípio
da modularidade deve estar presente [AUD07, PRI09, HER99]. A modularidade
permite que tarefas independentes sejam desenvolvidas paralelamente de forma
distribuída [AUD07, PRI09]. Assim, a necessidade de integração entre os times
alocados em diferentes locais tende a diminuir evitando alguns problemas
inerentes ao DDS, como por exemplo, o impacto cultural entre equipes
distribuídas [BIN07].
Uma arquitetura modular, onde diferentes tarefas podem ser realizadas de
forma distribuída e independente pode ocasionar diversos problemas, se os
mesmos não forem detectados na fase inicial do processo. Um dos problemas
mais comuns neste tipo de projeto está no momento da integração do produto
final. Quando o projeto chega a um estado avançado do seu desenvolvimento, e
entra na fase de integração, algumas vezes, problemas de incompatibilidade entre
componentes são encontrados. Estes problemas são identificados somente nesta
fase, por diversas razões. Uma delas é a falha no processo de definição das
interfaces de integração do sistema, ou seja, estabelecer critérios de
comunicação entre os diferentes componentes que irão compor o sistema. Esta
definição deve levar em conta todas as possíveis comunicações que um
determinado serviço ou componente possa vir a realizar, portanto torna-se
importante a definição de formatos de mensagens (WSDLs) precisos e genéricos
o suficiente.
Após ter o completo entendimento dos requisitos, as equipes que possuem
acoplamento entre os seus componentes devem concordar que a mensagem
WSDL definida para tal serviço é suficiente, e que não haverá a necessidade de
adicionar ou remover elementos. Porém, em projetos de desenvolvimento de
software, os requisitos podem sofrer diversas alterações no decorrer do ciclo de
desenvolvimento. Estas modificações devem ser analisadas e o impacto desta
mudança identificado. Se as alterações dos requisitos impactarem na
comunicação entre componentes, as interfaces relativas aos mesmos devem ser

30. 30
reavaliadas para evitar problemas. As alterações de interfaces, caso sejam
necessárias, devem ser realizadas o quanto antes. Para que isso ocorra de forma
correta, os times distribuídos, que possuem os componentes impactados por esta
modificação de requisito devem redefinir e concordar com o novo formato de
mensagem que serão trocadas entre os componentes, assim evitando futuros
problemas de integração.
Outro fator importante a ser destacado é que o conhecimento entre as
equipes distribuídas é fundamental [HER99]. O exemplo a seguir ilustra esta
situação: quando o time de desenvolvimento que está alocado no Brasil percebe
um erro na definição de um tipo de atributo contido na mensagem que o seu
serviço está utilizando para trocar informações com um serviço desenvolvido por
uma equipe alocada nos Estados Unidos. Este erro encontrado poderia ser que,
ao invés de um atributo receber um valor booleano, este deveria conter apenas
um valor numérico. Neste caso, fica claro que a equipe alocada no Brasil deverá
contatar a equipe americana para entrar em um acordo sobre a modificação a ser
realizada na comunicação. Nesta situação, fica evidente a importância do
conhecimento entre as equipes distribuídas [HER99], pois o time de
desenvolvimento do Brasil deve saber a qual elemento da equipe americana
recorrer para solucionar este problema.
A modularidade está diretamente ligada ao completo funcionamento da
integração do sistema, caso contrário, utilizar uma arquitetura modular não evitou
problemas. Outra característica relacionada com a modularidade para uma AS,
que aumenta a probabilidade de sucesso de um projeto que utiliza DDS, é o baixo
acoplamento. Esta propriedade visa ter os componentes mais independentes
possíveis uns dos outros. Isso se torna importante no processo de
desenvolvimento do software, pois quanto menor o número de conexões entre os
serviços, menor o número de pontos de falhas. Logo, os problemas de integração
tendem a diminuir na medida em que o acoplamento diminui [OLS96].
As características acima citadas demonstram que torna-se interessante o
uso de uma arquitetura orientada a serviço (SOA) para projetos de
desenvolvimento distribuído de software, pois esta arquitetura possui as
características adequadas para o DDS. Esta afirmação está em consonância com

31. 31
os recentes trabalhos de Martignoni [MAR09], Bin Xu [BIN07], Shroff et al.
[SHR05] e Bosch et al. [BOS10] que afirmam que SOA é o modelo de arquitetura
mais indicado para projetos de DDS.

32. 32
3 TRABALHOS RELACIONADOS
Embora diversos estudos reconheçam a importância da arquitetura de
software em um projeto de desenvolvimento de sistemas e também reconhecem
as vantagens que o DDS pode agregar nos projetos de softwares, após uma
pesquisa extensa, encontrou-se apenas um número reduzido de artigos que
mostram a importância da escolha de uma AS adequada nos projetos de DDS.
Nesta seção é apresentada uma compilação dos principais artigos relacionados à
esta temática. Os estudos apresentados versam sobre os mais diversos tipos de
projetos de softwares, porém todos convergem para uma mesma conclusão: a
escolha de uma AS orientada a serviços pode evitar diversos problemas nos
projetos de software que utilizam DDS.
3.1 Abordagem de Bosch e Bosch-Sijtsema (2010)
O recente artigo publicado por Bosch e Bosch-Sijtsema [BOS10], realiza
um estudo em três diferentes organizações globais de desenvolvimento de
software, com o objetivo de identificar as principais características encontradas
em diferentes dimensões: arquitetura, processos e organização. O estudo ainda
apresenta, baseado nas informações coletadas na pesquisa, como pode ser
realizado um processo para diminuir o acoplamento dos sistemas desenvolvidos
para que estes possam ser realizados de forma distribuída. Para alcançar este
objetivo, pesquisou projetos que utilizavam cinco estratégias distintas, as quais
serão detalhadas a seguir.
A primeira estratégia de desenvolvimento pesquisada foi a que o autor
identifica como Integração Central. Neste modelo, o projeto é desenvolvido com
um ponto de integração único. Na maioria dos casos, é dedicada uma fase no
ciclo de desenvolvimento específico para a integração do sistema, onde todos os
componentes são testados. Nesta fase, normalmente inúmeros problemas de
integração são encontrados, os quais precisam ser resolvidos pelos times os
quais os desenvolveram. A Tabela 1 apresenta as principais características

33. 33
encontradas nos projetos que utilizaram esta estratégia, relacionada às três
dimensões pesquisadas.
Tabela 1. Integração Central
Dimensão Características
Arquitetura − A arquitetura utilizada não foi a ideal;
− Arquitetura fortemente conectada entre seus componentes;
− Pouca documentação, ou documentação defasada.
Processos − Mesmo que as empresas utilizem técnicas de integração contínua,
problemas de integração ainda continuam acontecendo, logo, a
fase final de integração ainda utiliza um número de horas
considerável do projeto.
Organização − Mesmo tendo times distribuídos, as empresas pesquisadas tinham
a tendência de deixar a parte mais crucial do projeto em um único
local. Desta forma, muitas vezes recursos que estavam localizados
de forma distribuída necessitavam viajar para realizar o trabalho.
Mesmo que a estratégia de Integração Central tenha algumas
desvantagens, o autor concluiu que para projetos onde o nível de conexão entre
componentes é alto, este tipo de estratégia pode ser vantajoso.
A segunda estratégia utilizada na pesquisa foi a que o autor chama de
Agrupamento de Releases, onde as organizações dividiam os componentes em
grupos, e os pré-integravam, entregando assim, um grupo de componentes. A
Tabela 2 apresenta as principais características encontradas nos projetos que
utilizaram esta estratégia.
Tabela 2. Agrupamento de Releases
Dimensão Características
Arquitetura − A arquitetura foi decomposta até o nível mais alto, e assim,
definindo o agrupamento que seria utilizado;
− O momento de integração entre os serviços aconteceu dentro de
cada grupo de serviço, o que se assemelhou à primeira estratégia.
Processos − Cada grupo possui seus processos independente de

34. 34
desenvolvimento, o que leva a obter uma variação de problemas e
desafios dentro de cada um dos grupos.
Organização − Times responsáveis por cada grupo de serviços são distribuídos;
− Os custos de coordenação e tempo para realizar o projeto tendem
a aumentar.
As vantagens desta estratégia, segundo o autor, é a possibilidade de
distribuir diferentes grupos de componentes em times geograficamente
distribuídos, fazendo o uso do DDS de forma mais efetiva.
A terceira estratégia pesquisada foi a que o autor chama de Release
Trains, onde os grupos de componentes utilizados na estratégia anterior, neste
momento são decompostos resultando em cada componente que compõe o
sistema. A Tabela 3 apresenta as principais características encontradas nos
projetos que utilizaram esta estratégia relacionada às três dimensões
pesquisadas.
Tabela 3. Release Trains
Dimensão Características
Arquitetura − A arquitetura dever ser especificada no nível de componentes,
definindo inclusive detalhes das interfaces;
− Neste ponto não devem existir dependências entre os
componentes.
Processos − Uma peça chave no processo está na fase que antecede o
desenvolvimento onde as especificações das interfaces são
realizadas, e aceitas por todo o time;
− Cada time pode trabalhar de forma independente, porém ainda é
necessário que as entregas sejam realizadas ao mesmo tempo.
Organização − A necessidade de coordenação e comunicação entre os times
distribuídos diminui;
− A distribuição pode agora ser realizada sem os problemas
encontrados nas estratégias anteriores.

35. 35
Segundo o autor, a estratégia de Release Trains é adequada para projetos
que necessitam realizar entregas contínuas de software. Não sendo necessária a
fase de integração. Basta o serviço ser instalado ao final do seu desenvolvimento
e o mesmo está pronto para ser utilizado.
A quarta estratégia estudada foi a que o autor identifica como Implantação
Independente. Segundo o autor, esta estratégia deve ser utilizada por
organizações extremamente maduras, onde não seja necessária a sincronização
de tarefas entre os times durante as interações. Neste caso, o momento da
entrega de cada componente é definido pelo time que a desenvolve, a única
exigência é que o componente deve garantir a compatibilidade com os outros
serviços do sistema. Por obter resultados muito semelhantes à estratégia anterior,
não será detalhado cada dimensão.
Um dos fatores de sucesso desta estratégia apontado pelo autor é que
essa abordagem é interessante para times que desenvolvem tarefas de diferentes
complexidades e diferentes tempos de desenvolvimento necessário. O fator crítico
para o sucesso desta estratégia está na maturidade de desenvolvimento da
organização. Processo de planejamento, design e testes devem ser apoiados por
ferramentas automatizadas.
A quinta e última estratégia proposta versa sobre a utilização de soluções
desenvolvidas por terceiros. Também mostra características semelhantes à
terceira estratégia. Por tratar-se de um sistema desenvolvido por terceiro, a
arquitetura do sistema deve levar em consideração a garantia de segurança. A
principal vantagem desta estratégia, segundo o autor, é a possibilidade de
diminuir o time-to-market.
Finalmente, as conclusões que o autor define para o seu estudo são:
mesmo que a distribuição de tarefas entre times distribuídos possa gerar
complexidade aos projetos, mantendo certas características no projeto, essas
adversidades podem ser drasticamente diminuídas. O principal fator apontado
pelo autor está na escolha de uma arquitetura adequada, a qual deve ser
modular, possuir o menor nível de acoplamento possível e possuir os pontos de
integração entre os componentes bem definidos. O autor sugere que o uso de
uma arquitetura orientada a serviço é o mais adequado para este tipo de projeto,

36. 36
pois desta forma, cada serviço pode ser desenvolvido em locais geograficamente
distintos.
3.2 Abordagem de Martignoni (2009)
O estudo realizado por Robert Martignoni [MAR09] tem como objetivo
identificar ferramentas e serviços que visam a otimização do desenvolvimento
distribuído de software. A motivação para este estudo foi a constatação que as
ferramentas utilizadas no desenvolvimento tradicional de software não eram
suficientemente adequadas para o processo distribuído.
O método de pesquisa está baseado na identificação e classificação de
ferramentas e serviços utilizados no desenvolvimento de software. Num segundo
momento, procurou-se por funcionalidades adicionais nestas ferramentas que
poderiam ser utilizadas exclusivamente no DDS. A busca por estas ferramentas e
serviços baseou-se numa extensiva análise de mercado e uma profunda pesquisa
na literatura. Todas as ferramentas de desenvolvimento encontradas foram
analisadas e categorizadas da seguinte maneira:
Ferramenta de Desenvolvimento: desenvolvidas especificamente para
auxiliar em uma ou mais fases do processo de desenvolvimento, como por
exemplo: sistemas de gerenciamento de documentação (MS Sharepoint,
Docushare); ferramentas de teste (HP Quality Center, JUnit); ferramentas de SQA
(CAST, CheckStyle, EMMA); monitoramento de desempenho (Digite, Borland
BMS); gerenciamento de código fonte (Subversion, CSV, Virtual Safe). Segundo o
autor, todas estas ferramentas suportam uma tarefa específica do
desenvolvimento de software, e podem ser utilizadas no DDS. Porém, nenhuma
delas adiciona funcionalidades específicas para o DDS.
Ferramenta de escrita de código: normalmente chamadas de IDEs, estas
ferramentas foram desenvolvidas tradicionalmente para desenvolvimento de
software. Estas ferramentas normalmente integram editores de texto,
compiladores e debuggers de código. Nesta categoria, três tipos distintos podem
ser identificados: (i) IDEs stand-alone, utilizada para um único programador

37. 37
desenvolver suas tarefas; (ii) IDEs modificadas que permitem funcionalidades de
integração, como controle de código fonte e controle de defeitos; (iii) e finalmente,
IDEs colaborativas, que integram funcionalidades de colaboração dentro do
ambiente de desenvolvimento.
Software como serviço: está baseado na idéia de prover funcionalidades
de software como serviços distribuídos, os quais podem ser arranjados de
maneira a criar um sistema único. A principal vantagem de usar esta abordagem
está na possibilidade de utilizar DDS juntamente com um repositório de código
central. O conceito de utilizar serviços pode diminuir a necessidade de
sincronização e comunicação entre os times distribuídos.
Segundo o autor, outras análises demonstram que a utilização de serviços
é o mais indicado em projetos globais. Este fato deve-se à escolha da arquitetura
que é utilizada, a qual deve manter a modularidade e possuir baixo acoplamento,
sendo possível a utilização de serviços para compor um sistema. Portando, após
a identificação, a categorização e as análises de ferramentas e serviços que
poderiam ser utilizadas no DSS, o autor concluiu que a utilização de uma
arquitetura orientada a serviço é a mais adequada para o uso de DDS, podendo
assim, cada serviço ser desenvolvido por uma equipe de desenvolvimento distinta
e em locais geograficamente distantes.
3.3 Abordagem de Xu (2007)
Bin Xu [BIN07] publicou um trabalho em 2007 relatando um modelo de
distribuição dentro de um projeto de desenvolvimento de software. O autor chama
este modelo de Desenvolvimento Cooperativo de Software.
Após analisar as diferentes formas que as organizações distribuídas
gerenciavam seus recursos, Bin Xu constatou que um dos maiores problemas
encontrados nos projetos de DDS estava na comunicação. Na busca da solução
para este problema, o autor busca investigar os problemas que a comunicação
pode causar, e formas para evitar estes problemas em um projeto global.

38. 38
Para evitar estas adversidades, o autor propõe um processo colaborativo
de desenvolvimento global de software. Neste processo, entende-se que para o
sistema que será desenvolvido, o mesmo deve ser dividido em serviços. Estes
serviços devem ser modulares e com baixo acoplamento. O autor desenvolve
uma maneira formal para a descrição dos serviços, evitando assim problemas de
entendimento dos requisitos. Como é possível visualizar na Figura 7, a estrutura
proposta para a definição que cada serviço deve seguir é bem detalhada. É
possível observar que nesta estrutura estão contidos dentre outra informações,
dados importantes como a definição de objetivos do serviço, as interfaces,
envolvidas, etc.
Figura 7. Estrutura definição de serviço [BIN07]
Tendo os serviços bem definidos, é proposto que seja criada uma fila de
serviços, onde estas definições são adicionadas, e ficam esperando que um
desenvolvedor esteja apto a desenvolver o serviço.
Finalmente, o autor submete a sua proposta a um teste, usando para isto,
um caso de estudo de um projeto que está sendo desenvolvido de forma
distribuída. Os desenvolvedores estão alocados na cidade de Hangzhou – China
– enquanto o cliente está alocado em Boston – Estados Unidos. Antes do início
do uso do trabalho proposto por Xu, em média, havia um atraso entre dois a três
dias na comunicação entre as equipes distribuídas. Quando essa comunicação
era relacionada ao resultado do entendimento do requisito, ou a uma dúvida sobre
o mesmo, geravam atrasos no projeto. Por exemplo, quando era uma dúvida, o
desenvolvedor deveria esperar a resposta antes de continuar, o que demorava
em média entre dois e três dias. Após o uso das filas de definições de serviços,
como o entendimento aumentou bastante, é possível que ao surgir alguma
dúvida, esta seja comunicada e, enquanto a resposta não chega, o desenvolvedor
pode iniciar o trabalho com outro serviço disponível na fila. Com este processo, o
tempo médio total de espera de um recurso no ciclo de desenvolvimento foi de

39. 39
três dias, ou seja, 2% do ciclo. Segundo o autor, este dado prova a eficiência do
estudo proposto.
Com este estudo, o autor concluiu que tendo uma arquitetura orientada a
serviços, onde seja possível o desenvolvimento de serviços independentes, e
tendo serviços extremamente bem definidos, é possível amenizar as
adversidades que o DDS pode ocasionar, principalmente problemas de
comunicação.
3.4 Abordagem de Mockus e Weiss (2001)
O artigo apresentado por Audris Mockus e David Weiss [MOC01] tem como
principal objetivo auxiliar gerentes de projeto na escolha de tarefas que possam
ser distribuídas geograficamente. Para isto, iniciaram a pesquisa em algumas
empresas, onde identificam as principais formas utilizadas para a distribuição
global de tarefas e suas justificativas eram:
- Divisão por funcionalidades: distribuição para centros remotos, baseados
na funcionalidade do subsistema a ser desenvolvido. A principal vantagem desta
abordagem é que se tem determinados centros especializados em determinadas
funções do sistema. A desvantagem pode ser que ao incluir novas
funcionalidades ao sistema, pode ser necessário que especialistas de diversos
centros trabalhem em conjunto, aumentando assim necessidade de coordenação.
- Divisão por localização: nesta abordagem o autor afirma que a
distribuição é realizada baseada na localização geográfica. Este tipo de
abordagem foi mais utilizado em sistemas que necessitavam funcionalidades
específicas de determinados países ou mercados. Um exemplo para este modelo
pode ser a necessidade de tradução da interface gráfica de um sistema, para um
determinado idioma, para este caso, distribuir para um país onde esse idioma é
utilizado facilitou o processo.
- Divisão por fase de desenvolvimento: cada fase do processo de
desenvolvimento pode ser realizado em um determinado local. Segundo o artigo,
um exemplo poderia ser a implementação do sistema em uma localização distinta

40. 40
de onde o teste é realizado. A vantagem é manter os especialistas em
desenvolvimento em um local, porém a desvantagem é o aumento da
necessidade de comunicação.
- Manutenção: outra forma que os autores mostram, é que ao final do ciclo
de desenvolvimento, qualquer manutenção no sistema é realizada em um local
distinto, para que novos sistemas possam ser desenvolvidos. A principal
desvantagem desta abordagem está no fato de que como a equipe que realizará
a manutenção no sistema, não é a mesma que o desenvolveu, o tempo de
resolução de problemas tende a ser maior.
Após estas informações coletadas, os autores propõem outra abordagem
de distribuição de tarefas, que seria baseada em porções de códigos. Esta
abordagem tem como principal objetivo, diminuir a necessidade de sincronização
e comunicação entre as equipes distribuídas.
Para isso, os autores definiram uma maneira de classificar se um
determinado tipo de trabalho pode ou não ser distribuído para diferentes
localidades. Esta classificação está baseada na estrutura que as tarefas
normalmente possuem. O modelo utilizado pode ser visto na Figura 8.
Figura 8. Estrutura de uma tarefa [MOC01]
Uma tarefa varia de tamanho, desde a entrega como um todo (software
release), até pequenas modificações em um código fonte (delta) (Figura 8). Para

41. 41
determinar a possibilidade de distribuição de determinado tipo de tarefa, os
autores mostram que através de sistemas de controle de versão é possível medir
os níveis de acoplamento que o código que está sendo alterado tem, esta
medição é chamada de delta.
Neste sentido, os autores afirmam que quanto menor o valor desta
variação, maior a chance da distribuição desta porção de código ser realizada de
forma efetiva, pois assim, quanto menor a variação, menor o acoplamento, logo
maior a chance de sucesso.
A conclusão dos autores é que ao distribuir tarefas bem definidas, com
pouca integração com outros componentes, pode ser vantajoso. Por outro lado,
para tarefas que possuem alto grau de acoplamento umas com as outras, seria
mais interessante fazer o desenvolvimento no mesmo local, pois nesse caso, a
necessidade de comunicação entre os desenvolvedores é maior. Portanto, a
utilização de uma arquitetura de software adequada, com o menor acoplamento
possível, através do cálculo proposto no artigo, poderia aumentar o número de
tarefas que teriam a possibilidade de ser desenvolvida de forma distribuída.
3.5 Abordagem de Herbsleb e Grinter (1999)
O trabalho apresentado em 1999 pelos autores James D. Herbsleb e
Rebecca E. Grinter [HER99] tem como foco principal mostrar que times
geograficamente distribuídos enfrentam um número muito grande de problemas
de comunicação e de coordenação em projetos distribuídos. Os autores
apresentam um caso de estudo que mostra como eventos comuns não previstos
podem comprometer um projeto como um todo. Os problemas principais citados
pelos autores dizem respeito a atrasos no cronograma e principalmente
problemas de integração do sistema.
Para este caso de estudo descrito no artigo, os autores escolheram um
projeto que estava distribuído em dois países distintos, onde era possível
identificar algumas diferenças importantes: fuso horário, idioma e diferenças
culturais acentuadas.

42. 42
Seguindo os requisitos, cada equipe iniciou o desenvolvimento dos seus
subsistemas isoladamente nos seus países de origem. Cada time construiu seus
próprios simuladores que representavam componentes que os outros times
desenvolveriam de fato. Para a construção destes artefatos, quando não se tinha
uma definição clara, suposições eram usadas, muitas vezes erroneamente.
Ao final do projeto, foram realizadas entrevistas com alguns líderes dos
times e constatou-se que o principal problema causado pelo uso de DDS foi na
integração do sistema. Ao final da pesquisa, após análise dos dados coletados,
alguns pontos foram destacados pelos autores. Tendo uma arquitetura de
software modular e usando este fato como base para realizar a distribuição das
tarefas para diferentes locais, quanto mais claramente separados os módulos a
serem desenvolvidos, maior a chance de sucesso ao desenvolvê-los em
diferentes localidades. Por este motivo, os autores defendem a utilização de
arquiteturas de software modulares e com baixo acoplamento. Pois assim a
necessidade de interação entre os times remotos tende a diminuir. Outro ponto
destacado por este estudo mostra que só é interessante fazer a distribuição de
tarefas entre times distintos se estas estiverem com os requisitos muito bem
definidos e entendidos pelos times.
3.6 Análise comparativa
Após a apresentação dos trabalhos relacionados, a Tabela 4 mostra uma
análise comparativa entre estas diferentes abordagens. Para cada critério
(colunas), procurou-se saber se o trabalho relacionado, de alguma forma indicou
importância para este fator.

43. 43
Tabela 4. Comparação entre trabalhos realizados
Considera Sugere o Identifica
importante uso de problemas de
cada serviço em
SOA para DDS
Sincronização
Comunicação
acoplamento
local distinto
Desenvolver
Integração
Escolha AS
Escolha AS
modular
Trabalhos relacionados
baixo
Bosch e Bosch-Sijtsema (2010) X X X X X X
Martignoni (2009) X X X X X X X
Xu (2007) X X X
Mockus e Weiss (2001) X X X X
Herbsleb e Grinter (1999) X X X X X
Como podemos perceber, todos os trabalhos consideram importante a
divisão de trabalho em forma de serviços, para então distribuí-los
geograficamente. Porém, a ressalva que a maioria dos trabalhos indicou é que
para que isso funcione da maneira adequada, a modularidade e o baixo
acoplamento entre os serviços devem estar garantidos.
Os principais problemas mencionados nos trabalhos relacionados dizem
respeito às comunicações e sincronizações necessárias em projetos de DDS.
Dentre os trabalhos apresentados, todos apontam a comunicação como um
importante problema enfrentado. Problemas de sincronização estão relacionados
às dificuldades que diferentes times distribuídos têm em sincronizar o
desenvolvimento do projeto. Um exemplo deste problema pode acontecer quando
um time alocado na Índia necessita de um serviço que está sendo desenvolvido
por outra equipe no México, a qual atrasou o seu desenvolvimento e impactou o
processo de desenvolvimento do time Indiano. Este tipo de problema é apontado
pela maior parte dos trabalhos apresentados. Também foi citado por mais de um
autor a integração do sistema como um problema importante para projetos desta
natureza.
Neste sentido, as diferentes abordagens convergem, na maioria das vezes,
para soluções que diminuem a necessidade de comunicação entre times
distribuídos: fazer a distribuição de serviços bem definidos que não necessitem a
integração entre as equipes distribuídas para o seu desenvolvimento.
Outros pontos a serem destacados, que estão diretamente relacionados ao
trabalho em desenvolvimento, são: apenas um trabalho não citou a importância

44. 44
da escolha de uma AS adequada, porém, este trabalho destaca a importância da
divisão do trabalho em serviços; e, três trabalhos afirmaram diretamente que o
uso de arquitetura orientada a serviço (SOA) é o mais indicado para projetos de
desenvolvimento distribuído de software.
É possível observar através dos trabalhos relacionados que os problemas
mencionados são sempre semelhantes, inclusive para os trabalhos mais recentes.
Podemos observar que todos os trabalhos convergem para um ponto único: a
utilização de serviços que possam ser desenvolvidos de forma distribuída
geograficamente. Portanto, podemos identificar através deste comparativo entre
os trabalhos relacionados, que existem estudos que apontam a escolha de uma
arquitetura de software adequada como fator importante no processo de DDS.
Encontram-se, ainda, trabalhos que mostram que para diminuir problemas
inerentes ao DDS, a divisão de trabalho em serviços, antes de realizar a
distribuição, é um fator importante. Porém, após revisão da literatura, constatou-
se que alguns trabalhos sugerem o uso de uma arquitetura de software orientada
a serviço para solucionar os problemas evidenciados pelo DDS. Entretanto, há
uma escassez na literatura atual de trabalhos que apresentam os resultados
sobre como a utilização de SOA reduziu os problemas gerados em ambientes de
DDS.

45. 45
4 CONSIDERAÇÕES FINAIS
Conforme apresentado no decorrer do trabalho, a revisão da literatura
confirmou a importância da escolha de uma arquitetura de software adequada
como parte essencial de um processo de desenvolvimento de software
distribuído, com o objetivo de diminuir as adversidades inerentes a este processo.
Quando existem diferentes equipes, dispersas geograficamente,
trabalhando em um mesmo projeto de desenvolvimento de software, os desafios
tendem a aumentar. Para diversos autores [HER01, BOS10, MAR09, BIN07,
MOC01], a necessidade de gerenciar uma grande variedade de dependências
entre times geograficamente dispersos é um problema que faz parte do processo
de DDS. Segundo estes autores, para diminuir estes problemas é necessário
reduzir a quantidade de comunicação e sincronização necessária entre as
equipes distribuídas. Para alcançar este objetivo, é recomendado eliminar as
dependências entre os times, através do uso de uma arquitetura de software
adequada.
De acordo com o que foi visto nos trabalhos relacionados, a AS adequada
para um projeto de DDS deve ser uma arquitetura modular e com baixo
acoplamento. A escolha de uma arquitetura com estes atributos pode ser um fator
de extrema importância para o sucesso de um projeto desta natureza. Após
avaliar os principais tipos de arquitetura de software encontrados na literatura de
processos de desenvolvimento de software, constatou-se que a mais adequada
para a utilização de DDS é a arquitetura orientada a serviço – SOA, devido às
suas principais características.
Apesar de haver, na literatura, muitos trabalhos que demonstram a
importância da escolha de uma AS com as características já mencionadas para o
sucesso no processo de DDS. Os estudos que apresentam os resultados sobre
como a utilização de SOA reduz os problemas inerentes ao DDS ainda são
insuficientes na literatura atual. Neste sentido, esta pesquisa visa entender como
a utilização de uma Arquitetura de Software Orientada a Serviços (SOA) pode
diminuir as adversidades impostas pelo uso do Desenvolvimento Distribuído de
Software (DDS).

46. 46
REFERÊNCIAS BIBLIOGRÁFICAS
[AUD07] Audy, J.; Prikladnicki, R., “Desenvolvimento Distribuído de Software
– Desenvolvimento de Software com Equipes Distribuídas.” Brasil:
Campus, 2007. 232 p.
[BIN07] Bin X., “A Service Oriented Model for Role Based Global
Cooperative Software Development," Convergence Information
Technology, 2007. International Conference on , vol., no., pp.376-
381, 21-23 Nov. 2007
[BOS10] Bosch, J.; Bosch-Sijtsema, P., "Software Product Lines , Global
Development and Ecosystems : Collaboration in Software
Engineering," Collaborative Software Engineering, Springer Berlin
Heidelberg, pp.77-92, 10 Mar. 2010
[CUR08] Curry, E.; Grace, P., "Flexible Self-Management Using the Model-
View-Controller Pattern," Software, IEEE , vol.25, no.3, pp.84-90,
May-June 2008
[DAM06] Damian, D.; Moitra, D., "Guest Editors' Introduction: Global Software
Development: How Far Have We Come?",
Software,IEEE,vol.23,no.5,Sept.-Oct. 2006, p.17-19.
[DAN08] Dan, X.; Shi, Y.; Tao, Z.; Xiang-Yang, J.; Zao-Qing, L.; Jun-Feng, Y.,
"An Approach for Describing SOA," Wireless Communications,
Networking and Mobile Computing, 2006. WiCOM 2006.International
Conference on , vol., no., pp.1-4, 22-24 Sept. 2006
[DAV08] Davies, J.; Schorow, D.; Ray, S.; Rieber, D., "The Definitive Guide to
SOA Oracle Service Bus." EUA: Apress, 2008. 508 p.
[DIA08] Dias Júnior, J.J.L., “A Software Architecture Process for SOA-Based
Entrerprise Applications.” Dissetação de Mestrado, Universidade
Ferderal de Pernambuco, 2008.

47. 47
[HER01] Herbsleb, J.D.; Moitra, D., "Global software development," Software,
IEEE , vol.18, no.2, pp.16-20, Mar/Apr 2001
[HER99] Herbsleb, J.D.; Grinter, R.E., "Architectures, coordination, and
distance: Conway's law and beyond ," Software, IEEE , vol.16, no.5,
pp.63-70, Sep/Oct 1999
[HOL06] Holmstrom, H., Conchúir, E., Ågerfalk P. J., Fitzgerald B., "Global
Software Development Challenges : A Case Study on Temporal ,
Geographical and Socio-Cultural Distance," Global Software
Engineering, 2006. ICGSE 2006. IEEE International Conference on ,
vol., no., pp. 3-11. 2006
[HON09] Hongqi L.; Zhuang W., "Research on Distributed Architecture Based
on SOA," Communication Software and Networks, 2009. ICCSN '09.
International Conference on , vol., no., pp.670-674, 27-28 Feb. 2009
[JBO10] Jboss. “JBoss ESB”. Capturado em:
http://www.jboss.org/jbossesb.html. Maio 2010.
[KAR98] Karolak, D. W., "Global Software Development - Managing Virtual
Teams and Environments." Los Alamitos, EUA: IEEE Computer
Society, 1998. 159 p.
[KNO07] Knob, F. F., “RiskFree4ppm: uma proposta de processo para o
gerenciamento de portfólios de projetos distribuídos.” Dissertação de
Mestrado, PPGCC, Faculdade de Informática, PUCRS, 2007.
[KUA08] Kuang-Yu Peng; Shao-Chen Lui; Ming-Tsung Chen; , "A Study of
Design and Implementation on SOA Governance: A Service
Oriented Monitoring and Alarming Perspective," Service-Oriented
System Engineering, 2008. SOSE '08. IEEE International
Symposium on , vol., no., pp.215-220, 18-19 Dec. 2008
[KUR06] Kruchten, Philippe; Obbink, Henk ; Stafford, Judith., “The Past,
Present, and Future of Software Architecture”. IEEE Software, vol.

48. 48
23-2, Mar-Abr 2006, pp. 22-30.
[LAN08] Lane, M.; Agerfalk, P., "On the Suitability of Particular Software
Development Roles to Global Software Development", Global
Software Engineering, 2008. ICGSE 2008. IEEE International
Conference on , vol., no., pp.3-12, 17-20 Aug. 2008.
[LIN07] Lings B., Lundell B., Ågerfalk P. J., Fitzgerald B., "A reference model
for successful Distributed Development of Software Systems," Global
Software Engineering, 2007. ICGSE 2007. IEEE International
Conference on , vol., no., pp. 130-139. 2007
[LOP04] Lopes, L.,“Um Modelo de Processo de Engenharia de Requisitos
para Ambientes de Desenvolvimento Distribuído de Software.”
Dissertação de Mestrado, PPGCC, Faculdade de Informática,
PUCRS, 2004.
[MAH99] Mahemoff, M.; Johnston, L., "Handling multiple domain objects with
Model-View-Controller," Technology of Object-Oriented Languages
and Systems, 1999. TOOLS 32. Proceedings , vol., no., pp.28-39,
1999
[MAR09] Martignoni, R., "Global Sourcing of Software Development - A
Review of Tools and Services," Global Software Engineering, 2009.
ICGSE 2009. Fourth IEEE International Conference on , vol., no.,
pp.303-308, 13-16 July 2009
[MOC01] Mockus, A.; Weiss, D., "Globalization by chunking: a quantitative
approach," Software, IEEE , vol.18, no.2, pp.30-37, Mar/Apr 2001
[OAS10] OASIS Advancing open standards for the information society.
“Universal Description, Discovery and Integration v3.0.2 (UDDI)”.
Capturado em: http://www.oasis-open.org/committees/uddi-
spec/doc/spec/v3/uddi-v3.0.2-20041019.htm. Maio 2010.

49. 49
[OLS96] Olson, J. S. ; Teasley, S., “Groupware in the wild: lessons learned
from a year of virtual collocation”, Proceedings of the 1996 ACM
conference on Computer supported cooperative work, p.419-427,
November 16-20, 1996, Boston, Massachusetts, United States
[OSH07] Oshri I., Kotlarsky J. and Willcocks L.P., “Global Software
Development: Exploring Socialization in Distributed Strategic
Projects”, Journal of Strategic Information Systems 16 (1), pp. 25-49.
2007
[PAP07] Papazoglou, M.; Traverso, P.; Dustdar, S.; Leymann, F., “Service
oriented computing: State of the Art and Research Challenges.”IEEE
Journals, v.40, 2007, pp.38-45.
[PIL06] Pilatti, L. S. M., “Estrutura e Características para Análise de
Ambientes de Desenvolvimento Global de Software em
Organizações Offshore Insourcing.” Dissertação de Mestrado,
PPGCC, Faculdade de Informática, PUCRS, 2006.
[PRI08] Prikladnicki, R.; Damian, D.; Audy, J., "Patterns of Evolution in the
Practice of Distributed Software Development in Wholly Owned
Subsidiaries: A Preliminary Capability Model," Global Software
Engineering, 2008. ICGSE 2008. IEEE International Conference on ,
vol., no., pp.99-108, 17-20 Aug. 2008
[PRI09] Prikladnicki, R., “Padrões de Evolução na Prática de
Desenvolvimento de Software em Ambientes de Internal Offshoring:
Um Modelo de Capacidade.” Tese de Doutorado, PPGCC,
Faculdade de Informática, PUCRS, 2009.
[RAV89] Ravindran, K.; Chanson, S.T.; Ramakrishnan, K.K.; , "Reliable client-
server communication in distributed programs," Local Computer
Networks, 1989., Proceedings 14th Conference on , vol., no.,
pp.242-251, 10-12 Oct 1989

50. 50
[SHR05] Shroff, G.; Mehta, A.; Agarwal, P.; Sinha, R.; , "Collaborative
development of business applications," Collaborative Computing:
Networking, Applications and Worksharing, 2005 International
Conference on , vol., no., pp.6 pp., 2005
[VAL09] Valipour, M.H.; Amirzafari, B.; Maleki, K.N.; Daneshpour, N., "A brief
survey of software architecture concepts and service oriented
architecture," Computer Science and Information Technology, 2009.
ICCSIT 2009. 2nd IEEE International Conference on , vol., no.,
pp.34-38, 8-11 Aug. 2009
[WAU09] Wautelet, Y.; Achbany, Y.; Kiv, S.; Kolp, M., "A Service-Oriented
Framework for Component-Based Software Development: An i*
Driven Approach,". ICEIS 2009: pp. 551-563