Identificação e mitigação de riscos em projetos de desenvolvimento distribuído de software

Pedro Henrique Veras Coelho^a, Germano Fenner, Alberto Sampaio Lima^a

Resumo

Os mercados estão cada vez mais globalizados, gerando impactos em diversas áreas e provocando o surgimento de novas formas de competição e cooperação que ultrapassam os limites das fronteiras dos países. Nesse contexto, a área de desenvolvimento de software também foi afetada, impulsionando muitas organizações a experimentarem o desenvolvimento de programasem instalações localizadas em vários países. Surgiu assim o desenvolvimento distribuído de software (DDS), que apresenta diversos fatores de risco, como a dispersão geográfica e problemas de comunicação. Embora existam diversas dificuldades enfrentadas pelas organizações que adotam o DDS, verificou-se que com medidas de mitigação dos riscos, as vantagens se sobrepõem às dificuldades e seu uso possibilita a redução de custos e aumento da competitividade das organizações. Foi realizada uma pesquisa bibliográfica e um estudo de caso que identificaram os riscos mais comuns do DDS e as formas de tratá-los.

Palavras-chave: Desenvolvimento Distribuído de Software, Gerenciamento de Riscos, Gerenciamento de Projetos.

1.  INTRODUÇÃO

O panorama econômico atual demanda cada vez mais uma redução de custos dos projetos e do tempo de colocação de produtos no mercado. Caracterizado pela distribuição do desenvolvimento de software entre cidades, regiões ou até mesmo entre países, o desenvolvimento distribuído de software (DDS) surgiu para atender essa demanda por competitividade das organizações.

Com o aumento da disponibilidade de infraestrutura e de ferramentas de comunicação, o gerenciamento do DDS se tornou mais viável (Persson et al., 2009). No entanto, devido a sua complexidade, o DDS ainda apresenta uma série de riscos nas áreas de comunicação, cultura, tecnologia colaboração e engenharia de requisitos.

Segundo Kwak e Stoddard (2004), a disciplina de gerenciamento de riscos é a menos praticada dentre as áreas de gerenciamento de projetos. Devido a diversos fatores como a iteração social limitada entre os membros da equipe, o gerenciamento de riscos não pode ser negligenciado no DDS. Sua ausência pode levar o projeto ao fracasso.

A presente pesquisa investigou os riscos envolvidos no DDS relacionados a cinco áreas (comunicação, cultura, tecnologia, colaboração e engenharia de requisitos), propondo medidas para mitigá-los.  Realizou-se um estudo de caso real que gerou resultados promissores, propiciando um melhor entendimento sobre os riscos identificados e as estratégias adotadas para aplacá-los.

2.  TRABALHOS RELACIONADOS

Nos últimos anos, pode-se perceber um grande avanço em direção à globalização dos negócios. Na busca por redução de custos e acesso a profissionais qualificados, muitas organizações começaram a experimentar o outsourcing e criar instalações para desenvolvimento de software em locais remotos.

De acordo com Steinmacher et al. (2013), o DDS é baseado em times geograficamente dispersos trabalhando colaborativamente em um projeto de software. No DDS, os desenvolvedores interagem de forma distribuída durante o ciclo de vida do software, criando uma rede de times distribuídos. Em alguns casos, esses grupos incluem membros de uma mesma organização; já em outros envolvem diferentes organizações. Os autores ainda afirmaram que o DDS traz novos desafios para os gestores -  desafios contextuais, culturais, organizacionais, geográficos, temporais, de linguagem e diferenças políticas entre os desenvolvedores.  Foi citado que a adoção crescente do DDS e suas características apresentam vários desafios e novas oportunidades para pesquisa, bem como para a investigação da aplicabilidade das pesquisas existentes. Em seu trabalho, os autores realizaram uma revisão sistemática sobre o DDS, identificando lacunas e oportunidades para pesquisa nas dimensões de comunicação, coordenação e cooperação entre os times, e ainda uma falta de ligação das pesquisas avaliadas com outras áreas de pesquisa, como computação ubíqua. O gerenciamento de projetos foi citado como uma das áreas que poderiam ser pesquisadas, sendo o foco do presente trabalho.

Foi citado em Jimenez et al. (2009) que nos projetos de DDS os encontros presenciais se tornaram menos comuns e que a interação entre os membros requeria a utilização da tecnologia para dar suporte à comunicação, coordenação e cooperação das equipes.

Além da redução de custos, o DDS traz diversas vantagens como aproveitamento da legislação trabalhista, a proximidade do mercado local, incentivos fiscais governamentais, a sobreposição de fusos horários (com a possibilidade de se trabalhar 24 horas por dia) permitindo o desenvolvimento round-the-clock e consequente redução no tempo para colocar um produto no mercado (Hersleb et Moitra, 2001). Segundo Sakthivel (2007), muitas empresas americanas na Fortune 500 têm desenvolvido seus sistemas de informação em países como a Índia e China se beneficiando dos baixos custos de mão de obra nesses países.

O avanço da economia, a sofisticação dos meios de comunicação e a pressão pela redução de custos têm atraído grandes investimentos no DDS.  Com a melhoria das ferramentas e métodos de engenharia de software, haverá uma pressão contínua para a adoção de abordagens globalizadas de criação de programas.Estas abordagens podem ter a forma de contratos formais de outsourcing, emergir por meio da colaboração entre diferentes divisões de organizações internacionais, ou consistir de um pequeno grupo de programadores que trabalham em um mesmo projeto, mas vivem em cidades diferentes (Kiel, 2003).

Não existem dúvidas que tanto o desenvolvimento de software tradicional quanto o distribuído apresentam dificuldades. No entanto, o desenvolvimento distribuído acrescenta alguns desafios ao gerenciamento de projetos, como ter que gerenciar pessoas dispersas geograficamente e em diferentes fusos horários, além das barreiras de linguagem e diferenças socioculturais. De acordo com Herbsleb et Moitra (2001), a separação física entre os membros do projeto pode se refletir em diferentes fatores, como a decisão de realizar ou não um projeto de forma distribuída; de que maneira as tarefas serão distribuídas,tendo como base os recursos disponíveis, infraestrutura e expertise em tecnologias; questões relacionadas aos valores e princípios culturais entre os membros da equipe; questões relacionadas ao gerenciamento de processos, como a dificuldade de sincronismo e a necessidade de marcos comuns ao projeto; e questões relativas à gestão do conhecimento, como o armazenamento e compartilhamento de informações.

Em Bubeck et al. (2012) foi apresentada uma proposta DDS para o desenvolvimento distribuído de plataformas de robôs, ajudando no processo de integração do sistema. Foram gerenciados com sucesso projetos para o desenvolvimento de dez robôs em sete locais diferentes. O trabalho abordou principalmente os aspectos relacionados ao desenvolvimento do código.

Estler et al. (2012) apresentou um estudo de caso sobre o impacto dos processos de desenvolvimento ágeis e estruturados em projetos de software distribuídos globalmente. Avaliou-se o sucesso, a economia, a importância atribuída pelos clientes, a motivação dos times e a quantidade de comunicação em tempo real e assíncrona necessária durante a execução dos projetos avaliados. Os autores discutiram aspectos como offshore verso nearshore, padrões de comunicação e alguns pontos críticos. Os resultados desse trabalho indicaram que a escolha entre métodos ágeis ou estruturados não era um fator essencial para os projetos de DDS.

O trabalho de Farias Junior et al. (2012) apresentou os riscos de comunicação em projetos de DDS identificados em uma abordagem empírica. Foram demonstradas formas para mitigá-los, coletadas por meio de entrevistas com líderes e gerentes de projeto de várias empresas. Os autores afirmaram que apesar dos gestores estarem cientes da importância do gerenciamento de riscos nesses projetos, existe pouca efetividade e muitas empresas não possuem uma metodologia formal definida. Os pesquisadores afirmaram ainda que em ambientes distribuídos, caso o processo de software não esteja bem definido e os times não estejam bem preparados para o trabalho nesse contexto, o risco aumenta substancialmente.

3.  GERENCIAMENTO DE RISCOS EM PROJETOS DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE

O desenvolvimento de software consiste na elaboração de algo que nunca foi feito antes, mesmo que o processo seja similar ao de outros projetos (Kwak et Stoddard, 2004). Essa característica resulta em um ambiente de incertezas e consequente no surgimento de riscos. 

Segundo Boehm (1991), em uma pesquisa feita com 600 empresas, 35% delas já tiveram pelo menos um projeto problemático. E muito desses problemas teriam sido evitados ou reduzidos se houvesse a preocupação em identificar e resolver os elementos de alto risco. Segundo o PMI (2008), a abordagem proativa das incertezas dos projetos pode evitar que estas se transformem em ameaças ao projeto.

Um gerenciamento inadequado de riscos em projetos de desenvolvimento de software é uma das principais razões que causam o estouro de prazo e orçamento. O perigo é ainda maior quando os sistemas são desenvolvidos por equipes compostas por pessoas de diversas nacionalidades, falando várias línguas e distribuídas geograficamente e temporalmente (fusos horários distintos) (Salthivel, 2007).

O gerenciamento de riscos no DDS se torna ainda mais importante à medida que os projetos distribuídos são difíceis de serem implantados, executados e controlados, devido a fatores não técnicos - diferenças culturais, sociais e políticas (Priladnick et Yamaguti, 2004). No entanto, com o gerenciamento efetivo dos riscos, adotando-se processos, ferramentas e principalmente medidas que facilitem a comunicação, o DDS pode ser extremamente benéfico.

3.1.  Identificação dos riscos em desenvolvimento distribuído de software

No Quadro 1 estão listados os riscos que são característicos de projetos distribuídos agrupados em cinco áreas. Alguns são também são típicos de um projeto coalocado, mas será feita uma análise de cada risco focada no desenvolvimento distribuído.

3.2.  Comunicação

A comunicação tem um papel fundamental no desenvolvimento de software, permitindo resolução de problemas, entendimento de requisitos e compreensão das tarefas a serem desenvolvidas. Em um estudo de caso conduzido por Perry et al. (1994), constatou-se que os desenvolvedores gastam 75 minutos por dia em comunicação informal.

A comunicação entre os membros da equipe pode ser um grande desafio no desenvolvimento de software distribuído. Segundo Herbsleb et Mockus (2003), quando a distância entre os membros da equipe atinge 30 metros ou mais, a frequência de comunicação entre eles cai para um nível equivalente a membros que estão a quilômetros de distância.

Quadro 1. Riscos Identificados no DDS

Fonte: Os próprios autores

Dependendo da quantidade de locais envolvidos e da dispersão temporal, a comunicação síncrona pode se tornar muito difícil, tornando necessário o uso de meios de comunicação assíncronos.

Entre os fatores que afetam a comunicação no DDS, destacam-se:

• Quantidade de locais envolvidos: em um projeto distribuído, quanto maior a quantidade de locais envolvidos, mais complexo tende a ser a coordenação e distribuição de tarefas. Em um país pode haver um feriado nacional, provocando a parada de uma equipe enquanto as demais continuam o trabalho. Além disso, certas legislações podem impedir a importação de hardware e software.
• Dispersão geográfica: Os projetos distribuídos podem apresentar variados níveis de dispersão geográfica o que impossibilita a interação face a face. De acordo com Audy et Prikladnicki (2008), estes podem ser:
• dispersão nacional - caracteriza-se por membros localizados no mesmo país. Em alguns países há diferenças de fusos horários, no entanto as equipes podem reunir-se em um curto intervalo de tempo
• distância continental - equipes localizadas em países diferentes mas em um mesmo continente. As diferenças culturais, de idioma e de fusos horários são mais acentuadas, podendo dificultar interações.
• distância global: é caracterizada por equipes localizadas em diferentes países e continentes. A diferença de fuso horário pode impedir interações síncronas, e as diferenças culturais podem dificultar o trabalho.
• Dispersão temporal: o projeto pode envolver equipes localizadas em diversos fusos horários, dificultando a coordenação e a troca de informações de forma síncrona e aumentando dependência da comunicação assíncrona, como o email. Dessa forma, pode ser necessário que uma equipe aguarde mais de um dia para solucionar problemas ou dúvidas que necessitam da resposta de uma equipe localizada em outro fuso horário. Outro risco que a dispersão temporal acrescenta é em relação à marcação de reuniões, pois podem ocorrer confusões em relação a qual fuso horário utilizado para o agendamento.

3.3.  Cultura

A dispersão das equipes em diversos países traz consigo desafios relacionados à cultura. Cada país possui sua forma de expressão característica, o que pode ser interpretado de maneira diferente por uma equipe em outro país gerando mal-entendidos. Entre os riscos identificados relacionados à cultura, destacam-se:

• Diferenças socioculturais - a reunião de pessoas com diferentes costumes, valores e religiões em um ambiente de projeto que requer uma estreita cooperação. Pode ocasionar o surgimento de conflitos e desentendimentos. Diferentes formas de trabalho, entonação e até mesmo a linguagem utilizada na escrita de e-mails podem gerar desavenças, reduzindo o sentimento de time e impactando negativamente o projeto (Kiel, 2003). Além desse fator de risco, podem existir também diferenças religiosas: se um local tem tradição de não se trabalhar em certo período, haverá uma falta de sincronismo no projeto.
• Diferenças de idioma - o idioma constitui uma importante barreira na comunicação entre as equipes distribuídas, especialmente na comunicação verbal. O sotaque e a entonação podem ocasionar mal-entendidos e atrasos na comunicação mesmo em equipes que possuem o mesmo idioma (Kiel, 2003).

3.4  Tecnologia

Uma infraestrutura tecnológica adequada é parte fundamental do DDS; sem ela seriam impossíveis a comunicação e a interação entre os envolvidos no projeto. Além da infraestrutura física relacionada a configurações de rede e servidores, há também a questão de gerenciamento das ferramentas utilizadas para garantir uma padronização no projeto. Entre os riscos identificados relacionados à tecnologia, destacam-se:

• Conhecimentos técnicos - segundo Sakthivel (2007), alguns países investem pouco em pesquisa e desenvolvimento, produzindo profissionais da tecnologia da informação sem conhecimentos nas tecnologias e processos de desenvolvimento mais modernos e com baixa produtividade. Além disso, as equipes podem não possuir os mesmos conhecimentos técnicos, com uma possuindo conhecimento em uma determinada linguagem de programação que a outra não tem.
• Gerenciamento de configuração - um sistema de gerenciamento de configuração de software é uma ferramenta muito poderosa que permite redução de problemas de comunicação, pois força uma visão única do projeto e um processo único de trabalho (Carmel et Argwal, 2001). No entanto, essa tecnologia pode ser um grande desafio para equipes distribuídas devido a diferenças de ferramentas, desconhecimento das mudanças no produto e dos defeitos existentes (Persson et al., 2009).
• Infraestrutura - alguns países podem sofrer de infraestrutura inadequada de internet e de energia elétrica, apresentando lentidões na conexão e oscilações elétricas que atrasam e dificultam o trabalho em projetos distribuídos.
• Compatibilidade de ferramentas - de acordo com Persson et al. (2009), quando há o envolvimento de desenvolvedores de diversas partes do mundo trabalhando, a compatibilidade de ferramentas pode ser um grande problema, pois uns podem preferir determinada linguagem de programação, sistema operacional ou ferramentas de desenvolvimento.

3.5.  Colaboração

A colaboração reflete a capacidade que os envolvidos no projeto têm de compartilhar as informações. Segundo Persson et al. (2009), o grande risco é quando a estrutura de colaboração não se encaixa no desenvolvimento distribuído. Entre os riscos associados, estão:

• Alinhamento de processos – a falta de conhecimento da cultura organizacional, diferenças de processos de negócios, nos métodos de desenvolvimento e de gerenciamento de projetos podem resultar em conflitos, incompatibilidades e na dificuldade de criação de um sentimento de time entre os membros do projeto (Persson et al., 2009).
• Compartilhamento da Informação - os níveis de dispersão do desenvolvimento distribuído, o desconhecimento sobre quem está responsável por uma tarefa e quem possui conhecimento técnico em uma determinada área podem ocasionar a falta de compartilhamento de informações. Além disso, pouca confiança entre as equipes resulta no medo de perder a propriedade sobre as soluções encontradas, deixando de disponibilizá-las para outros grupos. Com isso, o reuso de código e de solução que economizariam tempo e dinheiro fica comprometido.
• Controle do projeto - as dificuldades de comunicação impostas pelo desenvolvimento distribuído provocam desconhecimento do status do projeto e de quais tarefas estão no caminho crítico. Além disso, o desenvolvimento distribuído requer outras formas de estimativa de esforço, diferentes das usadas em projetos coalocados, pois estes podem fornecer uma estimativa imprecisa em projetos distribuídos devido aos diversos níveis de comunicação e de gerenciamento envolvidos.

3.6  Engenharia de requisitos

Devido à distância, a frequência de comunicação entre os engenheiros de requisitos e os stakeholders diminui. Dessa forma, aumenta-se o risco de os requisitos serem mal interpretados e consequentemente necessitarem ser modificados, o que aumentaria o custo e estouraria o prazo do projeto. Entre os riscos relacionados à engenharia de requisitos, pode-se citar:

• Conhecimento da tarefa – com o frequente uso da comunicação assíncrona e volatilidade das especificações dos requisitos, uma má especificação das tarefas a serem desenvolvidas pode ocorrer, gerando incompreensão sobre o que deve ser desenvolvido.
• Mudança de requisito - as mudanças nos requisitos são um grande risco ao desenvolvimento de software. Segundo Herbsleb et al. (2003), em projetos distribuídos, essas mudanças levam 2,5 vezes mais tempo para serem implementadas do que em projetos coalocados.
• Baixa qualidade - em um projeto envolvendo muitas pessoas localizadas em diversos países, sem métodos, ferramentas e processos de desenvolvimento adequados, pode-se levar ao risco de uma baixa qualidade do produto desenvolvido. Com isso, geram-se retrabalho e aumento da desconfiança entre os membros do projeto (Ebert et al., 2008).

4.  ESTUDO DE CASO

Um estudo de caso consiste em uma abordagem metodológica de investigação especialmente adequada ao momento. Nele procura-se compreender, explorar ou descrever acontecimentos e contextos complexos, nos quais estão envolvidos diversos fatores simultaneamente. Yin (2005) afirmou que essa abordagem se adapta à pesquisa em que o investigador é confrontado com situações complexas, de tal forma que dificulta a identificação das variáveis consideradas importantes.

Foi avaliado um cenário real de DDS visando à identificação dos riscos envolvidos em um projeto de do tipo.  Apresentaram-se os riscos envolvidos no projeto e as medidas de tratamento de riscos adotadas para mitigá-los.

O cenário avaliado corresponde a um projeto financiado com recursos de isenção fiscal da Lei de Informática, cujo objetivo era o desenvolvimento de uma rede social para integração de cientistas atendendo uma empresa americana com sede no Brasil e em Israel. Por questões de confidencialidade do negócio, seu nome não será divulgado.

4.1.   Metodologia

O objetivo principal desta pesquisa foi o desenvolvimento, esclarecimento e verificação de conceitos e ideias a partir das teorias existentes sobre o gerenciamento de riscos em projetos de DDS.

Para isso, realizou-se uma pesquisa de campo qualitativa e exploratória (Gil, 2002).   Buscou-se coletar informações relevantes durante a execução do projeto de DDS avaliado por meio de revisão de literatura, da observação de atividades rotineiras e das informações coletadas por meio de entrevistas semiestruturadas realizadas com gerentes de projetos, membros dos times e líderes da empresa.

Buscou-se observar as recomendações de Runerson et Host (2009) e de Wohlin et al. (2000) durante a fase de planejamento da pesquisa e projeto das entrevistas.

4.2.  Descrição e análise

O projeto possuía um nível de dispersão global: uma equipe estava localizada em Fortaleza, outra em Porto Alegre e a terceira na cidade de Haifa (Israel). A Figura 1 apresenta uma visão sobre a distância física que separa essas cidades.

A equipe sediada em Fortaleza realizou o desenvolvimento da camada de apresentação do sistema, a qual se comunica com a camada de lógica de negócio que continha os algoritmos desenvolvidos pela equipe em Israel.

O grupo de Porto Alegre realizou a intermediação e cuidou da parte contratual do projeto.

A metodologia de desenvolvimento utilizada foi a incremental com ciclo de desenvolvimento de 10 dias. Ao, havia uma teleconferência entre todas as equipes para apresentar o que havia sido desenvolvido e discutir as lições aprendidas e possíveis melhorias para os próximos ciclos.

Entre as barreiras identificadas durante esta pesquisa pode-se citar a dispersão temporal, pois a diferença de fuso horário entre Brasil e Israel é de 5 horas (conforme mostrado na Figura 2), o que reduz a janela de comunicação e o tempo para resolução de dúvidas.

Figura 1. Distribuição das equipes

Fonte: autoria própria

Outra barreira identificada foi relativa às diferenças socioculturais. A equipe localizada em Israel cumpria a tradição judaica do Shabat, que representa o descanso semanal no judaísmo e constitui-se no período a partir de sexta-feira à tarde até o sábado à noite, onde não se trabalha. Além desse fato, a semana de trabalho em Israel se inicia no domingo, de forma diferente do Brasil. Dessa forma, houve apenas quatro dias de trabalho em comum durante o projeto.

Combinado aos riscos inerentes a dispersões geográfica e temporal, foi identificado no projeto o risco evidenciado na seção 3.4, da diferença de conhecimentos técnicos. As equipes localizadas em Porto Alegre e Haifa não possuíam conhecimentos na linguagem de programação utilizada pela equipe localizada em Fortaleza e esta não possuía conhecimento nos algoritmos desenvolvidos pela equipe localizada em Israel.

Figura 2. Fusos horários

Fonte: Autoria própria

Inicialmente houve um receio da equipe de Haifa em repassar o algoritmo por ela desenvolvido. Conforme apresentado na seção 3.5, o risco da falta de compartilhamento de informações é citado como comum nos projetos distribuídos.

Algumas solicitações de mudanças foram feitas pelo grupo de Fortaleza para complementar o algoritmo desenvolvido pela equipe de Haifa, implicando no risco de falta de conhecimento da tarefa, o qual foi evidenciado na seção 3.6 desta pesquisa.

As dificuldades do gerenciamento de configuração e a baixa qualidade do software desenvolvido foram dois dos riscos inerentes a este projeto.  Para tanto, necessitaram-se de políticas de testes e de gerenciamento de configuração como medidas de mitigação. Na sequência serão explicitadas as políticas utilizadas neste cenário.

No início do projeto, o líder técnico de Fortaleza precisou viajar para Israel. Com essa ação, foi possível abrandar o risco da falta de alinhamento de processos, além de realizar um maior detalhamento dos requisitos do processo, o que dificilmente seria possível sem uma comunicação face a face.

As diferenças de idioma se apresentaram como um grande risco ao projeto. O idioma padrão adotado no projeto foi o inglês, no entanto alguns dos membros da equipe de Fortaleza apresentavam um nível muito básico do idioma. Como forma de auxílio, os participantes do projeto foram estimulados a frequentar cursos de idioma, mesmo que fosse durante o horário de trabalho.

Devido à diferença de fuso horário e à tradição judaica do Shabat, as reuniões somente podiam ser realizadas de segunda a quinta-feira até as 9h da manhã (horário de Brasília). Dessa forma, medidas de mitigação não puderam ser tomadas e o risco foi incorporado ao projeto. Tornou-se necessário que a equipe de Fortaleza iniciasse o expediente de trabalho mais cedo em dias de reunião. Devido ao Shabat, as equipes tiveram apenas quatro dias de trabalho em comum, prejudicando a interação.

Todas as reuniões do projeto foram realizadas via teleconferência e utilizando software de compartilhamento de tela. Nessas reuniões, o progresso do projeto era acompanhado e novas funcionalidades e requisitos eram adicionados, gerando um risco de incompreensão da tarefa a ser realizada e do correto status do projeto. Como forma de diminuição desses riscos, ao final de cada reunião era gerada uma ata, que passava pela conferência das equipes, e as tarefas eram cadastradas no software acompanhamento de tarefas. O acesso às informações desse software era disponibilizado para todos os participantes do projeto.

O risco da diferença de conhecimentos técnicos foi abrandado com a equipe de Fortaleza ficando responsável pelo desenvolvimento na linguagem de programação sobre a qual ela detinha conhecimento. Houve ainda um estudo dos algoritmos desenvolvidos pela equipe de Israel. Já a equipe de Haifa ficou responsável pela parte do desenvolvimento que não demandava o uso da linguagem de programação utilizada pelo grupo de Fortaleza.

A política de testes consistia na utilização de testes unitários pelos desenvolvedores e de integração automatizados ao se enviar uma modificação no código para o sistema de gerenciamento da configuração. Ao final do desenvolvimento de uma atividade, testes funcionais eram realizados manualmente por um testador, para verificar a aderência do que foi desenvolvido aos requisitos. Com essa política, foi possível diminuir o risco da baixa qualidade do produto desenvolvido.

Juntamente à política de testes, adotou-se uma de gerenciamento de configuração que consistiu na utilização de um repositório local em Fortaleza. Ao final de cada ciclo de desenvolvimento, era sincronizado com o repositório central da empresa localizado em Porto Alegre. Ao se iniciar o desenvolvimento de uma nova atividade, o desenvolvedor criava um branch. Ao terminar a atividade e testá-la, o que foi desenvolvido era integrado ao repositório. Dessa forma, evitou-se que um código defeituoso fosse introduzido no repositório central, comprometendo a qualidade do software. Por meio da utilização dessa política de gerenciamento da configuração, conseguiu-se eliminar o risco da falta de versionamento de código e documentos.

No Quadro 2 estão listados os riscos identificados no projeto e como eles foram tratados.

Quadro 2. Riscos e mitigações do cenário

Fonte: Os próprios autores

5.   CONCLUSÃO

É inegável que o DDS traz benefícios como redução de custo de mão de obra, aproveitamento de legislações trabalhistas e desenvolvimento round-the-clock. No entanto, o processo traz consigo uma série de riscos associadas às dificuldades de comunicação, diferenças socioculturais, de idioma e fuso horário.

Os riscos associados ao DDS vão além das questões tecnológicas, envolvendo fatores sociais e humanos. Dentre os riscos identificados, o mais citado na literatura é comunicação, pois à medida que o nível de dispersão aumenta, mais difícil se torna gerenciá-lo.

Esta pesquisa proporcionou uma visão geral dos riscos envolvidos do DDS com base na experiência obtida em um estudo de caso real, confrontado com uma revisão de literatura.

As propostas de mitigações que foram apresentadas podem ser utilizadas para reduzir o impacto das dificuldades oriundas do desenvolvimento distribuído de software, permitindo que as organizações obtenham bons resultados ao gerenciarem esses tipos de projetos.

Os riscos identificados no estudo realizado são comuns em projetos distribuídos. No entanto, devido à especificidade de cada projeto, as equipes devem identificar os perigos inerentes ao projeto e realizar um processo contínuo para identificá-los.

Apesar dos resultados obtidos nesta pesquisa terem sido promissores, indicando a necessidade de um gerenciamento de riscos efetivo para os projetos de DDS, é importante ressaltar que o paradigma qualitativo está sujeito às limitações humanas devido ao fato de utilizar informações baseadas na experiência de pessoas. Outro dado que deve ser mencionado é que o estudo analisou apenas uma empresa, o que pode dificultar a generalização de resultados.

Como trabalhos futuros, pode-se citar a repetição do estudo em outras empresas, a análise das técnicas de solução dos riscos, da qualidade do produto gerado, entre outras possibilidades.

REFERÊNCIAS

Audy, J. et Prikladnicki, R. (2008), Desenvolvimento distribuído de software: desenvolvimento de software com equipes distribuídas, Elsevier, Rio de Janeiro, RJ.

Boehm, B. W. (1991), “Software risk management: principles and practices”, Software, IEEE, Vol.8, No.1, pp.32-41.

Bubeck A., Weisshardt F., Sing T., Reiser U., Hagele M., Verl A. (2012), “Implementing best practices for systems integration and distributed software development in service robotics - The Care-O-bot robot family proceedings of International Symposium on System Integration, Fukuoka, Japão, Dec 16-18, 2012.

Carmel, E. et Agarwal, R. (2001), “Tactical approaches for alleviating distance in global software development”, Software, IEEE, Vol.18, No.2, pp.22-29.

Ebert, C., Murthy, B. K., Jha, N.N. (2008), “Managing risks in global software engineering: principles and practices”, proceedings of International Conference on Global Software Engineering, Bangalore, India, Ago 17-20, 2008.

Estler H.C, Nordio M., Furia C. A., Meyer B., Schneider J. (2012), “Agile vs. structured distributed software development: a case study”, proceedings of 7th International Conference on Global Software Engineering, Porto Alegre, RS, Ago 27-30, 2012.

Farias Junior I H., Azevedo R. R., Moura H. P., Silva D. S. M. (2012), “Elicitation of communication inherent risks in distributed software development”, proceedings of 7th International Conference on Global Software Engineering, Porto Alegre, RS, Ago 27-30, 2012.

Gil, A. C. (2002), Como elaborar projetos de pesquisa, Atlas, São Paulo, SP.

Herbsleb, J. et Moitra, D. (2001), “Global Software Development”, Software, IEEE, Vol.18, No.2, pp.16-20.

Herbsleb, J. et Mockus, A. (2003), “An empirical study of speed and communication in globally distributed software development”, IEEE Transactions on Software Engineering, Vol.29, No.6, pp.481-494.

Jimenez M., Piattini M., Vizcaíno A. (2009), “Challenges and improvements in distributed software development: a systematic review”, Advances in Software Engineering, Vol. 2009, pp. 1-14.

Kiel, L. (2003), “Experiences in distributed development: a case study”, proceedings of the International Workshop on Global Software Development, 2003, Portland.

Kwak, Y. H. et Stoddard, J. (2004), “Project risk management: Lessons learned from software development environment”, Technovation, Vol.24, No.11, pp. 915-920.

Perry, D. E., Staudenmayer, N. A., Votta, L. G. (1994), “People, organizations, and process improvement”, Software, IEEE, Vol.11, No.4, pp.36-45.

Persson, J. S., Mathiassen, L., Boeg, J., Madsen, T.S., Steinson, F. (2009), “Managing risks in distributed software projects: an integrative framework”, Engineering Management, IEEE Transactions on, Vol.56, No.3, pp.508-532.

Prikladnicki, R et Yamaguti, M. H. (2004), Risk Management in global software development: a position paper. proceedings of 3th International Workshop on Global Software Development, Edinburgh, Scotland, 24th May, 2004.

Project Management Institute – PMI (2008), Um guia do conjunto de conhecimento sem gerenciamentos de projetos: Guia PMBOK. 4 ed. Four Campus Boulevard, Pennsylvania.

Runerson, P. et Host, M. (2009), “Guidelines for conducting and reporting case study research in software engineering”, Empirical Software Engineering, Vol.14, pp. 131-164.

Sakthivel, S. (2007), “Managing risk in offshore systems development”, Communications of the ACM, Vol.50, No.4, pp. 69-75.

Steinmacher I., Chaves A. P., Gerosa M. A. (2013), “Awareness support in distributed software development: a systematic review and mapping of the literature”, Computer Supported Cooperative Work, Vol.22, No.2, pp. 113-158.

Wohlin C., Runerson P., Host M., Ohlsson B. R., Wesslen A. (2000), Experimentation in software engineering - an introduction, Kluwer Academic Publishers, Norwell, MA.

Yin, R. K. (2005), Estudo de caso: planejamento e métodos, Bookman, São Paulo, SP.