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

1. PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL
FACULDADE DE INFORMÁTICA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DE COMPUTAÇÃO
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
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 o
desenvolvimento cada vez mais distribuído e global. Em busca de vantagens
competitivas, tais como redução de custo e ganho de produtividade, as
organizações optam por distribuir o processo de desenvolvimento de software em
países com custo de produção mais acessível. Cada vez mais projetos estão
sendo desenvolvidos em ambientes geograficamente distribuídos, caracterizando
o desenvolvimento distribuído de software. Entretanto, os desafios inerentes a
este ambiente de desenvolvimento de software são significativos. Dentre estes
desafios está a diferença de fuso horário, o qual pode ser também encarado como
uma vantagem, através do uso do desenvolvimento follow-the-sun. Este trabalho
apresenta uma revisão da literatura desta temática e constata a escassez de
trabalhos nesta área. Apresenta ainda, estudos que concluem que o ganho obtido
com 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 estas
dificuldades. Neste sentido, este trabalho mostra a importância em definir um
processo formal para a transferência diária de tarefas durante a fase de
desenvolvimento de um projeto de software.
Palavras Chave: Desenvolvimento distribuído de software,
Desenvolvimento global software, Engenharia de software, Follow-the-sun, Round
the clock, Time to market.

3. 3
Desenvolvimento Follow-the-sun em Ambiente de Desenvolvimento
Distribuído de Software
ABSTRACT
Nowadays, the globalization process is emerging, what is generating huge
challenges to the software engineering area, making the software development
more distributed and global. Looking for the competitive advantages as low coast
and productivity gains, organizations choose to distribute their software
development process to other countries with production costs more affordable.
Increasingly, projects are being developed in geographically distributed
environments, featuring the distributed software development. However, the
challenges inherent in this software development environment are significant.
Among these challenges is the time zone difference, which can also be tackled as
an advantage, through the use of the follow-the-sun development. This paper
presents a literature review in this subject and concludes the scarcity of studies in
this area. Also presents studies that conclude that the gain that the follow-the-sun
development can provide are still worse than expected, due to difficulties imposed
by follow-the-sun. Therefore, it becomes increasingly important to find ways to
alleviate these difficulties. In this direction, this paper shows the importance to
define a formal process to alleviate the daily hand-offs during the development
phase in a software project
Keywords: Distributed software development, Global software
development, Software engineer, Follow-the-sun, Round the clock, Time to
market.

4. 4
LISTA DE TABELAS
Tabela 1. Comparação entre as definições apresentadas ................................... 19
Tabela 2. Comparação entre os experimentos apresentados .............................. 37

5. 5
LISTA DE FIGURAS
Figura 1. Modelo cascata, adaptado de [SOM07] ................................................ 22
Figura 2. Distribuição típica da duração das fases de um projeto, adaptado de
[CAR09] ................................................................................................................ 25
Figura 3. Utilização do FTS durante a fase de testes ........................................... 26
Figura 4. Utilização do FTS durante a fase de testes com trabalho simultâneo .. 26
Figura 5. Modelo de Prototipação ........................................................................ 28
Figura 6. Modelo Incremental, adaptado de [PRE10] ........................................... 29
Figura 7. Disposição inicial das equipes, adaptado de [SET07] .......................... 30
Figura 8. Duração do experimento, adaptado de [CAR09] ................................... 33
Figura 9. Fluxo principal do processo................................................................... 40

6. 6
LISTA DE ABREVIATURAS E SIGLAS
AS Arquitetura de Software
DDS Desenvolvimento Distribuído de Software
ES Engenharia de Software
FTS Follow-the-sun
GSD Global Software Development
VPN Virtual Private Network

7. 7
SUMÁRIO
1 INTRODUÇÃO ............................................................................................... 8
2 CONTEXTUALIZAÇÃO................................................................................ 10
2.1 Desenvolvimento Distribuído de Software ............................................. 10
2.2 Desenvolvimento Follow-the-sun ........................................................... 14
3 CONCEITOS ................................................................................................ 16
4 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 .......................................... 29
5 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 .............................................................................. 36
6 CONSIDERAÇÕES FINAIS ......................................................................... 39
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................... 41

8. 8
1 INTRODUÇÃO
No ambiente em que estamos vivendo atualmente, o processo de
globalização está se destacando, o que está gerando grande desafio para a área
de Engenharia de Software (ES). Hoje em dia, mais projetos estão sendo
desenvolvidos em ambientes geograficamente distribuídos, caracterizando o
Desenvolvimento Distribuído de Software (DDS). O DDS é caracterizado sempre
que um ou mais recursos envolvidos no projeto estiver fisicamente distante dos
demais [AUD07]. Pode-se dizer também que uma equipe global de
desenvolvimento de software está tipicamente em países diferentes, porém
colaborando em um mesmo projeto de qualquer natureza (criação ou manutenção
de software) [LAN08].
Durante a implementação do DDS, diversos desafios de gerenciamento
emergem. Dentre estes desafios, diversos autores mostram que a diferença de
fuso 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ão
apenas como uma desvantagem [CAR09, HOL06, LIN07, SET07, SOL10,
KNO07, TRE06]. Neste sentido, surge o conceito conhecido como
desenvolvimento 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 diferentes
localidades, com diferentes fusos horários, utilizando esta diferença como uma
vantagem para o projeto [KNO07, TRE06].
Dentro desta área de estudo, este trabalho será desenvolvido com o
objetivo de desenvolver um processo formal para a transferência diária de tarefas
em um ambiente FTS, durante a fase de implementação de um projeto de
software.
Portanto, esta pesquisa torna-se relevante, pois a criação de um processo
para a transferência de trabalho pode facilitar o uso desta estratégia nos projetos
de software. Além disto, para a teoria da área, esta pesquisa torna-se importante,

9. 9
pois a literatura não apresenta a definição de um processo para a transferência de
trabalho em projetos que utilizam esta estratégia.
Sintetizando, a questão de pesquisa que norteia este estudo é: como
transferir trabalho durante a fase de desenvolvimento do ciclo de vida de um
software em um ambiente de DDS, utilizando estratégia FTS?Para alcançar os
objetivos citados, este trabalho estará estruturado da seguinte forma: a seção dois
destinada a apresentar uma Contextualização envolvendo o desenvolvimento
distribuído de software e o desenvolvimento follow-the-sun; a seção três aborda
os Conceitos encontrados na literatura relacionados ao desenvolvimento follow-
the-sun; a seção quatro apresenta o Ciclo de Vida no Processo de
Desenvolvimento Follow-the-sun, focando em uma breve descrição de modelos
de ciclos de vida e, para cada modelo, serão abordadas diferentes formas de
utilizar o desenvolvimento FTS; a seção cinco aborda os Estudos encontrados na
literatura sobre a área de pesquisa; e, finalmente, na seção seis será exposto as
Considerações Finais, onde será realizada uma análise crítica da pesquisa em
desenvolvimento.

10. 10
2 CONTEXTUALIZAÇÃO
O Desenvolvimento Distribuído de Software (DDS) está tornando-se uma
tendência na indústria de software [DAM06, HER01], pois apresenta diversos
fatores motivadores que levam as empresas a utilizar cada vez mais este conceito
em seus negócios. Porém, o DDS adiciona inúmeros desafios ao processo de
desenvolvimento de software. Dentre estes desafios, podemos citar a diferença
de fuso horário entre as equipes distribuídas. Entretanto, o fuso horário pode ser
encarado como uma vantagem para o projeto. Esta diferença de fuso horário
pode ser utilizada para realizar o uso do desenvolvimento FTS [HOL06, LIN07].
Sendo assim, neste capítulo apresentam-se os desafios existentes no
desenvolvimento distribuído de software (DDS), e como surge a utilização do
desenvolvimento FTS neste contexto. Na seção 2.1 é apresentado o
desenvolvimento distribuído de software (DDS), juntamente com suas vantagens
e os seus desafios. Na seção 2.2 será mostrado como surge o desenvolvimento
FTS em ambiente de DDS.
2.1 Desenvolvimento Distribuído de Software
Para contextualização do desenvolvimento distribuído de software, nesta
seção apresentam-se alguns resultados obtidos na revisão da literatura abordada
no trabalho de Introdução à Pesquisa I. Serão apresentados os fatores que
motivam 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 as
empresas começaram a desenvolver software com times distribuídos [LAN08]. O

11. 11
DDS é caracterizado sempre que um ou mais recursos envolvidos no projeto
estiverem fisicamente distantes dos demais [AUD07]. Quando a distância física
entre os integrantes dos times de um projeto abrange mais de um país,
caracteriza-se o Desenvolvimento Global de Software (GSD, do inglês Global
Software 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. A
seguir são apresentados alguns destes fatores motivadores. Optou-se por
apresentar apenas uma breve descrição das vantagens mais citadas por
diferentes autores, pois o detalhamento das mesmas foi abordado no trabalho de
Introduçã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 vez
menor. Desta maneira, contratam mão de obra de outro país ou localidade onde o
custo de produção seja mais baixo [KNO07];
- Ganho de proximidade com o cliente [LAN08]: como a demanda de
software cresce em diversos países [KNO07], uma empresa que esteja
expandindo seus negócios para uma nova região poderia iniciar uma operação de
DDS nesta localidade e, assim, estaria se aproximando dos seus clientes.
- Redução do tempo de projeto [LAN08, DAM06, PRI08]: também chamado
de time-to-market [CAR09], incluir um produto no mercado antes do concorrente
pode ser vital para o sucesso do mesmo. Sendo assim, com mais recursos
trabalhando nos projetos, o tempo de desenvolvimento pode ser reduzido.
- Recursos especializados [LAN08] e globais [DAM06, PRI08, AUD07,
MAR09]: com o DDS é possível obter a disponibilidade da mão de obra tão
especializada quanto em projetos tradicionais, porém com a vantagem de manter
o baixo custo.
Apesar de todas as vantagens que o DDS disponibiliza para as
organizações, o processo de desenvolvimento de software continua sendo uma
atividade complexa. Utilizando o DDS, adiciona-se ao processo alguns desafios,

12. 12
como a distância física, diferenças de fusos horários e diferenças culturais [PRI09,
AUD07, DAM06], os quais tornam este tipo de projeto extremamente complexo de
ser gerenciado. Segundo alguns autores, os desafios encontrados no DDS podem
ser divididos em algumas categorias [AUD07, PRI09, KNO07, PIL06], as quais
afetam 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 chamados
como dificuldades técnicas [PIL06, KNO07], contemplam dificuldades
relacionadas a forma como o projeto será desenvolvido, incluindo o uso de
ferramentas e métodos [PRI09]. Dizem respeito ainda as adversidades
relacionadas com a gerência de requisitos, integração, gerência de configuração,
dificuldades no acompanhamento do projeto e na utilização de ferramentas
[PIL06, KNO07]. Exemplos 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 gerenciamento
de projetos [PRI09].
Desafios relacionados a Pessoas [PRI09], também identificado como
problemas sociais [PIL06, KNO07] dizem respeito aos problemas que afetam
diretamente os recursos envolvidos no projeto [PRI09], alguns exemplos são:
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 de
Introdução à Pesquisa I, os próximos parágrafos mostram detalhadamente como
a diferença de fuso horário pode afetar projetos de software. Estas diferenças
podem afetar os projetos de DDS de diferentes formas, dependendo do tamanho
da diferença de horário entre os centros distribuídos. Este fator está diretamente

13. 13
ligado ao desenvolvimento FTS. A seguir, são mostrados exemplos de como esta
diferenç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. Como
exemplo, podemos citar uma equipe localizada na cidade de Dallas, e outra no
Rio de Janeiro. Para este caso a diferença de fuso horário seria de apenas duas
horas na maior parte do ano. Neste modo a comunicação é facilitada, pois é
possível usar a comunicação síncrona, como ferramentas de mensagens
instantâneas, ligações telefônicas, vídeo conferências, entre outras.
Quando a diferença de horário atinge em torno de cinco horas, a
possibilidade de trabalhar juntos na maior parte do tempo já não é mais válida.
Então, para este caso, a comunicação síncrona tende a diminuir e a comunicação
assíncrona aumenta. Para este exemplo, poderíamos citar uma equipe localizada
em Nova Iorque e outra em Londres. Para este caso a diferença seria de cinco
horas na maior parte do ano.
Finalmente, temos o caso em que as equipes distribuídas nunca trabalham
no mesmo horário. Neste caso, quando uma equipe está terminando o seu dia de
trabalho a outra está começando. Além da falta de comunicação síncrona, torna-
se vital que a comunicação assíncrona seja realizada de forma clara e efetiva.
Qualquer dependência de uma resposta de algum membro do outro time pode
demorar no mínimo um dia. Para este exemplo, poderíamos citar uma equipe
localizada em São Paulo e outra em Tóquio, onde a diferença será de doze horas
na maior parte do ano.
Nota-se que os problemas relacionados ao fuso horário tendem a ficar mais
evidentes na medida em que a diferença aumenta. Para que esta diferença possa
ser utilizada como uma vantagem, alguns autores defendem a utilização do
desenvolvimento FTS. Porém, atualmente este conceito é pouco explorado na
indústria [HOL06, LIN07, TRE06].

14. 14
2.2 Desenvolvimento Follow-the-sun
Devido aos desafios impostos pelo desenvolvimento distribuído de software
relacionadas à diferenças de fusos horários, surge o conceito chamado de
desenvolvimento follow-the-sun (FTS). O desenvolvimento FTS é um subconjunto
do desenvolvimento global de software, o qual está, principalmente, focado na
diminuiçã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, como
uma vantagem [CAR09, HOL06, LIN07, SET07, SOL10, KNO07, TRE06], para
fazer o desenvolvimento do projeto durante as 24 horas do dia. Porém, devido ao
fato de ser uma área nova de estudo na engenharia de software, pouco sobre
esta temática foi publicado [TRE06]. Casos de sucesso na indústria utilizando o
FTS ainda são escassos [SOL10]. [CAR09] afirma que não há casos de sucesso
na 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 trabalhar
em um único local, e dependendo da velocidade necessária para criá-los, durante
as 24 horas do dia, implicando em trabalhos fora do horário convencional. Um
exemplo é a indústria automobilística, onde uma equipe termina o seu turno, e a
próxima assume logo após, para iniciar a sua jornada, mantendo a produção 24
horas por dia, porém, no mesmo local [GOR96-II]. Este fato poderia afetar a
qualidade do produto, pois pessoas ao redor do mundo estão acostumadas a
trabalhar durante o dia, e descansar durante a noite [CAR09, JAL04].
Na indústria do desenvolvimento de software, a primeira tentativa
documentada do uso do desenvolvimento FTS foi protagonizada pela IBM
[CAR99]. Em 1997 [SOO08], a IBM decidiu desenvolver um projeto utilizando o
desenvolvimento FTS [CAR09]. Para isto, criou cinco equipes distribuídas em
cinco 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 ganho
esperado pelos gestores, os responsáveis pelo projeto desistiram de utilizar o

15. 15
FTS para acelerar o processo de desenvolvimento, mantendo apenas o
desenvolvimento global de software [CAR09].
Para melhor entender do desenvolvimento FTS, nos próximos capítulos
este 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 uma
breve descrição sobre o ciclo de vida do software e, posteriormente, é
apresentado formas de utilizar o desenvolvimento FTS durante o processo de
desenvolvimento de software, com o objetivo de aumentar as suas chances de
sucesso.

16. 16
3 CONCEITOS
Devido ao fato do FTS ser um assunto recente na literatura e na indústria
do desenvolvimento de software, existem poucos trabalhos publicados nesta área
[TRE06]. Neste sentido, é possível observar a existência de diversas formas de
definir 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 o
desenvolvimento FTS. Os próximos parágrafos apresentaram definições de
diferentes autores e, ao final desta seção, é apresentada uma reflexão sobre
estas definições, com o objetivo de oferecer uma definição onde sintetizaremos as
principais idéias encontradas na literatura.
Segundo Visser [VIS09], o desenvolvimento follow-the-sun pode ser
determinado ao ter equipes de desenvolvimento de software distribuídas por
múltiplos fusos horários, onde ao final do dia de trabalho, uma equipe deve
entregar 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 time
anterior parou. Desta forma, o projeto estará sendo desenvolvido vinte e quatro
horas 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 nova
denominação: software shift work. Os autores mostram que a indústria tem a
necessidade 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 em
um único local, porém durante as 24 horas do dia (implicando em trabalhos fora
do 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 é uma
coleção de arquivos binários, documentação, código-fonte e executáveis, onde
utilizando redes modernas e rápidas de comunicação de dados como as que

17. 17
existem atualmente na grande parte dos países onde o desenvolvimento global de
software é utilizado, estes artefatos podem rapidamente ser transferidos para
qualquer lugar do mundo. Portando o desenvolvimento 24-horas de software pode
ser alcançado apenas utilizando a diferença de fuso horário entre os locais onde
os times estão alocados. Cada time trabalha no seu horário convencional e, ao
final do seu turno (um dia de trabalho), o próximo time, o qual está iniciando o seu
turno assume o trabalho de onde a equipe anterior parou.
Já para Gupta, Mattarelli, Seshasai e Broschak [GUP09-II] o
desenvolvimento follow-the-sun pode ser estendido para diferentes tarefas, além
do desenvolvimento. Os autores mostram o conceito de fábrica de conhecimento,
onde as tarefas a serem desenvolvidas em um projeto podem ser voltadas ao
conhecimento, o qual é passado entre os times globalmente distribuídos ao final
de cada dia. Para exemplificar este conceito para o desenvolvimento contínuo
durante 24 horas por dia, é apresentado o ciclo de testes de um software, onde o
conhecimento é o próprio software em desenvolvimento, e o conhecimento está
onde o software atende os requisitos de forma satisfatória ou não. Este
conhecimento é passado entre os times de desenvolvimento e de testes, os quais
estão distribuídos em locais distintos. Desta forma, a fase de testes pode ser
finalizada de forma mais rápida, o que segundo os autores, é um dos principais
benefícios ao distribuir equipes de desenvolvimento em fusos horários distintos e
utilizar o desenvolvimento follow-the-sun.
Treinen e Miller-Frost [TRE06] definem o follow-the-sun, de uma forma
mais sucinta. Para estes autores, a diferença de fuso horário deve ser vista como
uma vantagem, para assim, distribuir equipes com o objetivo de criar um ambiente
de desenvolvimento de software onde as equipes trabalham apenas durante as
suas horas normais de trabalho, e ao final do dia, apenas redistribuem as suas
tarefas ao time que está iniciando a sua jornada, criando assim, efetivamente o
desenvolvimento 24-horas.
Carmel, Dubinsky e Espinosa [CAR09], propõem uma definição para o
follow-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
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 de
fluxo de trabalho de conhecimento global, criado com o objetivo de reduzir a
duração de um projeto, onde o produto é de propriedade de um centro de
desenvolvimento até ser entregue ao próximo. Esta entrega deve ser diária, e a
próxima equipe deve estar localizada diversos fusos horários a frente para dar
continuidade ao trabalho.
Após a apresentação das diferentes definições por diferentes autores, a
Tabela 1 mostra uma análise comparativa entre estas diferentes abordagens.
Para cada critério (colunas), procurou-se saber se a definição apresentada, de
alguma forma, indicou importância para este fator.
Os fatores utilizados para a análise comparativa apresentada na Tabela 1
surgiram de uma avaliação prévia dos conceitos apresentados pelos autores.
Procurou-se identificar os principais fatores de cada conceito encontrado na
literatura, os quais poderiam ser comparados entre as definições.

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 uma
definição para o desenvolvimento FTS. Podemos identificar que apenas um autor
define o FTS somente para a codificação, enquanto que os autores restantes
defendem a utilização para qualquer tarefa dentro do projeto. Outra característica
nas definições está relacionada ao objetivo principal da utilização do FTS. Apesar
de expresso de maneira distinta pelos autores, podemos perceber que o objetivo
principal do FTS é a diminuição do tempo necessário para desenvolver um
projeto. A diferença mínima necessária de fusos horários entre as equipes
distribuídas foi pouco citada. Também existem poucos trabalhos que consideram
relevante a importância de ter equipes distintas trabalhando no seu horário
habitual, evitando horas extras durante a noite. Este fator poderia ser mais
considerado, pois a maior parte das pessoas ao redor do mundo está acostumada
a trabalhar durante o dia e descansar durante a noite [CAR09].
Portanto, após esta análise comparativa das diferentes definições
sugeridas pelos autores, foram identificados pontos importantes em todas elas.
Assim, através destas informações coletadas, propomos uma definição para o
desenvolvimento FTS, a qual sintetiza as principais idéias e pode ser descrita da
seguinte forma:

20. 20
O follow-the-sun é tipo de desenvolvimento global de software onde o
principal objetivo é a diminuição do time-to-market, acelerando a construção do
produto final desde a concepção até a sua distribuição. Este ambiente opera com
equipes distribuídas em fusos horários e países distintos, onde cada equipe
detém o trabalho por determinado período, até que o mesmo seja transmitido para
a próxima equipe que inicia a sua jornada. A transferência pode ser para qualquer
tipo de tarefa relacionada com o desenvolvimento do projeto de software. Esta
transferência deve acontecer diariamente e de forma padronizada.

21. 21
4 CICLOS DE VIDA NO PROCESSO DE DESENVOLVIMENTO
FOLLOW-THE-SUN
Para tornar o desenvolvimento de software uma atividade mais estruturada
e padronizada, surgiram os modelos de processo de software [SOM07], também
conhecidos como ciclos de vida de um software [MCC99, KRI08]. A
funcionalidade principal de um modelo de ciclo de vida de um software é
estabelecer uma ordem na qual um projeto de software faz suas atividades como
por exemplo: especificação, implementação e testes [MCC99]. Estabelece ainda,
critérios que devem ser usados para determinar o momento de seguir para a
próxima fase do projeto [MCC99]. Atualmente existem diversos modelos de ciclos
de vida, dentre estes, podemos citar como exemplo, o modelo cascata, modelo
incremental e o modelo de prototipação.
A importância da escolha de um processo adequado para a utilização do
desenvolvimento FTS é fator importante para o sucesso do projeto [CAR09].
Atualmente, não existem processos largamente aceitos para esta forma de
desenvolver software. Diferentes autores defendem maneiras distintas para a
utilização do desenvolvimento FTS. Neste sentido, este capítulo apresenta uma
breve descrição de alguns modelos de ciclos de vida e, para cada modelo, serão
abordadas diferentes formas de utilizar o desenvolvimento FTS.
4.1 Modelo Cascata
Este modelo, também chamado de ciclo de vida clássico [PRE10], propõe
uma 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, existem
fases bem definidas, onde o final de cada fase marca o início da fase
imediatamente seguinte. A Figura 1 ilustra este modelo.

22. 22
Figura 1. Modelo cascata, adaptado de [SOM07]
Cada fase encontrada no modelo cascata pode ser resumidamente
definida, segundo [SOM07], da seguinte forma:
- Definição de requisitos: esta fase é marcada como o início do ciclo de
vida do software. Nesta fase do processo, são estabelecidas as funcionalidades
que o sistema deverá atender [SOM07].
- Projeto: esta fase caracteriza-se por traduzir os requisitos em uma
representação de software [PRE95]. Consiste em projetar o que foi definido na
fase anterior, do ponto de vista do sistema. Neste momento, é planejada a
arquitetura do sistema, estruturas de dados, e detalhes procedurais a serem
utilizados [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 sistema
concluída, é realizada a integração e os testes de todo o sistema. Esta fase
caracteriza-se por identificar problemas no sistema, e resolvê-los. Ao final desta
fase, 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 a
correção de problemas encontrados durante a utilização do sistema [SOM07].

23. 23
Este modelo de ciclo de vida é recomendado para projetos onde os
requisitos estão bem definidos e são geralmente fixos, ou seja, não mudam no
decorrer do projeto. Assim, o projeto pode ser desenvolvido de maneira linear do
início ao fim [PRE10].
4.1.1 Follow-the-Sun no Modelo Cascata
No modelo cascata, segundo trabalhos encontrados na literatura, o
desenvolvimento 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 como
poderia 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 FTS
durante esta fase [SOL10, CAR09]. Porém, para obter êxito nesta fase do
processo, [CAR09] apresenta práticas oriundas de metodologias ágeis para
facilitar e aumentar as chances de sucesso no uso do desenvolvimento FTS. A
abordagem ágil possui algumas características que apóiam a estruturação de
projetos para utilizar o desenvolvimento FTS [CAR09]. Estas características
facilitam á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 de
integração continua através de um ambiente de integração automatizado [CAR09,
YAP05], permite que cada time possa desenvolver suas tarefas no seu próprio
có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 o
dia com problemas em qualquer teste automatizado, bem como manter a

24. 24
integração continua do produto são práticas comuns em metodologias ágeis, e
cabem no desenvolvimento FTS, pois deste modo facilitam a transferência diárias
de tarefas.
Para evitar problemas de comunicação, as metodologias ágeis enfatizam a
comunicação face a face. O trabalho [CAR09] afirma que esta comunicação deve
ser mantida, porém para comunicação entre os membros de uma mesma equipe
co-localizada. Entretanto, ao utilizar o FTS, o objetivo é reduzir a comunicação
entre centros distribuídos para o menor nível possível, confiando mais nas
ferramentas e processos utilizados para suportar os aspectos técnicos, gerenciais
e sociais do desenvolvimento. Facilitando assim, a transferência de tarefas ao
final do dia, diminuindo os problemas de comunicação enfrentados por equipes
que utilizam o FTS.
A colaboração é vital no processo de desenvolvimento de software
[CAR09]. A abordagem ágil enfatiza a colaboração entre todas as pessoas
envolvidas no desenvolvimento. Ao utilizar o desenvolvimento FTS a colaboração
está relacionada a forma como os membros da equipe mantém as regras do
processo de desenvolvimento. Desta forma, é importante manter protocolos que
permitam ao próximo centro continuar o trabalho entregue pelo centro anterior
sendo 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 um
software é difícil, pois ao final de cada dia, tarefas inacabadas devem ser
transferidas 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 dia
de trabalho deve continuar a tarefa deixada pela equipe anterior, o que torna o
trabalho muito difícil. Porém, apesar de não haver na indústria exemplos de
sucesso [CAR09], seguindo estas práticas durante esta fase do projeto, pode-se
obter sucesso na utilização do desenvolvimento FTS [CAR09].

25. 25
4.1.1.2 Integração e Testes
O maior consenso encontrado na literatura relacionado a aplicação do
desenvolvimento FTS está na utilização desta forma de trabalho na fase do ciclo
de vida onde são realizados os testes e correções dos problemas encontrados
[CAR09, GOR96, HOL06]. Esta forma de trabalho vem sendo aplicada na
indústria com bastante sucesso [CAR09]. Utilizar o desenvolvimento FTS nesta
abordagem pode, porém, diminuir o ganho teórico de 50% no tempo de
desenvolvimento do projeto (para projetos que utilizam dois centros de
desenvolvimento) [CAR09]. Conforme mostrado na Figura 2, percebemos que a
fase de testes, onde seria utilizado o FTS, compreende apenas 25% do tempo
total do projeto [CAR09]. Neste caso, o ganho teórico de 50% seria somente
dentro 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 problemas
identificados por esta equipe devem ser documentos em um sistema de controle
centralizado, do qual integrantes de todos os times distribuídos têm acesso. Ao
terminar o dia de trabalho do time de teste, os problemas estão todos
documentados [CAR09]. No momento em que o time de desenvolvimento inicia o
seu trabalho, os defeitos encontrados e todas as informações relevantes aos
mesmos estão acessíveis, sendo assim, possível iniciar a sua correção. A Figura
3 ilustra a utilização do FTS durante a fase de integração e testes.

26. 26
Figura 3. Utilização do FTS durante a fase de testes
É importante destacar que, para o funcionamento desta forma de utilização
do desenvolvimento FTS, a transferência de tarefas ao final de cada dia deve
seguir uma estrutura bem definida e entendida por todos os times envolvidos no
desenvolvimento. Os problemas encontrados devem ser documentados de forma
clara e compreensível, com todas as informações necessárias, evitando
problemas de entendimento na comunicação [CAR09]. Para equipes que, devido
a 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 o
andamento do projeto. Portanto, a padronização das entregas de uma equipe
para outra é fundamental.
Uma pequena variação desta forma de utilizar o desenvolvimento FTS é
apresentada por [GOR09]. Para evitar alguns problemas de coordenação e
comunicação, o trabalho [GOR09] propõe uma pequena modificação. Deve existir
pelo menos 2 horas de trabalho simultâneo entre mais de uma equipe (a equipe
que está terminando o seu dia, e a que está iniciando). Neste período de tempo
devem ser discutidos os problemas de forma síncrona e qualquer dúvida que
possa surgir pode ser resolvida neste momento, evitando assim, atrasos no
projeto [GOR09]. A Figura 4 ilustra esta variação na utilização do FTS durante a
fase de integração e testes.
Figura 4. Utilização do FTS durante a fase de testes com trabalho simultâneo

27. 27
4.1.1.3 Manutenção
Alguns autores citam ainda a fase de manutenção como uma fase do ciclo
de vida propícia para utilizar o FTS [LUC02, CON06, HEL06, JAL04]. Para a
utilização do desenvolvimento FTS nesta fase deve-se manter times distribuídos
ao redor do mundo, garantindo que a diferença de fuso horário cubra 24 horas, ou
seja, sempre haverá um time trabalhando [LUC02]. Portanto, sempre que algum
problema for identificado, um time de suporte poderá ser acionado e, assim,
sempre haverá uma equipe disponível. Se for encontrado algum problema, a
equipe 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 foi
resolvido, esta equipe repassa todo o conhecimento adquirido até o momento
sobre o problema para a próxima equipe, que assume o mesmo, e a investigação
continua do ponto onde parou. Utiliza-se o FTS desta forma para soluções críticas
como 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 de
desenvolvimento não estão bem definidos, e o modelo de prototipação pode ser
usado para ajudar a identificar e definir requisitos [PRE10]. Este modelo é uma
forma iterativa, onde a primeira iteração inicia com os requisitos, logo após os
protótipos são criados, para então, serem validados pelo cliente [PRE10]. Após
esta avaliação, o cliente pode fornecer informações relevantes para que este
protó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 o
nível de satisfação esperado pelo cliente [SOM07, PRE10]. A Figura 5 ilustra este
modelo.

28. 28
Figura 5. Modelo de Prototipação
A vantagem da utilização deste modelo está na sua rapidez de
desenvolvimento, focando apenas no que será visível ao cliente, como interface
gráfica, formatos de entradas e saídas do sistema [SOM07, PRE10]. Neste
modelo, 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 de
utilização do desenvolvimento FTS, a equipe responsável por criar os requisitos e
a 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 de
trabalho, disponibiliza todas as informações necessárias para a próxima equipe, a
qual irá desenvolver os protótipos. Ao terminar a sua jornada de trabalho, a
equipe que desenvolveu os protótipos disponibiliza os mesmos para o time que
fará a verificação destes, apontando problemas e melhorias a serem realizadas.
Este processo é repetido desta forma até o momento em que o protótipo gerado
atinja 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 do
desenvolvimento FTS [CAR09].

29. 29
4.3 Modelo Incremental
O modelo incremental utiliza elementos do modelo linear, também
chamado de modelo cascata, porém com fluxos de processos paralelos [PRE10].
O modelo incremental é realizado em ciclos, e dentro de cada ciclo, utiliza-se o
modelo cascata. Cada um destes ciclos, também chamados de incrementos
[PRE10], produz alguma funcionalidade nova ao sistema, e ao finalizar o último
ciclo, obtém-se a versão final e funcional do produto. Os requisitos podem ser
priorizados onde os mais prioritários são entregues nos primeiros incrementos, ou
seja, funcionalidades mais críticas são entregues nos primeiros ciclos, deixando
funcionalidades adicionais para os próximos [SOM07, PRE10]. Ao iniciar um
incremento, os requisitos são congelados, deixando novos requisitos para ciclos
futuros [SOM07]. Desta forma, o sistema é entregue em pequenas versões, ao
invé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 do
modelo cascata (incrementos) [PRES10]. Desta forma, o desenvolvimento FTS
neste modelo de ciclo de vida, ocorre da mesma forma que no modelo cascata. A
principal diferença está no fato de utilizar o FTS a cada incremento, dentro das
fases citadas nos itens 4.1.1.1 (implementação), 4.1.1.2 (integração e testes) e
4.1.1.3 (manutenção).

30. 30
5 ESTUDOS EM FOLLOW-THE-SUN
A literatura apresenta poucos trabalhos relacionados ao desenvolvimento
FTS [TRE06]. Após uma extensa pesquisa, encontrou-se um número reduzido de
artigos que realizam estudos teóricos nesta área. Esta seção apresenta uma
compilação dos principais estudos relacionados à esta temática. Os estudos
apresentados 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 as
vantagens 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 os
requisitos para alcançar uma vantagem que seja interessante para um projeto
desenvolvido desta forma.
O estudo inicia descrevendo forma como as equipes devem realizar o
desenvolvimento do projeto. Para esta fase, duas equipes distintas foram criadas.
Uma delas opera em apenas uma localidade, sem fazer o uso do
desenvolvimento FTS. A outra equipe é dividida em duas localidades com fuso
horário distinto, e faz o uso do desenvolvimento FTS. A Figura 7 ilustra o formato
das 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
desenvolvimento FTS não gerou o ganho esperado. Os resultados mostraram um
aumento de 50% no tempo necessário para o desenvolvimento do projeto, foi
notado também um aumento de 70% no esforço, e a qualidade foi pior, pois a
quantidade de defeitos foi maior que o dobro.
Após adquirir estes dados iniciais sobre o desempenho das equipes, os
autores buscaram identificar fatores que teriam um forte impacto para a melhoria
destas medidas. Estes fatores, segundo os autores, podem direcionar os projetos
para a utilização de práticas onde os benefícios podem ser alcançados com maior
facilidade. Após a identificação destes fatores, os autores mostram que os
principais resultados foram:
- Diminuir o esforço: aumentando o tempo de trabalho simultâneo (também
conhecido como overlap) entre equipes distribuídas resulta em um menor esforço
necessário. Como na primeira configuração, as equipes não tinham a
possibilidade 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 um
aumento na produtividade. Entre outras vantagens, este tipo de comunicação
melhora a confiança entre os membros da equipe, resultando, assim na
diminuição do esforço.
- Diminuir duração do projeto: aumentar o overlap entre as equipes
distribuídas pode aumentar a duração do projeto, pois o tempo de
desenvolvimento diário diminui. Porém, ao notar que, além de ter um período
maior de trabalho simultâneo entre equipes distribuídas, outros fatores já citados
(produtividade, confiança), ajudam a diminuir o esforço, resultando assim num
menor tempo de desenvolvimento.
- Diminuição do número de defeitos: tendo um aumento na efetividade da
comunicação síncrona entre as equipes através do trabalho simultâneo,
diminuíram os problemas de entendimento das comunicações assíncronas. Isto
resultou em um número menor de defeitos encontrados.
Após identificar os fatores que poderiam melhorar o desempenho do
projeto, realizou-se o experimento novamente, porém, desta vez com um overlap
de horas de trabalho entre as equipes distribuídas. O resultado encontrado
apresentou uma pequena melhora em relação a primeira execução, porém, o

32. 32
desempenho do FTS ainda mostrou-se pior que o desenvolvimento em um único
local.
Na tentativa de alcançar uma melhora significativa, os autores incluíram
mais um centro de desenvolvimento, obtendo assim, a distribuição em três locais
distintos 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 os
centros de desenvolvimento distribuídos normalmente estarem em países que
possuem baixo custo. A qualidade continuou pior neste modelo, devido a
dificuldade de comunicação e coordenação entre os 3 centros.
Finalmente, os autores afirmam que o FTS pode ser uma boa estratégia se
dentre as necessidades do projeto está a diminuição do tempo de
desenvolvimento. Porém, salientam que se esta decisão for tomada, deve-se
utilizar a abordagem com no mínimo três centros distribuídos de forma a obter o
desenvolvimento 24 horas por dia, e tendo um período de trabalho simultâneo
para 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 desenvolver
um projeto de software. O objetivo deste estudo foi medir o ganho no tempo de
desenvolvimento 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 de
desenvolvimento de software, uma delas denominada controle (CO), composta
por 7 integrantes e a outra equipe, denominada de FTS, composta por 8
participantes. As duas equipes deveriam implementar os mesmos requisitos de
sistema. Todos os participantes do estudo eram estudantes de Ciência da
Computação ou Engenharia Elétrica de uma grande universidade. O tempo de
desenvolvimento por recurso era o mesmo para ambos os times. Definiu-se que o

33. 33
tempo de desenvolvimento do projeto seria 5 semanas. Porém, como a equipe
FTS faria o uso do desenvolvimento FTS, teoricamente, o tempo necessário para
o projeto deveria de duas semanas e meia. A Figura 8 ilustra o tempo de projeto
definido 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 foi
desenvolvido da forma tradicional, com todos os recursos da equipe trabalhando
no 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 em
horários diferentes, para simular a diferença de fuso horário: SubTeamA entre
21:30 e 11:00 e SubTeamB entre 11:30 e 21:00, mantendo 30 minutos para
alguma hora extra, quando necessário. Para garantir que nenhuma comunicação
síncrona entre as equipes SubTeamA e SubTeamB ocorressem, mecanismos
como mensagens SMS, comunicador instantâneo, e qualquer outro tipo de
comunicação síncrona foi proibido. Para controlar os horários de trabalho, cada
uma das duas equipes do FTS só poderia alterar códigos no repositório nos
horários determinados. Este controle foi realizado de forma automática pelo
sistema de repositório de código utilizado no projeto.
Ao final do estudo, os resultados apresentados pelos autores ficaram muito
aquém do esperado no início do estudo. Houve um ganho de apenas 10% no
tempo de duração do projeto, ao invés dos 50% que teoricamente deveria ser
alcançado. Analisando as estatísticas geradas pelo sistema de repositório de
código utilizado, uma constatação foi importante para justificar a pouca redução
do tempo de desenvolvimento deste experimento. A equipe FTS realmente

34. 34
terminou o projeto num tempo menor que a equipe CO, porém, devido a falta de
uma diretriz sobre o momento de parar a codificação, mesmo tendo terminado a
codificaçã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, atualizaram
arquivos, melhorando funcionalidades prontas. Enquanto isso, a equipe CO
realizava 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 apenas
10%, este número poderia ser maior, se tivessem definido o momento para
terminar a fase de codificação para a equipe FTS. Este ponto foi identificado
como uma limitação do estudo.
5.3 Estudo apresentado por Solingen e Valkema (2010)
No estudo apresentado por Solingen e Valkema [SOL10], os autores
apresentaram algumas hipóteses, e através de um experimento controlado,
apontam a validade ou não das hipóteses propostas. O estudo foca na
investigação do impacto do aumento do número de centros distribuídos na
velocidade de desenvolvimento de projetos que utilizam o FTS. Procura-se saber
qual o número ideal de equipes para se trabalhar em um projeto FTS.
O experimento inicia definindo a configuração das equipes, as quais foram
definidas da seguinte forma: cada execução do experimento seria realizada
utilizando um número de centros de desenvolvimento diferente entre 2 e 4. Estes
centros foram configurados da seguinte forma: sempre existe um centro
responsável por prover os requisitos e os feedbacks do trabalho realizado, então,
na configuração com duas equipes, existirá uma equipe de desenvolvimento e
uma de requisitos, para três equipes, da mesma forma, haverá uma de requisitos
enquanto as outras duas para o desenvolvimento e assim sucessivamente.
Devido ao fato de ser um experimento controlado, as diferenças de fusos
horários foram todas simuladas, criando horários de trabalho pré definidos entre
as diferentes equipes. Cada ciclo diário consiste de 2 a 4 dias trabalhados (um

35. 35
para cada equipe distinta), dependendo do número de centros adotados. Os dias
de trabalhos são contínuos, onde quando um dia termina (para um determinado
centro) outro está começando, simulando assim fusos horários distintos. Ao final
de um dia, o trabalho é repassado ao próximo time que está iniciando a sua
jornada.
O experimento foi realizado com estudantes de Ciência da Computação. A
cada dia, três execuções foram realizadas, utilizando 4, 3 e 2 centros de
desenvolvimentos. Ao final de cada execução, retirou-se uma equipe
aleatoriamente. Ao final de cada dia, a primeira equipe (responsável por requisitos
e feedbacks) relatava para o primeiro time de desenvolvimento as informações
necessárias para iniciar o próximo ciclo. As tarefas a serem realizados eram
extremamente simples, sendo possível assim, simular um dia de trabalho em
apenas quatro minutos. Com esta configuração, segundo os autores, foi possível
analisar o efeito do número de centros distribuídos em um projeto FTS
relacionado com o tempo de desenvolvimento.
O estudo discute os resultados obtidos da seguinte forma: apresenta a
hipótese, e a validade ou não da mesma. A seguir estão relacionadas as
hipóteses propostas pelos autores, juntamente com o resultado obtido em relação
as mesmas.
- Quantidade de trabalho entregue:
Htotal: total4 > total3 > total2
Apresentados os dados coletados, foi possível identificar que a quantidade
de trabalho entregue realmente aumenta a medida que a quantidade de centros
de 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 diminuem
a velocidade de trabalho por volta de 20% na média por centro de
desenvolvimento. Portanto, concluindo assim favoravelmente a está hipótese.

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-se
afirmar sobre está hipótese.
- Percepção de velocidade:
Hperspd: perspd4 < perspd3 < perspd2
Segundo os dados obtidos, houve apenas uma diminuição desta percepção
na configuração com 4 centros. Portanto, segundo os autores mostram, esta
hipó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, esta
percepção caí drasticamente, e os participantes encontram mais dificuldade para
medir 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 mostram
que apesar das dificuldades de coordenação e comunicação que o
desenvolvimento FTS impõe, dependendo do que espera-se de um projeto de
software, a sua utilização pode ser benéfica. A principal vantagem que o FTS
pode alcançar, segundo os autores, está na diminuição do tempo de projeto, o
que 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 uma
análise comparativa entre diferentes trabalhos. Para cada critério (colunas),
procurou-se saber se o experimento relacionado, de alguma forma indicou
importância para este fator.

37. 37
Os fatores utilizados para a análise comparativa apresentada na Tabela 2
surgiram de uma avaliação prévia dos estudos apresentados. Procurou-se
identificar os principais fatores de cada estudo, os quais poderiam utilizados para
crité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
Algum
Experimentos Apresentados
Setamanit, 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 estudos
apresentados está relacionada às métricas utilizadas. Percebe-se que todos os
estudos 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 inferior
ao esperado, enquanto [SET07], ao obter um resultado aquém do esperado,
investiga os problemas enfrentados e refaz o experimento, para tentar melhorar o
ganho no tempo de projeto, alcançando um pequeno ganho. Já [SOL10] faz o
experimento utilizando diversas distribuições com 2, 3 e 4 equipes, buscando
avaliar se há uma melhora no ganho do tempo de projeto ao adicionar novos
times.
A métrica relacionada ao número de centros necessários para obter
vantagem na utilização do FTS foi utilizada por [SET07] e [SOL10]. Estes estudos
fazem uma comparação do ganho no tempo de desenvolvimento adicionando
mais de dois centros de desenvolvimento, obtendo resultados satisfatórios.

38. 38
Conseqüentemente, estes trabalhos sugerem um número mínimo de centros de
desenvolvimento para aumentar as chances de sucesso na utilização do
desenvolvimento FTS. Para [SET07], a vantagem no tempo de desenvolvimento
só é atingida quando existem, pelo menos, três centros distribuídos. Enquanto
que [SOL10] defende que o ganho aumenta conforme o número de centros
distribuídos aumenta (este estudo utilizou distribuição entre dois e quatro centros
para 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 realmente
um ganho em relação ao tempo de desenvolvimento em todos os trabalhos
apresentados. Porém, este ganho ficou muito aquém do ganho teórico esperado
pelo 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 centro
de desenvolvimento foi adicionado ao projeto, pois utilizando apenas dois, o
tempo para desenvolver o projeto, foi 50% maior. [SOL10] mostra apenas que a
quantidade de trabalho entregue é maior se aumentarmos o número de centros
de desenvolvimentos distribuídos, obtendo melhor resultado com quatro centros
distribuídos (número máximo utilizado).
Portanto, segundo os resultados apresentados, o desenvolvimento FTS
ainda não produz o ganho teórico esperado, principalmente devido as dificuldades
impostas, porém pode-se obter algum ganho no tempo de projeto. Percebe-se
que 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 de
desenvolvimento deve ser utilizada, segundo os estudos, apenas quando há a
necessidade de desenvolver o produto em um tempo menor, ou seja, diminuir o
time-to-market [SET07, SOL10, CAR09]. As conclusões destes estudos vão ao
encontro com a literatura desta área, a qual afirma que a principal vantagem do
uso do desenvolvimento FTS está na diminuição do tempo de desenvolvimento de
um projeto [CAR09, GUP09-II, GOR96-II, VIS09].

39. 39
6 CONSIDERAÇÕES FINAIS
A utilização do DDS pelas organizações está cada vez mais comum. Isto
se deve ao fato das diversas vantagens que a utilização deste ambiente de
desenvolvimento pode trazer. Porém, o DDS apresenta alguns desafios, dentre
estes, está a diferença de fuso horário entre centros de desenvolvimento
distribuídos. Alguns autores sugerem que esta diferença possa ser vista como
uma 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 de
desenvolvimento do projeto, ou seja, redução do time-to-market. Porém o ganho
apresentado ainda é muito inferior ao esperado. Portanto, devido aos desafios
que esta forma de desenvolver software pode apresentar, os estudos expostos no
capítulo 5 sugerem o uso do FTS apenas para projetos onde existe a necessidade
da redução do tempo de projeto. Ainda, a revisão da literatura mostrou que devido
ao fato do desenvolvimento FTS ser uma área nova de estudo na engenharia de
software, poucos estudos sobre esta temática foram publicados [TRE06]. Estudos
empíricos que envolvem casos de sucesso na indústria utilizando esta forma de
desenvolver software ainda são raros [SOL10, CAR09]. Este fato está relacionado
as inúmeras dificuldades de coordenação e comunicação em projetos desta
natureza [SET07, CAR09]. Estas adversidades surgem principalmente durante a
transição de tarefas entre equipes distribuídas, os chamados hand-offs.
Neste sentido, identifica-se a oportunidade de desenvolver um estudo que
atue nas dificuldades relatadas. Portanto, esta pesquisa visa a definição de um
processo 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ão
focadas 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
idéia: para cada funcionalidade do projeto, definem-se testes unitários antes do
início da sua implementação, durante a fase de projeto. Estes artefatos seriam
utilizados como um guia para as equipes distribuídas. Ao final de cada dia de
trabalho, deve-se fazer o check-in do código desenvolvido, e um build
automatizado é executado. Nesta etapa, todos os testes unitários são executados
e, ao final, sabe-se quais os testes que estão cobertos pelo código atual. Desta
maneira, seria possível identificar de forma clara e precisa em qual ponto do
desenvolvimento a equipe anterior terminou o seu dia de trabalho, e de onde o
trabalho deve ser continuado. A Figura 9 apresenta a idéia principal do processo a
ser 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
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
[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:
Conway's 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 Practitioner's 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
[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
[YAP05] Yap, M.; , "Follow the sun: distributed extreme programming
development," Agile Conference, 2005. Proceedings , vol., no., pp. 218-
224, 24-29 July 2005