• Save
ARQUITETURA DISTRIBUÍDA DE SOFTWARE PARA AMBIENTE DE DESENVOLVIMENTO DISTRIBUÍDO
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 3,365 views

ARQUITETURA DISTRIBUÍDA DE SOFTWARE PARA

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

Statistics

Views

Total Views
3,365
Views on SlideShare
3,362
Embed Views
3

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 3

http://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL FACULDADE DE INFORMÁTICAPROGRAMA 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 Arquitetura Distribuída de Software para Ambiente de Desenvolvimento Distribuído RESUMO No ambiente em que estamos vivendo atualmente, o processo deglobalização está se destacando, o que está gerando grande desafio para a áreade Engenharia de Software (ES), tornando o desenvolvimento de software cadavez mais distribuído e global. Em busca de vantagens competitivas, tais comobaixo custo, ganho de produtividade e qualidade, as organizações optam pordistribuir o processo de desenvolvimento de software em outros países com custode produção mais acessível. Cada vez mais projetos estão sendo desenvolvidosem ambientes geograficamente distribuídos, caracterizando o desenvolvimentodistribuído de software (DDS), que está tornando-se uma tendência na indústria.Entretanto, os desafios apresentados pela distribuição das equipes envolvidas noprocesso de desenvolvimento de software são significativos. Portanto, torna-secada vez mais importante encontrar maneiras de atenuar estas dificuldades. Estetrabalho apresenta diversos tipos de arquiteturas de softwares. Após fazer umaanálise sobre as necessidades de DDS em relação à arquitetura de software,mostra que uma arquitetura de software orientada a serviço pode suavizardiversos problemas inerentes ao DDS. Palavras Chave: Desenvolvimento distribuído de software, Engenharia desoftware, Arquitetura de Software, Arquitetura Orientada a Serviço
  • 3 Arquitetura Distribuída de Software para Ambiente de Desenvolvimento Distribuído ABSTRACT Nowadays, in the environment we are living, the globalization process isgetting emerging, what is generating huge challenges to the software engineeringarea, making the software development more distributed and global. Looking forthe competitive advantages as low coast, productivity gains and quality,organizations choose to distribute their software development process to othercountries with production costs more affordable. Increasingly, projects are beingdeveloped in geographically distributed environments, featuring the distributedsoftware development, which is becoming a trend in the industry. However, thechallenges posed by the involved teams’ distribution in the software developmentare significant. Therefore, it becomes increasingly important to find ways toalleviate these difficulties. This paper presents some different types of softwarearchitectures. After an analysis on the needing for distributed softwaredevelopment in relation to software architecture, it is posed that service orientedarchitecture can alleviate many problems inherent to distributed softwaredevelopment. Keywords: Distributed Software Development, Software Engineer,Software Architecture, Service Oriented Architecture.
  • 4 LISTA DE TABELASTabela 1. Integração Central ..................................................................... 33Tabela 2. Agrupamento de Releases......................................................... 33Tabela 3. Release Trains ........................................................................... 34Tabela 4. Comparação entre trabalhos realizados .................................... 43
  • 5 LISTA DE FIGURASFigura 1. AS baseado em camadas, adaptado de [CUR08] ...................... 11Figura 2. Arquitetura de software cliente-servidor ..................................... 12Figura 3. Simples esquemático de Arquitetura Orientada a Serviços ........ 14Figura 4. Estrutura WSDL, adaptado de [DIA08] ....................................... 16Figura 5. Relacionamento entre empresas, adaptado de [AUD07]............ 21Figura 6. Nível de confiança durante projeto [AUD07] ............................... 24Figura 7. Estrutura definição de serviço [BIN07]........................................ 38Figura 8. Estrutura de uma tarefa [MOC01] ............................................... 40
  • 6 LISTA DE ABREVIATURAS E SIGLASAS Arquitetura de SoftwareDDS Desenvolvimento Distribuído de SoftwareES Engenharia de SoftwareESB Enterprise Service BusGSD Global Software DevelopmentIDE Integrated Development EnvironmentMVC Model-View-ControllerSOA Service-Oriented ArchitectureSOAP Simple Object Access ProtocolSQA Software Quality AssuranceUDDI Universal Description, Discovery and IntegrationVPN Virtual Private NetworkWSDL Web Services Description LanguageXML Extensible Markup Language
  • 7 SUMÁRIO1 INTRODUÇÃO ............................................................................................... 82 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 ....................................................................... 283 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 .............................................................................. 424 CONSIDERAÇÕES FINAIS ......................................................................... 45REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................... 46
  • 81 INTRODUÇÃO No ambiente em que estamos vivendo atualmente, o processo deglobalização está se destacando, o que está gerando grande desafio para a áreade Engenharia de Software (ES), tornando o desenvolvimento de software cadavez mais distribuído e global [AUD07]. Hoje em dia, mais projetos estão sendodesenvolvidos em ambientes geograficamente distribuídos, caracterizando oDesenvolvimento Distribuído de Software (DDS), que está tornando-se umatendência na indústria [DAM06]. O DDS é caracterizado sempre que um ou maisrecursos envolvidos no projeto estiver fisicamente distante dos demais [AUD07].Pode-se dizer também que uma equipe global de desenvolvimento de softwareestá tipicamente em países diferentes, porém colaborando em um mesmo projetode qualquer naturalidade (criação ou manutenção de software) [LAN08]. A arquitetura de software (AS) pode ser considerada uma importante áreadentro da área de ES, pois é uma etapa que une a especificação funcional dosrequisitos 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 estruturapela qual componentes e subcomponentes de sistemas interagem entre si, com oobjetivo de formar um sistema. Para apoiar o DDS, o mais apropriado seria autilização de arquiteturas de softwares modulares [AUD07]. Dentre as diversasarquiteturas de software utilizadas atualmente, podemos citar ArquiteturaOrientada a Serviço (SOA, do inglês Service-Oriented Architecture), umaarquitetura modular, a qual será um dos objetivos deste trabalho. Esta arquitetura,largamente difundida, é caracterizada por utilizar serviços para suportar odesenvolvimento de aplicações de baixo acoplamento, grande interoperatibilidadee de distribuição em massa [PAP07]. Seus serviços podem ser autônomos, comentidades independentes de plataforma e de sistema operacional, podem serdescritas, publicadas e encontradas na rede, os serviços podem executar desdepequenos processamentos para responder a uma requisição até a execução decomplexas regras de negócio [PAP07]. Qualquer parte do código ou componenteinstalado no sistema pode ser reutilizado e transformado em um serviçodisponível na rede.
  • 9 Dentro desta área de estudo, este trabalho será desenvolvido com oobjetivo de relacionar duas áreas distintas dentro de um mesmo contexto:Desenvolvimento Distribuído de Software (DDS) e Arquitetura de SoftwareOrientada a Serviços (SOA). Este tema torna-se relevante devido aos trabalhos recentes quedemonstram o crescimento do uso do DDS na indústria de desenvolvimento desoftware. Conforme [DAM06, HER01], a busca das vantagens competitivasencontradas no desenvolvimento distribuído direciona as organizações nocaminho do DDS, o que está tornando-se uma norma no mercado atual. Ajustificativa do tema, ainda pode ser constatada devido ao fato de diversosautores afirmarem que a arquitetura orientada a serviço está crescendo muitorapidamente no mercado nos últimos anos e tornando-se uma tendência nosprojetos de desenvolvimento de software [HON09, PAP07, DIA08, KUA08,WAU09, SHR05]. Para alcançar os objetivos citados, este trabalho estará estruturado daseguinte forma: a seção dois destinada a apresentar a Base Teórica envolvendoas áreas de Arquitetura de Software, com foco em SOA, e desenvolvimentodistribuí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 dapesquisa em desenvolvimento.
  • 102 BASE TEÓRICA Com equipes cada vez maiores, e com a grande complexidade dossistemas de informação que são construídos atualmente, a padronização nosprocessos de desenvolvimento de software torna-se vital para o sucesso dosprojetos. Neste sentido, emerge a área de Arquitetura de Software (AS). Sendoassim, neste capítulo apresentam-se detalhes sobre AS e o processo deDesenvolvimento Distribuído de Software (DDS). Na seção 2.1 são apresentadasdefinições de arquiteturas de software. Na seção 2.1.1 será abordada emprofundidade a arquitetura orientada a serviços. Na seção 2.2 são apresentadosdetalhes sobre desenvolvimento distribuído de software, e finalmente na seção2.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 desoftware 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 dediversos problemas das empresas. Já segundo Kruchten, Obbink e Staford [KUR06], pode ser definida como aestrutura pela qual componentes e subcomponentes de sistemas interagem entresi, com o objetivo de formar um sistema. Para o desenvolvimento deste trabalho, adotaremos a definiçãoapresentada por Kruchten, Obbink e Staford [KUR06]. Esta escolha foi realizadadevido ao fato dos autores mostrarem que a interação entre componentes éutilizada para a construção de um sistema, o que nos remete a arquiteturasmodulares, 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 deprocessos de desenvolvimento de software:
  • 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, querepresentam a funcionalidade principal de sistema, views que exibem os modelosaos usuários do sistema e, finalmente em controllers que permitem ao usuáriofazer modificações nos models [MAH99], ou seja, representam as regras denegócio da aplicação. Esta AS tem nível baixo de acoplamento, pois acesso a dados, regras denegócios, e a interação com o usuário estão localizadas em diferentes camadas[CUR08]. A arquitetura MVC é mais comumente encontrada em aplicaçõesdesenvolvida para a internet. Nestes tipos de aplicações é comum separar dados,interface com o usuário e regras de negócio em diferentes camadas, conformemostrado pela Figura 1. Figura 1. AS baseado em camadas, adaptado de [CUR08] Dentre os pontos fortes da arquitetura baseada em camadas, pode-sedestacar, o baixo nível de acoplamento entre as camadas [CUR08] e a facilidadede ser implementada nas linguagens de programação mais utilizadas atualmente,normalmente com auxílio de ferramentas de desenvolvimento de software quedão suporte a este tipo de sistema [MAH99]. Apesar de ser altamente utilizada, este tipo de arquitetura de softwarepossui alguns pontos fracos, dentre eles, é possível destacar a dificuldade de
  • 12separar totalmente a camada view e camada controller, pois as ferramentas deprogramação mais utilizadas atualmente (IDEs) normalmente misturam asentradas e saídas destas duas camadas [MAH99]. Outro ponto fraco a serdestacado é o desempenho desta arquitetura que devido a grande interação entreas 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 entrequem solicita a execução de uma tarefa (cliente) e quem irá, de fato, executaresta tarefa (servidor) [RAV89]. O funcionamento acontece do seguinte modo: osprocessos que implementam os serviços, são chamados servers. Os serversexpõem uma visão abstrata dos seus serviços, onde ficam descritas as suasoperações (também conhecidos como stubs). Os clientes têm acesso a essasvisões abstratas e, a partir delas, é possível fazer as requisições aos servers[RAV89]. Os servers podem, em determinados momentos, ser ao mesmo temposervidor 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 essaarquitetura pode ser implementada, incluindo o caso onde um servidor pode serconsiderado cliente e servidor ao mesmo tempo. Figura 2. Arquitetura de software cliente-servidor
  • 13 Dentre os pontos fortes desta arquitetura, podemos citar a centralização doprocessamento e armazenamento de dados, o que facilita o controle do acesso àsinformações do sistema. Como o controle de segurança é realizado no lado doservidor, o sistema tem maior facilidade no controle aos dados e recursos,garantindo assim que apenas os clientes com as permissões apropriadas possamacessar e alterar dados. Outra vantagem desta arquitetura está na manutenção,pois é possível reparar, realizar upgrades ou substituir servidores, com um baixoimpacto 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 chamadassimultâneas para um mesmo servidor pode ocasionar uma sobrecarga. Outroponto importante a ser destacado é que ao acontecer uma falha no servidor, osclientes 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-OrientedArchitecture), é uma arquitetura largamente difundida, caracterizada por utilizarserviços para suportar o desenvolvimento de aplicações de baixo acoplamento,grande interoperatibilidade, por ser altamente escalável e por sua facilidade dedistribuição [PAP07]. Seus serviços podem ser autônomos, com entidadesindependentes de plataforma e de sistema operacional, podem ser descritas,publicadas e encontradas em uma rede (intra ou extranet). Os serviços podemexecutar desde pequenos processamentos para responder a uma requisição até aexecução de complexas regras de negócio [PAP07]. Qualquer parte do código oucomponente instalado no sistema pode ser reutilizado e transformado em umnovo serviço disponível na rede. SOA é uma arquitetura para sistemas distribuídos. Através do uso deinterfaces previamente definidas entre os vários componentes da aplicação,também chamados de serviços, os sistemas integram estes serviços com oobjetivo de alcançar requisitos do sistema. A Figura 3 mostra um esquema muitosimples que ilustra este comportamento, apenas para dar uma idéia como é ofuncionamento de uma arquitetura orientada a serviço. Nesta figura é possível
  • 14observar que existem três serviços expostos na rede, onde tem duas aplicaçõesque poderiam combinar estes componentes de diversas maneiras, para que osseus requisitos sejam alcançados de forma satisfatória. Por exemplo, a AplicaçãoABC que foi implementada usando tecnologia Java precisa consultar umcomponente que foi implementado em .Net, que está exposto na rede, e logoapós realizar uma consulta ao banco de dados. Enquanto que a Aplicação XYZrealizará apenas uma consulta à base de dados. A regra de negócio das duasaplicações é completamente diferente, porém conforme ilustrado, para ambos oscasos, esta arquitetura seria suficiente para resolver o problema, apenascombinando de maneira correta as chamadas aos componentes. A próxima seção2.1.1 irá discutir com maior profundidade o funcionamento desta arquitetura, suasformas de implementação e as principais vantagens e desvantagens destaarquitetura. Figura 3. Simples esquemático de Arquitetura Orientada a Serviços2.1.1 Arquitetura de Software Orientada a Serviço (SOA) Conforme apresentado nos objetivos deste trabalho, pretende-se mostrar orelacionamento de uma arquitetura de software orientada a serviço (SOA) com odesenvolvimento 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
  • 15desta arquitetura e, finalmente, as principais vantagens e desvantagens nautilização de SOA. Existem várias maneiras de definir SOA. Diferentes autores mostramdefinições distintas, porém todas convergem para uma mesma direção. Para XieDan et al [DAN08], SOA é uma arquitetura de software desenvolvida para criar umambiente dinâmico de serviços dispostos em rede, possíveis de serem usadoscomo componentes. Definindo de uma forma abstrata, SOA pode ser descritacomo um conjunto de componentes que podem ser utilizados, e os quais, suasdefinições de interfaces podem ser descritas na rede para que os mesmospossam ser encontrados [DAN08] Segundo Hongqi Li et al [HON09], SOA é um modelo de arquitetura desoftware para sistemas distribuídos, a qual utiliza padrões e interfaces bemdefinidas dentre todas as unidades funcionais, conhecida como serviços oucomponentes. As junções destes diversos serviços criam um sistema através darede. Estes serviços devem estar dispostos na rede de forma que os mesmospossam ser encontrados e utilizados [HON09]. Já para Michael Papazoglou et al [PAP07] SOA pode ser definida comouma arquitetura que utiliza serviços para suportar o desenvolvimento deaplicações de forma mais rápida, com menor custo, baixo acoplamento, grandeinteroperatibilidade e de distribuição em massa. Seus serviços podem serautônomos, com entidades independentes de plataforma e de sistemaoperacional, podem ser descritas, publicadas e encontradas na rede, os serviçospodem executar desde pequenos processamentos para responder a umarequisição até a execução de complexas regras de negócio. Qualquer parte docódigo ou componente instalado no sistema pode ser reutilizado e transformadoem um serviço disponível na rede [PAP07]. Conforme visto anteriormente, sistemas orientado a serviços mostram aidéia de acomodar componentes de uma aplicação em uma rede de serviços como objetivo de criar aplicações flexíveis, com processos dinâmicos de negócios ede rápida implementação. Este tipo de arquitetura pode ser desenvolvida deinúmeras maneiras, porém, a mais utilizada no mercado atualmente é através deweb-services [HON09, DIA08].
  • 16 Para que a construção desta arquitetura seja realizada de forma correta epadronizada, é necessário o conhecimento de alguns dos principais protocolosque os serviços devem utilizar [HON09, DIA08]. - SOAP: Para assegurar que as trocas de mensagens entre componentesaconteçam de forma correta, é utilizado o protocolo SOAP (do inglês, SimpleObject Access Protocol) [PAP07]. Este mecanismo consiste da definição de ummodelo de mensagem XML que deverá ser trocada entre os serviços [DIA08]. - WSDL: Para garantir o baixo acoplamento entre os componentes, é utilizado umXML que descreve o funcionamento do serviço, denominado de WSDL (do inglês,Web Services Description Language) [PAP07, DIA08]. Neste XML, estão descritosas assinaturas dos métodos expostos, seus parâmetros e tipos de retorno. OWSDL pode ser considerado um contrato entre os provedores e os consumidoresdos serviços [DIA08]. A Figura 4 mostra o conteúdo que esta mensagem devepossuir. 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ãodescreve como as informações de um serviço devem ser armazenadas para que
  • 17a publicação e a descoberta destas informações sejam realizadas de formacorreta [DIA08]. Para a construção de um software baseado em serviços é necessário quehaja uma estrutura de comunicação interligando todos os componentes ouserviç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ãoempacotados como componentes ou serviços e fornecem funcionalidades bemdefinidas e são independentes dos outros serviços existentes [HON09].Finalmente estes componentes são instalados no ESB. A utilização deste tipo deestrutura ao sistema agrega grandes vantagens. Os benefícios que mais sedestacam, além dos já citados anteriormente são [DAV08]: - Transparência de localização: não é necessário que o cliente tenha oconhecimento onde o serviço está fisicamente. O cliente precisa saber apenas umendereço lógico para o serviço. Desta maneira, o gerenciamento dos serviçospode ficar mais flexível. É possível adicionar, mover ou remover serviços sempreque 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ãorealizadas através desta camada, as mensagens recebidas e envidas podem, deforma apropriada, sofrer transformações, ou serem enviadas a outros serviços ecriando assim, uma composição de serviços, mantendo a transparência para osclientes [DAV08]. - Composição de serviços: o ESB pode fazer o papel de um roteador demensagens, fazendo assim a chamada de inúmeros serviços, fazendo acomposiçã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 eos clientes, fica apropriado que a segurança resida nesta camada. Toda arequisição recebida passará obrigatoriamente pela segurança [DAV08].
  • 18 - Monitoramento: como todos os serviços disponíveis estão expostos paraos clientes através do ESB, é possível que o monitoramento destes serviços sejarealizado por esta camada. Existem duas principais formas de realizar omonitoramento através do ESB: proativa e reativa. Na proativa, é monitoradocomo está o desempenho do sistema e é possível através desses dados obtidossaber o momento de fazer um aumento da capacidade do sistema.Diferentemente, na abordagem reativa, o administrador do sistema definemétricas para monitorar e para cada uma destas métricas são definidas condiçõesque poderiam gerar problemas. Ao alcançar estas condições, o sistema disparaalarmes e os envia para os administradores analisarem os problemas. Atualmente, diversas empresas disponibilizam implementações comerciaisde 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 umatendência nos projetos de software [HON09, PAP07, DIA08, KUA08, WAU09,SHR05]. Esse crescimento está diretamente ligado às vantagens que estaarquitetura disponibiliza. A relação de vantagens a seguir, mostra as mais citadaspelos autores e, certamente, não é uma lista definitiva: baixo acoplamento,possibilidade do reuso, a modularidade [HON09, DAV08, DIA08], possibilidade decompor serviços para gerar um novo serviço [HON09, DIA08], baixo custo naconstrução de serviços, ou até mesmo utilizando a compra de componentes deterceiros [PAP07, WAU09], flexibilidade [DIA08]. Apesar das inúmeras vantagens que esta arquitetura oferece, algumasdesvantagens podem ser identificadas. Segundo Hongqi Li et al [HON09] autilização de um Enterprise Service Bus, pode dificultar o sucesso do projeto. Ajustificativa do autor para esta afirmação é que a utilização do ESB podeaumentar 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.
  • 192.2 Desenvolvimento Distribuído de Software No ambiente em que estamos vivendo atualmente, o processo deglobalização está se destacando, gerando um grande desafio para a área deengenharia de software (ES). Na busca de vantagens econômicas na construçãode softwares [PRI09], empresas estão tornando o desenvolvimento cada vez maisdistribuído e global. Hoje em dia, mais projetos estão sendo desenvolvidos emambientes geograficamente distribuídos, caracterizando o DesenvolvimentoDistribuído de Software (DDS), o qual está tornando-se uma norma na indústriade software [DAM06, HER01]. As empresas de software são levadas ao uso de DDS, pois a construçãode 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 seuscustos de produção de software e, portanto, aumentar a sua competitividade nomercado [PRI08] O DDS não é um conceito novo. DDS surgiu nos anos 90, onde asempresas começaram a desenvolver software com times distribuídos [LAN08]. ODDS é caracterizado sempre que um ou mais recursos envolvidos no projetoestiver fisicamente distante dos demais [AUD07]. Quando a distância física entreos elementos dos times do projeto abrange mais de um país, caracteriza-se oDesenvolvimento Global de Software (GSD, do inglês Global SoftwareDevelopment) [LAN08]. As formas de distribuição das equipes em DDS podem variar entre ascompanhias. A escolha da forma de utilização do DDS deve ser realizada combase no tipo de projeto a ser desenvolvido. Com isso, torna-se relevante adefinição de alguns conceitos utilizados para realizar esta caracterização:Outsourcing e Insourcing (formas de relacionamento entre empresas); Inshore eOffshore (distribuições geográficas). Outsourcing: também conhecido como terceirização é a contratação deuma empresa para realizar um serviço. É encontrado no momento em que umaempresa designa uma tarefa a ser realizada por uma empresa contratada [PRI09].
  • 20Alguns autores defendem que esta é a forma mais fácil e rápida deimplementação [AUD07, BIN07]. Insourcing: conceito que surgiu em oposição ao outsourcing [PIL06]. Esteconceito é caracterizado quando as empresas criam os seus próprios centros dedesenvolvimento. Dentre os motivos que levam a utilização do insourcing está omaior controle sobre os negócios da empresa, a maior flexibilidade e o menorcusto a longo prazo [AUD07]. Este modelo é considerado o que possui maiorcomplexidade e que demanda mais tempo para sua implementação. Offshore: consiste em enviar serviços ou projetos para uma companhialocalizada em um país diferente da localização da matriz [PIL06]. Pode ser umaempresa contratada ou até mesmo uma subsidiária da matriz [AUD07]. Paísescomponentes do grupo econômico BRIC estão cada vez mais tornado-se umaalternativa atraente para este tipo de serviço, pois apresentam baixos custoscomparados com Estados Unidos e Europa. A motivação para a utilização destemodelo está na redução de custos, capacidade de ampliar e reduzir a equipeconforme a demanda e o acesso a profissionais com habilidades específicas[PIL06]. Esta forma de distribuição é mais indicada para projetos que possuemplano de projeto bem definido e com requisitos de sistemas completamenteentendidos [AUD07]. Onshore: ocorre quando a matriz e o cliente estão localizados no mesmopaís. Duas situações distintas podem ocorrer neste modelo. Todo odesenvolvimento é realizado na empresa contratada, em um local fisicamentedistinto da empresa contratante, o que caracteriza o offsite. Outra situação équando o desenvolvimento é realizado fisicamente no mesmo local onde o clienteestá, e assim caracterizando o onsite [PRI09]. A Figura 5 mostra a combinação dos modelos de negócio mais adotadospelas empresas [AUD07] em relação ao modelo de trabalho entre as empresas eas suas distribuições geográficas.
  • 21 Figura 5. Relacionamento entre empresas, adaptado de [AUD07] A Figura 5 nos remete a quatro principais modelos de desenvolvimentodistribuído, os quais são caracterizados a seguir: Onshore insourcing: o modelo mais simples e conhecido. É basicamenteuma demanda interna da empresa, onde a partir da necessidade da construçãode um software, um departamento dentro da própria empresa, ou até mesmo umasubsidiária é responsável pelo seu desenvolvimento. Como temos o termoOnshore, vale destacar que este departamento ou subsidiária deve estargeograficamente 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 umasubsidiária desenvolver o projeto, neste modelo, o desenvolvimento é realizadopor uma empresa terceirizada. Como novamente temos o termo onshore, deveficar claro que a companhia que desenvolverá o projeto deve estar localizadafisicamente no mesmo país que a contratante. Offshore insourcing: este modelo implica na criação de um centro dedesenvolvimento da própria empresa. Devido ao uso do termo offshore, estáimplícito que esta subsidiária criada deve estar obrigatoriamente em um paísdistinto da matriz. Esta subsidiaria é responsável por executar serviços dedesenvolvimento de software para a matriz (insourcing). Offshore outsourcing: o termo outsourcing nos leva a definir que umaempresa terceira será contratada, e offshore remete a diferente localizaçãogeográfica da contratante. Então, este modelo representa a contratação de uma
  • 22empresa terceira, localizada em um país diferente para prover serviços dedesenvolvimento de software. O DDS apresenta muitos fatores motivadores que levam as empresas autilizar cada vez mais este conceito em seus negócios. A seguir são apresentadosalguns destes fatores. Optou-se por apresentar as vantagens mais citadas pordiferentes autores. - Redução de custos [LAN08, DAM06, PRI08, AUD07, MAR09]:organizações procuram alternativas para que o custo de produção seja cada vezmenor. Desta maneira, contratam mão de obra de outro país ou localidade onde ocusto de produção seja mais baixo [KNO07], e assim alcançam o objetivo dereduzir custos; - Ganho de proximidade com o cliente [LAN08]: como a demanda desoftware cresce em diversos países [KNO07], uma empresa que estejaexpandindo seus negócios para uma nova região poderia iniciar uma operação deDDS nesta localidade e, assim, estaria se aproximando dos seus clientes. - Redução do tempo de projeto [LAN08, DAM06, PRI08]: também chamadode time-to-market, incluir um produto no mercado antes do concorrente pode servital para o sucesso do mesmo. Sendo assim, com mais recursos trabalhando nosprojetos, o tempo de desenvolvimento pode ser reduzido. Ainda é possível citar avantagem que é alcançada através da diferença de fuso horário entre osdiferentes centros de desenvolvimento da empresa, que torna possível o uso dochamado desenvolvimento follow-the-sun, onde a qualquer momento do diahaverá 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ãoespecializada quanto em projetos tradicionais, porém com a vantagem de mantero baixo custo. Apesar de todas as vantagens que o DDS disponibiliza para asorganizações, o processo de desenvolvimento de software continua sendo umaatividade complexa. Utilizando o DDS, adiciona-se ao processo outros inúmeros
  • 23problemas, como a distância física, diferenças de fusos horários e diferençasculturais [PRI09, AUD07, DAM06], os quais tornam este tipo de projetoextremamente complexo de ser gerenciado. Portando, diversas dificuldades sãoadicionadas ao processo de desenvolvimento de software, e essas novasadversidades devem ser conhecidas e gerenciadas para alcançar o sucesso noDDS. Segundo alguns autores, as adversidades encontradas no DDS podem serdivididas em algumas categorias [AUD07, PRI09, KNO07, PIL06], as quais afetamdeterminadas áreas do processo. Procuram-se listar algumas das dificuldadesencontradas no DDS mais citadas por diferentes autores: Problemas relacionados a Pessoas [PRI09], também identificado comoproblemas sociais [PIL06, KNO07] dizem respeito aos problemas que afetamdiretamente 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 quegeralmente depende da cooperação de vários membros dentro da equipe, aconfiança torna-se fundamental. Esta relação é essencial para o bomfuncionamento da equipe, resultando em diversos benefícios, como melhora nodesempenho, redução de custo e maior sociabilidade entre os membros daequipe [AUD07, PRI09]. Algumas formas de interação podem facilitar o aumentoda confiança entre os elementos dos times distribuídos, dentre elas, podemoscitar: 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 caircom o passar tempo, por esta razão, torna-se importante encontros no decorrerdo projeto.
  • 24 Figura 6. Nível de confiança durante projeto [AUD07] - Conflitos: Como em qualquer projeto de desenvolvimento de software, conflitospodem acontecer. Em alguns casos, eles podem ser benéficos para o projeto epodem ser resolvidos no próprio processo de desenvolvimento. Porém podemacontecer 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 doprojeto. Este teria o papel de sanar os conflitos, tomando a decisão que julgarmais adequada. Deve ser a autoridade central do projeto [AUD07, PRI09]. - Diferenças culturais: Diferenças culturais fazem parte do cotidiano no DDS. Com timesdistribuídos ao redor do globo, os problemas relacionados à cultura emergemmuito rapidamente. Culturas diferentes pensam, comunicam-se e agem de formasdistintas [BIN07]. Em um país, algo que possa ser trivial e corriqueiro, em outrolocal pode ser algo completamente incomum. Neste sentido, é recomendado queas equipes compreendam cada cultura, e que adéquam suas expectativas emrelação as diferenças existentes. Algumas companhias utilizam o conceito deliaison, que consiste em ter um membro da equipe que age como uma ponte entreculturas diferentes [AUD07, HER99, HOL06, LAN08, LIN07]. Normalmente estapessoa já conviveu com essa cultura e por isso pode fazer este papel. Porexemplo, um brasileiro trabalhando nos Estados Unidos auxiliando o ladobrasileiro do time distribuído a compreender comportamentos da equipeamericana [AUD07].
  • 25 - Liderança: Questões relacionadas a liderança são tratadas de forma diferentedependendo da cultura. Algumas culturas tratam a liderança com menos rigor doque em outras, ou seja, encorajam a participação do time nas tomadas dedecisões. Enquanto que outras culturas utilizam uma estrutura mais hierárquica etomam as decisões de maneira autônoma, sem permitir que seus comandadosexpressem suas opiniões. - Diferentes fusos horários: As diferenças de fusos horários podem afetar os projetos de DDS dediferentes formas. Para equipes separadas por uma pequena diferença dehorário, podem passar a maior parte do dia trabalhando ao mesmo tempo. Nestemodo 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ídeoconferências, etc. Como exemplo, podemos citar uma equipe localizada na cidadede Nova Iorque, e outra em São Paulo. Para este caso a diferença seria deapenas uma hora na maior parte do ano. Os problemas relacionados ao fusohorário começam a ficar mais evidentes na medida em que a diferença começa aaumentar. Por exemplo, quando essa diferença atinge algo em torno de cincohoras, a possibilidade de trabalhar juntos na maior parte do tempo já não é maisválida. Então, para este caso, a comunicação síncrona tende a diminuir e acomunicação assíncrona aumenta. Para este exemplo, poderíamos citar umaequipe localizada em Nova Iorque e outra em Londres. Para este caso a diferençaseria de cinco horas na maior parte do ano. Finalmente temos o caso em que asequipes distribuídas nunca trabalham no mesmo horário. Neste caso, quandouma equipe está terminando o seu dia de trabalho a outra está começando. Nestecaso além da falta de comunicação síncrona, torna-se vital que a comunicaçãoassíncrona seja realizada de forma clara e efetiva. Qualquer dependência de umaresposta de algum membro do outro time pode demorar no mínimo um dia. Comesta diferença de fuso horário, alguns autores defendem que seja possível utilizaro desenvolvimento follow-the-sun – desenvolvimento 24 horas por dia, porém esteconceito é pouco utilizado na indústria [HOL06, LIN07]. Para este exemplo,
  • 26poderíamos citar uma equipe localizada em São Paulo e outra em Tóquio, onde adiferenç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 deprocessos [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 oslocais envolvidos (principalmente em casos de distribuição global). Essasdiferenças implicam em maior complexidade no estabelecimento de contratos,bem como a necessidade de cautela com questões de sigilo e propriedadeintelectual [KAR98]. - Gerenciamento de portfólio de projeto: Este tipo de gerenciamento tem surgido como um importante aliado nogerenciamento de projetos. O principal objetivo deste tipo de gerenciamento não éexecutar projetos de desenvolvimento de software corretamente. Seu principalobjetivo é realizar os projetos corretos, nos momentos adequados, baseado nasestratégias da empresa. Os desafios desta área estão em determinar através dediversas análises como os projetos de DDS serão desenvolvidos, definir como oprojeto 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 modelosde negócio. Não existe o modelo correto, mas existe o modelo mais adequado aoproblema a ser resolvido. Para fazer a decisão sobre qual modelo será utilizado,as empresas devem realizar uma análise e identificar suas reais necessidadescom a utilização do DDS, e quais os tipos de projetos que pretende distribuirgeograficamente. A partir desses dados, uma decisão mais precisa pode sertomada. A prática demonstra que um bom planejamento tem determinado osucesso no modelo escolhido [PRI09].
  • 27 Problemas relacionados à Projetos [PRI07, HER01] também identificadospor [PIL06, KNO07] como problemas técnicos, contemplam dificuldadesrelacionados a forma como o projeto será desenvolvido, incluindo o uso deferramentas e métodos [PRI09]. Dizem respeito ainda as adversidadesrelacionadas 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 é aescolha da arquitetura de software [BOS10]. Uma AS apropriada para este tipo deprojeto deve ser uma arquitetura modular, pois desta forma é possível alocartarefas 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çãopode tornar-se um fator decisivo. Para contornar este problema, a utilização deuma metodologia de desenvolvimento de software impõe rigor à equipe. Nestesentido, é possível verificar que cada vez mais as companhias buscam excelênciana 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. Nestesentido, é 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 asformas de conexões que possam ser utilizadas. Atualmente a maior parte daslocalidades já possui esta infra-estrutura. A segurança nesta comunicaçãotambém é um fator importante. Hoje em dia, existe grande diversidade de opçõestecnológicas que garantem esta segurança. Ultimamente tem crescido a opção
  • 28pelo 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, juntamentecom o gerenciamento dos processos de desenvolvimento do sistema pode sercomplexo. Para diminuir esta dificuldade é recomendada a utilização de umrepositó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 deprojeto deve sofrer adaptações em relação ao modelo tradicional utilizados emtime co-localizados. É recomendada a utilização de técnicas mais formais degerenciamento [PRI09]. Com as informações apresentadas na seção 2.1, onde foi abordada aarquitetura de software, e na seção 2.2, onde o tema tratado foi DDS. A próximaseção visa fazer o relacionamento entre estas duas áreas e demonstrar aimportância deste relacionamento.2.3 Relacionando DDS e AS Na busca das vantagens competitivas encontradas no desenvolvimentodistribuí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 empresasainda encontram muitas adversidades na implementação deste modelo deprocesso de desenvolvimento de software. Conforme apresentado anteriormente,uma maneira para contribuir na redução de algumas destas dificuldades está nautilização de uma arquitetura de software adequada [AUD07, PRI09, HER99,BOS10]. Neste sentido, a escolha de uma AS ideal é considerado um dos fatores
  • 29determinantes para o sucesso de um projeto de desenvolvimento distribuído desoftware [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ípioda modularidade deve estar presente [AUD07, PRI09, HER99]. A modularidadepermite que tarefas independentes sejam desenvolvidas paralelamente de formadistribuída [AUD07, PRI09]. Assim, a necessidade de integração entre os timesalocados em diferentes locais tende a diminuir evitando alguns problemasinerentes ao DDS, como por exemplo, o impacto cultural entre equipesdistribuídas [BIN07]. Uma arquitetura modular, onde diferentes tarefas podem ser realizadas deforma distribuída e independente pode ocasionar diversos problemas, se osmesmos não forem detectados na fase inicial do processo. Um dos problemasmais comuns neste tipo de projeto está no momento da integração do produtofinal. Quando o projeto chega a um estado avançado do seu desenvolvimento, eentra na fase de integração, algumas vezes, problemas de incompatibilidade entrecomponentes são encontrados. Estes problemas são identificados somente nestafase, por diversas razões. Uma delas é a falha no processo de definição dasinterfaces de integração do sistema, ou seja, estabelecer critérios decomunicação entre os diferentes componentes que irão compor o sistema. Estadefinição deve levar em conta todas as possíveis comunicações que umdeterminado serviço ou componente possa vir a realizar, portanto torna-seimportante a definição de formatos de mensagens (WSDLs) precisos e genéricoso suficiente. Após ter o completo entendimento dos requisitos, as equipes que possuemacoplamento entre os seus componentes devem concordar que a mensagemWSDL definida para tal serviço é suficiente, e que não haverá a necessidade deadicionar ou remover elementos. Porém, em projetos de desenvolvimento desoftware, os requisitos podem sofrer diversas alterações no decorrer do ciclo dedesenvolvimento. Estas modificações devem ser analisadas e o impacto destamudança identificado. Se as alterações dos requisitos impactarem nacomunicação entre componentes, as interfaces relativas aos mesmos devem ser
  • 30reavaliadas para evitar problemas. As alterações de interfaces, caso sejamnecessárias, devem ser realizadas o quanto antes. Para que isso ocorra de formacorreta, os times distribuídos, que possuem os componentes impactados por estamodificação de requisito devem redefinir e concordar com o novo formato demensagem que serão trocadas entre os componentes, assim evitando futurosproblemas de integração. Outro fator importante a ser destacado é que o conhecimento entre asequipes distribuídas é fundamental [HER99]. O exemplo a seguir ilustra estasituação: quando o time de desenvolvimento que está alocado no Brasil percebeum erro na definição de um tipo de atributo contido na mensagem que o seuserviço está utilizando para trocar informações com um serviço desenvolvido poruma equipe alocada nos Estados Unidos. Este erro encontrado poderia ser que,ao invés de um atributo receber um valor booleano, este deveria conter apenasum 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 serrealizada na comunicação. Nesta situação, fica evidente a importância doconhecimento entre as equipes distribuídas [HER99], pois o time dedesenvolvimento do Brasil deve saber a qual elemento da equipe americanarecorrer para solucionar este problema. A modularidade está diretamente ligada ao completo funcionamento daintegração do sistema, caso contrário, utilizar uma arquitetura modular não evitouproblemas. Outra característica relacionada com a modularidade para uma AS,que aumenta a probabilidade de sucesso de um projeto que utiliza DDS, é o baixoacoplamento. Esta propriedade visa ter os componentes mais independentespossíveis uns dos outros. Isso se torna importante no processo dedesenvolvimento do software, pois quanto menor o número de conexões entre osserviços, menor o número de pontos de falhas. Logo, os problemas de integraçãotendem a diminuir na medida em que o acoplamento diminui [OLS96]. As características acima citadas demonstram que torna-se interessante ouso de uma arquitetura orientada a serviço (SOA) para projetos dedesenvolvimento distribuído de software, pois esta arquitetura possui ascaracterísticas adequadas para o DDS. Esta afirmação está em consonância com
  • 31os recentes trabalhos de Martignoni [MAR09], Bin Xu [BIN07], Shroff et al.[SHR05] e Bosch et al. [BOS10] que afirmam que SOA é o modelo de arquiteturamais indicado para projetos de DDS.
  • 323 TRABALHOS RELACIONADOS Embora diversos estudos reconheçam a importância da arquitetura desoftware em um projeto de desenvolvimento de sistemas e também reconhecemas vantagens que o DDS pode agregar nos projetos de softwares, após umapesquisa extensa, encontrou-se apenas um número reduzido de artigos quemostram 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 deprojetos de softwares, porém todos convergem para uma mesma conclusão: aescolha de uma AS orientada a serviços pode evitar diversos problemas nosprojetos de software que utilizam DDS.3.1 Abordagem de Bosch e Bosch-Sijtsema (2010) O recente artigo publicado por Bosch e Bosch-Sijtsema [BOS10], realizaum estudo em três diferentes organizações globais de desenvolvimento desoftware, com o objetivo de identificar as principais características encontradasem diferentes dimensões: arquitetura, processos e organização. O estudo aindaapresenta, baseado nas informações coletadas na pesquisa, como pode serrealizado um processo para diminuir o acoplamento dos sistemas desenvolvidospara que estes possam ser realizados de forma distribuída. Para alcançar esteobjetivo, pesquisou projetos que utilizavam cinco estratégias distintas, as quaisserão detalhadas a seguir. A primeira estratégia de desenvolvimento pesquisada foi a que o autoridentifica como Integração Central. Neste modelo, o projeto é desenvolvido comum ponto de integração único. Na maioria dos casos, é dedicada uma fase nociclo de desenvolvimento específico para a integração do sistema, onde todos oscomponentes são testados. Nesta fase, normalmente inúmeros problemas deintegração são encontrados, os quais precisam ser resolvidos pelos times osquais os desenvolveram. A Tabela 1 apresenta as principais características
  • 33encontradas nos projetos que utilizaram esta estratégia, relacionada às trêsdimensõ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 algumasdesvantagens, o autor concluiu que para projetos onde o nível de conexão entrecomponentes é alto, este tipo de estratégia pode ser vantajoso. A segunda estratégia utilizada na pesquisa foi a que o autor chama deAgrupamento de Releases, onde as organizações dividiam os componentes emgrupos, e os pré-integravam, entregando assim, um grupo de componentes. ATabela 2 apresenta as principais características encontradas nos projetos queutilizaram 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 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 dedistribuir diferentes grupos de componentes em times geograficamentedistribuídos, fazendo o uso do DDS de forma mais efetiva. A terceira estratégia pesquisada foi a que o autor chama de ReleaseTrains, onde os grupos de componentes utilizados na estratégia anterior, nestemomento são decompostos resultando em cada componente que compõe osistema. A Tabela 3 apresenta as principais características encontradas nosprojetos que utilizaram esta estratégia relacionada às três dimensõespesquisadas. 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 Segundo o autor, a estratégia de Release Trains é adequada para projetosque necessitam realizar entregas contínuas de software. Não sendo necessária afase de integração. Basta o serviço ser instalado ao final do seu desenvolvimentoe o mesmo está pronto para ser utilizado. A quarta estratégia estudada foi a que o autor identifica como ImplantaçãoIndependente. Segundo o autor, esta estratégia deve ser utilizada pororganizações extremamente maduras, onde não seja necessária a sincronizaçãode tarefas entre os times durante as interações. Neste caso, o momento daentrega de cada componente é definido pelo time que a desenvolve, a únicaexigência é que o componente deve garantir a compatibilidade com os outrosserviç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 é queessa abordagem é interessante para times que desenvolvem tarefas de diferentescomplexidades e diferentes tempos de desenvolvimento necessário. O fator críticopara o sucesso desta estratégia está na maturidade de desenvolvimento daorganização. Processo de planejamento, design e testes devem ser apoiados porferramentas automatizadas. A quinta e última estratégia proposta versa sobre a utilização de soluçõesdesenvolvidas por terceiros. Também mostra características semelhantes àterceira estratégia. Por tratar-se de um sistema desenvolvido por terceiro, aarquitetura do sistema deve levar em consideração a garantia de segurança. Aprincipal vantagem desta estratégia, segundo o autor, é a possibilidade dediminuir 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 gerarcomplexidade aos projetos, mantendo certas características no projeto, essasadversidades podem ser drasticamente diminuídas. O principal fator apontadopelo autor está na escolha de uma arquitetura adequada, a qual deve sermodular, possuir o menor nível de acoplamento possível e possuir os pontos deintegração entre os componentes bem definidos. O autor sugere que o uso deuma arquitetura orientada a serviço é o mais adequado para este tipo de projeto,
  • 36pois desta forma, cada serviço pode ser desenvolvido em locais geograficamentedistintos.3.2 Abordagem de Martignoni (2009) O estudo realizado por Robert Martignoni [MAR09] tem como objetivoidentificar ferramentas e serviços que visam a otimização do desenvolvimentodistribuído de software. A motivação para este estudo foi a constatação que asferramentas utilizadas no desenvolvimento tradicional de software não eramsuficientemente adequadas para o processo distribuído. O método de pesquisa está baseado na identificação e classificação deferramentas e serviços utilizados no desenvolvimento de software. Num segundomomento, procurou-se por funcionalidades adicionais nestas ferramentas quepoderiam ser utilizadas exclusivamente no DDS. A busca por estas ferramentas eserviços baseou-se numa extensiva análise de mercado e uma profunda pesquisana literatura. Todas as ferramentas de desenvolvimento encontradas foramanalisadas e categorizadas da seguinte maneira: Ferramenta de Desenvolvimento: desenvolvidas especificamente paraauxiliar em uma ou mais fases do processo de desenvolvimento, como porexemplo: 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, BorlandBMS); gerenciamento de código fonte (Subversion, CSV, Virtual Safe). Segundo oautor, todas estas ferramentas suportam uma tarefa específica dodesenvolvimento de software, e podem ser utilizadas no DDS. Porém, nenhumadelas adiciona funcionalidades específicas para o DDS. Ferramenta de escrita de código: normalmente chamadas de IDEs, estasferramentas foram desenvolvidas tradicionalmente para desenvolvimento desoftware. Estas ferramentas normalmente integram editores de texto,compiladores e debuggers de código. Nesta categoria, três tipos distintos podemser identificados: (i) IDEs stand-alone, utilizada para um único programador
  • 37desenvolver suas tarefas; (ii) IDEs modificadas que permitem funcionalidades deintegração, como controle de código fonte e controle de defeitos; (iii) e finalmente,IDEs colaborativas, que integram funcionalidades de colaboração dentro doambiente de desenvolvimento. Software como serviço: está baseado na idéia de prover funcionalidadesde software como serviços distribuídos, os quais podem ser arranjados demaneira a criar um sistema único. A principal vantagem de usar esta abordagemestá na possibilidade de utilizar DDS juntamente com um repositório de códigocentral. O conceito de utilizar serviços pode diminuir a necessidade desincronizaçã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 arquiteturaque é 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ósa identificação, a categorização e as análises de ferramentas e serviços quepoderiam ser utilizadas no DSS, o autor concluiu que a utilização de umaarquitetura orientada a serviço é a mais adequada para o uso de DDS, podendoassim, cada serviço ser desenvolvido por uma equipe de desenvolvimento distintae em locais geograficamente distantes.3.3 Abordagem de Xu (2007) Bin Xu [BIN07] publicou um trabalho em 2007 relatando um modelo dedistribuição dentro de um projeto de desenvolvimento de software. O autor chamaeste modelo de Desenvolvimento Cooperativo de Software. Após analisar as diferentes formas que as organizações distribuídasgerenciavam seus recursos, Bin Xu constatou que um dos maiores problemasencontrados nos projetos de DDS estava na comunicação. Na busca da soluçãopara este problema, o autor busca investigar os problemas que a comunicaçãopode causar, e formas para evitar estes problemas em um projeto global.
  • 38 Para evitar estas adversidades, o autor propõe um processo colaborativode desenvolvimento global de software. Neste processo, entende-se que para osistema que será desenvolvido, o mesmo deve ser dividido em serviços. Estesserviços devem ser modulares e com baixo acoplamento. O autor desenvolveuma maneira formal para a descrição dos serviços, evitando assim problemas deentendimento dos requisitos. Como é possível visualizar na Figura 7, a estruturaproposta 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 deserviços, onde estas definições são adicionadas, e ficam esperando que umdesenvolvedor 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 formadistribuída. Os desenvolvedores estão alocados na cidade de Hangzhou – China– enquanto o cliente está alocado em Boston – Estados Unidos. Antes do iníciodo uso do trabalho proposto por Xu, em média, havia um atraso entre dois a trêsdias na comunicação entre as equipes distribuídas. Quando essa comunicaçãoera relacionada ao resultado do entendimento do requisito, ou a uma dúvida sobreo mesmo, geravam atrasos no projeto. Por exemplo, quando era uma dúvida, odesenvolvedor deveria esperar a resposta antes de continuar, o que demoravaem 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 algumadúvida, esta seja comunicada e, enquanto a resposta não chega, o desenvolvedorpode iniciar o trabalho com outro serviço disponível na fila. Com este processo, otempo médio total de espera de um recurso no ciclo de desenvolvimento foi de
  • 39três dias, ou seja, 2% do ciclo. Segundo o autor, este dado prova a eficiência doestudo proposto. Com este estudo, o autor concluiu que tendo uma arquitetura orientada aserviços, onde seja possível o desenvolvimento de serviços independentes, etendo serviços extremamente bem definidos, é possível amenizar asadversidades que o DDS pode ocasionar, principalmente problemas decomunicação.3.4 Abordagem de Mockus e Weiss (2001) O artigo apresentado por Audris Mockus e David Weiss [MOC01] tem comoprincipal objetivo auxiliar gerentes de projeto na escolha de tarefas que possamser distribuídas geograficamente. Para isto, iniciaram a pesquisa em algumasempresas, onde identificam as principais formas utilizadas para a distribuiçãoglobal de tarefas e suas justificativas eram: - Divisão por funcionalidades: distribuição para centros remotos, baseadosna funcionalidade do subsistema a ser desenvolvido. A principal vantagem destaabordagem é que se tem determinados centros especializados em determinadasfunções do sistema. A desvantagem pode ser que ao incluir novasfuncionalidades ao sistema, pode ser necessário que especialistas de diversoscentros trabalhem em conjunto, aumentando assim necessidade de coordenação. - Divisão por localização: nesta abordagem o autor afirma que adistribuição é realizada baseada na localização geográfica. Este tipo deabordagem foi mais utilizado em sistemas que necessitavam funcionalidadesespecíficas de determinados países ou mercados. Um exemplo para este modelopode ser a necessidade de tradução da interface gráfica de um sistema, para umdeterminado 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 dedesenvolvimento pode ser realizado em um determinado local. Segundo o artigo,um exemplo poderia ser a implementação do sistema em uma localização distinta
  • 40de onde o teste é realizado. A vantagem é manter os especialistas emdesenvolvimento em um local, porém a desvantagem é o aumento danecessidade de comunicação. - Manutenção: outra forma que os autores mostram, é que ao final do ciclode desenvolvimento, qualquer manutenção no sistema é realizada em um localdistinto, para que novos sistemas possam ser desenvolvidos. A principaldesvantagem 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 deresolução de problemas tende a ser maior. Após estas informações coletadas, os autores propõem outra abordagemde distribuição de tarefas, que seria baseada em porções de códigos. Estaabordagem tem como principal objetivo, diminuir a necessidade de sincronizaçãoe comunicação entre as equipes distribuídas. Para isso, os autores definiram uma maneira de classificar se umdeterminado tipo de trabalho pode ou não ser distribuído para diferenteslocalidades. Esta classificação está baseada na estrutura que as tarefasnormalmente 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 (softwarerelease), até pequenas modificações em um código fonte (delta) (Figura 8). Para
  • 41determinar a possibilidade de distribuição de determinado tipo de tarefa, osautores mostram que através de sistemas de controle de versão é possível mediros níveis de acoplamento que o código que está sendo alterado tem, estamedição é chamada de delta. Neste sentido, os autores afirmam que quanto menor o valor destavariação, maior a chance da distribuição desta porção de código ser realizada deforma efetiva, pois assim, quanto menor a variação, menor o acoplamento, logomaior a chance de sucesso. A conclusão dos autores é que ao distribuir tarefas bem definidas, compouca integração com outros componentes, pode ser vantajoso. Por outro lado,para tarefas que possuem alto grau de acoplamento umas com as outras, seriamais interessante fazer o desenvolvimento no mesmo local, pois nesse caso, anecessidade de comunicação entre os desenvolvedores é maior. Portanto, autilização de uma arquitetura de software adequada, com o menor acoplamentopossível, através do cálculo proposto no artigo, poderia aumentar o número detarefas 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 eRebecca E. Grinter [HER99] tem como foco principal mostrar que timesgeograficamente distribuídos enfrentam um número muito grande de problemasde comunicação e de coordenação em projetos distribuídos. Os autoresapresentam um caso de estudo que mostra como eventos comuns não previstospodem comprometer um projeto como um todo. Os problemas principais citadospelos autores dizem respeito a atrasos no cronograma e principalmenteproblemas de integração do sistema. Para este caso de estudo descrito no artigo, os autores escolheram umprojeto que estava distribuído em dois países distintos, onde era possívelidentificar algumas diferenças importantes: fuso horário, idioma e diferençasculturais acentuadas.
  • 42 Seguindo os requisitos, cada equipe iniciou o desenvolvimento dos seussubsistemas isoladamente nos seus países de origem. Cada time construiu seuspróprios simuladores que representavam componentes que os outros timesdesenvolveriam de fato. Para a construção destes artefatos, quando não se tinhauma definição clara, suposições eram usadas, muitas vezes erroneamente. Ao final do projeto, foram realizadas entrevistas com alguns líderes dostimes e constatou-se que o principal problema causado pelo uso de DDS foi naintegração do sistema. Ao final da pesquisa, após análise dos dados coletados,alguns pontos foram destacados pelos autores. Tendo uma arquitetura desoftware modular e usando este fato como base para realizar a distribuição dastarefas para diferentes locais, quanto mais claramente separados os módulos aserem desenvolvidos, maior a chance de sucesso ao desenvolvê-los emdiferentes localidades. Por este motivo, os autores defendem a utilização dearquiteturas de software modulares e com baixo acoplamento. Pois assim anecessidade de interação entre os times remotos tende a diminuir. Outro pontodestacado por este estudo mostra que só é interessante fazer a distribuição detarefas entre times distintos se estas estiverem com os requisitos muito bemdefinidos e entendidos pelos times.3.6 Análise comparativa Após a apresentação dos trabalhos relacionados, a Tabela 4 mostra umaanálise comparativa entre estas diferentes abordagens. Para cada critério(colunas), procurou-se saber se o trabalho relacionado, de alguma forma indicouimportância para este fator.
  • 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 baixoBosch 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 adivisão de trabalho em forma de serviços, para então distribuí-losgeograficamente. Porém, a ressalva que a maioria dos trabalhos indicou é quepara que isso funcione da maneira adequada, a modularidade e o baixoacoplamento entre os serviços devem estar garantidos. Os principais problemas mencionados nos trabalhos relacionados dizemrespeito às comunicações e sincronizações necessárias em projetos de DDS.Dentre os trabalhos apresentados, todos apontam a comunicação como umimportante problema enfrentado. Problemas de sincronização estão relacionadosàs dificuldades que diferentes times distribuídos têm em sincronizar odesenvolvimento do projeto. Um exemplo deste problema pode acontecer quandoum time alocado na Índia necessita de um serviço que está sendo desenvolvidopor outra equipe no México, a qual atrasou o seu desenvolvimento e impactou oprocesso de desenvolvimento do time Indiano. Este tipo de problema é apontadopela maior parte dos trabalhos apresentados. Também foi citado por mais de umautor a integração do sistema como um problema importante para projetos destanatureza. Neste sentido, as diferentes abordagens convergem, na maioria das vezes,para soluções que diminuem a necessidade de comunicação entre timesdistribuídos: fazer a distribuição de serviços bem definidos que não necessitem aintegração entre as equipes distribuídas para o seu desenvolvimento. Outros pontos a serem destacados, que estão diretamente relacionados aotrabalho em desenvolvimento, são: apenas um trabalho não citou a importância
  • 44da escolha de uma AS adequada, porém, este trabalho destaca a importância dadivisão do trabalho em serviços; e, três trabalhos afirmaram diretamente que ouso de arquitetura orientada a serviço (SOA) é o mais indicado para projetos dedesenvolvimento distribuído de software. É possível observar através dos trabalhos relacionados que os problemasmencionados são sempre semelhantes, inclusive para os trabalhos mais recentes.Podemos observar que todos os trabalhos convergem para um ponto único: autilização de serviços que possam ser desenvolvidos de forma distribuídageograficamente. Portanto, podemos identificar através deste comparativo entreos trabalhos relacionados, que existem estudos que apontam a escolha de umaarquitetura de software adequada como fator importante no processo de DDS.Encontram-se, ainda, trabalhos que mostram que para diminuir problemasinerentes ao DDS, a divisão de trabalho em serviços, antes de realizar adistribuiçã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 orientadaa serviço para solucionar os problemas evidenciados pelo DDS. Entretanto, háuma escassez na literatura atual de trabalhos que apresentam os resultadossobre como a utilização de SOA reduziu os problemas gerados em ambientes deDDS.
  • 454 CONSIDERAÇÕES FINAIS Conforme apresentado no decorrer do trabalho, a revisão da literaturaconfirmou a importância da escolha de uma arquitetura de software adequadacomo parte essencial de um processo de desenvolvimento de softwaredistribuí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 desafiostendem a aumentar. Para diversos autores [HER01, BOS10, MAR09, BIN07,MOC01], a necessidade de gerenciar uma grande variedade de dependênciasentre times geograficamente dispersos é um problema que faz parte do processode DDS. Segundo estes autores, para diminuir estes problemas é necessárioreduzir a quantidade de comunicação e sincronização necessária entre asequipes distribuídas. Para alcançar este objetivo, é recomendado eliminar asdependências entre os times, através do uso de uma arquitetura de softwareadequada. De acordo com o que foi visto nos trabalhos relacionados, a AS adequadapara um projeto de DDS deve ser uma arquitetura modular e com baixoacoplamento. A escolha de uma arquitetura com estes atributos pode ser um fatorde extrema importância para o sucesso de um projeto desta natureza. Apósavaliar os principais tipos de arquitetura de software encontrados na literatura deprocessos de desenvolvimento de software, constatou-se que a mais adequadapara a utilização de DDS é a arquitetura orientada a serviço – SOA, devido àssuas principais características. Apesar de haver, na literatura, muitos trabalhos que demonstram aimportância da escolha de uma AS com as características já mencionadas para osucesso no processo de DDS. Os estudos que apresentam os resultados sobrecomo a utilização de SOA reduz os problemas inerentes ao DDS ainda sãoinsuficientes na literatura atual. Neste sentido, esta pesquisa visa entender comoa utilização de uma Arquitetura de Software Orientada a Serviços (SOA) podediminuir as adversidades impostas pelo uso do Desenvolvimento Distribuído deSoftware (DDS).
  • 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[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: Conways 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 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[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[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