PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL                FACULDADE DE INFORMÁTICAPROGRAMA DE PÓS-GRADUAÇÃO EM ...
2    Desenvolvimento Follow-the-sun em Ambiente de Desenvolvimento                             Distribuído de Software    ...
3     Desenvolvimento Follow-the-sun em Ambiente de Desenvolvimento                                 Distribuído de Softwar...
4                                LISTA DE TABELASTabela 1. Comparação entre as definições apresentadas ......................
5                                           LISTA DE FIGURASFigura 1. Modelo cascata, adaptado de [SOM07] ...................
6           LISTA DE ABREVIATURAS E SIGLASAS    Arquitetura de SoftwareDDS   Desenvolvimento Distribuído de SoftwareES    ...
7                                                   SUMÁRIO1      INTRODUÇÃO ................................................
81 INTRODUÇÃO      No ambiente em que estamos vivendo atualmente, o processo deglobalização está se destacando, o que está...
9pois a literatura não apresenta a definição de um processo para a transferência detrabalho em projetos que utilizam esta ...
102 CONTEXTUALIZAÇÃO       O Desenvolvimento Distribuído de Software (DDS) está tornando-se umatendência na indústria de s...
11DDS é caracterizado sempre que um ou mais recursos envolvidos no projetoestiverem fisicamente distantes dos demais [AUD0...
12como a distância física, diferenças de fusos horários e diferenças culturais [PRI09,AUD07, DAM06], os quais tornam este ...
13ligado ao desenvolvimento FTS. A seguir, são mostrados exemplos de como estadiferença afeta os projetos.      Quando exi...
142.2   Desenvolvimento Follow-the-sun       Devido aos desafios impostos pelo desenvolvimento distribuído de softwarerela...
15FTS para acelerar o processo de desenvolvimento, mantendo apenas odesenvolvimento global de software [CAR09].      Para ...
163 CONCEITOS        Devido ao fato do FTS ser um assunto recente na literatura e na indústriado desenvolvimento de softwa...
17existem atualmente na grande parte dos países onde o desenvolvimento global desoftware é utilizado, estes artefatos pode...
18    ii.       Um dos principais objetivos é reduzir o tempo de desenvolvimento/              time-to-market;    iii.    ...
19                          Tabela 1. Comparação entre as definições apresentadas                                         ...
20      O follow-the-sun é tipo de desenvolvimento global de software onde oprincipal objetivo é a diminuição do time-to-m...
214 CICLOS DE VIDA NO PROCESSO DE DESENVOLVIMENTO      FOLLOW-THE-SUN       Para tornar o desenvolvimento de software uma ...
22                      Figura 1. Modelo cascata, adaptado de [SOM07]      Cada fase encontrada no modelo cascata pode ser...
23      Este modelo de ciclo de vida é recomendado para projetos onde osrequisitos estão bem definidos e são geralmente fi...
24integração continua do produto são práticas comuns em metodologias ágeis, ecabem no desenvolvimento FTS, pois deste modo...
254.1.1.2 Integração e Testes      O maior consenso encontrado na literatura relacionado a aplicação dodesenvolvimento FTS...
26                      Figura 3. Utilização do FTS durante a fase de testes      É importante destacar que, para o funcio...
274.1.1.3 Manutenção       Alguns autores citam ainda a fase de manutenção como uma fase do ciclode vida propícia para uti...
28                           Figura 5. Modelo de Prototipação      A vantagem da utilização deste modelo está na sua rapid...
294.3   Modelo Incremental       O modelo incremental utiliza elementos do modelo linear, tambémchamado de modelo cascata,...
305 ESTUDOS EM FOLLOW-THE-SUN       A literatura apresenta poucos trabalhos relacionados ao desenvolvimentoFTS [TRE06]. Ap...
31desenvolvimento FTS não gerou o ganho esperado. Os resultados mostraram umaumento de 50% no tempo necessário para o dese...
32desempenho do FTS ainda mostrou-se pior que o desenvolvimento em um únicolocal.          Na tentativa de alcançar uma me...
33tempo de desenvolvimento do projeto seria 5 semanas. Porém, como a equipeFTS faria o uso do desenvolvimento FTS, teorica...
34terminou o projeto num tempo menor que a equipe CO, porém, devido a falta deuma diretriz sobre o momento de parar a codi...
35para cada equipe distinta), dependendo do número de centros adotados. Os diasde trabalhos são contínuos, onde quando um ...
36       - Exatidão do trabalho realizado:               Haccur: accur4 < accur3 < accur2       Devido a pequena diferença...
37         Os fatores utilizados para a análise comparativa apresentada na Tabela 2surgiram de uma avaliação prévia dos es...
38Conseqüentemente, estes trabalhos sugerem um número mínimo de centros dedesenvolvimento para aumentar as chances de suce...
396 CONSIDERAÇÕES FINAIS      A utilização do DDS pelas organizações está cada vez mais comum. Istose deve ao fato das div...
40idéia: para cada funcionalidade do projeto, definem-se testes unitários antes doinício da sua implementação, durante a f...
41                        REFERÊNCIAS BIBLIOGRÁFICAS[AUD07]      Audy, J.; Prikladnicki, R., “Desenvolvimento Distribuído ...
42[GUP09-II]   Amar Gupta, Elisa Mattarelli, Satwik Seshasai, Joseph Broschak, Use of             collaborative technologi...
43[OSH07]      Oshri I., Kotlarsky J. and Willcocks L.P., “Global Software Development:             Exploring Socializatio...
44[YAP05]   Yap, M.; , "Follow the sun: distributed extreme programming          development," Agile Conference, 2005. Pro...
Upcoming SlideShare
Loading in …5
×

DESENVOLVIMENTO FOLLOW-THE-SUN EM AMBIENTE DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE

888 views
843 views

Published on

DESENVOLVIMENTO FOLLOW-THE-SUN EM AMBIENTE DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
888
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

DESENVOLVIMENTO FOLLOW-THE-SUN EM AMBIENTE DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE

  1. 1. 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 DESENVOLVIMENTO FOLLOW-THE-SUN EM AMBIENTE DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE ESTEVÃO RICARDO HESS Orientador: Prof. Dr. Jorge Luis Nicolas Audy Porto Alegre 2010
  2. 2. 2 Desenvolvimento Follow-the-sun em Ambiente de Desenvolvimento Distribuído de Software RESUMO Atualmente, o processo de globalização está se destacando, o que estágerando grande desafio para a área de engenharia de software, tornando odesenvolvimento cada vez mais distribuído e global. Em busca de vantagenscompetitivas, tais como redução de custo e ganho de produtividade, asorganizações optam por distribuir o processo de desenvolvimento de software empaíses com custo de produção mais acessível. Cada vez mais projetos estãosendo desenvolvidos em ambientes geograficamente distribuídos, caracterizandoo desenvolvimento distribuído de software. Entretanto, os desafios inerentes aeste ambiente de desenvolvimento de software são significativos. Dentre estesdesafios está a diferença de fuso horário, o qual pode ser também encarado comouma vantagem, através do uso do desenvolvimento follow-the-sun. Este trabalhoapresenta uma revisão da literatura desta temática e constata a escassez detrabalhos nesta área. Apresenta ainda, estudos que concluem que o ganho obtidocom o desenvolvimento follow-the-sun ainda está muito aquém do esperado,devido as dificuldades impostas por esta forma de desenvolvimento. Portanto,torna-se cada vez mais importante encontrar maneiras de atenuar estasdificuldades. Neste sentido, este trabalho mostra a importância em definir umprocesso formal para a transferência diária de tarefas durante a fase dedesenvolvimento de um projeto de software. Palavras Chave: Desenvolvimento distribuído de software,Desenvolvimento global software, Engenharia de software, Follow-the-sun, Roundthe clock, Time to market.
  3. 3. 3 Desenvolvimento Follow-the-sun em Ambiente de Desenvolvimento Distribuído de Software ABSTRACT Nowadays, the globalization process is emerging, what is generating hugechallenges to the software engineering area, making the software developmentmore distributed and global. Looking for the competitive advantages as low coastand productivity gains, organizations choose to distribute their softwaredevelopment process to other countries with production costs more affordable.Increasingly, projects are being developed in geographically distributedenvironments, featuring the distributed software development. However, thechallenges inherent in this software development environment are significant.Among these challenges is the time zone difference, which can also be tackled asan advantage, through the use of the follow-the-sun development. This paperpresents a literature review in this subject and concludes the scarcity of studies inthis area. Also presents studies that conclude that the gain that the follow-the-sundevelopment can provide are still worse than expected, due to difficulties imposedby follow-the-sun. Therefore, it becomes increasingly important to find ways toalleviate these difficulties. In this direction, this paper shows the importance todefine a formal process to alleviate the daily hand-offs during the developmentphase in a software project Keywords: Distributed software development, Global softwaredevelopment, Software engineer, Follow-the-sun, Round the clock, Time tomarket.
  4. 4. 4 LISTA DE TABELASTabela 1. Comparação entre as definições apresentadas ................................... 19Tabela 2. Comparação entre os experimentos apresentados .............................. 37
  5. 5. 5 LISTA DE FIGURASFigura 1. Modelo cascata, adaptado de [SOM07] ................................................ 22Figura 2. Distribuição típica da duração das fases de um projeto, adaptado de[CAR09] ................................................................................................................ 25Figura 3. Utilização do FTS durante a fase de testes ........................................... 26Figura 4. Utilização do FTS durante a fase de testes com trabalho simultâneo .. 26Figura 5. Modelo de Prototipação ........................................................................ 28Figura 6. Modelo Incremental, adaptado de [PRE10] ........................................... 29Figura 7. Disposição inicial das equipes, adaptado de [SET07] .......................... 30Figura 8. Duração do experimento, adaptado de [CAR09] ................................... 33Figura 9. Fluxo principal do processo................................................................... 40
  6. 6. 6 LISTA DE ABREVIATURAS E SIGLASAS Arquitetura de SoftwareDDS Desenvolvimento Distribuído de SoftwareES Engenharia de SoftwareFTS Follow-the-sunGSD Global Software DevelopmentVPN Virtual Private Network
  7. 7. 7 SUMÁRIO1 INTRODUÇÃO ............................................................................................... 82 CONTEXTUALIZAÇÃO................................................................................ 10 2.1 Desenvolvimento Distribuído de Software ............................................. 10 2.2 Desenvolvimento Follow-the-sun ........................................................... 143 CONCEITOS ................................................................................................ 164 CICLOS DE VIDA NO PROCESSO DE DESENVOLVIMENTO FOLLOW-THE-SUN ............................................................................................................. 21 4.1 Modelo Cascata ..................................................................................... 21 4.1.1 Follow-the-Sun no Modelo Cascata ................................................ 23 4.2 Modelo de Prototipação ......................................................................... 27 4.2.1 Follow-the-Sun no Modelo de Prototipação .................................... 28 4.3 Modelo Incremental ............................................................................... 29 4.3.1 Follow-the-Sun no Modelo Incremental .......................................... 295 ESTUDOS EM FOLLOW-THE-SUN ............................................................ 30 5.1 Estudo apresentado por Setamanit, Wakeland e Raffo (2007).............. 30 5.2 Estudo apresentado por Carmel, Dubinsky e Espinosa (2009) ............. 32 5.3 Estudo apresentado por Solingen e Valkema (2010) ............................ 34 5.4 Análise comparativa .............................................................................. 366 CONSIDERAÇÕES FINAIS ......................................................................... 39REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................... 41
  8. 8. 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). Hoje em dia, mais projetos estão sendodesenvolvidos em ambientes geograficamente distribuídos, caracterizando oDesenvolvimento Distribuído de Software (DDS). O DDS é caracterizado sempreque um ou mais recursos envolvidos no projeto estiver fisicamente distante dosdemais [AUD07]. Pode-se dizer também que uma equipe global dedesenvolvimento de software está tipicamente em países diferentes, porémcolaborando em um mesmo projeto de qualquer natureza (criação ou manutençãode software) [LAN08]. Durante a implementação do DDS, diversos desafios de gerenciamentoemergem. Dentre estes desafios, diversos autores mostram que a diferença defuso horário pode ser um fator de extrema relevância [HOL06, HER01, TRE06].Porém, a diferença de fuso horário pode ser utilizada ainda como vantagem e nãoapenas como uma desvantagem [CAR09, HOL06, LIN07, SET07, SOL10,KNO07, TRE06]. Neste sentido, surge o conceito conhecido comodesenvolvimento follow-the-sun (a partir deste ponto, referenciado como FTS),também conhecido como desenvolvimento round-the-clock, no qual o projeto édesenvolvido 24 horas por dia, utilizando times alocados em diferenteslocalidades, com diferentes fusos horários, utilizando esta diferença como umavantagem para o projeto [KNO07, TRE06]. Dentro desta área de estudo, este trabalho será desenvolvido com oobjetivo de desenvolver um processo formal para a transferência diária de tarefasem um ambiente FTS, durante a fase de implementação de um projeto desoftware. Portanto, esta pesquisa torna-se relevante, pois a criação de um processopara a transferência de trabalho pode facilitar o uso desta estratégia nos projetosde software. Além disto, para a teoria da área, esta pesquisa torna-se importante,
  9. 9. 9pois a literatura não apresenta a definição de um processo para a transferência detrabalho em projetos que utilizam esta estratégia. Sintetizando, a questão de pesquisa que norteia este estudo é: comotransferir trabalho durante a fase de desenvolvimento do ciclo de vida de umsoftware em um ambiente de DDS, utilizando estratégia FTS?Para alcançar osobjetivos citados, este trabalho estará estruturado da seguinte forma: a seção doisdestinada a apresentar uma Contextualização envolvendo o desenvolvimentodistribuído de software e o desenvolvimento follow-the-sun; a seção três abordaos Conceitos encontrados na literatura relacionados ao desenvolvimento follow-the-sun; a seção quatro apresenta o Ciclo de Vida no Processo deDesenvolvimento Follow-the-sun, focando em uma breve descrição de modelosde ciclos de vida e, para cada modelo, serão abordadas diferentes formas deutilizar o desenvolvimento FTS; a seção cinco aborda os Estudos encontrados naliteratura sobre a área de pesquisa; e, finalmente, na seção seis será exposto asConsiderações Finais, onde será realizada uma análise crítica da pesquisa emdesenvolvimento.
  10. 10. 102 CONTEXTUALIZAÇÃO O Desenvolvimento Distribuído de Software (DDS) está tornando-se umatendência na indústria de software [DAM06, HER01], pois apresenta diversosfatores motivadores que levam as empresas a utilizar cada vez mais este conceitoem seus negócios. Porém, o DDS adiciona inúmeros desafios ao processo dedesenvolvimento de software. Dentre estes desafios, podemos citar a diferençade fuso horário entre as equipes distribuídas. Entretanto, o fuso horário pode serencarado como uma vantagem para o projeto. Esta diferença de fuso horáriopode ser utilizada para realizar o uso do desenvolvimento FTS [HOL06, LIN07].Sendo assim, neste capítulo apresentam-se os desafios existentes nodesenvolvimento distribuído de software (DDS), e como surge a utilização dodesenvolvimento FTS neste contexto. Na seção 2.1 é apresentado odesenvolvimento distribuído de software (DDS), juntamente com suas vantagense os seus desafios. Na seção 2.2 será mostrado como surge o desenvolvimentoFTS em ambiente de DDS.2.1 Desenvolvimento Distribuído de Software Para contextualização do desenvolvimento distribuído de software, nestaseção apresentam-se alguns resultados obtidos na revisão da literatura abordadano trabalho de Introdução à Pesquisa I. Serão apresentados os fatores quemotivam a utilização do DDS e os desafios encontrados nesta área. O DDS não é um conceito novo. O DDS surgiu nos anos 90, quando asempresas começaram a desenvolver software com times distribuídos [LAN08]. O
  11. 11. 11DDS é caracterizado sempre que um ou mais recursos envolvidos no projetoestiverem fisicamente distantes dos demais [AUD07]. Quando a distância físicaentre os integrantes dos times de um projeto abrange mais de um país,caracteriza-se o Desenvolvimento Global de Software (GSD, do inglês GlobalSoftware Development) [LAN08]. A utilização do DDS pelas empresas está cada vez mais comum. Isto deve-se ao fato das diversas vantagens que a utilização deste conceito pode trazer. Aseguir são apresentados alguns destes fatores motivadores. Optou-se porapresentar apenas uma breve descrição das vantagens mais citadas pordiferentes autores, pois o detalhamento das mesmas foi abordado no trabalho deIntrodução à Pesquisa I. - 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]; - 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 [CAR09], incluir um produto no mercado antes do concorrentepode ser vital para o sucesso do mesmo. Sendo assim, com mais recursostrabalhando nos projetos, o tempo de desenvolvimento pode ser reduzido. - 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 alguns desafios,
  12. 12. 12como 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 deser gerenciado. Segundo alguns autores, os desafios encontrados no DDS podemser divididos em algumas categorias [AUD07, PRI09, KNO07, PIL06], as quaisafetam determinadas áreas do processo. Optou-se por apenas listar os desafios,pois os mesmos estão detalhadamente descritos no trabalho de Introdução àPesquisa I. Os desafios 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:legislação [KAR98] e gerenciamento de portfólio de projeto [PRI09, PIL06]: Desafios relacionados a Projetos [PRI07, HER01], também chamadoscomo dificuldades técnicas [PIL06, KNO07], contemplam dificuldadesrelacionadas 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 destes desafios são: arquitetura de software [AUD07,PRI09, HER99, BOS10], processos de desenvolvimento [AUD07, PRI09]:telecomunicações [AUD07], gerência de configuração [MAR09] e gerenciamentode projetos [PRI09]. Desafios 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:confiança [OSH07, AUD07, PRI09], conflitos [AUD07, PRI09], diferenças culturais[BIN07] e diferenças de fusos horários: Em função do aprofundamento do estudo realizado a partir do trabalho deIntrodução à Pesquisa I, os próximos parágrafos mostram detalhadamente comoa diferença de fuso horário pode afetar projetos de software. Estas diferençaspodem afetar os projetos de DDS de diferentes formas, dependendo do tamanhoda diferença de horário entre os centros distribuídos. Este fator está diretamente
  13. 13. 13ligado ao desenvolvimento FTS. A seguir, são mostrados exemplos de como estadiferença afeta os projetos. Quando existem equipes separadas por uma pequena diferença de horário,onde podem passar a maior parte do dia trabalhando ao mesmo tempo. Comoexemplo, podemos citar uma equipe localizada na cidade de Dallas, e outra noRio de Janeiro. Para este caso a diferença de fuso horário seria de apenas duashoras na maior parte do ano. Neste modo a comunicação é facilitada, pois épossível usar a comunicação síncrona, como ferramentas de mensagensinstantâneas, ligações telefônicas, vídeo conferências, entre outras. Quando a diferença de horário atinge em torno de cinco horas, apossibilidade 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çãoassíncrona aumenta. Para este exemplo, poderíamos citar uma equipe localizadaem Nova Iorque e outra em Londres. Para este caso a diferença seria de cincohoras na maior parte do ano. Finalmente, temos o caso em que as equipes distribuídas nunca trabalhamno mesmo horário. Neste caso, quando uma equipe está terminando o seu dia detrabalho a outra está começando. 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 podedemorar no mínimo um dia. Para este exemplo, poderíamos citar uma equipelocalizada em São Paulo e outra em Tóquio, onde a diferença será de doze horasna maior parte do ano. Nota-se que os problemas relacionados ao fuso horário tendem a ficar maisevidentes na medida em que a diferença aumenta. Para que esta diferença possaser utilizada como uma vantagem, alguns autores defendem a utilização dodesenvolvimento FTS. Porém, atualmente este conceito é pouco explorado naindústria [HOL06, LIN07, TRE06].
  14. 14. 142.2 Desenvolvimento Follow-the-sun Devido aos desafios impostos pelo desenvolvimento distribuído de softwarerelacionadas à diferenças de fusos horários, surge o conceito chamado dedesenvolvimento follow-the-sun (FTS). O desenvolvimento FTS é um subconjuntodo desenvolvimento global de software, o qual está, principalmente, focado nadiminuição do tempo de desenvolvimento de um projeto [CAR09, GOR96-II,GUP09-II]. Utilizando a diferença de fuso horário das equipes distribuídas, comouma vantagem [CAR09, HOL06, LIN07, SET07, SOL10, KNO07, TRE06], parafazer o desenvolvimento do projeto durante as 24 horas do dia. Porém, devido aofato de ser uma área nova de estudo na engenharia de software, pouco sobreesta temática foi publicado [TRE06]. Casos de sucesso na indústria utilizando oFTS ainda são escassos [SOL10]. [CAR09] afirma que não há casos de sucessona indústria [CAR09]. Esta forma de trabalho, em outros ramos da indústria não é uma novidade.Dependendo do tipo de produto a ser criado, existe a necessidade de trabalharem um único local, e dependendo da velocidade necessária para criá-los, duranteas 24 horas do dia, implicando em trabalhos fora do horário convencional. Umexemplo é a indústria automobilística, onde uma equipe termina o seu turno, e apróxima assume logo após, para iniciar a sua jornada, mantendo a produção 24horas por dia, porém, no mesmo local [GOR96-II]. Este fato poderia afetar aqualidade do produto, pois pessoas ao redor do mundo estão acostumadas atrabalhar durante o dia, e descansar durante a noite [CAR09, JAL04]. Na indústria do desenvolvimento de software, a primeira tentativadocumentada do uso do desenvolvimento FTS foi protagonizada pela IBM[CAR99]. Em 1997 [SOO08], a IBM decidiu desenvolver um projeto utilizando odesenvolvimento FTS [CAR09]. Para isto, criou cinco equipes distribuídas emcinco centros de desenvolvimento distintos em cinco países diferentes [SOO08].Durante o projeto, muitas dificuldades de coordenação foram encontradas,principalmente durante as transferências diárias de trabalho [SET07]. Portanto,como o FTS não estava funcionando como planejado, não trazendo o ganhoesperado pelos gestores, os responsáveis pelo projeto desistiram de utilizar o
  15. 15. 15FTS para acelerar o processo de desenvolvimento, mantendo apenas odesenvolvimento global de software [CAR09]. Para melhor entender do desenvolvimento FTS, nos próximos capítuloseste tema será abordado em maior profundidade. Para isto, no capítulo 3 serámostrado os conceitos encontrados na literatura, no capítulo 4 será exposta umabreve descrição sobre o ciclo de vida do software e, posteriormente, éapresentado formas de utilizar o desenvolvimento FTS durante o processo dedesenvolvimento de software, com o objetivo de aumentar as suas chances desucesso.
  16. 16. 163 CONCEITOS Devido ao fato do FTS ser um assunto recente na literatura e na indústriado desenvolvimento de software, existem poucos trabalhos publicados nesta área[TRE06]. Neste sentido, é possível observar a existência de diversas formas dedefinir o desenvolvimento FTS, também referenciado como desenvolvimento 24-horas [GUP09, GOR96-II], desenvolvimento round-the-clock [CAR09],desenvolvimento around-the-clock [YAP05] e software shift work [GOR96-II].Diversos autores possuem suas próprias definições para este tema, sendo assim,na literatura desta área não há um consenso na forma de definir odesenvolvimento FTS. Os próximos parágrafos apresentaram definições dediferentes autores e, ao final desta seção, é apresentada uma reflexão sobreestas definições, com o objetivo de oferecer uma definição onde sintetizaremos asprincipais idéias encontradas na literatura. Segundo Visser [VIS09], o desenvolvimento follow-the-sun pode serdeterminado ao ter equipes de desenvolvimento de software distribuídas pormúltiplos fusos horários, onde ao final do dia de trabalho, uma equipe deveentregar as informações relevantes do trabalho realizado até o momento,juntamente com o código fonte do produto, para a próxima equipe, a qual estáiniciando a sua jornada. O trabalho deve ser continuado do ponto onde o timeanterior parou. Desta forma, o projeto estará sendo desenvolvido vinte e quatrohoras por dia e não apenas durante oito horas, como normalmente acontece. Outra forma de identificar esta maneira de desenvolver software éapresentada por Gorton e Motwani [GOR96-II], onde é proposta uma novadenominação: software shift work. Os autores mostram que a indústria tem anecessidade de criar seus produtos em um tempo cada vez menor, porém,dependendo do tipo de produto a ser criado, existe a necessidade de trabalhar emum único local, porém durante as 24 horas do dia (implicando em trabalhos forado horário convencional), como exemplo, o autor cita a indústria automobilística.Porém, a criação de software difere radicalmente, pois o produto final é umacoleção de arquivos binários, documentação, código-fonte e executáveis, ondeutilizando redes modernas e rápidas de comunicação de dados como as que
  17. 17. 17existem atualmente na grande parte dos países onde o desenvolvimento global desoftware é utilizado, estes artefatos podem rapidamente ser transferidos paraqualquer lugar do mundo. Portando o desenvolvimento 24-horas de software podeser alcançado apenas utilizando a diferença de fuso horário entre os locais ondeos times estão alocados. Cada time trabalha no seu horário convencional e, aofinal do seu turno (um dia de trabalho), o próximo time, o qual está iniciando o seuturno assume o trabalho de onde a equipe anterior parou. Já para Gupta, Mattarelli, Seshasai e Broschak [GUP09-II] odesenvolvimento follow-the-sun pode ser estendido para diferentes tarefas, alémdo desenvolvimento. Os autores mostram o conceito de fábrica de conhecimento,onde as tarefas a serem desenvolvidas em um projeto podem ser voltadas aoconhecimento, o qual é passado entre os times globalmente distribuídos ao finalde cada dia. Para exemplificar este conceito para o desenvolvimento contínuodurante 24 horas por dia, é apresentado o ciclo de testes de um software, onde oconhecimento é o próprio software em desenvolvimento, e o conhecimento estáonde o software atende os requisitos de forma satisfatória ou não. Esteconhecimento é passado entre os times de desenvolvimento e de testes, os quaisestão distribuídos em locais distintos. Desta forma, a fase de testes pode serfinalizada de forma mais rápida, o que segundo os autores, é um dos principaisbenefícios ao distribuir equipes de desenvolvimento em fusos horários distintos eutilizar o desenvolvimento follow-the-sun. Treinen e Miller-Frost [TRE06] definem o follow-the-sun, de uma formamais sucinta. Para estes autores, a diferença de fuso horário deve ser vista comouma vantagem, para assim, distribuir equipes com o objetivo de criar um ambientede desenvolvimento de software onde as equipes trabalham apenas durante assuas horas normais de trabalho, e ao final do dia, apenas redistribuem as suastarefas ao time que está iniciando a sua jornada, criando assim, efetivamente odesenvolvimento 24-horas. Carmel, Dubinsky e Espinosa [CAR09], propõem uma definição para ofollow-the-sun aonde quatro idéias básicas devem ser seguidas: i. Equipes de desenvolvimento devem estar localizadas a diversos fusos- horários de diferença;
  18. 18. 18 ii. Um dos principais objetivos é reduzir o tempo de desenvolvimento/ time-to-market; iii. A cada momento existe somente uma equipe que possui a posse do produto; iv. A transferência de tarefas deve ser realizada diariamente, onde esta é definida por um check-in de uma unidade de trabalho da qual a próxima equipe depende para continuar o trabalho. Após apresentar estas quatro idéias básicas, o trabalho de [CAR09]apresenta a seguinte definição para o desenvolvimento follow-the-sun: um tipo defluxo de trabalho de conhecimento global, criado com o objetivo de reduzir aduração de um projeto, onde o produto é de propriedade de um centro dedesenvolvimento até ser entregue ao próximo. Esta entrega deve ser diária, e apróxima equipe deve estar localizada diversos fusos horários a frente para darcontinuidade ao trabalho. Após a apresentação das diferentes definições por diferentes autores, aTabela 1 mostra uma análise comparativa entre estas diferentes abordagens.Para cada critério (colunas), procurou-se saber se a definição apresentada, dealguma forma, indicou importância para este fator. Os fatores utilizados para a análise comparativa apresentada na Tabela 1surgiram de uma avaliação prévia dos conceitos apresentados pelos autores.Procurou-se identificar os principais fatores de cada conceito encontrado naliteratura, os quais poderiam ser comparados entre as definições.
  19. 19. 19 Tabela 1. Comparação entre as definições apresentadas Objetivo principal Transferências Considera relevante do FTS diárias de tarefas Diminuir time to market diário desenvolvimento de desenvolvimento do Diversos fusos horários Trabalhar somente nos horários convencionais Aumentar velocidade (apenas codificação) Aumentar tempo de Múltiplas tarefas Código fonte de diferença Autor projeto Visser [VIS09] X X X X Gorton e Motwani X X X X X [GOR96-II] Gupta, Mattarelli, Seshasai e Broschak X X X [GUP09-II] Treinen e Miller-Frost X X X [TRE06] Carmel, Dubinsky e X X X X Espinosa [CAR09] Como podemos perceber, não há uma convergência para apenas umadefinição para o desenvolvimento FTS. Podemos identificar que apenas um autordefine o FTS somente para a codificação, enquanto que os autores restantesdefendem a utilização para qualquer tarefa dentro do projeto. Outra característicanas definições está relacionada ao objetivo principal da utilização do FTS. Apesarde expresso de maneira distinta pelos autores, podemos perceber que o objetivoprincipal do FTS é a diminuição do tempo necessário para desenvolver umprojeto. A diferença mínima necessária de fusos horários entre as equipesdistribuídas foi pouco citada. Também existem poucos trabalhos que consideramrelevante a importância de ter equipes distintas trabalhando no seu horáriohabitual, evitando horas extras durante a noite. Este fator poderia ser maisconsiderado, pois a maior parte das pessoas ao redor do mundo está acostumadaa trabalhar durante o dia e descansar durante a noite [CAR09]. Portanto, após esta análise comparativa das diferentes definiçõessugeridas pelos autores, foram identificados pontos importantes em todas elas.Assim, através destas informações coletadas, propomos uma definição para odesenvolvimento FTS, a qual sintetiza as principais idéias e pode ser descrita daseguinte forma:
  20. 20. 20 O follow-the-sun é tipo de desenvolvimento global de software onde oprincipal objetivo é a diminuição do time-to-market, acelerando a construção doproduto final desde a concepção até a sua distribuição. Este ambiente opera comequipes distribuídas em fusos horários e países distintos, onde cada equipedetém o trabalho por determinado período, até que o mesmo seja transmitido paraa próxima equipe que inicia a sua jornada. A transferência pode ser para qualquertipo de tarefa relacionada com o desenvolvimento do projeto de software. Estatransferência deve acontecer diariamente e de forma padronizada.
  21. 21. 214 CICLOS DE VIDA NO PROCESSO DE DESENVOLVIMENTO FOLLOW-THE-SUN Para tornar o desenvolvimento de software uma atividade mais estruturadae padronizada, surgiram os modelos de processo de software [SOM07], tambémconhecidos como ciclos de vida de um software [MCC99, KRI08]. Afuncionalidade principal de um modelo de ciclo de vida de um software éestabelecer uma ordem na qual um projeto de software faz suas atividades comopor exemplo: especificação, implementação e testes [MCC99]. Estabelece ainda,critérios que devem ser usados para determinar o momento de seguir para apróxima fase do projeto [MCC99]. Atualmente existem diversos modelos de ciclosde vida, dentre estes, podemos citar como exemplo, o modelo cascata, modeloincremental e o modelo de prototipação. A importância da escolha de um processo adequado para a utilização dodesenvolvimento FTS é fator importante para o sucesso do projeto [CAR09].Atualmente, não existem processos largamente aceitos para esta forma dedesenvolver software. Diferentes autores defendem maneiras distintas para autilização do desenvolvimento FTS. Neste sentido, este capítulo apresenta umabreve descrição de alguns modelos de ciclos de vida e, para cada modelo, serãoabordadas diferentes formas de utilizar o desenvolvimento FTS.4.1 Modelo Cascata Este modelo, também chamado de ciclo de vida clássico [PRE10], propõeuma forma sistemática e seqüencial, onde inicia-se com os requisitos do sistema,terminando na entrega e manutenção do mesmo. Durante este processo, existemfases bem definidas, onde o final de cada fase marca o início da faseimediatamente seguinte. A Figura 1 ilustra este modelo.
  22. 22. 22 Figura 1. Modelo cascata, adaptado de [SOM07] Cada fase encontrada no modelo cascata pode ser resumidamentedefinida, segundo [SOM07], da seguinte forma: - Definição de requisitos: esta fase é marcada como o início do ciclo devida do software. Nesta fase do processo, são estabelecidas as funcionalidadesque o sistema deverá atender [SOM07]. - Projeto: esta fase caracteriza-se por traduzir os requisitos em umarepresentação de software [PRE95]. Consiste em projetar o que foi definido nafase anterior, do ponto de vista do sistema. Neste momento, é planejada aarquitetura do sistema, estruturas de dados, e detalhes procedurais a seremutilizados [SOM07]. - Implementação: utilizando as informações oriundas da fase de projeto,esta fase está focada na implementação de cada unidade do sistema, ou seja,transformar os requisitos em código fonte, e realizar testes unitários dos mesmos[SOM07]. - Integração e testes: com a implementação de cada unidade do sistemaconcluída, é realizada a integração e os testes de todo o sistema. Esta fasecaracteriza-se por identificar problemas no sistema, e resolvê-los. Ao final destafase, o sistema deve estar pronto para a sua utilização [SOM07]. - Manutenção: esta é a fase mais longa do ciclo de vida. O sistema éinstalado e utilizado pelo usuário final. Neste momento, deve ser realizado acorreção de problemas encontrados durante a utilização do sistema [SOM07].
  23. 23. 23 Este modelo de ciclo de vida é recomendado para projetos onde osrequisitos estão bem definidos e são geralmente fixos, ou seja, não mudam nodecorrer do projeto. Assim, o projeto pode ser desenvolvido de maneira linear doinício ao fim [PRE10].4.1.1 Follow-the-Sun no Modelo Cascata No modelo cascata, segundo trabalhos encontrados na literatura, odesenvolvimento FTS pode ser realizado em três fases distintas: implementação[CAR09], integração e testes [CAR09, GOR96, HOL06] e manutenção [LUC02,CON06, HEL06, JAL04]. Os itens 4.1.1.1, 4.1.1.2 e 4.1.1.3 descrevem comopoderia ser realizado o desenvolvimento FTS nestas três fases respectivamente.4.1.1.1 Implementação Muitas dificuldades diminuem a chance de sucesso da utilização do FTSdurante esta fase [SOL10, CAR09]. Porém, para obter êxito nesta fase doprocesso, [CAR09] apresenta práticas oriundas de metodologias ágeis parafacilitar e aumentar as chances de sucesso no uso do desenvolvimento FTS. Aabordagem ágil possui algumas características que apóiam a estruturação deprojetos para utilizar o desenvolvimento FTS [CAR09]. Estas característicasfacilitam áreas problemáticas apresentadas nesta forma de desenvolver software,como hand-off diário, comunicação e coordenação [CAR09, SET07, RAF07,CON06, HOL06, SOO08]. Para suportar a transferência diária de tarefas (hand-offs), fazer o uso deintegração continua através de um ambiente de integração automatizado [CAR09,YAP05], permite que cada time possa desenvolver suas tarefas no seu própriocódigo fonte e no seu horário habitual. Assim, cada time mantém um código fonte,estável, ou seja, testado e sem problemas, para ser utilizado pela próxima equipe.A política de manter os testes de integração funcionais, ou seja, não terminar odia com problemas em qualquer teste automatizado, bem como manter a
  24. 24. 24integração continua do produto são práticas comuns em metodologias ágeis, ecabem no desenvolvimento FTS, pois deste modo facilitam a transferência diáriasde tarefas. Para evitar problemas de comunicação, as metodologias ágeis enfatizam acomunicação face a face. O trabalho [CAR09] afirma que esta comunicação deveser mantida, porém para comunicação entre os membros de uma mesma equipeco-localizada. Entretanto, ao utilizar o FTS, o objetivo é reduzir a comunicaçãoentre centros distribuídos para o menor nível possível, confiando mais nasferramentas e processos utilizados para suportar os aspectos técnicos, gerenciaise sociais do desenvolvimento. Facilitando assim, a transferência de tarefas aofinal do dia, diminuindo os problemas de comunicação enfrentados por equipesque utilizam o FTS. A colaboração é vital no processo de desenvolvimento de software[CAR09]. A abordagem ágil enfatiza a colaboração entre todas as pessoasenvolvidas no desenvolvimento. Ao utilizar o desenvolvimento FTS a colaboraçãoestá relacionada a forma como os membros da equipe mantém as regras doprocesso de desenvolvimento. Desta forma, é importante manter protocolos quepermitam ao próximo centro continuar o trabalho entregue pelo centro anteriorsendo necessário o mínimo de comunicação síncrona entre centros distribuídos.Ou seja, manter claro o que cada equipe deve entregar a outra ao final do dia e,da mesma forma, o que esperar no início do dia. Ao utilizar o desenvolvimento FTS durante a fase de implementação de umsoftware é difícil, pois ao final de cada dia, tarefas inacabadas devem sertransferidas para o próximo time, o qual deve continuar o seu desenvolvimento.Sem fazer o uso de comunicação síncrona, a próxima equipe iniciando o seu diade trabalho deve continuar a tarefa deixada pela equipe anterior, o que torna otrabalho muito difícil. Porém, apesar de não haver na indústria exemplos desucesso [CAR09], seguindo estas práticas durante esta fase do projeto, pode-seobter sucesso na utilização do desenvolvimento FTS [CAR09].
  25. 25. 254.1.1.2 Integração e Testes O maior consenso encontrado na literatura relacionado a aplicação dodesenvolvimento FTS está na utilização desta forma de trabalho na fase do ciclode vida onde são realizados os testes e correções dos problemas encontrados[CAR09, GOR96, HOL06]. Esta forma de trabalho vem sendo aplicada naindústria com bastante sucesso [CAR09]. Utilizar o desenvolvimento FTS nestaabordagem pode, porém, diminuir o ganho teórico de 50% no tempo dedesenvolvimento do projeto (para projetos que utilizam dois centros dedesenvolvimento) [CAR09]. Conforme mostrado na Figura 2, percebemos que afase de testes, onde seria utilizado o FTS, compreende apenas 25% do tempototal do projeto [CAR09]. Neste caso, o ganho teórico de 50% seria somentedentro desta fase, resultando num ganho de apenas 12,5% no total do projeto[CAR09]. Figura 2. Distribuição típica da duração das fases de um projeto, adaptado de [CAR09] Uma equipe trabalha nos testes do sistema desenvolvido. Os problemasidentificados por esta equipe devem ser documentos em um sistema de controlecentralizado, do qual integrantes de todos os times distribuídos têm acesso. Aoterminar o dia de trabalho do time de teste, os problemas estão todosdocumentados [CAR09]. No momento em que o time de desenvolvimento inicia oseu trabalho, os defeitos encontrados e todas as informações relevantes aosmesmos estão acessíveis, sendo assim, possível iniciar a sua correção. A Figura3 ilustra a utilização do FTS durante a fase de integração e testes.
  26. 26. 26 Figura 3. Utilização do FTS durante a fase de testes É importante destacar que, para o funcionamento desta forma de utilizaçãodo desenvolvimento FTS, a transferência de tarefas ao final de cada dia deveseguir uma estrutura bem definida e entendida por todos os times envolvidos nodesenvolvimento. Os problemas encontrados devem ser documentados de formaclara e compreensível, com todas as informações necessárias, evitandoproblemas de entendimento na comunicação [CAR09]. Para equipes que, devidoa diferença de fuso horário, não trabalham em nenhum período simultaneamente,as soluções de dúvidas podem demorar mais de um dia, comprometendo oandamento do projeto. Portanto, a padronização das entregas de uma equipepara outra é fundamental. Uma pequena variação desta forma de utilizar o desenvolvimento FTS éapresentada por [GOR09]. Para evitar alguns problemas de coordenação ecomunicação, o trabalho [GOR09] propõe uma pequena modificação. Deve existirpelo menos 2 horas de trabalho simultâneo entre mais de uma equipe (a equipeque está terminando o seu dia, e a que está iniciando). Neste período de tempodevem ser discutidos os problemas de forma síncrona e qualquer dúvida quepossa surgir pode ser resolvida neste momento, evitando assim, atrasos noprojeto [GOR09]. A Figura 4 ilustra esta variação na utilização do FTS durante afase de integração e testes. Figura 4. Utilização do FTS durante a fase de testes com trabalho simultâneo
  27. 27. 274.1.1.3 Manutenção Alguns autores citam ainda a fase de manutenção como uma fase do ciclode vida propícia para utilizar o FTS [LUC02, CON06, HEL06, JAL04]. Para autilização do desenvolvimento FTS nesta fase deve-se manter times distribuídosao redor do mundo, garantindo que a diferença de fuso horário cubra 24 horas, ouseja, sempre haverá um time trabalhando [LUC02]. Portanto, sempre que algumproblema for identificado, um time de suporte poderá ser acionado e, assim,sempre haverá uma equipe disponível. Se for encontrado algum problema, aequipe que estiver disponível no momento recebe o problema e inicia o trabalho. Chegando ao final do seu dia de trabalho, e este problema ainda não foiresolvido, esta equipe repassa todo o conhecimento adquirido até o momentosobre o problema para a próxima equipe, que assume o mesmo, e a investigaçãocontinua do ponto onde parou. Utiliza-se o FTS desta forma para soluções críticascomo sistemas de controle de cartões de crédito e sistemas de telefonia [LUC02].4.2 Modelo de Prototipação A característica principal deste modelo é gerar protótipos do sistema,normalmente não funcionais, baseado nas definições propostas pelo cliente.Normalmente os requisitos de um sistema no início do processo dedesenvolvimento não estão bem definidos, e o modelo de prototipação pode serusado para ajudar a identificar e definir requisitos [PRE10]. Este modelo é umaforma iterativa, onde a primeira iteração inicia com os requisitos, logo após osprotótipos são criados, para então, serem validados pelo cliente [PRE10]. Apósesta avaliação, o cliente pode fornecer informações relevantes para que esteprotótipo seja modificado ou melhorado. Neste momento, uma nova iteração éiniciada. Este ciclo é repetido até o momento em que o protótipo gerado atinja onível de satisfação esperado pelo cliente [SOM07, PRE10]. A Figura 5 ilustra estemodelo.
  28. 28. 28 Figura 5. Modelo de Prototipação A vantagem da utilização deste modelo está na sua rapidez dedesenvolvimento, focando apenas no que será visível ao cliente, como interfacegráfica, formatos de entradas e saídas do sistema [SOM07, PRE10]. Nestemodelo, a parte funcional do sistema não é abordada.4.2.1 Follow-the-Sun no Modelo de Prototipação Prototipação é um modelo de ciclo de vida onde, segundo [CAR09],poderia, também, empregar o uso do desenvolvimento FTS. Para este modo deutilização do desenvolvimento FTS, a equipe responsável por criar os requisitos ea equipe que desenvolve os protótipos devem estar em localidades distintas.Desta forma, uma das equipes constrói os requisitos e, ao final do seu dia detrabalho, disponibiliza todas as informações necessárias para a próxima equipe, aqual irá desenvolver os protótipos. Ao terminar a sua jornada de trabalho, aequipe que desenvolveu os protótipos disponibiliza os mesmos para o time quefará a verificação destes, apontando problemas e melhorias a serem realizadas.Este processo é repetido desta forma até o momento em que o protótipo geradoatinja o nível de satisfação esperado pelo cliente [SOM07, PRE10]. Desta forma,obter ganho durante a prototipação também é possível, através do uso dodesenvolvimento FTS [CAR09].
  29. 29. 294.3 Modelo Incremental O modelo incremental utiliza elementos do modelo linear, tambémchamado de modelo cascata, porém com fluxos de processos paralelos [PRE10].O modelo incremental é realizado em ciclos, e dentro de cada ciclo, utiliza-se omodelo cascata. Cada um destes ciclos, também chamados de incrementos[PRE10], produz alguma funcionalidade nova ao sistema, e ao finalizar o últimociclo, obtém-se a versão final e funcional do produto. Os requisitos podem serpriorizados onde os mais prioritários são entregues nos primeiros incrementos, ouseja, funcionalidades mais críticas são entregues nos primeiros ciclos, deixandofuncionalidades adicionais para os próximos [SOM07, PRE10]. Ao iniciar umincremento, os requisitos são congelados, deixando novos requisitos para ciclosfuturos [SOM07]. Desta forma, o sistema é entregue em pequenas versões, aoinvés de uma única entrega ao final [SOM07]. A Figura 6 representa este modelo. Figura 6. Modelo Incremental, adaptado de [PRE10]4.3.1 Follow-the-Sun no Modelo Incremental Podemos notar que o modelo incremental, é constituído de ciclos domodelo cascata (incrementos) [PRES10]. Desta forma, o desenvolvimento FTSneste modelo de ciclo de vida, ocorre da mesma forma que no modelo cascata. Aprincipal diferença está no fato de utilizar o FTS a cada incremento, dentro dasfases citadas nos itens 4.1.1.1 (implementação), 4.1.1.2 (integração e testes) e4.1.1.3 (manutenção).
  30. 30. 305 ESTUDOS EM FOLLOW-THE-SUN A literatura apresenta poucos trabalhos relacionados ao desenvolvimentoFTS [TRE06]. Após uma extensa pesquisa, encontrou-se um número reduzido deartigos que realizam estudos teóricos nesta área. Esta seção apresenta umacompilação dos principais estudos relacionados à esta temática. Os estudosapresentados versam sobre diferentes óticas para avaliar o desenvolvimento FTS.5.1 Estudo apresentado por Setamanit, Wakeland e Raffo (2007) Apresentado por Setamanit, Wakeland e Raffo [SET07], o estudo mostra asvantagens ao utilizar o FTS em relação a um projeto realizado em um único local.O objetivo é identificar quando há uma vantagem ao utilizar o FTS, e quais são osrequisitos para alcançar uma vantagem que seja interessante para um projetodesenvolvido desta forma. O estudo inicia descrevendo forma como as equipes devem realizar odesenvolvimento do projeto. Para esta fase, duas equipes distintas foram criadas.Uma delas opera em apenas uma localidade, sem fazer o uso dodesenvolvimento FTS. A outra equipe é dividida em duas localidades com fusohorário distinto, e faz o uso do desenvolvimento FTS. A Figura 7 ilustra o formatodas equipes. Figura 7. Disposição inicial das equipes, adaptado de [SET07] Neste primeiro cenário, após realizar 30 testes para cada configuração (co-localizado e follow-the-sun), os autores identificaram que a utilização do
  31. 31. 31desenvolvimento FTS não gerou o ganho esperado. Os resultados mostraram umaumento de 50% no tempo necessário para o desenvolvimento do projeto, foinotado também um aumento de 70% no esforço, e a qualidade foi pior, pois aquantidade de defeitos foi maior que o dobro. Após adquirir estes dados iniciais sobre o desempenho das equipes, osautores buscaram identificar fatores que teriam um forte impacto para a melhoriadestas medidas. Estes fatores, segundo os autores, podem direcionar os projetospara a utilização de práticas onde os benefícios podem ser alcançados com maiorfacilidade. Após a identificação destes fatores, os autores mostram que osprincipais resultados foram: - Diminuir o esforço: aumentando o tempo de trabalho simultâneo (tambémconhecido como overlap) entre equipes distribuídas resulta em um menor esforçonecessário. Como na primeira configuração, as equipes não tinham apossibilidade de trabalhar ao mesmo tempo, a comunicação síncrona não existia.Ao introduzir a possibilidade deste tipo de comunicação, foi possível notar umaumento na produtividade. Entre outras vantagens, este tipo de comunicaçãomelhora a confiança entre os membros da equipe, resultando, assim nadiminuição do esforço. - Diminuir duração do projeto: aumentar o overlap entre as equipesdistribuídas pode aumentar a duração do projeto, pois o tempo dedesenvolvimento diário diminui. Porém, ao notar que, além de ter um períodomaior de trabalho simultâneo entre equipes distribuídas, outros fatores já citados(produtividade, confiança), ajudam a diminuir o esforço, resultando assim nummenor tempo de desenvolvimento. - Diminuição do número de defeitos: tendo um aumento na efetividade dacomunicação síncrona entre as equipes através do trabalho simultâneo,diminuíram os problemas de entendimento das comunicações assíncronas. Istoresultou em um número menor de defeitos encontrados. Após identificar os fatores que poderiam melhorar o desempenho doprojeto, realizou-se o experimento novamente, porém, desta vez com um overlapde horas de trabalho entre as equipes distribuídas. O resultado encontradoapresentou uma pequena melhora em relação a primeira execução, porém, o
  32. 32. 32desempenho do FTS ainda mostrou-se pior que o desenvolvimento em um únicolocal. Na tentativa de alcançar uma melhora significativa, os autores incluírammais um centro de desenvolvimento, obtendo assim, a distribuição em três locaisdistintos para o desenvolvimento. Neste modelo, o tempo de duração foi menor(11,1%). Entretanto o esforço foi significativamente maior (45,4%), porém,segundo os autores, este fator não se mostra relevante, devido ao fato de oscentros de desenvolvimento distribuídos normalmente estarem em países quepossuem baixo custo. A qualidade continuou pior neste modelo, devido adificuldade de comunicação e coordenação entre os 3 centros. Finalmente, os autores afirmam que o FTS pode ser uma boa estratégia sedentre as necessidades do projeto está a diminuição do tempo dedesenvolvimento. Porém, salientam que se esta decisão for tomada, deve-seutilizar a abordagem com no mínimo três centros distribuídos de forma a obter odesenvolvimento 24 horas por dia, e tendo um período de trabalho simultâneopara comunicação síncrona entre as equipes distribuídas.5.2 Estudo apresentado por Carmel, Dubinsky e Espinosa (2009) O recente estudo apresentado por Carmel, Dubisnky e Espinosa [CAR09]relata um quasi-experimento comparando duas formas distintas de desenvolverum projeto de software. O objetivo deste estudo foi medir o ganho no tempo dedesenvolvimento de um projeto de software, o qual, para este tipo de projeto,teoricamente deveria ser de 50%. O experimento controlado inicia com a escolha de duas equipes dedesenvolvimento de software, uma delas denominada controle (CO), compostapor 7 integrantes e a outra equipe, denominada de FTS, composta por 8participantes. As duas equipes deveriam implementar os mesmos requisitos desistema. Todos os participantes do estudo eram estudantes de Ciência daComputação ou Engenharia Elétrica de uma grande universidade. O tempo dedesenvolvimento por recurso era o mesmo para ambos os times. Definiu-se que o
  33. 33. 33tempo de desenvolvimento do projeto seria 5 semanas. Porém, como a equipeFTS faria o uso do desenvolvimento FTS, teoricamente, o tempo necessário parao projeto deveria de duas semanas e meia. A Figura 8 ilustra o tempo de projetodefinido para cada equipe. Figura 8. Duração do experimento, adaptado de [CAR09] Para a equipe CO, nenhuma restrição foi imposta, ou seja, o software foidesenvolvido da forma tradicional, com todos os recursos da equipe trabalhandono mesmo local. Para a equipe FTS, a primeira etapa foi dividir a equipe em duas,SubTeamA, composta por 3 recursos, e SubTeamB, integrada por 5 recursos.Cada uma destas duas equipes, oriundas do grupo FTS, deveria trabalhar emhorários diferentes, para simular a diferença de fuso horário: SubTeamA entre21:30 e 11:00 e SubTeamB entre 11:30 e 21:00, mantendo 30 minutos paraalguma hora extra, quando necessário. Para garantir que nenhuma comunicaçãosíncrona entre as equipes SubTeamA e SubTeamB ocorressem, mecanismoscomo mensagens SMS, comunicador instantâneo, e qualquer outro tipo decomunicação síncrona foi proibido. Para controlar os horários de trabalho, cadauma das duas equipes do FTS só poderia alterar códigos no repositório noshorários determinados. Este controle foi realizado de forma automática pelosistema de repositório de código utilizado no projeto. Ao final do estudo, os resultados apresentados pelos autores ficaram muitoaquém do esperado no início do estudo. Houve um ganho de apenas 10% notempo de duração do projeto, ao invés dos 50% que teoricamente deveria seralcançado. Analisando as estatísticas geradas pelo sistema de repositório decódigo utilizado, uma constatação foi importante para justificar a pouca reduçãodo tempo de desenvolvimento deste experimento. A equipe FTS realmente
  34. 34. 34terminou o projeto num tempo menor que a equipe CO, porém, devido a falta deuma diretriz sobre o momento de parar a codificação, mesmo tendo terminado acodificação das funcionalidades propostas, continuou-se apenas aprimorando-as.Foi possível identificar que na última semana do projeto a equipe FTS fez check-ins apenas sobre arquivos que já estavam no repositório, ou seja, atualizaramarquivos, melhorando funcionalidades prontas. Enquanto isso, a equipe COrealizava a criação das funcionalidades. Cabe lembrar, que segundo os autores,ambas as equipes concluíram a codificação dos requisitos de forma satisfatória.Os autores argumentam que apesar de terem identificado um ganho de apenas10%, este número poderia ser maior, se tivessem definido o momento paraterminar a fase de codificação para a equipe FTS. Este ponto foi identificadocomo uma limitação do estudo.5.3 Estudo apresentado por Solingen e Valkema (2010) No estudo apresentado por Solingen e Valkema [SOL10], os autoresapresentaram algumas hipóteses, e através de um experimento controlado,apontam a validade ou não das hipóteses propostas. O estudo foca nainvestigação do impacto do aumento do número de centros distribuídos navelocidade de desenvolvimento de projetos que utilizam o FTS. Procura-se saberqual o número ideal de equipes para se trabalhar em um projeto FTS. O experimento inicia definindo a configuração das equipes, as quais foramdefinidas da seguinte forma: cada execução do experimento seria realizadautilizando um número de centros de desenvolvimento diferente entre 2 e 4. Estescentros foram configurados da seguinte forma: sempre existe um centroresponsável por prover os requisitos e os feedbacks do trabalho realizado, então,na configuração com duas equipes, existirá uma equipe de desenvolvimento euma de requisitos, para três equipes, da mesma forma, haverá uma de requisitosenquanto as outras duas para o desenvolvimento e assim sucessivamente. Devido ao fato de ser um experimento controlado, as diferenças de fusoshorários foram todas simuladas, criando horários de trabalho pré definidos entreas diferentes equipes. Cada ciclo diário consiste de 2 a 4 dias trabalhados (um
  35. 35. 35para cada equipe distinta), dependendo do número de centros adotados. Os diasde trabalhos são contínuos, onde quando um dia termina (para um determinadocentro) outro está começando, simulando assim fusos horários distintos. Ao finalde um dia, o trabalho é repassado ao próximo time que está iniciando a suajornada. O experimento foi realizado com estudantes de Ciência da Computação. Acada dia, três execuções foram realizadas, utilizando 4, 3 e 2 centros dedesenvolvimentos. Ao final de cada execução, retirou-se uma equipealeatoriamente. Ao final de cada dia, a primeira equipe (responsável por requisitose feedbacks) relatava para o primeiro time de desenvolvimento as informaçõesnecessárias para iniciar o próximo ciclo. As tarefas a serem realizados eramextremamente simples, sendo possível assim, simular um dia de trabalho emapenas quatro minutos. Com esta configuração, segundo os autores, foi possívelanalisar o efeito do número de centros distribuídos em um projeto FTSrelacionado com o tempo de desenvolvimento. O estudo discute os resultados obtidos da seguinte forma: apresenta ahipótese, e a validade ou não da mesma. A seguir estão relacionadas ashipóteses propostas pelos autores, juntamente com o resultado obtido em relaçãoas mesmas. - Quantidade de trabalho entregue: Htotal: total4 > total3 > total2 Apresentados os dados coletados, foi possível identificar que a quantidadede trabalho entregue realmente aumenta a medida que a quantidade de centrosde desenvolvimento aumenta, concluindo assim, favoravelmente a esta hipótese. - Velocidade média de trabalho por centro: Havgspd: avgspd4 < avgspd3 < avgspd2 Os dados mostram que a adição de centros de desenvolvimento diminuema velocidade de trabalho por volta de 20% na média por centro dedesenvolvimento. Portanto, concluindo assim favoravelmente a está hipótese.
  36. 36. 36 - Exatidão do trabalho realizado: Haccur: accur4 < accur3 < accur2 Devido a pequena diferença encontrada nas três variações, nada pôde-seafirmar sobre está hipótese. - Percepção de velocidade: Hperspd: perspd4 < perspd3 < perspd2 Segundo os dados obtidos, houve apenas uma diminuição desta percepçãona configuração com 4 centros. Portanto, segundo os autores mostram, estahipótese não foi confirmada. - Percepção de exatidão do trabalho: Hperacc: peracc4 < peracc3 < peracc2 Mantendo 2 centros, a percepção de exatidão mostra-se normal, porém,quando esta configuração possuí mais de 2 centros distintos trabalhando, estapercepção caí drasticamente, e os participantes encontram mais dificuldade paramedir a exatidão do trabalho em desenvolvimento entre todos os centros,confirmando assim esta hipótese. Ao final do estudo, os autores discutem os resultados obtidos e mostramque apesar das dificuldades de coordenação e comunicação que odesenvolvimento FTS impõe, dependendo do que espera-se de um projeto desoftware, a sua utilização pode ser benéfica. A principal vantagem que o FTSpode alcançar, segundo os autores, está na diminuição do tempo de projeto, oque está em consonância com os outros estudos apresentados no capítulo 5.5.4 Análise comparativa Após a apresentação dos estudos analisados, a Tabela 2 mostra umaanálise comparativa entre diferentes trabalhos. Para cada critério (colunas),procurou-se saber se o experimento relacionado, de alguma forma indicouimportância para este fator.
  37. 37. 37 Os fatores utilizados para a análise comparativa apresentada na Tabela 2surgiram de uma avaliação prévia dos estudos apresentados. Procurou-seidentificar os principais fatores de cada estudo, os quais poderiam utilizados paracritério de comparação entre os estudos. Tabela 2. Comparação entre os experimentos apresentados Mede Atinge Sugere Vantagem do Diminuição Utilizar FTS número de mínimo de do tempo Esperado Número centros centros Ganho Ganho AlgumExperimentos ApresentadosSetamanit, Wakeland e X X X X X Raffo [SET07] Carmel, Dubisnky e X X X Espinosa [CAR09] Solingen e Valkema X X X X X [SOL10] A primeira constatação que podemos perceber em relação aos estudosapresentados está relacionada às métricas utilizadas. Percebe-se que todos osestudos medem a diminuição do tempo de projeto através do uso do FTS.[CAR09] e [SET07] identificam esta métrica de uma maneira semelhante,comparando um projeto executado de forma tradicional, co-localizada em umúnico centro, com um projeto executado deforma distribuída, utilizando o FTS.[CAR09] executa o experimento uma única vez, alcançando um resultado inferiorao esperado, enquanto [SET07], ao obter um resultado aquém do esperado,investiga os problemas enfrentados e refaz o experimento, para tentar melhorar oganho no tempo de projeto, alcançando um pequeno ganho. Já [SOL10] faz oexperimento utilizando diversas distribuições com 2, 3 e 4 equipes, buscandoavaliar se há uma melhora no ganho do tempo de projeto ao adicionar novostimes. A métrica relacionada ao número de centros necessários para obtervantagem na utilização do FTS foi utilizada por [SET07] e [SOL10]. Estes estudosfazem uma comparação do ganho no tempo de desenvolvimento adicionandomais de dois centros de desenvolvimento, obtendo resultados satisfatórios.
  38. 38. 38Conseqüentemente, estes trabalhos sugerem um número mínimo de centros dedesenvolvimento para aumentar as chances de sucesso na utilização dodesenvolvimento FTS. Para [SET07], a vantagem no tempo de desenvolvimentosó é atingida quando existem, pelo menos, três centros distribuídos. Enquantoque [SOL10] defende que o ganho aumenta conforme o número de centrosdistribuídos aumenta (este estudo utilizou distribuição entre dois e quatro centrospara chegar a esta conclusão). O resultado mais importante apresentado nos estudos avaliados estárelacionado ao ganho que o FTS pode prover. Percebemos que houve realmenteum ganho em relação ao tempo de desenvolvimento em todos os trabalhosapresentados. Porém, este ganho ficou muito aquém do ganho teórico esperadopelo desenvolvimento FTS. Segundo [CAR09], este ganho ficou em torno de 10%,já para [SET07], o ganho foi de 11,1%, porém, apenas quando um terceiro centrode desenvolvimento foi adicionado ao projeto, pois utilizando apenas dois, otempo para desenvolver o projeto, foi 50% maior. [SOL10] mostra apenas que aquantidade de trabalho entregue é maior se aumentarmos o número de centrosde desenvolvimentos distribuídos, obtendo melhor resultado com quatro centrosdistribuídos (número máximo utilizado). Portanto, segundo os resultados apresentados, o desenvolvimento FTSainda não produz o ganho teórico esperado, principalmente devido as dificuldadesimpostas, porém pode-se obter algum ganho no tempo de projeto. Percebe-seque todos os estudos indicam a utilização do desenvolvimento FTS. Porém,devido às dificuldades de coordenação e comunicação neste tipo de projeto,principalmente durante a transição de tarefas, a utilização desta forma dedesenvolvimento deve ser utilizada, segundo os estudos, apenas quando há anecessidade de desenvolver o produto em um tempo menor, ou seja, diminuir otime-to-market [SET07, SOL10, CAR09]. As conclusões destes estudos vão aoencontro com a literatura desta área, a qual afirma que a principal vantagem douso do desenvolvimento FTS está na diminuição do tempo de desenvolvimento deum projeto [CAR09, GUP09-II, GOR96-II, VIS09].
  39. 39. 396 CONSIDERAÇÕES FINAIS A utilização do DDS pelas organizações está cada vez mais comum. Istose deve ao fato das diversas vantagens que a utilização deste ambiente dedesenvolvimento pode trazer. Porém, o DDS apresenta alguns desafios, dentreestes, está a diferença de fuso horário entre centros de desenvolvimentodistribuídos. Alguns autores sugerem que esta diferença possa ser vista comouma vantagem, através do uso do desenvolvimento FTS [CAR09, HOL06, LIN07,SET07, SOL10, KNO07, TRE06]. Contudo, de acordo com os estudos apresentados [SET07, CAR09,SOL10], o desenvolvimento FTS pode resultar em um ganho no tempo dedesenvolvimento do projeto, ou seja, redução do time-to-market. Porém o ganhoapresentado ainda é muito inferior ao esperado. Portanto, devido aos desafiosque esta forma de desenvolver software pode apresentar, os estudos expostos nocapítulo 5 sugerem o uso do FTS apenas para projetos onde existe a necessidadeda redução do tempo de projeto. Ainda, a revisão da literatura mostrou que devidoao fato do desenvolvimento FTS ser uma área nova de estudo na engenharia desoftware, poucos estudos sobre esta temática foram publicados [TRE06]. Estudosempíricos que envolvem casos de sucesso na indústria utilizando esta forma dedesenvolver software ainda são raros [SOL10, CAR09]. Este fato está relacionadoas inúmeras dificuldades de coordenação e comunicação em projetos destanatureza [SET07, CAR09]. Estas adversidades surgem principalmente durante atransição de tarefas entre equipes distribuídas, os chamados hand-offs. Neste sentido, identifica-se a oportunidade de desenvolver um estudo queatue nas dificuldades relatadas. Portanto, esta pesquisa visa a definição de umprocesso para atuar na transição de tarefas entre equipes distribuídas,especificamente durante a fase de implementação. Para atingir este objetivo, as próximas etapas desta pesquisa estarãofocadas na identificação de técnicas e abordagens que possam ser utilizadas,como, por exemplo, metodologias ágeis, RUP, etc. Somente como exemplo,explorando preliminarmente o uso de técnicas, como Test-driven Development(TDD) e integração contínua, poderia ser criado um processo com a seguinte
  40. 40. 40idéia: para cada funcionalidade do projeto, definem-se testes unitários antes doinício da sua implementação, durante a fase de projeto. Estes artefatos seriamutilizados como um guia para as equipes distribuídas. Ao final de cada dia detrabalho, deve-se fazer o check-in do código desenvolvido, e um buildautomatizado é executado. Nesta etapa, todos os testes unitários são executadose, ao final, sabe-se quais os testes que estão cobertos pelo código atual. Destamaneira, seria possível identificar de forma clara e precisa em qual ponto dodesenvolvimento a equipe anterior terminou o seu dia de trabalho, e de onde otrabalho deve ser continuado. A Figura 9 apresenta a idéia principal do processo aser desenvolvido, iniciando desde o ponto em que os testes unitários são criados,até o momento em que a implementação da funcionalidade está concluída. Figura 9. Fluxo principal do processo
  41. 41. 41 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[CAR01] Carmel, E.; Agarwal, R.; , "Tactical approaches for alleviating distance in global software development," Software, IEEE , vol.18, no.2, pp.22-29, Mar/Apr 2001[CAR06] Carmel, E.; "Building your Information Systems from the Other Side of the World: How Infosys manages time differences" . Management Information Systems Quarterly - Executive , March, 2006.[CAR09] Carmel, E.;Espinosa, A.; Dubinsky, Y., "Follow The Sun Software Development : New Perspectives , Conceptual Foundation , and Exploratory Field Study," 42nd Hawaii International Conference on System Sciences, Proceedings , 2009[CAR10] "Follow the Sun" Workflow in Global Software Development Journal of Management Information Systems Vol. 27 No. 1 , Summer 2010 , pp. 17 - 38[CAR99] Carmel, E. Global Software Teams: collaborating across borders and time zones, 1999. publicado por Prentice Hall-PTR[CON06] Ó Conchúir, E., Ågerfalk, P.J., Fitzgerald, B and Holmström H. (forthcoming). Global Software Development. Never mind the Problems – Where are the Benefits? To appear in Communications of the ACM Special Issue on Distributed Development.[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.[GOR06] Gorton, I.; Hawryszkiewycz, I.; Fung, L.; , "Enabling software shift work with groupware: a case study," System Sciences, 1996., Proceedings of the Twenty-Ninth Hawaii International Conference on , , vol.3, no., pp.72- 81 vol.3, 3-6 Jan 1996[GOR96-II] Ian Gorton, Sanjeev Motwani, Issues in co-operative software engineering using globally distributed teams, Information and Software Technology, Volume 38, Issue 10, 1996, Pages 647-655[GUP09] Amar Gupta, Deriving mutual benefits from offshore outsourcing, Communications of the ACM, v.52 n.6, June 2009
  42. 42. 42[GUP09-II] Amar Gupta, Elisa Mattarelli, Satwik Seshasai, Joseph Broschak, Use of collaborative technologies and knowledge sharing in co-located and distributed teams: Towards the 24-h knowledge factory, The Journal of Strategic Information Systems, Volume 18, Issue 3, September 2009, Pages 147-161[HER01] Herbsleb, J.D.; Mockus, A.; Finholt, T.A.; Grinter, R.E.; , "An empirical study of global software development: distance and speed," Software Engineering, 2001. ICSE 2001. Proceedings of the 23rd International Conference on , vol., no., pp. 81- 90, 12-19 May 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] Helena Holmstrom; Eoin O Conchuir; Par J Agerfalk; Brian Fitzgerald; , "Global Software Development Challenges: A Case Study on Temporal, Geographical and Socio-Cultural Distance," Global Software Engineering, 2006. ICGSE 06. International Conference on , vol., no., pp.3-11, Oct. 2006[JAL04] Jalote, P.; Jain, G.; , "Assigning tasks in a 24-hour software development model," Software Engineering Conference, 2004. 11th Asia-Pacific , vol., no., pp. 309- 315, 30 Nov.-3 Dec. 2004[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.[KRI08] Krishnamurthy, N.; Saran, A. ; “Building Software: A Practitioners Guide (Applied Software Engineering Series)”. EUA: Auerbach Publications, 2008.[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.[LUC02] Di Lucca, G.A.; Di Penta, M.; Gradara, S.; , "An approach to classify software maintenance requests," Software Maintenance, 2002. Proceedings. International Conference on , vol., no., pp. 93- 102, 2002[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[MCC96] McConnell, S. “Rapid Development: Taming Wild Software Schedules ”. EUA: Microsoft Press, 1996.
  43. 43. 43[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[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.[PRE10] Pressman, Roger S. “Software Engineering: a practitioner’s approach (seventh edition)”. EUA: McGraw Hill, 2010. 888p[PRE95] Pressman, Roger S. “Engenharia de Software”. Brasil: Makron Books, 1995. 1027p[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.[SCH00] Schmidt, M. E.C. “Implementing the IEEE Software Engineering Standards”. EUA: Sams, 2000.[SET07] Setamanit, S.-o.; Wakeland, W.; Raffo, D.; , "Improving Global Software Development Project Performance Using Simulation," Management of Engineering and Technology, Portland International Center for , vol., no., pp.2458-2466, 5-9 Aug. 2007[SET07-II] Siri-on Setamanit , Wayne Wakeland , David Raffo, Using simulation to evaluate global software development task allocation strategies: Research Sections, Software Process: Improvement and Practice, v.12 n.5, p.491-503, September 2007[SOL10] van Solingen, Rini; Valkema, Menno; , "The Impact of Number of Sites in a Follow the Sun Setting on the Actual and Perceived Working Speed and Accuracy: A Controlled Experiment," Global Software Engineering (ICGSE), 2010 5th IEEE International Conference on , vol., no., pp.165- 174, 23-26 Aug. 2010[SOM07] SOMMERVILLE, Ian. “Software Engineering (eighth edition)”. Pearson Education Limited, 2007, 865p.[SOO08] P. Sooraj, Pratap K.J. Mohapatra, (2008) "Modeling the 24-h software development process", Strategic Outsourcing: An International Journal, Vol. 1 Iss: 2, pp.122 - 141[TRE06] Treinen, James J., Miller-Frost, Susan L. Following the Sun : Case Studies in Global Software Development. In : IBM Systems Journal, Volume 45, Number 4, October 2006.[VIS09] Visser, C; "Connecting Time Zones and Languages in Follow-the-Sun: a routing model", Dissertação de Mestrado - Delf University of Technology - Holanda
  44. 44. 44[YAP05] Yap, M.; , "Follow the sun: distributed extreme programming development," Agile Conference, 2005. Proceedings , vol., no., pp. 218- 224, 24-29 July 2005

×