proceedings eselaw2010 procurar por mapeamento sistematico

Prévia do material em texto

Proceedings of 7th Experimental 
Software Engineering Latin 
American Workshop
(ESELAW 2010)
November 10-12, 2010
Goiânia, GO - Brazil
Organization
Instituto de Informática, Universidade Federal de Goiás
Sponsors
CNPq – Conselho Nacional de Desenvolvimento Científico e Tecnológico
FAPEG – Fundação de Amparo à Pesquisa do Estado de Goiás
FUNAPE – Fundação de Apoio à Pesquisa – UFG
SIAGRI – Sistemas de Gestão
Support
Brazilian Computer Society – SBC
Dados Internacionais de Catalogação na Publicação (CIP)
GPT/BC/UFG
E965p
Experimental Software Engineering Latin American Workshop (7. :
 2010 : Goiânia, GO).
 Proceedings of 7th Experimental Software Engineering Latin
American Workshop (ESELAW 2010), Goiânia, Brazil, November, 10-
12, 2010 [recurso eletrônico] / edited by Auri Marcelo Rizzo Vincenzi, 
Tayana Uchoa Conte, Marllos Paiva Prado. - Goiânia : 
UFG/INF/FUNAPE, 2010.
 CD-ROM, 4 ¾ pol.
 Patrocinadores: CNPq, FAPEG, FUNAPE, SIAGRI.
 ISBN: 978-85-87191-87-8
 1. Engenharia de Software. 2. Workshop. I. Vincenzi, Auri Marcelo 
Rizzo. II. Conte, Tayana Uchoa. III. Prado, Marllos Paiva. IV. Título
 
CDU: 004.41:061.3
7th Experimental Software 
Engineering Latin American 
Workshop
(ESELAW 2010)
November 10-12, 2010
Goiânia, GO - Brazil
Organization
Instituto de Informática, Universidade Federal de Goiás
Sponsors
CNPq – Conselho Nacional de Desenvolvimento Científico e Tecnológico
FAPEG – Fundação de Amparo à Pesquisa do Estado de Goiás
FUNAPE – Fundação de Apoio à Pesquisa – UFG
SIAGRI – Sistemas de Gestão
Edited By
Auri Marcelo Rizzo Vincenzi, INF – UFG
Tayana Uchoa Conte, DCC – UFAM
Marllos Paiva Prado, INF – UFG
Presentation
In the field of Software Engineering, experimentation has a fundamental aspect on 
contributing with the assessment and evolution of the benefits of different techniques, 
methods, methodologies and tools. The global market of Information Technology is 
demanding high quality professionals with knowledge to improve the quality and the 
way software is currently developed. One fundamental aspect in this direction is the 
dissemination of the current state of art on software development techniques among 
academic, industrial and commercial communities. It is essential to exchange ideas to 
understand the strengths and weaknesses of software engineering technologies, focusing 
on the process, design and structure of empirical studies, as well as on the results from 
specific studies.
The Experimental Software Engineering Latin American Workshop (ESELAW) 
contributes in this direction, specially among Brazilian and Latin American 
professionals. Moreover, following a world trend, some Brazilian universities, including 
the Universidade Federal de Goiás, created the Bachelor in Software Engineering, 
aiming at bridging the gap between the theoretical and practical aspects of Software 
Engineering, providing a core of disciplines that the student assimilate, earlier, the 
importance of experimentation in this research area.
The seventh edition of the event – ESELAW 2010 – includes one opening talk, one 
invited talk, two short courses and three technical sections. Prof. Oscar Dieste describes, 
in the opening talk, the experimental conditions under which each meta-analysis method 
such as weighted mean differences, statistical vote counting, parametric response ratio 
and non-parametric response ratio should be applied, based on a recent research that he 
performed using Monte Carlo simulations. In the invited talk, Prof. Guilherme 
Travassos explains how the technology can evolve through experimentation. Prof. 
Emilia Mendes presents an introduction to metrics and measurement of software as the 
first short course and Prof. Oscar Dieste discusses Aggregation of Software Engineering 
Experiments as the second short course. The three technical sections present researches 
on systematic review and experimental software engineering support, studies with 
qualitative focus and experimental studies.
The event received forty paper submissions that were reviewed by three referees each 
one. Twelve of them were selected for presentation in the technical sessions. These 
papers are printed in the proceedings as well as a summary of the talks and short 
courses.
The Instituto de Informática at Universidade Federal de Goiás, GO, Brazil is hosting 
this edition of ESELAW. 
Auri Marcelo Rizzo Vincenzi
Tayana Uchoa Conte
Committees
Chairs
Auri M. R. Vincenzi (INF-UFG, Brazil) – General Chair
Tayana U. Conte (UFAM, Brazil) – Program Chair
Steering Committee
Guilherme Horta Travassos (COPPE-UFRJ, Brazil)
José Carlos Maldonado (ICMC-USP, Brazil)
Márcio Eduardo Delamaro (ICMC-USP, Brazil)
Manoel G. de Mendonça Neto (UFBA, Brazil)
Sandra C. P. F. Fabbri (DC-UFSCAR, Brazil)
Program Committee
Andreas Jedlitschka (Fraunhofer IESE, German) 
Arilo Dias Neto (UFAM, Brazil) 
Carla Lima Reis (UFPA, Brazil) 
Cleidson de Souza (IBM Brasil, Brazil) 
Daniela Cruzes (NTNU, Norway) 
Eduardo Almeida (UFBA-RiSE, Brazil) 
Ellen Francine Barbosa (ICMC-USP, Brazil)
Emilia Mendes (The University of Auckland, New Zealand) 
Fabio Queda Bueno da Silva (UFPE, Brazil) 
Giovanni Cantone (University of Rome TorVergata, Italy) 
Guilherme Travassos (COPPE-UFRJ, Brazil) 
Jeffrey Carver (University of Alabama, USA) 
José Carlos Maldonado (ICMC-USP, Brazil)
Juliano Oliveira (UFG, Brazil) 
Manoel G. de Mendonça Neto (UFBA, Brazil) 
Marcela Genero (University of Castilla-La Mancha, Spain)
Márcio Eduardo Delamaro (ICMC-USP, Brazil) 
Marco Antônio Pereira Araújo (COPPE-UFRJ, Brazil) 
Marcos Chaim (EACH-USP, Brazil)
Oscar Dieste (Universidad Politécnica de Madrid, Spain)
Oscar Pastor (Universitat Politècnica de València, Spain)
Plínio Leitão-Júnior (UFG, Brazil) 
Rafael Prikladnicki (PUCRS, Brazil)
Raul Sidnei Wazlawick (UFSC, Brazil)
Sandra C. P. F. Fabbri (DC-UFSCar, Brazil)
Sergio Ochoa (Universidad de Chile, Chile)
Simone Souza (ICMC-USP, Brazil)
Organizing Committee
Local Arrangements Chair
Cristiane Bastos Rocha Ferreira (INF-UFG, Brazil)
Edmundo Sérgio Spoto (INF-UFG, Brazil)
Tutorial And Short Course Session
Guilherme Horta Travassos (COPPE-UFRJ, Brazil)
Publication Chair
Marllos Paiva Prado (INF-UFG, Brazil)
External Reviewers
Adailton Lima (UFPA, Brazil)
Alline Lemos (UFPA, Brazil)
Fabiano Cutigi Ferrari (ICMC-USP, Brazil)
Gleison Santos (UNIRIO, Brazil)
Katia Felizardo (ICMC – USP, Brazil)
Leandro Oliveira (INF-UFG, Brazil)
Maria Istela Cagnin (UFMS, Brazil)
Paulo Masiero (ICMC - USP, Brazil)
Mayara Figueiredo (UFPA, Brazil)
Pedro Treccani (UFPA, Brazil)
Rodrigo Reis (UFPA , Brazil)
Rogério Eduardo Garcia (UNESP, Brazil)
Rosana Braga (ICMC-USP, Brazil)
Valdemar Neto (UFG, Brazil)
Conteu´do
Invited Talk 2
Comparative Analysis of Meta-Analysis Methods: When to Use Which (Oscar
Dieste) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Developing Software Technologies through Experimentation: Experiences from
the Battlefield (Guilherme Travassos) . . . . . . . . . . . . . . . . . . . . . . 5
Short Courses 6
Introduc¸a˜o a Me´tricas e Medic¸a˜o de Software (Emı´lia Mendes) . . . . . . . . . . 7
Aggregation of Software Engineering Experiments (Oscar Dieste) . . . . . . . . . 8
Technical Session 1 -Systematic Reviews and Experimental Software Engi-
neering Support 9
Uso dos Resultados de um Estudo Baseado em Revisa˜o Sistema´tica para Ela-
borar uma Proposta Inicial de Pesquisa (Nata´lia Chaves Lessa Schots, Ana
Regina Rocha, Gleison Santos) . . . . . . . . . . . . . . . . . . . . . . . . . 10
Estudo Baseado em EvideˆnciasSobre Dificuldades, Fatores e Ferramentas no
Gerenciamento da Comunicac¸a˜o em Projetos de Desenvolvimento Distri-
bu´ıdo de Software (Alinne C. Correia dos Santos, Camila Cunha Borges, David
E. S. Carneiro, Fabio Q. B. da Silva) . . . . . . . . . . . . . . . . . . . . . . 20
Avaliac¸a˜o da Ferramenta StArt Utilizando o Modelo TAM e o Paradigma GQM
(Elis Hernandes, Augusto Zamboni, Andre Di Thommazo, Sandra Fabbri) . . . 30
Uma Ferramenta de Apoio ao Planejamento de Estudos Experimentais em En-
genharia de Software (Vitor Pires Lopes, Guilherme Horta Travassos) . . . . 40
Technical Session 2 - Studies With Qualitative Focus (SQF) 49
Utilizac¸a˜o de Metodologias A´geis no Desenvolvimento de Software: Resultados
de um Estudo Emp´ırico (Pedro J. F. Treccani, Cleidson R. B. de Souza) . . . 50
Aplicando Te´cnicas de Grounded Theory e Retrospectiva A´gil Para Buscar Me-
lhorias Para o Curso Laborato´rio XP (Viviane A. Santos, Alfredo Goldman) 60
Trabalhamos Enquanto voceˆ Trabalha: Utilizando Grounded Theory Para Iden-
tificar as Vantagens do Brasil no Mercado Global de TI em Func¸a˜o da sua
Posic¸a˜o Geogra´fica (Rafael Prikladnicki) . . . . . . . . . . . . . . . . . . . . 70
Um Estudo Explorato´rio dos Fatores Associados ao Est´ımulo do Aprendizado
em Times A´geis na Indu´stria (Claudia de O. Melo, Carlos D. Santos Jr, Gisele
R. M. Ferreira, Fabio Kon) . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Experimental Studies 90
Resultados de um Estudo de Caracterizac¸a˜o e Avaliac¸a˜o de Crite´rios de Teste
Estruturais Entre os Paradigmas Procedimental e OO (Marllos Paiva Prado,
Simone do Rocio Senger de Souza, Jose´ Carlos Maldonado) . . . . . . . . . . . 91
Reuso de Conjuntos de Casos de Teste no Ensino de Disciplinas Introduto´rias
de Programac¸a˜o (Maria A. S. Brito, Joa˜o L. Rossi, Simone R. S. de Souza,
Rosana T. V. Braga) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
1
Evaluating a Tool for Bug-report Analysis and Search (Yguarata˜ Cerqueira Ca-
valcanti; Paulo Anselmo da Silveira Mota; Ivan do Carmo Machado; Eduardo
Santana de Almeida; Silvio Romero de Lemos Meira) . . . . . . . . . . . . . . 111
Boas Pra´ticas para Apoiar o Gerenciamento de Tempo em Projetos DDS (Ana
Carina M. Almeida, Ivaldir H. de F. Jr, Renata Souza, Hermano Perrelli) . . . 121
2
 
 
 
 
 
 
 
INVITED TALK 
 
 
 
 
 
 
 
 
3
Oscar Dieste: Comparative analysis of meta-analysis 
methods: when to use which 
 
 
Several meta-analysis methods can be used to quantitatively combine the results of a 
group of experiments, including weighted mean differences, statistical vote counting, 
parametric response ratio and non-parametric response ratio. Research on the 
quantitative combination of experimental results in software engineering has mainly 
focused on weighted mean differences. However, the other meta-analysis methods have 
their strengths. The software engineering community has not yet investigated decision-
making on which meta-analysis method to use. In this talk, I will describe the 
experimental conditions under which each meta-analysis method should be applied, 
based on a recent research that we performed using Monte Carlo simulations. 
 
Prof. Oscar Dieste is researcher at the Empirical Software Engineering lab 
(http://www.grise.upm.es) of the Madrid Technical University. His research interests 
are requirements engineering and empirical software engineering. In this field, he is 
focused on experimental aggregation, either using statistical (meta-analysis) and non-
statistical procedures. He has published some papers on the field (i.e., Understanding 
the Customer: What Do We Know about Requirements Elicitation? @ TSE) and taught 
a number of courses and tutorials on experiment aggregation at several venues, such as 
the International Advanced School on Software Engineering (IASESE'2008), 2010 
FIRST Research School and Conferencia Iberoamericana en Ingeniería del Software 
(CIbSE 2010). Further information about Oscar is available at 
http://www.grise.upm.es/miembros/oscar/. 
 
 
 
 
 
 
4
Guilherme Horta Travassos: Developing Software 
Technologies through Experimentation: Experiences 
from the Battlefield
For a long time scientists have been committed to describe and organize information 
obtained by observations from the field. We can observe similar behavior in Software 
Engineering. Software engineers have intensively worked to understand the application 
and evolution of software processes and technologies by applying the scientific method 
(experimentation) to support their researches. Nowadays, experimentation based 
approaches already represent a cardinal tool to allow the transference of software 
technologies to the industry; improve software processes and evidence behaviors in 
Software Engineering. The Experimental Software Engineering Group at COPPE/UFRJ 
(ese.cos.ufrj.br) promotes experimentation in the building of software technologies to 
the industry. However, the mere providing of the software technology is not enough. It 
is necessary to produce evidence regarding its feasibility and applicability for different 
development contexts. Therefore, we believe for a technology to be made available it is 
necessary that it goes through three initial stages in its life cycle: conception, 
construction and evaluation. Some approaches to construct and evaluate software 
technologies are easily found in the technical literature. However, this is not the case 
with the conception stage. This talk discuss an approach concerned with the conception, 
construction and evaluation of software technologies based on evidences collected 
through secondary and primary studies to support their development. The types of 
studies (including (quasi) systematic reviews, surveys, quasi-experiments, action 
research and so on) and decision points are presented to allow their evaluation and 
application by software engineers. The arguments will be illustrated with concrete 
examples of technologies that have been developed by ESE group following this 
approach..
Prof. Guilherme H. Travassos is an Associate Professor of Software Engineering in the 
Systems Engineering and Computer Science Program at COPPE – Federal University 
of Rio de Janeiro-Brazil and a CNPq – Brazilian Research Council researcher. He 
received his doctorate degree from COPPE/UFRJ in 1994. He has been with the 
Experimental Software Engineering Group at the University of Maryland- College Park 
for a post-doctoral position (1998/2000). Prof. Travassos leads the Experimental 
Software Engineering Group at COPPE/UFRJ. His current research interests include 
experimental software engineering, e-science, software quality, software engineering 
environments and verification, validation and testing concerned with object-oriented 
software. Prof.Travassos is member of the ISERN, ACM and SBC - Brazilian Computer 
Society. Most of the information regarding his research projects and working activities 
can be found at http://www.cos.ufrj.br/~ght. Contact him at ght@cos.ufrj.br. 
5
 
 
 
 
 
 
 
INVITED SHORT COURSES 
 
 
 
 
 
 
 
 
6
Introdução a métricas e medição de software
Emília Mendes
Métricas e medição de software objetivam aplicar uma abordagem de engenharia para 
desenvolvimento e manutenção de software. Ao medir as características de software e 
processos de desenvolvimento, feedback pode ser obtido, e utilizado a fim de 
compreender, controlar e melhorar os nossos produtos (por exemplo, software) e 
processos (por exemplo, desenvolvimento, manutenção, reutilização). Este cursovisa 
introduzir os conceitos de métricas e medição de software utilizando exemplos práticos 
no contexto de estimativa de custos de projetos de software. O entendimento destes 
conceitos facilitará empresas a entenderem melhor e aperfeiçoarem os seus processos de 
desenvolvimento de software, e o software desenvolvido.
Prof. Emilia Mendes is the principal investigator in the Tukutuku Research project, 
aimed at developing and comparing Web effort models using industrial Web project 
data, and benchmarking productivity within and across Web companies. She has active 
research interests in the areas of Web engineering, Empirical Software Engineering, 
Hypermedia and Computer Science education, in which areas she has published widely 
and more than 100 refereed papers. A/Prof. Mendes has been on the programme 
committee of more than 90 conferences and workshops, and on the editorial board of 
the International Journal of Web Engineering and Technology, the Journal of Web 
Engineering, the Journal of Software Measurement, the International Journal of 
Software Engineering and Its Applications, and Empirical Software Engineering. She 
has collaborated with Web companies in New Zealand and overseas on Web effort 
estimation and usability measurement. A/Prof. Mendes worked in the software industry 
for ten years before obtaining her PhD in Computer Science from the University of 
Southampton (UK), and moving to Auckland.
7
Aggregation of Software Engineering Experiments
Oscar Dieste
The precision and accuracy of software experiments is limited. It is necessary to 
combine several experimental replications to overcome the weaknesses of single 
experiments. A range of aggregation procedures can be used, but the application of 
quantitative procedures based on meta-analysis techniques is now being championed. 
The most popular meta-analysis technique in SE is the weighted mean difference 
(WMD). This technique was used in seminal papers by Miller, Basili and Kitchenham, 
and it is the method of choice of recent aggregation research (i.e., Dyba on Pair 
Programming). However, WMD is just one of several meta-analysis techniques, such as 
response ratio or vote counting. This short course will describe those techniques and 
how to apply them in practice.
Prof. Oscar Dieste is researcher at the Empirical Software Engineering lab 
(http://www.grise.upm.es) of the Madrid Technical University. His research interests are 
requirements engineering and empirical software engineering. In this field, he is 
focused on experimental aggregation, either using statistical (meta-analysis) and non-
statistical procedures. He has published some papers on the field (i.e., Understanding 
the Customer: What Do We Know about Requirements Elicitation? @ TSE) and taught 
a number of courses and tutorials on experiment aggregation at several venues, such as 
the International Advanced School on Software Engineering (IASESE'2008), 2010 
FIRST Research School and Conferencia Iberoamericana en Ingeniería del Software 
(CIbSE 2010). Further information about Oscar is available at 
http://www.grise.upm.es/miembros/oscar/.
8
 
 
 
 
 
 
 
TECHNICAL SESSION 1 
Systematic Reviews and Experimental 
Software Engineering Support 
(SRESES) 
 
 
 
 
 
 
9
 
Uso dos Resultados de um Estudo Baseado em Revisão 
Sistemática para Elaborar uma Proposta Inicial de Pesquisa 
Natália Chaves Lessa Schots
1
, Ana Regina Rocha
1
, Gleison Santos
2
 
1
 COPPE/UFRJ – Universidade Federal do Rio de Janeiro 
Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro, Brasil 
2
 Programa de Pós-Graduação em Informática – Universidade Federal do Estado do Rio 
de Janeiro (UNIRIO) - Av. Pasteur 458, Urca, CEP 22290-240 – Rio de Janeiro, RJ 
{natalia, darocha}@cos.ufrj.br, gleison.santos@uniriotec.br 
Abstract. A systematic review is a formal process to identify, evaluate and 
interpret the available and relevant research results on a certain subject. This 
paper presents how a systematic review-based study was planned and 
executed to assist the development and refinement of an approach to support 
the identification of problems’ root causes. We present the results of this study, 
as well as how they have influenced the definition of that approach. 
Resumo. Uma revisão sistemática é um processo formal para identificar, 
avaliar e interpretar a pesquisa disponível e relevante sobre determinado 
assunto. Este artigo apresenta como um estudo baseado em revisão 
sistemática foi planejado e executado para auxiliar a elaboração e 
refinamento de uma abordagem para apoiar a identificação de causas raiz de 
problemas. São apresentados os resultados deste estudo, além de como eles 
influenciaram positivamente na definição da abordagem. 
1. Introdução 
É cada vez mais evidente para uma organização de desenvolvimento de software a im-
portância da adoção de estratégias preventivas contra qualquer tipo de problema. Grady 
(1996) e Card (2005), por exemplo, apresentam alguns riscos que uma organização pode 
enfrentar ao adotar somente medidas reativas diante dos problemas que, naturalmente, 
surgem durante seu dia-a-dia. Dentre as estratégias que auxiliam a prevenção de ocor-
rência de problemas, a Análise de Causas de Problemas vem sendo muito discutida na 
literatura, além de ser frequentemente utilizada nas organizações [Card 2005] [Kali-
nowski et al. 2008]. 
A Análise de Causas de Problemas é definida como um processo de coleta e aná-
lise de dados sobre determinado evento, a fim de identificar suas causas com o objetivo 
de desenvolver melhorias no processo e prevenir uma nova ocorrência deste evento no 
futuro [Collofello e Gosalia 1993] [Rooney e Heuvel 2004]. De acordo com Endres 
(1975), a maioria das informações necessárias para identificar a causa raiz de um pro-
blema está no inconsciente das pessoas que lidam com este problema no seu ambiente 
de trabalho. Pressupõe-se ser este o motivo pelo qual a maioria das abordagens de Aná-
lise de Causas de Problemas utiliza técnicas que auxiliam a externalização do conheci-
mento implícito, tais como diagrama de Ishikawa, entrevista e sessões de brainstorming. 
10
 
Contudo, há um risco inerente à adoção deste tipo de técnicas para obter as in-
formações necessárias para identificar a causa raiz: estas técnicas não seguem regras 
explícitas durante sua execução e, portanto, são subjetivas, dependendo excessivamente 
tanto do conhecimento da pessoa que está conduzindo a técnica quanto do conhecimento 
das demais pessoas envolvidas. Este risco pode acarretar na identificação inadequada da 
causa raiz do problema e, portanto, invalidar o esforço despendido na execução da Aná-
lise de Causas. 
 Para tentar resolver este impasse, uma abordagem foi elaborada com o objetivo 
de: (1) melhorar a qualidade das informações sobre os problemas coletadas para a Aná-
lise de Causas de Problemas e (2) minimizar a subjetividade desta coleta e da análise 
dos dados, adotando procedimentos específicos para tal. De uma forma geral, esta abor-
dagem visa auxiliar a captura de informações relevantes a respeito do problema selecio-
nado (apoiada por um processo definido e modelos (templates) de documentos) e anali-
sar estas informações utilizando conceitos da Grounded Theory [Strauss e Corbin 1998] 
(um método de pesquisa qualitativa que gera teorias fundamentadas em dados), a fim de 
que a(s) causa(s) do problema sejam identificadas. A descrição completa da abordagem 
é apresentada em [Schots et al. 2010] [Schots 2010]. 
 A fim de embasar a proposta inicial da abordagem em conhecimentos anteriores,um estudo baseado em revisão sistemática foi conduzido. Uma revisão sistemática se 
refere a uma metodologia específica de pesquisa, desenvolvida para coletar e avaliar 
evidências disponíveis sobre determinado tópico [Biolchini et al. 2005]. A partir da e-
xecução deste tipo de pesquisa, buscam-se resultados mais abrangentes e menos de-
pendentes do conhecimento do pesquisador, permitindo que a pesquisa seja repetida por 
outros pesquisadores e os resultados possam ser comparados. No contexto deste traba-
lho, um estudo baseado em revisão sistemática foi conduzido com o objetivo de identi-
ficar estudos com propostas de execução do processo de Análise de Causas de Proble-
mas – especificamente da etapa de identificação da causa raiz. Este artigo apresenta o 
planejamento e a execução deste estudo e como os resultados deste estudo influenciaram 
a definição da abordagem proposta. 
Para condução do estudo baseado em revisão sistemática, foi seguido o processo 
definido em [Silva Filho 2006], composto pelas atividades descritas nas seções a seguir: 
definir escopo e estudos preliminares, definir protocolo (seção 2), testar protocolo (se-
ção 3), avaliar protocolo, executar a pesquisa (seção 4) e avaliar resultados da pesquisa 
(seção 5). Além destas atividades, há duas atividades (empacotar resultados e publicar 
resultados) que não são descritas, pois se referem à disponibilização dos resultados para 
a comunidade científica, o que é realizado a partir da publicação do estudo neste traba-
lho. Por fim, na seção 6 são apresentadas as considerações finais deste trabalho. 
2. Definição do Escopo e do Protocolo 
Nesta primeira atividade, foi realizada uma pesquisa informal sobre Análise de Causas 
de Problemas, objetivando obter conhecimento sobre o domínio. Após analisar os traba-
lhos encontrados, verificou-se a importância da etapa de identificação de causas de pro-
blemas e a carência de técnicas que possibilitassem uma forma sistemática para esta 
identificação. Além disso, verificou-se a carência de abordagens que lidassem com pro-
blemas no âmbito organizacional na área de engenharia de software, tais como: desvio 
11
 
de cronograma, rotatividade de pessoal e problemas de comunicação. 
A partir destas informações, o escopo do estudo baseado em revisão sistemática 
foi estabelecido e consiste na pesquisa de trabalhos que apresentam a Análise de Causas 
de Problemas (principalmente a etapa de identificação da causa raiz) de outros tipos de 
problemas relacionados ao processo de desenvolvimento de software, além de defeitos. 
O protocolo do estudo baseado em revisão sistemática possui o objetivo de guiar 
a execução do estudo. Este protocolo é composto pela descrição dos seguintes itens: 
contexto do estudo, objetivos a serem atingidos, questões de pesquisa, escopo delimita-
do, idiomas escolhidos, métodos de busca das publicações, procedimentos de seleção e 
critérios para inclusão das publicações no estudo, procedimentos para extração de dados 
e procedimentos para a análise dos resultados. Por motivos de limitação de espaço so-
mente alguns destes itens serão detalhados neste artigo. A descrição completa do proto-
colo é apresentada em [Schots 2010]. 
Objetivo - O objetivo deste estudo foi delineado a partir do paradigma GQM [Basili e 
Rombach 1988] e consiste em analisar relatos de experiência e publicações científicas 
sobre Análise de Causas de Problemas, com o propósito de identificar técnicas, méto-
dos, processos e ferramentas, com relação a procedimentos para identificação das cau-
sas raiz de problemas, do ponto de vista de pesquisadores, no contexto acadêmico e in-
dustrial. 
Questões de pesquisa - A partir do objetivo do estudo, foi elaborada uma questão prin-
cipal “Que técnicas, métodos, processos e ferramentas têm sido propostos e/ou utiliza-
dos para identificar causas raiz de problemas durante o processo de Análise de Causas 
de Problemas?” e quatro questões secundárias: (i) “Quais técnicas, métodos, processos 
e ferramentas que apoiam a sistematização da identificação de causa raiz de proble-
mas?”; (ii) “Que dados de problemas são, geralmente, coletados para que as causas do 
problema sejam identificadas eficientemente?”; (iii) “Quais são as características dos 
problemas normalmente tratados pela Análise de Causas de Problemas?”; e (iv) “Como 
os problemas são categorizados durante o processo de Análise de Causas?”. 
Métodos de busca de publicações - A máquina de busca foi acessada via Web, por 
meio de expressão de busca pré-estabelecida, apresentada a seguir no formato da má-
quina de busca Scopus (www.scopus.com): TITLE-ABS-KEY("causal analysis" OR 
"cause analysis" OR "cause-effect analysis" OR "cause-and-effect analysis" OR "root 
cause analysis" OR "root-cause analysis" OR "defect analysis") AND ("root cause") 
AND (process OR approach OR method OR methodology OR technique OR tool OR 
paradigm OR strategy)) AND PUBYEAR AFT 1975 AND (LIMIT-TO(SUBJAREA, 
"COMP") OR LIMIT-TO(SUBJAREA, "BUSI") OR LIMIT-TO(SUBJAREA, "MULT")) 
Até se chegar a esta expressão final, foi realizado um processo de teste da ex-
pressão de busca, detalhado na seção 3 deste artigo. Durante este processo, decidiu-se 
limitar a pesquisa à Scopus (esta escolha também está descrita na seção 3). 
Procedimentos de seleção e critérios - A seleção dos estudos foi feita em três etapas: 
1ª Etapa: seleção e catalogação preliminar dos estudos coletados: a seleção preliminar 
das publicações foi feita a partir da aplicação da expressão de busca à fonte selecionada. 
Cada publicação foi catalogada e armazenada em um banco de dados criado na ferra-
12
 
menta EndNote (www.endnote.com) para posterior análise; 
2ª Etapa: seleção dos estudos relevantes (1º filtro): a seleção preliminar com o uso da 
expressão de busca não garante que todo o material coletado seja útil no contexto da 
pesquisa, pois a aplicação das expressões de busca é restrita ao aspecto sintático. Desta 
forma, os resumos (abstracts) das publicações retornadas foram lidos e analisados se-
guindo os critérios de inclusão a seguir, verificando se a publicação propõe ou descreve 
como sua principal contribuição o uso de: (CI1) técnicas, métodos, processos e/ou fer-
ramentas relacionadas à Análise de Causas; (CI2) técnicas, métodos, processos e/ou 
ferramentas relacionadas à identificação de causas; (CI3) técnicas, métodos, processos 
e/ou ferramentas relacionadas à captura de problemas para Análise de Causas; ou (CI4) 
esquemas de classificação de problemas na Análise de Causas. 
3ª Etapa: seleção dos estudos relevantes (2º filtro): apesar de limitar o universo de bus-
ca, o filtro anterior também não garante que todo o material coletado seja útil no contex-
to da pesquisa. Por isso, as publicações selecionadas na 2ª etapa devem ser lidas com-
pletamente, verificando se, de fato, atendem a, pelo menos um, dos critérios definidos. 
3. Teste de Protocolo 
Antes da definição da expressão de busca final, vários testes foram conduzidos de forma 
a tentar garantir que a expressão de busca escolhida estivesse de acordo com o objetivo 
e questões do presente estudo. A partir da pesquisa inicial (apresentada da seção 2), fo-
ram identificados artigos relevantes para o contexto deste trabalho e que serviram como 
artigos de controle da expressão de busca (ver Tabela 1). Caso a expressão de busca 
retornasse todos estes artigos, então haveria indícios de que estaria adequada. 
Tabela 1 – Artigos de controle 
# Título Autor(es) Ano 
1 An Analysis of Errors and their Causes in System Programs G. Endres 1975 
2 Experiences with Defect Prevention 
R.G. Mays, C.L. Jones 
et al. 
1990 
3 
An Application of Causal Analysis to the Software Modification 
ProcessJ. Collofello e B. 
Gosalia 
1993 
4 
Software Failure Analysis for High Return Process Improvement 
Decisions 
R. Grady 1996 
5 Root Cause Analysis for Beginners J. Rooney e L. Heuvel 2004 
6 Defect Analysis: Basics Techniques for Management and Learning D. Card 2005 
7 
Implementing Causal Analysis and Resolution in Software Devel-
opment Projects: The MiniDMAIC Approach 
F. Gonçalves, C. Be-
zerra et al. 
2008 
8 Towards a Defect Prevention Based Process Improvement Approach 
M. Kalinowski, G. 
Travassos e D. Card 
2008 
Primeira rodada - Na primeira rodada de testes foi utilizada a seguinte expressão de 
busca: ("causal analysis" OR "cause analysis" OR "cause-effect analysis" OR "cause-
and-effect analysis" OR "root cause analysis" OR "root-cause analysis") AND (identify 
OR recognize OR recognise OR identification OR recognition) AND ("root cause") 
AND (process OR approach OR method OR methodology OR technique OR tool OR 
paradigm OR strategy). 
 As máquinas de busca utilizadas neste primeiro momento foram a Scopus e a 
Compendex. Estas fontes atenderam aos critérios adotados para a pesquisa e foram sele-
13
 
cionadas devido ao bom funcionamento e abrangência de suas máquinas de busca, evi-
denciadas em alguns trabalhos, como o de SANTOS (2008). Após a execução da ex-
pressão de busca, foram identificadas 249 publicações na base da Scopus (sendo que dos 
8 artigos de controle, 5 estavam indexados e somente 2 destes foram retornados: artigos 
5 e 8) e 80 publicações na Compendex (sendo que dos 8 artigos de controle, 4 estavam 
indexados e nenhum deles foi retornado). 
Segunda rodada - Com a execução do primeiro teste, identificou-se que a expressão de 
busca não estava adequada, pois uma quantidade razoável dos artigos de controle defi-
nidos não estava sendo retornada. Após analisar as palavras-chaves dos artigos de con-
trole, foi decidido retirar da expressão de busca a restrição (identify OR recognize OR 
recognise OR identification OR recognition). 
 Após a execução desta nova expressão de busca, foram identificadas 758 publi-
cações na Scopus (sendo que dos 5 artigos de controle indexados, apenas o artigo 6 não 
foi retornado) e 361 na Compendex (sendo que dos 4 artigos de controle indexados, 
somente artigo 4 foi retornado). 
Terceira rodada - A partir dos resultados obtidos, decidiu-se alterar a expressão de 
busca, adicionando o termo “defect analysis” para incluir o único artigo de controle in-
dexado ainda não retornado na máquina de busca Scopus. Após esta alteração, verifi-
cou-se que a expressão retornou todos os artigos de controle indexados em somente uma 
das fontes de busca (Scopus). No entanto, o número de publicações retornadas cresceu 
muito em ambas as fontes. Após esta constatação, decidiu-se analisar mais detalhada-
mente as publicações que estavam sendo retornadas, separando-as por área de conheci-
mento (permitido somente na fonte de busca Scopus). 
Foram analisadas as publicações das áreas de conhecimento que retornavam 
mais de 30 publicações, a partir da leitura dos resumos (abstracts) das 40 primeiras pu-
blicações (quando existiam). Os critérios de inclusão foram utilizados para avaliar quais 
publicações fariam parte do escopo do trabalho ou não. Os resultados desta análise estão 
apresentados na Tabela 2. 
Após a análise dos resumos dos artigos retornados, verificou-se a impossibili-
dade de identificar algum termo-chave para ser inserido ou retirado da atual expressão 
de busca para que a pesquisa retornasse publicações de acordo com o objetivo do estu-
do. Por outro lado, foi observado a partir do cálculo do índice de relevância (apre-
sentado na Tabela 2) que a área Ciência da Computação foi a área de conhecimento que 
mais retornou publicações relevantes. Assim, decidiu-se limitar a pesquisa a apenas esta 
área. 
Quarta rodada - Dada a facilidade fornecida pela máquina de busca Scopus – a partir 
da função “Limit to” – e pelos poucos resultados relevantes obtidos na máquina de busca 
Compendex, decidiu-se limitar esta pesquisa à execução da expressão de busca na Sco-
pus. Nesta quarta rodada de testes, 114 publicações foram retornadas na máquina de 
busca Scopus. Todos os artigos de controle que estavam indexados nesta base (exceto o 
artigo 5) foram retornados. Verificou-se que o artigo de controle 5, não retornado nesta 
rodada de testes, pertence à área de conhecimento “negócios, gerência e contabilidade” e 
como esta área parece ser relevante para o contexto deste estudo (devido ao seu alto ín-
dice de relevância), decidiu-se incluir também esta área de conhecimento na pesquisa. 
14
 
Tabela 2 – Resultados da análise dos artigos retornados por área de conhecimento 
Área de conhecimento 
Nº total de 
publicações 
Nº de resu-
mos lidos 
Nº de publicações 
selecionadas 
Índice de 
relevância
1
 
Engenharia 359 40 17 2,35 
Medicina 167 40 5 8 
Ciência da Computação 114 40 20 2 
Enfermagem 58 40 13 3,08 
Engenharia Química 56 40 9 4,44 
Ciências Sociais 43 40 11 3,63 
Física e Astrologia 43 40 6 6,67 
Energia 41 40 15 2,67 
Ciência de Materiais 41 40 8 5 
Negócio, Gerência e Contabilidade 34 34 14 2,43 
Matemática 32 32 8 4 
Quinta rodada - Dados os resultados anteriores, a quinta e última rodada de testes foi 
realizada. A pesquisa, portanto, limitou-se a duas áreas de conhecimento: “ciência da 
computação” e “negócios, gerência e contabilidade”. Com esta nova definição, foram 
retornadas 152 publicações, sendo que todos os artigos de controle indexados foram 
retornados. Desta forma, a expressão de busca foi calibrada de forma que todos os arti-
gos de controle indexados na máquina de busca fossem retornados. Com isto, a expres-
são foi considerada adequada para a execução da pesquisa. 
4. Avaliação do Protocolo e Execução da Pesquisa 
A avaliação do protocolo foi feita de duas formas: em apresentações de seminários mi-
nistrados na COPPE/UFRJ com a participação de especialistas na área de Análise de 
Causas, onde se avaliava o escopo e a abrangência das questões de pesquisa, e por um 
especialista com conhecimento em execução de revisões sistemáticas, onde se avaliou o 
formalismo do estudo e a adequação da string de busca. Os seminários são apresenta-
ções realizadas, periodicamente, pelos alunos de pós-graduação da área de Qualidade da 
linha de Engenharia de Software da COPPE/UFRJ. Nestes seminários, os alunos apre-
sentam o andamento e os resultados de suas pesquisas a fim de obter o retorno do(s) 
orientador(es) e dos demais alunos. Além disso, a expressão de busca foi avaliada a par-
tir do retorno dos artigos de controle definidos inicialmente. 
Após o estabelecimento e aprovação do protocolo de pesquisa, o estudo baseado 
em revisão sistemática foi executado. A execução do protocolo foi realizada em dois 
momentos: antes da definição completa da abordagem (em agosto de 2009) e após a 
finalização da definição da abordagem (em abril de 2010). 
Execução em Agosto de 2009 - Como primeira etapa da seleção dos estudos, a expres-
são de busca definida foi executada na máquina de busca Scopus. Esta execução retor-
nou 152 publicações. Na etapa seguinte de seleção dos estudos, o título e resumo de 
cada publicação foram lidos. Seguindo os critérios de inclusão estabelecidos, foram se-
lecionadas 53 publicações, além dos 5 artigos de controle retornados pela máquina de 
busca. Não foi possível acessar todas as publicações selecionadas na segunda etapa: das 
53 publicações selecionadas, apenas 42 estavam disponíveis para download. 
 
1 O índice de relevância foi calculado dividindo-se o número de resumos lidos pelo número de publicações selecio-nadas. Quanto mais próximo de 1 o índice estiver, melhor é a relevância das publicações da área para o estudo. 
15
 
Para atender à terceira etapa de seleção, as 42 publicações foram lidas comple-
tamente e, destas, somente 14 atendiam a, pelo menos, um dos critérios de inclusão de-
finidos. Foram extraídas as informações das 14 publicações consideradas dentro do es-
copo do estudo e dos 8 artigos de controle utilizados para a calibração da expressão de 
busca. As informações coletadas de cada publicação seguiram os itens descritos nos 
procedimentos para extração de dados e foram armazenadas em tabelas, conforme o 
exemplo apresentado na Tabela 3, para todos os artigos selecionados. 
Tabela 3 – Exemplo de Informações Extraídas das Publicações Selecionadas 
Dados da publicação 
Referência completa: Collofello, J., Gosalla, B. (1993). “Application of Causal Analysis to the Soft-
ware Modification Process”, Software Practice and Experience, 23(10), pp. 
1095–1105. 
Resumo da publicação 
Os autores sugerem uma adaptação do processo de análise de causas de falhas de software para ativida-
des de manutenção de software. A abordagem proposta de análise de causas aplicada para processos de 
modificação de software é composta pelas seguintes atividades: (1) Obter relatórios de problemas; (2) 
Priorizar problemas; (3) Categorizar faltas; (4) Determinar causas da falta; (5) Desenvolver recomenda-
ções. É apresentado um estudo para avaliar a viabilidade da abordagem. 
Como ocorre a identificação das causas raiz? 
A identificação de causas raiz ocorre na atividade “Determinar causas da falta”, onde sugere-se entrevis-
tar o indivíduo responsável pela inserção do defeito no software. Aconselha-se que a entrevista seja in-
formal para impedir que o indivíduo fique intimidado. Após a obtenção das informações, seleciona-se 
uma categoria para o erro que está sendo analisado. A abordagem propõe sete categorias, específicas 
para a manutenção de software: (1) conhecimento/experiência do sistema, (2) comunicação, (3) impactos 
de software, (4) métodos/padrões, (5) implantação, (6) ferramentas de apoio e (7) erro humano. 
Quais dados dos problemas são utilizados durante a identificação da causa raiz? 
O artigo cita que as seguintes informações devem ser obtidas para cada defeito: tipo de defeito; fase em 
que o defeito foi encontrado; fase em que o defeito foi inserido; causa do defeito; soluções para prevenir 
que o defeito re-ocorra no futuro. 
Quais são as características dos problemas tratados pela Análise de Causas? 
São tratados defeitos/falhas de manutenção de software. No exemplo citado, utiliza como fonte de dados 
um relatório de testes de integração. 
Quais categorias de problema são utilizadas? 
Utiliza uma categorização própria criada especificamente para manutenção de software. Classifica as 
faltas em: (1) defeitos de projeto, (2) incompatibilidade de interface, (3) sincronização incorreta de có-
digo proveniente de projetos paralelos, (4) remendo (patch) incorreto de objetos e (5) insuficiência de 
recursos do sistema. 
Execução em Abril de 2010 - Após o refinamento da abordagem proposta a partir dos 
resultados providos pela execução do estudo baseado em revisão sistemática, decidiu-se 
reexecutar o estudo, a fim de verificar a existência de novas publicações na área. 
Desta forma, a primeira etapa de seleção dos estudos foi reexecutada, utilizando 
a mesma expressão de busca na fonte de dados Scopus. Esta execução retornou 177 pu-
blicações, sendo 25 novas publicações comparadas à execução anterior. A partir da lei-
tura do título e do resumo destas publicações, foram selecionadas 4, de acordo com os 
critérios de inclusão. Para atender à terceira etapa de seleção, as 4 foram lidas comple-
tamente e, destas, somente 1 atendia a, pelo menos, um dos critérios definidos. 
5. Avaliação dos Resultados da Pesquisa 
A partir das informações extraídas das publicações selecionadas para o estudo, foi pos-
sível responder, parcialmente, às questões da pesquisa. 
16
 
Em relação à questão principal da pesquisa, de uma forma geral, as abordagens 
propostas nos trabalhos identificados se centralizam em reuniões nas quais as informa-
ções sobre os problemas são capturadas e analisadas pelos indivíduos mais experientes 
sobre os problemas em questão. Estas reuniões são conduzidas, normalmente, por um 
moderador que emprega alguma técnica de brainstorming ou que guia o grupo com uma 
lista de questões, do tipo “o quê?”, “como?”, “por quê?”, “onde?”, “quem?” etc. Nesta 
reunião, muitas abordagens sugerem a elaboração do Diagrama de Ishikawa [Ishikawa 
1976 citado por Card 2005] como ferramenta para identificar a principal causa raiz de 
determinado problema. 
O objetivo da primeira questão secundária da pesquisa era verificar se havia a-
bordagens que identificassem a causa raiz de uma forma mais objetiva (sistemática). 
Verificou-se em poucos trabalhos esta sistematização. No trabalho de Kim et al. (2008), 
por exemplo, é apresentada uma abordagem automática para identificar relacionamentos 
de causa e efeito por meio de expressões de causalidade, utilizando-se de técnicas de 
processamento de linguagem natural (NLP) e probabilidade. No entanto, esta abordagem 
é específica para o domínio de engenharia (o artigo foi retornado pela Scopus apesar do 
filtro adotado). Outras abordagens apresentam algoritmos específicos da área para tentar 
automatizar a identificação de relacionamentos de causa e efeito; no entanto, não se ve-
rificou sua aplicabilidade para a área de engenharia de software. Além disto, estas abor-
dagens não levam em consideração o aspecto qualitativo da Análise de Causas. 
Para a segunda questão secundária da pesquisa, verificou-se a ausência de in-
formação sobre quais dados são coletados em muitos trabalhos. No entanto, nos traba-
lhos da área de desenvolvimento de software – por exemplo, em [Mays 1990] e [Card 
2005] –, esta informação é normalmente apresentada e envolve os seguintes dados: tipo 
de defeito, fase/atividade na qual o defeito foi inserido, esforço para corrigir, severidade 
etc. Em outras áreas, são capturadas informações sobre: circunstância do evento, deta-
lhes da investigação, discussões sobre as causas raiz, conclusões e recomendações [Dew 
1991] [Latino 2005]. Em Latino (2005), é sugerida a utilização de informações “míni-
mas” para o problema, necessárias para a efetividade da Análise de Causas, propondo o 
método 5-P’s: partes, posição, pessoas, papel e paradigmas. 
A partir da terceira questão secundária da pesquisa, buscava-se identificar os cri-
térios de seleção de problemas a serem analisados pela Análise de Causas. No entanto, 
não foi possível identificar esta informação na maioria das publicações. Nos trabalhos 
nos quais esta informação é apresentada, destaca-se a importância de analisar somente 
os problemas relevantes; no entanto, não é sugerido como fazer esta seleção. Somente 
em um trabalho [Kalinowski et al. 2008], é sugerida a utilização do Gráfico de Pareto 
para esta priorização. Em outro trabalho [Leszak et al. 2000], é sugerida a elaboração de 
critérios para selecionar os problemas a serem analisados, envolvendo, por exemplo, a 
avaliação de quanto o defeito prejudica a organização, o tempo de vida do defeito e a 
complexidade para sua solução. 
Em relação à quarta questão secundária da pesquisa, foi possível verificar que a 
classificação adotada depende da natureza do problema que está sendo analisado. De 
uma forma geral, no contexto de desenvolvimento de software, as seguintes categorias 
foram sugeridas nas abordagens: onde o defeito foi inserido no software (sua origem); 
quando o problema foi detectado; qual o tipo de erro cometido ou qual o tipode defeito 
17
 
introduzido. Dentro deste contexto, o esquema de classificação Orthogonal Defect Clas-
sification (ODC) é sugerido ou adaptado em duas abordagens [Gupta et al. 2009] 
[Shenvi 2009]. Em outros trabalhos ([Dorsch et al. 1997], [Kalinowski et al. 2008], 
dentre outros) é sugerida a classificação adotada pelo Diagrama de Ishikawa, a saber: 
método, pessoas, entrada, ferramentas e organização. 
 Dessa forma, a partir da execução da revisão sistemática, verificou-se a ausência 
de trabalhos que auxiliem a identificação da causa raiz do problema de forma mais ob-
jetiva e ao mesmo tempo preservando a qualidade dos dados capturados. Este fato mo-
tiva estudos mais aprofundados nesta área, para que as organizações consigam identifi-
car as verdadeiras causas de seus problemas e mantenham uma gerência proativa efici-
ente. Este fato corroborou a proposta da abordagem em analisar a causa raiz do pro-
blema utilizando métodos de pesquisa qualitativa (Grounded Theory), por meio da defi-
nição de modelos e passos bem definidos para auxiliar a execução da análise. 
 Sumarizando as contribuições do estudo baseado em revisão sistemática para a 
elaboração e refinamento da abordagem proposta, destacam-se os seguintes itens: (i) 
identificação de abordagens sobre a Análise de Causas de Problemas, a partir das quais a 
abordagem proposta se baseou; (ii) elaboração dos formulários de coleta de dados dos 
problemas a partir das informações sobre quais dados são normalmente capturados ou 
sugeridos para a execução da Análise de Causas. Além das informações pontuais sobre 
os problemas (onde ocorreu, quando, quem identificou etc.), um dos formulários seguiu 
a sugestão das informações mínimas, o método 5-P’s, apresentada por Latino (2005); e 
(iii) estabelecimento da premissa de que a organização deve possuir uma política quanto 
à seleção dos problemas que serão analisados a partir da Análise de Causas, a partir de 
critérios pré-definidos. 
A indisponibilidade de acesso a alguns artigos retornados pode ser considerada 
uma possível limitação deste trabalho, pois pode ter afetado a abrangência dos resulta-
dos obtidos. Tal limitação pode ser resolvida a partir da execução do protocolo do estu-
do em outras máquinas de busca, o que ainda não foi feito. 
6. Considerações Finais 
Este artigo apresentou somente alguns itens do planejamento e execução do estudo ba-
seado em revisão sistemática utilizado como base para a elaboração da abordagem pro-
posta para identificação de causas de problemas utilizando Grounded Theory. Este estu-
do mostrou-se válido para refinar a abordagem proposta, apresentando alguns aspectos 
que não haviam sido identificados anteriormente. 
A abordagem proposta foi avaliada a partir de um estudo de viabilidade e há in-
dícios de que seja viável para problemas complexos e críticos para uma organização 
[Schots et al. 2010] [Schots 2010]. Durante a avaliação, melhorias na abordagem foram 
identificadas e trabalhos futuros foram definidos. 
Como trabalhos futuros, espera-se que, a partir da evolução da abordagem, ree-
xecuções periódicas do estudo baseado em revisão sistemática sejam conduzidas a fim 
de fornecer mais subsídios para esta evolução. 
18
 
Referências 
BASILI, V., ROMBACH, H., 1988, "The Tame Project: Towards Improvement-Oriented Soft-
ware Environments", IEEE Transactions on Software Engineering, v. 14, n. 6, pp. 758-773. 
BIOLCHINI, J., MIAN, P. G., NATALI, A. C. C., TRAVASSOS, G. H., 2005, “Systematic 
Review in Software Engineering”, Relatório Técnico COPPE/UFRJ. 
CARD, D., 2005, “Defect Analysis: Basic Techniques for Management and Learning”, Ad-
vances in Computers, vol. 65, pp. 259-295. 
COLLOFELLO, J. S., GOSALIA B. P., 1993, “An Application of Causal Analysis to the Soft-
ware Modification Process”, Software-Practice and Experience, v. 23, n. 10, pp. 1095-1105, 
October. 
DEW, J. R., 1991, “In Search of the Root Cause”. Quality Progress, vol. 24, n. 3, pp. 97-102. 
DORSCH, J. J., YASIN M. M., CZUCHRY A., 1997, “Application of Root Cause Analysis in a 
Service Delivery Operational Environment: a Framework for Implementation”, International 
Journal of Service Industry Management, vol. 8, n. 4, pp. 268-289. 
ENDRES, A., 1975, “An Analysis of Errors and their Causes in System Program”, IEEE Trans-
actions on Software Engineering, SE-1, pp. 140-149. 
GUPTA, A., LI. J., CONRADI R., RONNEBERG, H., LANDRE, E., 2009, “A Case Study 
Comparing Defect Profiles of a Reused Framework and of Applications Reusing it”, Em-
pirical Software Engineering, vol. 14, n. 2, pp. 227-255. 
GRADY, R. B., 1996, “Software Failure Analysis for High return Process Improvement Deci-
sions”, Hewlett-Packard Journal, v. 47, n. 4, pp. 15 – 24, August. 
KALINOWSKI, M., TRAVASSOS, G. H., CARD, D. N., 2008, “Towards a Defect Prevention 
Based Process Improvement Approach”. 34th Euromicro Conference on Software Engi-
neering and Advanced Applications (SEAA), pp. 199-206, Parma, Italy, September. 
KIM, S., AURISICCHIO, M., WALLACE, K., 2008, “Towards Automatic Causality Boundary 
Identification from Root Cause Analysis Reports”, Journal of Intelligent Manufacturing, pp. 
1-11. 
LATINO, R. J., 2005, “The Application of PROACT® RCA to Terrorism/Counter Terrorism 
Related Events”, Lecture Notes in Computer Science, pp. 579-589. 
LESZAK, M., PERRY, D., STOLL, D., 2000, “A Case Study in Root Cause Defect Analysis”. 
International Conference on Software Engineering (ICSE 2000), pp. 428-437, Limerick, 
Ireland, June. 
MAYS, R.G., 1990, “Applications of Defect Prevention in Software Development”, IEEE 
Journal on Selected Areas in Communications, vol. 8, n. 2, pp. 164-168. 
ROONEY, J., HEUVEL, L., 2004, “Root Cause Analysis for Beginners”, Quality Progress, pp. 
45-53, July. 
SILVA FILHO, R. C., 2006, Uma Abordagem para Avaliação de Propostas de Melhoria em 
Processos de Software. Dissertação de M.Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil. 
SANTOS, G., 2008, Ambientes de Engenharia de Software Orientados à Corporação. Tese de 
D. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil. 
SHENVI, A. A., 2009, “Defect Prevention with Orthogonal Defect Classification”, Proceedings 
of the 2nd India Software Engineering Conference (ISEC 2009), pp. 83-87, Pune, India, Feb-
ruary. 
SCHOTS, N. C. L., 2010, Uma Abordagem para a Identificação de Causas de Problemas Utili-
zando Grounded Theory. Dissertação de M.Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil. 
SCHOTS, N. C. L., ROCHA, A. R., SANTOS, G., 2010, “Uma Abordagem para a Identificação 
de Causas de Problemas utilizando Grounded Theory”. In: XXXVI Conferencia 
Latinoamericana de Informatica (CLEI 2010), Assunción, Paraguay. A ser publicado. 
STRAUSS, A., CORBIN, J. M., 1998, “Basics of Qualitative Research: Techniques and Proce-
dures for Developing Grounded Theory”, Second Edition, Sage Publications. 
19
 
Estudo baseado em Evidências sobre Dificuldades, Fatores 
e Ferramentas no Gerenciamento da Comunicação em 
Projetos de Desenvolvimento Distribuído de Software 
Alinne C. Corrêa dos Santos¹, Camila Cunha Borges¹, David E. S. Carneiro¹, 
Fabio Q. B. da Silva¹ 
1 Centro de Informática – Universidade Federal de Pernambuco (CIN – UFPE) 
CEP 50732-970 – Recife – PE – Brasil 
{accs,ccb2,fabio,desc}@cin.ufpe.br 
Abstract. This paper presents the difficulties, factors and tools of 
communication management in projects of Distributed Software Development 
(DSD) identified by a systematic literature review, which can be especially 
useful for project managers and distributed teams. This paper comprises a 
description of the process of systematic literature review, and a 
systematization and evaluation of results. 
Resumo. Este artigo apresenta as dificuldades, os fatores e ferramentas da 
gestãoda comunicação em projetos de Desenvolvimento Distribuído de 
Software (DDS), identificados por meio de uma Revisão Sistemática da 
Literatura, sendo especialmente útil para apoio aos gerentes de projeto e às 
equipes distribuídas. Este artigo compreende uma descrição do processo da 
Revisão Sistemática da Literatura, sistematização e avaliação dos resultados. 
1. Introdução 
Nos últimos anos, muitos projetos estão sendo desenvolvidos por profissionais 
espalhados em diferentes lugares, sendo possível notar, na última década, um aumento 
significativo desta abordagem, conhecida como Desenvolvimento Distribuído de 
Software (DDS). Existem inúmeras razões para essa popularização: redução dos custos 
de produção, ganhos de escala, acesso aos recursos especializados, redução do tempo de 
colocação no mercado, melhoria na qualidade e acesso a novos mercados [Katainen e 
Nahar 2008], [Prikladnicki 2003]. Embora muitas organizações viessem executando 
projetos com equipes distribuídas, apenas algumas delas têm eficácia nas práticas 
estabelecidas para apoiar os gestores e desenvolvedores que trabalham neste novo 
ambiente [Binder 2007]. 
Inserido neste contexto, este artigo apresenta através de uma revisão sistemática 
da literatura, as dificuldades na gestão da comunicação, os fatores identificados nas 
equipes durante o processo de comunicação que influenciam os projetos de DDS e 
ferramentas relatadas em comunidades científicas confiáveis, que são evidenciadas 
como eficazes no apoio à comunicação para a gestão de projetos de DDS. Esta revisão 
sistemática da literatura seguirá as diretrizes definidas por Kitchenham (2007); 
Travassos e Biolchini (2007), para responder às seguintes questões: 
(RQ1) Quais são as principais dificuldades na gestão da comunicação em 
projetos de Desenvolvimento Distribuído de Software? 
20
 
(RQ2) Quais são os principais fatores identificados nas equipes que influenciam 
o processo de comunicação em projetos de Desenvolvimento Distribuído de Software? 
(RQ3) Quais são as melhores ferramentas e práticas a serem adotadas na 
comunicação das equipes em projetos de Desenvolvimento Distribuído de Software? 
2. Revisão Sistemática da Literatura 
As revisões sistemáticas da literatura (Systematic Literature Review) são parte do 
paradigma de práticas baseadas em evidências de uma forma sistemática e transparente. 
Kitchenham (2007) resume as etapas de uma revisão sistemática da literatura em três 
fases principais: Planejamento da revisão, Condução da revisão e Apresentação dos 
resultados. O primeiro passo para realizar essa revisão foi a definição do protocolo, que 
descreve o plano de pesquisa em detalhes nas seguintes subseções. 
 
2.1. Termos de Pesquisa 
Os termos de pesquisa utilizados nesta revisão foram gerados a partir das perguntas de 
pesquisa e da combinação dos termos chave e sinônimos (Tabela 1). 
Tabela 1. String de Busca. 
Comunicação AND (Communication OR Communication Management) 
Desenvolvimento Distribuído 
de Software (Distributed software development OR Global software OR …) 
Dificuldades AND (Challenge OR Difficult OR …) 
Equipes de Software AND (Software teams OR Software group OR …) 
Ferramentas (Tool OR Technique OR ... ) 
 
2.2. Fontes de Busca 
A busca foi realizada apenas em fontes de busca e/ou bibliotecas digitais disponíveis na 
Internet e que possui parceria com a Universidade Federal de Pernambuco: IEEEXplore 
Digital Library, ACM Digital Library, ScienceDirect, EI Compendex e Scopus. 
 
2.3. Processo de Seleção dos Estudos Primários 
Após a execução da consulta, os documentos resultantes foram selecionados 
independentemente por dois pesquisadores diferentes, de acordo com o procedimento 
descrito a seguir: 
Tabela 2. Fases do Processo de Seleção dos Estudos. 
Fase 1 Leitura independente dos títulos e resumos dos estudos por parte dos dois pesquisadores. 
Fase 2 Leitura independente do resumo e da conclusão dos estudos selecionados na Fase 1. 
Fase 3 Análise e validação dos artigos para eliminação de duplicações e leitura completa dos estudos 
selecionados pelos pesquisadores. 
Fase 4 Preenchimento independente da ficha de avaliação de cada estudo pelos pesquisadores 
 
2.4. Critérios de Seleção dos Estudos Primários 
A inclusão de um trabalho é determinada pela relevância, em relação às questões de 
investigação, determinadas pela análise do título, abstract e conclusão. Os critérios de 
seleção utilizados podem ser vistos na Tabela 3. 
 
21
 
Tabela 3. Critérios de Seleção dos Estudos. 
O artigo deve... 
(1) ... estar disponível entre os recursos selecionados (5) ... descrever claramente sua metodologia 
(2) ... ser escrito em inglês (6) ... ter dados suficientes para análise. 
(3) ... ter algum estudo envolvendo Gestão da 
comunicação em DDS 
(7) ... estar completo 
(4) ... apresentar alguma influência da comunicação em 
projetos de DDS 
(8) ... ser original (não possuir duplicações) 
 
2.5. Extração dos Dados 
As buscas primárias realizadas durante 4 messes retornaram um total de 6835 trabalhos, 
e 118 foram considerados potencialmente relevantes para a pesquisa. Com a leitura do 
resumo e conclusão, e utilizando os critérios de inclusão/exclusão, 85 estudos foram 
excluídos, chegando ao total de 33estudos primários (Tabela 4). 
Tabela 4. Seleção dos Estudos. 
Fontes Resultados Estudos Relevantes 
Não 
Relevantes Repetidos Incompletos 
Estudos 
Primários 
IEEEXplore 114 22 8 0 0 14 
ACM 51 11 4 2 1 4 
ScienceDirect 2991 21 15 2 0 4 
EI Compendex 3245 41 18 9 8 6 
Scopus 434 23 12 1 5 5 
TOTAL 6835 118 59 14 14 33 
 Esta revisão sistemática da literatura não restringiu o período de publicações, 
embora todos os estudos selecionados foram realizados entre 1998 e 2008, retratando 
assim a relevância desta abordagem. A partir dos 33 estudos selecionados, 27 (82%) são 
Estudos Empíricos, 4 (12%) Estudos Teóricos e 2 (6%) são Relatos de Experiências 
Industriais, dentre estes nenhuma revisão sistemática da literatura foi identificada. 
 Para a avaliação da qualidade dos estudos é usada a escala Likert, a qual abrange 
cinco características: a validade da investigação, as ameaças à validade, a pertinência, a 
aplicabilidade e a consistência das evidências. Para validar as características citadas foi 
criado um formulário com 18 questões, o qual foi preenchido por ambos pesquisadores 
para cada estudo selecionado, a fim de obter respostas para as questões de investigação. 
Os estudos avaliados podem se enquadrar em 5 níveis de qualidade: Ótimo, Bom, 
Regular, Ruim e Péssimo. De acordo com o grau de classificação 14 estudos foram 
classificados como Ótimo; 17 estudos como Bom; 2 como Regular e nenhum estudo foi 
classificado como Ruim ou Péssimo, o que significa que as evidências encontradas 
possuem um nível razoável de confiabilidade. 
 Com o preenchimento finalizado, cada formulário foi comparado e discutido por 
ambos os pesquisadores, a fim de organizar a extração, análise e síntese dos dados. Para 
tal organização foi adotada a ferramenta Mendeley Desktop, que permite uma visão 
geral dos dados coletados e dos documentos das fontes de busca ou bibliotecas digitais, 
facilitando o processo de revisão da literatura. 
3. Trabalhos Relacionados 
Para o planejamento desta revisão foi realizada uma análise de 5 revisões sistemáticas 
existentes no contexto de DDS, para justificar a necessidade da execução da presente 
22
 
revisão. Tendo em vista isso, serão discutidas as abordagens das revisões identificadas 
na Literatura. 
Na revisão de Miguel Jiménez et. al (2009), foram selecionados 78 estudos 
primários no período de 2000 a 2008, onde foram identificados 10 desafios no 
desenvolvimento de software distribuído, dentre os quais merece destaque a 
comunicação, bem como 10 fatores de sucesso. O número de estudosselecionados foi 
significativo, devido ser uma abordagem mais abrangente e evidenciada na literatura. 
No entanto, a revisão realizada por Miguel Jiménez et. al (2009) apresenta um foco 
diferente da revisão descrita neste trabalho, pois a comunicação é apresentada como um 
dos desafios enfrentados no desenvolvimento de software distribuído, enquanto que está 
revisão está focada exclusivamente no gerenciamento da comunicação no contexto 
distribuído, o que justifica a diferença da quantidade de estudos selecionados por estas 
revisões. 
Na revisão de Catarina Costa et. al (2010), foram selecionados 25 estudos 
primários no período de 2001 a 2009, onde foram identificado 11 modelos e 24 
ferramentas eficazes para o gerenciamento de desenvolvimento de software distribuído. 
Apesar de resultados satisfatórios, esta revisão teve como foco principal a identificação 
de modelos e ferramentas utilizadas para apoiar a gestão de projetos de desenvolvimento 
de software distribuído, onde algumas das ferramentas identificadas por Catarina Costa 
et. al (2010) diferem das ferramentas identificadas pela presente revisão, devido o foco 
voltado para a gerenciamento da comunicação. 
Na revisão de Rodrigo Rocha et. al (2010), foram selecionados 8 estudos 
primários no período de 2000 a 2009, onde foram identificados 8 modelos de 
colaboração utilizados pela indústria e/ou academia para desenvolver software no 
contexto distribuído, tendo como base o ciclo de vida básico do desenvolvimento 
tradicional de software. Apesar desta revisão ter seguido uma metodologia rigorosa, a 
mesma possui algumas limitações, como a quantidade de estudos da revisão sistemática 
da literatura, tendo como resultado somente 8 estudos, bem como não fizeram relação 
ao tema abordado pela presente revisão. 
Na revisão de C. Costa et. al (2010), foram selecionados 54 estudos primários, 
onde foram identificados um conjunto de desafios e boas práticas para o gerenciamento 
de projetos de software em DDS. De acordo com esta revisão foram identificadas 30 
desafios, onde alguns destes foram identificados na revisão realizada por Miguel 
Jiménez et. al (2009) e 31 práticas eficazes para o gerenciamento de projetos, onde a 
maioria das boas práticas sugeridas são para superar os desafios de comunicação em 
DDS, como diferenças culturais, a coordenação, as diferenças de fuso horário, a 
colaboração e a confiança, confirmando alguns resultados obtidos pela presente revisão. 
Na revisão de Alinne Santos et. al (2010), foram selecionados 33 estudos 
primários, onde foram identificados as dificuldades enfrentadas na gestão da 
comunicação, os fatores encontrados nas equipes que influenciam o processo de 
comunicação e as ferramentas utilizadas no gerenciamento da comunicação em projetos 
de DDS. De acordo com esta revisão foram identificados 9 dificuldades, 7 fatores e 18 
ferramentas no gerenciamento da comunicação em projetos de DDS. Apesar desta 
revisão ter seguido uma metodologia rigorosa, a mesma não apresentou a relação entre 
os resultados obtidos, bem como suas respectivas implicações. 
 Nas revisões discutidas acima, assim como nas demais identificadas na literatura 
como Darja Smite et. al (2008), Emam Hossain et. al (2009), Siffat Khan et. al (2009), 
23
 
Siffat Ullah Khan et. al (2009), John Stouby Persson et. al (2009) e Thaís Ebling et. al 
(2009), ficou evidente que estas possuem abordagens distintas desta revisão, as quais 
podem ser percebidas, por exemplo na revisão de C. Costa et. al (2010), a qual 
selecionou 54 estudos referentes aos desafios e boas práticas para o gerenciamento de 
projetos de DDS, onde desses 54 estudos, somente 4 também foram identificados nesta 
revisão, justificando a necessidade da mesma. Portanto, de acordo com as revisões 
identificadas estas estão voltadas para o desenvolvimento de software ou gerenciamento 
de projetos no contexto de DDS, justificando a necessidade desta revisão que contempla 
as dificuldades, os fatores identificados nas equipes, bem como suas respectivas 
relações com as ferramentas voltadas para o gerenciamento da comunicação. 
4. Resultados 
Entre os estudos selecionados, foram encontradas evidências relevantes que respondem 
de forma satisfatória às três questões de investigação. As dificuldades existentes na 
gestão da comunicação no DDS foram discutidas em 25 dos 33 estudos selecionados, 
onde a maioria dos estudos evidenciou as dificuldades enfrentadas na Gestão da 
comunicação no ambiente distribuído, as quais podem ser associadas com as boas 
práticas para melhorar a gestão da comunicação apresentadas na revisão sistemática 
realizada por C. Costa et.al (2010). A Tabela 6 detalha cada dificuldade de acordo com 
os estudos primários, sendo notável que as principais dificuldades concentram-se em 
torno das Diferenças Culturais e Dispersão Geográfica, seguido pelo fuso-horário 
confirmando com os resultados obtidos por Junior (2009). 
Tabela 6. Dificuldades na Gestão da Comunicação 
Dificuldades Estudos Primários 
D1. Diferenças Culturais [EP4], [EP5], [EP9], [EP10], [EP14], [EP17], [EP18], [EP19], [EP20], [EP22], [EP24], [EP25], [EP26], [EP30], [EP31], [EP33] 
D2. Dispersão Geográfica [EP4], [EP9], [EP14], [EP17], [EP20], [EP22], [EP24], [EP25], [EP30], [EP31], [EP32], [EP33] 
D3. Diferença de fuso horário [EP9], [EP14], [EP20], [EP22], [EP24], [EP25], [EP30], [EP31] 
D4. Reunião face-to-face [EP9], [EP13], [EP14] 
D5. Gerenciamento do time [EP28], [EP31], [EP32], [EP33] 
D6. Sobrecarga de informações [EP14], [EP15], [EP17], [EP26] 
D7. Atraso da informação [EP3], [EP9], [EP10], [EP14], [EP15], [EP24], [EP26] 
D8. Meio de comunicação 
deficiente [EP9], [EP14], [EP15], [EP27] 
D9. Planejamento da Comunicação [EP1], [EP2], [EP3], [EP5], [EP18], [EP29], [EP32], [EP33] 
Os principais fatores identificados nas equipes que influenciam o processo de 
comunicação no ambiente distribuído foram discutidos em 28 dos 33 estudos 
selecionados (Tabela 7). No entanto, este estudo não encontrou provas suficientes para 
detalhar o que trata a satisfação do trabalho bem como a personalidade. 
Tabela 7. Fatores identificados nas equipes de software.
Fatores Estudos Primários 
FA1. Fatores sociais (Confiança, interação, integração, 
motivação, cooperação e coesão) 
[EP2], [EP3], [EP4], [EP6], [EP10], 
[EP11], [EP14], [EP15], [EP16], [EP17], 
[EP18], [EP19], [EP21], [EP23], [EP24], 
[EP26], [EP28], [EP32], [EP33] 
FA2. Falta de confiança na língua nativa [EP5], [EP9], [EP14], [EP15], [EP16], 
24
 
[EP18], [EP19], [EP20], [EP21], [EP22], 
[EP27], [EP33] 
FA3. Dificuldade de expressão [EP9], [EP14], [EP18], [EP22], [EP24], [EP25], [EP30], [EP31] 
FA4. Preferências meios de comunicação baseada em texto [EP5], [EP10], [EP29] 
FA5. Satisfação no trabalho [EP9], [EP16], [EP17] 
FA6. Conhecimentos técnicos [EP18], [EP19], [EP23], [EP24], [EP33] 
FA7. Personalidade [EP14], [EP19], [EP23], [EP24], [EP26] 
 As principais ferramentas adotadas no processo de comunicação no ambiente 
distribuído foram discutidas em 28 dos 33 estudos selecionados (Tabela 8). 
Tabela 8. Ferramentas utilizadas no processo de comunicação. 
Ferramentas Estudos Primários 
FE1. Aúdio Conferência (teleconferência, 
chamadas de conferência ou conferência 
via Internet) 
[EP5], [EP9], [EP11], [EP12], [EP14], [EP19], [EP20], 
[EP21], [EP22], [EP27], [EP31], [EP32] 
FE2. Telefone [EP3], [EP5], [EP9], [EP11], [EP14], [EP15], [EP27], 
FE3. Video conferência [EP1], [EP5], [EP8], [EP10], [EP11], [EP14], [EP24] 
FE4. NetMeeting [EP9], [EP15], [EP25] 
FE5. Chat ou Messenger [EP5], [EP6], [EP8], [EP9], [EP11], [EP18], [EP24], [EP26], [EP27], [EP28], [EP29] 
FE6. Conferência de Dados [EP1], [EP11] 
FE7. VOIP [EP5], [EP9] 
FE8. Compartilhamento de documentos [EP9], [EP10], [EP12], [EP18],[EP26], [EP27] 
FE9. Fóruns [EP5], [EP18], [EP24] 
FE10. Intranet ou websites [EP2], [EP5], [EP9], [EP11], [EP12] 
FE11. Wiki [EP12] 
FE12. E-mail 
[EP1], [EP3], [EP4], [EP5], [EP6], [EP8], [EP9], 
[EP10], [EP12], [EP13], [EP14], [EP15], [EP18], [EP19], 
[EP20], [EP21], [EP22], [EP26], [EP29], [EP31], [EP32] 
FE13. PowerPoint [EP11], [EP12] 
FE14. Calendários [EP5], [EP9] 
FE15. Fax [EP14] 
FE16. Collanos [EP27] 
FE17. Bugzilla [EP15] 
FE18. TeamSpace [EP7] 
A partir das dificuldades, fatores e ferramentas identificadas na literatura na 
Tabela 9 são apresentadas as principais ferramentas utilizadas para minimizar as 
dificuldades encontradas. 
Tabela 9. Relação entre Dificuldades e Ferramentas 
Dificuldades Ferramentas Estudos Primários 
D1. Diferenças Culturais 
FE1, FE2, FE3, FE4, FE5, 
FE7,FE8, FE9, FE10, FE12, 
FE14, FE15 
[EP4], [EP5], [EP9], [EP10], 
[EP14], [EP18], [EP19], [EP20], 
[EP22], [EP24], [EP25], [EP26], 
[EP31] 
D2. Dispersão Geográfica 
FE1, FE2, FE3, FE4, FE5, 
FE7, FE8, FE10, FE12, FE14, 
FE15 
[EP4], [EP9], [EP14], [EP20], 
[EP22], [EP24], [EP25], [EP31], [EP32] 
D3. Diferença de fuso 
horário 
FE1, FE2, FE3, FE4, FE5, 
FE7, FE8, FE10, FE12, FE14, 
[EP9], [EP14], [EP20], [EP22], 
[EP24], [EP25], [EP31] 
25
 
FE15 
D4. Reunião face-to-face FE1, FE2, FE4, FE5, FE7, FE8, FE10, FE12, FE14, FE15 [EP9], [EP14] 
D5. Gerenciamento do time FE1, FE5, FE12 [EP28], [EP31], [EP32], 
D6. Sobrecarga de 
informações 
FE1, FE2, FE3, FE4, FE5, 
FE8, FE12, FE15, FE17 [EP14], [EP15], [EP26] 
D7. Atraso da informação 
FE1, FE2, FE4, FE5, FE7, 
FE8, FE10, FE12, FE14, 
FE15, FE17 
[EP3], [EP9], [EP10], [EP14], 
[EP15], [EP24], [EP26] 
D8. Meio de comunicação 
deficiente 
FE1, FE2, FE4, FE5, FE7, 
FE8, FE10, FE12, FE14, 
FE15, FE16, FE17, 
[EP9], [EP14], [EP15], [EP27] 
D9. Planejamento da 
Comunicação 
FE1, FE2, FE3, FE5, FE7, 
FE8, FE9, FE10, FE12, FE14, 
[EP1], [EP2], [EP3], [EP5], [EP18], 
[EP29], [EP32], 
A Tabela 10 apresenta a relação entre os fatores identificados nas equipes e as 
ferramentas utilizadas. 
Tabela 10. Relação entre Fatores e Ferramentas. 
Fatores Ferramentas Estudos Primários 
FA1. Fatores sociais 
(Confiança, interação, 
integração, motivação, 
cooperação e coesão) 
FE1, FE2, FE3, FE4, FE5,FE8, 
FE9, FE10, FE12, FE13, FE15, 
FE17 
[EP1], [EP6], [EP15], [EP10], [EP11], 
[EP14], [EP15], [EP16], [EP18], [EP19], 
[EP21], [EP24], [EP26], [EP28], [EP32] 
FA2. Falta de confiança na 
língua nativa 
FE1, FE3, FE4, FE5, FE7, 
FE8, FE9, FE10, FE12, FE14, 
FE15, FE16, FE17, 
[EP5], [EP9], [EP14], [EP15], [EP18], 
[EP19], [EP20], [EP21], [EP22], [EP27], 
FA3. Dificuldade de 
expressão 
FE1, FE2, FE3, FE4, FE5, 
FE7, FE10, FE12, FE14, FE15 
[EP9], [EP14], [EP22], [EP24], [EP25], 
[EP31] 
FA4. Preferências meios de 
comunicação baseada em 
texto 
FE1, FE2,FE3, FE5, FE7, FE8, 
FE9, FE10, FE12, FE14 [EP5], [EP10], [EP29] 
FA5. Satisfação no trabalho FE1, FE2, FE4, FE5, FE7, FE8, FE9, FE10, FE12, FE14 [EP9] 
FA6. Conhecimentos 
técnicos 
FE1, FE3, FE5, FE8, FE9, 
FE12 [EP18], [EP19], [EP24] 
FA7. Personalidade FE1, FE2, FE3, FE5, FE8, FE9, FE12, FE15 [EP14], [EP19], [EP24], [EP26] 
4. Considerações Finais 
Esta pesquisa apresenta as dificuldades identificadas na gestão da comunicação, os 
fatores identificados nas equipes e as ferramentas utilizadas no processo de 
comunicação em DDS. Esses resultados foram identificados por meio de uma revisão 
sistemática da literatura realizada no período de agosto à novembro de 2009, 
envolvendo 33 trabalhos, publicados entre 1998 e 2008. Uma possível explicação por 
não ter estudos relevantes em 2009 é que as publicações e trabalhos relevantes ainda não 
foram indexados nas fontes de busca. 
De acordo com os estudos selecionados, as maiores dificuldades enfrentadas na 
gestão da comunicação foram as Dificuldades Culturais e a Dispersão Geográfica, tendo 
uma influência significativa dos fatores sociais e da falta de confiança na língua nativa 
26
 
identificados nas equipes. Algumas das dificuldades identificadas podem ser 
amenizadas por meio das ferramentas como audioconferência, email, entre outros. 
 Como trabalhos futuros pretende-se sugerir um conjunto de práticas para 
melhorar a gestão de comunicação; pesquisas mais aprofundadas a fim de abranger uma 
amostra mais significativa de estudos, o que permitirá análises mais amplas e 
comparação entre os estudos e a validação desta revisão por meio de uma pesquisa de 
campo a fim de comparar e confirmar os resultados identificados na literatura por mei 
da prática para tornar o processo de comunicação para o DDS mais consistente. 
Referências 
Alinne C. Corrêa dos Santos, Camila Cunha Borges, Fabio Q. B. da Silva, David E. S. 
Carneiro. (2010) Dificuldades, Fatores e Ferramentas no Gerenciamento da 
Comunicação em projetos de Desenvolvimento Distribuído de Software: uma 
Revisão Sistemática da Literatura. IV Workshop de Desenvolvimento Distribuído de 
Software, Salvador, BA. 
Binder, J. (2007). “Global Project Management: Communication, Collaboration and 
Management Across Borders”. Gower Publishing. 
Catarina Costa, Camila Cunha, Rodrigo Rocha, A. César. França, Fabio Q. B. da Silva, 
Rafael Prikladnicki. (2010). "Models and Tools for Managing Distributed Software 
Development: A Systematic Literature Review",14th International Conference on 
Evaluation and Assessment in Software Engineering. 
 C. Costa, R. Rocha, F. Q. B. da Silva, R. Prikladnicki. (2010). Desafios e Boas Práticas 
para o Gerenciamento de Projetos no Desenvolvimento Distribuído de Software. IV 
Workshop de Desenvolvimento Distribuído de Software, Salvador, BA. 
Darja Smite, Claes Wohlin, Robert Feldt, Tony Gorschek. (2008). “Reporting Empirical 
Research in Global Software Engineering: a Classification Scheme”. IEEE 
International Conference on Global Software Engineering (ICGSE’08). 
Emam Hossain, Muhammad Ali Babar, Hye-young Paik (2009). “Using Scrum in 
Global Software Development: A Systematic Literature Review”. IEEE International 
Conference on Global Software Engineering (ICGSE’09). 
John Stouby Persson, Lars Mathiassen, Jesper Boeg, Thomas Stenskrog Madsen, 
Flemming Steinsonet. (2009). “Managing Risks in Distributed Software Projects: An 
Integrative Framework”. IEEE Transactions on Engineering Management, 56:3. 
Junior, I.; Azevedo, R. Dantas, E.; Rocha, R.; Veras, W.; Freitas, F.; Gomes, J. (2009) 
Proposta de Boas Práticas no Processo de Comunicação em Projetos Distribuídos. III 
Workshop de Desenvolvimento Distribuído de Software, Fortaleza, CE. 
Katainen, T.; Nahar, N. (2008) “Using methods and IT tools innovatively for the 
management of International IS development projects” Proc. Portland International 
Conference on Management of Engineering. Technology PICMET, 1851-1863. 
Kitchenham, B. (2007) “Guidelines for performing Systematic Literature Reviews in 
Software Engineering”, V 2.3 EBSE Technical Report, EBSE-01. 
Miguel Jiménez, Mario Piattini, Aurora Vizcaíno. (2009). “Challenges and 
Improvements in Distributed Software Development: A Systematic Review”. Journal 
Advances in Software Engineering, 1-13. 
27
 
Prikladnicki, R. (2003) “MuNDDoS - Um modelo de referência para desenvolvimento 
distribuído de software” Dissertação de Mestrado, PUC/RS, Porto Alegre, RS, Brasil. 
Rodrigo Rocha, Catarina Costa, Rafael Prikladnicki, Ryan Ribeiro de Azevedo, Ivaldir 
H. F. Junior, Silvio Meira (2010). Modelos de Colaboração no Desenvolvimento 
Distribuído de Software: uma Revisão Sistemática da Literatura. IV Workshop de 
Desenvolvimento Distribuído de Software, Salvador, BA. 
Siffat Ullah Khan, Mahmood Niazi, Rashid Ahmad. (2009).