Embed Size (px)
Citation preview
Pós-Graduação em Ciência da Computação
“UM MAPEAMENTO SISTEMÁTICO DE GERENCIAMENTO DE PROJETOS NO
DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE”
Por
Juliana Braz da Costa
Dissertação de Mestrado Profissional
Universidade Federal de Pernambuco [email protected]
www.cin.ufpe.br/~posgraduacao
RECIFE, Abril/2014
Universidade Federal de Pernambuco
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
Juliana Braz Da Costa
“Mapeamento Sistemático de Gerenciamento de Projetos no
Desenvolvimento Distribuído de Software"
ORIENTADOR(A): Prof. Sérgio Castelo Branco Soares
RECIFE, ABRIL/2014
Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre Profissional em Ciência da Computação.
Costa, Juliana Braz da. Um mapeamento sistemático de gerenciamento de projetos no desenvolvimento distribuído de software / Juliana Braz da Costa. – Recife: O Autor, 2014. 205 f.: fig., tab., quadro. Orientador: Sérgio Castelo Branco Soares. Dissertação (Mestrado) - Universidade Federal de Pernambuco. CIN. Ciência da Computação, 2014. Inclui referências e apêndices. 1. Engenharia de software. 2. Engenharia de software-
Gerência. 3. Software - Desenvolvimento. I. Soares,
Sérgio Castelo Branco (orientador). II. Título.
005.1 (22. ed.) MEI 2014-78
Catalogação na fonte Bibliotecária Joana D’Arc L. Salvador, CRB 4-572
Dissertação de Mestrado Profissional apresentada por Juliana Braz da Costa à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, sob o título, “Um Mapeamento Sistemático de Gerenciamento de Projetos no Desenvolvimento Distribuído de Software”, orientada pelo Professor Sérgio Castelo Branco Soares e aprovada pela Banca Examinadora formada pelos professores:
_______________________________________________ Prof. André Luís de Medeiros Santos
Centro de Informática / UFPE
______________________________________________ Prof. Cristine Martins Gomes de Gusmão
Centro de Tecnologia e Geociências/ UFPE
_______________________________________________ Prof. Sérgio Castelo Branco Soares
Centro de Informática / UFPE
Visto e permitida a impressão. Recife, 29 de abril de 2014. ___________________________________________________ Profª. EDNA NATIVIDADE DA SILVA BARROS Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.
Dedico à minha família.
Agradecimentos Agradeço primeiramente a Deus, por ter me permitido e dado condução de ter realizado
esta etapa.
Aos meus pais, pelo apoio e compreensão, pela minha ausência em vários momentos
familiares.
Aos minhas irmãs Luciana e Tatiane, pelo carinho e pela força nos momentos mais difíceis.
Ao meu marido Jhordano, pela paciência, compreensão e companheirismo nas noite de
estudo, amor, Sabia que Te amo hoje!
Aos meu orientador Sérgio Soares, obrigada pela oportunidade e pelo empenho durante o
mestrado.
Ao meu Professor Milícias Alves de Almeida, pela revisão e incentivo.
Aos meus colegas: Lilan Gonçalves, Rosinete Libanio, Catarina Costa e Ivaldir Júnior.
Aos colegas de revisão: Alex Nery, Emanoel Barreiro, Eudis Teixeira e Nethus Pires.
“Acredite, você é capaz de realizar…”
Autor desconhecido
Resumo
As evidências encontradas na literatura científica e na prática industrial tem deixado claro que, gerenciamento de projetos é fundamental para o sucesso de projetos de software tradicionais. Devido ao aumento das práticas de desenvolvimento de software distribuídos na indústria, alguma variáveis como distância física, diferença temporal, interação entre equipe e comunicação, são acrescentados ao já complexo problema de gerenciar projetos de software. No entanto, guias e modelos existentes para desenvolvimento co-localizado, são usados em projetos de desenvolvimento distribuído de software. A partir desse contexto, esta pesquisa selecionou os trabalhos mais relevantes da área identificando os desafios, melhores práticas, ferramentas e modelos de apoio ao gerenciamento de projetos quando o desenvolvimento é distribuído. O método de pesquisa utilizado foi um estudo de mapeamento sistemático, em que quatro questões foram utilizadas para guiá-lo. Inicialmente identificou-se 2123 estudos e, após aplicação dos critérios de exclusão, restaram 373 estudos potencialmente relevantes. Após a leitura dos resumos e conclusões, destes, 224 estudos primários responderam as questões de pesquisa. Os selecionados, serviram como base para coleta dos dados, de forma a comparar os mais evidenciados com o estudo de Costa (2009), contribuindo assim à identificação dos desafios e soluções (melhores práticas, modelos e ferramentas) demonstrados na literatura. Palavras-‐chave: Gerenciamento de Projetos, Desenvolvimento Distribuído de Software, Mapeamento Sistemático.
Abstract
The evidence in the scientific literature and industrial practice has made it clear that project management is critical to the success of traditional software projects. Due to the increase in the practice of distributed software development in industry, some variables such as distance, time difference, communication and interaction between staff, are added to the already complex problem of managing software projects. However, guides and co-located existing development models are used in distributed software development projects. From this context, this study selected the most relevant work in the area identifying the challenges, best practices, tools and templates to support project management when the development is distributed. The method used was a systematic mapping study, in which four questions were used to guide it. Initially was identified 2123 studies and, after application of the exclusion criteria, 373 potentially relevant studies remain. After reading the summaries and conclusions, of these, 224 primary studies answered the research questions. The studies selected, this one served as the basis for data collection in order to compare more evident with the study by Costa (2009), thus contributing to the identification of the challenges and solutions (best practices, models and tools ) reported in the literature . Keywords: Project Management, Distributed Software Development, Systematic Mapping
Lista de Figuras
FIGURA 2.1 - RAZÕES QUE LEVAM AO DDS .................................................................... 25 FIGURA 2.2 - FORÇAS CENTRÍFUGAS ............................................................................. 29 FIGURA 2.3 - FORÇAS CENTRÍPETAS .............................................................................. 30 FIGURA 2.4 - GRUPOS DE PROCESSOS DE GERENCIAMENTO DE PROJETOS ....................... 39 FIGURA 2.5 - PROCESSO DO PRINCE2 ......................................................................... 40 FIGURA 2.6 - PLANEJAMENTO E GERENCIAMENTO DE PROJETOS DE SOFTWARE ................ 42 FIGURA 3.1 - ETAPAS DAS PESQUISA ............................................................................. 50 FIGURA 3.2 - PROCESSO DE SELEÇÃO DOS ESTUDOS PRIMÁRIOS ..................................... 59 FIGURA 3.3 - ANÁLISE DOS RESULTADOS ....................................................................... 63 FIGURA 4.1 - RELAÇÃO ENTRE AS QUESTÕES DE PESQUISA ............................................. 84 FIGURA 4.2 - ABORDAGEM PARA GERENCIAMENTO DE PROJETOS NO DDS ..................... 136
Lista de Quadros
QUADRO 4.1 - SELEÇÃO DOS ESTUDOS PRIMÁRIOS ......................................................... 69
Lista de Gráficos
GRÁFICO 2.1 - ÁREAS PROBLEMÁTICAS DE DDS ............................................................ 33 GRÁFICO 2.2 - ÁREAS ABORDADAS PELOS ESTUDOS PRIMÁRIOS ...................................... 34 GRÁFICO 3.1 - AVALIAÇÃO DA QUALIDADE ...................................................................... 62 GRÁFICO 4.1 - NÚMERO DE TRABALHOS RETORNADOS .................................................... 68 GRÁFICO 4.2 - NÚMERO DE ESTUDOS PRIMÁRIOS DAS FONTES AUTOMÁTICAS ................... 70 GRÁFICO 4.3 - NÚMERO DE ESTUDOS PRIMÁRIOS DA BUSCA MANUAL ............................... 71 GRÁFICO 4.4 - NÚMERO DE ESTUDOS PRIMÁRIOS ........................................................... 71 GRÁFICO 4.5 - NÚMERO DE ESTUDOS PRIMÁRIOS IDENTIFICADOS POR COSTA (2009) ....... 72 GRÁFICO 4.6 - SOMA DOS ESTUDOS PRIMÁRIOS IDENTIFICADOS POR COSTA (2009) E POR
ESTA PESQUISA ..................................................................................................... 72 GRÁFICO 4.7 - NÚMERO DE ESTUDOS PRIMÁRIOS DAS BUSCAS AUTOMÁTICAS POR BASE ... 73 GRÁFICO 4.8 - QUANTIDADE DE ESTUDOS PRIMÁRIOS COM QUALIDADE "BAIXA" ................ 73 GRÁFICO 4.9 - QUANTIDADE DE ESTUDOS PRIMÁRIOS COM QUALIDADE "MÉDIA" ............... 74 GRÁFICO 4.10 - QUANTIDADE DE ESTUDOS PRIMÁRIOS COM QUALIDADE "BOA" ................. 74 GRÁFICO 4.11 - QUANTIDADE DE ESTUDOS PRIMÁRIOS COM QUALIDADE "MUITO BOA" ...... 75 GRÁFICO 4.12 - QUANTIDADE DE ESTUDOS PRIMÁRIOS COM QUALIDADE "EXCELENTE" ...... 75 GRÁFICO 4.13 - PROPORÇÃO GERAL DA AVALIAÇÃO DA QUALIDADE ................................. 76
Lista de Tabelas
TABELA 2.1 - CARACTERÍSTICAS DO PMBOK® E PRINCE2 ........................................... 40 TABELA 3.1 - CLASSIFICAÇÃO DA PESQUISA ................................................................... 49 TABELA 3.2 - TERMOS E SINÔNIMOS .............................................................................. 54 TABELA 3.3 - STRINGS DE PESQUISA ............................................................................. 56 TABELA 3.4 - AVALIAÇÃO DA QUALIDADE ........................................................................ 60 TABELA 4.1 - DESAFIOS DO GERENCIAMENTO DE PROJETOS NO DDS .............................. 77 TABELA 4.2 - MELHORES PRÁTICAS PARA O GERENCIAMENTO DE PROJETOS NO DDS ....... 80 TABELA 4.3 - FERRAMENTAS DE APOIO AO DDS ............................................................. 81 TABELA 4.4 - MODELOS DE APOIO AO GERENCIAMENTO DE PROJETOS DISTRIBUÍDOS ........ 83 TABELA 4.5 - DESAFIOS E MELHORES PRÁTICAS ............................................................. 84 TABELA 4.6 - DESAFIOS E FERRAMENTAS ....................................................................... 87 TABELA 4.7 - DESAFIOS E MODELOS .............................................................................. 90 TABELA 4.8 - MELHORES PRÁTICAS E FERRAMENTAS ...................................................... 91 TABELA 4.9 - MELHORES PRÁTICAS E MODELOS ............................................................. 94 TABELA 4.10 - COMPARAÇÃO DE EVIDÊNCIAS ENCONTRADAS NA LITERATURA ................. 141
Sumário
1. INTRODUÇÃO ......................................................................................................... 15 1.1 INTRODUÇÃO ......................................................................................................... 16 1.2 ENFOQUE DO ESTUDO ............................................................................................ 17 1.3 OBJETIVOS ............................................................................................................ 18
1.3.1 Objetivo Geral ....................................................................................................................................... 18 1.3.2 Objetivos Específicos ............................................................................................................................. 18
1.4 ESTRUTURA DA DISSERTAÇÃO ................................................................................ 19 2. FUNDAMENTAÇÃO TEÓRICA ............................................................................... 20
2.1 DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE ...................................................... 21 2.1.1 Modelos de Negócio .............................................................................................................................. 22 2.1.2 Níveis de Dispersão ............................................................................................................................... 23 2.1.3 Razões que levam ao DDS ..................................................................................................................... 24 2.1.4 Desafios e Boas Práticas no DDS ........................................................................................................... 26
2.2 GERENCIAMENTO DE PROJETOS ............................................................................. 35 2.2.1 Projetos – Fases e Ciclo de Vida ............................................................................................................ 37 2.2.2 Modelos de Gerenciamento de Projetos ............................................................................................... 38 2.2.3 Gerenciamento de Projetos de Softwares ............................................................................................. 41 2.2.4 Gerenciamento de Projetos Distribuídos de Software ........................................................................... 42
2.3 ENGENHARIA DE SOFTWARE BASEADA EM EVIDÊNCIAS ............................................. 44 2.4 CONSIDERAÇÕES FINAIS DO CAPÍTULO ..................................................................... 47
3. MÉTODO DE PESQUISA ........................................................................................ 48 3.1 CLASSIFICAÇÃO DA PESQUISA ................................................................................. 49 3.2 CICLO DA PESQUISA ............................................................................................... 50
3.2.1 Mapeamento Sistemático ..................................................................................................................... 52 3.2.2 Métodos para Análise dos Resultados .................................................................................................. 63
3.3 CONSIDERAÇÕES FINAIS DO CAPÍTULO ..................................................................... 65 4. ANÁLISE DOS RESULTADOS ............................................................................... 66
4.1 RESULTADO DA EXTRAÇÃO E ANÁLISE DOS DADOS .................................................... 68 4.2 MAPEAMENTO DAS EVIDÊNCIAS ............................................................................... 76
4.2.1 Relacionando evidências ao gerenciamento do projeto no DDS ........................................................... 83 4.3 APRESENTAÇÃO DAS RESPOSTAS DAS EVIDÊNCIAS ................................................... 94
4.3.1 Q1: Desafios no gerenciamento de projetos no DDS ............................................................................. 95 4.3.2 Q2: Melhores Práticas no gerenciamento de projetos no DDS ........................................................... 112 4.3.3 Q3: Ferramentas de apoio ao gerenciamento de projetos no DDS ..................................................... 123 4.3.4 Q4: Modelos de apoio ao gerenciamento de projetos no DDS ............................................................ 130
4.4 ABORDAGEM PARA O GERENCIAMENTO DE PROJETOS NO DDS ................................ 135 4.5 DISCUSSÃO DOS RESULTADOS .............................................................................. 138 4.6 COMPARAÇÃO DOS RESULTADOS .......................................................................... 139 4.7 CONSIDERAÇÕES FINAIS ....................................................................................... 142
5. CONSIDERAÇÕES FINAIS ................................................................................... 144 5.1 LIMITAÇÕES DO ESTUDO ....................................................................................... 145 5.2 TRABALHOS FUTUROS .......................................................................................... 145 5.3 CONCLUSÕES ...................................................................................................... 146
REFERÊNCIAS ............................................................................................................ 148 APÊNDICES ................................................................................................................. 153
APÊNDICE A – ESTUDOS PRIMÁRIOS INCLUÍDOS ............................................................. 153 APÊNDICE B – ESTUDOS EXCLUÍDOS ............................................................................. 170 APÊNDICE C – PROTOCOLO DO MAPEAMENTO ............................................................... 183
Principais Abreviações
DDS – Desenvolvimento Distribuído de Software PMI – Project Management Institute PMBOK – Project Management Body of Knowlegde PRINCE2 – Project In Controlled Evironments ICGSE – International Conference on Global Software Engineering TI – Tecnologia da Informação IPMA – International Project Management Association PCSPM – Professional Competency Standards for Project Management AIPM – Australian Institute of Management CCTA – Central Computer and Telecommunications Agency OGC – Office of Government Commerce EBSE – Engenharia de Software Baseada em Evidências EBM –Medicina Baseada em Evidências RSL – Revisão Sistemática da Literatura EMS – Estudo de Mapeamento Sistemático GP – Gerenciamento de Projetos
15
Capítulo
1 1. Introdução
Este capítulo relata as principais motivações para realização deste trabalho, o
foco do estudo, os objetivos de pesquisa almejados e, finalmente, mostra como está
estruturado o restante desta dissertação.
16
1.1 Introdução
É cada vez mais significativo o número de empresas que estão distribuindo
seus processos de desenvolvimento de software ao redor do mundo. De acordo com
Prikladnicki (2003), o desenvolvimento distribuído tem atraído um maior volume de
pesquisa na área de Engenharia de Software. Os engenheiros de software têm
reconhecido a grande influência desta nova forma de trabalho e estão em busca de
modelos que facilitem o desenvolvimento de software com equipes geograficamente
dispersas.
Segundo Carmel (1999), as principais características que diferenciam o
desenvolvimento distribuído de software do desenvolvimento co-localizado são a
dispersão geográfica, a dispersão temporal e as diferenças culturais. Uma das
atividades afetadas por esta dispersão física da equipe é o gerenciamento de
projetos, considerado crítico para o sucesso de projetos co-localizados e é afetado
diretamente pelos desafios impostos pela distribuição.
De acordo com McBride (2005), com o entendimento das diferenças, é possível
estabelecer práticas de gerenciamento mais eficazes e direcionar para ferramentas
de gestão que possam auxiliar projetos distribuídos. Dentre essas diferenças,
identificar as dificuldades e as ações que possam apoiar o processo de
desenvolvimento distribuído pode ajudar os gerentes e as equipes a estarem mais
preparadas para os desafios do cenário distribuído de desenvolvimento.
Em um estudo recente, Costa (2009) propôs uma abordagem baseada em
evidências para apoiar o gerenciamento de projetos de desenvolvimento distribuído
de software, através de um revisão sistemática na literatura, que analisou 54
trabalhos publicados entre 1998 e 2009, nas seguintes fontes: IEEEXplore Digital
Library, ACM Digital Library, Elsevier ScienceDirect, El Compedex e na 4a edição da
conferência Internacional de Engenharia de Software Global - ICGSE 2009, dos
quais foram extraídos os maiores desafios, as melhores práticas, os modelos e as
ferramentas evidenciadas na literatura. A abordagem baseada em evidências
proposta pela autora, combina desafios e soluções (melhores práticas, modelos e
ferramentas).
Segundo Da Silva (2010) uma atualização e ampliação de uma revisão
sistemática pode ser por três maneiras complementares:
17
• A atualização temporal pode ser realizada para ampliar o prazo das
publicações de estudos primários, sem grandes mudanças no protocolo
de revisão original.
• Uma extensão de pesquisa pode ser realizada para ampliar o número
de fontes e as estratégias de busca (manual ou automatizado) no
mesmo período da revisão original só para aumentar a cobertura do
estudo original.
• Atualização temporal e extensão de busca podem ser combinados.
Pelas evidências coletadas pela pesquisa de Costa (2009) é possível perceber
que os temas apontados na abordagem para apoiar o gerenciamento de projetos no
desenvolvimento distribuído de software, devem ser verificados ou reafirmados,
devido ao aumento de estudos disponíveis na literatura, em relação a gerência de
projetos globais.
A motivação para o desenvolvimento deste trabalho é, portanto, e devido ao
crescimento de empresas que estão distribuindo cada vez mais seus processos de
desenvolvimento pelo mundo, utilizando-se do estudo prévio de Costa (2009), e
evoluí-lo. A quantidade de estudos disponíveis na literatura e o surgimento de novos
sinônimos relacionados ao termo de desenvolvimento distribuído de software – DDS,
como: Dispersed software development, Virtual software development, Dispersed
development, Dispersed software engineering, Virtual software engineering, Virtual
development, Virtual teams, Geographically dispersed development teams, além da
atualização temporal - no período de 2009 a 2012 - novas buscas em duas novas
fontes e, em todas as sete edições do ICGSE (International Conference on Global
Software Engineering).
1.2 Enfoque do estudo
Com o intuito de investigar, atualizar e ampliar a abordagem proposta por
Costa (2009) que tem como perguntas de pesquisa i) “o que muda no
gerenciamento de projetos de software quando o desenvolvimento é distribuído?” e
ii) “como apoiar a gerência nesse cenário de desenvolvimento?” esta pesquisa parte
para quatro questões de investigação mais específicas que possam responder essas
18
perguntas na busca por uma abordagem que apoie, com práticas e ferramentas
eficazes, o gerenciamento de projetos distribuídos.
• (Q1) Quais os principais desafios no gerenciamento de projetos de
desenvolvimento distribuído de software?
• (Q2) Quais as melhores práticas a serem adotadas no gerenciamento
de projetos de desenvolvimento distribuído de software?
• (Q3) Que ferramentas existem para apoiar as atividades de
gerenciamento de projetos no desenvolvimento distribuído de
software?
• (Q4) Que modelos existem para apoiar as atividades de gerenciamento
de projetos no desenvolvimento distribuído de software?
1.3 Objetivos
1.3.1 Objetivo Geral Este trabalho tem como objetivo descrever novos conhecimentos evidenciados
na literatura, a partir do trabalho de Costa (2009), sobre desafios e melhores práticas
para o gerenciamento de projetos em um cenário de desenvolvimento distribuído de
software, identificando modelos e ferramentas que possam apoiar a gerência.
1.3.2 Objetivos Específicos
• Realizar uma atualização da mapeamento sistemática sobre o
gerenciamento de projetos no desenvolvimento distribuído de software;
• Identificar evidências que apontem desafios, melhores práticas,
modelos e ferramentas de apoio ao gerenciamento no desenvolvimento
distribuído de software;
• Analisar e classificar de maneira sistemática os desafios, as melhores
práticas, os modelos e as ferramentas de suporte ao gerenciamento de
projetos de software em ambientes distribuídos;
19
• Identificar as evidências encontradas no mapeamento e realizar
comparação os resultados evidenciados na abordagem de Costa
(2009).
• Identificar as possíveis melhorias para apoiar o gerenciamento no
DDS.
1.4 Estrutura da Dissertação
Este trabalho está estruturado da seguinte maneira:
• Capítulo 2 – Fundamentação Teórica: é apresentado o referencial
teórico do assunto proposto por este trabalho.
• Capítulo 3 – Método de Pesquisa: é descrito a metodologia que foi
adotada para realizar esta pesquisa. É apresenta a classificação de
pesquisa com a apresentação de um quadro metodológico, as
principais etapas deste estudo, os procedimentos seguidos pelo
mapeamento sistemático, com apresentação do protocolo definido, a
forma como os dados foram extraídos, analisados e sintetizados.
• Capítulo 4 – Análise dos Resultados: São apresentados os
resultados do mapeamento sistemático. Inicia-se com as informações
gerais sobre o processo de pesquisa e seleção dos estudos primários
que participaram do estudo, posteriormente, as evidências encontradas
que serviram para responder as perguntas de pesquisa e por fim, a
proposta de uma abordagem que relaciona os resultados das questões
de pesquisa e uma análise dos resultados.
• Capítulo 5 – Considerações Finais: são apresentadas as limitações e
ameaças a validação do trabalho, propondo trabalhos futuros a partir
dos resultado e finalizando com as conclusões.
20
Capítulo
2 2. Fundamentação Teórica
Neste capítulo será apresentada a fundamentação teórica obtida por meio de
uma revisão bibliográfica tradicional (informal). Os tópicos que serão abordados são:
Desenvolvimento Distribuído de Software, Gerenciamento de Projetos e Engenharia
de Software Baseado em Evidências. As seções a seguir mostram em detalhes cada
tópico citado.
2.1 Desenvolvimento Distribuído de Software - apresenta conceitos sobre
Desenvolvimento Distribuído de Software (DDS), como: as principais características,
cenários, razões para o crescimento e pesquisa importantes para a área.
2.2 Gerenciamento de Projetos - apresenta conceitos referentes ao
Gerenciamento de Projetos, principais relacionamentos a definição de projetos,
gerenciamento de projetos de software, e modelos de gerenciamento.
2.3 Engenharia de Software Baseada em Evidências - apresenta os
conceitos sobre Engenharia de Software Baseada em Evidências, que tem nos
estudos de mapeamento Sistemático um método de procedimento.
2.4 Considerações finais do capítulo - apresenta um resumo, sobre o que foi
visto durante o capítulo.
21
2.1 Desenvolvimento Distribuído de Software
Nos últimos anos, o software se tornou um componente vital de negócios e o
sucesso de uma organização cada vez mais depende da utilização do software
como um diferencial competitivo. Ao mesmo tempo, a economia tem convertido os
mercados nacionais em mercados globais, criando novas formas de competição e
colaboração (HERBSLEB, 2003). Motivados principalmente pela globalização,
muitas empresas nas últimas décadas passaram a distribuir seus processos de
desenvolvimento em lugares diferentes, levando suas equipes a trabalharem de
forma distribuída.
Segundo Zanoni (2002), com a distribuição geográfica de recursos e
investimentos, surge uma nova tendência de desenvolvimento de software, em que
usuários e equipes de desenvolvimento estão em locais físicos diferentes, às vezes
com culturas diferentes, denominado Desenvolvimento Distribuído de Software
(DDS). O DDS, incluindo a terceirização, subcontratação e parcerias, tornou-se uma
realidade empresarial comum.
Muitas terminologias vem surgindo na literatura para caracterizar esse tipo de
desenvolvimento de software, como por exemplo: Distributed software development,
Global software development, Collaborative software development, Global software
engineering, Globally distributed work, Collaborative software engineering,
Distributed development, Distributed teams, Global software teams, Globally
distributed development, Geographically distributed software development, Offshore
software development, Offshoring, Offshore, Offshore, outsourcing, Dispersed teams,
Dispersed Software Development, Virtual Software Development, Dispersed
Development, Dispersed Software Engineering, Virtual Software Engineering, Virtual
Development, Virtual Teams, Geographically Dispersed Development Teams,
Dispersed software development, Virtual software development, Dispersed
development, Dispersed software engineering, Virtual software engineering, Virtual
development, Virtual teams, Geographically dispersed development teams, e, no
Brasil, sendo conhecido como: Desenvolvimento Distribuído de Software (DDS),
termo utilizado nesta pesquisa.
22
De acordo com Carmel (1999), as principais características que diferenciam o
desenvolvimento co-localizado do desenvolvimento distribuído são: distância (a
distância entre os desenvolvedores e entre os desenvolvedores e clientes),
diferenças de fuso horário e cultural (incluindo a língua, tradições, costumes,
comportamentos e normas). A literatura reconhece não só distância física, mas
também os seguintes tipos de distância: Temporal, cultural, organizacional
(diferentes culturas organizacionais envolvidas), e a distância das partes
interessadas (a quantidade de pessoas interessadas no projeto com diferentes
objetivos em mente).
Para Audy e Prikladnicki (2007), o desenvolvimento distribuído de software
ganha cada vez mais força, motivado por três fatores ligados ao ambiente de
negócios: a globalização, o crescimento da importância dos sistemas de informação
nas empresas e os processos de terceirização que geram o ambiente propício a
esse cenário de desenvolvimento. Mesmo com diversos fatores contribuindo para o
crescimento do DDS, assim como no desenvolvimento co-localizado, construir
software não é uma tarefa simples, e no cenário de desenvolvimento distribuído a
complexidade tende a aumentar. Prikladnicki (2003), afirma que o desenvolvimento
distribuído criou uma nova classe de problemas a serem resolvidos pelos
pesquisadores na área de Engenharia de Software. Este modelo de fazer software
está causando um grande impacto não apenas na indústria propriamente dito, mas
na maneira como os produtos estão sendo criados, modelados, construídos,
testados e entregues para os clientes.
Devido à distribuição, atividades relativamente simples, como identificar
módulos funcionalmente relacionados ou encontrar pessoas que são especialistas
em determinados aspectos do sistema tornam-se mais difíceis e demoradas
(OMORONYIA et al, 2007).
2.1.1 Modelos de Negócio O desenvolvimento distribuído de software é considerado uma aplicação de
grande abrangência, possuindo uma diversidade de conceitos que auxiliam sua
caracterização como a simples distribuição em um mesmo país ou uma distribuição
em países ou continentes. Dentro do contexto de desenvolvimento distribuído de
software, foram aplicados conceitos de equipes globais (MARQUARDT, 2001), e
23
organizações virtuais (KAROLAK, 1998), por exemplo, ampliando a extensão do
conhecimento envolvido.
A literatura na área de Engenharia de Software reconhece diversos termos
para caracterizar a distribuição da equipe de desenvolvimento e alguns desses
termos estão relacionados ao modelo de negócio da(s) organização(ões)
envolvida(s) no projeto. Audy e Prikladcnick (2007) apresentam uma classificação
quanto ao modelo de negócio:
§ Onshore Insourcing: departamento dentro da empresa ou uma
subsidiária da empresa no mesmo país. Nesse modelo, existe um
departamento dentro da própria empresa ou uma subsidiária da
empresa no mesmo país (onshore) que provê serviços de
desenvolvimento de software através de projetos internos (insourcing);
§ Offshore Insourcing: também é um departamento ou subsidiária da
empresa para prover serviços de desenvolvimento de software, mas
agora em um país diferente da matriz ou empresa contratada
(offshore);
§ Onshore Outsourcing ou Outsourcing: contratação de uma empresa
terceirizada (outsourcing) localizada no mesmo país da empresa
contratante. Nesse modelo, ambos os envolvidos (empresa contratante
e a terceirizada) se encontram no mesmo país (onshore);
§ Offshore Outsourcing ou Offshoring: contratação de uma empresa
terceirizada (outsourcing) localizada em um país diferente da
contratante (Offshore).
2.1.2 Níveis de Dispersão O processo de Desenvolvimento Distribuído de Software é possível caracterizar
o nível de dispersão dos diversos atores envolvidos no processo ao longo do projeto.
Audy e Prikladnicki (2007) caracterizam o nível de dispersão dos diversos
atores envolvidos no processo ao longo do projeto em quatro níveis: mesma localização, distância continental, distância nacional e distância global e
expõem que as dificuldades de um cenário com equipes co-localizadas podem ser
bem diferentes de um cenário com equipes em distância global descritos a seguir:
24
§ Mesma Localização Física: caso em que a empresa possui toda a
equipe em um mesmo local. Nesse caso, reuniões podem ocorrer sem
dificuldades e a equipe pode interagir estando fisicamente presente.
Não existem dificuldades como, diferenças de fuso horário e cultural.
§ Distância Nacional: caso em que a equipe está localizada dentro de
um mesmo país, podendo reunir-se em curtos intervalos de tempo.
Dependendo do país, pode haver diferenças culturais e de fuso horário.
§ Distância Continental: caso em que as equipes estão localizadas em
países diferentes, porém dentro do mesmo continente. Possíveis
encontros entre a equipe ficam mais difíceis de serem realizados face a
face, a diferença de fuso horário pode dificultar algumas interações.
§ Distância Global: caso em que as equipes estão em países diferentes
e em continentes diferentes, formando uma distribuição global.
Encontros físicos também se tornam difíceis, sem contar os fatores
como diferenças culturais, comunicação e fuso horário são cruciais
para o sucesso de projetos.
2.1.3 Razões que levam ao DDS O desenvolvimento de software global tornou-se uma alternativa estratégica de
crescimento das empresas. Com isso, alguns países não têm recursos suficientes
para a demanda de TI de produtos e serviços tornando uma regra para grandes
empresas o desenvolvimento de software distribuído. De acordo com estudos
realizados por Carmel (1999), Prikladnicki (2003) e Freitas (2005), alguns fatores
são citados como principais motivos do crescimento do DDS como demonstrado
também na Figura 2.1:
§ Necessidade de Recursos Globais para serem utilizados a qualquer
hora, inclusive profissionais qualificados em áreas especializadas;
§ Incentivos Fiscais para o investimento em pesquisas em informática;
§ Disponibilidade de Mão-de-obra especializada e de custos reduzidos
em países em desenvolvimento;
§ Vantagem De Estar Perto Do Mercado Local, incluindo o
conhecimento os clientes e as condições locais;
25
§ Rápidas formação de organizações e Equipes Virtuais para
explorar as oportunidades locais;
§ Grande Pressão para o desenvolvimento time-to-market (velocidade
no trabalho tempo entre a concepção e a comercialização do produto)
utilizando as vantagens do fuso horário diferente, no desenvolvimento
conhecido como follow-the-sun (24 horas contínuas); e,
§ Necessidade de Integrar Recursos Resultantes de Aquisição e Fusões Organizacionais;
Figura 2.1 - Razões que levam ao DDS
Lamersdorf e Münch (2009) realizaram uma pesquisa com profissionais com
experiência em DDS, e confirmaram algumas das razões apresentadas por
26
pesquisas anteriores. Segundo os autores, a maioria dos entrevistados afirmou que
a principal razão para desenvolverem de maneira distribuída, séria a redução nos
custos, principalmente com parceiros na China e Índia. Outra razão muito citada foi a
possibilidade de acesso a recursos globais, disponibilidade de diferentes talentos em
diferentes regiões.
É notável que as empresas queiram reduzir os custos, com as razões
mencionadas, no desenvolvimento e aproveitar as oportunidades do mercado locais,
as empresas querem ter equipes capacitadas, o que nem sempre é possível
encontrar em um único local.
2.1.4 Desafios e Boas Práticas no DDS Segundo Cockbum (2002), o processo de desenvolvimento de software é
tradicionalmente caracterizado por pessoas localizadas lado a lado, permitindo um
fluxo constante de informação e ideias. Herbsleb e outros autores (2001) afirmam
porém que quando a distância entre os desenvolvedores, ou equipes de
desenvolvedores, ultrapassa 30 metros a comunicação dentro da equipe se torna
equivalente a comunicação entre os desenvolvedores situados a milhares de
distância. A abordagem tradicional de desenvolvimento com equipes co-localizadas
tem se tornado cada vez mais custosa e menos competitiva. Com isso, a quantidade
de projeto distribuídos vem crescendo e com isso os problemas e desafios no
desenvolvimento de software são intensificados.
Segundo Carmel et al (2001), diversas organizações começaram a investir no
desenvolvimento distribuído, sobretudo, por conter custos e pela rápida
disponibilidade de recursos técnicos qualificados. Pichler (2007) acredita que muitas
equipes de projetos distribuídos mundialmente ainda são criadas como se todos os
membros da equipe podem estar distribuídas em países diferentes, até mesmo em
continentes diferentes com vários fusos, culturas e idiomas diferentes.
Para MacGregor e outros autores (2005), são de conhecimento dos
profissionais da área as dificuldades e baixas taxas de sucesso de projetos de
software com equipes co-localizadas. Acrescentando novas variáveis como,
distância, comunicação virtual, diferenças de fuso horário e culturais, não se
colabora muito para que essas taxas de sucesso melhorem.
27
Mesmo com diversos fatores contribuindo para o crescimento do DDS,
desenvolver software não é uma tarefa trivial e o cenário DDS adiciona novas
classes de problemas. Segundo Liang (2008), o tempo e a distância em um projeto
que trabalha de maneira distribuída é um dos grandes desafios para o sucesso, pois
significa mais infraestrutura e maior coordenação para estabelecer uma
comunicação eficaz dentro do projeto. Além disso, a distância física e as diferenças
culturais entre os membros são na sua maioria muito grandes e a comunicação pode
ser ineficiente, já que, uma vez que as pessoas que não estejam fisicamente ao seu
lado, são mais fáceis de serem ignoradas.
O DDS, ao lidar com dispersão geográfica, dispersão temporal e diferenças
culturais, amplia as dificuldades e desafios presentes no desenvolvimento
tradicional. Uma solução para esses desafios que a distribuição intensifica seria
evitar o desenvolvimento distribuído de software. Contudo, para organizações que
estão sempre em busca de vantagens competitivas em escala global, os benefícios
potenciais de desenvolvimento distribuído podem ser muito atraentes para
simplesmente serem ignorados (Mak, 2007). A literatura apresenta artigos
associados aos desafios que o desenvolvimento de software adiciona. Alguns
desses trabalhos são discutidos no Capítulo 3.
2.1.4.1 Carmel (1999)
Em seu trabalho, Carmel (1999) leva em conta os principais desafios e
características inerentes à formação de equipes globais. O autor sugere a existência
de cinco fatores que podem levar uma equipe distribuída ao fracasso: comunicação
ineficiente, falta de coordenação, dispersão geográfica, perda do espírito de equipe
e diferenças culturais, chamadas de força centrífuga. Também sugere, a existência
de seis fatores que podem levar a equipe ao sucesso: infraestrutura de
comunicação, arquitetura do produto, construção de uma equipe, metodologia de
desenvolvimento, tecnologia de colaboração e técnicas de gerência, chamadas de
força centrípeta. A Figura 2.2 ilustra as forças centrífugas e a Figura 2.3 as forças
centrípetas sugeridas por Carmel (1999).
28
Forças centrífugas
§ Comunicação Ineficiente: A dispersão das equipes expõe um
problema chave no desenvolvimento distribuído, ela impacta
diretamente na comunicação (formal, informal, assíncrona) de um time.
As pessoas deixam de se comunicar devido às dificuldades impostas, o
número de reuniões aumenta e a complexidade de coordená-las torna-
se maior.
§ Dispersão: para Carmel (1999), existem dois tipos de dispersão:
dispersão geográfica e dispersão temporal. A dispersão geográfica,
baseada na distância física entre os atores envolvidos em projetos
dispersos. Já a dispersão temporal, onde membros de uma equipe
estão dispersos no tempo pela diferença nos horários de trabalho,
fusos horários e/ou ritmos de trabalho que diminuam o tempo
disponível para interação síncrona.
§ Diferenças Culturais: a gestão da diversidade cultural é importante
para efetividade de uma equipe distribuída. De acordo com Carmel
(1999), as culturas diferem em muitas dimensões críticas, como a
necessidade de estrutura, atitudes com relação à hierarquia, senso de
tempo e estilo de comunicação.
§ Perda do Espírito de Equipe: com a falta de comunicação entre as
equipes nos corredores, nas salas de café e entre outros possíveis
áreas sociais da empresa, torna se difícil de manter um espírito de
equipe, em virtude da distância e as diferenças culturais das equipes.
§ Falta de Coordenação: coordenar uma equipe distribuída não é nada
fácil, problemas como: dificuldades culturais, língua e tecnologia estão
presente em todos os momentos da integração de tarefas.
29
Figura 2.2 - Forças centrífugas Fonte : Carmel (1999)
Forças Centrípetas
§ Arquitetura de Produto: para Carmel (1999), para resolver e reduzir
as dificuldades do DDS deve se basear a arquitetura de software no
princípio da modularidade, considerando a principal forma de resolver e
alocar tarefas complexas de forma distribuída; § Construção de Equipe: equipes de DDS necessitam de interação, ter
mecanismo de comunicação eficiente e ter uma visão compartilhada,
conhecendo os papéis e responsabilidades de cada um dentro do
projeto; § Técnicas de Gerência: uma adaptação nas técnicas de gerência de
projetos deve ser feito para utilizar em projetos distribuídos; § Tecnologia de Colaboração: são utilizadas para ampliar a
comunicação informal, possibilitando novas formas de comunicação
entre os membros da equipe;
30
§ Metodologia de Desenvolvimento: com a dispersão das equipes e a
falta de sincronização, pode prejudicar o projeto, é ideal que seja
seguida uma mesma metodologia para as equipes de projeto. § Infraestrutura de Comunicação: os ambientes de DDS necessitam de
conexões confiáveis, com alta qualidade, e de boa infraestrutura de
comunicação.
Figura 2.3 - Forças centrípetas Fonte: Carmel (1999)
2.1.4.2 Prikladnicki (2003)
Algumas das dificuldades de dimensões técnicas e não-técnicas encontradas
no desenvolvimento distribuído é listada por Prikladnicki (2003), como:
§ A Engenharia de Requisitos: os requisitos devem ser passados com
o maior nível de detalhes, sem dupla interpretação;
§ O Processo de Desenvolvimento de Software: nem sempre as
equipes estão ligadas por um mesmo processo, muitos problemas
podem surgir na gerência de projeto;
31
§ Gerência de Configuração: muitas vezes os artefatos não possuem a
mesma versão, nem o mesmo conteúdo nos diferentes locais onde o
projeto está sendo desenvolvido ao pouco investimento nesta área;
§ A Gestão de Conhecimento: dificuldades no sentido de compartilhar
informações em ambientes distribuídos devido ao pouco investimento
nesta área;
§ As Barreiras de Comunicação e Idioma: dificuldade devido à
diferenças de idioma, dificultam a comunicação frequentemente;
§ As Diferenças Culturais e Contextos: devido a distribuição da
equipe em países diferentes, surgem diversas dificuldades;
§ A Confiança: com a equipe distribuída não se cria respeito e
confiança entre os mesmos.
Prikladnicki (2003), baseado na literatura e em estudos de caso, propõe alguns
fatores críticos de sucesso e soluções em projetos distribuídos:
§ Gerenciamento de expectativas: definir claramente papéis e
responsabilidades dos integrantes das equipes;
§ Integração das Equipes: integração face a face entre as equipes, na
medida do possível;
§ Comunicação Aberta e feedback: boa infraestrutura de comunicação;
§ Processo de desenvolvimento de software: definição dos processos
e padrões de trabalhos;
§ Gerenciamento de riscos: identificação e ações de mitigação podem
minimizar diversas dificuldades;
§ Engenharia de requisitos: documentação e aprovação formais dos
artefatos de projeto;
§ Aquisição da confiança: treinamento, planejamento, entre outras
atividades de integração das equipes remotamente ou face a face,
quando possível visam principalmente à aquisição de confiança e o
conhecimentos dos participantes;
§ Treinamento: nivelamento do conhecimento, aprendizagem contínua;
§ Planejamento e engajamento: uma clara definição do planejamento
inicial e do engajamento das equipes no projeto é importante;
32
§ Infraestrutura: boa infraestrutura de comunicação e ferramentas de
suporte ao desenvolvimento.
Para o autor, o desenvolvimento distribuído é considerado mais complexo que
o desenvolvimento centralizado devido principalmente à falta de contato pessoal e a
obrigatoriedade de haver um relacionamento distribuído, aumentando a necessidade
de comunicação. Projetos distribuídos necessitam de um maior controle e,
consequentemente, de um maior investimento na gerência do projeto. Além disso,
gerenciar riscos nesse ambiente é uma tarefa essencial.
2.1.4.3 Komi-Sirviõ e Tihinen (2005)
Komi-Sirviö e Tihinen (2005) apresenta em seu trabalho uma pesquisa de
campo realizada em 2002 que contou principalmente com a participação de
empresas da Finlândia, mas também de outras da Holanda e dos Estados Unidos.
No total, foram 27 organizações consideradas sendo que 53% destas são empresas
com mais de 500 funcionários, 35% entre 50 e 500 funcionários e 13% com menos
de 50 funcionários. O objetivo da pesquisa foi o de levantar e compartilhar lições
aprendidas para obter um melhor entendimento da natureza do processo de
desenvolvimento de software quando realizado em um ambiente distribuído e dos
problemas que podem estar associados a tais processos.
Durante a pesquisa os participantes tinham a opção de escolher até oito áreas
de problemas diferentes no DDS. A lista de problemas foi construída a partir de uma
revisão da literatura. Ou seja, os entrevistados marcavam os problemas que eles
haviam enfrentado em seus projetos e também descreviam com mais detalhes estes
problemas. Também havia a possibilidade de identificar problemas não presentes na
lista, mais só dois participantes utilizaram esta opção. Além da descrição dos
detalhes dos problemas enfrentados, os participantes também descreveram as
soluções adotadas para superá-los, assim como fizeram uma auto-avaliação do
nível de sucesso destas soluções. O Gráfico 2.1 apresenta a distribuição das
respostas ao longo das oito áreas de problemas.
33
Gráfico 2.1 - Áreas problemáticas de DDS Fonte: Komi – Sirviö e Tihinem (2005)
Como podemos verificar no Gráfico 2.1 que mostra que a área mais
problemática está relacionada com ferramentas e ambientes de desenvolvimento de
software, mais especificamente com a incompatibilidade de ferramentas e versões
usadas por sites de desenvolvimento diferentes. Este problema é mais acentuado
em grandes organizações que empregam mais de 500 pessoas. Problemas de
comunicação aparentam ser extremamente comuns em todas as organizações, de
forma que esta área de problema foi classificada como a segunda. Contudo, uma
análise mais detalhada das respostas mostra que o papel da comunicação é ainda
maior do que aparenta ser inicialmente. Ao estudar as razões por trás de outros
problemas, a falta ou a baixa qualidade das comunicações é frequentemente
mencionada como áreas bastante problemática em projetos de desenvolvimento
distribuído de software, causando vários erros.
A pesquisa de Komi-Sirviö e Tihinen (2005) deixa evidente que
desenvolvimento distribuído de software com sucesso requer tanto Engenharia de
Software disciplinada e estruturada, como também soluções de gerenciamento,
considerando particularmente o gerenciamento das comunicações e um substituto
efetivo para a comunicação face a face.
81% 74%
67% 59%
52% 52%
33% 30%
11%
0% 10% 20% 30% 40% 50% 60% 70% 80% 90%
Ferram
entas d
e de
senvolvimen
to e
ambien
te
Comun
icação, con
tatos
Conh
ecim
ento de de
sign
Gerenciamen
to de projetos
Diferenças Culturais
Dispersão tempo
ral/
crescimen
to do orçamen
to
Gestão de prod
uto
Comun
icação, ferramen
tas
outros
34
2.1.3.4 Jiménez et al. (2009)
A revisão sistemática da literatura feita por Jiménez et al (2009), reuni os
desafios e possíveis melhorias para o desenvolvimento distribuído de software. Os
autores falam das vantagens que fomentam as empresas a distribuírem seus
processos de desenvolvimento, mas atentam para algumas desvantagens causadas
pela distância que separa as equipes de desenvolvimento. Um dos grandes desafios
e a coordenação e comunicação, já que os componentes do software são
provenientes de diferentes lugares, aumentando assim, a necessidade por
processos e ferramentas.
A questão de pesquisa que guiou a revisão sistemática foi: Quais são as
iniciativas realizadas em relação à melhoria do processo de DDS? Com a pesquisa
nas fontes de busca (ScienceDirect, Wiley Interscience, IEEE Digital Library, e ACM
Digital Library), o estudo chegou a 78 estudos primários. Todos os estudos
encontrados foram publicados entre 2000 e 2008. As áreas mais abordadas pelos
estudos primários são apresentada no Gráfico 2.2.
Gráfico 2.2 - Áreas abordadas pelos estudos primários Fonte: Jimenez et al., (2009)
A pesquisa feita por Jimenez et al. (2009), alguns temas merecem atenção
especial quando o desenvolvimento do software é distribuído. Os desafios e
43,500% 35,900%
5,400% 4,300% 7,600% 2,200% 1,100%
,00% 5,00% 10,00% 15,00% 20,00% 25,00% 30,00% 35,00% 40,00% 45,00% 50,00%
Controle do Processo,
Cron
ograma de
Tarefas
e Co
orde
nação de
Ferram
entas d
e Co
labo
ração, Técnicas
e Fram
eworks
Gestão de
Confi
guração
Sistem
as M
uld-‐agen
tes
Gestão de
Conh
ecim
ento
Detecção de De
feito
s
Gestão de Teste
35
propostas de melhorias identificados pela revisão sistemática são: (1) Comunicação;
(2) Awaness (Consciência de grupo); (3) Gestão de Configuração; (4) Gestão do
Conhecimento; (5) Coordenação; (6) Colaboração; (7) Gestão de Projeto; (8) Gestão
e Suporte ao processo; (9) Qualidade e Métricas; (10) Gestão de Riscos.
2.2 Gerenciamento de Projetos Gerenciamento de projeto ou gerência de projeto, segundo a PMI (Project
Management Institute), associação profissional desta área mais conhecida e
respeitada atualmente, é: “a aplicação de conhecimento, habilidades, ferramentas e
técnicas às atividades do projeto para atender aos seus requisitos” (PMI, 2008).
Para Kerzner (2004) o gerenciamento de projetos pode ser definido como “o
planejamento, organização, direção e controle de uma série de tarefas integradas de
forma que os objetivos do projeto sejam alcançados com sucesso e de acordo com
os interesses dos stakeholders”. Ele acrescenta dizendo que um bom gerenciamento
de projetos requer um intenso planejamento e coordenação.
Cleland Ireland (2002) citam que as principais funções da gerência de projetos
são: planejamento, organização, motivação, direção e controle, abrangendo quase
todos os aspectos da vida das pessoas, não só da vida profissional. As pessoas têm
planejado e gerenciado projetos desde o início dos tempos. Algumas pesquisas
indicam que os problemas de gerência de projetos em ambientes distribuídos não
diferem significativamente dos problemas no desenvolvimento tradicional (co-
localizado). Entretanto, no contexto distribuído é reforçado a importância das
técnicas formais de gerenciamento de projetos, como, por exemplo, as apresentadas
no PMBOK® (Audy e Prikladnicki, 2007).
Bruzzi (2008) descreve gerenciamento de projetos como “o planejamento,
programação e controle das atividades do referido projeto para atingir os seus
objetivos”.
Prikladnicki (2003) afirma que o gerenciamento de projetos de DDS exige uma
adaptação de algumas técnicas utilizadas em projetos co-localizados, de forma a
suportar e reduzir as dificuldades impostas pela dispersão da equipe.
36
Heldman (2006) afirma que “o gerenciamento abrange uma série de ferramenta
e técnicas utilizadas por pessoas para descrever, organizar e monitorar o andamento
das atividades do projeto”. Para Fame (1995) “o gerenciamento de projetos também
envolve negociação, solução de problemas, política, comunicação, liderança e
estudo da estrutura organizacional”.
Sendo gerenciamento de projetos o planejamento de atividades, cronograma,
custo, ferramentas, pessoas, tempo, prazos, gerenciando para atender aos
requisitos do projeto.
Em conformidade com o PMBOK® (Project Management Body of Knowlegde),
guia de responsabilidade do PMI (Project Management Institute), “o gerenciamento
de projetos consiste na aplicação de conhecimentos, habilidades, ferramentas e
técnicas às atividades do projeto a fim de atender aos requisites”. O guia acrescenta
que gerenciar um projeto inclui: (1) identificar das necessidades; (2) estabelecer
objetivos claros e alcançáveis; (3) balancear as demandas conflitantes de qualidade,
escopo, tempo e custo; (4) adaptar as especificações, os planos e a abordagem às
diferentes preocupações e expectativas das diversas partes interessadas (PMI,
2008).
Todos os trabalhos apresentam o seu ponto de vista e sua descrição de
gerenciamento de projetos, porém todos concordam que o gerenciamento de
projetos vem se fortalecendo cada vez mais. Para Torreão (2005), as organizações
estão conferindo maior importância a esta disciplina para minimizar o sucesso em
seus projetos. A importância de um bom gerenciamento de projetos é clara, muitos
pesquisadores e instituições têm se dedicado à pesquisa na área e na literatura
existem alguns trabalhos com resultados importantes, sendo o PMBOK®, uma das
referências mais conhecidas.
Um dos pilares fundamentais que existe dentro do gerenciamento de projetos é
os gerentes de projetos, que são os responsáveis pela administração dos processos
envolvidos e pela aplicação das ferramentas e técnicas necessárias ao cumprimento
das atividades do projeto. Para exercer esse papel de gerente deve ter algumas
habilidades para que o projeto seja eficaz, como: (1) uma boa comunicação, tanto
escrita como oral; (2) aptidões organizacionais e de planejamento; (3) habilidades
para elaboração de orçamentos; (4) habilidades para resolução de conflitos; (5)
37
habilidades de negociação e influência; (6) habilidades de liderança; (7) habilidades
para formação e motivação de equipes (Heldman, 2006).
As novas organizações estão descobrindo que a utilização do Gerenciamento
de Projetos traz muitos benefícios. Clientes esclarecidos exigem cada vez mais
produtos melhores e serviços mais rápidos. A coação para acompanhar a velocidade
do mercado demandam mais eficácia. Gerenciar projetos de forma profissional
encontrou seu lugar no campo empresarial competitivo e global de hoje (PMISP,
2013).
2.2.1 Projetos – Fases e Ciclo de Vida Projetos, segundo Heldman (2006), “um empreendimento temporário, com
datas de início e término definidos, e tem por finalidade a criação de um produto ou
a execução de um serviço específico e que está concluído quando suas metas e o
objetivos forem alcançadas e aprovadas pelos stakeholders”. Uma vez que em
qualquer empreendimento, as atividades precisam ser planejadas, programadas e
controladas durante a execução (Martins, 2007).
Para Kerzner (2004) um projeto é um esforço que tem um objetivo definido,
consome recursos e é realizado com restrições de tempo, custo e qualidade. Vargas
(2005) define um projeto como “um empreendimento não repetitivo, caracterizado
por uma sequência clara e lógica de eventos, com início e fim, que se destina a
atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de
parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade”.
Heldman (2006) sintetiza as características de um projeto como:
§ Os projetos são únicos;
§ Os projetos são de natureza temporária e têm datas definidas de início
e fim;
§ Os projetos estão concluídos quando as metas forem alcançadas ou
quando for decidido que o projeto não é mais viável.
§ Um projeto bem-sucedido é aquele que atende ou exerce as
expectativas dos stakeholders.
O desenvolvimento de projetos é dividido em processos gerenciais que,
geralmente, são agrupados em fases, assim facilitando o controle gerencial. Ao
38
conjunto lógico desta fase é dado o nome de ciclo de vida do projeto (Martins, 2007).
Quando se inicia um projeto deve ser definido quantas e quais fases existirão no
decorrer do projeto. De acordo com o PMBOK® não existe um ciclo de vida ideal
(PMI, 2008). Para Heldman (2006) um projeto terá no mínimo um estágio inicial ou
de iniciação, uma fase intermediária, ou várias, e uma fase final.
Todos os projetos tem início e fim definidos. Portanto as atividades
desenvolvidas no decorrer poderão variar muito, de acordo com o projeto. O ciclo de
vida oferece uma estrutura básica para o gerenciamento, independentemente do
trabalho específico envolvido (PMI, 2008). O PMBOK® contempla a seguinte
estrutura de um projeto:
§ Início do Projeto;
§ Organização e preparação;
§ Execução do trabalho do projeto; e,
§ Encerramento do projeto.
O ciclo de vida de um projeto de Tecnologia da Informação - TI, é composto por
fases, como: definição dos requisitos, projeto, implementação e teste. Vargas (2005)
afirma que conhecer o ciclo de vida proporciona uma série de benefícios para
quaisquer tipos de projetos e destaca alguns destes benefícios:
§ Permite determinar o que foi, ou não, feito pelo projeto.
§ Permite avaliar como o projeto está progredindo até o momento.
§ Permite que seja indicado qual o ponto exato em que o projeto se
encontra no momento.
2.2.2 Modelos de Gerenciamento de Projetos Duas grandes referências são reconhecidas pela literatura na área de
gerenciamento de projetos são: o guia PMBOK®, que se encontra na sua 5a edição,
lançada no início de 2014, e o PRINCE2 (Projects In Controlled Environments), mais
popular na Europa, que passou por algumas mudanças em 2009. Além desses dois
alguns outros modelos podem ser encontrados na literature como referências para o
gerenciamento de projetos, como: o ICB – IPMA (International Project Management
Association) Competence Baseline; o RCB, versão brasileira do IPMA Competence
39
Baseline; o PCSPM – (Professional Competency Standards for Project Management)
do AIPM (Australian Institute of Management), entre outros.
§ PMBOK®: foi criado em 1996, com base em trabalhos anteriores do
PMI, que começaram em 1986. Atualmente o PMI é a maior entidade
mundial sem fins lucrativos voltada ao gerenciamento de projetos, com
mais de 500.000 membros em 185 países (PMISP, 2013). O guia
PMBOK® objetiva reunir a melhores práticas em gerenciamento de
projetos, através da aplicação e da integração de melhores práticas
organizadas nos seguintes grupos de processos: iniciação,
Planejamento, execução, monitoramento e controle, e encerramento.
Apresentados na Figura 2.4. O guia é composto por um conjunto de
processos associados a 9 áreas de conhecimento: Integração, Escopo,
Tempo, Custo, Qualidade, Recursos Humanos, Comunicação, Riscos e
Aquisições (PMI, 2008).
Figura 2.4 - Grupos de processos de gerenciamento de projetos Fonte: Baseado em Figura do Guia PMBOK® (PMI)
§ PRINCE2: Criado em 1989 pela CCTA (Central Computer and
Telecommunications Agency), rebatizado de OGC (Office of
Government Commerce), o PRINCE2 (Projects IN Controlled
Environments) é uma abordagem, assim como o PMBOK®, baseada
40
em processos para a gestão eficaz de projetos. É um padrão
amplamente utilizado pelo Governo do Reino Unido e reconhecido
internacionalmente. A versão 2009 do modelo apresenta sete
processos e 40 sub-processos (PRINCE, 2013). Os processos são
apresentados na Figura 2.5.
Figura 2.5 - Processo do PRINCE2 Fonte: Baseado em Figura do PRINCE2 (PRINCE2, 2013)
O PMBOK® e o PRINCE2, apresentam meios para se gerenciar projetos de
maneira eficaz, através de processos, técnicas e ferramentas. Os modelos buscam
ajudar a gerência na condução dos projetos e tomada de decisões. O uso de um
modelo, não impede o uso do outro, os modelos são totalmente aderentes um ao
outro, assim, pode-se tirar vantagens das duas mais conhecidas e respeitadas
abordagens de gerenciamento de projetos do mundo atualmente. A Tabela 2.1
apresenta as principais características destes dois guias.
Tabela 2.1 - Características do PMBOK® e PRINCE2
Fonte: Costa (2009)
PMBOK® PRINCE2 Objetivo Identificar o subconjunto do
conjunto de conhecimento em gerenciamento amplamente reconhecido como boa prática. Além de fornecer e promover um vocabulário comum dentro da profissão.
Fornecer benefícios para os gestores e administradores de um projeto e para uma organização, reunindo as melhores práticas em gerenciamento de projetos.
Áreas de conhecimento/Temas
9 áreas de conhecimento Integração Escopo, Tempo, Custo Qualidade
7 Temas Negócio Organização Qualidade
41
Risco Comunicação Recursos Humanos Aquisição
Planos Riscos Mudanças Progresso
Processos 5 Grupos de Processos Iniciação Planejamento Execução Monitoramento e Controle Encerramento
7 Processos Iniciando o Projeto Dirigindo o Projeto Planejando o Projeto Controlando os Estágios Gerenciando as fronteiras dos estágios Gerenciando as entregas dos produtos Encerando o Projeto
Responsável PMI (Project Management Institute)
OGC (office of Government Commerce)
Certificação PMI – Project Management Professional CAPM – Certified Associate in Project Management PgMP – Program Management Professional
RINCE2 Foundation e PRINCE2 Practitioner
2.2.3 Gerenciamento de Projetos de Softwares A utilização de técnicas, práticas e ferramentas de gerenciamento de projetos
tornaram-se comuns na Engenharia de Software, devido a complexidade e os
desafios que envolvem o desenvolvimento de software. As empresas atuais tratam o
desenvolvimento de um software ou a disponibilização de um serviço como um
projeto, que precisa ser planejado, organizado, conduzido, monitorado e controlado.
Porém, gerenciar projetos de software não é uma tarefa simples. De acordo com
Zanoni (2004), boa parte dos fracassos, no que diz respeito aos projetos de
software, deve-se principalmente a problemas de administração ou gerenciamento
do processo de desenvolvimento de software.
Sommerville (2007), afirma que no passado, o gerenciamento de projetos é
uma parte essencial da Engenharia de Software, pois a mesma está sempre sujeita
às restrições de orçamento e de cronograma. Kerzner (2004) o gerenciamento de
projetos é uma parte essencial de Engenharia de Software, pois a mesma está
sujeita às restrições de orçamento e de cronograma.
O gerenciamento está presente em todas as fases do projeto, começando
antes do trabalho técnico, prossegue à medida que o software se desenvolve do
modelo conceitual para a realidade e encerra somente quando o software se torna
obsoleto e é aposentado. A Gerência é trabalhada em paralelo e em conjunto com a
42
metodologia de desenvolvimento de sistemas na medida da elaboração das fases,
subfases e produtos (Rezende, 2005).
Leite (2006), afirma que, o gerenciamento de projetos de software consiste no
planejamento (previsão das atividades, recursos, custos e prazos, além de
estimativas do produto e processo) e gerenciamento (controle de acordo com o que
foi planejado e verificação da qualidade do processo e do produto). A Figura 2.6
demonstra essas etapas.
Figura 2.6 - Planejamento e gerenciamento de projetos de software Fonte: Leite (2006)
Para ter uma gestão de projetos bem-sucedido Rezende (2005), sugeri
compreender: o escopo do trabalho a ser realizado, os riscos, custos e benefícios,
os recursos exigidos e respectivas responsabilidades, as tarefas a serem
executadas, os marcos, o esforço e custo despendido e a programação a ser
seguida. Muitos dos problemas que afetam os projetos de desenvolvimento de
software são de ordem gerencial e não técnicos (Branco e Belchior, 2002). Mas,
mesmo assim, diversas dificuldades tais como entregas fora do prazo estimulado ou
com custos superiores ao orçado são obstáculos no desenvolvimento de software
(Lopes et al., 2003).
2.2.4 Gerenciamento de Projetos Distribuídos de Software Quando se trata de gerenciamento de projetos no desenvolvimento de software
a atenção deve ser especial. Para Erickson e Ranganathan (2006), a distribuição
complica significativamente projetos de desenvolvimento de aplicações e aumenta a
43
necessidade de um forte gerenciamento de projetos, devido à redução da
comunicação, possibilidade de mal entendidos culturais e risco da falta de
compreensão do real objetivo do projeto.
No desenvolvimento de software distribuído, muitas variáveis são adicionadas
no ambiente no qual a equipe trabalha dispersa e isso precisa ser levado em
consideração para um melhor gerenciamento do projeto. O guia PMBOK® (PMI,
2008), discute algumas questões relacionadas a equipes virtuais, como por exemplo,
na área de conhecimento de gerenciamento de recursos humanos, umas das
técnicas de mobilização da equipe do projeto é o uso de equipes virtuais.
Ralyte et al., (2008) afirma que o tempo necessário para obter a resposta a
uma consulta de um parceiro distante é importante e pode reduzir a produtividade
quando a resposta é necessária para continuar o trabalho. O autor ainda relata,
quando a cultura empresarial não é assimilada e compreendida da mesma forma em
diferentes locais, a coordenação do trabalho pode sofrer algumas dificuldades.
Valores e normas podem variar de uma empresa para outra e, portanto, pode ser
uma fonte de dificuldades. Na pesquisa de Ralyte et al., (2008), vários colaboradores
entrevistados assinalaram que é mais fácil fazer uma pergunta a um colega que está
sentado próximo do que entrar em contato com uma pessoa situada em um local
distante. Segundo a pesquisa, garantir uma boa comunicação e um mínimo de
reuniões face a face é indispensável. Para Kiel (2003) diante de uma grande
distância é difícil sentir empatia por pessoas que você nem conhece, e é fácil ignorá-
las e desvalorizar as suas contribuições e habilidades.
Na literatura existem poucos estudos que tratam sobre gerenciamento de
projetos no desenvolvimento distribuído e estratégias de terceirização (Sutherland et
al., 2007). Equipes distribuídas necessitam ainda mais de documentação clara, de
fácil acesso e sempre atualizadas para o andamento do projeto Liang (2008). Na
execução de projetos distribuídos se faz necessárias informações relativas tanto ao
planejamento de cada projeto correlato individualmente, quanto informações
relativas ao projeto como um todo.
44
2.3 Engenharia de Software Baseada em Evidências O objetivo da Engenharia de Software Baseada em Evidência (Evidence-Based
Software Engineering – EBSE ) é prover meios pelos quais melhores evidências
provenientes da pesquisa possam ser integradas com experiência prática e valores
humanos no processo de tomada de decisão considerando o desenvolvimento e a
manutenção do software (Kitchenham et al., 2004). Para Monteiro (2010), a essência
do paradigma baseada em evidência é coletar e analisar sistematicamente todos os
dados disponíveis sobre determinado fenômeno para obter uma perspectiva mais
completa e mais ampla do que se pode captar através de um estudo individual.
À medida que uma área de pesquisa amadurece, existe uma tendência de
aumento acentuado no número de relatórios e resultados divulgados, tornando-se
importante uma síntese para fornecimento da visão geral na área (Petersen et al.,
2007). Muitos campos de pesquisa desenvolveram metodologias específicas para
tais estudos secundários, e eles têm sido amplamente utilizados, como é o exemplo
da medicina baseada em evidências (Evidence-based Medicine - EBM). Para
(Biochini et al., 2005), esse não era o caso da Engenharia de Software, até
recentemente. No entanto, tem surgido uma tendência no paradigma orientado a
evidência na Engenharia de Software (Kitchenham et al., 2004) levando ao aumento
no foco de novos métodos empíricos de pesquisa sistemática.
De acordo (Mafra et al., 2006), o trabalho de (Kitchenham et al., 2004) foi o
primeiro a estabelecer um paralelo entre Medicina e Engenharia de Software no que
diz respeito à abordagem baseada em evidências. (Kitchenham et al., 2004),
acreditam que a Engenharia de Software baseada em evidências pode fornecer
mecanismos necessários para ajudar o profissional a adotar tecnologias adequadas
e evitar as inadequadas, buscando as melhores práticas e procedimentos. Alguns
trabalhos sugerem que profissionais (pesquisadores) da Engenharia de Software
devem considerar o suporte do uso da Engenharia de Software baseada em
Evidências para melhorar suas decisões sobre quais tecnologias adotar (Dybå et al.,
2007, Kitchenham et al., 2004; Kitchenham, 2007; Oates E Capper, 2009;
Travassos, 2007).
Para (Biolchini et al., 2005), existem poucas iniciativas que questionem como a
Engenharia de Software poderia se beneficiar da adoção da abordagem baseada em
evidências. Isso pode ser constatado pelo ainda baixo número de trabalhos de
45
pesquisas que associem revisões sistemáticas à Engenharia de Software, diferente
de outras áreas, como a medicina.
A Engenharia de Software baseada em Evidência reúne e avalia evidências
existentes em uma tecnologia através de cinco etapas de uma metodologia (Dybå et
al., 2007):
1. Transforma o problema ou necessidade de informação em uma
questão de pesquisa;
2. Pesquisar na literatura por melhores evidências disponíveis para
responder às perguntas;
3. Avaliar criticamente as evidências, quanto a sua validade, impacto e
aplicabilidade;
4. Integrar as evidências avaliadas com experiências práticas, valores e
circunstâncias para tomar decisões;
5. Avaliar o desempenho das etapas de 1 a 4 e buscar formas de
melhorá-las.
As etapas dois e três são realizadas através de uma Revisão Sistemática da
Literatura (RSL) (Systematic Literature Review), que é um dos principais métodos
empregado pela EBSE. Sendo classificados como estudos secundários, já que,
dependem dos estudos primários conduzidos para poder agregar evidências e
construir conhecimento (Dybå, 2007; Kitchenham, 2007; Oates E Capper, 2009;
Biolchini, 2007). De acordo com (Petticrew and Roberts, 2005; O’Malley e Arksey,
2005) a literatura diferencia alguns tipos de RSLs:
§ Revisões Sistemáticas Convencionais da Literatura (RSL): (Petticrew, Roberts, 2006), agregam resultados sobre a efetividade de
um tratamento, intervenção ou tecnologia, e estão relacionados com
questões de pesquisa específicas, como: numa população P, a
intervenção I, num contexto c, é mais eficaz na obtenção de resultados
O do que uma intervenção C? (resultando em estrutura PICOC). § Estudos de Mapeamento Sistemático (EMS): (Arksey, O’Malley,
2005), que objetiva identificar todas as pesquisas relacionada a um
tema específico, ou seja, responder questões que são mais amplas
(exploratórias) sobre tendências de pesquisa. Uma questão típica que
são exploratórias: O que nós sabemos sobre o tópico T?
46
Kitchenham e Charters (2007) definiram uma revisão sistemática da literatura
“como um meio de identificar, avaliar e interpretar todas as evidências disponíveis
relevantes para uma questão específica, área temática, ou fenômeno de interesse”.
E mapeamento sistemático da literatura, “como uma ampla revisão dos estudos
primários em um tema específico que visa identificar as evidências disponíveis sobre
o tema”.
Segundo os autores, as principais diferenças entre revisão sistemática e
mapeamento sistemático são:
§ Estudo de mapeamento geralmente têm questões de pesquisa mais
amplas e, muitas vezes, tratam questões de múltiplas pesquisas;
§ Os termos utilizados no processo de busca nos estudos de
mapeamento são menos focados do que o processo de extração de
dados de revisões sistemáticas e, assim, é comum retornar com um
número muito grande de estudos. O objetivo é promover uma ampla
cobertura dos estudos de interesse;
§ O processo de extração de dados em estudos de mapeamento
também é muito mais amplo do que o processo de extração de dados
de revisões sistemáticas. Pode ser chamado de fase de classificação
ou categorização. O objetivo desta etapa é classificar documentos com
detalhes suficientes para responder às questões de pesquisa e
identificar estudos para revisões posteriores, sem ser uma tarefa
demorada;
§ A etapa de análise de um estudo sobre mapeamento é a síntese dos
dados para responder às questões de pesquisas colocadas. Não
incluem técnicas de análise aprofundada, como a meta-análise e de
síntese narrativa, mas totais e resumos. As representações gráficas
das distribuições dos estudos por tipo de classificação pode ser um
mecanismo de comunicação eficaz;
§ A divulgação dos resultados de um estudo de mapeamento pode ser
mais limitada do que para uma revisão sistemática.
Outra diferença é em relação aos processos de pesquisa, em um MS, é a
extração de dados que é mais abrangente e a síntese tem foco maior na
classificação e categorização dos resultados (Bailey et al., 2007), já que, em uma
47
revisão sistemática a extração é mais aprofundada e a síntese foca mais em
identificar as melhores práticas e sua efetividade (Petersen et al., 2007), além de
que se preocupa em estabelecer as condições da evidência em termos da avaliação
da qualidade dos estudos primários, o que aumenta a profundidade e,
consequentemente o esforço da revisão, Kitchenham, (2007). Preocupação essa
que um estudo de mapeamento não tem, pois não pretende avaliar a qualidade das
provas e, consequentemente, não pretende determinar se certos estudos fornecem
resultados robustos ou confiáveis (Arksey e O'Malley, 2005).
Além disso, um EMS pode ser visto como uma alternativa complementar a uma
revisão sistemática, no sentido de poder ser usado quando as evidências empíricas
em uma determinada área são poucas, ou se o tópico de pesquisa for muito amplo
para uma revisão sistemática ser viável (Kitchenham, 2007).
Com essas diferenças em mente, o procedimento adotado para condução
desse estudo de mapeamento sistemático foi baseado nos guias de Kitchenham
(2007) e Petersen et al. (2007), além dos trabalhos Bailey et al. (2007).
2.4 Considerações finais do capítulo Neste capítulo foi apresentado a fundamentação teórica utilizada durante esta
pesquisa. Foram apresentados os seguintes conceitos de: Desenvolvimento
Distribuído de Software, Gerenciamento de Projetos e Engenharia de Software
Baseada em Evidência e seus principais métodos de pesquisa.
48
Capítulo
3 3. Método de pesquisa
Neste capítulo é apresentada a metodologia científica que é indispensável em
um trabalho acadêmico, pois ela traz confiança aos estudo e torna possível sua
replicação, de forma independente, por outros pesquisadores. O capítulo apresenta
a abordagem metodológica usada nesta pesquisa que está organizada em duas
partes:
3.1 Classificação da Pesquisa - apresentação da classificação da pesquisa
juntamente com o quadro metodológico definido.
3.2 Ciclo da Pesquisa - descrição das etapas da pesquisa, bem como do
processo da revisão sistemático com todos os passos que se seguiram para a
realização da mesma.
3.3 Considerações finais do capítulo - apresenta um resumos dos tópicos
descrito no capítulo.
49
3.1 Classificação da pesquisa Esta pesquisa utiliza o método de abordagem indutiva baseado em dados de
natureza qualitativa, apoiada no método de procedimento estruturalista conforme
classificação de Marconi e Lakatos (2007), que afirmam que não há ciência sem o
emprego de métodos científicos. A Tabela 3.1 apresenta o quadro metodológico
dessa pesquisa.
Tabela 3.1 - Classificação da pesquisa Fonte: Elaboração própria
Quadro Metodológico Método de Abordagem Indutivo
Método de Procedimento Estudo de Mapeamento Sistemático Natureza das Variáveis Qualitativa
Para Marconi e Lakatos (2007) o método de abordagem indutiva é “um
processo mental por intermédio do qual, partindo de dados particulares,
suficientemente constatados, infere-se uma verdade geral ou universal, não contida
nas partes examinadas”. Considerando três elementos essenciais:
§ Observação dos fenômenos, com a finalidade de descobrir as causas
de sua manifestação;
§ Descoberta da relação, por intermédio da comparação, com a
finalidade de descobrir a relação constante existente entre ele; e,
§ Generalização da relação entre os fenômenos e fatores semelhantes.
O Método de Procedimento, que é a etapa mais concreta no processo de
investigação, definido para a pesquisa, é o Estudo de Mapeamento Sistemático
(Systematic Mapping Study), que é uma forma de avaliar e interpretar todas as
pesquisas disponíveis referentes a uma questão de investigação particular, área
temática ou fenômeno de interesse, parte do paradigma de práticas baseada em
evidências.
Por fim, no que diz respeito ao uso de pesquisa utilizando o método qualitativo,
Marconi e Lakatos, (2007) destacam que a escolha por esse tipo de método de
pesquisa possuem vantagens quando comparados aos demais. O mesmo procura
analisar e interpretar aspectos mais profundos, descrevendo a complexidade do
50
comportamento humano, fornecendo dessa forma, análises mais detalhadas sobre
as investigações, hábitos, atitudes, tendências de comportamento, etc. Sendo
capazes de promover informações mais exploratórias e ajudam a refinar as
proposições para que melhor se ajustem aos dados.
Contudo, o uso de pesquisa qualitativa também traz algumas desvantagens.
Dentre elas pode-se destacar o maior esforço que o pesquisador tem que despender
em relação ao método quantitativo e a maior dificuldade para resumir os achados.
Além disso, resultados qualitativos frequentemente são considerados mais
nebulosos do que os quantitativos, especialmente em comunidades mais técnicas
como na Engenharia de Software.
3.2 Ciclo da Pesquisa As etapas que compõem o ciclo de vida utilizado nesta pesquisa é ilustrado
pela Figura 3.1.
Figura 3.1 - Etapas das pesquisa Fonte - Costa (2009), baseado em Monteiro (2010)
Esta pesquisa iniciou-se com a realização de pesquisa bibliográfica tradicional
(revisão ad hoc com os principais temas que envolvem a pesquisa: DDS, GP e
Engenharia de Software Baseada em Evidências), apresentada na fundamentação
teórica, descrito no Capítulo 2 desse trabalho.
51
Em seguida foram observados e analisados trabalhos na literatura sobre o
gerenciamento de projetos no DDS, uma revisão sistemática da literatura realizada
por Costa (2009), teve como objetivo principal investigar “o que muda no
gerenciamento de software quando o desenvolvimento é distribuído?” e “como
apoiar a gerência nesse cenário de desenvolvimento?”, identificando os maiores
desafios, as melhores práticas, os modelos e as ferramentas evidenciados na
literatura, com a leitura do título, resumo e conclusão dos estudos potencialmente
relevantes, e utilizando-se os critérios de inclusão e exclusão, chegou-se a 54
estudos primários, sobre quatro questões de investigação, publicados entre os
períodos de 1998 a 2009, estes estudos foram extraídos de quatro fontes de busca
automática: IEEEXplore Digital Library, ACM Digital Library, Elsevier ScienceDirect,
El Compedex e uma busca manual, na 4a edição da conferência Internacional de
Engenharia de Software Global - ICGSE 2009.
A atualização e ampliação de uma revisão sistemática pode ser por três
maneiras complementares de acordo com Da Silva (2010):
§ A atualização temporal pode ser realizada para ampliar o prazo das
publicações de estudos primários, sem grandes mudanças no protocolo
de revisão original.
§ Uma extensão de pesquisa pode ser realizada para ampliar o número
de fontes e as estratégias de busca (manual ou automatizado) no
mesmo período da revisão original só para aumentar a cobertura do
estudo original.
§ Atualização temporal e extensão de busca podem ser combinados.
A partir do estudo, um protocolo foi construído e executado com o objetivo de
ampliar o trabalho de Costa (2009), através de um mapeamento sistemático, para
cobrir o período de 2009 a 2012 nas 4 fontes de busca realizada pelo estudo da
autora Costa, e em duas fontes: Elsevier Scopus e Springer Link, entre os períodos
de 1997 a 2012, e nas sete edições do ICGSE (International Conference on Global
Software Engineering). Analisando a qualidade, e a cobertura de publicações de
trabalhos que descreve abordagens que apoie com práticas e ferramentas eficazes
o gerenciamento de projetos de software quando o desenvolvimento e distribuído.
Além da atualização temporal, novos sinônimos relacionado ao termo ao
“Desenvolvimento Distribuído de Software” tem surgido. Com a ajuda de um
52
especialista oito novos sinônimos foram encontrados na literatura, e acrescentados
a string de busca do protocolo. Sendo os seguintes termos: Dispersed software
development, Virtual software development, Dispersed development, Dispersed
software engineering, Virtual software engineering, Virtual development, Virtual
teams, Geographically dispersed development teams. O protocolo completo é
apresentado resumidamente nesse capítulo e por completo no Apêndice C desse
trabalho.
Por fim, o relatório do mapeamento escrito, e desta forma, visa prover uma
atualização e contribuição científica com a agregação de conhecimento
evidenciados na literatura para o gerenciar projetos em desenvolvimento de software
distribuído.
3.2.1 Mapeamento Sistemático Esta pesquisa conduziu o mapeamento com o objetivo de encontrar e analisar
trabalhos primários relevantes e reconhecidos na área de gerenciamento de projetos
no DDS, que pudesse responder as questões de pesquisa. Nesta seção são
apresentados tópicos do protocolo de pesquisa que guiou o estudo. O protocolo por
completo se encontra no Apêndice C desse trabalho.
Questão de pesquisa
Com o intuito de investigar, atualizar e ampliar a abordagem proposta por
Costa (2009) que tem como perguntas de pesquisa i) “o que muda no
gerenciamento de projetos de software quando o desenvolvimento é distribuído?” e
ii) “como apoiar a gerência nesse cenário de desenvolvimento?” esta pesquisa parte
para quatro questões de investigação mais específicas, que são equivalente a da
revisão de Costa (2009), para responder essas perguntas na busca por uma
abordagem que apoie, com práticas e ferramentas eficazes, o gerenciamento de
projetos distribuídos.
§ (Q1) Quais os principais desafios no gerenciamento de projetos de
desenvolvimento distribuído de software?
§ (Q2) Quais as melhores práticas a serem adotadas no gerenciamento
de projetos de desenvolvimento distribuído de software?
53
§ (Q3) Que ferramentas existem para apoiar as atividades de
gerenciamento de projetos no desenvolvimento distribuído de software?
§ (Q4) Que modelos existem para apoiar as atividades de gerenciamento
de projetos no desenvolvimento distribuído de software?
Escopo das Questões
Visando delinear o escopo da pesquisa e de identificar os elementos que
vieram a fazer parte das questões de pesquisa, foi utilizado uma estrutura
recomendada por Kitchenham (2007), que considera as questões de pesquisa a
partir da seguinte estrutura PICOC (Population, Intervention, Context, Outcomes and
Comparison):
Q1:
§ População (Population): Projetos de desenvolvimento distribuído de
software.
§ Intervenção (Intervention): Gerenciamento de projetos.
§ Resultado (Outcomes): Desafios no gerenciamento de projetos.
Q2:
§ População (Population): Projetos de desenvolvimento distribuído de
software.
§ Intervenção (Intervention): Práticas de gerenciamento de projetos.
§ Resultado (Outcomes): Melhor Gerenciamento de projetos.
Q3:
§ População (Population): Projetos de desenvolvimento distribuído de
software.
§ Intervenção (Intervention): Ferramentas.
§ Resultado (Outcomes): Apoiar o gerenciamento de projetos.
Q4:
§ População (Population): Projetos de desenvolvimento distribuído de
software.
54
§ Intervenção (Intervention): Modelos.
§ Resultado (Outcomes): Apoiar o gerenciamento de projetos.
O item comparação (Comparison) não foi utilizado, uma vez que o estudo não
realiza comparações entre os mecanismos para guiar estudos empíricos. O item da
estrutura denominado contexto (Context) é normalmente utilizado para definir o
contexto que ocorre a comparação. Portanto, aqui será utilizado para definir o
contexto admitido para os mecanismos encontrados.
Estratégia de Busca
A construção das Strings de busca utilizada nas bibliotecas digitais
selecionadas seguiu uma estratégia baseada em Kitchenham (2007), que consiste
nos seguintes passos:
§ Derivar a partir das questões de pesquisa as principais palavras-chaves
a partir da identificação da população, intervenção, comparação
(quando for o caso), resultados e contexto;
§ Procurar por palavras chaves em artigos relevantes já consultados em
uma revisão informal;
§ Identificar sinônimos e termos alternativos as palavras chaves;
§ Consultar especialistas na área;
§ Usar o conector booleano OR para incorporar palavras alternativas e
sinônimas;
§ Usar o conector booleano AND para ligar palavras chaves;
§ Verificar a string de busca construída realizando buscas piloto e
comparando os resultados obtidos com uma lista de estudos primários
já conhecidos;
Como resultado da estratégia supracitados os seguintes termos e sinônimos
estão identificados na Tabela 3.2.
Tabela 3.2 - Termos e sinônimos Fonte: Elaboração própria
Termos Sinônimos Desenvolvimento Distribuído de Software
Distributed software development Global software development
55
Collaborative software development Global software engineering Globally distributed work Collaborative software engineering Distributed development Distributed teams Global software teams Globally distributed development Geographically distributed software development Offshore software development Offshoring Offshore Offshore outsourcing Dispersed teams Dispersed software development Virtual software development Dispersed development Dispersed software engineering Virtual software engineering Virtual development Virtual teams Geographically dispersed development teams
Gerenciamento de Projetos Project management, Approach Desafios Challenge
Difficult Critical Factor Problem
Melhores Práticas ou Lições Aprendidas Practice Best practice Good Practice Lesson Learned Success Factor
Ferramentas Tool Software Program System
Modelos Model Process Framework Method Technique Methodology
As quatro strings de busca geradas para responder as questões de pesquisa
deste mapeamento Sistemática, estão listadas a seguir na Tabela 3.3.
56
Tabela 3.3 - Strings de pesquisa Fonte: Elaboração própria
Strings da pesquisa
Para Q1
(“Project Management”) AND (“Distributed software development” OR “Global software development” OR “Collaborative software development” OR “Global software engineering” OR “Globally distributed work” OR “Collaborative software engineering” OR “Distributed development” OR “Distributed teams” OR “Global software teams” OR “Globally distributed development” OR “Geographically distributed software development” OR “Offshore software development” OR Offshoring OR Offshore OR “Offshore outsourcing” OR “Dispersed teams” OR “Dispersed Software Development” OR “Virtual Software Development” OR “Dispersed Development” OR “Dispersed Software Engineering” OR “Virtual Software Engineering” OR “Virtual Development” OR “Virtual Teams” OR “Geographically Dispersed Development Teams” ) AND ( “Challenge” OR “Difficult” OR “Critical Factor” OR “Problem” )
Para Q2
(“Project Management”) AND (“Distributed software development” OR “Global software development” OR “Collaborative software development” OR “Global software engineering” OR “Globally distributed work” OR “Collaborative software engineering” OR “Distributed development” OR “Distributed teams” OR “Global software teams” OR “Globally distributed development” OR “Geographically distributed software development” OR “Offshore software development” OR Offshoring OR Offshore OR “Offshore outsourcing” OR “Dispersed teams” OR “Dispersed Software Development” OR “Virtual Software Development” OR “Dispersed Development” OR “Dispersed Software Engineering” OR “Virtual Software Engineering” OR “Virtual Development” OR “Virtual Teams” OR “Geographically Dispersed Development Teams”) AND (“Practice” OR “Best practice” OR “Good Practice” OR “Lesson” OR “Learned” OR “Success Factor” )
Para Q3
(“Project Management”) AND (“Distributed software development” OR “Global software development” OR “Collaborative software development” OR “Global software engineering” OR “Globally distributed work” OR “Collaborative software engineering” OR “Distributed development” OR “Distributed teams” OR “Global software teams” OR “Globally distributed development” OR “Geographically distributed software development” OR “Offshore software development” OR Offshoring OR Offshore OR “Offshore outsourcing” OR “Dispersed teams” OR “Dispersed Software Development” OR “Virtual Software Development” OR “Dispersed Development” OR “Dispersed Software Engineering” OR “Virtual Software Engineering” OR “Virtual Development” OR “Virtual Teams” OR “Geographically Dispersed Development Teams”) AND (“Tool” OR “Software” OR “Program” OR “System”)
Para Q4
(“Project Management”) AND (“Distributed software development” OR “Global software development” OR “Collaborative software development” OR “Global software engineering” OR “Globally distributed work” OR “Collaborative software engineering” OR “Distributed development” OR “Distributed teams” OR “Global software teams” OR “Globally distributed development” OR “Geographically distributed software development” OR “Offshore software
57
development” OR Offshoring OR Offshore OR “Offshore outsourcing” OR “Dispersed teams” OR “Dispersed Software Development” OR “Virtual Software Development” OR “Dispersed Development” OR “Dispersed Software Engineering” OR “Virtual Software Engineering” OR “Virtual Development” OR “Virtual Teams” OR “Geographically Dispersed Development Teams”) AND (“Model” OR “Process” OR “Framework” OR “Method” OR “Technique” OR “Methodology”)
Processo de Busca
O processo que foi usado para procurar por estudos primários incluindo buscas
automatizadas através de engenhos de busca das bibliotecas digitais, onde foram
utilizadas as strings de busca formuladas. Este processo de busca também foi
executado de forma manual no periódico da área, com o objetivo de ampliar a
cobertura da pesquisa e dar mais segurança ao pesquisador. Os critérios para a
seleção das fontes foram:
§ Disponibilidade de consultar os artigos na web;
§ Presença de mecanismo de busca usando palavras-chave; e,
§ Importância e relevância das fontes.
As bibliotecas digitais utilizadas na busca dos estudos primários são listadas a
seguir:
§ IEEEXplore Digital Library (httt://ieeexplore.ieee.org)
§ ACM Digital Library (http://portal.acm.org)
§ Elsevier ScienceDirect (http://www.sciencedirect.com)
§ EI Compendex (http://www.engineeringvillage2.org)
§ Elsevier Scopus (http://www.scopus.com/home.url)
§ Springer Link (http://link.springer.com)
Os periódicos utilizados na busca manual:
§ 1a edições do ICGSE - International Conference on Global Software
Engineering
§ 2a edições do ICGSE - International Conference on Global Software
Engineering
58
§ 3a edições do ICGSE - International Conference on Global Software
Engineering
§ 4a edições do ICGSE - International Conference on Global Software
Engineering
§ 5a edições do ICGSE - International Conference on Global Software
Engineering
§ 6a edições do ICGSE - International Conference on Global Software
Engineering
§ 7a edições do ICGSE - International Conference on Global Software
Engineering
Critérios de Exclusão dos Estudos
A partir da análise do título, palavras-chave e resumo, foram excluídos os
estudos que se enquadrem em qualquer dos casos:
a) Estudos que não tem como foco principal ou não citam Dificuldades,
Fatores Críticos, Desafios e Problemas em projetos de
Desenvolvimento Distribuído de Software relacionados ao
gerenciamento;
b) Estudos que não apresentam como foco principal ou não citam as Boas
Práticas, Lições Aprendidas e Fatores de Sucesso em projetos de
Desenvolvimento Distribuído de Software relacionados ao
gerenciamento;
c) Estudos que não apresentam como foco principal ou não citam
Modelos, Processos, Técnicas, Metodologias e Ferramentas de apoio
ao Gerenciamento de Projetos no Desenvolvimento Distribuído de
Software;
d) Estudos claramente irrelevantes para a pesquisa, de acordo com as
questões de investigação levantadas;
e) Estudos Repetidos: se determinado estudo estiver disponível em
diferentes fontes de busca, somente a primeira pesquisa será
considerada;
59
f) Estudos Duplicados: caso dois trabalhos apresentem estudos
semelhantes, apenas o mais recente e/ou o mais completo será
incluído, a menos que tenham informação complementar;
g) Estudos que apresentem texto, conteúdo e resultados incompletos, ou
seja, trabalhos com resultados não concluídos não serão aceitos.
h) Estudos publicados em língua diferente do Inglês.
i) Estudos que estavam entre os estudo primários de Costa (2009).
Processo de Seleção dos Estudos Primários
Segundo Kitchenham (2007), as buscas iniciais retornam uma grande
quantidade de estudos que não são relevantes, não respondem às questões ou
mesmo não tem relação com o tópico em questão. Logo, estudos totalmente
irrelevantes são descartados no início. A Figura 3.2 apresenta as etapas do
processo de seleção dos estudos primários.
Figura 3.2 - Processo de seleção dos estudos primários Fonte – Elaboração própria, baseado em Costa (2009)
ETAPA 1 – Incialmente realiza - se as buscas para identificar os potenciais estudos primários e a partir da leitura dos títulos dos trabalhos que a pesquisa retorna e palavras-chave, excluem trabalhos que claramente são irrelevantes para as questões investigadas.
ETAPA 3 - A partir da lista unificada com os potenciais candidatos a estudos primários, todos os trabalhos são avaliados por dois ou mais pesquisadores, mediante a leitura do resumo e conclusão, considerando-se os critérios de exclusão, para então chegar a uma lista final de estudos primário.
ETAPA 2 – Listar os potenciais estudos primários;
ETAPA 4 - Os estudos incluídos são documentados através de formulários, assim como todos os trabalhos excluídos e o critério que definiu sua exclusão. Posteriormente, cada estudo primário e lido e através de formulários a extração dos dados e avaliação da qualidade dos trabalhos é realizada.
Etapas do Processo de Seleção dos Estudos Primários
60
Avaliação da Qualidade
Kitchenham (2004), em adição aos critérios de exclusão, é considerado
importante avaliar a qualidade dos estudos primários. Apesar de não existir uma
definição universal do que seja qualidade de estudo, a maioria dos checklists
incluem questões que objetivam avaliar a extensão em que o viés é minimizado e a
validação interna e externa são maximizadas Khan et al. (2001); Kitchenham (2007).
Algumas questões foram definidas, para a realização da avaliação da
qualidade dos estudos primários, as mesmas estão disponíveis no formulário de
extração dos dados, que se encontra na Seção C5 do Apêndice C, e podem ser
visualizadas na Tabela 3.4. Entre os critérios de avaliação, existem os que deverão
ser aplicados a todos os tipos de estudos e outros que são específicos para cada
tipo de estudo:
§ Estudos Experimentais - são aqueles baseados em evidências
diretas ou experimentais; Os métodos para estudos experimentais são
classificados por Easterbrook (2007) como: Experimentos Controlados,
Estudos de Caso, Pesquisa de Campo, Etnografia e Pesquisa-Ação.
§ Estudos Teóricos - são estudos conceituais e baseados em um
entendimento de uma área, referenciando outros trabalhos;
§ Revisão Sistemática da Literatura - avaliam estudos primários
através de um processo rigoroso;
§ Relatos de Experiência Industrial – apresentam um estudo baseado
na experiência prática na indústria.
Tabela 3.4 - Avaliação da qualidade Fonte - Costa (2009)
Item Critérios de Qualidade Valores Introdução/Planejamento
1 Os objetivos ou questões do estudo são claramente definidos (incluindo justificativas para a realização do estudo)?
2 O tipo de estudo está definido claramente? Desenvolvimento
3 Existe uma clara descrição do contexto no qual a pesquisa foi realizada?
4 O trabalho é bem/adequadamente referenciado (apresenta trabalhos relacionados/semelhantes e baseia-se em modelos e teorias da literatura)?
Conclusão 5 O estudo relata de forma clara e não ambígua os resultados? 6 Os objetivos ou questões do estudo são alcançados? Critério Específico para estudos Experimentais
61
7 Existe um método ou um conjunto de métodos descrito para a realização do estudo?
Critério Específico para estudos Teóricos 7 Existe um processo não tendencioso na escolha dos estudos? Critério Específico para Revisões Sistemáticas
7 Existe um protocolo rigoroso, descrito e seguido? Critério Específico para Relato de Experiência Industrial
7 Existe uma descrição sobre a(s) organização(ões), equipe(s), projeto(s) e distribuição envolvida?
Critérios para as Questões de Investigação (Q1, Q2 e Q3 e Q4)
8 O estudo lista primária ou secundariamente dificuldades, desafios ou problemas em projetos de DDS relacionados ao gerenciamento?
9 O estudo lista primária ou secundariamente boas práticas, lições aprendidas ou fatores de sucesso em projetos de DDS relacionados ao gerenciamento?
10 O estudo apresenta Modelos, Processos, Métodos, Técnicas, Metodologias ou Ferramentas de apoio ao gerenciamento de projetos no DDS?
TOTAL
Além de perguntas relacionadas à realização e resultados de cada trabalho
avaliado, isto é, como o estudo foi conduzido, três perguntas relacionadas às
questões de investigação são adicionadas, no intuito de verificar o quanto cada
estudo atende aos objetivos desta pesquisa. Como as questões são semelhantes e
complementares, um mesmo trabalho pode apresentar resultados para as quatros
questões de pesquisa e assim obter bons conceitos nos três critérios.
Ao realizar a avaliação de qualidade dos estudos é usado a escala Likert-5,
que permite respostas gradativas. O pesquisador pode usar os seguintes níveis de
concordância ou discordância (concordo totalmente, concordo parcialmente, neutro,
discordo parcialmente e discordo totalmente). Para a avaliação, devem ser
considerado o seguinte:
§ Concordo totalmente (4): deve ser concedido no caso em que o
trabalho apresente no texto os critérios que atendam totalmente a
questão;
§ Concordo parcialmente (3): deve ser concedido no caso em que o
trabalho atenda parcialmente aos critérios da questão;
§ Neutro (2): deve ser concedido no caso em que o trabalho não deixe
claro se atende ou não a questão;
§ Discordo parcialmente (1): deve ser concedido no caso em que os
critérios contidos na questão não são atendidos pelo trabalho avaliado;
§ Discordo totalmente (0): deve ser concedido no caso em que não
existe nada no trabalho que atende aos critérios de questão.
62
Ao avaliar um estudo primário, o mesmo pode se enquadrar em 5 (cinco) níveis
de qualidade, conforme classificação de Beecham et al. (2007), a partir dos valores
finais da avaliação de cada estudo, conforme apresentado no Gráfico 3.1.
Gráfico 3.1 - Avaliação da qualidade Fonte – Elaboração Própria, baseado em Beecham et al. (2007).
No Gráfico 3.1 observa-se que os estudos avaliados com valor > 86%, recebem
avaliação “Excelente”, > 66% e < 85%, conceito de avaliação “Muito bom”, > 46% e
< 65%, avaliação “Boa”, > 26% e < 45%, avaliação “Média, e < 26%, recebeu a
avaliação “Baixa”.
Extração dos dados
A extração de dados utilizou formulários disponíveis na Seção C5 do Apêndice
C – Protocolo do mapeamento. Para cada trabalho aprovado pelo processo de
seleção, utilizou-se o Formulário A, que lista os trabalhos incluídos, com as
informações que identificam o trabalho e dados que serão apresentados em forma
de gráficos nos resultados da revisão no Capítulo 4. No Formulário B, são listados os
trabalhos excluídos e o motivo que o levou a exclusão. Finalmente, o Formulário C é
utilizado para extrair as informações gerais e realizar da avaliação da qualidade.
Síntese dos Dados
De acordo com Kitchenham, (2007); Travassos, (2007), Após a coleta dos
dados, as informações devem ser tabuladas de acordo com as questões de
100%
85%
65%
45%
26%
86%
66%
46%
26%
0% 0%
20%
40%
60%
80%
100%
120%
Excelente Muito bom Boa Média Baixa
Avaliação da Qualidade
63
pesquisa, as tabelas devem ser estruturadas de forma a destacar as semelhanças e
diferenças entre os resultados do estudo. Assim, Kitchenham, (2007) afirmam que a
síntese dos dados pode ser quantitativa e/ou qualitativa, sendo que a primeira
necessariamente seria tratada através de meta-análise.
O procedimento para a síntese dos dados se inicia com a marcação das
passagens retiradas dos estudos selecionados (dados qualitativos), a partir dos
formulários apresentados no Apêndice C – Protocolo do mapeamento, que fornecem
algum tipo de informação relevante para responder as perguntas de pesquisa.
3.2.2 Métodos para Análise dos Resultados Ao extrair e sintetizar os dados da revisão sistemática, realizou-se análise mais
detalhada dos mesmos para a criação de uma abordagem que relacione os desafios
às boas práticas identificadas. A Figura 3.3, adaptada de Wholin et al. (2000),
apresenta essa análise, relaciona em projetos no desenvolvimento distribuído de
software, os desafios do gerenciamento de projetos, variáveis dependentes, com os
tratamentos (melhores práticas, ferramentas e modelos), variáveis independentes,
que buscam reduzir ou eliminar os desafios.
Figura 3.3 - Análise dos resultados Fonte: Elaboração própria, adaptado de Wholin et al., (2000)
Os dados identificados como desafios nos estudos primários foram extraídos e
receberam um código, a solução proposta pelo mesmo estudo para aquele desafio
recebeu o mesmo código. Pois os códigos devem seguir um padrão para
64
posteriormente serem agrupados, possibilitando uma relação direta entre desafios e
tratamentos e, com a combinação dessas informações foi possível a criação da
abordagem. Os códigos deste estudo seguem a seguinte formatação:
§ Para os Desafios:
o D1....Dn - <Desafios>
§ Para os Tratamentos:
o MP1....MPn - <Melhores Práticas>
o F1.......Fn - <Ferramenta>
o M1.....Mn - <Modelo>
Onde:
§ D1 ... Dn – um número atribuído sequencialmente para os desafios que
os estudos primários avaliados apresentavam;
§ Desafio – desafios no gerenciamento de projetos no DDS,
apresentadas pelos estudos primários;
§ MP1 ... MPn – um número atribuído sequencialmente às melhores
práticas propostas pelos estudos primários, correspondente ao número
do desafio relacionado;
§ Melhores Prática – solução proposta para atender aos desafios no
gerenciamento de projetos no DDS.
§ F1 ... Fn – um número atribuído sequencialmente às ferramentas de
apoio propostas pelos estudos primários, correspondente ao número
do desafio ou boa prática relacionado;
§ Ferramenta – solução tecnologia proposta para apoiar o gerenciamento
de projetos no DDS.
§ M1 ... Mn – um número atribuído sequencialmente aos modelos de
apoio ao gerenciamento proposto pelos estudos primários,
correspondente ao número do desafio ou boa prática relacionado;
§ Modelo – modelos de apoio propostos para o gerenciamento de
projetos no DDS.
A síntese das evidências coletadas, foi realizada em forma de tabelas
relacionando a evidência ou a categoria construída a partir das evidências com a
origem através da referência ao estudo primário. Será verificado, nas tabelas Tabela
4.1Tabela 4.2Tabela 4.3Tabela 4.4, apresentadas no Capítulo 4 deste trabalho, a
65
frequência de ocorrência das evidências, através da contagem no número de vezes
que a mesma é encontrada em estudos diferentes.
3.3 Considerações finais do capítulo Neste capítulo foi descrito a metodologia utilizada nesta pesquisa, como foi
estruturada, conduzida e as razões de uso dos procedimentos e métodos. Além de,
uma breve descrição do protocolo usado para guiar a execução o mapeamento
sistemático proposto pelo estudo. Consequentemente, dessa forma se espera atingir
o rigor necessário para obter validade científica, essencial para a confiabilidade dos
resultados deste estudo.
66
Capítulo
4 4. Análise dos resultados
Este capítulo apresenta os resultados do estudo executado através protocolo definido no
capítulo anterior. Os resultados foram estruturados em quatro componentes que constituem as
principais contribuições do estudo e serão detalhadas da seguinte ordem:
4.1 Resultados da extração e análise dos dados – descrevem dados gerais do
mapeamento, como: número de trabalhos retornados nas buscas automatizadas e manuais,
processo de seleção com o número final de estudos primários, distribuição ao longo das datas
de publicação de cada um através dos anos, modelos de negócios envolvidos, o foco e, por
fim, a avaliação da qualidade.
4.2 Mapeamento das evidências – descreve as evidências identificadas pelo
mapeamento sistemático (Q1, Q2, Q3 e Q4).
4.3 Apresentação das respostas das evidências – apresenta a respostas para as
questões de pesquisa que foram evidenciadas na Seção 4.2 encontradas neste mapeamento.
4.3 Abordagem para o gerenciamento de projetos no DDS – uma relação e
estabelecida entre os resultados de cada questão de pesquisa, propondo assim uma abordagem
para o gerenciamento de projetos do DDS, na qual a gerência pode ter como base desafios e
possíveis soluções para os mesmos.
67
4.4 Discussão sobre os resultados obtidos – descreve uma análise dos principais
resultados obtidos pela pesquisa.
4.5 Comparação dos resultados – apresenta a comparação dos resultados deste
mapeamento com a abordagem proposta por Costa (2009).
4.6 Considerações finais – apresenta um resumo dos tópicos do capítulo.
68
4.1 Resultado da extração e análise dos dados O mapeamento sistemático foi executado de acordo com o protocolo descrito
resumidamente no capítulo anterior e disponível por completo no Apêndice C –
Protocolo do mapeamento. A partir das strings e fontes definidas, as buscas
primárias retornaram um total de 2123 trabalhos, nos quais 150 trabalhos foram
identificados no IEEE, 279 na ACM, 368 no ScienceDirect, 266 no El compendex,
424 na Elsevier Scopus, 278 na Springer Link, e 358 trabalhos das sete edições
ICGSE (International Conference on Global Software Engineering).
O Gráfico 4.1 mostra a quantidade de trabalhos retornados por cada engenho
de busca e o ano de limitação das buscas, apresentando a evolução em números do
processo de seleção de estudos primários.
Gráfico 4.1 - Número de trabalhos retornados Fonte – Elaboração própria, com dados do mapeamento
Já Quadro 4.1 apresenta a evolução em números do processo de seleção de
estudos primários. São apresentados os valores da busca primária para cada string
no total de 2123 estudos retornados em que, a partir da primeira seleção por título e
1900ral
1900ral
1901ral
1900ral
1900ral 1901ral
1900ral
1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1901ral 1901ral
Núm
ero de
ArMgos R
etorna
dos
Bases de Busca
69
palavra-chave, foram identificados 373 estudos potencialmente relevantes para a
pesquisa.
Seleção de Estudos Primários
Fontes Ano
Estudos Retornados
1ª S
eleç
ão
(Títu
lo e
Pa
lavr
a-ch
ave)
2ª Seleção (Resumo e Conclusão)
Excluídos
Incl
uído
s
Q1
Q2
Q3+
Q4
Tota
l
Est
udos
P
oten
cial
men
te
Rel
evan
tes
Não
rele
vant
es
Rep
etid
o/ D
uplic
ado
Inco
mpl
etos
Est
udos
P
rimár
ios
IEEEXplore 2009-2012 40 40 70 150 115 30 5 5 71 ACM 2009-2012 81 87 111 279 7 200 2 70 5
ScienceDirect 2009-2012 74 70 224 368 28 300 10 30 20 El Compendex 2009-2012 76 63 127 266 37 200 31 0 19
Elsevier Scopus 1998-2012 14 16 394 424 110 300 10 10 68
SpringerLink 1997-2012 80 62 136 278 20 237 1 20 10 ICGSE 2006-2012 358 358 56 250 30 24 31
Total 2123 373 1750 224
Quadro 4.1 - Seleção dos estudos primários Fonte – Elaboração própria, com dados do mapeamento
Após a leitura do resumo e conclusão dos estudos potencialmente relevantes e
utilizando os critérios de exclusão, chegou-se em 224 estudo primários, disponíveis
no Apêndice A – Estudos primários incluídos deste trabalho. Os 149 trabalhos
considerados potencialmente não relevantes na primeira seleção foram excluídos,
disponíveis no Apêndice B – Estudos excluídos deste trabalho, e os principais
motivos para a exclusão foram:
§ Não respondiam a nenhuma questão de pesquisa;
§ Identificados duas vezes por fontes diferentes, isto é, repetido ou
duplicado;
§ Não apresentavam texto completo; e,
§ Trabalhos que estavam na revisão sistemática de Costa (2009).
70
O Gráfico 4.2 ilustra a distribuição dos estudos primários identificados pelo
processo de seleção automático, ao longo dos anos. Observa-se que em 2009
houve um grande crescimento nos estudos relacionados a DDS, de acordo
mapeamento sistemática realizada. Os anos de 2009, 2010 e 2011 tiveram mais
publicações.
Gráfico 4.2 - Número de estudos primários das fontes automáticas Fonte – Elaboração própria, com dados do mapeamento
O Gráfico 4.3 ilustra a distribuição dos estudos primários identificados pelo
processo de seleção de seleção manual, que foi realizado nas sete edições do IGSE
(International Conference on Global Software Engineering).
1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral
1900ral
1900ral 1900ral 1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
Qua
nMda
de
Anos
71
Gráfico 4.3 - Número de estudos primários da busca manual Fonte – Elaboração própria, com dados do mapeamento
O Gráfico 4.4 ilustra a distribuição dos estudos primários nas bases manual e
automática ao longo dos anos.
Gráfico 4.4 - Número de estudos primários Fonte – Elaboração própria, com dados do mapeamento
O Gráfico 4.5 ilustra a distribuição de estudos primários nas bases automática
e manual ao longo dos anos referente a pesquisa de Costa (2009).
1900ral 1900ral
1900ral
1900ral 1900ral
1900ral 1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1905ral 1905ral 1905ral 1905ral 1905ral 1905ral 1905ral
Qua
nMda
de
Anos
1900ral 1900ral 1900ral 1900ral 1900ral 1900ral
1900ral 1900ral
1900ral 1900ral 1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
Qua
nMda
de
Anos
72
Gráfico 4.5 - Número de estudos primários identificados por Costa (2009) Fonte – Costa (2009)
O Gráfico 4.6 ilustra a quantidade de estudos primários desta pesquisa, somados com os estudos primários do estudo de Costa (2009).
Gráfico 4.6 - Soma dos estudos primários identificados por Costa (2009) e por esta pesquisa Fonte - Fonte – Elaboração própria, com dados do mapeamento e em Costa (2009)
O Gráfico 4.7 ilustra a distribuição quantitativa dos estudos primários
identificados nas respectivas bases.
1900ral 1900ral 1900ral 1900ral
1900ral 1900ral 1900ral
1900ral
1900ral 1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral Qua
nMda
de
Anos
1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral
1900ral
1900ral
1900ral 1900ral 1900ral
1900ral 1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
Qua
nMda
de
Anos
73
Gráfico 4.7 - Número de estudos primários das buscas automáticas por base Fonte – Elaboração própria, com dados do mapeamento
A pontuação máxima que um estudo poderia alcançar de acordo com os
critérios de qualidade definidos no Capítulo 3, são 40 pontos. Baseado em Beecham
et al., (2007) os valores foram divididos em cinco faixas de notas e a esse valor é
associado uma classificação: Baixa, Médio, Boa, Muito Boa e Excelente.
O Gráfico 4.8 ilustra a quantidade de estudos primários, que tiveram avaliação
de qualidade “Baixa”, em que se nota somente um estudo com tal avaliação, sendo
este da fonte IEEEXplore.
Gráfico 4.8 - Quantidade de estudos primários com qualidade "Baixa" Fonte – Elaboração própria, com dados do mapeamento, baseado em Beecham et al., (2007)
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral
Qua
nMda
de
1900ral 1900ral 1900ral 1900ral
1900ral
1900ral 1900ral 1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
74
O Gráfico 4.9 ilustra a quantidade de estudos primários que tiveram avaliação
de qualidade “Média”.
Gráfico 4.9 - Quantidade de estudos primários com qualidade "Média" Fonte – Elaboração própria, com dados do mapeamento, baseado em Beecham et al., (2007)
O Gráfico 4.10 ilustra a quantidade de estudos primários que tiveram avaliação
de qualidade “Boa”.
Gráfico 4.10 - Quantidade de estudos primários com qualidade "Boa" Fonte – Elaboração própria, com dados do mapeamento, baseado em Beecham et al., (2007)
1900ral
1900ral 1900ral
1900ral 1900ral
1900ral 1900ral 1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral 1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
75
O Gráfico 4.11 ilustra a quantidade de estudos primários que tiveram avaliação
de qualidade “Muito Boa”.
Gráfico 4.11 - Quantidade de estudos primários com qualidade "Muito boa" Fonte – Elaboração própria, com dados do mapeamento, baseado em Beecham et al., (2007)
O Gráfico 4.12 ilustra a quantidade de estudos primários que tiveram avaliação
de qualidade “Excelente”.
Gráfico 4.12 - Quantidade de estudos primários com qualidade "Excelente" Fonte – Elaboração própria, com dados do mapeamento, baseado em Beecham et al., (2007)
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral
1900ral
1900ral
1900ral
1900ral
1900ral
1900ral 1900ral
1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral 1900ral
76
O Gráfico 4.13 mostra uma visão geral da avaliação da qualidade dos estudos
primários. Nele é apresentado a proporcionalidade de estudos retornados pelo total
encontrado em cada base. A avaliação da qualidade individual de cada estudo
encontra-se no Apêndice A deste trabalho.
Gráfico 4.13 - Proporção geral da avaliação da qualidade Fonte – Elaboração própria, com dados do mapeamento, baseado em Beecham et al., (2007)
4.2 Mapeamento das evidências Nesta seção, são apresentados os resultados evidenciados para os maiores
desafios, as melhores práticas, ferramentas e modelos de apoio ao gerenciamento
de projetos no desenvolvimento distribuído de software. Esses resultados foram
sumarizados nas tabelas Tabela 4.1, Tabela 4.2, Tabela 4.3 e Tabela 4.4 com suas
respectivas referências e quantidades.
A Tabela 4.1, apresenta os 32 desafios evidenciados na literatura relacionados
ao gerenciamento de projetos de desenvolvimento distribuído de software. A
primeira coluna apresenta os desafios extraídas dos estudos primários apresentados
na coluna dois e a terceira coluna, a quantidade de trabalhos.
0%
10%
20%
30%
40%
50%
60%
70%
80%
Baixa
Média
Boa
Muito Boa
Excelente
77
Tabela 4.1 - Desafios do gerenciamento de projetos no DDS Fonte: Elaboração própria, com base no mapeamento
D: Desafios Referência - EP: Estudos Primários Quantidade de trabalhos
D1. Comunicação EP_01, EP_02, EP_03, EP_04, EP_07, EP_08, EP_10, EP_11, EP_12, EP_13, EP_20, EP_14, EP_15, EP_21, EP_23, EP_25, EP_29, EP_32, EP_33, EP_34, EP_35, EP_36, EP_39, EP_40, EP_41, EP_43, EP_44, EP_47, EP_49, EP_50, EP_51, EP_52, EP_54, EP_55, EP_57, EP_58, EP_59, EP_60, EP_61, EP_62, EP_63, EP_65, EP_66, EP_67, EP_68, EP_69, EP_70, EP_71, EP_78, EP_80, EP_84, EP_86, EP_87, EP_88, EP_90, EP_98, EP_99, EP_102, EP_103, EP_104, EP_107, EP_109, EP_110, EP_112, EP_113, EP_116, EP_117, EP_118, EP_119, EP_121, EP_125, EP_128, EP_129, EP_130, EP_131, EP_132, EP_133, EP_134, EP_135, EP_136, EP_137, EP_138, EP_139, EP_140, EP_141, EP_142, EP_143, EP_144, EP_145, EP_146, EP_147, EP_148, EP_150, EP_152, EP_153, EP_154, EP_157, EP_158, EP_159, EP_160, EP_162, EP_163, EP_164, EP_168, EP_169, EP_170, EP_171, EP_173, EP_175, EP_177, EP_178, EP_179, EP_180, EP_181, EP_185, EP_188, EP_189, EP_192, EP_193, EP_196, EP_197, EP_199, EP_201, EP_203, EP_204, EP_206, EP_207, EP_209, EP_210, EP_211, EP_212, EP_213, EP_214, EP_215, EP_216, EP_218, EP_219, EP_220, EP_221, EP_223
140
D2. Interação entre stakeholders EP_01, EP_12, EP_21, EP_47, EP_78, EP_102, EP_147, 7
D3. Dispersão Geográfica
EP_02, EP_04, EP_05, EP_12, EP_13, EP_21, EP_33, EP_35, EP_36, EP_41, EP_43, EP_46, EP_47, EP_51, EP_52, EP_55, EP_59, EP_63, EP_64, EP_69, EP_75, EP_78, EP_81, EP_83, EP_84, EP_87, EP_90, EP_91, EP_95, EP_98, EP_99, EP_102, EP_103, EP_104, EP_107, EP_110, EP_112, EP_114, EP_116, EP_162, EP_ 179, EP_180, EP_181, EP_189, EP_192, EP_193, EP_194, EP_196, EP_203, EP_ 205, EP_208, EP_212, EP_219, EP_25, EP_29, EP_51, EP_52, EP_81, EP_117, EP_120, EP_123, EP_125, EP_126, EP_129, EP_130, EP_133, EP_135, EP_136, EP_139, EP_141, EP_142, EP_144, EP_146, EP_147, EP_148, EP_153, EP_154, EP_156, EP_157, EP_158, EP_159, EP_169, EP_170, EP_171, EP_172, EP_173, EP_179, EP_194, EP_201, EP_210, EP_220
91
D4. Diferença Cultural
EP_02, EP_06, EP_07, EP_08, EP_10,EP_12, EP_14, EP_20, EP_21, EP_22, EP_24, EP_25, EP_28, EP_29, EP_33, EP_34, EP_35, EP_36, EP_37, EP_39, EP_40, EP_41, EP_44, EP_45, EP_46, EP_47, EP_49, EP_50, EP_51, EP_52, EP_54, EP_55, EP_58, EP_59, EP_62, EP_63, EP_65, EP_66, EP_68, EP_69, EP_70, EP_74, EP_75, EP_77, EP_79, EP_80, EP_81, EP_87, EP_90, EP_91, EP_98, EP_99, EP_103, EP_104, EP_107, EP_108, EP_109, EP_110, EP_112, EP_114, EP_115, EP_116, EP_117, EP_120, EP_125, EP_126, EP_128, EP_129, EP_130, EP_131, EP_132, EP_133, EP_135, EP_136, EP_139, EP_141, EP_142, EP_143, EP_144, EP_145, EP_146, EP_148, EP_149, EP_151, EP_152, EP_154 EP_155, EP_158, EP_159, EP_162, EP_163, EP_165, EP_167, EP_168, EP_169, EP_170, EP_172, EP_175, EP_177, EP_178, EP_179, EP_180, EP_181, EP_185, EP_188, EP_189, EP_192, EP_193, EP_194, EP_197, EP_199, EP_202, EP_203, EP_206, EP_ 207, EP_208, EP_210, EP_212, EP_219, EP_220
140
D5. Coordenação EP_02, EP_03, EP_07, EP_22, EP_23, EP_29, EP_32, EP_33, EP_43, EP_47, EP_52, EP_63, EP_65, EP_68, EP_69, EP_90, EP_95, EP_98, EP_103, EP_107, EP_112, EP_117, EP_129, EP_131, EP_139, EP_141, EP_142, EP_143, EP_144, EP_149, EP_150, EP_158, EP_163, EP_168, EP_171, EP_173, EP_175, EP_178, EP_185, EP_187, EP_189, EP_199, EP_201, EP_207, EP_210, EP_211, EP_212, EP_219,
48
78
D6. Diferença Temporal
EP_02, EP_03, EP_04, EP_06, EP_08, EP_21,EP_22, EP_23, EP_25, EP_32, EP_34, EP_35, EP_37, EP_40, EP_41, EP_43, EP_44, EP_47, EP_51, EP_52, EP_59, EP_65, EP_69, EP_70, EP_74, EP_75, EP_77, EP_78, EP_91, EP_98, EP_103, EP_108, EP_109, EP_114, EP_115, EP_116, EP_118, EP_123, EP_132, EP_133, EP_141, EP_142, EP_143, EP_144, EP_146, EP_147, EP_148, EP_149, EP_151, EP_152, EP_153, EP_159, EP_162, EP_163, EP_169, EP_170, EP_172, EP_173, EP_175, EP_178, EP_179, EP_180, EP_187, EP_188, EP_189, EP_192, EP_193, EP_194, EP_196, EP_202, EP_203, EP_204, EP_205, EP_204, EP_205, EP_208, EP_210, EP_212, EP_ 218,
79
D7. Diferentes Tecnologias
EP_02, EP_10, EP_11, EP_25, EP_29, EP_74, EP_81, EP_117, EP_121, EP_130, EP_146, EP_178, EP_180, EP_194, EP_196, EP_206, 16
D8. Confiança EP_04, EP_12, EP_14, EP_16, EP_20, EP_23, EP_29, EP_43, EP_52, EP_65, EP_67, EP_91, EP_104, EP_117, EP_121, EP_122, EP_132, EP_143, EP_159, EP_177, EP_180, EP_187, EP_194, EP_196, EP_213, EP_215,
26
D9. Idioma/ Barreira Linguística
EP_04, EP_10,EP_22, EP_23, EP_36, EP_37, EP_39, EP_41, EP_44, EP_47, EP_55, EP_58, EP_59, EP_65, EP_66, EP_68, EP_69, EP_70, EP_75, EP_77, EP_79, EP_80, EP_87, EP_91, EP_98, EP_103, EP_107, EP_108, EP_109, EP_110, EP_111, EP_112, EP_116, EP_117, EP_118, EP_122, EP_123, EP_124, EP_125, EP_131, EP_133, EP_135, EP_138, EP_147, EP_148, EP_153, EP_158, EP_163, EP_167, EP_171, EP_178, EP_180, EP_181, EP_185, EP_188, EP_192, EP_194, EP_196, EP_197, EP_204, EP_213,
61
D10. Diferentes Tipos de Governos, leis, regras e regulamentos
EP_06, EP_77, EP_98, EP_115, EP_117, EP_130, EP_145, EP_179, EP_ 194, EP_196, EP_206, 11
D11. Economia EP_07, EP_10, EP_81, EP_103, EP_180, 5 D12. Cumprimento de Prazos / Gerenciar Cronograma
EP_07, EP_10, EP_29, EP_37, EP_117, EP_178, EP_180, 7
D13. Orçamento EP_07, EP_10, EP_29, EP_32, EP_37, 5 D14.Falta de planejamento de projetos
EP_07, EP_17, EP_150, EP_117, EP_196, EP_207 6
D15. Propriedade Intelectual/ Confidencialidade e Privacidade
EP_07, EP_10, EP_19, EP_117, EP_10, EP_57, EP_114, EP_132, EP_147, EP_185 10
D16. Qualidade/ Métrica EP_07, EP_117, EP_118, EP_141, EP_142, EP_155, EP_166, EP_169,
EP_175, EP_191, EP_204, EP_206, EP_211, EP_213, 14
D17. Infraestrutura EP_07, EP_10, EP_23, EP_34, EP_74, EP_84, EP_91, EP_102, EP_109, EP_117, EP_119, EP_122, EP_125, EP_133, EP_145, EP_147, EP_169, EP_175, EP_180, EP_185, EP_196, EP_197,
22
D18. Distribuição/ Gerenciamento de Tarefas
EP_11, EP_57, EP_65, EP_74, EP_117, EP_129, EP_168, EP_180 8
D19. Colaboração/ Cooperação
EP_12, EP_18, EP_37, EP_47, EP_117, EP_118, EP_122, EP_153, EP_167, EP_169, EP_178, EP_189, EP_192, EP_194, EP_207, EP_215, EP_222
17
D20. Gestão de Conflitos/ Gestão de Pessoa
EP_10, EP_12, EP_13, EP_20, EP_37, EP_46, EP_55, EP_58, EP_66, EP_109, EP_117, EP_123, EP_136, EP_162, EP_167, EP_172, EP_179, EP_180, EP_197, EP_222,
20
D21. Manter espírito de equipe
EP_20, EP_25, EP_32,EP_44, EP_59, EP_104, EP_117, EP_168, EP_194 9
79
D22. Diferentes Níveis de Conhecimento/ Transferência de Conhecimento
EP_21, EP_26, EP_24, EP_25, EP_58, EP_65, EP_69, EP_107, EP_109, EP_117, EP_118, EP_194, EP_196, EP_207, 14
D23. Diferença Organizacional/ Padrões, Processos, Metodologias e Políticas diferentes
EP_34, EP_36, EP_37, EP_41, EP_52, EP_74, EP_91, EP_95, EP_98, EP_103, EP_117, EP_122, EP_130, EP_132, EP_153, EP_180, EP_197, EP_207, EP_211
19
D24. Gestão do Conhecimento
EP_29, EP_36, EP_41, EP_81, EP_111, EP_119, EP_122, EP_132, EP_138, EP_178, EP_192, EP_194, EP_206, 13
D25. Gestão de Risco EP_42, EP_47, EP_54, EP_58, EP_62, EP_73, EP_74, EP_80, EP_81, EP_84, EP_106, EP_111, EP_117, EP_119, EP_125, EP_132, EP_135, EP_138, EP_140, EP_144, EP_149, EP_156, EP_160, EP_162, EP_178, EP_181, EP_196, EP_197, EP_208, EP_216, EP_220
31
D26. Monitoramento e Controle
EP_67, EP_68, EP_103, EP_112, EP_117, EP_119, EP_131, EP_142, EP_144, EP_148, EP_149, EP_171, EP_ 178, EP_201, EP_210, EP_219, 16
D27. Identificar Papéis e Responsabilidades
EP_36, EP_163, EP_117, 4
D28. Sincronização de Trabalhos entre os Sites
EP_117, EP_224 2
D29. Gestão de Escopo/Gestão de Mudança
EP_117, EP_150, EP_203, 3
D30. Diferentes Stakeholders EP_06, EP_52, EP_117, EP_77 4
D31. Aplicação de um processo iterativo Ágil
EP_67, EP_117, EP_112, EP_188, EP_199, EP_215, EP_219 7
D32. Visibilidade/Clareza de quem faz o que é onde
EP_10, EP_34, EP_69, EP_90, EP_91, EP_117, 6
A Tabela 4.2, apresenta as 28 melhores práticas evidenciadas na literatura
relacionados ao gerenciamento de projetos de desenvolvimento distribuído de
software. A primeira coluna apresenta as melhores práticas extraídas dos estudos
primários apresentados na coluna dois e a terceira coluna, a quantidade de
trabalhos.
80
Tabela 4.2 - Melhores práticas para o gerenciamento de projetos no DDS Fonte: Elaboração própria, com base no mapeamento
MP: Melhores Práticas Referências - EP: Estudos Primários Quantidade de trabalhos
MP1. Disponibilização/ Treinamento em ferramentas de comunicação e colaboração
EP_3, EP_6, EP_11, EP_14, EP_16, EP_27, EP_28, EP_117, EP_166, EP_188, EP_223, EP_224
12
MP2. Transferência de conhecimento EP_02, EP_03_04, EP_11, EP_52, EP_71, EP_108, EP_117 8
MP3. Disponibilidade de vários meios de comunicação/ Ter mecanismo para comunicação face a face
EP_11, EP_41, EP_70, EP_78, EP_93, EP_103, EP_117, EP_131, EP_144, EP_186, EP_187, EP_04, EP_75, EP_103, EP_128, EP_150, EP_162, EP_224
18
MP4. Organizar equipe com culturas e conhecimento complementares EP_11, EP_21, EP_117, EP_122, EP_192, 5
MP5. Promover Interação Informal EP_02, EP_07, EP_11, EP_25, EP_31, EP_36, EP_22, EP_117, EP_118, EP_122, EP_128, EP_131, EP_146, EP_157, EP_179, EP_199, EP_98, EP_103, EP_125, EP_134, EP_145, EP_156, EP_167, EP_174, EP_182, EP_192, EP_198, EP_201, EP_213, EP_222,
30
MP6. Detalhar o planejamento EP_26, EP_28, EP_30, EP_62, EP_117, EP_118, EP_119, 7
MP7. Disponibilidade de uma boa infraestrutura EP_52, EP_103, EP_117, EP_185, 4
MP8. Treinamento sobre Culturas diferentes EP_68, EP_75, EP_87, EP_107, EP_117, 5
MP9. Gerenciar Riscos constantemente EP_70, EP_107, EP_117, EP_122, EP_155, 5
MP10. Motivar Equipe/Manter espírito de equipe
EP_43, EP_52, EP_98, EP_47, EP_59, EP_102, EP_117, 7
MP11. Gerenciar/Coordenar pessoas EP_74, EP_117, 2 MP12. Utilizar Metodologia Ágeis EP_32, EP_67, EP_78, EP_117, EP_143, 5 MP13. Sincronização de Trabalhos entre sites EP_44, EP_47, EP_65, EP_117, 4
MP14. Definição de papéis e responsabilidade EP_61, EP_70, EP_74, EP_91, EP_117, 5
MP15. Manter padrões de Qualidade EP_70, EP_117, EP_141, EP_142, EP_166, 5
MP16. Criação de Protocolo de Comunicação
EP_41, EP_74, EP_117, EP_157, EP_04, EP_08, EP_44, EP_119, 8
MP17. Utilizar Redes Sociais EP_77, EP_93, 2 MP18. Visita entre sites EP_10, EP_19, EP_21, EP_33, EP_91, EP_117,
EP_128, EP_151, EP_158, EP_163 10
MP19. Estimular a Cooperação/Colaboração EP_43, EP_117, EP_132, EP_144, 4
81
MP20. Gestão de Configuração EP_65, EP_100, EP_101, EP_149, EP_181, EP_199, EP_203, EP_213, EP_117, EP_147, EP_186,
11
MP21. Face a face Kickoff EP_117, EP_147, 2 MP22. Gerenciar Cronograma
EP_29, EP_117,EP_118, EP_122, EP_164, 5
MP23. Sincronicidade - Reuniões com horários razoáveis para a maioria dos sites EP_29, EP_64, EP_78, EP_117, 4
MP24. Garantir confidencialidade e privacidade e propriedade intelectual EP_19, EP_64, EP_35, EP_117, EP_185, 5
MP26. Visibilidade do trabalho EP_91, EP_117, 2 MP27. Espaço físico para equipes locais EP_21, EP_68, EP_117, 3 MP28. Critérios claros para atribuição de tarefas EP_12, EP_117, EP_187, 3
A Tabela 4.3, apresenta as 31 ferramentas evidenciadas na literatura
relacionados ao gerenciamento de projetos de desenvolvimento distribuído de
software. A primeira coluna apresenta os desafios extraídas dos estudos primários
apresentados na coluna dois e a terceira coluna, a quantidade de trabalhos.
Tabela 4.3 - Ferramentas de apoio ao DDS Fonte: Elaboração própria, com base no mapeamento
F: Ferramentas Referências - EP: Estudos Primários Quantidade de trabalhos
F1. E-mail EP_08, EP_12, EP_13, EP_24, EP_26, EP_27, EP_28, EP_32, EP_34, EP_38, EP_40, EP_41, EP_44, EP_52, EP_59, EP_60, EP_67, EP_69, EP_74, EP_75, EP_82, EP_83, EP_87, EP_91, EP_96, EP_98, EP_102, EP_110, EP_114, EP_117, EP_131, EP_133, EP_134, EP_136, EP_144, EP_147, EP_157, EP_160, EP_163, EP_173, EP_182, EP_187, EP_189, EP_192, EP_194, EP_197, EP_204, EP_205, EP_210, EP_221,
50
F2. Telefone EP_12, EP_26, EP_32, EP_37, EP_38, EP_40, EP_41, EP_44, EP_52, EP_60, EP_69, EP_74, EP_75, EP_82, EP_83, EP_87,EP_91, EP_ 117, EP_128, EP_131, EP_134, EP_136, EP_139, EP_147, EP_149, EP_159, EP_173, EP_182, EP_189, EP_194, EP_197, EP_205, EP_210,
33
F3. Teleconferência EP_04, EP_21, EP_58, EP_67, EP_87, EP_102, EP_117, EP_133, EP_144, EP_183, EP_187, EP_189, EP_210, EP_217, EP_221,
15
F4. Videoconferência EP_12, EP_13,EP_27, EP_32, EP_41, EP_44, EP_58, EP_60, EP_69, EP_74, EP_75, EP_82, EP_83, EP_84, EP_87, EP_91, EP_96, EP_102, EP_110, EP_114, EP_117, EP_131, EP_134, EP_144, EP_146, EP_147, EP_160, EP_173, EP_174, EP_187, EP_189, EP_192, EP_194, EP_197, EP_204, EP_217, EP_221,
37
82
F5. Bate-papo (Chat) EP_13, EP_26, EP_27, EP_32, EP_40, EP_44, EP_75, EP_87, EP_102, EP_117, EP_128, EP_146, EP_182, EP_194, EP_204, EP_52, EP_67, EP_69, EP_82, EP_91, EP_110, EP_114, EP_134, EP_ 136, EP_147, EP_149, EP_157, EP_159, EP_182, EP_187, EP_189, EP_192, EP_197, EP_214, EP_217, EP_219, EP_38, EP_182, EP_38, EP_143, EP_157, EP_160, EP_182, EP_194, EP_214,
45
F6. Áudio Conferência EP_27, EP_32, EP_34, EP_40, EP_74, EP_114, EP_117, EP_133, EP_134, EP_205, 10
F7. Voicemail EP_34, EP_74, EP_117, 3 F8. NetMeeting EP_32, EP_34, EP_74, EP_75, EP_117, EP_189, EP_194,
EP_197, EP_205, EP_217 10
F9. VoIP EP_38, EP_96, EP_133, EP_157, 4 F10. Wiki EP_40, EP_43, EP_67, EP_91, EP_102, EP_110, EP_114, EP_
117, EP_134, EP_144, EP_147, EP_153, EP_182, EP_183, EP_187, EP_189, EP_192, EP_194, EP_212, EP_217, EP_219, EP_221
22
F11. Blog EP_40, EP_117, EP_147, EP_187, EP_189, EP_194, 6 F12. Calendário de Grupo (Group calendars)
EP_40, EP_117, EP_169, EP_182, EP_194, EP_205, 6
F13. Fax EP_40, EP_44 , EP_83, EP_117, EP_197, 5 F14. Jazz EP_48, EP_164, EP_192, EP_219, 4 F15. TAMRI EP_68,EP_117, EP_192, EP_194, 4 F16. Intranet EP_26, EP_69, EP_75, EP_87, EP_117, EP_140, EP_197, 7 F17. Fórum de discussão EP_34, EP_74, EP_96, EP_134, EP_204 5 F18. Quadros Virtuais (Virtual whiteboards)
EP_114, EP_117, EP_134, EP_189, EP_192, EP_194, EP_204, 7
F19. Galeria de fotos (Photo Gallery)
EP_117, EP_144, EP_189, EP_194, 4
F20. Jira EP_117, EP_144, EP_168, EP_192, 4 F21. TeamSpace EP_40, EP_117, EP_194, 3 F22. CAMEL EP_117, EP_168, EP_194, 3 F23. NEXTMOVE EP_117, EP_194, 2 F24. Groupware EP_40, EP_75, EP_87, EP_99, EP_192, EP_194, 6 F25. ActiveCollab EP_168,EP_192, 2 F26. Assembla EP_168, EP_192, 2 F27. GliFFy EP_168, 1 F28. Repositório de lições aprendidas
EP_14, EP_117, EP_ 223 3
F29. Webex EP_168, EP_192, 2 F30. Xplanner EP_215, 1 F31. Ms Sharepoint EP_192, 1
A Tabela 4.4, apresenta 14 modelos evidenciadas na literatura, para apoia o
gerenciamento de projetos de desenvolvimento distribuído de software. A primeira
83
coluna apresenta os desafios extraídas dos estudos primários apresentados na
coluna dois e a terceira coluna, a quantidade de trabalhos.
Tabela 4.4 - Modelos de apoio ao gerenciamento de projetos distribuídos Fonte: Elaboração própria, com base no mapeamento
M: Modelos Referência - EP: Estudos Primários Quantidade de trabalhos
M1. TAPER EP_06, EP_117, EP_194, EP_210 4 M2. Project management model EP_117, EP_194 2 M3. A reference model for global software development EP_194 1
M4. Conceptual model for managing an international IS development project EP_117, EP_194 2
M5. DRiMaP—a model of distributed risk management EP_140, EP_194 2
M6. Solar system EP_117, EP_194 2 M7. Dyadic model EP_194 1 M8. Project management framework EP_117, EP_194 2 M9. Process maturity framework for managing distributed development EP_117, EP_194 2
M10. Approach to offshore collaboration EP_32, EP_117, EP_194 3 M11. Framework for supporting management in distributed information systems development EP_117, EP_194 2
M12. NEXTMOVE EP_117, EP_194 2 M13. GSD model EP_52, EP_59, EP_194 3 M14. Framework to enable coordination in distributed software development EP_117, EP_194 2
4.2.1 Relacionando evidências ao gerenciamento do projeto no DDS As evidências, relacionadas aos desafios, melhores práticas, modelos e
ferramentas, descritos na Seção 4.2 deste capítulo foram combinadas nas tabelas
Tabela 4.5Tabela 4.6Tabela 4.7Tabela 4.8. Esta abordagem foi proposta por Costa
(2009), e usada neste mapeamento, permitindo que a gerência, diante da
identificação de um desafio, possa verificar as possibilidades que venha minimizar
ou eliminar o desafio no gerenciamento de projetos distribuídos de software. As
fases e detalhes desta abordagem estão detalhadas na Seção 4.4, deste capítulo.
A Figura 4.1, ilustra as relações existentes entre as questões de pesquisa. O
ponto inicial são os dados evidenciados sobre os desafios no gerenciamento de
projetos no desenvolvimento distribuídos (Q1) e as melhores práticas utilizadas para
superá-los (Q2). Ferramentas (Q3) e modelos (Q4) que suportam boas práticas ou
84
atendem a desafios no gerenciamento de projetos no DDS foram relacionados com
as evidências das questões Q1 e Q2. Esta relação foi proposta por Costa (2009).
Figura 4.1 - Relação entre as questões de pesquisa Fonte: Costa (2009)
A Tabela 4.5 apresenta a relação de desafios e melhores práticas identificados
na literatura. A primeira coluna apresenta os desafios, na segunda coluna, os
estudos que relacionam o desafio a uma melhor prática específica, e na terceira
coluna, os estudos que relacionam o desafio a uma melhor prática.
Dentre os desafios listados na Tabela 4.1, na Seção 4.2, os desafios: D7 –
Diferentes Tecnologias, D11 - Economia, D23 - Diferença Organizacional/Padrões,
Processos, Metodologias e Políticas diferentes e D24 - Gestão do Conhecimento,
não foi encontrada nenhuma prática. Então esse desafios não estão listados na
Tabela 4.5.
Tabela 4.5 - Desafios e melhores práticas Fonte: Elaboração própria, com base no mapeamento
D: Desafios MP: Melhores Práticas Referências - EP: Estudos Primários
D1. Comunicação MP1. Disponibilização/ Treinamento em ferramentas de comunicação e colaboração
EP_3, EP_6, EP_11, EP_14, EP_16, EP_27, EP_28, EP_117, EP_166, EP_188, EP_223, EP_224
MP3. Disponibilidade de vários meios de comunicação/ Ter mecanismo para comunicação face a face
EP_11, EP_41, EP_70, EP_78, EP_93, EP_103, EP_117, EP_131, EP_144, EP_186, EP_187, EP_04, EP_75, EP_103, EP_128, EP_150, EP_162, EP_224
85
MP18. Visita entre sites EP_10, EP_19, EP_21, EP_33, EP_91, EP_117, EP_128, EP_151, EP_158, EP_163
MP16. Criação de Protocolo de Comunicação
EP_41, EP_74, EP_117, EP_157, EP_04, EP_08, EP_44, EP_119,
MP17. Utilizar Redes Sociais EP_77, EP_93,
MP12. Utilizar Metodologia Ágeis EP_32, EP_67, EP_78, EP_117, EP_143,
MP23. Sincronicidade - Reuniões com horários razoáveis para a maioria dos sites
EP_29, EP_64, EP_78, EP_117,
MP21. Face a face Kickoff EP_117, EP_147, D2. Interação entre stakeholders
MP17. Utilizar Redes Sociais EP_77, EP_93,
MP12. Utilizar Metodologia Ágeis EP_32, EP_67, EP_78, EP_117, EP_143,
MP1. Disponibilização/ Treinamento em ferramentas de comunicação e colaboração
EP_3, EP_6, EP_11, EP_14, EP_16, EP_27, EP_28, EP_117, EP_166, EP_188, EP_223, EP_224
MP3. Disponibilidade de vários meios de comunicação/ Ter mecanismo para comunicação face a face
EP_11, EP_41, EP_70, EP_78, EP_93, EP_103, EP_117, EP_131, EP_144, EP_186, EP_187, EP_04, EP_75, EP_103, EP_128, EP_150, EP_162, EP_224
MP21. Face a face Kickoff EP_117, EP_147,
MP5. Promover Interação Informal
EP_11, EP_36, EP_22, EP_117, EP_118, EP_122, EP_128, EP_131, EP_146, EP_157, EP_179, EP_199, EP_98, EP_103, EP_118,
MP8. Treinamento sobre Culturas diferentes EP_68, EP_75, EP_87, EP_107, EP_117,
D3. Dispersão Geográfica MP27. Espaço físico para equipes locais EP_21, EP_68, EP_117,
D4. Diferença Cultural MP18. Visita entre sites
EP_10, EP_19, EP_21, EP_33, EP_91, EP_117, EP_128, EP_151, EP_158, EP_163
MP1. Disponibilização/ Treinamento em ferramentas de comunicação e colaboração
EP_3, EP_6, EP_11, EP_14, EP_16, EP_27, EP_28, EP_117, EP_166, EP_188, EP_223, EP_224
MP3. Disponibilidade de vários meios de comunicação/ Ter mecanismo para comunicação face a face
EP_11, EP_41, EP_70, EP_78, EP_93, EP_103, EP_117, EP_131, EP_144, EP_186, EP_187, EP_04, EP_75, EP_103, EP_128, EP_150, EP_162, EP_224
D5. Coordenação MP12. Utilizar Metodologia Ágeis EP_32, EP_67, EP_78, EP_117, EP_143,
MP14. Definição de papéis e responsabilidade EP_61, EP_70, EP_74, EP_91, EP_117,
D6. Diferença Temporal
MP23. Sincronicidade - Reuniões com horários razoáveis para a maioria dos sites
EP_29, EP_64, EP_78, EP_117,
D8. Confiança MP1. Disponibilização/ Treinamento em ferramentas de comunicação e colaboração
EP_3, EP_6, EP_11, EP_14, EP_16, EP_27, EP_28, EP_117, EP_166, EP_188, EP_223, EP_224
86
MP5. Promover Interação Informal
EP_11, EP_36, EP_22, EP_117, EP_118, EP_122, EP_128, EP_131, EP_146, EP_157, EP_179, EP_199, EP_98, EP_103, EP_118,
MP5. Promover Interação Informal
EP_11, EP_36, EP_22, EP_117, EP_118, EP_122, EP_128, EP_131, EP_146, EP_157, EP_179, EP_199, EP_98, EP_103, EP_118,
D9. Idioma/ Barreira Linguística MP1. Disponibilização/ Treinamento em
ferramentas de comunicação e colaboração
EP_3, EP_6, EP_11, EP_14, EP_16, EP_27, EP_28, EP_117, EP_166, EP_188, EP_223, EP_224
D10. Diferentes Tipos de Governos, leis, regras e regulamentos
MP6. Detalhar o planejamento EP_26, EP_28, EP_30, EP_62, EP_117, EP_118, EP_119,
D12. Cumprimento de Prazos / Gerenciar Cronograma
MP9. Gerenciar Riscos constantemente EP_70, EP_107, EP_117, EP_122, EP_155,
MP22. Gerenciar Cronograma EP_29, EP_117,EP_118, EP_122, EP_164,
D13. Orçamento MP6. Detalhar o planejamento EP_26, EP_28, EP_30, EP_62, EP_117,
EP_118, EP_119, D14. Falta de planejamento de projetos
MP6. Detalhar o planejamento EP_26, EP_28, EP_30, EP_62, EP_117, EP_118, EP_119,
D15. Propriedade Intelectual/ Confidencialidade e Privacidade
MP7. Disponibilidade de uma boa infraestrutura EP_52, EP_103, EP_117, EP_185,
MP24. Garantir confidencialidade e privacidade e propriedade intelectual EP_19, EP_64, EP_35, EP_117, EP_185,
D16. Qualidade/ Métrica
MP28. Critérios claros para atribuição de tarefas EP_12, EP_117, EP_187,
MP22. Gerenciar Cronograma EP_29, EP_117,EP_118, EP_122, EP_164,
MP15. Manter padrões de Qualidade EP_70, EP_117, EP_141, EP_142, EP_166,
D17. Infraestrutura MP7. Disponibilidade de uma boa infraestrutura EP_52, EP_103, EP_117, EP_185,
MP1. Disponibilização/ Treinamento em ferramentas de comunicação e colaboração
EP_3, EP_6, EP_11, EP_14, EP_16, EP_27, EP_28, EP_117, EP_166, EP_188, EP_223, EP_224
D18. Distribuição/ Gerenciamento de Tarefas
MP28. Critérios claros para atribuição de tarefas EP_12, EP_117, EP_187,
MP26. Visibilidade do trabalho EP_91, EP_117,
D19. Colaboração/ Cooperação
MP1. Disponibilização/ Treinamento em ferramentas de comunicação e colaboração
EP_3, EP_6, EP_11, EP_14, EP_16, EP_27, EP_28, EP_117, EP_166, EP_188, EP_223, EP_224
MP1. Disponibilização/ Treinamento em ferramentas de comunicação e colaboração
EP_3, EP_6, EP_11, EP_14, EP_16, EP_27, EP_28, EP_117, EP_166, EP_188, EP_223, EP_224
MP19. Estimular a Cooperação/Colaboração EP_43, EP_117, EP_132, EP_144,
87
D20. Gestão de Conflitos/ Gestão de Pessoa
MP11. Gerenciar/Coordenar pessoas EP_74, EP_117,
D21. Manter espírito de equipe
MP10. Motivar Equipe/Manter espírito de equipe
EP_43, EP_52, EP_98, EP_47, EP_59, EP_102, EP_117,
MP21. Face a face Kickoff EP_117, EP_147, D22. Diferentes Níveis de Conhecimento/ Transferência de Conhecimento
MP2. Transferência de conhecimento EP_02, EP_03_04, EP_11, EP_52, EP_71, EP_108, EP_117
D25. Gestão de Risco MP9. Gerenciar Riscos constantemente EP_70, EP_107, EP_117, EP_122,
EP_155, D27. Identificar Papéis e Responsabilidades
MP26. Visibilidade do trabalho EP_91, EP_117,
MP26. Visibilidade do trabalho EP_91, EP_117,
D28. Sincronização de Trabalhos entre os Sites
MP23. Sincronicidade - Reuniões com horários razoáveis para a maioria dos sites
EP_29, EP_64, EP_78, EP_117,
D29. Gestão de Escopo/Gestão de Mudança
MP20. Gestão de Configuração EP_65, EP_100, EP_101, EP_149, EP_181, EP_199, EP_203, EP_213, EP_117, EP_147, EP_186,
D30. Diferentes Stakeholders
MP4. Organizar equipe com culturas e conhecimento complementares EP_11, EP_21, EP_117, EP_122, EP_192,
D31. Aplicação de um processo iterativo Ágil
MP12. Utilizar Metodologia Ágeis EP_32, EP_67, EP_78, EP_117, EP_143,
D32. Visibilidade/Clareza de quem faz o que é onde
MP26. Visibilidade do trabalho EP_91, EP_117,
MP28. Critérios claros para atribuição de tarefas EP_12, EP_117, EP_187,
Na Tabela 4.6, apresenta-se a relação entre desafios e ferramentas. Na
primeira coluna são indicados os desafios; na segunda coluna, as ferramentas
evidenciadas na literatura para apoiar o gerenciamento e, na terceira coluna, os
estudos primários que relacionaram o desafios a determinada ferramenta.
Tabela 4.6 - Desafios e ferramentas Fonte: Elaboração própria, com base no mapeamento
D: Desafios F: Ferramenta Referências - EP: Estudos Primários
D1. Comunicação
F1. E-mail
EP_08, EP_12, EP_13, EP_24, EP_26, EP_27, EP_28, EP_32, EP_34, EP_38, EP_40, EP_41, EP_44, EP_52, EP_59, EP_60, EP_67, EP_69, EP_74, EP_75, EP_82, EP_83, EP_87, EP_91, EP_96, EP_98, EP_102, EP_110, EP_114, EP_117, EP_131, EP_133, EP_134, EP_136, EP_144, EP_147, EP_157, EP_160, EP_163, EP_173, EP_182, EP_187, EP_189, EP_192, EP_194, EP_197, EP_204, EP_205, EP_210, EP_221,
88
F4. Videoconferência
EP_12, EP_13,EP_27, EP_32, EP_41, EP_44, EP_58, EP_60, EP_69, EP_74, EP_75, EP_82, EP_83, EP_84, EP_87, EP_91, EP_96, EP_102, EP_110, EP_114, EP_117, EP_131, EP_134, EP_144, EP_146, EP_147, EP_160, EP_173, EP_174, EP_187, EP_189, EP_192, EP_194, EP_197, EP_204, EP_217, EP_221,
F5. Bate-papo (Chat)
EP_13, EP_26, EP_27, EP_32, EP_40, EP_44, EP_75, EP_87, EP_102, EP_117, EP_128, EP_146, EP_182, EP_194, EP_204, EP_52, EP_67, EP_69, EP_82, EP_91, EP_110, EP_114, EP_134, EP_ 136, EP_147, EP_149, EP_157, EP_159, EP_182, EP_187, EP_189, EP_192, EP_197, EP_214, EP_217, EP_219, EP_38, EP_182, EP_38, EP_143, EP_157, EP_160, EP_182, EP_194, EP_214
F3. Teleconferência
EP_04, EP_21, EP_58, EP_67, EP_87, EP_102, EP_117, EP_133, EP_144, EP_183, EP_187, EP_189, EP_210, EP_217, EP_221,
F2. Telefone
EP_12, EP_26, EP_32, EP_37, EP_38, EP_40, EP_41, EP_44, EP_52, EP_60, EP_69, EP_74, EP_75, EP_82, EP_83, EP_87,EP_91, EP_ 117, EP_128, EP_131, EP_134, EP_136, EP_139, EP_147, EP_149, EP_159, EP_173, EP_182, EP_189, EP_194, EP_197, EP_205, EP_210,
F6. Áudio Conferência
EP_27, EP_32, EP_34, EP_40, EP_74, EP_114, EP_117, EP_133, EP_134, EP_205,
F10. Wiki
EP_40, EP_43, EP_67, EP_91, EP_102, EP_110, EP_114, EP_ 117, EP_134, EP_144, EP_147, EP_153, EP_182, EP_183, EP_187, EP_189, EP_192, EP_194, EP_212, EP_217, EP_219, EP_221
F8. NetMeeting EP_32, EP_34, EP_74, EP_75, EP_117, EP_189, EP_194, EP_197, EP_205, EP_217,
F13. Fax EP_40, EP_44 , EP_83, EP_117, EP_197,
F16. Intranet EP_26, EP_69, EP_75, EP_87, EP_117, EP_140, EP_197, F12. Calendário de Grupo (Group calendars)
EP_40, EP_117, EP_169, EP_182, EP_194, EP_205,
F14. Jazz EP_48, EP_164, EP_192, EP_219,
F17. Fórum de discussão
EP_34, EP_74, EP_96, EP_134, EP_204
F21. TeamSpace EP_40, EP_117, EP_194,
F22. CAMEL EP_117, EP_168, EP_194, F23. NEXTMOVE
EP_117, EP_194,
F29. Webex EP_168, EP_192,
F30. Xplanner EP_215, F31. Ms Sharepoint
EP_192
F32. Costar EP_192,
F33. QSM SLIM EP_192,
F9. VoIP EP_38, EP_96, EP_133, EP_157, D4. Diferença Cultural F10. Wiki
EP_40, EP_43, EP_67, EP_91, EP_102, EP_110, EP_114, EP_ 117, EP_134, EP_144, EP_147, EP_153, EP_182, EP_183, EP_187, EP_189, EP_192, EP_194, EP_212, EP_217, EP_219, EP_221
D5. Coordenação F10. Wiki
EP_40, EP_43, EP_67, EP_91, EP_102, EP_110, EP_114, EP_ 117, EP_134, EP_144, EP_147, EP_153, EP_182, EP_183, EP_187, EP_189, EP_192, EP_194, EP_212, EP_217, EP_219, EP_221
89
F12. Calendário de Grupo (Group calendars)
EP_40, EP_117, EP_169, EP_182, EP_194, EP_205,
F26. Assembla EP_168, EP_192,
F30. Xplanner EP_215, D8. Confiança
F10. Wiki EP_40, EP_43, EP_67, EP_91, EP_102, EP_110, EP_114, EP_ 117, EP_134, EP_144, EP_147, EP_153, EP_182, EP_183, EP_187, EP_189, EP_192, EP_194, EP_212, EP_217, EP_219, EP_221
F19. Galeria de fotos (Photo Gallery)
EP_117, EP_144, EP_189, EP_194,
D9. Idioma/ Barreira Linguística
F1. E-mail
EP_08, EP_12, EP_13, EP_24, EP_26, EP_27, EP_28, EP_32, EP_34, EP_38, EP_40, EP_41, EP_44, EP_52, EP_59, EP_60, EP_67, EP_69, EP_74, EP_75, EP_82, EP_83, EP_87, EP_91, EP_96, EP_98, EP_102, EP_110, EP_114, EP_117, EP_131, EP_133, EP_134, EP_136, EP_144, EP_147, EP_157, EP_160, EP_163, EP_173, EP_182, EP_187, EP_189, EP_192, EP_194, EP_197, EP_204, EP_205, EP_210, EP_221,
D18. Distribuição/ Gerenciamento de Tarefas
F15. TAMRI EP_68,EP_117, EP_192, EP_194,
F30. Xplanner EP_215, F23. NEXTMOVE
EP_117, EP_194,
D19. Colaboração/ Cooperação
F1. E-mail
EP_08, EP_12, EP_13, EP_24, EP_26, EP_27, EP_28, EP_32, EP_34, EP_38, EP_40, EP_41, EP_44, EP_52, EP_59, EP_60, EP_67, EP_69, EP_74, EP_75, EP_82, EP_83, EP_87, EP_91, EP_96, EP_98, EP_102, EP_110, EP_114, EP_117, EP_131, EP_133, EP_134, EP_136, EP_144, EP_147, EP_157, EP_160, EP_163, EP_173, EP_182, EP_187, EP_189, EP_192, EP_194, EP_197, EP_204, EP_205, EP_210, EP_221,
F23. NEXTMOVE
EP_117, EP_194,
F4. Videoconferência
EP_12, EP_13,EP_27, EP_32, EP_41, EP_44, EP_58, EP_60, EP_69, EP_74, EP_75, EP_82, EP_83, EP_84, EP_87, EP_91, EP_96, EP_102, EP_110, EP_114, EP_117, EP_131, EP_134, EP_144, EP_146, EP_147, EP_160, EP_173, EP_174, EP_187, EP_189, EP_192, EP_194, EP_197, EP_204, EP_217, EP_221,
F5. Bate-papo (Chat)
EP_13, EP_26, EP_27, EP_32, EP_40, EP_44, EP_75, EP_87, EP_102, EP_117, EP_128, EP_146, EP_182, EP_194, EP_204, EP_52, EP_67, EP_69, EP_82, EP_91, EP_110, EP_114, EP_134, EP_ 136, EP_147, EP_149, EP_157, EP_159, EP_182, EP_187, EP_189, EP_192, EP_197, EP_214, EP_217, EP_219, EP_38, EP_182, EP_38, EP_143, EP_157, EP_160, EP_182, EP_194, EP_214,
F2. Telefone
EP_12, EP_26, EP_32, EP_37, EP_38, EP_40, EP_41, EP_44, EP_52, EP_60, EP_69, EP_74, EP_75, EP_82, EP_83, EP_87,EP_91, EP_ 117, EP_128, EP_131, EP_134, EP_136, EP_139, EP_147, EP_149, EP_159, EP_173, EP_182, EP_189, EP_194, EP_197, EP_205, EP_210,
F18. Quadros Virtuais (Virtual whiteboards)
EP_114, EP_117, EP_134, EP_189, EP_192, EP_194, EP_204,
F19. Galeria de fotos (Photo Gallery)
EP_117, EP_144, EP_189, EP_194,
F27. GliFFy EP_168,
F26. Assembla EP_168, EP_192,
90
F17. Fórum de discussão
EP_34, EP_74, EP_96, EP_134, EP_204
D20. Gestão de Conflitos/ Gestão de Pessoa
F22. CAMEL EP_117, EP_168, EP_194,
F27. GliFFy EP_168,
F21. TeamSpace EP_40, EP_117, EP_194,
Na Tabela 4.7, apresenta–se a relação entre desafios e modelos. Na primeira
coluna são indicados os desafios; na segunda, modelos evidenciados na literatura
como possíveis soluções e, na terceira coluna, os estudos que relacionam o
desafios a um modelo.
Tabela 4.7 - Desafios e modelos Fonte: Elaboração própria, com base no mapeamento
D: Desafios Modelos Referência - EP: Estudos Primários
D1. Comunicação M10. Approach to offshore collaboration EP_32, EP_117,
EP_194 M11. Framework for supporting management in distributed information systems development
EP_117, EP_194
M8. Project management framework EP_117, EP_194 M6. Solar system EP_117, EP_194 M5. DRiMaP—a model of distributed risk management EP_140, EP_194
M13. GSD model EP_52, EP_59, EP_194
D3. Dispersão Geográfica M3. A reference model for global software development EP_194
D5. Coordenação M11. Framework for supporting management in distributed information systems development
EP_117, EP_194
M14. Framework to enable coordination in distributed software development EP_117, EP_194
M6. Solar system EP_117, EP_194 M5. DRiMaP—a model of distributed risk management EP_140, EP_194
M13. GSD model EP_52, EP_59, EP_194
D8. Confiança M1. TAPER EP_06, EP_117, EP_194, EP_210
M7. Dyadic model EP_194 D14.Falta de planejamento de projetos M2. Project management model EP_117, EP_194
D17. Infraestrutura M4. Conceptual model for managing an international IS development project EP_117, EP_194
91
D18. Distribuição/ Gerenciamento de Tarefas M12.NEXTMOVE EP_117, EP_194
D20. Gestão de Conflitos/ Gestão de Pessoa M4. Conceptual model for managing an
international IS development project EP_117, EP_194
M6. Solar system EP_117, EP_194 D22. Diferentes Níveis de Conhecimento/ Transferência de Conhecimento
M10. Approach to offshore collaboration EP_32, EP_117, EP_194
D23. Diferença Organizacional/ Padrões, Processos, Metodologias e Políticas diferentes
M10. Approach to offshore collaboration EP_32, EP_117, EP_194
D24. Gestão do Conhecimento M9. Process maturity framework for managing distributed development EP_117, EP_194
D26. Monitoramento e Controle M11. Framework for supporting management in distributed information systems development
EP_117, EP_194
D32. Visibilidade/Clareza de quem faz o que é onde M6. Solar system EP_117, EP_194
Na Tabela 4.8, apresenta-se a relação entre melhores práticas e ferramentas.
Na primeira coluna são indicadas as categorias de melhores práticas; na segunda,
as ferramentas evidenciadas na literatura de apoio às práticas e, na terceira coluna,
os estudos que relacionam a prática a uma ferramenta.
Tabela 4.8 - Melhores práticas e ferramentas Fonte: Elaboração própria, com base no mapeamento
MP: Melhores Práticas F: Ferramentas Referências - EP: Estudos Primários
MP1. Disponibilização/ Treinamento em ferramentas de comunicação e colaboração
F1. E-mail
EP_08, EP_12, EP_13, EP_24, EP_26, EP_27, EP_28, EP_32, EP_34, EP_38, EP_40, EP_41, EP_44, EP_52, EP_59, EP_60, EP_67, EP_69, EP_74, EP_75, EP_82, EP_83, EP_87, EP_91, EP_96, EP_98, EP_102, EP_110, EP_114, EP_117, EP_131, EP_133, EP_134, EP_136, EP_144, EP_147, EP_157, EP_160, EP_163, EP_173, EP_182, EP_187, EP_189, EP_192, EP_194, EP_197, EP_204, EP_205, EP_210, EP_221,
F2. Telefone
EP_12, EP_26, EP_32, EP_37, EP_38, EP_40, EP_41, EP_44, EP_52, EP_60, EP_69, EP_74, EP_75, EP_82, EP_83, EP_87,EP_91, EP_ 117, EP_128, EP_131, EP_134, EP_136, EP_139, EP_147, EP_149, EP_159, EP_173, EP_182, EP_189, EP_194, EP_197, EP_205, EP_210,
F3. Teleconferência EP_04, EP_21, EP_58, EP_67, EP_87, EP_102, EP_117, EP_133, EP_144, EP_183, EP_187, EP_189, EP_210, EP_217, EP_221,
92
F4. Videoconferência
EP_12, EP_13,EP_27, EP_32, EP_41, EP_44, EP_58, EP_60, EP_69, EP_74, EP_75, EP_82, EP_83, EP_84, EP_87, EP_91, EP_96, EP_102, EP_110, EP_114, EP_117, EP_131, EP_134, EP_144, EP_146, EP_147, EP_160, EP_173, EP_174, EP_187, EP_189, EP_192, EP_194, EP_197, EP_204, EP_217, EP_221,
F5. Bate-papo (Chat)
EP_13, EP_26, EP_27, EP_32, EP_40, EP_44, EP_75, EP_87, EP_102, EP_117, EP_128, EP_146, EP_182, EP_194, EP_204, EP_52, EP_67, EP_69, EP_82, EP_91, EP_110, EP_114, EP_134, EP_ 136, EP_147, EP_149, EP_157, EP_159, EP_182, EP_187, EP_189, EP_192, EP_197, EP_214, EP_217, EP_219, EP_38, EP_182, EP_38, EP_143, EP_157, EP_160, EP_182, EP_194, EP_214,
F6. Áudio Conferência
EP_27, EP_32, EP_34, EP_40, EP_74, EP_114, EP_117, EP_133, EP_134, EP_205,
F7. Voicemail EP_34, EP_74, EP_117,
F8. NetMeeting EP_32, EP_34, EP_74, EP_75, EP_117, EP_189, EP_194, EP_197, EP_205, EP_217,
F9. VoIP EP_38, EP_96, EP_133, EP_157,
F10. Wiki
EP_40, EP_43, EP_67, EP_91, EP_102, EP_110, EP_114, EP_ 117, EP_134, EP_144, EP_147, EP_153, EP_182, EP_183, EP_187, EP_189, EP_192, EP_194, EP_212, EP_217, EP_219, EP_221
F11. Blog EP_40, EP_117, EP_147, EP_187, EP_189, EP_194, F13. Fax EP_40, EP_44 , EP_83, EP_117, EP_197, F14. Jazz EP_48, EP_164, EP_192, EP_219, F15. TAMRI EP_68,EP_117, EP_192, EP_194, F17. Fórum de discussão EP_34, EP_74, EP_96, EP_134, EP_204 F18. Quadros Virtuais (Virtual whiteboards)
EP_114, EP_117, EP_134, EP_189, EP_192, EP_194, EP_204,
F20. Jira EP_117, EP_144, EP_168, EP_192, F21. TeamSpace EP_40, EP_117, EP_194, F24. Groupware EP_40, EP_75, EP_87, EP_99, EP_192, EP_194, F25. ActiveCollab EP_168,EP_192, F26. Assembla EP_168, EP_192, F27. GliFFy EP_168,
F28. Repositório de lições aprendidas EP_14, EP_117, EP_ 223 F29. Webex EP_168, EP_192, F30. Xplanner EP_215, F31. Ms Sharepoint EP_192 F32. Costar EP_192, F33. QSM SLIM EP_192,
93
MP3. Disponibilidade de vários meios de comunicação/ Ter mecanismo para comunicação face a face
F1. E-mail
EP_08, EP_12, EP_13, EP_24, EP_26, EP_27, EP_28, EP_32, EP_34, EP_38, EP_40, EP_41, EP_44, EP_52, EP_59, EP_60, EP_67, EP_69, EP_74, EP_75, EP_82, EP_83, EP_87, EP_91, EP_96, EP_98, EP_102, EP_110, EP_114, EP_117, EP_131, EP_133, EP_134, EP_136, EP_144, EP_147, EP_157, EP_160, EP_163, EP_173, EP_182, EP_187, EP_189, EP_192, EP_194, EP_197, EP_204, EP_205, EP_210, EP_221,
F2. Telefone
EP_12, EP_26, EP_32, EP_37, EP_38, EP_40, EP_41, EP_44, EP_52, EP_60, EP_69, EP_74, EP_75, EP_82, EP_83, EP_87,EP_91, EP_ 117, EP_128, EP_131, EP_134, EP_136, EP_139, EP_147, EP_149, EP_159, EP_173, EP_182, EP_189, EP_194, EP_197, EP_205, EP_210,
F3. Teleconferência EP_04, EP_21, EP_58, EP_67, EP_87, EP_102, EP_117, EP_133, EP_144, EP_183, EP_187, EP_189, EP_210, EP_217, EP_221,
F4. Videoconferência
EP_12, EP_13,EP_27, EP_32, EP_41, EP_44, EP_58, EP_60, EP_69, EP_74, EP_75, EP_82, EP_83, EP_84, EP_87, EP_91, EP_96, EP_102, EP_110, EP_114, EP_117, EP_131, EP_134, EP_144, EP_146, EP_147, EP_160, EP_173, EP_174, EP_187, EP_189, EP_192, EP_194, EP_197, EP_204, EP_217, EP_221,
F5. Bate-papo (Chat)
EP_13, EP_26, EP_27, EP_32, EP_40, EP_44, EP_75, EP_87, EP_102, EP_117, EP_128, EP_146, EP_182, EP_194, EP_204, EP_52, EP_67, EP_69, EP_82, EP_91, EP_110, EP_114, EP_134, EP_ 136, EP_147, EP_149, EP_157, EP_159, EP_182, EP_187, EP_189, EP_192, EP_197, EP_214, EP_217, EP_219, EP_38, EP_182, EP_38, EP_143, EP_157, EP_160, EP_182, EP_194, EP_214,
F6. Áudio Conferência
EP_27, EP_32, EP_34, EP_40, EP_74, EP_114, EP_117, EP_133, EP_134, EP_205,
F7. Voicemail EP_34, EP_74, EP_117,
F8. NetMeeting EP_32, EP_34, EP_74, EP_75, EP_117, EP_189, EP_194, EP_197, EP_205, EP_217,
F9. VoIP EP_38, EP_96, EP_133, EP_157,
F10. Wiki EP_40, EP_43, EP_67, EP_91, EP_102, EP_110, EP_114, EP_ 117, EP_134, EP_144, EP_147, EP_153, EP_182, EP_183, EP_187, EP_189, EP_192, EP_194, EP_212, EP_217, EP_219, EP_221
F11. Blog EP_40, EP_117, EP_147, EP_187, EP_189, EP_194, F13. Fax EP_40, EP_44 , EP_83, EP_117, EP_197, F17. Fórum de discussão EP_34, EP_74, EP_96, EP_134, EP_204 F18. Quadros Virtuais (Virtual whiteboards)
EP_114, EP_117, EP_134, EP_189, EP_192, EP_194, EP_204,
F28. Repositório de lições aprendidas EP_14, EP_117, EP_ 223
MP13. Sincronização de Trabalhos entre sites
F5. Bate-papo (Chat)
EP_13, EP_26, EP_27, EP_32, EP_40, EP_44, EP_75, EP_87, EP_102, EP_117, EP_128, EP_146, EP_182, EP_194, EP_204, EP_52, EP_67, EP_69, EP_82, EP_91, EP_110, EP_114, EP_134, EP_ 136, EP_147, EP_149, EP_157, EP_159, EP_182, EP_187, EP_189, EP_192, EP_197, EP_214, EP_217, EP_219, EP_38, EP_182, EP_38, EP_143, EP_157, EP_160, EP_182, EP_194, EP_214,
94
F2. Telefone
EP_12, EP_26, EP_32, EP_37, EP_38, EP_40, EP_41, EP_44, EP_52, EP_60, EP_69, EP_74, EP_75, EP_82, EP_83, EP_87,EP_91, EP_ 117, EP_128, EP_131, EP_134, EP_136, EP_139, EP_147, EP_149, EP_159, EP_173, EP_182, EP_189, EP_194, EP_197, EP_205, EP_210,
F21. TeamSpace EP_40, EP_117, EP_194, F29. Webex EP_168, EP_192,
MP28. Critérios claros para atribuição de tarefas
F15. TAMRI EP_68,EP_117, EP_192, EP_194, F31. Ms Sharepoint EP_192 F30. Xplanner EP_215,
Na Tabela 4.9, apresenta-se a relação entre melhores práticas e modelos. Na
primeira coluna são indicadas as categorias de melhores práticas; na segunda,
modelos evidenciados na literatura de apoio às práticas e, na terceira coluna, os
estudos relacionados a prática a um modelo.
Tabela 4.9 - Melhores práticas e modelos Fonte: Elaboração própria, com base no mapeamento
MP: Melhores Práticas Modelos Referência - EP: Estudos Primários
MP2. Transferência de conhecimento
M10. Approach to offshore collaboration EP_32, EP_117, EP_194
MP3. Disponibilidade de vários meios de comunicação/ Ter mecanismo para comunicação face a face
M4. Conceptual model for managing an international IS development project
EP_117, EP_194
MP7. Disponibilidade de uma boa infraestrutura
M4. Conceptual model for managing an international IS development project
EP_117, EP_195
MP11. Gerenciar/Coordenar pessoas M6. Solar system EP_117, EP_194
MP19. Estimular a Cooperação/Colaboração
M9. Process maturity framework for managing distributed development
EP_117, EP_194
MP26. Visibilidade do trabalho M6. Solar system EP_117, EP_194 MP28. Critérios claros para atribuição de tarefas M12.NEXTMOVE EP_117, EP_194
4.3 Apresentação das respostas das evidências Nessa seção, são apresentados as respostas para cada questão de pesquisa.
Na Seção 4.3.1 são apresentadas as evidências quanto aos desafios no
gerenciamento de projetos no DDS. Na Seção 4.3.2 são apresentadas as evidências
quanto as boas práticas para o gerenciamento de projetos no DDS. Na Seção 4.3.3
95
são descritas as ferramentas que são utilizadas para apoiar o gerenciamento no
cenário distribuído. Por fim, na Seção 4.3.4 são descritos os modelos que são
utilizados para apoiar o gerenciamento no cenário distribuído. Todas as evidências
são apresentadas com a devida referência. Os 224 estudos primários que se
encontram no apêndice A, são referenciados com um prefixo EP (Estudo Primário),
mais uma numeração de 1 a 224 na ordem em que são dispostos, e a avaliação de
qualidade.
4.3.1 Q1: Desafios no gerenciamento de projetos no DDS Q1: Quais os principais desafios no gerenciamento de projetos no desenvolvimento distribuído de software?
Esta questão buscou identificar e investigar os principais desafios no
gerenciamento de projetos no DDS. A partir dos 224 estudos primários analisados,
31 desafios foram identificados pela pesquisa. Os desafios são apresentados a
seguir.
D1 . Comunicação
O desafio “comunicação” é visto pela maioria dos trabalhos com um fator chave
para o sucesso e difícil de ser conduzida de maneira eficiente em um ambiente
distribuído. Portanto, a comunicação formal quanto a informal são essenciais para o
gerenciamento do projeto e devem ser incentivadas pela gerência.
Dos 224 estudos primários analisados, 140 apontam a comunicação como um
desafio. Segundo as evidências coletadas, a comunicação informal é quase ausente
nas equipes, acarretando uma série de outros problemas, como: falta de
concordância, de espírito de equipe e baixa colaboração nas tarefas. Mesmo quando
é possível a comunicação síncrona, nem sempre existem estrutura para a
comunicação face a face, o que reduz o contato, levando uma menor confiança e
produtividade.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
96
§ EP_02: “Despite the availability of sophisticated collaboration tools,
virtual project teams struggle to meet stated project outcomes due to
challenges related to communication, developing a shared
understanding, and geographic and cultural dispersion.”
§ EP_98: “Communication and cooperation in DSD projects are normally
electronic with limited opportunities for synchronous contact, due to
geographical location and time zone differences.” § EP_163: “Other challenges to GSD are trust among the companies
which is lead by Difference Cultural differences and lack of informal
communication among the two. Because the team is not aware of the
culture of the other team and so on hence decreasing productivity.”
D2. Interação entre Stakeholders
A complexidade de se reunir pessoas de uma variedade de domínios técnicos
e funcionais . Os desafios desta mistura heterogênea conhecimento tornar-se ainda
mais aguda como as equipes de projeto interagir com outros grupos de
stakeholders. No desenvolvimento distribuído de software, a interação entre a
equipe e essencial, pois uma equipe que não interage, pode não contribuir e
colaborar com a realização das tarefas. Fazer com que toda a equipe se interaja é
um desafio.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
§ EP_21: “In the interaction of the stakeholders, there were a number of
processes that signaled the need for a collective interpretive effort....
The challenges of this heterogeneous knowledge mix become even
more acute as project teams interact with other stakeholder groups”.
§ EP_147: “However, these projects face numerous management
challenges that are inherent to their distributed nature, e.g., limited
social interaction ... language barriers..., and time zone differences.”
97
D3. Dispersão Geográfica
A distância geográfica pode ser medida pelo esforço que um participante
precisa fazer para ir até outro site, as condições de transporte, tempo necessário de
viajar de um local para outro, se deparando com culturas e fuso-horários. Tudo isso
pode dificultar ainda mais a possibilidade de contato face a face das equipes.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
§ EP_37: “Geographic separation is generally associated with: increased
coordination challenges, more delays, communication problems, and
differences in feedback cycles.”
§ EP_91: "Geographic distance introduces numerous barriers to
collaboration, the most immediate being the lack of informal encounters
that provide not only the opportunity to exchange implicit knowledge,
but also to develop personal relationships.”
D4. Diferença Cultural/ Integração social
As diferenças culturais são tidas como desafios no gerenciamento de projetos
distribuídos. Valores, estilos, modo de expressão e comunicação definem a cultura
de um país. Diferentes stakeholders trabalhando em conjunto, pode haver
comportamentos e pensamentos diferentes, gerando conflitos entre as equipes.
Cada localidade possui sua própria cultura, como: política, atitudes em relação
a hierarquia, tempo de trabalho (carga horária e modalidade de trabalho), feriados
(calendários diferentes), férias e entre outros. A forma de alguém escrever um E-
mail, em que a comunicação pode ser direta, pode parecer inculto para alguém de
uma cultura diferente.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
§ EP_07: “Our findings indicate that ‘language and cultural barriers’,
‘country instability’, ‘lack of project management’, ‘lack of protection for
intellectual property rights’ and ‘lack of technical capability’ have a
negative impact on software development outsourcing clients in the
98
selection of software development outsourcing vendors.”
§ EP_28: “A second area where problems can arise in crossborder
outsourcing is in the Difference Cultural adaptation of the bridgehead
teams working in the client countries. Challenges not only concern the
need to adapt to different ways of working but to Difference Cultural
norms of Difference Cultural behavior, attitudes toward authority, and
language issues.”
§ EP_180: “Difference Cultural understanding, i.e., culture influences
interpretation of communication, Difference Cultural norms can lead to
conflicting approaches for problem solving.”
§ EP_47: “Also, social integration is generally considered a key challenge
because the presence of several cultures in GDSPs creates an
environment significantly different from that of collocated projects.”
D5. Coordenação
A coordenação de diversas equipes de desenvolvimento é complicada, devido
a envolver a integração de cada tarefa atribuída aos locais de desenvolvimento
diferentes para atingir o objetivo global do projeto. Desafios como: cultura, idioma,
diferentes tecnologias, interfere na realização de tarefas interdependentes exigindo
algum modelo de coordenação.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
§ EP_32: “Coordination of various activities during systems development
is often a major problem that contributes to the project failure, and the
magnitude of the problem increases for strategic systems developed in
dispersed locations.”
§ EP_43: “A combination of the increased size and complexity of the
system to be developed, as well as the new challenges listed that come
with managing a distributed project, may make it extremely difficult for a
project manager to control and coordinate all of the activities associated
with modern software development projects.”
99
§ EP_171: "These problems, which are going to have a negative impact
in the development of software, are mainly grounded in the distance ....
and in the fact of merging people coming from different cultures and
speaking different languages, with different levels of knowledge and
technical skill capabilities ... All of these make more difficult the process
of communication, coordination, and control."
D6. Dispersão Temporal
A dispersão temporal torna a atividade das equipes ainda mais difícil, devido
aos diferentes fusos-horários. Com isso, as equipes buscam contornar estas
dificuldades através da comunicação assíncrona. Como por exemplo: se tiver um
projeto sendo realizado em diferentes continentes, a realização de uma reunião,
torna-se uma atividade complexa, pois o horário sempre vai estar inconveniente para
algum membro da equipe.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
§ EP_91: “Another frequently identified barrier is the time zone difference
encountered when development is distributed around the globe. Often
termed “Difference Temporal distance,” the main problem with having
developers working in different time zones is that there are fewer hours
in the work day when multiple sites can participate in synchronous
meetings.”
§ EP_212: “Time difference leads to delays because of less overlapping
working hours. Furthermore, geographical distance leads to delays
because it increases the unresponsiveness of practitioners. This
challenge amplifies that of culture, as empirically supported by ...”
D7. Diferentes Tecnologias
A intensa variedade de tecnologias disponíveis para auxiliar o gerenciamento
de projetos distribuídos, pode levar a uma divergência nas aplicações dos diferentes
parceiros, podendo haver incompatibilidade na utilização de diferentes ferramentas,
100
tecnologias de informação e comunicação, ambientes de desenvolvimento,
linguagens de programação, plataforma e na maneira de usá-los. Podendo a equipe
as vezes nem se quer conhecer a ferramenta utilizada pela outra.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
§ EP_29: “Although their members need time to adapt to the technology
and new team form, they have often been found to be able to do so
satisfactorily.” § EP_81: “The difference of technological platforms used by GSD
partners can induce great problems especially during the phase of
tests.”
D8. Confiança
Devido a dispersão física da equipe, estabelecer confiança entre sites não é
uma tarefa cândido. A distância geográfica entre as equipes e a falta de
comunicação informal, ou até mesmo do simples cafezinho de corredor, pode reduzir
a confiança entre os stakeholders.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
§ EP_29: “Trust. Trust development in virtual teams also presents
significant challenges because it is difficult to assess teammates’
trustworthiness without ever having met them.... Moreover, as the life of
many virtual teams is relatively limited, trust must quickly develop....
Yet, trust development is deemed crucial for the successful completion
of virtual team projects.”
§ EP_43: “Peer evaluations breed trust between co-workers, which is
difficult to develop in a distributed project environment; efforts should be
made to enhance trust whenever possible.”
101
D9. Idioma/Barreira Linguísticas
O idioma entre as diversas equipes distribuída, é um desafio para o
gerenciamento do projeto, dificultando a comunicação. Assim, alguns membros de
equipe deixam de se comunicar através de comunicação síncrona por deficiência ou
medo de falar em outro idioma.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
§ EP_37: “Language differences caused time overruns, extra cost and
effort, and lower system quality in eight projects. In virtually all projects,
English was used as a common business language when project team
members spoke different languages. However, even when all team
members spoke a common business language, various problems
emerged. Non-native speakers usually had difficulties in reading
between the lines and understanding subtle differences in what is being
communicated. As a result, language barriers caused reduced project
participation of non-native speakers, less frequent communications,
longer time for communications, and misunderstandings, which
eventually led to lower project performance...”
§ EP_91: “This affects not only the quality of communication, but the
choice of communication media. For example, team members who are
not confident with their English language skills may prefer instant
messaging or email over telephone or video conferencing, as text-
based media provide more time to comprehend and compose a
response. But text-based media do not convey the visual or auditory
queues that convey important information such as how well a
participant truly understands a conversation."
D10. Diferentes Tipos de Governos, leis, regras e regulamentos
O desenvolvimento distribuído de um projeto pode envolver várias questões,
como diferentes tipos de governo, leis, regras e regulamentos. As equipes algumas
vezes são formadas sem o conhecimento do negócio, das leis e regulamentos que
regem alguns sites.
102
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_130: “Governmental issues the government rules and regulations
(procedures and legislations) vary in different countries and cultures.
Making the different governmental issues compatible with each other in
GDSD is a problematic issue. Other problems include immigration work
laws, visa permits, import rules and regulations, and export rules and
regulations. The inadequate support received from governaments
creates additional challenges”.
D11. Economia
O crescimento da indústria de terceirização de software, está se expandindo
para oferecer tanto uma maior escolha de locais e uma ampla gama de serviços. No
entanto, também atraiu a atenção devido à complexidade e os desafios relacionados
com as questões econômicas do país.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_81: “Offshore outsourcing investment in emerging economies
involves barriers associated with unstable institutions (economic, legal,
politics). According to Lessard, Although expropriation and war are the
most visible and dramatic forms that such political risk can take,
uncertainty about local governments’ economic and regulatory policies
may actually lead to larger reductions in the expected values of
overseas projects”.
D12. Cumprimento de prazo/ Gerenciar cronograma
A estimativa de prazos em projetos de desenvolvimento de software é uma
atividade árdua. Com equipes distribuída e um desafio cumprir os prazos estimulado
pelo cronograma, pois as tarefas do projeto podem ter sido determinada, sem o seu
conhecimento de complexidade.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
103
§ EP_29: "Software project failure has been studied extensively in the IT
project management literature. To address this issue, scholars have
spent considerable time identifying risk factors. IT project risks
frequently materialize in delays, resource overruns, and Project
abandonment. Such problems reduce the net benefits that a client
organization reaps from the use of IT."
D13. Orçamento
Um dos principais desafios para o gerenciamento de projeto, e fazer suas
equipes globais trabalhar de forma eficaz para entregar sistemas no prazo e dentro
do orçamento estimulado.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
§ EP_07: "Therefore, one of the key challenges for IS organizations today
is to find ways to make their global project teams work effectively and to
deliver quality systems on time and within budget."
§ EP_37: “However, several project managers indicated that budgets and
timelines had to be revised at least once during a project to account for
the additional effort needed to make global projects succeed in the
presence of global barriers.” - "Therefore, one of the key challenges for
IS organizations today is to find ways to make their global project teams
work effectively and to deliver quality systems on time and within
budget."
D14. Planejamento do projeto
O planejamento de projetos distribuídos é uma alternativa para se alcançar o
sucesso do mesmo, sendo comum planos atrasados sem muitos detalhes, além de
pouca oportunidade para a equipe interagir informalmente, para esclarecer dúvidas.
Planejamento mal elaborado, sem prever feriados, datas comemorativas de acordo
com a cultura de cada país, pode levar o projeto ao fracasso.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
104
§ EP_07: “... ‘lack of Project management’ as a barrier that can have a
negative impact on outsourcing clients. In the outsourcing process an
effective Project management plays a vital role as it has been a difficult
task to manage the geographical distributed teams; have found that
improving the project planning is an effective tool in dealing with high-
risk projects; have reported the impact of project planning on project
duration; have described the ‘lack of project planning’ as a risk to
software projects.”
D15. Propriedade intelectual/ Garantir confidencialidade e privacidade
Devido a distribuição de equipes, os engenhos e ferramentas de
disponibilização e compartilhamento de conhecimento devem garantir a
confidencialidade e privacidade das informações da organização. Sendo,
fundamental a gerência de projeto garantir e legalizar toda a questão de direito
autorais e a propriedade intelectual.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_19: “how people can balance the awareness information they want
others to have of their work with their own privacy needs. (first and
foremost, note that privacy is not just a technical issue) ... Rather, it is
heavily dependent on the group culture and the actual practice of use
that develops over time.”
D16. Qualidade/ Métrica
Ao se falar em qualidade em ambientes de desenvolvimento distribuído, o
primeiro contratempo é que as equipes distribuídas não possuem processo de
desenvolvimentos iguais. Cada equipe realiza sua tarefa de acordo com seus
processos e procedimentos internos, com diferentes padrões de qualidade. Utilizar
métricas para acompanhar o processo de atividade das equipes se torna difícil,
devido estarem em mais de um site.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
105
§ EP_118: “But, when the team is distributed, barriers (collaboration
perspective) impact activities in the other perspectives. In our case,
ambiguity adversely affected software quality.”
§ EP_166: “For value-based software engineering, the need for a
common understanding of the prioritization of software quality aspects
by key stakeholders is crucial.”
D17. Infraestrutura
O planejamento da infraestrutura é fundamental para a realização de projetos
distribuídos. A integração entre a equipe deve ser basicamente por tecnologias de
comunicação, toda a infraestrutura de rede (conectividade, banda, velocidade),
hardware e software devem ser bem pensado. A segurança definida na
infraestrutura deve garantir que a propriedade intelectual e outros conhecimentos
não sejam acessados, por pessoas não autorizadas, e garantindo a comunicação
segura.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_91: “Inadequate knowledge management infrastructure can inhibit
the formation of a shared understanding among project teams.” –
“Geographic distance means face-to-face meetings are not possible, so
distributed teams must rely on video and teleconferencing infrastructure
to communicate; even intermittent failures of these Technologies can
mean that communication simply does not take place.”
D18. Distribuição/ Gerenciamento de tarefas
A distribuição de tarefas entre equipes remotas e o gerenciamento das
mesmas, é um grande desafio. A escassez em visualizar a competência de dos
parceiros e habilidades pode levar a uma má atribuição de tarefas. O entendimento
por parte da equipe sobre o raciocínio, a prioridade e atribuição que deve ter cada
tarefa, é de suma importância.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
106
§ EP_11: “The delivery and understanding of a message is the pivotal
element for team members as they Exchange information, coordinate
efforts, provide feedback, and comprehend each other in order to
complete the tasks at hand.”
§ EP_129: “On the other hand, returning to an interrupted task is also
rather difficult for people, as they have to remember what the last thing
they were doing in relation to that interrupted task. Another issue stated
in, is that when workers are performing a task they often and ideally
tend to delay their response to an interaction with the purpose of
finishing the task at hand before attending the new interaction request.”
D19. Colaboração/ Cooperação
Garantir a colaboração e cooperação entre as equipes distribuídas é uma
tarefa difícil para o gerente de projeto. A falta de confiança no membro da equipe
contribui para que não aconteça cooperação na realização ou esclarecimento de
tarefas.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
§ EP_12: “When little or no trust exists within ateam, serious collaboration
problems may occur, such as poor decision-making, hampered
information exchange, an increased risk of misunderstandings and
mounting personal conflicts.”
§ EP_222: “...cooperative work is attributed to mutual interdependence of
tasks among multiple users to produce specific products or services.”
D20. Gestão de Conflitos/ Gestão de pessoas
A gestão de pessoas em projetos distribuídos envolve manutenção, alistamento
e treinamento, podendo ser difícil de realizar-se de maneira eficaz. Conflitos entre as
equipes podem ocorrer devido a pressão de cumprir os prazos apertados, E-mails
mal interpretados e reuniões tensas. Gerenciar uma equipe com pessoas de
diversos lugares e chegar a um acordo é um desafio.
107
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_13: “Competitive conflict represents a behavior that team members
seek their individuals’ goal that consequently aggregate to the
achievement of the team.”
D21. Construir/ Manter espírito de equipe
Os membros de equipes estão em locais distantes, tornando mais difícil criar o
comprometimento. Manter o espírito de equipe é essencial para garantir a
colaboração e cooperação de alta qualidade. O compartilhamento de informação,
fica difícil diante de diferentes processos, culturas, idioma e a ausência de um
mesmo ambiente físico de trabalho, levando a falta de sentimento de equipe.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_194: “On the other hand, the studies found that communication
barriers have negative impact on cooperation among workers, increase
the problems with conflict resolution, and reduce the sense of cohesion
and team spirit.”
D22. Diferentes Níveis de Conhecimento/ Transferência de Conhecimento/ Compartilhar Informações
Devido a comunicação ser menor em entre equipes distribuídas
geograficamente, o conhecimento da equipe não se desenvolve de forma brilhante
como aconteceria em uma equipe local. Podendo haver desarmonia no
conhecimento que os sites tem sobre a realização de alguma tarefa ou aplicação.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
§ EP_36: “Detailed, comprehensive documentation as well as codified,
explicit knowledge is critical in global contexts because communication
is problematic and tacit knowledge is difficult to share.”
§ EP_69: “One of the challenges is that the project suffers from changes
in staff. mention that the retrenchment of onshore staff to be replaced
108
by offshore staff results in loss of tacit, hard-to-transfer software
process knowledge... Sometimes staff members leave or join in the
middle or towards the end of the project. This requires re-scheduling of
activities and overloading of other team members to meet deadlines.
Moreover the knowledge gap left takes additional time to overcome by
team members."
D23. Diferença Organizacional/ Padrões, Processos, Metodologias e Políticas diferentes
Diferenças organizacionais e nos padrões e processos de negócio das
organizações envolvidas é um desafio para o gerenciamento do projeto. Diferentes
normas de maturidade, padrões e política, podem tornar o projeto bastante difícil de
ser gerenciado. A metodologia utilizada pelas equipes deve ser a mesma, para evitar
diferentes entendimentos dos mesmos termos.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_34: “...considering such factors as complicated organizational
structure, many escalation levels, and different approaches in
responsibility sharing. Many organizations involved in distributed
projects are not ready to change their internal structure and processes
along with new partners.”
D24. Gestão do Conhecimento
Manter uma equipe distribuída atualizada é uma tarefa árdua. As melhores
práticas, ideias e percepções estão espalhadas em vários locais, em projetos
distribuídos, coordenar e reduzir este conhecimento é um desafio.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
§ EP_41: “The change to a knowledge-based perspective has received
attention from organizational economists, who have revised their theory
of the firm, and knowledge management researchers, who consider
knowledge as a dependent variable requiring coordination across the
109
organization.”
§ EP_47: “Knowledge management refers to how projects create,
capture, and integrate knowledge about the project task, including
goals, problems, possible solutions, and approaches.”
D25. Gestão de risco
O desenvolvimento de um projeto distribuído envolve mais riscos do que um
co-localizado, como: riscos de atraso ou falha devido à diferença cultural e linguística
e, a distância temporal, devem ser levados em conta. Devido a culturas diferentes os
riscos podem ser entendidos de diversas maneiras pela equipe. Um risco pode ser
complexo para uma equipe e simples para outra.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_107: “Risk management in globally distributed software
development (GDSD) projects is becoming a critical area of concern for
practitioners. The risks in GDSD projects can be dynamic due to the
multiplicity in various aspects of GDSD projects (e.g., multi-locations,
multi-cultures, multi-groups, multi-standards, and multi-technologies).
This multiplicity nature leads to dynamic interactions among the internal
(people, process, and technology) and external elements of a GDSD
project.”
D26. Monitoramento/ Controle
Monitorar e controlar um projeto distribuído é uma tarefa complexa para a
gerente. Ter o controle dos membros da equipe e das tarefas que estão executando
em localidades diferentes, exige um cuidado especial. para não ultrapassar os
prazos estimados.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_201: “Control is the act of adhering to goals such as financial
figures or deadlines, the different policies that apply, standards that
need to be followed while developing the software, or quality levels.”
110
D27. Identificar papéis e responsabilidades
No desenvolvimento distribuído, a realização de tarefas relativamente simples
como identificar módulos funcionalmente relacionados ou encontrar pessoas que
são especialistas, torna-se mais difícil e demorado. Isso devido a dificuldade de
identificação de papéis e responsabilidades.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_36: “we found that specific coping strategies within the same
category often played different roles in increasing flexibility or rigor;
some strategies primarily contributed to flexibility and others mainly
contributed to rigor.”
D28. Sincronização de trabalhos entre os sites
Em projetos distribuídos, trabalhar com a sincronicidade é muito difícil. Ter uma
equipe disposta a trabalhar no mesmo horário/tempo em determinado projeto é uma
atividade complexa.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_224: "…synchronization happens when the whole team is in the
same timezone, or willing to work together on the same site, the time
independent counsel."
D29. Gestão de Escopo/Gestão de Mudança
Elicitar e definir os requisitos e o escopo do projeto distribuído é uma atividade
difícil para o gerenciamento em um ambiente distribuído.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_203: “manage changes and assets across geographic boundaries
in a secure environment.”
D30. Diferentes stakeholders
111
Diversos tipos de stakeholders existem em cada projeto, cada um com
diferentes percepções e opiniões sobre o mesmo. No gerenciamento de projeto
distribuído, extrair a opinião de cada stakeholder, pode levar tempo e gerar
informação desnecessária.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_112: “Distributed teams consisting of stakeholders from different
national and organizational cultures, different geographic locations and
potentially different time zones characterize global software
engineering.”
D31. Aplicação de um processo iterativo ágil
A aplicação de técnicas iterativas torna possível os projetos responderem mais
rapidamente os requisitos dos clientes ou desafios inesperados. A utilização dessa
técnica em projeto distribuído é considerada difícil, devido a distribuição geográfica
em diferentes países e culturas.
Apresenta-se algumas das transcrições de evidências relacionadas a esse
tema:
§ EP_67: “Agile methods have been gaining acceptance in the
mainstream software development community. At the same time,
globally distributed software development is another trend delivering
high-quality software to global users at lower costs. The overall
performance and satisfaction with the international deployment of the
latest version of My Yahoo! Increased by more than 30% after the
global product team, distributed over three continents, adopted.”
§ EP_170: “Agile methodologies recognize that a close relationship with
the customer and face-to-face communications are crucial for success
in software development...”
D32. Visibilidade/ Clareza de quem faz o que é quando
No desenvolvimento de projetos distribuídos a visibilidade dos trabalhos das
equipes é uma tarefa difícil. Os membros da equipe geralmente não são informados
112
do processo dos colegas remotos. Por isso, essa falta de competência dos parceiros
e habilidades pode levar a uma má atribuição de tarefas e responsabilidades.
Apresenta-se uma transcrição de evidências relacionadas a esse tema:
§ EP_91: “Lack of informal communication also limits process visibility,
leading to misunderstandings and frustration on the part of remote
teams.”
4.3.2 Q2: Melhores Práticas no gerenciamento de projetos no DDS Q2: Quais as melhores práticas a serem adotadas no gerenciamento de projetos no desenvolvimento distribuído de software?
Nesta questão será abordado as boas práticas adotadas no gerenciamento de
projetos no DDS. Após as evidências coletadas no mapeamento, 28 melhores
práticas a serem adotadas no gerenciamento de projetos distribuídos foram
identificadas e sumarizadas na Tabela 4.2, na Seção 4.2. A primeira coluna
apresenta as melhores práticas extraídas dos estudos primários apresentados na
coluna dois e a terceira coluna, a quantidade de trabalhos. As melhores práticas são
citadas a seguir com suas evidências.
MP1. Disponibilização e Treinamento em ferramentas de comunicação e colaboração
No gerenciamento de projetos distribuídos a utilização de múltiplos meios de
comunicação é indispensável. As equipes necessitam de utilizar ferramentas de
comunicação e colaboração para a execução das atividades e o sucesso do projeto.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_27: "The empowerment of teams to make independent decisions
related to the project and perhaps the business is an essential
component of reinforcing the team concept. As stated previously, this
focus on the big picture is an underlying requirement for successful
virtual team implementation. Teams receiving the greatest
Independence and opportunity to make overall project decisions will
113
function as better teams and reduce the likelihood that geographic
separation will affect the project outcome."
MP2.Transferência de conhecimento
Recursos e tempo devem ser alocados para a transferência de conhecimento
entre equipes. Deve se ter um stakeholder chave na equipe para poder informar aos
novos sobre a aplicação, processos e padrões.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_11: “Team members who are experienced could positively
communicate with their colleagues to solve problems and increase their
efficiency.”
MP3. Disponibilização de múltiplos canais de comunicação/ Ter mecanismo para comunicação face a face
Uma boa prática a ser adotada em projetos distribuídos é a disponibilização de
diferentes meios de comunicação, uma vez que são equipes de culturas e idioma
diferentes.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_11: “Through communication, people convey their thoughts,
exchange ideas, express their concerns, and collectively find solutions
to their problems.”
MP4. Organizar equipe com culturas e conhecimento complementares
A criação de uma equipe pode ser determinante na sua produção, diferentes
valores e estilos de culturas fornecem boas soluções. A cultura de cada membro
deve ser respeita, incluindo seu estilo, valores e crença.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_70: “...cultural differences decrease productivity.”
114
MP5. Promover interações informal
A comunicação informal é fundamental para o sucesso de um projeto
distribuído. A introdução de alguns momentos de descontração antes e depois da
reunião é importante. Deve se utilizar esses momentos para discutir assuntos
comuns e, durante a reunião, deve-se tentar trazer todos para a discussão, pois é
um ótimo momento para construir confiança.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_36: “...the conventional agile software development values people
over processes/tools, working software over comprehensive
documentation, customer collaboration over contract negotiation, and
responding to change over following a plan [3]. Furthermore, in agile
software development tacit knowledge is more important than explicit
knowledge and informal communication is more useful than traditional
formal communication.”
MP6. Detalhar o planejamento
O planejamento deve certificar que todos os membros da equipe entendem os
horários de trabalhos diferentes que poderão assumir, os meios de comunicação
que serão necessários com a outra equipe e a disponibilidade que precisam. As
equipes devem respeitar, aceitar e se comprometer com o planejamento do
cronograma.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_26: “Project planning helps resolve such uncertainty through
frequent exchanges of information...”
MP7. Disponibilidade de uma boa infraestrutura
A disponibilidade de uma infraestrutura adequada para apoiar as equipes
globais é fundamental, a estrutura de energia elétrica e dos meios de comunicação
devem ser seguras, para garantir a produção e a propriedade intelectual.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
115
§ EP_52: “To support a virtual team strategy, investment in key
infrastructure is essential and should be considered at the early stage
when selecting an offshoring location. Infrastructure requirements can
be as basic as the availability of a dependable electrical supply or the
hardware to ensure that, when interruptions in supply take place, an
alternate power source is available.”
MP8. Treinamento sobre culturas diferentes
Treinamento sobre as diferentes culturas envolvidas no projeto para as equipes
é uma boa prática para minimizar os efeitos das diferenças culturais que podem
existir em diferentes países. Com a realização de treinamentos, a diversidade
cultural pode ser transformada em força através da criação de equipes de apoio
para superar diversas situações. As informações sobre calendários são envolvidas
nos treinamentos, tentando incentivar o membro a conhecer e valorizar a cultura do
outro.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_87: “...to advance social ties in globally distributed teams may also
improve he formation of a globally distributed team as members get to
know each other during these meetings, learn about cultural differences
between team members, discuss and agree on ways to resolve
tensions, set up procedures for coordinating work activities, and start
working together toward a successful completion of a Project.”
MP9. Gerenciar riscos constantemente
O gerenciamento de risco é uma atividade que exige esforços adicionais para
atingir seus objetivos em um ambiente distribuído. É viável manter uma base dos os
riscos de projetos passados, juntamente com suas ações de mitigação.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_107: "Risk management in globally distributed software
development (GDSD) projects is becoming a critical area of concern for
practitioners. The risks in GDSD projects can be dynamic due to the
116
multiplicity in various aspects of GDSD projects (e.g., multi-locations,
multi-cultures, multi-groups, multi-standards, and multi-technologies).
This multiplicity nature leads to dynamic interactions among the internal
(i.e., people, process, and technology) and external elements of a
GDSD project.”
MP10. Motivar equipe e manter espírito de equipe
Devido a dispersão geográfica, os membros das equipes podem esquecer os
outros membros. Algumas informações, como lista com os nomes das pessoas, seus
cargos, férias, modo de contato, e-mail, data de aniversário, ajudam a manter o
clima de equipe. Conhecer a hierarquia e as pessoas responsáveis, é muito
importante na hora de se resolver um problema.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_102: “the team leader has to motivate and help team members to
achieve their goals. Motivation and goal identification make the team
work efficiently.”
MP11. Gerenciar e coordenar pessoas
A formação de uma equipe é importante para centros de desenvolvimento
offshore. É importante que a equipe treinada opte por permanecer com a
organização e deve-se realizar atividades com pessoas através de diferentes
abordagens para a comunicação, formação e estratégias. Deve haver também
mecanismo para resolução de conflitos entre pessoas.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_107: “Relating to these multiplicity natures in people-people
interactions, we further identify, as dynamic risks, the difficulty of
knowledge sharing among the distributed groups and individuals, the
language barriers hindering team communications or even leading to
misunderstandings, and different perceptions of hierarchy in both official
and non-official settings.”
117
MP12. Utilizar práticas ágeis
Em projetos desenvolvidos em ambientes distribuídos, todos os meios
possíveis para incentivar a comunicação deve ser usado. As práticas ágeis dão
ênfase à comunicação e são vistas como uma alternativa para incentivar a
comunicação entre membros. As práticas como: reuniões diárias com as equipes de
todos os sites e o representante ou cliente, com horários automatizados a partir de
repositório central, estar disponível para o outro e feedback rápido com o uso de
mensagens instantâneas contribui para uma gestão distribuída.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_36: “Agile and Principles, the conventional agile software
development values people over processes/tools, working software
over comprehensive documentation, customer collaboration over
contract negotiation, and responding to change over following a plan.
Furthermore, in agile software development tacit knowledge is more
important than explicit knowledge and informal communication is more
useful than traditional formal communication.”
MP13. Ajustar de trabalho entre sites
Entre os vários mecanismo de integração, algum pode ajudar a definir um
ponto de ajuste entre equipes de trabalho distribuídas. Espaços compartilhados para
armazenar arquivos de maneira centralizada em um local acessível e ferramentas
que atendam a distribuição do time, ajudam as equipes a realizar um bom trabalho.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_47: “Indicate information sharing can be an alternative in face-to-
face virtual teams due to the lack of things like routine update meetings
that are not available in a virtual environment.”
MP14. Definição de papéis e responsabilidade
Em equipes distribuídas, os papéis e responsabilidades devem estar bem
definidos e compreendidos em todos os níveis do projeto. Torna-se mais fácil de
118
identificar as competências e habilidades especiais de cada local, incentivados para
o planejamento estratégico. Estabelecer um fluxograma organizacional, facilita o
relacionamento e o cumprimento de regras, e permite a coordenação e o controle
eficaz.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_61: “enhances the quality of work, can share the burden of the daily
goals and responsibilities and increase his/her knowledge and skills
through frequent verbal communication.”
MP15. Manter padrões de qualidade
Os padrões de qualidade devem ser documentados e acordados entre os
envolvidos, atribuindo responsabilidades para as deficiências não se acumulem.
Deve-se aplicar qualidade através de padrões de codificação e verificação.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_166: “Em um esforço para identificar e comparar os perfis do
membros que formam os grupos derivados, tentamos retratar a forma
como os intervenientes em cada um dos aglomerados priorizar a
aspectos de qualidade.”
MP16. Criação de protocolo de comunicação
A criação de um protocolo de comunicação deve ser definido antes do início do
projeto. É essencial que esse protocolo seja de conhecimento e de livre acesso a
todos os membros da equipe. O mesmo deve ser claro e especificar as ferramentas
de comunicação que devem ser utilizadas e entendidas por todos. Os protocolos
podem ser definidos, por exemplo, que todas as mensagens serão respondidas no
prazo de 2 horas, ou que todos os telefonemas devem ter retorno no prazo de 3
horas.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_41: "Mutual adjustment included setting up rules of communications
which helped people adjust to communication styles and reduced the
119
misunderstandings and confusions that typically happened as a result
of different cultural backgrounds.”
MP17. Utilizar redes Sociais
A utilização de redes sociais podem ajudar no gerenciamento de projetos
distribuídos. Mapeando a rede, o gerente pode entender melhor como se comporta
os membros da equipe.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_93: “Overall distributed teams face more challenges to achieve
high performance. In this paper, we suggest that analysis of social
features and mapping social networks can lead us to draw conclusions
on the way distributed work groups coordinate. Social networks reflect
on the communication structure of a team therefore, analysis of these
networks can help us to understand team dynamics and roles of
different actors.”
MP18. Visitas entre sites
Desenvolvedores de diferentes sites devem conhecer a sede da empresa e os
outros membros da equipe. Conseguindo entender melhor o sistema, poderão
retornar à equipe local e compartilhar as novas informações adquiridas, além de
compreender melhor o contexto cultural das outras equipes.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_91: “The most common approach to dealing with cultural
differences is to develop understanding of different cultures through
interaction with team members from remote teams, via site visits or
face-to-face meetings using video-conferencing technology. Or, cultural
awareness can be introduced into the on-site team by including a
member from each of the remote teams’ cultures, to serve as “cultural
ambassadors” who can both interpret remote team communication and
actions, and serve as a contact for remote developers, who will
perceive the cultural ambassador as someone who understands their
120
language and culture.... Further, managers could rotate to different
locations to acquire first-hand knowledge of how different sites work.”
MP19. Estimular a cooperação/ colaboração
A utilização de ferramentas de colaboração deve ser estimulada, pois ajuda na
comunicação eficaz entre os projetos distribuídos, através do compartilhamento dos
objetivos organizacionais com todos os membros.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_43: “Most of these deficiencies center around the challenges of
effective communication between geographically separated Project
teams. Many project managers seek communication systems that
support realtime, multimedia collaboration. This is not useful for
developers who generally work alone. Also, as teams spread across
continents and even across multiple continents, time zone differences
between team members often make real-time collaboration unwieldy.
The use of wikis as project management tools resolves many of these
issues.”
MP20. Gestão de configuração
A gestão de configuração estabelecida em um projeto distribuído reduz os
problemas como a falta de comunicação e controle de mudanças, porque aplica um
processo comum de trabalho.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_199: “The provision of and use of effective Configuration
Management (CM) tools and a well-documented CM procedure is also
essential for efficient team operation in the global environment.”
MP21. Reuniões face a face Kickoff
Começar o desenvolvimento de projeto distribuído com uma reunião faca a
face é uma ótima oportunidade de interação, para conhecer uns aos outros. Essa
121
reunião leva a uma maior clareza e melhor direção, proporcionando as pessoas
oportunidade de estabelecer relações e desenvolver espírito de equipe.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_147: "Several relationship-building practices are suggested, such
as face- to- face meetings, organizational charts help to recognize
persons, and common kick-off meeting. Useful informing and monitoring
practices include a number of practices, such as weekly meetings and
progress reports. Informing and monitoring should be followed-up in all
directions."
MP22. Gerenciar cronograma
Cumprir o cronograma não é uma atividade fácil para projetos co-localizados.
Para os projetos distribuídos, esta tarefa também é complexa devido aos vários
fatores que envolvem tempo, cultura e idioma.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_29: “The virtual environment presents considerable challenges to
effective communication including time delays in sending feedback, lack
of a common frame of reference for all members, differences in salience
and interpretation of written text, and assurance of participation from
remote team members.”
MP23. Sincronicidade/ reuniões com horários razoáveis para a maioria dos sites
Em projetos de desenvolvimento distribuído os horários de reuniões devem ser
bem definidos, de forma a acomodar os melhores horários para o maior número de
sites, mantendo uma comunicação síncrona.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_78: "Difference Temporal dispersion, or time zone coordination,
also remains a challenge that project teams using metaverse
technologies cannot easily overcome. VWs support synchronous
communication, but project tasks that require individuals to meet at the
122
same time will still find it difficult to schedule team meetings."
MP24. Garantir confidencialidade, privacidade e propriedade de intelectual
Proteger os dados de projetos distribuídos e indispensável, pois os dados são
enviados por meio de acordos de confidencialidade. Com isso, torna-se uma tarefa
essencial devido a dispersão física das equipes. É importante criar protocolos de
privacidade, para privar os dados organizacionais.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_19: “Privacy is a generic term that means different things to
different people. To enable the unambiguous description and discussion
of privacy-related issues in media spaces,... created a framework that
collects various terms and concepts related to privacy from the
literature. Their framework broadly divides privacy into the three‘ control
modalities’ of confidentiality, autonomy, and solitude. In the framework,
each modality contains additional terms that detail aspects of it.”
MP25. Visibilidade do trabalho
Com os papéis e responsabilidade claramente definidos, cada membro da
equipe sabe as atividades e artefatos necessários para a realização de trabalho. A
visibilidade de todas as partes do projeto, é peça fundamental para o sucesso do
mesmo, inclusive em equipes dispersas.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_91: “Distance also affects project visibility. The need for effective
collaboration and visibility between locations in a GSD team
environment is essential.”
MP26. Espaços físicos para equipes locais
Um ambiente físico deve ser preparado para a equipe local do projeto possa
trabalhar e trocar ideias. Assim, é importante ter escritórios para as equipes para que
possam se comunicar, com salas estruturadas para as reuniões.
123
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_21: “Teams may even establish dedicated physical spaces, or
project war rooms, to improve access to information and awareness of
critical issues among development team members.”
MP27. Critérios para atribuição de tarefas
Ao atribuir tarefas as equipes destruídas, vários fatores devem ser
considerados: conhecimento especializado, proximidade, planejamento, estratégia,
qualidade de desenvolvimento, confiança, diferença de fuso horário, cultura, idioma
e disposição do site para realizar as tarefas.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_12: “Virtual teams vary a longa number of dimensions, such as
team size, degree of geographic dispersion, prior shared work
experience, nature of members’ assignment, Difference Cultural
diversity (national, organizational and/or professional) and expectations
of a common future.”
4.3.3 Q3: Ferramentas de apoio ao gerenciamento de projetos no DDS Q3: Que ferramentas existem para apoiar as atividades de gerenciamento no DDS?
Esta questão buscou identificar ferramentas de apoio ao gerenciamento no
DDS. Foram encontradas 31 ferramentas de apoio ao gerenciamento de
desenvolvimento distribuído de software e os estudos que propuseram a maioria
dessas ferramentas, não relatam suas experiências de forma ampla, somente
algumas delas estão evidenciadas na literatura.
Essas ferramentas estão sumarizadas na Tabela 4.3, na Seção 4.2, em que a
primeira coluna apresenta as ferramentas extraída das evidências que são
apresentadas na coluna dois e a coluna três a quantidade de trabalhos.
As ferramentas a serem utilizadas no gerenciamento de projetos distribuídos
estão descritas conforme apresentadas na sequência:
124
F1. E-mail
A utilização do e-mail, mesmo sendo uma comunicação assíncrona entre os
sites, ainda é muito utilizada por todas as equipes. Devido a distribuição geográfica e
fuso horário entre as equipes, as dúvidas ou a busca de informação não pode ser
imediata.
F2. Telefone
Durante a realização de tarefas complexas, dúvidas podem surgir e o telefone
é utilizado como comunicação síncrona, para resolver questões inesperadas. Porém,
a utilização do telefone tem algumas restrições como o idioma, fazendo com que os
stakeholders normalmente utilizem outra ferramenta.
F3. Teleconferência
A utilização de teleconferência, permite a comunicação em tempo real entre
membros que não estão no mesmo espaço físico.
F4. Videoconferência
No desenvolvimento projetos distribuído, a videoconferência é usada várias
vezes no decorrer do trabalho, como por exemplo: em reuniões semanais, reduzindo
a necessidade de viajar, ajudando na tomada de decisão mais rápida e até mesmo
na resolução de problemas. A videoconferência possibilita mostrar a sinceridade e
autoridade através da linguagem corporal e o contato visual.
F5. Bate-papo (chat)/ Skype/ Google Talk
São ferramentas que permitem a interação de duas ou mais pessoas ao
mesmo tempo. Este tipo de ferramenta e usado em todas as fases de
desenvolvimento do projeto. O compartilhamento de questões e muito utilizado por
mensagens instantâneas.
125
F6. Áudio Conferência
O baixo custo e a excelente qualidade de áudio, faz com que as equipes
distribuídas usem em todas as fases do projeto.
F7. Voicemail
É um sistema centralizado de gestão de mensagens de telefone, que permite
enviar MSN para um grande grupo de pessoas, possibilitando o compartilhamento
de informações em conjunto.
F8. NetMeeting
NetMeeting é uma ferramenta que disponibiliza transferência de arquivos,
conferindo os dados entre os sites.
F9. VoIP
A utilização de VoIP no desenvolvimento do projeto, facilita a comunicação
entre os membros da equipe. Outra vantagens que isso pode trazer, é que uma
conexão de Internet pode se tornar uma maneira de fazer ligações telefônicas
gratuitamente, embora geralmente apenas para outro sistema VoIP, mas possui um
baixo custo.
F10. Wiki
Wiki é um sistema colaborativo que disponibiliza um ambiente padronizado e
permite contribuições coletivas, compartilhamento de documentos (texto e vídeos),
aumentando a visibilidade entre as equipes. Wiki permite um ponto de fácil acesso
de informações como: agendas de reuniões e informações de cada membro da
equipe de trabalho.
F11. Blog
126
Blog são páginas de internet onde regularmente são utilizado para publicar
diversos conteúdos, como texto, imagem, música e vídeo para a transmissão de
informação social entre a equipe, podendo assim capturar conhecimentos
importantes, criando discussão e comentários curtos.
F12. Calendário de Grupo (Group calendars)
É uma ferramenta que permite construir uma agenda de atividades onde toda a
equipe tem acesso à informação. O compartilhamento da agenda evita surpresas
nas entregas de atividade.
F13. Fax
Apesar de se encontrar um pouco ultrapassado, o fax ainda é usado para a
transferência remota de documento.
F14. Jazz
Jazz é uma plataforma de desenvolvimento colaborativo síncrono, que integra
várias tecnologias diferentes.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_168: “Jazz tool that provides planning, source code management,
work item management, building management, and project health. To
carry out these tasks this tool integrates modules to support process
and team awareness, work item tracking, agile planning providing tools
to create plans for teams and continuous build integration."
F15. TAMRI (Task Allocation based on Multiple cRIteria)
É uma ferramenta que possibilita o gerenciamento de projetos distribuídos
através da identificação de atribuições de tarefas adequadas em um processo de
planejamento de projeto global.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
127
§ EP_68: “TAMRI (Task Allocation based on Multiple cRIteria), model for
supporting a systematic task allocation decision in distributed
development projects that is based on multiple criteria and influencing
factors.”
F16. Intranet
A utilização da intranet facilita o compartilhamento de arquivos e vídeos.
Podendo ser compartilhada, independente da localização das equipes.
F17. Fórum de Discussão
É uma ferramenta para página de internet destinada a promover debates
através mensagens publicadas abordando uma questão.
F18. Quadros virtuais (Virtual whiteboards)
Os quadros virtuais podem replicar e estender a funcionalidade dos quadros
físicos. Quando uma conversa é realizada via telefone, o quadro pode ser usado
para fazer visualização de determinadas tarefas a seguir.
F19. Galeria de fotos (Photo gallery)
A utilização de aplicativos deste tipo, permite o compartilhamento de fotos das
equipes, contribuindo substancialmente para a criação de espírito de equipe.
F20. Jira
É um software de gerenciamento de projeto, que pode ser utilizado no
planejamento e no acompanhamento. Permite acesso de diferentes locais,
facilitando o acompanhamento do projeto.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_168: “This is a tool with a high level of integration through plug-ins
which offers issue tracking and agile project management. It allows
128
easy bugs tracking and it offers full integration with popular IDEs such
as Eclipse.”
F21. TeamSpace
Esta ferramenta ajuda o gerenciamento de projetos distribuídos, colaborando
com o suporte de reuniões síncronas, planejamento e programação de encontros
futuros, além de condução e visualização de uma reunião em andamento. O
TeamSpace contém um repositório de reuniões anteriores, mantendo assim um
histórico das mesmas e permite que o usuário pesquise e reveja a reunião.
F22. CAMEL
Ferramenta de apoio a reuniões de projetos distribuídos, o CAMEL fornece um
ambiente em que vários diagramas UML podem ser esboçados e discutidos pela
equipe, além de suportar e capturar todas as informações relevantes durante uma
reunião.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_168: “This research tool provides an environment in which multiple
diagrams (UML and free-style) can be sketched and discussed. It also
supports mechanisms with which to manage the focus of the dialogue
during meetings and provides mechanisms for capturing all the relevant
information arising from design meetings."
F23. NEXTMOVE
Esta ferramenta tem como objetivo ajudar as equipes de projeto no
acompanhamento, coordenação e comunicação de tarefas em um ambiente
distribuído. No NextMove, há quatro principais visualizações na interface de
usuários: visão backlog (tarefas a serem executadas) da equipe, visão do backlog
pessoal, visão das atividades da equipe e visão dos artefatos.
F24. Groupware
129
É uma ferramenta que apoia os gerentes de projetos distribuídos em suas
atividades, possibilita ainda a identificação de tarefas adequadas em um processo
de planejamento global e permite enviar e-mail para se comunicar com a equipe.
F25. ActiveCollab
ActiveCollab é uma ferramenta de software que apoia as atividades
relacionadas com o gerenciamento de projetos através de uma plataforma web.
Oferece eventos e notificações por e-mail e permite que a integração de no fluxo de
trabalho do projeto.
F26. Assembla
Esta é uma ferramenta baseada na web permitindo que o fluxo de atividades
de um projeto seja controlada e coordenada. Assim, possibilita a colaboração entre
os membros da equipe através do uso de recursos baseados em web, como páginas
de wiki e a capacidade de ver o trabalho de cada membro da equipe. Assembla
permite a integração de diferentes ferramentas de colaboração, além de
compartilhar informações sobre o projeto com os clientes.
F27. Gliffy
Esta ferramenta permite a colaboração entre os membros da equipe
distribuída. Através dela, é possível convidar os membros da equipe a uma sessão,
a fim de visualizar ou editar diagramas. Permite incluir as notificações de e-mail,
controle do sistema de revisão e acesso ao sistema em si. Ele também inclui um
gerenciador de documentos para organizar diagramas.
F28. Repositório de Lições Aprendidas
O armazenamento das melhores práticas e das lições aprendidas durante e
após o desenvolvimento do projeto, ajuda posteriormente nas tomadas de decisões.
130
F29. Webex
É uma ferramenta que disponibiliza transferência de arquivos em reuniões,
permite conferência de dados entre os sites.
F30. XPLanner
É uma ferramenta que apoia os gerentes de projetos, ajudando na
coordenação de tarefas e armazena informações como horas gasta pelo membro ao
realizar uma tarefa e quantas iterações ele fez.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_215: “XPlanner was used to collect project management data such
as the number of iterations, the user history and the number of hours
expended in specific tasks by each team member. This data was
entered into the XPlanner tool by each member of the pair-
programming team, therefore helping the team learn about the
methodology. We conclude that the use of the XPlanner tool provided
visibility to project management about task progress and helped ensure
the team’s adherence to the agile process for software development.”
F31. Ms Sharepoint
É uma ferramenta capaz de apoiar os gerentes de projeto na identificação de
atribuições de tarefas adequadas em um processo de planejamento de projeto
distribuído, além da comunicação e envio de e-mail e controle de fórum.
4.3.4 Q4: Modelos de apoio ao gerenciamento de projetos no DDS Q4: Que modelos existem para apoiar as atividades de gerenciamento no DDS?
Esta questão buscou investigar modelos de apoio ao gerenciamento no
desenvolvimento distribuído de software, em que foram encontrados 14 modelos
específicos para o ambiente distribuído. Esses modelos são somente propostos
pelos estudos, de forma que não são encontradas evidências de experimentos, com
131
exceção do modelo TAPER, que em um estudo encontrado na busca manual do
engenho ICGSE 2007, relata a experiência de uso deste modelo.
Os modelos identificados e as referências que os citaram estão na Tabela 4.4,
na Seção 4.2, onde a primeira coluna apresenta os modelos identificados na
literatura, a segunda coluna a referência dos estudos primários e a terceira mostra a
quantidade dos trabalhos.
Esses modelos evidenciados na literatura Tabela 4.4, na Seção 4.2, são
descritos conforme apresentados na sequência:
M1. TAPER
TAPER (Trust, Assess, Prove, Enhace, and Reengineer), é um framework para
estabelecer centros de desenvolvimento offshore, baseado em boas práticas para
superar as dificuldades em gerenciar ambientes distribuídos. TAPER sugere que a
criação de um centro de offshore deve seguir alguns passos padronizados, a fim de
minimizar os possíveis riscos e aumentar a chance de sucesso. Possui cinco ciclos:
confiança, avaliação, teste, melhoria e reengenharia.
Apresenta-se uma transcrição de evidência relacionada a esse tema:
§ EP_210: “We have experience in using the TAPER framework for more
than three years. We applied the framework for a new engagement with
a new customer from Germany with great success. The engagement
started in 2004. The use of the TAPER framework helped us in sharing
our understanding of the challenges in offshore software development.
This helped create a realistic set of expectations and showed how
important the customer side roles are in making any offshore Project a
success.”
M2. Project management model
Este modelo possui as seguintes características: possui ciclo de vida do tipo
espiral; utiliza o processo de desenvolvimento de sistemas orientado a objeto, com
linguagem de especificação UML (Unified Modeling Language) e processo UP
(Unified Process); incorpora a abordagem processual do PMI expandindo algumas
132
áreas de gestão do PMBOK. O modelo proposto é dividido em 6 fases, em que cada
uma contém um conjunto de atividades associadas, com as seguintes etapas:
Definição dos Requisitos, Projeto, Processos de Produção, Avaliação, Processos de
Transição e Processos de Integração.
M3. A reference model for global software development
Este modelo tem como finalidade apoiar o desenvolvimento global de software,
atuando como um guia para o desenvolvimento de software feito por equipes
geograficamente dispersas e heterogêneas. O modelo é composto por um conjunto
de variáveis críticas e sua relação identificado durante o estudo.
M4. Conceptual model for managing an international IS development project
É um modelo conceitual para a gestão internacional de desenvolvimento de
sistemas utilizando métodos e ferramentas de TI de forma inovadora, contendo as
seguintes etapas: ambiente, infraestrutura, gerenciamento do projeto, objetivos e
problemas encontrados no desenvolvimento internacional, participantes no projeto
internacional de desenvolvimento, comunicação, coordenação e colaboração
internacional, ferramentas de compartilhamento de informação para o
desenvolvimento internacional, ferramentas de compartilhamento de artefatos,
ferramentas de desenvolvimento e processo de desenvolvimento.
M5. DRiMaP – a model of distributed risk management
Este modelo coloca principalmente a pressão sobre as etapas do processo,
papéis envolvidos neles, canais de comunicação e coordenações das ações de
gestão de risco entre os diversos parceiros, abrangendo tanto o negócio quanto a
engenharia em níveis organizacionais.
M6. Solar system
O sistema organizacional solar foi criado pela NASA é um modelo adaptado
para a realidade de projetos virtuais de software que visa melhorar a comunicação e
133
coordenação. Contém as seguintes características: cada organização funcional de
uma equipe virtual é como um planeta no sistema solar, em que as principais partes
compõem o círculo interno de comunicação e colaboração, enquanto as demais
partes ficam no círculo exterior.
As interações fundamentais dentro deste modelo podem ser interpretadas
como: a) Colaboração do universo - melhorar o compartilhamento de informações,
utilizando um sistema de informação como uma wiki e interação direta. Permite que
os membros da equipe interajam uns com os outros para melhorar a confiança; b)
Participação do grupo - definir as 100 missões da equipe e resolver os problemas do
time; c) Planejamento estratégico - construir uma visão comum para todas as partes
interessadas no projeto tornou-se crítica para o projeto ser bem sucedido.
M7. Dyadic model
O modelo é um processo de curto prazo de interação entre participantes de
uma organização. O modelo se assemelha a sistemas dinâmicos existentes de
interação diádica.
M8. Project management framework
Este framework foi desenvolvido usando o Microsoft Project. Este software
organiza a maioria das questões de agendamento e, a tarefa de organizar as
interações entre vários sites, é realizada pelo framework que permite realizar até 101
formas de comunicações eficientes entre diferentes sites, múltiplas visões do
produto e geração do plano de projeto para um grande produto. Cada site na
organização pode ser tratado como um subprojeto e tem um plano de projeto criado
no Microsoft Project, que capta o planejamento e as dependências com outros sites.
O framework deve ser capaz de integrar diferentes pontos de vista de um produto
durante o seu ciclo de desenvolvimento.
M9. Process maturity framework for managing distributed development
Framework de processo de maturidade que propõe 24 processos essenciais
para a gestão de desenvolvimento distribuídos de software e melhoria contínua das
134
capacidades de gerenciamento. O modelo possui três estágios: iniciação,
consolidação e alta produtividade com processos mapeados. Cada estágio deve
estar de acordo com 4 conceitos: colaboração, gestão do conhecimento,
modularização do trabalho e tecnologia.
M10. Approach to Offshore collaboration
O modelo sugere uma abordagem em cascata na qual as fases de concepção,
análise e projeto são realizadas localmente. Já as fases de construção e teste, são
realizadas de forma distriuída. As fases do modelo são: planejamento da
configuração, formação e transferência de conhecimento, estabelecimento de
política e procedimentos. Seu foco é voltado na comunicação e checkpoints.
M11. Framework for supporting management in distributed information systems development
É um framework de apoio à gestão distribuída, que oferece uma estrutura de
classificação de problemas e soluções visando contribuir para uma melhor
compreensão do domínio do desenvolvimento distribuído. Assim, ajuda
pesquisadores e profissionais na identificação de novos problemas e indica quais
deles ainda precisam de soluções, baseado em seis dimensões (distância
geográfica, temporal, sociocultural, organizacional, tecnológica e de conhecimento) e
cinco tipos de atividades (comunicação, coordenação, controle, desenvolvimento e
manutenção). Para cada distância, problemas relacionados a cada atividade são
identificados e possíveis soluções são sugeridas.
M12. NEXTMOVE
O framework ajuda o gerente no processo de atribuição de tarefa, consistindo
em dois processos: a) Priorização de Tarefas – é realizado de acordo com quatro
critérios: cronograma, relação com o artefato, a prioridade de recursos e
dependências de fluxo de trabalho; b) Alocação de tarefas – os objetivos do
processo de atribuição de tarefas incluem: localizar a pessoa mais qualificada para a
tarefa, balancear carga de trabalho, minimizar sobrecarga e, para a atribuição de
135
tarefas, os gerentes de projeto precisam encontrar um equilíbrio entre estes
objetivos.
M13. GSD model
Um modelo que apoia o planejamento do projeto e melhoria de processos no
desenvolvimento de software distribuído.
M14. Framework to enable coordination in distributed software development
Este framework visa permitir uma melhor coordenação entre diferentes
ferramentas SDLC (software development lifecycle) com a seguinte estrutura: a)
Camada de integração de ferramentas – em que diferentes ferramentas do ciclo de
vida do desenvolvimento do software serão ligadas ao framework; b) Camada de
repositório de informações – central de armazenamento de dados das várias
ferramentas integradas; c) Camada de definição de domínio – apresenta uma
descrição formal do conhecimento no repositório; e d) Camada de mecanismos de
análise – análise das necessidades para verificar a aderência às políticas do projeto
e emitir alertas quando necessário.
4.4 Abordagem para o gerenciamento de projetos no DDS Uma abordagem é proposta nesta seção para orientar a melhoria em
gerenciamento de projetos no desenvolvimento distribuído de software. Está
abordagem foi proposta e utilizada por Costa (2009).
A abordagem é estruturada em dois níveis:
• Nível da Construção da Teoria: usando evidências da experimentação
científica e industrial. A abordagem é constantemente refinada em uma
teoria de gerenciamento de projetos no DDS, podendo ser construída
gradualmente e de forma colaborativa.
• Nível da Experimentação: construções teóricas e relações de causa e
efeito definidas na abordagem são usadas para buscar um efeito nos
problemas industriais ou acadêmicos. Então, os efeitos resultantes de
experiências com problemas reais são usados como evidências para
refinar a abordagem no nível da construção da teoria.
136
As evidências, relacionadas aos desafios, melhores práticas, modelos e
ferramentas, descritos na Seção 4.2 deste capítulo foram combinadas nas tabelas
Tabela 4.1Tabela 4.2,Tabela 4.3Tabela 4.4. Esta abordagem permite que a
gerência, diante da identificação de um desafio, possa verificar as possibilidades que
venha minimizar ou eliminar o desafio no gerenciamento de projetos distribuídos de
software. As fases da abordagem são ilustradas na Figura 4.2, e detalhadas a
seguir.
Figura 4.2 - Abordagem para gerenciamento de projetos no DDS Fonte: Costa (2009)
A abordagem proposta e utilizada por Costa (2009), segue as seguintes fases:
§ Fase 1 – Observar: Observar a situação atual do gerenciamento de
projetos no DDS procurando problemas. Encontrar respostas para a
pergunta "O que está errado com a situação atual?". Para isso, devem
ser utilizados os desafios listados na Tabela 4.1 para orientar a
(Refine Tabela 4.1)
(Refine Tabela 4.1)
(Refine Tabelas 4.2 a 4.9)
(Refine Tabelas 4.6 a 4.9)
137
observação, criando uma lista de desafios relevantes para a situação
atual.
§ Fase 2 – Teorizar (1, 2 e 3): Criar uma potencial solução para cada
desafio identificado na fase “Observar”. Para isso, deve-se utilizar os
componentes da abordagem que associam Desafios a Melhores
Práticas (Tabela 4.5), Desafios a Ferramentas (Tabela 4.6), Desafios a
Modelos (Tabela 4.7), Melhores Práticas a Ferramentas (Tabela 4.8) e,
Melhores Práticas a Modelos (Tabela 4.9), que se encontram na Seção
4.2.1, deste capítulo. Neste ponto, as hipóteses são de que a
implantação e utilização das Melhores Práticas, Ferramentas e
Modelos selecionados terá um efeito positivo sobre os problemas
identificados. Deve-se quantificar, se possível, o efeito desejado de
cada tratamento.
§ Fase 3 – Projetar: Construir um plano de aplicação dos tratamentos
identificados na fase “Teorizar” a um conjunto testes experimentais das
hipóteses geradas nas fases anteriores.
§ Fase 4 – Experimentar: Aplicar os tratamentos sobre a atual situação
e coletar dados sobre seus efeitos e problemas.
§ Fase 5 – Avaliar: Avaliar a eficácia dos tratamentos, avaliando seus
efeitos sobre a situação do problema original. Realimentar os
resultados para as fases “Observar” e “Coletar”. O ciclo de melhoria
pode continuar identificando novos desafios.
§ Fase 6 – Coletar: Coletar dados a partir de estudos experimentais que
relacionem Melhores Práticas, Ferramentas e Modelos para os
Desafios no gerenciamento de projetos no DDS. O protocolo de
mapeamento sistemático pode ser utilizado para guiar a coleta de
evidências. Os resultados dos experimentos da Fase 5, também
contribuem para essa fase.
§ Fase 7 - Refinar: Deve-se utilizar as novas evidências a partir de
estudos experimentais para refinar a abordagem, modificando as
tabelasTabela 4.1 à Tabela 4.9, de acordo com os resultados.
138
A aplicação desta abordagem as evidências encontradas, estão sumarizadas
nas em tabelas na Seção 4.2.1, deste capítulo.
4.5 Discussão dos resultados A partir do dados retornados do mapeamento descritos neste capítulo, e
apresentado na Seção 4.2, algumas discussões sobre os resultados podem ser
realizadas:
§ A Tabela 4.1, são apresentados os 32 desafios evidenciados na
literatura em relação ao gerenciamento de projeto no DDS. Alguns
desafios tiveram um número alto de evidências citados pelos estudos
como: Comunicação (140), Dispersão Geográfica (91), Diferença
Cultural (140), Idioma/ Diferença Linguística (61) e Diferença Temporal
(79). Também foram encontrados desafios que tiveram somente uma
evidência na literatura, portanto, conclui-se que a literatura dá muita
importância a esses desafios.
§ A Tabela 4.2, são apresentadas as 28 melhores práticas para o
gerenciamento de projetos no DDS. É possível perceber que foram
encontrados mais desafios do que melhores práticas, algumas mais
diretamente relacionadas à desafios específicos como, por exemplo,
boa prática (MP8), treinamento sobre culturas diferentes (que está
relacionado ao desafio Diferença cultural - D4).
§ A Tabela 4.3, são apresentadas as 31 ferramentas de apoio ao
gerenciamento em projetos no DDS. Dessas ferramentas, 27 são
relacionadas ao suporte de comunicação entre as equipes. Nestas, 11
ferramentas tratam especificamente da gestão em DDS.
§ A Tabela 4.4, são apresentados os 14 modelos de apoio ao
gerenciamento de projetos no desenvolvimento distribuído de software.
Todos foram citados pelos autores de 30 trabalhos e, dentre eles, o
único modelo que teve suas evidências de experimento encontradas,
foi o TAPER, no estudo EP_210. Os demais somente foram citados
pelos autores.
§ A Tabela 4.5, são apresentados os desafios e melhores práticas. É
observado que os desafios tiveram o maior número de evidências
139
perante as melhores práticas. Em se tratando das melhores práticas, o
foco foi a comunicação, como por exemplo, o D1. Comunicação, onde
este está relacionado à 8 melhores práticas.
§ A Tabela 4.6, apresenta a relação de desafio e ferramenta. O desafio
comunicação continua, comparando com o trabalho de Costa (2009),
sendo o foco, com 23 ferramentas referenciadas ao D1. Comunicação.
§ A Tabela 4.7, apresenta a relação entre desafios e modelos de apoio
ao gerenciamento no DDS. Os modelos evidenciados na literatura
focam em mais de um desafio.
§ A Tabela 4.8, apresenta melhores práticas e ferramentas. Identifica-se
que as ferramentas apoiam pouco as melhores práticas e somente 4
melhores práticas foram relacionadas às ferramentas.
§ A Tabela 4.9, apresenta melhores práticas e modelos em que, 7
melhores práticas foram relacionadas aos modelos de apoio ao
gerenciamento de projetos no DDS.
Diante disso, pode ser afirmado, após a análise dos resultados apresentados
pelo mapeamento, que a maioria das soluções, em termos de melhores práticas,
ferramentas e modelos, são evidenciados na literatura e disponibilizados para
ultrapassar os desafios de comunicação no gerenciamento de projetos em DDS,
sendo evidenciado pela literatura o D1. Comunicação.
4.6 Comparação dos resultados Os resultados apresentados neste mapeamento foram comparados ao de
Costa (2009), que realizou uma revisão sistemática com o objetivo de investigar “o
que muda no gerenciamento de projetos de software quando o desenvolvimento é
distribuído?” e “como apoiar a gerência nesse cenário de desenvolvimento?”
resultando em quatro questões de pesquisa. Costa (2009) realizou no seu trabalho,
buscas em quatro bases automáticas (IEEE, ACM, ScienceDirect e El Compendex) e
uma busca manual na 7ª edição do ICGSE (International Conference on Global
Software Engineering). 54 estudos primários foram analisados e uma abordagem foi
criada para apoiar o gerenciamento de projetos de desenvolvimento distribuído de
software.
140
O mapeamento realizado buscou investigar as mesma questões de pesquisa
proposta por Costa (2009), sendo acrescentado:
§ Oito novos sinônimos que identificam Desenvolvimento Distribuído de
Software (DDS) na literatura: Dispersed software development, Virtual
software development, Dispersed development, Dispersed software
engineering, Virtual software engineering, Virtual development, Virtual
teams, Geographically dispersed development teams.
§ Duas novas bases de dados: Elsevier Scopus e Springer Link, que são
sugeridas por Kitchenham (2007).
§ Busca no período de 2009 a 2012 nas 4 fontes de busca realizada pelo
estudo de Costa (2009).
§ A busca manual foi feita nas sete edições do ICGSE.
A partir dessas adições, os seguintes resultados foram obtidos:
§ Um maior número de evidências na literatura foi encontrado sobre os
desafios em gerenciamento de projetos no DDS, em que 224 estudos
primários foram evidenciados.
§ As duas novas bases automáticas que foram pesquisadas contribuíram
significativamente para a seleção dos estudos primários. A Elsevier
Scopus contribuiu com 68 estudos, sendo 8 de qualidade excelente, e
a Springer Link com 10 estudos, sendo 3 de qualidade excelente.
§ A busca manual realizada nas sete edições do ICGSE (International
Conference on Global Software Engineering), contribuiu com 31
estudos primários, sendo 21 estudos de qualidade “Muito Boa”.
§ O desafio “comunicação” com 63% de evidências no estudos, continua
sendo um dos desafios mais evidenciados na literatura e, alguns novos
desafios foram evidenciados como: Orçamento (2%) e economia (2%).
§ Entre as evidências 29% das melhores práticas estão relacionadas
ainda ao desafio “comunicação”.
§ Os estudos primários continuam apenas propondo o uso da
ferramentas, não realizando experimentos sobre o uso das mesmas.
§ Os modelos de apoio ao gerenciamento de software no DDS ainda
continuam apenas propostos na literatura, sem avaliação através de
141
experimentos ou outros estudos. Apenas um estudo que relatou
experiência do modelo TAPER. Quatro novos modelos de apoio foram
evidenciados pelos estudos: A reference model for global software
development, DRiMaP—a model of distributed risk management,
Dyadic model e GSD model.
Comparando algumas das evidências encontradas nos estudos deste
mapeamento aos evidenciados na revisão de Costa (2009), os seguintes resultados
são apresentados na Tabela 4.10. Na primeira coluna são listadas as questões de
pesquisa e na segunda, os dados extraídos das evidências nos estudos.
Respectivamente, na terceira e quarta coluna, apresentam-se a quantidade de
estudos evidenciados por Costa (2009) e por este mapeamento realizado neste
trabalho.
Tabela 4.10 - Comparação de evidências encontradas na literatura Fonte: Elaboração própria, com base em Costa e na pesquisa
Questões de Pesquisa Dados extraídos
Quantidade de trabalhos de
Costa (2009) / Proporção
Quantidade de trabalhos / Proporção
Q1. Desafios no gerenciamento de projetos no DDS
Comunicação 34 63% 140 63% Diferença Cultura 31 57% 140 63%
Coordenação 23 43% 48 21%
Diferença Temporal 19 35% 79 35%
Dispersão geográfica 13 24% 91 41%
Idioma/Barreira linguística 9 17% 61 27%
Gestão de Risco 2 4% 31 14%
Confiança 13 24% 26 12%
Infraestrutura 12 22% 22 10% Gestão de conflitos/ Gestão de pessoas 9 17% 20 9%
Q2. Melhores Práticas no gerenciamento de projetos no DDS
Disponibilização e Treinamento em Ferramentas de Comunicação e Colaboração
10 19% 12 5%
Disponibilização de múltiplos canais de comunicação síncrona face a face
10 19% 18 8%
Visita entre sites 7 13% 10 4%
Promover interações Informal 5 9% 30 13%
Transferência de Conhecimento 5 9% 8 4%
Detalhar o planejamento 5 9% 7 3% Motivar equipe/ Manter espírito de equipe 3 6% 7 3%
142
Criação de protocolo de comunicação 5 9% 8 4%
Gestão de Configuração 4 7% 11 5%
Gerenciar cronograma 2 4% 5 2% Q3. Ferramentas de apoio no gerenciamento de projetos no DDS
E-mail 17 31% 50 22% Videoconferência 14 26% 37 17%
Bate-papo (Chat) 11 20% 45 20%
Telefone 9 17% 33 15%
Teleconferência 8 15% 15 7%
Wiki 7 13% 22 10%
Áudio Conferência 5 9% 10 4%
NetMeeting 4 7% 10 4%
Quadros Virtuais (Photo Gallery) 4 7% 7 3%
Blog 1 2% 6 3% Q4. Modelos de apoio no gerenciamento de projetos no DDS
TAPER 1 2% 4 2% Approach to offshore collaboration 1 2% 3 1% Solar system 1 2% 2 1% GSD Model 0 0% 3 1% A reference model for global software development 0 0% 1 0%
DRiMaP—a model of distributed risk management 0 0% 2 1%
Project management framework 1 2% 2 1% Framework for supporting management in distributed information systems development
1 2% 2 1%
NEXTMOVE 1 2% 2 1% Framework to enable coordination in distributed software development 1 2% 2 1%
A partir da Tabela 4.10, conclui-se que a literatura continua apresentando
estudos que mostram os desafios, melhores práticas, ferramentas e modelos de
apoio para o gerenciamento de projetos no DDS. Através da comparação
proporcional entre os dois trabalhos, observa-se que houveram mudanças. Contudo,
destaca-se os desafios “Comunicação” e “Diferença Temporal”, que mesmo com o
passar do tempo, continuam com o mesmo cenário do período pesquisado por
Costa (2009).
4.7 Considerações finais Neste capítulo foram apresentados os resultados do mapeamento sistemático
realizado. O processo de busca retornou 2123 estudos, dos quais 373 foram
classificados como estudos primários relevantes e 224 estudos foram selecionados
143
como estudos primários. IEEE e a Elsevier Scopus foram os que mais contribuíram
para o mapeamento, com 71 e 68 estudos.
Os estudos primários selecionados apresentaram: 32 desafios, 28 melhores
práticas, 31 ferramentas e 14 modelos para apoiar o gerenciamento de projetos de
desenvolvimento distribuído de software. Os dados foram sumarizados e seguindo
abordagem de Costa (2009), foram agrupados e apresentados na Seção 4.2, deste
trabalho. Também foi comparados os resultados deste mapeamento com os do
trabalho de Costa (2009), observando-se que mudanças aconteceram, mais que,
desafios como: “Comunicação” e “Diferença Temporal”, continuam sendo
evidenciados pela literatura.
144
Capítulo
5 5. Considerações finais
Neste capítulo, as considerações finais deste trabalho são apresentadas. Entre
elas são discutidas limitações, ameaças a validade do estudo, trabalhos futuros e as
conclusões obtidas com a pesquisa.
145
5.1 Limitações do estudo
Um dos pontos fortes da abordagem de gerenciamento de projetos no DDS
proposto neste trabalho é que ela é baseada em evidências existentes no meio
industrial e científico. Uma vez que estas evidências foram encontradas em artigos
de revistas, periódicos, conferências de qualidade. No entanto, a abordagem herda
as ameaças à validade dos estudos a partir do qual as evidências foram coletadas.
Apesar da preocupação em utilizar quadro metodológico rigoroso, esta
pesquisa possui algumas limitações:
§ Os estudos experimentais e os relatórios de experiência industrial não
constataram informações contextuais sobre a distribuição geográfica.
Consequentemente não é possível saber se os estudos se concentram
em determinadas regiões ou países, podendo assim representar uma
ameaça a validade externa, por não saber se os resultados
representam todos os principais desenvolvedores de software ao redor
do mundo.
§ Toda a extração foi realizada por apenas um pesquisador, que possui
conhecimento básico através da literatura sobre gerenciamento de
projetos de desenvolvimento distribuído de software. Isso representa
uma limitação, mas é previsto por Kitchenham (2007) para alunos de
doutorado. Segundo o autor, basta que orientador da tese, participe da
revisão do protocolo e revise partes da execução da revisão, como
realizado nesta dissertação.
5.2 Trabalhos Futuros Um importante ponto que deve ser evidenciado em um trabalho é o de se
identificar oportunidades de trabalhos futuros, visando levantar essas oportunidades.
Apresenta-se alguns caminhos para novas pesquisas.
§ Utilização prática da abordagem, através da condução de estudos de
caso ou pesquisa-ação em ambientes industriais, sendo necessária
não só para testar a abordagem, mas também aumentar o número de
evidências sobre a utilização de boas práticas, ferramentas e modelos
no gerenciamento de projetos no DDS.
146
§ Apresentar a abordagem de apoio ao gerenciamento de projetos em
DDS aos autores dos estudos primários, coletando a avaliação deles
quanto à síntese constatada a partir dos seus estudos, fazendo assim
uma análise qualitativa.
§ Realizar busca através das referências bibliográficas declaradas nos
estudos primários selecionados com a finalidade de selecionar novos
estudos.
§ Realizar estudo através de análise envoltória de dados de forma a criar
o ranking das fontes de busca perante a qualidade de estudos
primários retornados.
§ Verificar a variação temporal dos resultados, referente as ferramentas.
§ Realizar a procedência geográfica dos estudos primários;
§ E por fim, estender o protocolo a novos engenhos de busca e ampliar a
busca manual a novas conferências e periódicos.
5.3 Conclusões Este mapeamento sistemático procurou na literatura por estudos que apoiam o
gerenciamento de projetos no desenvolvimento distribuído de software. Quatro
questões de pesquisa foram usadas para guiar o trabalho, sendo que as buscas
retornaram 2123 estudos. Ao aplicar os critérios de exclusão definidos, restaram 373
estudos potencialmente relevantes e destes, após a leitura do resumo e da
conclusão, mais 149 foram excluídos, restando assim 224 estudos primários
selecionados, sendo que 63% foram avaliados como “Muito Bom”, e 22% com
qualidade “Excelente”. Com isso, somam-se 85% dos trabalhos avaliados por esta
pesquisa, baseando-se nos critérios de (BEECHAN et al. 2005), possuem qualidade
alta.
O cenário apresentado pelo trabalho de Costa (2009) mudou perante esta nova
pesquisa. Foi possível observar que a literatura, dentro do recorte proposto nesta
pesquisa, além de aumentar o número de estudos evidenciados, apresentou
mudanças em relação aos desafios, melhores práticas, ferramentas e modelos de
apoio ao gerenciamento de projetos no DDS. Por exemplo, houve adição de
147
ferramentas e novos modelos de apoio. Vale destacar que estas ferramentas,
apenas foram propostas pela literatura, não sendo validadas.
Com a evidenciação dos dados, pode-se realizar um comparativo com o
cenário do trabalho de Costa (2009) com esta pesquisa. Identifica-se que dentre os
desafios e soluções (melhores práticas, ferramentas e modelos) de apoio ao
gerenciamento de projetos no DDS, alguns aumentaram, outros diminuíram, outros
ficaram equivalentes e novos surgiram na literatura. Destaca-se o desafio
“Comunicação”, que permanece com maior número de evidências, totalizando 63%
dos estudos retornados, tanto atualmente quanto na pesquisa de Costa (2009). E, o
desafio “Dispersão geográfica”, teve aumento proporcional de 70% perante o
identificado por Costa (2009). Estes itens então, merecem mais atenção no que
tangem o desenvolvimento distribuído de software.
Esta pesquisa buscou além de contribuir com o desenvolvimento distribuído de
software, contribuiu com a Engenharia de Software Baseada em Evidências. O
trabalho apresentou um processo detalhado para a realização de um estudo de
mapeamento sistemático, em que novas evidências foram identificadas para apoiar
no gerenciamento de projetos no desenvolvimento distribuído de software, servindo
de base para outros estudos.
Contudo, os resultados deste mapeamento contribuem para o desenvolvimento
distribuído de software, e para a abordagem proposta por Costa (2009) reafirmando
algumas evidências. Fornece à comunidade acadêmica uma compreensão sobre os
desafios no gerenciamento de projetos no DDS, mostrando as novas evidências
encontradas na literatura. Serve de apoio aos profissionais e pesquisadores na
identificação de desafios relevantes e definição de soluções para os mesmos,
utilizando para isso, as melhores práticas, ferramentas e modelos que já foram
evidenciados por outros estudos primários.
148
Referências
ARKSEY, H.; O'MALLEY,L. Scoping studies: towards a methodological framework. International Journal of Social Research Methodolog, v.8, n.1, p.19-32. doi 10.1080/1364557032000119616, 2005).
AUDY, J.; PRIKLADNICKI, R. Desenvolvimento Distribuído de Software: Desenvolvimento de software com equipes distribuídas . Rio de Janeiro: Elsevier, 2007.
BAILEY, J.; BUDGEN, D.; TURNER, M.; ET AL. Evidence relating to Object-Oriented software design: A survey. First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007), p. 482 – 484. Ieee. Doi: 10.1109/ESEM.2007.
BEECHAN, S. et al. Motivation in Software Engineering: A systematic literature review. Information and Software Technology: Elsevier, v. 50, n. 860 -878, 2007.
BIOLCHINI, J. et al. Systematic Review in Software Engineering . Technical Report. 2005.
BIOLCHINI, J.; TRAVASSOS, G. Revisões sistemáticas aplicadas a engenharia de software. In XXI SBES - Brazilian Symposium on Software Engineering, João Pessoa, PB, Brasil, 2007.
BRANCO, E. C.; BELCHIOR A. D. Um modelo para avaliação da qual idade da gerência de projetos de software. SBQS, Gramado, RS, Brasil, 2002.
BRUZZI, D. G. Gerência de Projetos. Brasília: Senac-DF, 2008.
CAPPER, G., OATES, B. J. Using systematic reviews and evidence-based software engineering with masters students. In EASE ’09: 13th International Conference on Evaluation and Assessment in Software Engineering. BCS, 2009.
CARMEL, E. Global Software Teams – Collaborating Across Borders and Time -Zones. Prentice Hall, EUA, 1999.
CARMEL, Erran; AGARWAL, Ritu. Tatical Approaches for Alleviating Distance in Global Software Development. IEEE Software , California, v. 16, n. 2, p. 22-29, Mar. /Abr. 2001.
CLELAND, D., IRELAND, L.(2002). Gerência de projetos. 10 edição. Rio de Janeiro: Reichmann & Affonso Editores, 324p.
COCKBURN. Alistair. Agile Software Development – The Agile Software Development Series. EUA: Addison-Wesley, 2002. 256 p.
149
COSTA, C. Revisão Sistemática da Literatura em Gerenciamento de Projetos no Desenvolvimento Distribuído de Software. Recife – PE. 2009.
DA SILVA, F. Q. B. et al. (2010). Critical Appraisal of Systematic Reviews in Software Engineering: a Tertiary Study. ESEM’2010, Bolzano-Bolzen, Italy.
DYBÅ T. et al. Applying Systematic Reviews to Diverse Study Types: An Experience Report. First International Symposium on Empirical Software Engineering and Measurement, ESEM, 2007.
DYBÅ, T., Torgeir Dingsoyr, and Geir K. Hanssen. Applying systematic reviews to diverse study types: An experience report. In Proceedings of the First International Symposium on Empirical Software Engineering and Measurement, ESEM ’07, pages 225–234, Washington, DC, USA, 2007. IEEE Computer Society.
EASTERBROOKS, S. et al. Selecting Empirical Methods for Software Engineering Research. International conference on Automated software engineering, Atlanta, Georgia, EUA, 2007.
ERICKSON, J. M.; RANGANATHAN, C. Project Management Capabilities: Key to Application Development Offshore Outsourcing. Proc. 39th Annual Hawaii International Conference on System Sciences HICSS '06, vol. 8, 199b, 2006.
FRAME, J. D. Managing Projects In Organizations, São Francisco: Jossey-Bass inc, 1995.
FREITAS, A. V. APSEE-Global: a Model of Processes Management of Distributed Software Processes. Faculdade de Informática – UFRS – RS- Brazil, 2005.
HELDMAN, K. Gerência de Projetos: guia para o exame oficial do PMI . Rio de Janeiro: Elsevier, 2006.
HERBSLEB, J. D.; MOITRA, D. Global Software Development . IEEE Software Magazine, IEEE Computer Society, EUA, 2001.
HERBSLEB, James; MOCKUS, Audris. An empirical study of speed and communication in globally distributed software development. IEEE Transactions on Software Engineering . EUA, v.29, n.6, p.481-494, 2003.
JIMÉNEZ, M. et al., Challenges and Improvements in Distributed Software Development: A Systematic Review. Advances in Software Engineering, 2009.
KAROLAK, Dale Walter. Global Software Development – Managing Virtual Teams and Environments. Los Alamitos, EUA: IEEE Computer Society, 1998. 159p.
KERZNER, H. Advanced project management: best practice on implementation. John Wiley & Sons, Inc. Hoboken, New Jersey, 2004.
KHAN, K.S. et al. Undertaking Systematic Review of Research on Effectiveness . CRD Report Number 4 (Second Edition), NHS Centre for Reviews and
150
Dissemination, University of York, UK, 2001.
KIEL, L. Experiences in Distributed Development: A Case Study . Workshop on Global Software Development at ICSE, Oregon, EUA, 2003.
KITCHENHAM, B. A.; CHARTERS, S. Guidelines for performing systematic literature reviews in software engineering. Technical Report EBSE 2007-001, Keele University and Durham University Joint Report, July 2007.
KITCHENHAM, B. CHARTERS, S. Guidelines for performing Systematic Literature Reviews in software Engineering. Technical Report EBSE-2007-01, Scholl of Computer Science and Mathematics, Keele University, 2007.
KITCHENHAM, B. et al. Evidence-based Software Engineering. Proceedings of the 26th International Conference on Software Engineering (ICSE’04). IEEE Computer Society, Washington DC, USA, p. 273 – 281, 2004.
KITCHENHAM, B. Guidelines for performing Systematic Literature Re views in Software Engineering. Vol 2.3 EBSE Technical Report, EBSE-2007-01, 2007.
KITCHENHAM, B. Procedures for Performing Systematic Reviews. Joint Technical Report, Software Engineering Group, Keele University, and Empirical Software Eng., Nat'l ICT Australia, 2004.
KOMI-SIRVIÖ, S.; TIHINEN M. Lessons Learned by Participants of Distributed Software Development. Journal Knowledge and Process Management, vol. 12 nº 2 p. 108 –122, 2005.
LAMERSDORF, A., MÜNCH J., ROMBACH, D. (2009) “A Survey on the State of the Practice in Distributed Software Development: Criteria for Task Allocation,”, IEEE Int. Conf. on Global Software Engineering, ICGSE 2009, pp. 41-50.
LEITE, J. C. Planejamento e Gerenciamento de Projeto de Software . Disponível em http://www.dimap.ufrn.br/~jair/ES/slides/PlanejamentoGerenciamentoIntroducao.pdf . Acessado em: 8/junho/2013.
LIANG, H. Distributed Software Development . Leading Edge Forum. CSC Experience e Results, 2008.
LOPES, L. et al. Uma proposta para processo de requisitos em ambientes de desenvolvimento de software. VI Workshop em Engenharia de Requisitos do SBC, Anais do WER'03, vol. 1. p. 78-92. Piracicaba, SP, Brasil, 2003.
MACGREGOR, E. et al. The impact of intercultural factors on global software development. Proc. Canadian Conference on Electrical and Computer Engineering , p. 920- 926, 2005.
MAFRA, S. et al. Aplicando uma Metodologia Baseada em Evidência na Definição de Novas Tecnologias de Software . In: Anais do XX Simpósio Brasileiro de Engenharia de Software, Florianópolis, SC, Brasil, p. 239-254, 2006.
151
MAK, D. K. M.; KRUCHTEN, P. B. NextMove: A Framework for Distributed Task Coordination. Proc. 18th Australian Software Engineering Conference ASWEC 2007 , p. 399-408, 2007.
MARCONI, M.; LAKATOS, E. Metodologia Cientifica: Ciência e Conhecimento Científico. Atlas, 2001.
MARQUARDT, Michael J; HORVATH, Lisa. Global Teams: How top multinationals span boundaries and cultures with higt-speed teamwork. Davies-Black Publishing. Palo Alto, EUA. 2001. 246p.
MARTINS, J. C. C. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML. Rio de Janeiro: Brasport, 2007.
MCBRIDE, T. The use of project management mechanisms in software development and their relationship to organisational distance: An emperical. Dissertation. Department of Software Engineering Faculty of Information Technology University of Technology, Sydney , 2005.
MONTEIRO, C. V. F. Impacto do uso de ferramentas de software n as fases iniciais do processo de inovação. Dissertação de Mestrado. Universidade Federal de Pernambuco , Recife, PE, Brasil, 2010.
OATES, J. B.; CAPPER G. Using systematic reviews and evidence -based software engineering with masters students. International Conference on Evaluation & Assessment in Software Engineering, EASE, 2009.
OMORONYIA, I. et al. A 3-Dimensional Relevance Model for Collaborative Software Engineering Spaces. Second IEEE International Conference on Global Software Engineering, ICGSE, p. 204 – 216, 2007.
PETERSEN, K.; FELDT, R.; MUJTABA, M. Systematic Literature Reviews in Software Engineering. Vol 2.3 EBSE Techical Report, EBSE-2007-01, 2007.
PETTICREW, M.; ROBERTS, H. Systematic Reviews in the Social Sciences: A Pratical Guide. Wiley-Blackwell, 2005;
PICHLER, H. Be successful, take a hostage or "outsourc ing the outsourcing Manager". Proc. Second IEEE International Conference on Global Software Engineering , ICGSE, p. 156-161, 2007.
PMI. Um guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK), 4.ed. Project Management Institute, Inc. Newton Square, Pennsylvania, EUA, 2008.
PMISP. Project Management Institute, Capítulo São Paulo (PMI®). Disponível em: http://www.pmisp.org.br/index.asp . Acessado em: 27/jun/2013.
PRIKLADNICKI, R. MuNDDoS - Um modelo de referência para desenvolvimento distribuído de software. Dissertação de Mestrado, PUC/RS, Porto Alegre, RS, Brasil, 2003.
PRINCE2. Foundation & PRINCE2 Practitioner Project Management Training.
152
Disponível em: http://www.prince2.com/ Acessado em: 28/jun/2013
RALYTE, J. et al. A Framework for supporting management in distributed information systems development. Proc. Second International Conference on Research Challenges in Information Science RCIS, p. 381-392, 2008.
REZENDE, D. A. Engenharia de Software e Sistemas de Informação . 3ª ed. Rio de Janeiro: Brasport, 2005.
SOMMERVILLE, I. Engenharia de Software. 8ª ed., São Paulo: Pearson Addison-Wesley, 2007.
SUTHERLAND, J. et al. Distributed Scrum: Agile Project Management with Outsourced Development Team. Proc. 40th Annual Hawaii International Conference on System Sciences HICSS, 274a, 2007.
TORREÃO, P. G. B. C. P. Project Management Knowledge Learning Environment: Ambiente de Aprendizado para Educação em Gerenciamento de Projetos. Dissertação de Mestrado, Universidade Federal de Pernambuco, Recife, PE, Brasil.
TRAVASSOS, G., BIOLCHINI J. Revisões Sistemáticas Aplicadas a Engenharia de Software. In: XXI SBES - Brazilian Symposium on Software Engineering, João Pessoa , PB, Brasil, 2007.
VARGAS, R. V. Gerenciamento de Projetos: estabelecendo diferenciais competitivos. 6ª ed. Rio de Janeiro: Brasport , 2005.
WHOLIN, C., Runeson, P., Höst, M., Ohlsson, M., Regnell, B., andWessl´en, A. Experimentation in Software Engineering: An Introduction. Kluwer, 2000.
ZANONI, R. Modelo de Gerência de Projeto Baseado no PMI para ambientes de Desenvolvimento de Software Fisicamente Distribuído. Dissertação de Mestrado, PUC/RS, Porto Alegre, RS, Brasil, 2002.
153
Apêndices Apêndice A – Estudos primários incluídos
ID Ano Fonte Referências Qualidade
EP_01 2011 ACM An Analysis of Collaborative Patterns in Large-Scale Ontology Development Projects. ACM. Falconer, S. M., Tudorache, T. & Noy, N., F.
Média
EP_02 2011 ACM
An Empirical Investigation of Virtual World Projects and Metaverse Technology Capabilities. Communications of ACM. Owens, D., Mitchell, A., Khazanchi. D. & Zigurs, I.
Excelente
EP_03 2010 ACM Using Global Pairs for Reducing Software Development Time. Communications of ACM. Jalote, P.& Gupta, A.
Excelente
EP_04 2010 ACM
A Case Study of Project Management Practices in Virtual Settings: Lessons from Working in and Managing Virtual Teams. Communications of ACM. Beise, C., Carte, T., Vician, C. & Chidambaram, L.
Média
EP_05 2010 ACM Managing a Corporate Open Source Software Asset. Communications of ACM. Gurbani, by Vijay K., Garvert, Anita , and Herbsleb, James D.
Muito Boa
EP_06 2010 SciencDirect
Process models in the practice of distributed software development: A systematic review of the literature. Information and Software Technology. Prikladnicki, Rafael, & Audy, Jorge Luis Nicolas.
Muito Boa
EP_07 2011 SciencDirect
Barriers in the selection of offshore software development outsourcing vendors: An exploratory study using a study using a systematic literature review. Information and Software Technology. Khan, Siffat Ullah, Niazi, Mahmood, & Ahmad, Rashid.
Excelente
EP_08 2011 SciencDirect
Understanding technology use in global virtual teams: Research methodologies and methods. Information and Software Technology. Clear, Tony, & MacDonell, Stephen G.
Boa
EP_09 2010 SciencDirect
Coordination implications of software architecture in a global software development project. The Journal of Systems and Software. Avritzera, Alberto, Paulisha, Daniel, Caib, Yuanfang, & Sethib, Kanwarpreet.
Excelente
EP_10 2009 SciencDirect
A comparative study of important risk factors involved in offshore and domestic outsourcing of software development projects: A two-panel Delphi study. Information & Management. Nakatsu, Robbie T. , & Iacovou, Charalambos L.
Excelente
EP_11 2010 SciencDirect
What affects information systems development team performance? An exploratory study from the perspective of combined socio-technical theory and coordination theory. Computers in Human Behavior. Lu, Y., Xiang, C., Wang, B., & Wangc, X.
Excelente
154
EP_12 2010 SciencDirect
Fostering trust in virtual project teams: Towards a design framework grounded ina Trust Worthiness Antecedents(TWAN)shema. Int. J.Human-ComputerStudies. Rusmann, E., Bruggen, Jan v., Sloep, P., & Koper, R.
Muito Boa
EP_13 2010 SciencDirect
Perceived job effectiveness in competition: A survey of virtual teams within business organizations. Computers in Human Behavior. Lin, Chieh-Peng, Wang, Yi-Ju, Tsai, Yuan-Hui, & Hsu, Yu-Fang. Hsu
Excelente
EP_14 2010 SciencDirect
Team member selection decisions for virtual versus face-to-face teams. Computers in Human Behavior. D’Souza, Geeta C. ,& Colarelli, Stephen M.
Muito Boa
EP_15 2011 SciencDirect
Virtual organization for open innovation: Semantic web based inter-organizational team formation. Expert Systems with Applications. Wia, H., Ohb, S., & Jung, M.
Excelente
EP_16 2011 SciencDirect
Trust estimation in a virtual team: A decision support method. Expert Systems with Applications. Zhi-Ping Fan, Wei-Lan Suo, Bo Feng, Yang Liu.
Excelente
EP_17 2011 SciencDirect
A distributed multi-model-based Management Information System for simulation and decision-making on construction projects. Advanced Engineering Informatics. Scherer,R.J., & Schapke, S.-E.
Excelente
EP_18 2011 SciencDirect
Collaborative virtual geographic environments: A case study of air pollution simulation. Information Sciences. Xu, B., Lin, H., Chiu, L., Hua, Y., Zhu, J., Hua, M., Cui, W.
Muito Boa
EP_19 2009 SciencDirect
Artifact awareness through screen sharing for distributed groups. Int. J.Human-ComputerStudies. Teea, K., Greenberga, s, & Gutwinb, C.
Muito Boa
EP_20 2010 SciencDirect
Team member selection decisions for virtual versus face-to-face teams. Computers in Human Behavior. D’Souza, Geeta C. , & Colarelli, Stephen M.
Muito Boa
EP_21 2010 SciencDirect
Getting on the same page: Collective hermeneutics in a systems development team. Information and Organization. Hansen,S., & Rennecker, J.
Excelente
EP_22 2011 SciencDirect Guest editorial: Studying work practices in Global Software Engineering. Information and Software Technology. Editorial.
Muito Boa
EP_23 2010 SciencDirect
Factors influencing clients in the selection of offshore software outsourcing vendors: An exploratory study using a systematic literature review. The Journal of Systems and Software. Khana, Siffat U., Niazia, M., & Ahmadd, R.
Excelente
EP_24 2009 SciencDirect
Use of collaborative technologies and knowledge sharing in co-located and distributed teams: Towards the 24-h knowledge factory. Journal of Strategic Information Systems. Gupta, A., Mattarelli, E., Seshasai,S., & Broschak, J.
Muito Boa
EP_25 2011 SciencDirect
Performance Evaluation of Software Development Teams: a Practical Case Study. Electronic Notes in Theoretical Computer Science. Fernandes, P., Sales, A. Santos, Alan
Muito Boa
155
R., & Webber, T.
EP_26 2002 Scopus Creating Virtual Teams for Engineering Design. Int. J. Engng Ed. Vol. 19, No. 2, pp. 316±327. Wilczynski, V. & Jennings, John J.
Excelente
EP_27 2003 Scopus
Virtual Teams: Guide to Successful Implementation. JOURNAL OF MANAGEMENT IN ENGINEERING. Chinowsky, Paul S., & Rojas,Eddy M.
Muito Boa
EP_28 2004 Scopus Managing cross-cultural issues in global software outsourcing. COMMUNICATIONS OF THE ACM. Krishna, By S.,Sahay, S., & Walsham, G.
Excelente
EP_29 2004 Scopus
Virtual Teams: A Review of Current Literature and Directions for Future Research. The DATA BASE for Advances in Information Systems - Winter. Powell, A., Piccoli, G. & Ives, B.
Excelente
EP_30 2004 Scopus Strategies for global information systems development. Information & Management. Akmanligila, M. & Palvia, P. C.
Muito Boa
EP_31 2004 Scopus
Human-centered design of a distributed knowledge management system. Journal of Biomedical Informatics. Rinkus, S., Walji, M., Johnson-Throop, Kathy A., Malinb, Jane T.,Turley, James P., Smith, Jack W. & Zhang, J.
Muito Boa
EP_32 2004 Scopus Virtual workgroups in offshore systems development. Information and Software Technology. Sakthivel, S.
Excelente
EP_33 2004 Scopus
Exploring defect causes in products developed by virtual teams. Information and Software Technology. Jacobs,J.,Moll, Jan v., Krause, P.,Kusters, R., Trienekens, J., Brombacher, A.
Excelente
EP_34 2006 Scopus Global Software Development One of the Biggest Companies in Latvia: Is Geographical Distribution a Problem?. Softw. Process Improve. Smite, D.
Excelente
EP_35 2006 Scopus
Enabling Collaboration in Distributed Requirements Management. IEEE Computer Society. Sinha, V., And Sengupta, B., & Chandra, S.
Excelente
EP_36 2006 Scopus Ambidextrous Coping Strategies In Globally Distributed Software Development Projects Excelente
EP_37 2006 Scopus Global boundaries, task processes and IS project success: a field study. Information Technology & People. Espinosa, J. A., DeLone, W., & Lee, G.
Muito Boa
EP_38 2007 Scopus
Using Digital Socialization to Support Geographically Dispersed AEC Project Teams. JOURNAL OF CONSTRUCTION ENGINEERING AND MANAGEMENT. EI_tayeh, A., & Gil, N.
Excelente
EP_39 2007 Scopus
Self-organization of teams for free/libre open source software development. Information and Software Technology. Crowston, K., Li, Q., Wei, K., Eseryel, Y., & Howison, J.
Muito Boa
EP_40 2007 Scopus Making Knowledge Work in Virtual Teams.COMMUNICATIONS OF THE ACM. Thomas, D.M., Bostrom, R. P. & Gouge, M.
Muito Boa
156
EP_41 2008 Scopus
Developing a knowledge-based perspective on coordination: The case of global software projects. Information & Management. Kotlarsky, J., Fenema, Paul C. V., & Willcocks, L. P.
Excelente
EP_42 2008 Scopus
Conceptual Framework on Risk Management in IT Outsourcing Projects. INFORMATION SCIENCE & APPLICATIONS. Aris, S. R. H. S., Arshad, N. H., & Mohamed, A.
Muito Boa
EP_43 2008 Scopus
Wiki Customization to Resolve Management Issues in Distributed Software Projects. Software Engineering Technology. Hohman, J. & Saiedian, H.
Excelente
EP_44 2008 Scopus A model to develop effective virtual teams. Decision Support Systems. Lin, C., Standing, C. & Liu, Ying-chieh.
Muito Boa
EP_45 2008 Scopus The mechanisms of project management of software development.The Journal of Systems and Software. McBride, T.
Muito Boa
EP_46 2008 Scopus
A Model of Conflict, Leadership, and Performance in Virtual Teams. Information Systems Research. Wakefield, R. L., & Leidner, D. E.
Muito Boa
EP_47 2009 Scopus
Managing Risks in Distributed Software Projects: An Integrative Framework. IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT. Persson, J. S., Mathiassen, L. Boeg, J., Madsen, T. S., & Steinson, F.
Muito Boa
EP_48 2009 Scopus
On Preparing Students for Distributed Software Development with a Synchronous, Collaborative Development Platform. Computing and Information Sciences Education. Meneely, A., & Williams, L.
Muito Boa
EP_49 2009 Scopus
Social networks and coordination performance of distributed software development teams. Journal of High Technology Management Research. Hossain, L. & Zhu, D.
Muito Boa
EP_50 2009 Scopus
OFFSHORE INFORMATION SYSTEMS PROJECT SUCCESS: the role os social embeddedness and cultural characteristics. Offshore IS Project Success. Rai, A., Maruping, L. M., & Venkatesh, V.
Muito Boa
EP_51 2009 Scopus
Exploring Agility in Distributed Information Systems Development Teams: An Interpretive Study in an Offshoring Context. Information Systems Research. Sarker, S., & Sarker, S.
Muito Boa
EP_52 2009 Scopus
Implementation of Global Software Development: A Structured Approach. SOFTWARE PROCESS IMPROVEMENT AND PRACTICE. Casey, V., & Richardson, I.
Muito Boa
EP_53 2009 Scopus The impact of virtual technologies on knowledge-based processes: An empirical study. Research Policy. Vaccaro, A., Veloso, F. & Brusoni, S.
Excelente
EP_54 2009 Scopus Towards a Globalized Software Industry. Acta Polytechnica Hungarica. Jaakkola, H. Muito Boa
EP_55 2009 Scopus
Virtual R & D teams in small and medium enterprises: A literature review. Scientific Research and Essays. Ebrahim, Ale N., Ahmed, S. & Taha, Z.
Muito Boa
157
EP_56 2010 Scopus
Engineering, Construction and Architectural Management Emerald Article: Critical, manifest variables in virtual construction project value delivery. References in Scopus. Barima, O. & Rowilnson, SM.
Muito Boa
EP_57 2010 Scopus
Global Dimension of Robust Project Network Design. JOURNAL OF CONSTRUCTION ENGINEERING AND MANAGEMENT. Wong, K., Unsal, H., Taylor, J. E. & Levitt, R. E.
Muito Boa
EP_58 2010 Scopus Project Risk Differences Between Virtual And Co-Located Teams. Journal of Computer Information Systems. Reed, A. H., & Knight, L. V.
Muito Boa
EP_59 2010 Scopus
Developing Trust In Virtual Software Development Teams. Journal of Theoretical and Applied Electronic Commerce Research. Casey, V.
Excelente
EP_60 2010 Scopus
Fostering trust in virtual project teams:Towards a design framework grounded in a TrustWorthiness Antecedents (TWAN) schema. Int. J.Human-ComputerStudies. Rusman, E., Bruggen, J. V., Sloep, P., & Koper, R.
Muito Boa
EP_61 2010 Scopus
A Model of job satisfaction for collaborative development processes. The Journal of Systems and Software. Pedrycz, W., Russo, B., & Succi, G.
Muito Boa
EP_62 2011 Scopus
Managing Outsourced Software Projects: An Analysis of Project Performance and Customer Satisfaction. Production and Operations Management Society. Narayanan, S., Balasubramanian, S., & Swaminathan, J. M.
Muito Boa
EP_63 2011 Scopus
Organizing Global Product Development for Complex Engineered Systems. IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT. Tripathy, A., & Eppinger, S. D.
Muito Boa
EP_64 2004 Scopus
Caramba—A Process-Aware Collaboration System Suppoting Ad hoc and Collaborative Processes in Virtual Teams. Distributed and Parallel Databases. Dustdar, S.
Muito Boa
EP_65 2007 Scopus Philips experiences in global distributed software development. Empir Software Eng. Kommeren, R., & Parviainen, P.
Muito Boa
EP_66 2008 Scopus
The impact of cultural differences in offshore outsourcing—Case study results from German–Indian application development projects. Inf Syst Front. Winkler, J. K., Dibbern, J., & Heinzl, A.
Muito Boa
EP_67 2009 Scopus Distributed agile: project management in global environment. Empir Software Eng. Lee, S., & Yong, H.
Excelente
EP_68 2010 Scopus A multi-criteria distribution model for global software development projects. J Braz Comput Soc. Lamersdorf, A., & Münch, J.
Excelente
EP_69 2010 Scopus Virtual software team project management. J Braz Comput Soc. Casey, V. Muito Boa
EP_70 2001 Scopus Surviving Global Software Development. IEEE SOFTWARE. Ebert, C., & Neve, P. Muito Boa
EP_71 2002 Scopus Collaborative Software Engineering. JOURNAL OF OBJECT TECHNOLOGY. Goldberg, A. Muito Boa
158
EP_72 2004 Scopus Beyonde the Black Box: Knowledge Overlaps in Software Outsourcing. The IEEE Computer Societ. Tiwana, A.
Muito Boa
EP_73 2005 Scopus Risks factors associated with offshore IT outsourcing. Industrial Management & Data Systems. Tafti, M. H.A.
Muito Boa
EP_74 2006 Scopus
Global Software Development Projects in One of the Biggest Companies in latvia: Is Geographical Distribution a Problem?. Wiley InterScience. Smite, D.
Excelente
EP_75 2007 Scopus
Global Software Development: Exploring socialization and face-to-face meetings in distributed strategic projects. Journal of Strategic Information Systems. Oshri, I., Kotlarsky, J., & Willcocks, L.P.
Excelente
EP_76 2007 Scopus
Effective strategies for internal outsourcing and offshoring of business services: An empirical investigation. Journal of Operations Management. Aksin, O. Z., & Masini, A.
Boa
EP_77 2008 Scopus A US Client’s learning from outsourcing IT work offshore. Springer Science + Business Media. Lacity, M. C., & Rottman, J. W.
Muito Boa
EP_78 2009 Scopus Real-World Opportinities for Virtual-World Project Management. IEEE. Owens, D., Davis, A., Murphy, J.D, Khazanchi, D. & Zigurs, I.
Muito Boa
EP_79 2009 Scopus
Critical Decisions in Software Development: Updating the State of the Practice. IEEE. Cusumano, M. A., MacCormack, A., Kemerer, C.F., & Crandall, W.
Muito Boa
EP_80 2009 Scopus Success Factors for Globally Distributed Projects. SOFTWARE PROCESS IMPROVEMENT AND PRACTICE. Zopf, S.
Muito Boa
EP_81 2010 Scopus Software Risks And Mitigation in Global Software development. Journal of Theoretical and Applied Information Technology. Khan, Q., & Ghayyur, S.
Muito Boa
EP_82 2011 Scopus
Impact of Poor Requirement Engineering in Software Outsourcing: A Study on Software Developers’ Experience. Int. J. of Computers, Communications & Control. Perera, I.
Muito Boa
EP_83 1998 Scopus Managing Geographically Distributed Teams. Communication Society. ©1998 IEEE. Anschuetz, L.
Muito Boa
EP_84 2001 Scopus Outsourcing in India. IEEE Software. Kobitzsch, W., Rombach, D. & Feldmann, R. L. Muito Boa
EP_85 2004 Scopus A social interaction approach to managing the “invisibles” of virtual teams Muito Boa
EP_86 2006 Scopus Assigning tasks in a 24-h software development model. The Journal of Systems and Software. Jalote, P. & Jain, G.
Muito Boa
EP_87 2008 Scopus
Missing Links: Building Critical Social ties for Global collaborative Teamwork. COMMUNICATIONS OF THE ACM. Oshri, I., Kotlarsky, J., & Willcocks, L.
Muito Boa
EP_88 2008 Scopus
Vendors’ perspectives on trust and control in offshore information systems outsourcing. Information & Management. Mao, J., Lee, J., & Deng, C.
Muito Boa
159
EP_89 2008 Scopus Analysis of a collaborative workflow process with distributed actors. Springer. Reijers, H. A., Song, M. & Jeong, B.
Boa
EP_90 2010 Scopus Imparting the importance of culture to global software development. acm Inroads. Casey, V. Muito Boa
EP_91 2010 Scopus Global Software Development and Collaboration: Barries and Solutions. acm Inroads. Noll, J., Beecham, S. & Richardson.
Excelente
EP_92 2004 Scopus Utilizing knowledge context in virtual collaborative work. Decision Support Systems. Ahn, H.J., Lee, H.J., Cho, K., & Park, S.J.
Boa
EP_93 2011 Scopus
Exploring computer supported collaborative coordination through social networks. Journal of High Technology Management Research. Feczak, S., & Hossain, L.
Muito Boa
EP_94 2005 SpringerLink A distributed internet-based framework for manufacturing planning. Int J Adv Manuf Technol. Cecil, J., Davidson, S., & Muthaiyan, A.
Média
EP_95 2005 SpringerLink
When Plans do not work Out: How Plans are Used in Software Development Projects. Computer Supported Cooperative Work. Rönkko, K., Dittrich, Y. & Randall, D.
Muito Boa
EP_96 2004 SpringerLink
The Toxicfarm Integrated Cooperation Framework for Virtual Teams. Computer Supported Cooperative Work. Godart, C., Molli, P., Oster, G., Perrin, O., Skaf-Molli, H., Ray, P., & Rabhi, F.
Muito Boa
EP_97 2009 SpringerLink
Bridging, Patching and Keeping the Work Flowing: Defect Resolution in Distributed Software Development. Computer Supported Cooperative Work. Avram, G., Bannon, L., Bowers, J., Sheehan, A., & Sullivan, D.K.
Muito Boa
EP_98 2012 SpringerLink
Awareness Support in Distributed Software Development: A Systematic Review and Mapping of the Literature. Computer Supported Cooperative Work. Steinmacher, I., Chaves, A.P., & Gerosa, M.A.
Muito Boa
EP_99 2007 SpringerLink
Comparing distributed and face-to-face meetings for software architecture evaluation: A controlled experiment. Empir Software Eng. Babar, M. A., Kitchenham, B., & Jeffery, R.
Excelente
EP_100 1997 SpringerLink
Negotiating Boundaries configuration Management in software Development Teams. The Journal of Collaborative Computing. Tellioglu, H., & Wagner, I.
Muito Boa
EP_101 1999 SpringerLink Industrial Requirements for Distributed SCM Tool. Software Quality Journal. Cocchio, L., & Puttero, D.
Muito Boa
EP_102 2010 SpringerLink
How to get mature global virtual teams: a framework to improve team process management in distributed software teams. Software Qual J. Guzmán, J.G., Ramos, J.S., Seco, A.A., & Esteban, A.S.
Excelente
EP_103 2009 SpringerLink
Empirical evidence in global software engineering: a systematic review.Empir Software Eng. Šmite, D., Wohlin, C., Gorschek, T., & Feldt, R.
Excelente
EP_104 2011 IEEExplore Global Virtual Teams: How to manage them. IEEE. Johnston, K., & Rosin, K. Boa
160
EP_105 2009 IEEExplore
Delegation in Global Software Teams: Leading or Managing?. Fourth IEEE International Conference on Global Software Engineering. Zhang, S., Tremaine, M., Milewski, A.E., & Köbler, F.
Boa
EP_106 2011 IEEExplore
A Decision Support System for Global Software Development. Sixth IEEE International Conference on Global Software Engineering Workshops. Beecham, S., Noll, J., & Richardson, I.
Muito Boa
EP_107 2010 IEEExplore A New Perspective on GDSD Risk Management. International Conference on Global Software Engineering. Mudumba, V., & Lee, O.
Muito Boa
EP_108 2011 IEEExplore
A Risk-driven Model for work Allocation in Global Software Development Projects. Sixth IEEE International Conference on Global Software Engineering. Lamersdorf, A., Münch, J., & Torre, A.F.V.
Muito Boa
EP_109 2010 IEEExplore
A Rule-based Model for Customized Risk Identification in Distributed Software Development Projects. International Conference on Global Software Engineering. Lamersdorf, A., & Münch, J.
Muito Boa
EP_110 2010 IEEExplore A training Tool for Global Software Development. IEEE. Monasor, M.J., Vizcaíno, A., Piattini, M., & Vizcaíno, A.
Muito Boa
EP_111 2011 IEEExplore
Adapting Business and Technical Processes for Collaborative Software Development. 17th International Conference on Concurrent Enterprising. Jastroch, N., Kirova, V., Ku, C.S., Marlowe, T.J., & Mohtashami, M.
Muito Boa
EP_112 2010 IEEExplore
Agile Practices in Global Software Engineering; A Systematic Map. International Conference on Global Software Engineering. Jalali, S., & Wohlin, C.
Excelente
EP_113 2008 IEEExplore
Applying Agile Principles for Distributed Software Development. International Conference on Advanced Computer Control. Phalnikar, R., Deshpande, V.S. & Joshi, S.D.
Excelente
EP_114 2010 IEEExplore
Beyond 'Temponomics'- The Many Dimensions of Time in Globally Distributed Project Teams. International Conference on Global Software Engineering. Clear, T., & MacDonell, S.G.
Muito Boa
EP_115 2010 IEEExplore
Causal Analysis of Factors Governing Collaboration in Global Software Development Teams. International Conference on Global Software Engineering. Mohapatra, P., Björndal, P., & Smiley, K.
Boa
EP_116 2010 IEEExplore
Challenges and Solutions in Distributed Software Development Project Management a Systematic Literature Review. International Conference on Global Software Engineering. Silva, F.Q.B., Costa, C., França, A.C.C., & Prikladinicki, R.
Excelente
EP_117 2009 IEEExplore
Collaboration Strategies for Distributed Teams A case Study of CAD Systems Integration. Fourth International Conference on Systems. Madsen, K.E.
Muito Boa
161
EP_118 2010 IEEExplore
Crafting a Global Teaming Model for Architectural Knowledge. International Conference on Global Software Engineering. Beecham, S., Noll, J., Richardson, I., & Ali, N.
Muito Boa
EP_119 2010 IEEExplore
Culture in Global Software development - a weakness or Strength?. International Conference on Global Software Engineering. Deshpande, S., Richardson, I., Casey, V., & Beecham, S.
Muito Boa
EP_120 2009 IEEExplore
Descriptive Analysis of Fear and Distrust in Early Phases of GSD Projects. Fourth IEEE International Conference on Global Software Engineering. Piri, A., Niinimäki, T., & Lassenius, C.
Muito Boa
EP_121 2010 IEEExplore Distributed Development - A literature Analysis on Challenges and Solutions. IEEE. Khoshroo, B.M., & Rashidi, H.
Muito Boa
EP_122 2010 IEEExplore
Managing Cognitive and Cultural Diversity in Global IT Teams. International Conference on Global Software Engineering. Jablokow, K., & Myers, M.
Muito Boa
EP_123 2009 IEEExplore
Linguistic Challenges in Global Software Development; Lessons Learned in an International SW Develipment Division. Fourth IEEE International Conference on Global Software Engineering. Lutz. B.
Muito Boa
EP_124 2010 IEEExplore Limitations and Measures in Outsourcing Projects to Geographically Distributed Offshore Teams. IEEE. Akbar, R., & Hassan, M.F.
Muito Boa
EP_125 2009 IEEExplore Leveraging or Exploiting Cultural Difference?. Fourth IEEE International Conference on Global Software Engineering. Casey, V.
Muito Boa
EP_126 2010 IEEExplore
Knowledge Transfer in Global Software Development - Leveraging Acceptance Test Case Specifications. Community ACM. Salger, F., & Engels, G.
Média
EP_127 2009 IEEExplore
Knowledge Management in Distributed Software Development Teams Does Culture Matter?. Fourth IEEE International Conference on Global Software Engineering. Boden, A., Avram, G., Bannon, L., & Wulf, V.
Muito Boa
EP_128 2011 IEEExplore
Knowledge Flow as Facilitator for Getting into Collaboration in Distributed Software Development. Proceedings of the 44th Hawaii International Conference on System Sciences. Palacio, R.R., Morán, A.L., Vizcaíno, A., González, V.M.
Excelente
EP_129 2011 IEEExplore Key Barreirs of Globally Distributed Software Products Development. IEEE. Helén, M., & Nahar, N.
Muito Boa
EP_130 2011 IEEExplore
Instant Messenger in Offshore Outsourced Software Development Projects-Experiences from a Case Study. Proceedings of the 44th Hawaii International Conference on System Sciences. Wende, E., & Philip, T.
Muito Boa
EP_131 2010 IEEExplore
Risk Management for Web and Distributed Software Development Projects. The Fifth International Conference on Internet Monitoring and Protection. Keshlaf, A.A., & Riddle, S.
Muito Boa
162
EP_132 2009 IEEExplore
Factors Affecting Audio and Text-based Communication Media Choice in Global Software Development Projects. Fourth IEEE International Conference on Global Software Engineering. Niinimäki, T., Piri, A., & Lassenius, C.
Muito Boa
EP_133 2009 IEEExplore
Whitch Groupware Tool Is the Most Suitable For This Group?. Fourth IEEE International Conference on Global Software Engineering. Aranda, G.N., Vizcaíno, A., Piattini, M.
Muito Boa
EP_134 2009 IEEExplore
Risks and Safeguards for the Requirements Engineering Process in Global Software Development. Fourth IEEE International Conference on Global Software Engineering. López, A., Nicolás, J., & Toval, A.
Muito Boa
EP_135 2011 IEEExplore
Impact of Changing Communication Media on Conflict Resolution in Distributed Software Development Projects. 5th Malaysian Conference in Software Engineering. Khan, H.H., Malik, N.,Usman, M., & Ikram, N.
Muito Boa
EP_136 2009 IEEExplore Workgroup Structures in Offshore Software Development Projects: A Vendor Case Study. IEEE. Mathrani, A., Parsons, D., & Stockdale, R.
Boa
EP_137 2009 IEEExplore
Offshorin Test Automation: Observations and Lessons Learned. Fourth IEEE International Conference on Global Software Engineering. Tervonen, I., & Mustonen, T.
Muito Boa
EP_138 2009 IEEExplore
Using FLOW to Improve Communication of Requirements in Globally Distributed Software Projects. IEEE. Stapel, K., Knauss, E., & Schneider, K.
Muito Boa
EP_139 2009 IEEExplore
DRiMaP - A Model of Distributed Risk Management Process. Fifth International Joint Conference on INC, IMS and IDC. Kajko-Mattsson, M., Sjökvist, K., Södesrtröm, J., & Krodgahl, D.
Boa
EP_140 2009 IEEExplore
Experiences in Global Software Development - A Framework-Based Analysis of Distributed Product Development Projects. Fourth IEEE International Conference on Global Software Engineering. Michael T., L., & J. Pär J., Å.
Muito Boa
EP_141 2009 IEEExplore
Quality in Global software Development Projects: A Closer Look at the Role of Distribution. Fourth IEEE International Conference on Global Software Engineering. Cataldo, M., & Nambiar, S.
Muito Boa
EP_142 2011 IEEExplore
FLOW Mapping: Planning and Managing Communication in Distributed Teams. Sixth IEEE International Conference on Global Software Engineering. Stapel, K., Knauss, E., Schneider, K., & Zazworka, N.
Muito Boa
EP_143 2009 IEEExplore
Risk Identification and Mitigation Processes for Using Scrum in Global Software Development: A Conceptual Framework. 16th Asia-Pacific Software Engineering Conference. Hossain, E., Babar, M.A.,Paik, H., & Verner, J.
Excelente
EP_144 2009 IEEExplore
Vietnam as an Emerging Destination for Offshore Outsourcing of Software Development for finnish Companies: A Conceptual Perspective. PICMET 2009 Proceedings. Kuivanen, L., & Nahar, N.
Muito Boa
163
EP_145 2009 IEEExplore
GLOBAL TEAMS: FUTURISTIC MODELS OF COLLABORATIVE WORK FOR TODAY'S SOFTWARE DEVELOPMENT INDUSTRY. Proceedings of the 42nd Hawaii International Conference on System Sciences. Dafoulas, G.A., Swigger, K., Brazile, R., Alpaslan, F.N., Cabrera, V.L., & Serce, F.C.
Muito Boa
EP_146 2010 IEEExplore
Supporting collaboration in the geographically distributed work with communication tools in the remote district SME's. International Conference on Global Software Engineering. Liukkunen, K., Lindberg, K., Hyysalo, J., & Markkula, J.
Excelente
EP_147 2010 IEEExplore
Proposing a Federated Approach to Global Software Development. Fourth International Conference on Digital Society. Tufekci, O., Cetin, S., & Arifoglu, A.
Boa
EP_148 2011 IEEExplore
Risk Identification and Risk Mitigation Instruments for Global Software Development: Systematic Review and Survey Results. Sixth IEEE International Conference on Global Software Engineering Workshops. Nurdiani, I., Jabangwe, R., Smite, D., & Damian, D.
Excelente
EP_149 2011 IEEExplore
Governance Patterns in Global Software Engineering: Best Practices and Lessos Learned. Sixth IEEE International Conference on Global Software Engineering. Bavani, R.
Boa
EP_150 2009 IEEExplore
Exploring Propinquity in Global Software Engineering. Fourth IEEE International Conference on Global Software Engineering. Prikladnicki, R.
Boa
EP_151 2010 IEEExplore
Preapring Students and Engineers for Global Software Development: A Systematic Review. International Conference on Global Software Engineering. Monasor, M.J., Vizcaíno, A., Piarrini, M., & Caballero, I.
Muito Boa
EP_152 2011 IEEExplore
Using the Cloud to Facilitate Global Software Development Challenges. Sixth IEEE International Conference on Global Software Engineering Workshops. Hashmi, S.I., Clerc, V., Razavian, M., Manteli, C., Tamburri, D.A., Lago, P., & Richardson, I.
Muito Boa
EP_153 2011 IEEExplore
Developing and Validating a Socio-Technical Model for geographically Distributed Collaboration in Global Virtual Teams. Proceedings of the 44th Hawaii International Conference on System Sciences. Cogburn, D.L., Santuzzi, A., & Vasquez, F. K. E.
Boa
EP_154 2011 IEEExplore
Investigation Integration Challenges and Solutions in Global Software Development. Frontiers of Information Technology. Zafar, A., Ali, S., Shahzad, R.K.
Muito Boa
EP_155 2010 IEEExplore A Process for Managing Risks in Distributed Teams. Published by the IEEE Computer Society. Persson, J.S., & Mathiassen, L.
Muito Boa
EP_156 2011 IEEExplore
Exploring the Role of Instant Messaging in a Global Software Development Project. Sixth IEEE International Conference on Global Software Engineering. Dittrich, Y., & Giuffrida, R.
Excelente
164
EP_157 2010 IEEExplore
Analytical modeling of Software Development Teams in Globally Distributed Projects. International Conference on Global Software Engineering. Czekster, R.M., Fernandes, P., Sales, A., & Webber, T.
Muito Boa
EP_158 2009 IEEExplore
Providing Suppot for Starting Collaboration in Distributed Software Development: A multi-Agent Approach. World Congress on Computer Science and Information Engineering. Palacio, R.R., Morán, A.L., González, V.M., & Vizcaíno, A.
Muito Boa
EP_159 2011 IEEExplore
GloSE-Lab: Teaching Global Software Engineering. Sixth IEEE International Conference on Global Software Engineering. Deiters, C., Herrmann, C., Hildebrandt, R., Knauss, E., Kuhrmann, M., Rausch, A., Rumpe, B., & Schneider, K.
Muito Boa
EP_160 2011 IEEExplore Coaching Global software Development Projects. Sixth IEEE International Conference on Global Software Engineering. Paasivaara, M.
Boa
EP_161 2010 IEEExplore
Risk and Compliance Management Framework for Outsourced Global Software Development. International Conference on Global Software Engineering. Magnusson, C., Chou, S.
Boa
EP_162 2010 IEEExplore
An Iterative Approach for Global Requirements Elicitation: A Case Study Analysis. International Conference on Electronics and Information Engineering (ICEIE 2010). Sabahat, N., Iqbal, F., Azam, F., & Javed, M.Y.
Muito Boa
EP_163 2011 IEEExplore
Requirements for an infrastructure to support Activity-Based Computing in Global Software development. Sixth IEEE International Conference on Global Software Engineering Workshops. Tell, P., & Babar, M.A.
Muito Boa
EP_164 2010 IEEExplore
Know Yourself and Beyond: A Student's Global Software Development Project Experience with Agile Methodology. The 5th International Conference on Computer Science & Education. Su, S.H., & Scharff, C.
Muito Boa
EP_165 2011 IEEExplore
Software Product Quality in Global Software Development: Finding Groups with Aligned Goals. 37th EUROMICRO Conference on Software Engineering and Advanced Applications. Chatzipetrou, P., Angelis, L., Barney, S., & Wohlin, C.
Boa
EP_166 2011 IEEExplore
Antecedents of ISD Offshoring Outcomes: Exploring Differences Between India and China. Proceedings of the 44th Hawaii International Conference on System Sciences. Spohrer, K., Heinzl, A., & Li, Y.
Boa
EP_167 2010 IEEExplore
Tools to Support Global Software Development Processes: A Survey. International Conference on Global Software Engineering. Portillo-Rodrígues, J., Ebert, C., & Piattini, M.
Excelente
EP_168 2011 IEEExplore Guiding Global Software Development Projects using Scrum and Agile with Quality Assurance. CSEE&T 2011. Scharff, C.
Excelente
165
EP_169 2010 IEEExplore
Transitioning to Distributed Development in Students' Global software Development Projects: The role of Agile Methodologies and End-to-End Tooling. Fifth International Conference on Software Engineering Advances. Scharff, C., Gotel, O., & Kulkarni, V.
Muito Boa
EP_170 2009 IEEExplore
Optimal Data Quality in Project Management for Global Software developments. Fourth International Conference on Cooperation and Promotion of Information Resources in Science and Technology. Caballero, I., Vizcaíno, A.,& Piattini, M.
Muito Boa
EP_171 2010 IEEExplore
Estimating the Effort Overhead in Global Software Development. International Conference on Global Software Engineering. Lamersdorf, A., Münch, J., Torre, A.F.V., Sánchez, C.R., & Rombach, D.
Boa
EP_172 2011 IEEExplore
Scrum-based Methodology for Distributed Software Development. Sixth IEEE International Conference on Global Software Engineering. Nuevo, E.D.N., Piattini, M., & Pino, F.J.
Muito Boa
EP_173 2010 IEEExplore Assessments in Global Software Development: A Tailorable Framework for Industrial Projects. ICSE. Salger, F., Engels, G., & Hofmann, A.
Boa
EP_174 2011 IEEExplore
Coordination and Performance in Global Software Service Delivery: The Vendor's Perspective. IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 58. Gopal, A., Espinosa, A., Gosain, S., & Darcy, D.P.
Muito Boa
EP_175 2009 El Compendex
The Moderating Effects of Virtuality on the Antecedents and Outcome of NPD Team Trust. J PROD INNOV MANAG. Bierly III, P.E., Stark, E.M., & Kessler, E.H.
Muito Boa
EP_176 2011 El Compendex
A Multi-criteria Model for Planning and Fine-tuning Distributed Scrum Projetcs. Sixth IEEE International Conference on Global Software Engineering. Almeida, L.H., Albuquerque, A.B., & Pinheiro, P.R.
Muito Boa
EP_177 2012 El Compendex
Managing Global R&D Projects - Practical experience in building Project Management competency. IEEE Seventh International Conference on Global Software Engineering. Singh, R., & Hofmann, K.
Boa
EP_178 2010 El Compendex
Propinquity in global software engineering: examining perceived distance in globally distributed project teams. JOURNAL OF SOFTWARE: EVOLUTION AND PROCESS. Prikladnicki, R.
Muito Boa
EP_179 2012 El Compendex
Knowledge transfer challenges and mitigation strategies in global software development- A systematic literature review and industrial validation. International Journal of Information Management. Nidhra, S., Yanamadala, M., Afzal, W., & Torkar, R.
Excelente
EP_180 2012 El Compendex
A Process Framework for Global Software Engineering Teams. Information and Software Technology. Richardson, I., Casey, V., McCaffery, F., Burton, J., & Beecham, S.
Muito Boa
166
EP_181 2010 El Compendex
Integrating a university team in the ALMA software development process: A successful model for distributed collaborations. Software and Cyberinfrastructure for Astronomy. Mora, M., Ibsen, J., Chiozzi, G., Troncoso, N., Tobar, R., Araya, M., Avarias, J., & Hoffstad, A.
Muito Boa
EP_182 2012 El Compendex
Managing Distributed Software Development in the Virtual Astronomical Observatory. Modeling, Systems Engineering, and Project Management for Astronomy. Evans, J.D., Plante, R.L., Bonaventura, N., Busko, I., Cresitello-Dittmar, M., D'Abrusco, R., Doe, S., Ebert, R., Laurino, O., Pevunova, O., Refsdal, B., & Thomas, B.
Muito Boa
EP_183 2011 El Compendex
Software Configuration Management Issues with Industrial Opensourcing. Sixth IEEE International Conference on Global Software Engineering Workshops. Bendix, L., Kojo, T., & Magnusson, J.
Boa
EP_184 2010 El Compendex
Empirical investigation of success factors for offshore software development outsourcing vendors. IET Software. Khan, S.U., Niazi, M., & Ahmad, R.
Muito Boa
EP_185 2012 El Compendex
Configuration Management Stories from the Distributed Software Development Trenches. IEEE Seventh International Conference on Global Software Engineering. Bendix, L., Magnusson, J., & Pendleton, C.
Muito Boa
EP_186 2010 El Compendex
Distributed Software Development Projects: Work Breakdown Approaches to Overcome Key Coordination Challenges. ACM. Mohan, S., & Fernandez, J.
Muito Boa
EP_187 2009 El Compendex
Experiences with Training a Remotely Located Performance Test Team in a Quase-Agile Global Environment. Fourth IEEE International Conference on Global Software Engineering. Bondi, A.B., & Ros, J.P.
Muito Boa
EP_188 2009 El Compendex
Risk Identification and Mitigation Processes for Using Scrum in Global Software Development: A Conceptual Framework. 16th Asia-Pacific Software Engineering Conference. Hossain, E., Babar, M.A., Paik, H., & Verner, J.
Excelente
EP_189 2010 El Compendex
Dialog Construction in a Collaborative Project Management Environment. 14th International Conference on Computer Supported Cooperative Work in Design. Ramos, M.P., Tacla, C.A., Sato, G.Y., Paraiso, E.C., & Barthès, J.A.
Boa
EP_190 2012 El Compendex Overcoming the Challenges in Cost Estimation for Distributed Software Projects. IEEE. Ramasubbu, N., & Balan, R.K.
Muito Boa
EP_191 2012 El Compendex Framework supporting team and project activities in Global Software Development (GSD). IEEE. Tariq, A., & Khan, A.A.
Muito Boa
EP_192 2012 El Compendex Agile distributed software development: enacting control through media and context. Info Systems J. Persson, J.S., Mathiassen, L., & Aaen, I.
Muito Boa
EP_193 2011 El Compendex
An evidence-based model of distributed software development project management: results from a systematic mapping study. JOURNAL OF SOFTWARE: EVOLUTION. Da Silva, F.Q.B., Prikladnicki, R., & França, A.C.C., Monteiro,
Excelente
167
C.V.F., Costa, C., & Rocha, R.
EP_194 2006 ICGSE
Global Software Development Challenges: A Case Study on Temporal, Geographical and Socio-Cultural Distance. IEEE International Conference on Global Software Engineering. Holmstrom, H., Conchúir, E.Ó., Ågerfalk, P.J., & Fitzgerald, B.
Boa
EP_195 2006 ICGSE
A Reference Model for Global Software Development: Findings from a Case Study. IEEE International Conference on Global Software Engineering. Prikladnicki, R., Audy, J.L.N., & Evaristo, R.
Muito Boa
EP_196 2006 ICGSE
Project Management within Virtual Software Teams. IEEE International Conference on Global Software Engineering. Casey, V., & Richardson, I.
Muito Boa
EP_197 2006 ICGSE
IT Application Assessment Model for Global Software Development. IEEE International Conference on Global Software Engineering. Kuni, R., & Bhushan, N.
Boa
EP_198 2006 ICGSE
Could Global Software Development Benefit from Agile Methods?. IEEE International Conference on Global Software Engineering. Paasivaara, M., & Lassenius, C.
Muito Boa
EP_199 2006 ICGSE
Sysiphus: Enabling informal collaboration in global software development. IEEE International Conference on Global Software Engineering. Bruegge, B., Dutoit, A.H., & Wolf, T.
Boa
EP_200 2006 ICGSE
Exploring the Assumed Benefits of Global Software Development. IEEE International Conference on Global Software Engineering. Conchúir, E.Ó., Holmström, H., Ågerfalk, P.J., & Fitzgerald, B.
Excelente
EP_201 2006 ICGSE
Tool Support for Distributed Software Engineering. IEEE International Conference on Global Software Engineering. Spanjers, H., Huurne, M.T., Graaf, B., Lormans, M., Bendas, D., & Solingen, R.V.
Muito Boa
EP_202 2006 ICGSE
Supporting Distributed Software Development with fine-grained Artefact Management. IEEE International Conference on Global Software Engineering. Bruegge, B., De Lucia, A., Fasano, F., & Tortora, G.
Muito Boa
EP_203 2006 ICGSE
Technology Selection to Improve Global Collaboration. IEEE International Conference on Global Software Engineering. Aranda, G.N., & Vizcaíno, A.
Muito Boa
EP_204 2007 ICGSE
Successful Global Development of a Large-scale Embedded Telecommunications Product. International Conference on Global Software Engineering. Leszak, M., & Meier, M.
Muito Boa
EP_205 2007 ICGSE
The Evolution of the Internal Offshore Software Development Model at Dell Inc. International Conference on Global Software Engineering. Szymanski, C.H., & Prikladnicki, R.
Muito Boa
168
EP_206 2007 ICGSE
Of Deadlocks and Peopleware Collaborative Work Practices in Global Software Development. International Conference on Global Software Engineering. Avram, G.
Muito Boa
EP_207 2007 ICGSE
Project Outcome Predictions: Risk Barometer Based on Historical Data. International Conference on Global Software Engineering. Šmite, D.
Muito Boa
EP_208 2007 ICGSE Be successful, take a hostage or "outsourcing the outsourcing Manager". International Conference on Global Software Engineering. Pichler, H.
Boa
EP_209 2007 ICGSE
TAPER: A generic framework for establishing an offshore development center. International Conference on Global Software Engineering. Höfner, G., & Mani, V.S.
Muito Boa
EP_210 2007 ICGSE Optimizing Supplier Management in Global Software Engineering. International Conference on Global Software Engineering. Ebert, C.
Muito Boa
EP_211 2007 ICGSE
Global Software Development: Are Architectural Rules the Answer?. International Conference on Global Software Engineering. Clerc, V., Lago, P., & Vliet, H.V.
Muito Boa
EP_212 2007 ICGSE
Distributed Software Development: Practices and challenges in different business strategies of offshoring and onshoring. International Conference on Global Software Engineering. Prikladnicki, R., Audy, J.L.N., Damian, D., & De Oliveira, T.C.
Muito Boa
EP_213 2008 ICGSE
Experiences of Instant Messaging in Global Software Development Projects: A Multiple Case Study. IEEE International Conference on Global Software Engineering.Niinimäki, T., & Lassenius, C.
Excelente
EP_214 2008 ICGSE
Experiences with Agile Practices in the Global Studio Projetc. IEEE International Conference on Global Software Engineering. Urdangarin, R., Avritzer, A., & Paulish, D.
Muito Boa
EP_215 2008 ICGSE
Managing Risks in Global Software Engineering: Principles and Practices. IEEE International Conference on Global Software Engineering. Ebert, C., Murthy, B.K., & Jha, N.N.
Muito Boa
EP_216 2008 ICGSE
Adopting Agile in Distributed Development. IEEE International Conference on Global Software Engineering. Sureshchandra, K., & Shrinivasavadhani, J.
Muito Boa
EP_217 2008 ICGSE
Challenges of Globally Distributed Software Development - Analysis of Problems Related to Social Processes and Group Relations. IEEE International Conference on Global Software Engineering. Piri, A.
Muito Boa
EP_218 2009 ICGSE
How Tecnological Support Can Enable Advantages of Agile Software Development in a GSE Setting. Fourth IEEE International Conference on Global Software Engineering. Dullemond, K., Gameren, B.V., & Solingen, R.V.
Excelente
EP_219 2009 ICGSE
Risk and Safeguards for the Requirements Engineering Process in Global Software Development. Fourth IEEE International Conference on Global Software Engineering.
Muito Boa
169
López, A., Nicolás, J., & Toval, A.
EP_220 2010 ICGSE
A Taxonomy And Visual Notation for Modeling Globally Distributed Requirements Engineering projects. International Conference on Global Software Engineering. Laurent, P., Mäder, P., Cleland-Huang, J., & Steele, A.
Excelente
EP_221 2011 ICGSE
Distributed Collaborative Model Editing Framework for Domain Specific Modeling Tools. Sixth IEEE International Conference on Global Software Engineering. Koshima, A., Englebert, V., & Thiran, P.
Muito Boa
EP_222 2011 ICGSE
How Globally Distributed Software Teams Can Improve their Collaboration Effectiveness?. Sixth IEEE International Conference on Global Software Engineering. Gupta, M., & Fernandez, J.
Boa
EP_223 2012 ICGSE
Sysstematic Literature Reviews in Distributed Software Development: A Tertiary Study. IEEE Seventh International Conference on Global Software Engineering. Marques, A.B., Rodrigues, R., & Conte, T.
Muito Boa
EP_224 2012 ICGSE
From Offshore Outsourcing to Offshore Insourcing:Three Stories. IEEE Seventh International Conference on Global Software Engineering. Moe, N.B., Šmite, D., & Hanssen, G.K.
Boa
170
Apêndice B – Estudos excluídos
t Ano Fonte Referência Critérios utilizado para excluir o estudo
1 2009 ACM A Tractable Time-cost Tradeoff Algorithm for Project Activity Management. ACM. Hsu, Kun-Jung, & Shi, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
2 2011 ACM
A Grounded Theory Research Investigation into the Importance of Social Relationships and Networks within Corporate Information Systems Projects. The ACM Community. Leonard, AC.
e) Estudos que não respondam nenhuma das questões de pesquisa;
3 2010 SciencDirect
The use of a hybrid fuzzy-Delphi-AHP approach to develop global business intelligence for information service firms. Expert Systems with Applications. Chen, M., & Wang, S.
e) Estudos que não respondam nenhuma das questões de pesquisa;
4 2010 SciencDirect Innovation outsourcing: Risks and quality issues. Computer Standards & Interfaces. Chou, D., & Chou, A.
e) Estudos que não respondam nenhuma das questões de pesquisa;
5 2009 SciencDirect
Advanced multi-phase trust evaluation model for collaboration between coworkers in dynamic virtual project teams. Expert Systems with Applications. Chen, T., & Chen, Y.
e) Estudos que não respondam nenhuma das questões de pesquisa;
6 2008 SciencDirect Information systems outsourcing life cycle and risks analysis. Computer Standards & Interfaces. Chou, D., & Chou, A.
e) Estudos que não respondam nenhuma das questões de pesquisa;
7 2008 SciencDirect
Developing a geoscience knowledge framework for a national geological survey organisation. Computers&Geosciences. Howard, A., & Hatton, B., & Reitsma, F., & Lawrie, K.
e) Estudos que não respondam nenhuma das questões de pesquisa;
8 2011 SciencDirect
Effects of initial and ongoing trust in IT outsourcing: A bilateral perspective. Information & Management. Lee, J., & Choy, B.
e) Estudos que não respondam nenhuma das questões de pesquisa;
9 2010 SciencDirect
The strategic choice to continue outsourcing, switch vendors, or backsource: Do switching cost matter? Information & Management. Whitten, D., & Chakrabarty, S. & Wakefield, R.
e) Estudos que não respondam nenhuma das questões de pesquisa;
10 2009 SciencDirect
Artifact a wareness through screen sharing for distributed groups. International Journal of human-computer studies. Tee, K., & Greenberg, S., & Gutwin, C.
e) Estudos que não respondam nenhuma das questões de pesquisa;
11 2005 Scopus
Trust in software outsourcing relationships: An empirical investigation of Indian software companies. Information and software technology. Oza, N., & Hall, T. & Rainer, A., & Greg, S.
e) Estudos que não respondam nenhuma das questões de pesquisa;
171
12 2007 Scopus Counting the Cost of Virtual Teams. Communications of the ACM. Pillis, E., & Furumo, K.
e) Estudos que não respondam nenhuma das questões de pesquisa;
13 2008 Scopus
Managing Software Development in Globally Distributed Teams. Communications of the ACM. Cusumano, M.
e) Estudos que não respondam nenhuma das questões de pesquisa;
14 2007 Scopus Selecting sustainable teams for PPP projects. Building and environment. Kumaraswamy, M., & Anvuur, A.
e) Estudos que não respondam nenhuma das questões de pesquisa;
15 2007 Scopus
Explaining Variations in Client Extra Costs between Software Projects offshored to india. Dibbern, J., & Winkler, J., & Heinzl, A.
e) Estudos que não respondam nenhuma das questões de pesquisa;
16 2007 Scopus
Project success and project team management: Evidence from capital projects in the process industries. Journal of Operations Management. Scott-Young, C., & Samson, D.
e) Estudos que não respondam nenhuma das questões de pesquisa;
17 2009 Scopus
HEADING INTO NEW VIRTUAL ENVIRONMENTS: WHAT SKILLS DO DESIGN TEAM MEMBERS NEED? Journal of Information Technology in Construction. Sher, W., & Sherratt, S., & Williams, A., & Gameson, R.
e) Estudos que não respondam nenhuma das questões de pesquisa;
18 2009 Scopus
Project Management: The Task of Holistic Systems Thinking. Human Factors and Ergonomics in Manufacturing. Aramo-Immonen, H., & Vanharanta, H.
e) Estudos que não respondam nenhuma das questões de pesquisa;
19 2009 Scopus
Design and Analysis of Contracts for Software Outsourcing. Information Systems Research. Dey, D., & Fan, M., & Zhang, C.
e) Estudos que não respondam nenhuma das questões de pesquisa;
20 2009 Scopus
Value creating construction virtual teams: A case study in the construction sector. Automation in Construction. Vorakulpipat, C., & Rezgui, Y., & Hopfe, C.
e) Estudos que não respondam nenhuma das questões de pesquisa;
21 2009 Scopus
Action readiness and mindset for IT offshoring. Journal of Enterprise Information Management. Aydin, M., & Groot, J., & Hillegersberg, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
22 2010 Scopus
Inter-Organizational Knowledge Transfer Through Malaysia E-government IT Outsourcing: A Theoretical Review. World Academy of Science, Engineering and Technology. Hamid, N., & Salim, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
23 2010 Scopus
Impact of cultural differences on knowledge management in global projects. VINE: The journal of information and knowledge management systems. Anantatmula, V.
e) Estudos que não respondam nenhuma das questões de pesquisa;
172
24 2010 Scopus
Analysis of the Peculiarity of the Japanese Software Development Style in offshore Software Development. IEEJ TRANSACTIONS ON ELECTRICAL AND ELECTRONIC ENGINEERING. Yoshii, A., & Higa, K.
e) Estudos que não respondam nenhuma das questões de pesquisa;
25 2011 Scopus
Partnering effects on user–developer conflict and role ambiguity in information system projects. Information and Software Technology. Liu, J., & Chiang, J., & Yang, M., & Klein, G.
e) Estudos que não respondam nenhuma das questões de pesquisa;
26 2011 Scopus
A decision method for supplier selection in multi-service outsourcing. Int. J.ProductionEconomics. Feng, B., & Fan, Z., & Li, Y.
e) Estudos que não respondam nenhuma das questões de pesquisa;
27 2011 Scopus
An Empirical Investigation of Client Managers’ Responsibilities in Managing Offshore Outsourcing of Software-Testing Projects. IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT. Jain, R., & Poston, R., & Simon, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
28 2011 Scopus
Stakeholder analysis is key to client–supplier relationships of global outsourcing project success. International Journal of Information Management. Berger, H., & Lewis, C.
e) Estudos que não respondam nenhuma das questões de pesquisa;
29 2011 Scopus
Changes and change management in construction and IT projects. Automation in Construction. Bröchner, J., & Badenfelt, U.
e) Estudos que não respondam nenhuma das questões de pesquisa;
30 2007 Scopus
The Impact of Offshore Outsourcing on IT Workers in Developed Countries. Communications of the ACM. Shao, B., & David, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
31 2010 Scopus
AN EMPIRICAL ANALYSIS OF THE IMPACT OF INFORMATION CAPABILITIES DESIGN ON BUSINESS PROCESS OUTSOURCING PERFORMANCE. Mis Quarterly. Mani, D., & Barua, A., & Whinston, A.
e) Estudos que não respondam nenhuma das questões de pesquisa;
32 2000 Scopus Working in Virtual Teams: A Tale of Two Projects and Many Cities. IT Pro. Haywood, M.
e) Estudos que não respondam nenhuma das questões de pesquisa;
33 2004 Scopus Quantitative aspects of outsourcing deals. Science of computer programming. Verhoef, C.
e) Estudos que não respondam nenhuma das questões de pesquisa;
34 2007 Scopus Offshore Outsourcing: The Risk of Keeping Mum. Communications of the ACM. Ramingwong, S., & Sajeev, A.
e) Estudos que não respondam nenhuma das questões de pesquisa;
173
35 2007 Scopus
A statistical framework for analyzing the duration of software projects. Empir Software Eng. Sentas, P., & Angelis, L., & Stamelos, I.
e) Estudos que não respondam nenhuma das questões de pesquisa;
36 2009 Scopus
Volunteers’ involvement in online community based software development. Information & Management. Xu, B., & Jones, D., & Shao, B.
e) Estudos que não respondam nenhuma das questões de pesquisa;
37 2009 Scopus
A COOPERATIVE HYPERMEDIA APPROACH TO FLEXIBLE PROCESS SUPPORT FOR MANAGING DISTRIBUTED PROJECTS. International Journal of Cooperative Information Systems. Wang, W., & Finch, K., & Rubart, J., & Haake, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
38 2010 Scopus
Software engineering education: A study on conducting collaborative senior project development. The Journal of Systems and Software. Chen, C., & Chong, P.
e) Estudos que não respondam nenhuma das questões de pesquisa;
39 2006 Scopus Exploring virtual team-working effectiveness in the construction sector. Interacting with computers. Resgui, Y.
e) Estudos que não respondam nenhuma das questões de pesquisa;
40 2007 Scopus
An empirical investigation of the drivers of software outsourcing decisions in Japanese organizations. Information and software technology. Bush, A., & Tiwana, A., & Tsuji, H.
e) Estudos que não respondam nenhuma das questões de pesquisa;
41 2008 Scopus
The impact of agile pratices on communication in software development. Empir Software Eng. Pikkarainen, M., & Haikara, J., & Salo, O., & Abrahamsson, P., & Still, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
42 2008 Scopus
Social Capital and Knowledge Integration in Digitally Enabled Teams. Information Systems Research. Robert, L., & Dennis, A., & Ahuja, M.
e) Estudos que não respondam nenhuma das questões de pesquisa;
43 2008 Scopus
In union lies strength: Collaborative competence in new product development and its performance effects. Journal of Operations Management. Mishra, A., & Shah, R.
e) Estudos que não respondam nenhuma das questões de pesquisa;
44 2009 Scopus
Cultural impacts on knowledge management and learning in project-based firms. Vine. Ajmal, M., & Kekäle, T., & Takala, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
45 2010 Scopus
The antecedents of process integration in business process outsourcing and its effect on firm performance. Journal of Operations Management. Narayanan, S., & Jayaraman, V., & Luo, Y., & Swaminathan, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
46 2008 SpringerLink
A methodology to evaluate the usability of digital socialization in "virtual"engineering design. Res Eng Design. El-Tayeh, A., & Gil, N., & Freeman, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
174
47 2010 SpringerLink
Infrastructure Time: Long-term Matters in Collaborative Development. Computer Supported Cooperative Work. Karasti, H., & Baker, K., & Millerand, F.
e) Estudos que não respondam nenhuma das questões de pesquisa;
48 2011 SpringerLink
Special Theme: Project Management in E-Science: Challenges and Opportunities. Computer Supported Cooperative Work. Spencer, D., & Zimmerman, A., & Abramson, D.
e) Estudos que não respondam nenhuma das questões de pesquisa;
49 2007 SpringerLink Global and task effects in information-seeking among software engineers. Empir Software Eng. Milewski, A.
e) Estudos que não respondam nenhuma das questões de pesquisa;
50 2007 SpringerLink
A measurement framework for assessing the maturity of requirements engineering process. Software Qual J. Niazi, M., & Cox, K., & Verner, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
51 2011 SpringerLink
Context-dependent awareness support in open collaboration environments. User Model User-Adap Inter. Ardissono, L., & Bosio, G.
e) Estudos que não respondam nenhuma das questões de pesquisa;
52 2005 SpringerLink
Virtual Software Engineering Laboratories in Support of Trade-off Analyses. Software Quality Journal. Münch, J., & Pfahl, D., & Rus, I.
e) Estudos que não respondam nenhuma das questões de pesquisa;
53 2012 SpringerLink
An empirically based terminology and taxonomy for global software engineering. Empir Software Eng. Šmite, D., & Wohlin, C., & Galviņa, Z., & Prikladnicki, R.
e) Estudos que não respondam nenhuma das questões de pesquisa;
54 2013 SpringerLink
Data collection in Global Software Engineering Research: learning from past experience. Empir Software Eng. Prikladnicki, R., & Boden, A., & Avram, G., & Souza, C., & Wulf, V.
e) Estudos que não respondam nenhuma das questões de pesquisa;
55 2011 SpringerLink A module-based thermal design approach for distributed product development. Res Eng Design. Seki, K., & Nishimura, H.
e) Estudos que não respondam nenhuma das questões de pesquisa;
56 2010 IEEExplore
Improving Distance Mentoring: Challenges and How to Deal with them in global Development Project Courses. 23rd IEEE Conference on Software Engineering Education and Training. Taran, G., & Carter, L.
e) Estudos que não respondam nenhuma das questões de pesquisa;
57 2009 IEEExplore
An Architecture for Supporting Small Collocated Teams in Cooperative Software Development. 13th International Conference on Computer Supported Cooperative Work in Design. Campagnolo, B., & Tacla, C., & Paraíso, E., & Sato, G., & Ramos, M.
e) Estudos que não respondam nenhuma das questões de pesquisa;
175
58 2009 IEEExplore
Critical Barriers for Offshore Software Development Outsourcing Vendors; A Systematic Literature Review. 16th Asia-Pacific Software Engineering Conference. Khan, S., & Niazi, M., & Ahmad, R.
e) Estudos que não respondam nenhuma das questões de pesquisa;
59 2011 IEEExplore
Critical Success Factos for Offshoring of Enterprise Resource Planning (ERP) Implementations - US Experience. IEEE-International Conference on Recent Trends in Information Technology 2011. Chauhan, R., & Sherry, A., & Bhat, V.
e) Estudos que não respondam nenhuma das questões de pesquisa;
60 2010 IEEExplore Enhancing Collaboration of Multi-developer Projects With Synchronous Changes. ICSE. Hattori, L.
e) Estudos que não respondam nenhuma das questões de pesquisa;
61 2011 IEEExplore Onshore-offshore Competition: A Stage Model. 44th Hawaii International Conference on System Sciences. Zhang, S.
e) Estudos que não respondam nenhuma das questões de pesquisa;
62 2011 IEEExplore
Outsourced, Offshored Software-Testing Practice: Vendor-Side Experiences. Sixth IEEE International Conference on Global Software Engineering. Shah, H., Sinha, S., Harrold, M.
e) Estudos que não respondam nenhuma das questões de pesquisa;
63 2010 IEEExplore Risk Assessment on Distributed Software Projects. ICSE. Lima, A.
e) Estudos que não respondam nenhuma das questões de pesquisa;
64 2009 IEEExplore
Orchertration of Global Software Engineering Projects - Position Paper. Fourth IEEE International Conference on Global Software Engineering. Bartelt, C., & Broy, M., & Herrmann, C., & Knauss, E., & Kuhrmann, M., & Rausch, A., & Rumpe, B., & Schneider, K.
e) Estudos que não respondam nenhuma das questões de pesquisa;
65 2011 IEEExplore
Offshore Insourcing: A Case Study on Software Quality Alignment. Sixth IEEE International Conference on Global Software Engineering. Barney, S., & Wohlin, C., & Chatzipetrou, P., & Angelis, L.
e) Estudos que não respondam nenhuma das questões de pesquisa;
66 2010 IEEExplore
Research on model of Knowledge transfer in outsourced software projects. International Conference on E-Business and E-Government. Gang, Q., & Bosen, L.
e) Estudos que não respondam nenhuma das questões de pesquisa;
67 2011 IEEExplore
Towards Understanding of Software Engineer Motivation in Globally Distributed Projects. Sixth IEEE International Conference on Global Software Engineering Workshops. Šteinberga, L., & Smite, D.
e) Estudos que não respondam nenhuma das questões de pesquisa;
68 2009 IEEExplore
Quantitative Modeling of Communication Cost for Global Service Delivery. IEEE International Conference on Services Computing. Zhou, N., & Ma, Q., & Ratakonda, K.
e) Estudos que não respondam nenhuma das questões de pesquisa;
176
69 2009 IEEExplore
Teaching Requirements Elicitation within the Context of Global Software Development. Mexican International Conference on Computer Science. Romero, M., & Vizcaíno, A., & Piattini, M.
e) Estudos que não respondam nenhuma das questões de pesquisa;
70 2009 IEEExplore
Global Requirements Engineering: Decision Support for Globally Distributed Projects. Fourth IEEE International Conference on Global Software Engineering. Lescher, C., & Brügge, B.
e) Estudos que não respondam nenhuma das questões de pesquisa;
71 2009 IEEExplore On Educating Globally Distributed Software Development - a Case Study. ISCIS. Mäkiö, J., & Betz, S.
e) Estudos que não respondam nenhuma das questões de pesquisa;
72 2009 IEEExplore
Empirically - Based Decision Support For Task Allocation in Global Software Development. Fourth IEEE International Conference on Global Software Engineering. Lamersdorf, A., & Rombach, D.
e) Estudos que não respondam nenhuma das questões de pesquisa;
73 2009 IEEExplore
Operational and Strategic Learning in Global Software Development/ Implications from two Offshoring Case Studies in Small Enterprises. IEEE Software. Boden, A., & Nett, B., & Wulf, V.
e) Estudos que não respondam nenhuma das questões de pesquisa;
74 2011 IEEExplore
Does Socio-Technical Congruence Have an Effect on Software Build Success? A Study of Coordination in a Software Project. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. Kwan, I., & Schro ̈ter, A., & Damian, D.
e) Estudos que não respondam nenhuma das questões de pesquisa;
75 2010 IEEExplore
Software Product Transfers: Lessons Learned from a Case Study. International Conference on Global Software Engineering. Šmite, D., & Wohlin, C.
e) Estudos que não respondam nenhuma das questões de pesquisa;
76 2010 IEEExplore
Software Configuration Management in Global Software Development: A Systematic Map. Asia Pacific Software Engineering Conference. Fauzi, S., & Bannerman, P., & Staples, M.
e) Estudos que não respondam nenhuma das questões de pesquisa;
77 2009 IEEExplore
Managing Globally Distributed Engineering Teams: A Case Study on Virtual Industrial Engineering. Domschke, M., & Bog, A., & Uflacker, M., & Zeier, A.
e) Estudos que não respondam nenhuma das questões de pesquisa;
78 2010 IEEExplore
New Angles for Global Software Engineering Research? Keynote Summary. International Conference on Global Software Engineering.Richardson, I.
e) Estudos que não respondam nenhuma das questões de pesquisa;
79 2010 IEEExplore
Collaboration Software Development of Scalable DoD Computational Engineering. DoD High Performance Computing Modernization Program Users Group Conference. Atwood, C., & Adamec, S.
e) Estudos que não respondam nenhuma das questões de pesquisa;
177
80 2010 IEEExplore
A People-centric Sensing Approach ti Transforming Cross-Cultural Practices in a Global Virtual Team Setting. WASE International Conference on Information Engineering. Qiu, R.
e) Estudos que não respondam nenhuma das questões de pesquisa;
81 2011 IEEExplore
Collaborative teaching of Globally Distributed Software Development: Community Building Workshop. Faulk, S., & Young, M., & Weiss, D., & Yu, L.
e) Estudos que não respondam nenhuma das questões de pesquisa;
82 2009 IEEExplore
Preparing Computer Engineers for a Global Economy: A Study on Effective Collaboration Practices in Global Student Teams. 39th ASEE/IEEE Frontiers in Education Conference. Doboli, A., & Doboli, S., & Currie, E.
e) Estudos que não respondam nenhuma das questões de pesquisa;
83 2010 IEEExplore
Global Software Engineering: Challenges in Customer value Creation. International Conference on Global Software Engineering. Bavani, R.
e) Estudos que não respondam nenhuma das questões de pesquisa;
84 2011 IEEExplore
Reverse Offshore Outsourcing experinces in Global Software Engineering projects. Sixth IEEE International Conference on Global Software Engineering. Wilson, B., & Ceuppens, K.
e) Estudos que não respondam nenhuma das questões de pesquisa;
85 2011 IEEExplore
Exploring the role of Social Software in Global Software development Projects. Sixth IEEE International Conference on Global Software Engineering Workshops. Giuffrida, R., & Dittrich, Y.
e) Estudos que não respondam nenhuma das questões de pesquisa;
86 2009 IEEExplore
End-to-End Features as Meta-Entities for Enabling Coordination in Geographically distributed Software development. ICSE’09 Workshop. Cataldo, M., & Herbsleb, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
87 2010 IEEExplore
New Apportunities presented by novel Work Breakdown techniques for Distributed Software Development. International Conference on Global Software Engineering. Mohan, S., & Fernandez, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
88 2010 IEEExplore
Effort Estimation in Global Software Development Projects. International Conference on Global Software Engineering. Peixoto, C., & Audy, J., & Prikladnicki, R.
e) Estudos que não respondam nenhuma das questões de pesquisa;
89 2009 IEEExplore
Changing Psychological Contracts and their Effect on Control Modes in IT Offshore Outsourcing Projects - A Case from the Financial Services Industry. Proceedings of the 42nd Hawaii International Conference on System Sciences. Prifling, M., & Gregory, R., & Beck, R.
e) Estudos que não respondam nenhuma das questões de pesquisa;
178
90 2009 IEEExplore
Towards Process-based Collaboration in Global software Engineering. 35th Euromicro Conference on Software Engineering and Advanced Applications. Klein, K., & Rausch, A., & Fischer, E.
e) Estudos que não respondam nenhuma das questões de pesquisa;
91 2010 IEEExplore The Challenges of Teaching Students How to Work in Global Software Teams. Swigger, K., & Brazile, R., & Serce, F.
e) Estudos que não respondam nenhuma das questões de pesquisa;
92 2010 IEEExplore Collaboration Tools for Global Software Engineering. Software Technology. Ebert, C.
e) Estudos que não respondam nenhuma das questões de pesquisa;
93 2011 IEEExplore
Decision Support for Offshore Insourcing Software Development. Sixth IEEE International Conference on Global Software Engineering Workshops. Jabangwe, R., & Šmite, D.
e) Estudos que não respondam nenhuma das questões de pesquisa;
94 2010 IEEExplore Patterns in Effective Distributed Software Development. Voice of Evidence. Shull, F.
c) Estudos que não apresentam como foco principal ou não citam Modelos, Processos, Técnicas, Metodologias e Ferramentas de apoio ao Gerenciamento de Projetos no Desenvolvimento Distribuído de Software;
95 2012 El Compendex
Commissiong Planning through an Operational Precedence Net using the Primavera software. International Conference on Offshore and Marine Technology: Science and Innovation. King, D.
e) Estudos que não respondam nenhuma das questões de pesquisa;
96 2011 El Compendex
Understanding Uncertainty: Assessment and Management of Geotechnical Risk in Tunnel Construction. GeoRisk. Pennington, T., & Richards, D.
e) Estudos que não respondam nenhuma das questões de pesquisa;
97 2009 El Compendex
Specifics of Entry-Level IT Project Managers in Eastern Europe. Ridchenko, O.
e) Estudos que não respondam nenhuma das questões de pesquisa;
98 2012 El Compendex
Systems Engineering Implementation in the Preliminary Design Phase of the Giant Magellan Telescope. Maiten, J., & Johns, M., & Trancho, G., & Sawyer, D., & Mady, P.
e) Estudos que não respondam nenhuma das questões de pesquisa;
99 2009 El Compendex
Supporting Small Teams in Cooperative Software Development with a Multi-Agent Architecture. Simpósio Brasileiro de Sistemas Colaborativos. Freddo, A., & Tacla, C., & Sato, G., & Paraiso, E., & Campagnolo, B., & Ramos, M.
e) Estudos que não respondam nenhuma das questões de pesquisa;
100 2009 El Compendex
Boundary Spanning in Offshored ISD Projetcs: A Project Social Capital Perspective. SIGMIS-CPR. Krishnan, P., & Ranganathan, C.
e) Estudos que não respondam nenhuma das questões de pesquisa;
179
101 2011 El Compendex
Preparing Civil Engineers for International Collaboration in Construction Management. OURNAL OF PROFESSIONAL ISSUES IN ENGINEERING EDUCATION & PRACTICE. Soibelman, L., & Sacks, R., & Akinci, B., & Dikmen, I., & Birgonul, M., & Eybpoosh, M.
e) Estudos que não respondam nenhuma das questões de pesquisa;
102 2009 El Compendex
Reducing NPR 7120.5D to Practice: Preparing for a Life-cycle Review. Taylor, R.
e) Estudos que não respondam nenhuma das questões de pesquisa;
103 2011 El Compendex
Do you dare to ask your HR Manager to practice Kanban? Agile Conference. Wijewardena, T.
c) Estudos que não apresentam como foco principal ou não citam Modelos, Processos, Técnicas, Metodologias e Ferramentas de apoio ao Gerenciamento de Projetos no Desenvolvimento Distribuído de Software;
104 2012 El Compendex
Offshore wind farm cabling: incidents and required learning. Institution of Civil Engineers. Boehme, T., & Robson, D.
e) Estudos que não respondam nenhuma das questões de pesquisa;
105 2011 El Compendex
Teaching a Global Project Course: Experiences and Lessons Learned. CTGDSD. Gloor, P., & Paasivaara, M., & Lassenius, C.
e) Estudos que não respondam nenhuma das questões de pesquisa;
106 2011 El Compendex
Avoiding Scylla and Charybdis in Distributed Software Development Course. CTGDSD. Bosnić, I., & Čavrak, I., & Orlić, M., & Žagar, M., & Crnković, I.
e) Estudos que não respondam nenhuma das questões de pesquisa;
107 2010 El Compendex
Renewing the Software Project Management Life Cycle. Favaro, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
108 2012 El Compendex
Suppoting Virtual Meetings in Distributes Scrum Teams. IEEE LATIN AMERICA TRANSACTIONS. Rodríguez, G., & Soria, A., & Campo, M.
i) Estudos publicados em língua diferente do Inglês.
109 2011 El Compendex
Configuring Global Software Teams: A Multi-Company Analysis of Project Productivity, Quality, and Profits. ICSE. Ramasubbu, N., & Cataldo, M., & Balan, R., & Herbsleb, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
110 2011 El Compendex
Culturally Influenced Risk Exposure: A New Approach to Tackle Risks in Offshore Outsourcing. IEEE. Ramingwong, S., & Ramingwong, L.
e) Estudos que não respondam nenhuma das questões de pesquisa;
111 2006 ICGSE
Road Blocks and Enablers for Global Software Engineering Projects. IEEE International Conference on Global Software Engineering. Ebert, C.
e) Estudos que não respondam nenhuma das questões de pesquisa;
180
112 2006 ICGSE
Cultural Differences in Temporal Perceptions and its Application to Running Efficient Global Software Teams. IEEE International Conference on Global Software Engineering. Egan, R., & Tremaine, M., & Fjermestad, J., & Milewski, A., & O’Sullivan, P.
e) Estudos que não respondam nenhuma das questões de pesquisa;
113 2006 ICGSE
Delegation in Virtual Team: the moderating Effects of Team Maturity and Team Distance. IEEE International Conference on Global Software Engineering. Zhang, S., & Tremaine, M., & Fjermestad, J., & Milewski, A., & O’Sullivan, P.
e) Estudos que não respondam nenhuma das questões de pesquisa;
114 2006 ICGSE
Methods and Tools for Collaboration in GSE Environments. IEEE International Conference on Global Software Engineering. Paulish, D.
e) Estudos que não respondam nenhuma das questões de pesquisa;
115 2006 ICGSE
Exploring the Relationship between Dependencies and Coordination to Support Global Software Development Projects. IEEE International Conference on Global Software Engineering. Fonseca, S., & Souza, C., & Redmiles, D.
e) Estudos que não respondam nenhuma das questões de pesquisa;
116 2006 ICGSE
Global Software Development Offshore Insourcing Organizations Characteristics: Lessons Learned from a Case Study. IEEE International Conference on Global Software Engineering. Pilatti, L., & Audy, J.
c) Estudos que não apresentam como foco principal ou não citam Modelos, Processos, Técnicas, Metodologias e Ferramentas de apoio ao Gerenciamento de Projetos no Desenvolvimento Distribuído de Software;
117 2006 ICGSE
MuNDDoS: A Research Group on Global Software Development. IEEE International Conference on Global Software Engineering. Prikladnicki, R., & Marczak, S., & Audy, J.
e) Estudos que não respondam nenhuma das questões de pesquisa;
118 2006 ICGSE
Improving Productivity of Local Software Development Teams in a Global Software Development Environment. IEEE International Conference on Global Software Engineering. Ribeiro, M., & Czekster, R., & Webber, T.
e) Estudos que não respondam nenhuma das questões de pesquisa;
119 2006 ICGSE
IMART: An Interoperability Model for Artifacts of Distributed Software Development Environments. IEEE International Conference on Global Software Engineering. Wiese, I., & Huzita, E.
e) Estudos que não respondam nenhuma das questões de pesquisa;
181
120 2006 ICGSE
IBM Software Development Leveraging Geographically Distributed Teams - The Interactive Solution Marketplace 2.0 (ISM) Case Study. IEEE International Conference on Global Software Engineering. Vitale, V.
e) Estudos que não respondam nenhuma das questões de pesquisa;
121 2007 ICGSE
Collaboration in Global Software Projects at Siemens: An Experience Report. International Conference on Global Software Engineering. Bass, M., & Herbsleb, J., & Lescher, C.
e) Estudos que não respondam nenhuma das questões de pesquisa;
122 2007 ICGSE
An Adaptive Tool Integration Framework to Enable Coordination in Distributed Software Development. International Conference on Global Software Engineering. Sinha, V., & Sengupta, B., & Ghosal, S.
e) Estudos que não respondam nenhuma das questões de pesquisa;
123 2007 ICGSE
A unified requirements model; integrating features, use cases, requirements, requirements analysis and hazard analysis.International Conference on Global Software Engineering. Berenbach, B., & Wolf, T.
e) Estudos que não respondam nenhuma das questões de pesquisa;
124 2007 ICGSE
What Did You Say? Intercultural Expectations, Misunderstandings, and Communications. International Conference on Global Software Engineering. Zarndt, F.
e) Estudos que não respondam nenhuma das questões de pesquisa;
125 2008 ICGSE
A Comparative Empirical Study of Communication in Distributed and Collocated Development Teams. IEEE International Conference on Global Software Engineering. Al-Ani, B., & Edwards, H.
e) Estudos que não respondam nenhuma das questões de pesquisa;
126 2008 ICGSE
Improving contextual skills in Global Software Engineering: A corporate training experience. IEEE International Conference on Global Software Engineering. Prikladnicki, R., & Pilatti, L.
e) Estudos que não respondam nenhuma das questões de pesquisa;
127 2008 ICGSE
A Readiness Model for Software Development Outsourcing Vendors. IEEE International Conference on Global Software Engineering. Khan, S., & Niazi, M., & Ahmad, R.
e) Estudos que não respondam nenhuma das questões de pesquisa;
128 2009 ICGSE
Global sourcing of software development - a review of tools and services. Fourth IEEE International Conference on Global Software Engineering. Martignoni, R.
e) Estudos que não respondam nenhuma das questões de pesquisa;
182
129 2009 ICGSE
Knowledge Management in the Global Software Engineering Environment. Fourth IEEE International Conference on Global Software Engineering. Richardson, I., & Casey, V., & O’Riordan, M., & Meehan, B., & Mistrík, I.
e) Estudos que não respondam nenhuma das questões de pesquisa;
130 2010 ICGSE
Simulating Global Software Development in a Course Environment. International Conference on Global Software Engineering. Keenan, E., & Steele, A., & Jia, X.
e) Estudos que não respondam nenhuma das questões de pesquisa;
131 2012 ICGSE
A tool Framework for Deriving the Application Architecture for Global Software Development Projects. IEEE Seventh International Conference on Global Software Engineering. Yildiz, B., & Tekinerdogan, B., & Cetin, S.
e) Estudos que não respondam nenhuma das questões de pesquisa;
132 2012 ICGSE
Problems? We All Know We Have Them. Do We Have Solutions Too? IEEE Seventh International Conference on Global Software Engineering. Gomes, V., & Marczak, S.
e) Estudos que não respondam nenhuma das questões de pesquisa;
133 2012 ICGSE
Freelancers: A Global Software Engineering Approach for Small Projects. IEEE Seventh International Conference on Global Software Engineering. Bhadauria, A.
e) Estudos que não respondam nenhuma das questões de pesquisa;
183
Apêndice C – Protocolo do mapeamento
PROTOCOLO
Mapeamento sistemático de gerenciamento de Projetos no Desenvolvimento Distribuído de Software
Juliana Braz da Costa
Agosto de 2013
184
Histórico de Revisões
Data Versão Descrição Autor 21/09/2013 V1.1 Atualização dos critérios de exclusão Juliana Braz da
Costa 28/09/2013 V1.2 Revisão geral Juliana Braz Da
Costa
185
Equipe
Nome Afiliação Papel Adauto Frigueiro Cin - Universidade Federal de
Pernambuco Revisor
Alex Nery Cin - Universidade Federal de Pernambuco
Revisor
Emanoel Barreiros Cin - Universidade Federal de Pernambuco
Revisor
Eudis Oliveira Teixeira
Cin – Universidade Federal de Pernambuco
Revisor
Juliana Braz da Costa
Cin – Universidade Federal de Pernambuco
Autora
Netuh Pires Cin - Universidade Federal de Pernambuco
Revisor
Sérgio Castelo Branco Soares
Cin - Universidade Federal de Pernambuco
Revisor interno (orientador)
186
C1. Introdução
Revisões sistemáticas provêem meios para executar revisões na literatura
abrangentes e não tendenciosas, fazendo com que seus resultados tenham valor
científico conforme mencionado por Travassos (2007). As revisões sistemáticas têm
por objetivo apresentar uma justa avaliação de um tópico de investigação, usando
uma confiável, rigorosa e auditável metodologia (KITCHENHAM, 2007).
Travassos (2007) apresenta algumas das razões para se realizar uma revisão
sistemática: Sumarizar evidências existentes sobre um fenômeno; Identificar lacunas
na pesquisa atual; Fornecer um arcabouço para posicionar novas pesquisas; e,
Apoiar a geração de novas hipóteses.
Uma revisão sistemática começa com a definição do protocolo que especifica
as questões de investigação e os métodos que serão usados para conduzir a
revisão. Segundo Kitchenham (2007), além das razões e objetivos da pesquisa,
devem fazer parte do protocolo:
§ As questões de investigação que a pesquisa pretende responder;
§ As estratégias usadas para as pesquisas dos estudos primários,
incluindo os termos usados, bibliotecas digitais, jornais e conferências;
§ Critérios de exclusão dos estudos primários;
§ Procedimentos de avaliação da qualidade dos estudos selecionados;
§ Estratégia de extração dos dados e síntese dos dados extraídos; e,
§ Estratégia de documentação e apresentação.
Assim, este documento apresenta a revisão de um protocolo realizado por
Costa (2009) no período de 1998 à 2009, de uma revisão sistemática, parte de uma
pesquisa de mestrado cujo objetivo principal foi investigar o que muda nas práticas
de gerenciamento de projetos de software quando o desenvolvimento do software é
distribuído. Esta nova revisão será nos período de 2009 à 2012 nas bases de dados
do protocolo sucessor, e em duas novas fontes no período de 1998 à 2012.
Este estudo busca reunir os novos procedimentos e ferramentas adequados
para a realização do gerenciamento em um cenário de desenvolvimento distribuído,
comparando com os resultados de Costa (2009), e reformulando as evidências, no
187
qual fatores como, distância física e temporal são presentes, tornando a atribuição,
coordenação, sincronização e acompanhamento de atividades uma tarefa ainda
mais complexa.
C2. Questões da Pesquisa
Com o objetivo de investigar “o que muda no gerenciamento de projetos de
software quando o desenvolvimento é distribuído?” e “como apoiar a gerência nesse
cenário de desenvolvimento?” a pesquisa parte para quatro questões de
investigação mais específicas que possam responder essas perguntas, na busca por
uma abordagem que apóie com práticas e ferramentas eficazes o gerenciamento de
projetos distribuídos.
§ (Q1) Quais os principais desafios no gerenciamento de projetos de
desenvolvimento distribuído de software?
§ (Q2) Quais as melhores práticas a serem adotadas no gerenciamento
de projetos de desenvolvimento distribuído de software?
§ (Q3) Que ferramentas existem para apoiar as atividades de
gerenciamento de projetos no desenvolvimento distribuído de
software?
§ (Q4) Que modelos existem para apoiar as atividades de gerenciamento
de projetos no desenvolvimento distribuído de software?
Kitchenham (2007) recomenda considerar as questões de pesquisa a partir da
seguinte estrutura PICOC (Population, Intervention, Context, Outcomes, e
Comparison) que traduzida para o português seria: População, Intervenção,
Contexto, Resultados e Comparação. Para cada pergunta de pesquisa, os
elementos PIO (Population, Interventaion, e Outcome) são apresentados a seguir:
Q1:
§ População (P): Projetos de desenvolvimento distribuído de software.
§ Intervenção (I): Gerenciamento de projetos.
§ Resultado (O): Desafios no gerenciamento de projetos.
Q2:
188
§ População (P): Projetos de desenvolvimento distribuído de software.
§ Intervenção (I): Práticas de gerenciamento de projetos.
§ Resultado (O): Melhor gerenciamento de projetos.
Q3:
§ População (P): Projetos de desenvolvimento distribuído de software.
§ Intervenção (I): Ferramentas.
§ Resultado (O): Apoiar o gerenciamento de projetos.
Q4:
§ População (P): Projetos de desenvolvimento distribuído de software.
§ Intervenção (I): Modelos.
§ Resultado (O): Apoiar o gerenciamento de projetos.
A Comparação e o Contexto da estrutura PICOC não foram utilizados, uma vez
que os objetivos do trabalho não incluem nenhum contexto específico e não buscam
a comparação entre os tópicos investigados.
C3. Estratégia de Busca
Segundo Kitchenham (2007), uma estratégia deve ser usada para a pesquisa
dos estudos primários, com a definição das palavras chaves, bibliotecas digitais,
jornais e conferências. A estratégia usada nessa pesquisa é apresentada nas
próximas seção.
C3.1. Termos Chaves da Pesquisa
A partir das estruturas das questões de investigação (População, Intervenção e
Resultados) definidas anteriormente, os principais termos são identificados. Após a
identificação, é realizada a tradução desses termos para o inglês por ser a língua
utilizada nas bases de dados eletrônicas pesquisadas e nas principais conferências
e jornais dos tópicos de investigação. Além disso, sinônimos são identificados com a
orientação de um especialista no tema de investigação para cada um dos principais
termos.
189
Os termos e sinônimos identificados são apresentados abaixo:
• Gerenciamento de Projetos: Project Management;
• Desenvolvimento Distribuído de Software: Distributed software
development, Global software development, Collaborative software
development, Global software engineering, Globally distributed work,
Collaborative software engineering, Distributed development,
Distributed teams, Global software teams, Globally distributed
development, Geographically distributed software development,
Offshore software development, Offshoring, Offshore, Offshore
outsourcing, Dispersed teams, Dispersed Software Development,
Virtual Software Development, Dispersed Development, Dispersed
Software Engineering, Virtual Software Engineering, Virtual
Development, Virtual Teams, Geographically Dispersed Development
Teams;
• Desafios: Challenge, Difficult, Critical Factor, Problem;
• Melhores Práticas ou Lições Aprendidas: Practice, Best practice,
Good Practice, Lesson, Learned, Success Factor;
• Ferramentas: Tool, Software, Program, System;
• Modelos: Model, Framework, Method, Technique, Methodolog.
C3.2. Strings de Busca
Segundo Kitchenham (2007), as strings são construídas a partir das estruturas
das questões e as vezes adaptações são necessárias de acordo com as
necessidades especificas de cada base de dados. Assim, as strings de busca foram
geradas a partir da combinação dos termos chave e sinônimos usando OR (ou) e
AND (e), e possíveis peculiaridades das bibliotecas digitais e adaptações mediante a
isso, serão registradas. As strings utilizadas para as questões são listadas a seguir
(Quadro 1):
190
Strings da pesquisa Para Q1
(“Project Management”) AND (“Distributed software development” OR “Global software development” OR “Collaborative software development” OR “Global software engineering” OR “Globally distributed work” OR “Collaborative software engineering” OR “Distributed development” OR “Distributed teams” OR “Global software teams” OR “Globally distributed development” OR “Geographically distributed software development” OR “Offshore software development” OR Offshoring OR Offshore OR “Offshore outsourcing” OR “Dispersed teams” OR “Dispersed Software Development” OR “Virtual Software Development” OR “Dispersed Development” OR “Dispersed Software Engineering” OR “Virtual Software Engineering” OR “Virtual Development” OR “Virtual Teams” OR “Geographically Dispersed Development Teams” ) AND ( “Challenge” OR “Difficult” OR “Critical Factor” OR “Problem” )
Para Q2
(“Project Management”) AND (“Distributed software development” OR “Global software development” OR “Collaborative software development” OR “Global software engineering” OR “Globally distributed work” OR “Collaborative software engineering” OR “Distributed development” OR “Distributed teams” OR “Global software teams” OR “Globally distributed development” OR “Geographically distributed software development” OR “Offshore software development” OR Offshoring OR Offshore OR “Offshore outsourcing” OR “Dispersed teams” OR “Dispersed Software Development” OR “Virtual Software Development” OR “Dispersed Development” OR “Dispersed Software Engineering” OR “Virtual Software Engineering” OR “Virtual Development” OR “Virtual Teams” OR “Geographically Dispersed Development Teams”) AND (“Practice” OR “Best practice” OR “Good Practice” OR “Lesson” OR “Learned” OR “Success Factor” )
Para Q3
(“Project Management”) AND (“Distributed software development” OR “Global software development” OR “Collaborative software development” OR “Global software engineering” OR “Globally distributed work” OR “Collaborative software engineering” OR “Distributed development” OR “Distributed teams” OR “Global software teams” OR “Globally distributed development” OR “Geographically distributed software development” OR “Offshore software development” OR Offshoring OR Offshore OR “Offshore outsourcing” OR “Dispersed teams” OR “Dispersed Software Development” OR “Virtual Software Development” OR “Dispersed Development” OR “Dispersed Software Engineering” OR “Virtual Software Engineering” OR “Virtual Development” OR “Virtual Teams” OR “Geographically Dispersed Development Teams”) AND (“Tool” OR “Software” OR “Program” OR “System”)
Para Q4
(“Project Management”) AND (“Distributed software development” OR “Global software development” OR “Collaborative software development” OR “Global software engineering” OR “Globally distributed work” OR “Collaborative software engineering” OR “Distributed development” OR “Distributed teams” OR “Global software teams” OR “Globally distributed development” OR “Geographically distributed software development” OR “Offshore software development” OR Offshoring OR Offshore OR “Offshore outsourcing” OR “Dispersed teams” OR “Dispersed Software Development” OR “Virtual Software Development” OR “Dispersed Development” OR “Dispersed Software Engineering” OR “Virtual Software Engineering” OR “Virtual Development” OR “Virtual Teams” OR “Geographically Dispersed Development Teams”) AND (“Model” OR “Process” OR “Framework” OR “Method” OR “Technique” OR “Methodology”)
Quadro 1. Strings para as quatro questões de pesquisa
C3.3. Fontes de Busca
Segundo Kitchenham (2007), as pesquisas iniciais dos estudos primários
podem ser realizadas em bibliotecas digitais, mas isso não é suficiente para uma
191
revisão sistemática, outras fontes também podem ser pesquisadas. Pesquisadores
da área também podem ser consultados para a indicação de fontes de material mais
adequado.
Os critérios para seleção das fontes são: Disponibilidade de consultar os
artigos na web; Presença de mecanismos de busca usando palavras-chave; e,
Importância e relevância das fontes. Assim, com as strings de busca definidas, as
fontes de pesquisa utilizadas para a busca dos estudos primários são listadas,
conforme abaixo:
• IEEEXplore Digital Library (httt://ieeexplore.ieee.org/)
• ACM Digital Library (http://portal.acm.org)
• Elsevier ScienceDirect (http://www.sciencedirect.com)
• EI Compendex (http://www.engineeringvillage2.org)
• Elsevier Scopus (http://www.scopus.com/home.url)
• Springer Link (http://link.springer.com)
• 7 edições do ICGSE - International Conference on Global Software
Engineering
No protocolo de Costa (2009) as buscas automática foram realizadas nas 4
primeiras fontes definidas (IEEEXplore Digital Library, ACM Digital Library, Elsevier
ScienseDirect e EI Compedex) no período de 1998 à 2009, e na 4a edição da
conferência Internacional de Engenharia de Software Global – ICGSE. Já neste novo
protocolo, duas novas bases serão acrescentadas, Elsevier Scopus e SpringerLink,
onde as buscas vai ser realizada no período de 1998 à 2012, e posteriormente em
todas 7 (sete) edições da conferência Internacional de Engenharia de Software
Global - ICGSE (International Conference on Global Software Engineering),
considerada por especialistas a maior conferência internacional na área. Deste
modo, os estudos disponíveis nesta conferência vai ser comparados com os já
existentes da busca automática. Se o estudo foi armazenado anteriormente, o último
será descartado.
192
Uma vez que potencias estudos primários tenham sido obtidos, eles precisam
ser analisados para que a sua relevância seja confirmada e trabalhos com pouca
relevância sejam descartados. Tendo em vista isto, na próxima seção, critérios de
exclusão são definidos para ajudar na análise desses trabalhos.
C4. Seleção dos Estudos
Os estudos que podem fazer parte dessa pesquisa são:
• Artigos em Jornais, Revistas, Conferências e Congressos;
• Relatórios Técnicos;
• Dissertações e Teses;
Não é descartada a possibilidade de livros serem utilizados na pesquisa,
porém, será avaliada primeiramente a disponibilidade do material. Além disso, outros
estudos não previstos que sejam encontrados e possam contribuir para a pesquisa,
podem ser adicionados. Caso isso aconteça, ou qualquer outra mudança no
processo de busca, será relatada na seção 6 (Documentação do Processo de
Busca).
Uma vez que estudos potencialmente candidatos a se tornarem estudos
primários tenham sido obtidos, eles precisam ser analisados para que a sua
relevância seja confirmada e trabalhos com pouca relevância sejam descartados.
Segundo Travassos (2007) critérios de exclusão devem ser baseados nas questões
de pesquisa. Logo, alguns critérios de exclusão são definidos nas próximas seções,
baseados nos trabalhos de Kitchenham (2007) e Travassos (2007).
C4.1. Critérios de Exclusão
A partir da análise do título, resumo e conclusão, serão excluídos os estudos
que se enquadrem em alguns dos casos abaixo:
a) Estudos que não tem como foco principal ou não citam Dificuldades,
Fatores Críticos, Desafios e Problemas em projetos de
Desenvolvimento Distribuído de Software relacionados ao
gerenciamento;
193
b) Estudos que não apresentam como foco principal ou não citam as Boas
Práticas, Lições Aprendidas e Fatores de Sucesso em projetos de
Desenvolvimento Distribuído de Software relacionados ao
gerenciamento;
c) Estudos que não apresentam como foco principal ou não citam
Modelos, Processos, Técnicas, Metodologias e Ferramentas de apoio
ao Gerenciamento de Projetos no Desenvolvimento Distribuído de
Software;
d) Estudos claramente irrelevantes para a pesquisa, de acordo com as
questões de investigação levantadas;
e) Estudos Repetidos: se determinado estudo estiver disponível em
diferentes fontes de busca, somente a primeira pesquisa será
considerada;
f) Estudos Duplicados: caso dois trabalhos apresentem estudos
semelhantes, apenas o mais recente e/ou o mais completo será
incluído, a menos que tenham informação complementar;
g) Estudos que apresentem texto, conteúdo e resultados incompletos, ou
seja, trabalhos com resultados não concluídos não serão aceitos;
h) Estudos publicados em língua diferente do Inglês;
i) Estudos que estão entre os estudos primários de Costa (2009).
C5. Processo de Seleção dos Estudos Primários
Após a definição das questões de pesquisa, da estratégia usada para a busca
dos estudos primários e dos critérios de exclusão, o processo de seleção dos
estudos primários é descrito abaixo:
194
Formulário A
O formulário A deverá ser utilizado para armazenar dados relativos aos
trabalhos incluídos no estudo.
Trabalhos Incluídos
ID Fonte Título Autor Local de Publicação Tipo Ano
Formulário B
ETAPA 1 – Incialmente realiza - se as buscas para identificar os potenciais estudos primários e a partir da leitura dos títulos dos trabalhos que a pesquisa retorna e palavras-chave, excluem trabalhos que claramente são irrelevantes para as questões investigadas.
ETAPA 3 - A partir da lista unificada com os potenciais candidatos a estudos primários, todos os trabalhos são avaliados por dois ou mais pesquisadores, mediante a leitura do resumo e conclusão, considerando-se os critérios de exclusão, para então chegar a uma lista final de estudos primário.
ETAPA 2 – Listar os potenciais estudos primários;
ETAPA 4 - Os estudos incluídos são documentados através de formulários, assim como todos os trabalhos excluídos e o critério que definiu sua exclusão. Posteriormente, cada estudo primário e lido e através de formulários a extração dos dados e avaliação da qualidade dos trabalhos é realizada.
Etapas do Processo de Seleção dos Estudos Primários
195
O formulário B deverá ser utilizado para armazenar dados relativos aos
trabalhos não incluídos no estudo.
Trabalhos Excluídos
ID Fonte Título Local de Publicação Tipo Autor Ano Critério usado para
Exclusão
Formulário C
O formulário C deverá ser utilizado para extração do dados relativos aos
trabalhos incluídos no estudo.
FORMULÁRIO DE COLETA DE DADOS
ID: Pesquisador: Data da Avaliação:
Título do Trabalho: Autores: Fonte de Pesquisa: Tipo: Local de Publicação: Ano: Tipo de Estudo: Modelo de Negócio: Foco: [x] INCLUIDO - Critérios Utilizados:
QUESTÕES DE PESQUISA
Q1: Quais os principais desafios no gerenciamento de projetos de desenvolvimento distribuído de software? Q2: Quais as melhores práticas a serem adotadas no gerenciamento de projetos de desenvolvimento distribuído de software? Q3: Que ferramentas existem para apoiar as atividades de gerenciamento de projetos no desenvolvimento distribuído de software? Q4: Que modelos existem para apoiar as atividades de gerenciamento de projetos no desenvolvimento distribuído de software?
AVALIAÇÃO DA QUALIDADE
196
Item Critérios de Qualidade Valores Introdução/Planejamento 1 Os objetivos ou questões do estudo são claramente definidos
(incluindo justificativas para a realização do estudo)?
2 O tipo de estudo está definido claramente? Desenvolvimento
3 Existe uma clara descrição do contexto no qual a pesquisa foi realizada?
4 O trabalho é bem/adequadamente referenciado (apresenta trabalhos relacionados/semelhantes e baseia-se em modelos e teorias da literatura)?
Conclusão 5 O estudo relata de forma clara e não ambígua os resultados? 6 Os objetivos ou questões do estudo são alcançados?
Critério Específico para estudos Experimentais (Empirical Studies)
7 Existe um método ou um conjunto de métodos descrito para a realização do estudo?
Critério Específico para estudos Teóricos (Theoretical Study)
7 Existe um processo não tendencioso na escolha dos estudos?
Critério Específico para Revisões Sistemáticas (Systematic Reviews)
7 Existe um protocolo rigoroso, descrito e seguido? Critério Específico para Relato de Experiência Industrial
(Industrial Experience Report)
7 Existe uma descrição sobre a(s) organização(ões), equipe(s), projeto(s) e distribuição envolvida?
Critérios para as Questões de Investigação (Q1, Q2 e Q3 e Q4)
8 O estudo lista primária ou secundariamente dificuldades, desafios ou problemas em projetos de DDS relacionados ao gerenciamento?
9 O estudo lista primária ou secundariamente boas práticas, lições aprendidas ou fatores de sucesso em projetos de DDS relacionados ao gerenciamento?
10 O estudo apresenta Modelos, Processos, Métodos, Técnicas, Metodologias ou Ferramentas de apoio ao gerenciamento de projetos no DDS?
TOTAL Observações/Comentários:
C6. Documentação do Processo de Busca
O processo de execução de revisão sistemática deve ser transparente e
replicável. Assim, toda a revisão, bem como a busca devem ser documentadas
conforme forem executadas e mudanças devem ser anotadas e justificadas. Tendo
197
como base as diretrizes de Kitchenham (2007), essa seção aborda as limitações e
adaptações que ocorram no processo de busca definido para essa revisão.
Os trabalhos são então analisados pelos pesquisadores, através de título,
resumo e palavra-chave, que chegam assim a duas listas de candidatos a estudos
primários.
As listas são então comparadas e os pesquisadores chegam a uma única lista.
A partir dessa lista, os trabalhos são divididos para análise entre os pesquisadores, e
revisados posteriormente. Nessa análise, através de resumo e conclusão, os
trabalhos podem ser excluídos ou incluídos como estudos primários da pesquisa.
Qualquer discordância, o trabalho deve ser incluído.
C7. Avaliação da Qualidade dos Estudos
Em adição aos critérios gerais de exclusão, é considerado importante avaliar a
qualidade dos estudos primários (KITCHENHAM, 2004). Apesar de não existir uma
definição universal do que seja qualidade de estudo, a maioria dos checklists
incluem questões que objetivam avaliar a extensão em que o viés é minimizado e a
validação interna e externa são maximizadas (KHAN et al., 2001; KITCHENHAM,
2007).
C7.1. Tipos de Estudo
Os tipos de estudos são classificados conforme Easterbrook (2007):
• Experimentais ou Empirical Studies;
• Teóricos (estudos conceituais baseados em um entendimento de uma
área, referenciando outros trabalhos relacionados);
• Revisões Sistemáticas (estudos secundários, onde os trabalhos são re-
examinados).
• Relato de Experiência Industrial (Industrial Experience Report – relatos
de experiências práticas na indústria)
198
Os métodos para estudos experimentais (conjunto de princípios de organização
em torno do qual os dados empíricos são coletados e analisados) são classificados
por Easterbrook (2007) como: Experimentos controlados, Estudos de caso, Estudo
de Campo Etnografia e Pesquisa-Ação.
Um experimento controlado é uma investigação de uma hipótese testável, uma
pré-condição para a realização de um experimento é uma hipótese clara. A hipótese
(teoria a partir da qual o experimento é desenhado) guia todas as etapas do projeto
experimental, incluindo a de decidir quais as variáveis a incluir no estudo e como
medi-las (EASTERBROOK, 2007).
Os estudos de caso oferecem uma compreensão profunda de como e porque
certos fenômenos ocorrem. Estudos de caso exploratórios são usados como
investigações iniciais de alguns fenômenos para derivar novas hipóteses e construir
teorias. Já os Estudos de caso de confirmação são usados para testar as teorias
existentes (EASTERBROOK, 2007).
Um Estudo de Campo é usado para identificar as características de uma ampla
população de indivíduos. É mais estreitamente associado com o uso de
questionários para coleta de dados. No entanto, um Estudo de Campo também pode
ser realizado por meio de entrevistas estruturadas, técnicas ou registro de dados
(EASTERBROOK, 2007).
Para a Engenharia de Software, a etnografia pode ajudar a compreender como
as comunidades técnicas constroem uma cultura de práticas e estratégias de
comunicação que lhes permitem executar os trabalhos técnicos de forma
colaborativa (EASTERBROOK, 2007).
Em uma Pesquisa-Ação, os investigadores tentam resolver um problema do
mundo real e simultaneamente estudar a experiência de resolver o problema
(DAVISON et al, 2004).
C7.2. Critérios de Avaliação
Para a realização da avaliação dos estudos primários, algumas questões são
definidas, essas questões estão disponíveis nessa seção e fazem parte do
formulário C da Seção 5. Dentre os critérios de avaliação, existem alguns que
199
deverão ser aplicados a todos os tipos de estudo e outros que são específicos para
cada tipo de estudo (Experimental, Teórico, Revisões Sistemáticas e Relatos de
Experiência Industrial).
Além de perguntas relacionadas à realização e resultados de cada trabalho
avaliado, isto é, como o estudo foi conduzido e se seus objetivos foram alcançados,
3 (três) perguntas relacionadas às questões de investigação são adicionadas, no
intuito de verificar o quanto cada estudo atende aos objetivos dessa pesquisa. Como
as questões são semelhantes e complementares, um mesmo trabalho pode
apresentar resultados para as 4 (quatros) questões de pesquisa e assim obter bons
conceitos nos três critérios.
Para a avaliação da qualidade dos estudos é usada a escala Likert-5, que
permite respostas gradativas através da opinião dos pesquisadores. Para responder
as questões dos critérios de qualidade, o pesquisador pode usar os seguintes níveis
de concordância ou discordância (concordo totalmente, concordo parcialmente,
neutro, discordo parcialmente e discordo totalmente). O Quadro 2 apresenta as
questões da avaliação da qualidade dos estudos. Para a avaliação, devem ser
consideradas as seguintes observações:
• Concordo totalmente (4): deve ser concedido no caso em que o
trabalho atenda totalmente aos critérios da questão;
• Concordo parcialmente (3): deve ser concedido no caso em que o
trabalho atenda parcialmente aos critérios da questão;
• Neutro (2): deve ser concedido no caso em que o trabalho não deixe
claro se atende ou não a questão;
• Discordo parcialmente (1): deve ser concedido no caso em que o
trabalho não atenda aos critérios contidos na questão;
• Discordo totalmente (0): deve ser concedido no caso em que o
trabalho não atenda de forma alguma aos critérios de avaliação, isto é,
não existe nada no trabalho que atenda aos critérios da questão.
200
Item Critérios de Qualidade Valores Introdução/Planejamento 1 Os objetivos ou questões do estudo são claramente definidos (incluindo
justificativas para a realização do estudo)?
2 O tipo de estudo está definido claramente? Desenvolvimento 3 Existe uma clara descrição do contexto no qual a pesquisa foi
realizada?
4 O trabalho é bem/adequadamente referenciado (apresenta trabalhos relacionados/semelhantes e baseia-se em modelos e teorias da literatura)?
Conclusão 5 O estudo relata de forma clara e não ambígua os resultados? 6 Os objetivos ou questões do estudo são alcançados? Critério Específico para estudos Experimentais (Empirical Studies) 7 Existe um método ou um conjunto de métodos descrito para a
realização do estudo?
Critério Específico para estudos Teóricos (Theoretical Study) 7 Existe um processo não tendencioso na escolha dos estudos?
Critério Específico para Revisões Sistemáticas (Systematic Reviews)
7 Existe um protocolo rigoroso, descrito e seguido? Critério Específico para Relato de Experiência Industrial (Industrial
Experience Report)
7 Existe uma descrição sobre a(s) organização(ões), equipe(s), projeto(s) e distribuição envolvida?
Critérios para as Questões de Investigação (Q1, Q2, Q3 e Q4) 8 O estudo lista primária ou secundariamente dificuldades, desafios ou
problemas em projetos de DDS relacionados ao gerenciamento?
9 O estudo lista primária ou secundariamente boas práticas, lições aprendidas ou fatores de sucesso em projetos de DDS relacionados ao gerenciamento?
10 O estudo apresenta Modelos, Processos, Métodos, Técnicas, Metodologias ou Ferramentas de apoio ao gerenciamento de projetos no DDS?
TOTAL Quadro 2. Questões para a Avaliação da Qualidade dos Estudos
C8. Estratégia de Extração dos Dados
Para Kitchenham (2007), o objetivo desta etapa é criar formas de extração dos
dados para registrar com precisão as informações obtidas a partir dos estudos
primários. Esta deve ser projetada para coletar as informações necessárias as
questões. Um formulário eletrônico é sugerido por vários trabalhos, pois segundo
especialistas, o uso pode facilitar a análise posterior.
No formulário A, são listados os trabalhos incluídos, com apenas as
informações que identificam o trabalho e dados que serão apresentados em forma
de gráficos nos resultados da revisão. No formulário B, são listados os trabalhos
201
excluídos e o motivo que levou a exclusão. Já o Formulário C é usado para extrair
as informações gerais e realização da avaliação da qualidade, algumas das
informações necessárias são listadas abaixo:
• ID (identificador), Título, Autores, Pesquisadores que fazem a
avaliação, Data de Avaliação, Fonte de pesquisa, Tipo de publicação
(Jornal ou Conferência), Local de Publicação, Data da Publicação;
• Tipo de Estudo: Experimentais (Experimentos controlados, Estudos de
caso, Survey, Etnografia), Teóricos, Revisões Sistemáticas e Relatos
de Experiência Industrial;
• Modelo de Negócio: Offshore Insourcing (Internal Offshoring), Offshore
Outsourcing (Offshoring), Onshore Insourcing (Demanda doméstica
interna), Onshore Outsourcing (Outsourcing), conforme classificação de
Audy e Prikladnicki, (2007). Para os trabalhos que o modelo de negócio
não esteja claramente definido, será utilizado o termo Distributed
(distribuído);
• Foco: Pessoas, Projeto, Organização;
• Resposta a alguma ou a mais de uma das perguntas de investigação,
Avaliação da Qualidade dos Estudos, Resumo, Análise e Observações.
C9. Síntese dos Dados Coletados
Após a coleta dos dados, as informações devem ser tabuladas de acordo com
as questões de pesquisa, as tabelas devem ser estruturadas de forma a destacar as
semelhanças e diferenças entre os resultados do estudo (KITCHENHAM, 2007;
TRAVASSOS, 2007). Os dados extraídos dos estudos são organizados em planilhas
eletrônicas, que permite a visualização de cada informação extraída em relação as
demais. A partir disso, são realizadas as análises, comparações e sínteses dos
dados.
Kitchenham (2007) afirma em seu trabalho que a síntese dos dados pode ser
quantitativa e/ou qualitativa, sendo que a primeira necessariamente seria tratada
como uma meta-análise. Para a natureza desta pesquisa, e as questões que ela
aborda, só se apresentaram trabalhos com dados qualitativos, logo uma síntese
202
qualitativa é realizada. Sintetizar estudos qualitativos envolve tentar integrar estudos
que se constituem de conclusões e resultados em linguagem natural, onde
diferentes pesquisadores podem ter usado termos e conceitos com alguns (ou
muitos) significados diferentes (KITCHENHAM, 2007).
C10. Documentação e Apresentação dos Resultados
A fase final de atualização de uma revisão sistemática envolve a redação e
comparação dos resultados da análise e divulgação dos resultados aos potenciais
interessados. Alguns estudos indicam alguns tópicos necessários para a
apresentação de uma revisão sistemática: Título (de acordo com as questões de
pesquisa); Autores; Resumo do trabalho (contexto, objetivos, método, resultados e
conclusões); Background (justificativa da necessidade da revisão); Questões da
pesquisa; Método da revisão (estratégia de busca, seleção dos estudos, avaliação
da qualidade, extração e síntese dos dados); Estudos incluídos e excluídos;
Resultados; Discussão, e Conclusões (KITCHENHAM, 2007; TRAVASSOS, 2007).
A partir da síntese dos dados, um conjunto de desafios e melhores práticas no
gerenciamento de projetos de desenvolvimento distribuído de software serão
identificados e documentados, além da apresentação de modelos e ferramentas de
apoio.
C11. Progresso deste estudo
A atualização e ampliação de uma revisão sistemática pode ser por três
maneiras complementares de acordo com Da Silva (2010):
• A atualização temporal pode ser realizada para ampliar o prazo das
publicações de estudos primários, sem grandes mudanças no protocolo
de revisão original.
• Uma extensão de pesquisa pode ser realizada para ampliar o número
de fontes e as estratégias de busca (manual ou automatizado) no
mesmo período da revisão original só para aumentar a cobertura do
estudo original.
203
• Atualização temporal e extensão de busca podem ser combinados.
A revisão sistemática da literatura, tem como objetivo principal investigar “o que
muda no gerenciamento de software quando o desenvolvimento é distribuído?” e
“como apoiar a gerência nesse cenário de desenvolvimento?”, com a leitura do título,
resumo e conclusão dos estudos potencialmente relevantes, e utilizando-se os
critérios de exclusão, na revisão de COSTA (2009) chegou-se a 54 estudos
primários, sobre as questões de investigação, publicados entre os períodos de 1998
a 2009, estes estudos foram pesquisados em quatro fontes de busca automática:
IEEEXplore Digital Library, ACM Digital Library, Elsevier ScienceDirect, El
Compedex e na 4a edição da conferência Internacional de Engenharia de Software
Global - ICGSE 2009.
Neste novo protocolo o objetivo é ampliar a revisão sistemática anterior para
cobrir o período de 2009 a 2012 nas 4 fontes de busca realizada pelo estudo, nessa
posterior extensão duas novas bases de dados serão pesquisadas: Elsevier Scopus
e Springer Link, entre os períodos de 1998 a 2012, e nas 7 (sete) edições do ICGSE.
Analisando a qualidade, e a cobertura de publicações de trabalhos que descreve
abordagens que apóie com práticas e ferramentas eficazes o gerenciamento de
projetos de software quando o desenvolvimento e distribuído.
A Engenharia de Software global tornou-se parte da estratégia de crescimento
das empresas, já que com isso, elas podem estar mais próximas dos mercados
locais e entender melhor as necessidades regionais. Assim alguns países não têm
recursos suficientes para a demanda de TI de produtos e serviços de software, onde
grandes empresas se aproveitam dos recursos globais cada vez mais para o
desenvolvimento de softwares. Devido a diferenças culturais de pessoas envolvidas,
novos sinônimos relacionado ao termo ao “Desenvolvimento Distribuído de Software”
tem surgido. Com a ajuda de um especialista 8 (oito) novos sinônimos foram
encontrados na literatura, e acrescentados a string de busca deste novo protocolo.
Sendo os seguintes termos: Dispersed software development, Virtual software
development, Dispersed development, Dispersed software engineering, Virtual
software engineering, Virtual development, Virtual teams, Geographically dispersed
development teams.
204
Com a ampliação deste protocolo será realizado busca manual e automática
procurando trabalhos publicados em periódicos e anais de conferências, analisando
os estudos relevantes, comparando e integrando o resultados deste protocolo com o
estudo anterior, com os resultados em mão, uma nova análise vai ser colocada em
evidência, verificando, “quais os novos desafios e possíveis melhores práticas?”, e
“o que deixou de ser um desafio no desenvolvimento distribuído de software?”,
devido ao grande números de desafios encontrados no protocolo antecessor. Com a
nova síntese de dados reformular um conjunto de desafios e melhores práticas no
gerenciamento de projetos de desenvolvimento distribuído de software serão
identificados e documentados, além da apresentação de modelo e ferramentas de
apoio.
205
Referências do Protocolo Audy J., Prikladnicki, R. (2007). Desenvolvimento Distribuído de Software: Desenvolvimento de software com equipes distribuídas. Rio de Janeiro, Elsevier. Davison, R. M., Martinsons, M. G., and Kock, N. (2004) Principles of Canonical Action Research. Information Systems Journal 14(1), 65-86. Easterbrook, S., Singer, J., Storey, M., Damian, D. (2007).Selecting Empirical Methods for Software Engineering Research. Guide to Advanced Empirical Software Engineering, Springer. Khan, K.S., ter Riet, G., Glanville, J., Sowden, A.J., Kleijnen, J. (Eds.), 2001. Undertaking Systematic Review of Research on Effectiveness. CRD Report Number 4 (Second Edition), NHS Centre for Reviews and Dissemination, University of York, UK. Kitchenham, B. A. (2004). Procedures for Performing Systematic Reviews. joint technical report, Software Engineering Group, Keele Univ., and Empirical Software Eng., Nat'l ICT Australia. Kitchenham, B. (2007). "Guidelines for performing Systematic Literature Reviews in Software Engineering ," V 2.3 EBSE Technical Report, EBSE-2007-01. Travassos, G., Biolchini J. (2007). Revisões Sistemáticas Aplicadas a Engenharia de Software. In: XXI SBES - Brazilian Symposium on Software Engineering, 2007, João Pessoa. SBES 2007 - XXI Simpósio Brasileiro de Engenharia de Software.
