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).“Critical Success Factors 
for Offshore Software Development Outsourcing Vendors: A Systematic Literature 
Review”. IEEE International Conference on Global Software Engineering 
(ICGSE’09). 
Siffat Khan, Mahmood Niazi, Rashid Ahmad. (2009). “Critical Barriers for Offshore 
Software Development Outsourcing Vendors: A Systematic Literature Review”. 
Asia-Pacific Software Engineering Conference (ASPEC’09). 
Thaís Ebling, Jorge Luis Nicolas Audy, Rafael Prikladnicki. (2009). “A Systematic 
Literature Review of Requirements Engineering in Distributed Software 
Development Environments”. Proceedings of the International Conference on 
Enterprise Information Systems (ICEIS), Milano, Italy. 
Travassos, G.; Biolchini J. (2007) “Revisões Sistemáticas Aplicadas a Engenharia de 
Software” In: XXI SBES - Brazilian Symposium on Software Engineering, João 
Pessoa, PB, BrasilFurther Reading. 
Apêndice: Estudos Primários 
[EP1] Lee, L.; Wei, W.“Breakdown Analysis on Distributed Group Communication”. 9th International 
Conference on Computer Supported Cooperative Work in Design Proceedings, 2005. 
[EP2] Plan, R.; Piri A. “Challenges of Globally Distributed Software Development – Analysis of 
Problems Related to Social Processes and Group Relations”. IEEE International Conference on Global 
Software Engineering, 2008:264-268. 
[EP3] Korkala, M. Abrahamsson, P. “Communication in Distributed Agile Development: A Case Study”. 
Conference on Software Engineering and Advanced Applications, 2007. 
[EP4] Wareham, J.; Mahnke, V.; Peters, S.;Bjorn-Andersen, N. “Communication Metaphors-in-Use: 
Technical Communication and Offshore Systems Development”. IEEE Transactions on Professional 
Communication, 2007:50(2):93-108. 
[EP 5] Piri, A.; Lassenius, C. “Factors Affecting Audio and Text-based Communication Media Choice in 
Global Software Development Projects”. Fourth IEEE International Conference on Global Software 
Engineering, 2009. 
[EP6] Nguyen, T.; Wolf, T.; Damian, D. “Global software development and delay: Does distance still 
matter?” IEEE International Conference on Global Software Engineering, 2008:45-54. 
[EP7] Geyer, W.; Richter, H.; Fuchs, L. et al. “A Team Collaboration Space Supporting Capture and 
Access of Virtual Meetings”. ACM, 2001:188-196. 
[EP8] Ocker, R. “Communication Differences in Virtual Design Teams: Findings from a Multi-Method 
Analysis of High and Low Performing Experimental Teams”. The Data Base for Advances in 
Information Systems, 2008:39( 1):51-67. 
[EP9] Thissen, M.; Page, J.; Bharathi, M.; Austin, T. “Communication Tools for Distributed Software 
Development Teams”. ACM, 2007 : 28-35. 
[EP10] Taweel, A.; Delaney, B.; Arvanitis, T.; Zhao, L. “Communication, Knowledge and Co-ordination 
Management in Globally Distributed Software Development Informed by a scientific Software 
Engineering Case Study”. Fourth IEEE International Conference on Global Software Engineering, 
2009:370-375. 
[EP11] Oshri, I.; Kotlarsky, J.; Willcocks, L. “Global software development: Exploring socialization and 
face-to-face meetings in distributed strategic projects”. Journal of Strategic Information Systems, 
2007:16:25-49. 
28
 
[EP12] Almeida, A.; Junior, I. “Managing Communication among Geographically Distributed Teams: a 
Brazilian Case”. Springer Berlin Heidelberg, 2009:35:130-135. 
[EP13] Calefato, F. 2007 “An Empirical Investigation on Text-Based Communication in Distributed 
Requirements WorkshoEP. International Conference on Global Software Engineering (ICGSE’07). 
[EP14] Mcdonough, E.; Kahn, K. “Managing Communication in Global Product Development Teams”. 
IEEE Transactions on Engineering Management, 1999;46(4):375-386. 
[EP15] Damian, D.; Izquierdo, L.; Singer, J.; Kwan, I. 2007 “Awareness in the Wild: Why 
Communication Breakdowns Occur”. International Conference on Global Software Engineering 
(ICGSE’07). 
[EP16] Gowda, R. 2006 “Comparison of Selected Survey Instruments for Software Team Communication 
Research”. International Conference on Global Software Engineering (ICGSE’06). 
[EP17] Egan, R.; Tremaine, M.; Fjermestad, J.; Milewski, A. 2006 “Cultural Differences in Temporal 
Perceptions and its Application to Running Efficient Global Software Teams”. International 
Conference on Global Software Engineering (ICGSE’06). 
[EP18] Serce, F.; Brazile, R.; Schumacker, R. “Exploring Collaboration Patterns among Global Software 
Development Teams”. Fourth IEEE International Conference on Global Software Engineering, 
2009:61-70. 
[EP19] Huang, H.; Trauth, E. “Cultural Influences and Globally Distributed Information Systems 
Development: Experiences from Chinese IT Professionals”. Communications of the ACM. 2007:36-
45. 
[EP20] Lee-kelley, L.; Sankey, T. “Global virtual teams for value creation and project success: A case 
study”. International Journal of Project Management, 2008:26:51-62. 
[EP21] Shirani, A.; Tafti, M.; Affisco, J. “Task and technology fit: a comparison of two technologies for 
synchronous and asynchronous group communication”. Information & Management, 199:36:19-50. 
[EP22] Prikladnicki, R.; Evaristo, R.; Damian, D.; Audy, J. “Conducting Qualitative Research in an 
International and Distributed Research Team: Challenges and Lessons Learned”. International 
Conference on System Sciences, 2008:1-10. 
[EP23] Maier, A.; Kreimeyer, M.; Hepperle, C.; Eckert, C.; Lindemann, U.; Clarkson, J. “Exploration of 
Correlations between Factors Influencing Communication in Complex Product Development”. 
Concurrent Engineering: Research and Applications, 2008:16(1):37-59. 
[EP24] Dafoulas, G.; Kingdom, U.; Swigger, K et al. “Global teams: futuristic models of collaborative 
work for todays software development industry”. International Conference on System Sciences, 
2009:1-10. 
[EP25] Roberts, T.; Lowry, P.; Cheney, P.; Hightower, R. “Improving Group Communication Outcomes 
with Collaborative Software: The Impact of Group Size, Media Richness, and Social 
Presence”.2006;(C):1-8. 
[EP26] Woit, D.; Bell, K. 2005. “Student Communication Challenges in Distributed Software 
Engineering Environments”. Innovation and Technology in Computer Science Education 
(ITiCSE’05), 286-290. 
[EP27] Davis, A.; Germonprez, M.; Petter, S.; Drum, D.; Kolstad, J. “A Case Study of Offshore 
Development across IS Courses: Lessons Learned from a Global Student Project”. Communications of 
the Association for Information Systems, 2009:24:351-372. 
[EP28] Lin, C.; Standing, C.; Liu, YC. “A model to develop effective virtual teams”. Journal Decision 
Support Systems, 2008:45: 1031-1045. 
[EP29] Gutwin C, Penner R, Schneider K. 2004 “Group awareness in distributed software development. 
Computer Supported Cooperative Work (CSCW’04),72-81. 
[EP30] Prikladnicki R. “Exploring Propinquity in Global Software Engineering”. IEEE International 
Conference on Global Software Engineering, 2009:133-142. 
[EP31] Ehrlich, K.; Chang, K. 2006 “Leveraging expertise in global software teams: Going outside 
boundaries”. International Conference on Global Software Engineering (ICGSE'06), 1-10. 
[EP32] French, A.; Layzell, P. 1998 “A Study of Communication and Cooperation in Distributed 
Software Project Teams”. International Conference on Software Maintenance (ICSM'98), 146-154. 
[EP33] Kommeren, R. “Phili EP experiences in global distributed software development”. Empir Software 
Eng, 2007 :12:647-660. 
29
 
Avaliação da ferramenta StArt utilizando o modelo TAM e 
o paradigma GQM 
Elis Hernandes1, Augusto Zamboni1, Andre Di Thommazo2, Sandra Fabbri1 
1Departamento de Computação - Universidade Federal de São Carlos (UFSCar) 
2Instituto Federal de Educação, Ciência e Tecnologia de São Paulo (IFSP) 
{elis_hernandes, sfabbri}@dc.ufscar.br, augusto_zamboni@comp.ufscar.br 
andredt@cefetsp.br 
Abstract: Context: The tool named StArt was developedto support the 
Systematic Review (SR) process. Aiming to characterize its contributions and 
limitations it should be evaluated. Objective: Presenting an evaluation of the 
StArt tool concerning its perceived usefulness and ease of use, according to 
TAM method. Method: The evaluation was designed based on GQM 
guidelines, taking into account the TAM method. The subjects were graduate 
students who had a previous knowledge of SR. Results: Considering the 
biggest answer percentages, 71,42% of the subjects totally agree with the 
StArt usefulness and 45,23% of the subjects partially agree with the StArt ease 
of use. Conclusion: The results and the GQM model leads to the following 
actions: to define guidelines for the ease of use improvement and to conduct 
another evaluation. 
Resumo: Contexto: Para apoiar o processo de Revisão Sistemática (RS) foi 
desenvolvida a ferramenta StArt que deve ser avaliada para que suas 
contribuições e limitações sejam caracterizadas. Objetivo: Apresentar uma 
avaliação da ferramenta StArt quanto à sua facilidade de uso e utilidade, de 
acordo com o método TAM. Método: A avaliação foi planejada de acordo com 
as diretrizes do GQM, pautada no modelo TAM e realizada por alunos de pós-
graduação com prévio conhecimento sobre RS. Resultados: Considerando as 
maiores porcentagens, 71,42% dos participantes concordam totalmente com a 
utilidade da StArt e 45,23% concordam parcialmente em relação à facilidade 
de uso. Conclusão: Os resultados e o GQM levam às seguintes ações: definir 
diretrizes para a melhoria da facilidade de uso da StArt e conduzir uma nova 
avaliação. 
1. Introdução 
A Revisão Sistemática (RS) busca identificar, avaliar e interpretar todas as pesquisas 
relevantes disponíveis relacionadas com algum tópico de pesquisa [Kitchenham, 2004]. 
Oriunda da área médica, a RS tem ganhando força nos últimos anos junto à comunidade 
científica da computação pela capacidade de prover um estudo detalhado e abrangente 
sobre o assunto que está sendo pesquisado. 
 Comparado com uma revisão bibliográfica feita de forma ad hoc, a RS é bem 
mais demorada e trabalhosa [Montebelo et al., 2007]. Ela envolve a execução de vários 
passos, desde a criação de um protocolo bem definido, passando por procedimentos 
para aceitação ou rejeição dos estudos selecionados até métodos para sumarização dos 
30
 
resultados. Com o intuito de facilitar esse processo foi desenvolvida a ferramenta StArt 
(State of the Art through Systematic Review). Ela dá suporte a todos os passos descritos 
anteriormente, bem como à geração de diversos relatórios que podem dar subsídios a 
caracterização do estado da arte do tópico pesquisado. 
 Para fazer uma avaliação prévia da StArt com o objetivo amplo de verificar sua 
aceitação pelos usuários, usou-se o Modelo de Aceitação de Tecnologia (TAM), 
posposto por Davis e outros (1989), o qual procura determinar os aspectos de utilidade e 
facilidade de uso. Segundo Hu e outros (2010) esse modelo é um dos mais influentes 
para mensurar aceitação de uma tecnologia pelos usuários. Para organizar esse estudo 
foi aplicado o paradigma Goal/Question/Metric (GQM) [Basili et al, 1994]. 
 Vale ressaltar que o objetivo deste artigo é apresentar a avaliação da StArt e não 
suas funcionalidades e aspectos de implementação. 
 O artigo apresenta na Seção 2 o processo de Revisão Sistemática e a ferramenta 
StArt. Na Seção 3, apresentam-se o modelo TAM e o paradigma GQM. A Seção 4 
apresenta os detalhes do estudo realizado, abordando cada fase do GQM. Considerações 
finais e trabalhos futuros são apresentados na Seção 5. 
2. Revisão Sistemática e a ferramenta StArt 
O processo de RS é composto por três fases: Planejamento, Execução e Publicação dos 
Resultados [Kitchenham, 2004]. Essas fases e seus objetivos são apresentados na Tabela 1. 
 
Tabela 1. Objetivos e etapas de cada fase da RS [Montebelo et al., 2007] 
Fase Objetivos Resumo 
Planejamento 
Definir o objetivo e planejar a 
Revisão Sistemática 
- Identificar a necessidade da Revisão Sistemática; 
- Definir os objetivos da pesquisa; 
- Criar o protocolo (planejar a RS); 
Execução 
(Condução, Seleção de 
estudos e Extração de 
Informações) 
Executar o planejamento feito no 
protocolo, buscar estudos 
primários e selecionar os estudos 
primários para serem sintetizados
- Executar as strings de busca nas máquinas de busca selecionadas;
- Selecionar os estudos primários de acordo com os critérios de 
inclusão e exclusão; 
- Extrair informações dos estudos primários selecionados; 
Publicação dos 
Resultados 
Sintetizar os estudos primários 
que atendem ao propósito da 
revisão 
- Sintetizar as informações extraídas dos estudos primários; 
- Publicar os resultados (relatório técnico ou artigos) 
 A ferramenta StArt foi desenvolvida para apoiar todo processo de RS. Por meio 
de uma árvore hierárquica localizada do lado esquerdo da tela, a StArt disponibiliza 
funcionalidades que apóiam a execução de cada fase da RS: 
 Para a fase de Planejamento a StArt disponibiliza o preenchimento do protocolo. 
Para a fase de Execução, a ferramenta disponibiliza funcionalidades para apoiar as 
etapas de condução, seleção e extração das informações. Para a fase de Sumarização, 
que corresponde à analise dos dados, a ferramenta disponibiliza gráficos com dados 
estatísticos da RS e permite que o usuário elabore um relatório final sobre a revisão 
realizada, podendo a todo momento acessar as informações extraídas de cada estudo na 
etapa de extração de informações. A Figura 1 ilustra a interface da ferramenta StArt e 
resume como a ferramenta apóia cada fase. 
31
 
 
Figura 1. Etapas da RS sendo englobadas pela ferramenta StArt 
 Além das funcionalidades mencionadas, a StArt permite que o usuário gere 
relatórios que auxiliam na extração de informações armazenadas na ferramenta durante 
a execução do processo de RS. Exemplos desses relatórios são: geração de todas as 
informações pertinentes à RS, correspondendo ao empacotamento da RS; resumos de 
todos os estudos importados por meio do arquivo BibTex para que o usuário possa le-
los no formato impresso; conjunto das informações extraídas pelo usuário de cada um 
dos estudos aceitos na etapa de Extração de Informações; arquivo no formato BibTex 
contendo todos os estudos pertencentes à RS possibilitando que eles sejam importados 
em um gerenciador de referências. 
3. O modelo TAM e o paradigma GQM 
O modelo TAM (Technology Acceptance Model), de acordo com Hu e outros (2009), é 
amplamente utilizado na área acadêmica para avaliação de aceitação de tecnologias 
pelos usuários e, segundo o autor, possui forte base teórica e vasto apoio empírico. Esse 
modelo foi proposto por Davis [DAVIS et al, 1989][DAVIS, 1993].e é uma evolução do 
modelo TRA [FISHBEIN, AJZEN, 1975]. 
 O objetivo do modelo TAM (Figura 2), é identificar porque determinada 
tecnologia é aceita ou rejeitada pelos usuários. A avaliação é baseada em dois conceitos: 
(i) percepção sobre utilidade (PE - perceived usefullness) e (ii) percepção sobre 
facilidade de uso (PEU – perceived ease of use). PE é definido como o quanto o usuário 
acredita que usando uma determinada tecnologia ele pode melhorar seu desempenho. 
PEU é definido como o quanto o indivíduo acredita que usando determinada tecnologia 
ele pode ficar livre de esforço físico ou mental [DAVIS, 1993]. Com base nessas 
informações, o modelo dá indícios sobre uma atitude positiva do usuário em realmente 
usar a tecnologia que foi avaliada. 
32
 
 
Figura 2. O modelo TAM (adaptado de Davis (1993)) 
 Segundo Polanĉiĉ e outros (2010), o TAM possui a vantagem de ter enfoque 
específico em tecnologias de informação; ter sua validade e confiabilidade demonstrada 
em pesquisas; ser extensível; e poder ser usado durante e após a adoção de determinada 
tecnologia.Considerado que a StArt, apesar de estável, ainda está em processo de 
desenvolvimento e melhorias, identificou-se no TAM um modelo para realizar a 
primeira avaliação da ferramenta. Essa avaliação foi planejada usando o paradigma 
GQM (Figura 3) uma vez que ele está consolidado na área de engenharia de software. 
 O GQM representa uma abordagem sistemática para a adaptação e integração de 
objetivos para os modelos dos processos de software, produtos e perspectivas de 
interesse de qualidade, com base nas necessidades específicas do projeto e da 
organização [Basili et al, 1994]. Para definir um modelo GQM é necessário identificar 
objetivos, representá-los por meio de perguntas e definir métricas que forneçam os 
dados para responder essas perguntas [Soligen, Berghout, 1999]. O resultado da 
aplicação do GQM é a especificação de um programa de medição, tendo como alvo um 
conjunto específico de problemas e um conjunto de regras para a interpretação dos 
dados. 
 
Figura 3. O modelo GQM [SOLIGEN, BERGHOUT, 1999] 
4. Avaliação da StArt 
Segundo Basili e outros (1996), toda tecnologia proposta, seja método, técnica, 
ferramenta, etc., deve ser avaliada antes de ser disponibilizada para uso. Assim, o 
objetivo da avaliação aqui apresentada é, principalmente, caracterizar os dois aspectos 
tratados pelo método TAM, para obter subsídios para a continuidade do 
desenvolvimento da StArt. Para a condução da avaliação foi usado o paradigma GQM e 
suas etapas são apresentadas nas próximas seções. 
33
 
4.1. Planejamento e definição 
A avaliação foi feita por quatorze alunos de pós-graduação em Ciência da Computação 
(mestrado e doutorado) que tiveram o primeiro contato com RS em uma disciplina de 
Metodologia de Pesquisa conduzindo-a de forma manual. Esses alunos aplicaram a RS 
até a etapa de seleção dos artigos. 
 A Figura 4 apresenta o modelo GQM, que é composto por quatro objetivos, 
quinze questões (Tabela 2) e quatorze métricas (Tabela 3). Os objetivos abordam os 
itens propostos pelo TAM, a identificação da etapa de maior dificuldade na RS e se 
houve mudanças no procedimento para realização de revisão bibliográfica a partir do 
conhecimento de RS. Na Tabela 4 apresenta-se o modelo de interpretação do GQM, o 
qual deve ser lido da seguinte forma: “Se Expressão então Interpretação”, ou seja, 
tomando como exemplo a linha 8, na qual a questão de referência é a Q4, “Se M9 + 
M10 + M11 ≥ M12 + M13 + M14 então a RS é vista como um recurso fundamental 
para a qualidade de uma pesquisa acadêmica”. 
 
 
Figura 4. GQM para avaliar a StArt 
Tabela 2. Questões usadas no GQM 
Questã
o 
Descrição Questã
o 
Descrição 
Q1 Qual atividade exigida no processo de revisão sistemática você julga ser a mais DIFÍCIL Q10 
Considero a StArt fácil de usar 
Q2 
Depois de conhecer o processo de revisão sistemática, você 
modificou sua forma de realizar revisão bibliográfica? Q11 
A StArt me permitiu executar a revisão 
sistemática em conformidade com o processo 
definido na literatura 
Q3 
Você tentou aplicar novamente o processo de revisão 
sistemática após a disciplina realizada no segundo semestre de 
2009? 
Q12 
Usar a StArt melhorou o meu desempenho 
durante a execução das atividades do processo 
de revisão sistemática que foram realizadas. 
Q4 
Qual seu grau de concordância com a afirmação: "A revisão 
sistemática é fundamental para a qualidade de uma pesquisa 
acadêmica" 
Q13 
Usar a StArt facilitou a execução das 
atividades que compõem o processo da revisão 
sistemática 
Q5 Foi fácil aprender a utilizar a StArt 
Q14 
Usar a StArt melhorou minha produtividade na 
execução das atividades do processo de revisão 
sistemática que foram realizadas. 
Q6 Consegui utilizar a StArt da forma que eu queria 
Q7 Eu entendia o que acontecia na minha interação com a StArt 
Q8 Foi fácil ganhar habilidade no uso da StArt 
Q15 
Eu considero a StArt útil para executar 
minha(s) revisão sistemática 
Q9 Foi fácil lembrar como realizar uma revisão sistemática com o uso da StArt 
34
 
Tabela 3. Métricas usadas no GQM 
Métrica Descrição 
M1 Número de pessoas que escolheram “elaboração do protocolo” 
M2 Número de pessoas que escolheram “criação das strings de busca” 
M3 Número de pessoas que escolheram “busca de artigos nas máquinas de busca” 
M4 Número de pessoas que escolheram “selecionar os artigos que serão lidos por completo” 
M5 Número de pessoas que escolheram “extrair informações dos artigos lidos por completo” 
M6 Número de pessoas que escolheram “sumarizar o resultado da revisão sistemática” 
M7 Número de pessoas que escolheram “SIM” 
M8 Número de pessoas que escolheram “NÃO” 
M9 Número de pessoas que escolheram “Concordo totalmente” 
M10 Número de pessoas que escolheram “Concordo amplamente” 
M11 Número de pessoas que escolheram “Concordo parcialmente” 
M12 Número de pessoas que escolheram “Discordo totalmente” 
M13 Número de pessoas que escolheram “Discordo amplamente” 
M14 Número de pessoas que escolheram “Discordo parcialmente” 
 
Tabela 4. Modelo de interpretação do GQM 
Nº Expressão Interpretação (próximas ações da equipe) 
1 M1 > Mi , i= 2, 3, 4, 5 e 6 atividade de maior dificuldade é a elaboração do protocolo 
2 M2 > Mi, i=1, 3, 4, 5 e 6 atividade de maior dificuldade é a criação das strings de busca 
3 M3 > Mi, i = 1, 2, 4, 5 e 6 atividade de maior dificuldade é a busca de artigos nas máquinas de busca 
4 M4 > Mi, i= 1, 2, 3, 5 e 6 atividade de maior dificuldade é selecionar os artigos que serão lidos por completo 
5 M5 > Mi, i= 1, 2, 3, 4 e 6 atividade de maior dificuldade é extrair informações dos artigos lidos por completo 
6 M6 > Mi, i= 1, 2, 3, 4 e 5 atividade de maior dificuldade é sumarizar o resultado da revisão sistemática 
7 Para Q2: M7 ≥ M8 ocorreu mudança na forma de realizar revisão bibliográfica após conhecer o processo de revisão sistemática 
8 Para Q4: M9 + M10 + M11 ≥ M12 + M13 + M14 
a RS é vista como um recurso fundamental para a qualidade de uma pesquisa 
acadêmica 
9 Para Qi, i = 5 a 10: M9 ≥ M10 + M11 
a StArt é fácil de ser utilizada, e o próximo passo é a condução de um estudo 
experimental com um novo grupo de participantes para comprovar o resultado 
10 
Para Qi,, i=5 a 10: 
 M9 ≤ M10 + M11 e 
M10 ≥ M11 
a StArt é fácil de ser utilizada, porém, o próximo passo deve ser a análise dos dados 
enviados pelos participantes por meio de comentários com o intuito de identificar as 
melhorias necessárias para facilitar o uso da ferramenta. Feitas as melhorias, a mesma 
avaliação deve ser realizada com um novo grupo de participantes 
11 
Para Qi,, i=5 a 10: 
M9 ≤ M10 + M11 e 
M11 ≥ M10 
a StArt não possui facilidade de uso e por isso, o próximo passo é estudar heurísticas e 
padrões de usabilidade definidos na literatura para realizar uma auto-avaliação sobre a 
interface da ferramenta, os comentários enviados pelos participantes devem ser 
analisados e baseado nisso, o projeto da StArt deve ser revisto e as melhorias 
implementadas. A avaliação deve ser novamente conduzida com o mesmo grupo de 
participantes para verificar se ocorreu melhoria nos resultados 
12 Para Qi,, i=11 a 15: M9 ≥ M10 + M11 
a StArt é útil para realizar revisão sistemática, sendo que o próximo passo é a 
condução de um estudo experimental para comprovar o resultado 
13 
Para Qi,, i=11 a 15: 
M9 ≤ M10 + M11 e 
M10 ≥ M11 
a StArt é útil, porém deve ser feita a análise dos dados enviados pelos participantes 
por meio de comentários com o intuito de identificar as melhorias necessárias para 
tornar a ferramenta útil. Feitas as melhorias, a mesma avaliação deve ser realizada 
com um novo grupo de participantes 
14 
Para Qi,, i=11 a 15: 
M9 ≤ M10 + M11 & 
M11 ≥ M10 
a StArt não de grande utilidade e por isso, o próximo passo da equipe é rever o projeto 
da ferramenta com o intuito de identificarse há funcionalidades que possam ser 
implementadas para prover maior utilidade a StArt. A avaliação deve ser novamente 
conduzida com o mesmo grupo de participantes para verificar se houve melhoria nos 
resultados 
15 
Para Qi,, i= 5 a 10: 
M14 + M13 + M12 ≥ 
M9 + M10 + M11 
a implementação de novas funcionalidades na StArt deve ser abortada, os comentários 
enviados pelos participantes devem ser analisados e o projeto da ferramenta deve ser 
totalmente revisto pela equipe, principalmente a interface com o usuário. Modificada a 
ferramenta, o mesmo estudo deve ser conduzido até que os participantes julguem a 
ferramenta fácil de usar 
16 
Para Qi,, i=11 a 15: 
M14 + M13 + M12 ≥ 
M9 + M10 + M11 
a implementação de novas funcionalidades na StArt deve ser abortada, os comentários 
enviados pelos participantes devem ser analisados e o projeto da ferramenta deve ser 
totalmente revisto pela equipe. Modificada a ferramenta, o mesmo estudo deve ser 
conduzido até que os participantes julguem a ferramenta útil 
35
 
 Na avaliação foram utilizados dois questionários: (i) o primeiro identificou a 
opinião e o contato atual do aluno com revisão sistemática; (ii) o segundo identificou os 
aspectos de utilidade e facilidade de uso referentes ao TAM. As questões relacionadas 
ao TAM foram baseadas no estudo de Laitenberger e Dreyer (1998), usando a Likert 
Scaling [McIver e Carmines, 1991] como opções de resposta. Seis questões avaliavam a 
facilidade de uso da StArt e cinco a sua utilidade. Ambos os questionários possuíam 
campos texto para que o participante pudesse fazer comentários. 
4.2. Coleta de dados 
 O primeiro questionário (objetivos 1 e 2 do GQM) foi enviado por e-mail aos 
participantes que, após o terem respondido, tiveram acesso a dois vídeos para 
treinamento sobre a StArt e puderam então fazer download da ferramenta, para realizar 
a avaliação individualmente. 
 Foi solicitado que os alunos explorassem a ferramenta até a fase de seleção dos 
estudos, como havia sido feito durante a disciplina, de forma manual. Terminando o que 
foi solicitado, os alunos respondiam ao segundo questionário, que foi enviado por e-
mail apenas para os que haviam respondido o primeiro questionário. Por usar 
questionários eletrônicos, ao fim da avaliação todas as respostas estavam tabuladas em 
planilhas eletrônicas, o que facilitou a análise dos dados. 
4.3. Análise dos resultados 
Nas Tabelas 4, 5 e 6 são apresentadas as perguntas e respostas do primeiro questionário 
e nas Figuras 5 e 6 são apresentados gráficos com as perguntas e respostas do segundo 
questionário. Nos gráficos, a ordem das barras obedece a ordem das questões. 
Tabela 5. Dados coletados no questionário 1 (pergunta 1) 
 
Elaboração 
do protocolo 
Criação 
das strings 
de busca 
Busca de 
artigos nas 
máquinas de 
busca 
Selecionar os 
artigos que 
serão lidos por 
completo 
Extrair 
informações/ 
dados dos artigos 
lidos por completo 
Sumarizar o 
resultado da 
revisão 
sistemática 
Outra
Q1) Qual atividade exigida 
no processo de revisão 
sistemática você julga ser a 
mais DIFÍCIL: 
6 5 1 0 2 0 0 
Tabela 6. Dados coletados no questionário 1 (perguntas 2 e 3) 
 Sim Não 
Q2) Depois de conhecer o processo de revisão sistemática, você modificou sua forma de realizar revisão 
bibliográfica? 13 1 
Q3) Você tentou aplicar novamente o processo de revisão sistemática após a disciplina realizada no segundo 
semestre de 2009? 6 8 
Tabela 7. Dados coletados no questionário 1 (perguntas 4) 
 Concordo 
totalmente 
Concordo 
amplamente
Concordo 
parcialmente
Discordo 
totalmente
Discordo 
parcialmente 
Discordo 
amplamente
Q4) Qual seu grau de concordância com 
a afirmação: "A revisão sistemática é 
fundamental para a qualidade de uma 
pesquisa acadêmica" 
7 3 4 0 0 0 
 
36
 
 
Figura 5. Perguntas e respostas relacionadas à facilidade de uso 
 
Figura 6. Perguntas e respostas relacionadas à utilidade de uso 
 Considerando o modelo de interpretação apresentado na Tabela 4 e os dados 
coletados durante a avaliação, representados nas figuras e tabelas acima, todos os 
objetivos da avaliação foram contemplados e o que se pode dizer acerca deles é: 
• G1: a atividade mais difícil do processo de RS é a elaboração do protocolo, pois, 
de acordo com a Tabela 4, seis pessoas assinalaram essa opção e isso satisfaz a 
expressão 1. 
• G2: os participantes concordam que a RS é um recurso fundamental para a 
qualidade da pesquisa acadêmica e mudaram a maneira de conduzir revisão 
bibliográfica, embora apenas 6 dos 14 participantes tenham tentado aplicar o 
processo novamente após o término da disciplina (Q3). Isso pode ser constatado, 
respectivamente, na Tabela 6, em que 7 pessoas concordam totalmente, 3 
concordam amplamente e 4 parcialmente, satisfazendo a expressão 8 (ou seja, 
7+3+4 ≥ 0+0+0) e na Tabela 5, que mostra que 13 pessoas responderam a Q2 
afirmativamente, satisfazendo a expressão 7 (ou seja, 13 ≥ 1); 
• G3: a maioria dos participantes concordam amplamente com a facilidade de uso 
da StArt. Isso pode ser constatado na Figura 5, em que 38 respostas dos 
participantes estão concentradas na opção “Concordo parcialmente”, o que 
satisfaz expressão 10 (ou seja, 32 ≤ 38+12 & 38 ≥ 12) e de acordo com o 
modelo de interpretação da Tabela 4, indica que o próximo passo para a equipe 
de desenvolvimento deve ser a análise dos dados enviados pelos participantes 
por meio de comentários com o intuito de identificar as melhorias necessárias 
para facilitar o uso da ferramenta. Feitas as melhorias, a mesma avaliação deve 
ser realizada com um novo grupo de participantes; 
37
 
• G4: a maioria dos participantes concordam totalmente com a utilidade da StArt. 
Isso pode ser confirmado na Figura 6, em que 50 respostas (considerando todas 
as questões) dos participantes estão concentradas na opção “Concordo 
totalmente”, o que satisfaz a expressão 12 (ou seja, 50 ≥ 17+2) e de acordo com 
o modelo de interpretação da Tabela 4, indica que próximo passo para a equipe 
de desenvolvimento é a condução de um estudo experimental para comprovar 
esse resultado. 
5. Considerações finais e trabalhos futuros 
Este artigo apresentou uma avaliação da ferramenta StArt, que foi planejada usando o 
GQM e estabeleceu como objetivos os aspectos tratados pelo método TAM – facilidade 
de uso e utilidade – além da identificação do ponto considerado mais difícil de uma RS, 
além da influência causada na conduta do participante, decorrente do uso de RS. O uso 
do TAM tornou a avaliação rápida e objetiva, além de disseminar o método entre todos 
os participantes. As diretrizes do GQM propiciaram objetividade à avaliação e à 
definição e elaboração dos formulários para coleta de dados. 
 A StArt é uma ferramenta que apóia a execução do processo de revisão 
sistemática [Zamboni et al., 2010]e que vem sendo desenvolvida de maneira iterativa e 
interativa, com realimentação constante do público que a tem utilizado. Embora a 
versão atual ainda não contenha todas as funcionalidades planejadas, como por 
exemplo, o processo de mapeamento sistemático [Petersen et al., 2008], ela já consiste 
em um firme apoio ao processo de RS e, por isso, uma avaliação era importante para 
direcionar os próximos passos. 
 Uma das limitações da avaliação é o número de participantes, o que não permite 
generalizar os resultados e aplicar análises estatísticas elaboradas. O pré-requisito para 
participar da avaliação foi ter realizado uma disciplina na qual o processo de RS foi 
executado até a fase de seleção dos estudos. Isso impossibilitou que mais alunos 
pudessem participar. 
 Assim, o resultado da avaliação indicou que a StArt é útil, uma vez que 71,42% 
dos participantes concordaram totalmente com a utilidade da ferramenta. Quanto à 
facilidadede uso, embora 38,09% concordaram totalmente com esse item, 45,23% 
concordaram amplamente, 14,28% concordaram parcialmente e 2,38% discordaram 
parcialmente. De acordo com o planejamento GQM, ações serão tomadas para que a 
StArt se torne mais fácil de usar. Em resumo, a avaliação forneceu indícios de que a 
ferramenta será aceita pelos usuários para dar suporte à realização de RS. 
 Além das ações definidas no modelo de interpretação do GQM, decorrentes 
diretamente da avaliação realizada, outras funcionalidades já estão sendo 
implementadas, como o suporte ao processo de mapeamento sistemático [Petersen et 
al., 2008], mecanismos de comunicação com outras ferramentas, etc. Além disso, 
estudos experimentais estão sendo planejados para avaliar a ferramenta em diferentes 
contextos. 
Agradecimentos 
Os autores agradecem aos alunos que participaram da avaliação e ao CNPq, CAPES e 
ao Projeto Observatório da Educação pelo apoio financeiro. 
38
 
Referências 
Basili, V. R., C. Caldiera, H.D. Rombach, (1994). “Goal Question Metric Paradigm”. 
Encyclopedia of Software Engineering. John Wiley & Sons, pp. 528-532. 
Basili, V. R.; Green, S.; Laitenberger, O.; Lanubile, F.; Shull, F.; Sorumgard, S.; 
Zelkowitz, M. (1996). “Packaging researcher experience to assist replication of 
experiments”. In: Inter. Software Engineering Research Network Meeting (ISERN). 
Australia, ISERN. 
Davis, F. D.; Bagozzi, R.; Warshaw, P. R. (1989). “User acceptance of computer 
technology: a comparison of two theoretical models”. In Management Science, pp. 
982-1003. 
Davis, F. D. (1993). “User acceptance of information technology: system characteristics, 
user preceptions and behavioral impacts”. In Int. J. Man-Macgine Studies (v.38), pp. 
475-487. 
Fishbein, M., Ajzen, I. (1975). “Belief, attitude, intention and behavior: A introduction to 
theory and research. Reading, MA: Addison-Wesley. 
Hu, Y., Sun, X., Zhang, J., Zhang, X., Luo, F.; Huang, L. (2009). “A University Student 
Behavioral Intention Model Of Online Shopping Based on TAM”. In Inter. Conf. on 
Infor. Manag., Innovation Manag. and Industrial Engineering, pp. 625-628. IEEE 
Press. 
Kitchenham, B. (2004). “Procedures for Performing Systematic Reviews”. Joint Technical 
Report SE Group, Depart. Computer Science Keele University, United King and 
Empirical Software Engineering, National ICT, Australia. 
Laitenberger, O., Dreyer, H. M. (1998). “Evaluating the Usefulness and the Ease of Use of 
a Web-based Inspection Data Collection Tool”. In International Symposium on 
Software Metrics, pp. 122-135. 
McIver, J. P.and Carmines, E. G. (1991). Unidimensional Scaling. Sage Publications. 
Montebelo, R. P., Orlando, A., Porto, D. P., Zaniro, D., Fabbri, S. (2007). “SRAT 
(Systematic Review Automatic Tool) - uma ferramenta computacional de apoio à 
Revisão Sistemática”. In Experimental Software Engineering Latin American 
Workshop, pp. 13-22. Fundação de Ensino Eurípedes Soares da Rocha. 
Petersen, K., Feldt, R., Mujtaba, S., Mattsson, M. (2008) “Systematic Mapping Studies in 
Software Engineering”. In: Inter. Conf. on Evaluation and Assessment in Software 
Engineering (EASE), pp.26-27. University of Bari. 
Polanĉiĉ, G., Heriĉko, M.; Rozman, I. (2010). “An empirical examination of application 
frameworks success based on technology acceptance model”. In The Journal of 
Systems and Software, pp. 574-584, Elsevier. 
Soligen, R., Berghout, E. (1999), The Goal/Question/Metric Method: a practical guide for 
quality improvement of software development, McGraw W-Hill Companies. 
Zamboni, A. B.; Di Thommazo, A. D.; Hernandes, E. C. M.; Fabbri, S. C. P. F. (2010). 
StArt Uma Ferramenta Computacional de Apoio à Revisão Sistemática. In: CBSoft - 
Congresso Brasileiro de Software – Sessão de Ferramentas. CBSoft. 
39
 
Uma Ferramenta de Apoio ao Planejamento de 
Estudos Experimentais em Engenharia de Software 
Vitor Pires Lopes, Guilherme Horta Travassos 
COPPE / UFRJ – Programa de Engenharia de Sistemas e Computação 
Caixa Postal 68.511, CEP 21945-970, Rio de Janeiro – Brasil 
{vitorlopes, ght}@cos.ufrj.br
Abstract. This paper presents a tool designed to provide support to decision 
making in experimental studies planning in Software Engineering research. 
This is achieved by retrieving knowledge from OWL ontology models. This 
tool shows this knowledge as planning questions, each one with its respective 
answer options. By answering these questions, the researcher is guided 
throughout the planning phase. After analyzing the ontologies, the tool 
generates a planning document template with the answers provided. 
Resumo. Este artigo apresenta uma ferramenta de apoio a tomadas de 
decisão no planejamento de estudos experimentais em Engenharia de 
Software. A ferramenta recupera conhecimento de ontologias OWL, sendo 
disponibilizado na forma de perguntas, cada qual com as respectivas 
respostas. O pesquisador é guiado ao longo da fase de planejamento através 
das respostas dadas às perguntas. Após recuperar o conhecimento, a 
ferramenta gera um template de documento de plano com as respostas dadas. 
1. Introdução 
Em Engenharia de Software, experimentação visa desenvolver uma base de evidência 
para compreensão e intervenção científica nos processos envolvidos no 
desenvolvimento de tecnologias de software [Travassos et al. 2008]. Tendo em vista a 
importância de experimentação nesse contexto, Sjøberg et al. (2007) conduziram uma 
análise da área de Engenharia de Software Experimental e apontaram alguns desafios a 
serem enfrentados nos próximos 10 anos. Dentre os desafios mais específicos, os 
pesquisadores salientam a necessidade de planejar estudos experimentais com maior 
rigor, em especial considerando amplamente os detalhes de design das estratégias de 
estudo, ou como também são denominados os diferentes métodos experimentais 
aplicáveis. A condução de estratégias de estudo demanda que diferentes questões de 
arranjo sejam consideradas, sendo todas específicas da estratégia escolhida. A não-
observância dos principais detalhes de design pertinentes a uma dada estratégia pode 
introduzir ameaças à validade do estudo. A solução para esse desafio, a princípio, 
requer: (1) explicitar o conhecimento sobre as diferentes estratégias de estudo e (2) 
disponibilizar adequadamente o conhecimento ao pesquisador, de modo a apoiar as 
diferentes tomadas de decisão comuns a essa etapa [Sjøberg et al. 2007]. 
No sentido de atender ao requisito (1), o Grupo de Engenharia de Software 
Experimental (ESE) da COPPE/UFRJ estruturou um repositório para registrar o 
conhecimento do domínio da Engenharia de Software Experimental e seus subdomínios 
40
 
como o de estratégia de estudo [Lopes e Travassos 2009a]. Esse repositório é parte 
integrante do eSEE (experimental Software Engineering Environment), um ambiente 
capaz de apoiar experimentação em larga-escala em Engenharia de Software [Travassos 
et al. 2008]. O objetivo desse artigo é apresentar uma das ferramentas do eSEE que tem 
por objetivo viabilizar o requisito (2) previamente apresentado. Denominada eSPA 
(experimental Studies Planning Assistant), essa ferramenta se caracteriza por recuperar 
conhecimento do repositório do eSEE, disponibilizando-o na forma de questões e 
respostas associadas aos conceitos de estratégias de estudo e de subdomínios de 
conhecimento correlatos. Opções de resposta são fornecidas para cada questão, na qual a 
ferramenta expõe o significado dos principais conceitos para auxiliar o pesquisador na 
tomada de decisão sobre a resposta apropriada tendo em vista as características do 
estudo que pretende planejar. Além disto, a ferramenta gera um template para o 
documento de plano do estudo, com seções específicas e aderentes às decisões tomadaspelo pesquisador. Esse template é organizado de acordo com as respostas dadas para 
cada questão, e servirá de roteiro para o planejamento do estudo. 
O artigo está organizado em cinco seções: A primeira seção compreende essa 
introdução. A seção dois discorre brevemente sobre algumas ferramentas relacionadas. 
A seção três descreve o contexto no qual essa ferramenta está inserida e será utilizada. A 
quarta seção apresenta as principais características e funcionalidades da ferramenta. A 
seção cinco descreve a arquitetura da solução. A sexta seção aborda trabalhos futuros 
envolvendo a ferramenta. A última seção conclui esse trabalho. 
2. Ferramentas Relacionadas 
Torii et al. (1999) apresentaram um ambiente de apoio a experimentação, 
denominado Ginger2. Esse ambiente foi construído de forma a implementar o 
framework CAESE (Computer-Aided Empirical Software Engineering). Esse 
framework estabelece um processo de experimentação contemplando as seguintes 
atividades: (1) análise de necessidades envolvendo a descrição do problema e definição 
de hipóteses; (2) design do experimento, na qual o pesquisador decide quais ferramentas 
serão utilizadas e quais serão os participantes; (3) execução e coleta de dados; (4) 
análise dos dados. Embora relevante para o contexto em que foi proposta, essa 
ferramenta apóia o processo de experimentação de modo geral sem, entretanto, fornecer 
um apoio mais específico à etapa de planejamento. Ou seja, Ginger2 não subsidia um 
planejamento adequado aos diversos detalhes de design das estratégias de estudos, tal 
como salienta Sjøberg et al. (2007). A eSPA se diferencia por propor um meio de 
auxiliar o pesquisador a considerar importantes detalhes no design das estratégias, 
disponibilizando conhecimento de apoio as tomadas de decisão. Esse conhecimento é 
recuperado do repositório do eSEE. 
3. Contexto: eSEE (experimental Software Engineering Environment) 
O eSEE consiste em uma infra-estrutura computacional baseada em serviços web e 
capaz de instanciar ambientes para gerenciar o processo de experimentação em 
Engenharia de Software, incluindo as atividades de definição, planejamento, execução e 
empacotamento de estudos primários e secundários. O eSEE disponibiliza processos de 
experimentação, pacotes da experiência, padrões de apresentação de dados, ferramentas 
e serviços para os diferentes tipos de estudos identificados em Engenharia de Software 
41
 
[Travassos et al. 2008]. Por ser um ambiente cujo foco é apoiar o pesquisador na 
condução de estudos, o conhecimento do domínio de Engenharia de Software 
Experimental precisa estar registrado formalmente. Lopes e Travassos (2009a) 
definiram a estrutura e organizaram um repositório que consolida o conhecimento desse 
domínio e dos subdomínios correlatos, tais como estratégia de estudo. A estrutura do 
repositório de conhecimento do ambiente está fundamentada na interdependência entre 
um glossário de termos (taxonomia) e ontologias (formalização do conhecimento). O 
primeiro está disponível na web (http://lens-ese.cos.ufrj.br/wikiese) através de recursos 
wiki e pode ser livremente utilizado pela comunidade. O objetivo do glossário é 
apresentar uma terminologia que possa, em algum momento, se identificar como 
consensual na Engenharia de Software Experimental, visando assim reduzir 
divergências conceituais entre diferentes grupos de pesquisa [Lopes e Travassos 2009b]. 
As ontologias explicitam os relacionamentos e restrições dos conceitos expressos 
no glossário. Os modelos foram construídos utilizando a linguagem LINGO [Mian 
2003], que consiste basicamente em um perfil UML. O repositório internaliza dois 
modelos: a Ontologia de Pesquisa Científica e a Ontologia de Pacote do Experimento. A 
primeira ontologia foi criada para englobar conceitos gerais do domínio de Engenharia 
de Software Experimental. Para subdomínios como estratégia de estudo, foram 
construídas subontologias específicas. A Figura 1 ilustra um desses modelos: a 
subontologia de survey, que congrega conceitos particulares desse tipo de estratégia. Os 
números ao lado de dois conceitos serão referenciados na próxima seção. 
 
Figura 1. Subontologia de Survey [Lopes e Travassos 2009a] 
A ontologia de Pacote do Experimento registra o conhecimento sobre os 
documentos envolvidos no processo de experimentação e que constituem o pacote do 
experimento. Um desses documentos é o plano de survey. Existem ainda outros modelos 
que integram as duas ontologias. Um exemplo é a subontologia de documentos de 
survey, que define, para cada seção do documento de plano de survey, quais conceitos 
da subontologia de survey (Figura 1) são registrados. O repositório do eSEE é composto 
de 24 modelos ontológicos com cerca de 442 conceitos [Lopes 2010], o que inviabiliza 
sua apresentação nesse artigo. O endereço (http://lens.cos.ufrj.br/esee) fornece uma visão 
geral sobre as principais ontologias do repositório do eSEE. 
2 
1 
42
 
De forma a permitir a recuperação e utilização do conhecimento a partir dessas 
ontologias, Lopes (2010) propõe um conjunto de heurísticas de conversão dos modelos 
LINGO para modelos OWL [W3C 2010]. A partir dos modelos convertidos para OWL, 
podem ser construídas ferramentas inteligentes que processam as ontologias para 
disponibilizar o conhecimento. A seguir apresentamos a eSPA, uma das ferramentas que 
se utilizam de componentes próprios de navegação e de componentes da API OWL e 
Protégé [Protégé 2010] para analisar e realizar inferência sobre os modelos OWL do 
repositório do eSEE. 
4. eSPA (experimental Studies Planning Assistant) 
A eSPA (http://ese.cos.ufrj.br/ConFiguradorPacote) é capaz de analisar os modelos 
OWL do repositório do eSEE. Nessa análise, eSPA recupera conhecimento sobre 
importantes tomadas de decisão acerca do design de estratégias de estudos 
experimentais em Engenharia de Software. Esse conhecimento é disponibilizado ao 
pesquisador na forma de questionamentos, cada qual relacionado a uma decisão. 
A primeira versão dos modelos OWL do repositório do eSEE não registrava o 
conhecimento a cerca de tomadas de decisão. Para construção da eSPA, procedemos 
com a inserção de metadados nas classes das ontologias OWL. Um deles é o metadado 
“decisao”, que indica a existência de um ponto de decisão relacionado a uma classe 
OWL que possua subclasses. O valor deste metadado é o texto de uma pergunta 
associada à decisão. As opções de resposta compreendem as subclasses OWL da classe 
que contém esse metadado. Na versão OWL da subontologia da Figura 1, a classe 
“Apoio ao Participante” possui um metadado “decisao” com a pergunta “como será 
organizado no survey o apoio ao participante?”. As opções de resposta são as próprias 
subclasses da classe “Apoio ao Participante”. 
A eSPA analisa a Ontologia de Pesquisa Científica. Nessa análise, a ferramenta 
navega pela árvore de relacionamentos hierárquicos e object properties. Quando o 
algoritmo visitar uma classe com metadado “decisao” preenchido, a ferramenta exibe o 
valor do metadado, apresentando assim um questionamento. Em seguida, a ferramenta 
renderiza as opções de resposta, cada qual constituindo uma subclasse da classe em 
questão. A Figura 2 ilustra um questionamento relacionado à decisão sobre qual 
estratégia de estudo deve ser adotada no estudo. A ferramenta disponibiliza ainda o 
significado do principal conceito associado à decisão, assim como a definição de cada 
opção de resposta. As definições são provenientes das ontologias. 
 
 
Ao escolher uma opção, a ferramenta registra essa escolha e continua analisando 
a ontologia para apresentar questionamentos específicos à opção escolhida em decisões 
Figura 2. Fragmento da Interface.Decisão sobre qual 
estratégia de estudo será adotada (survey) 
43
 
anteriores. A Figura 3 ilustra um exemplo desse mecanismo: ao selecionar “survey” na 
Figura 2, a ferramenta continua percorrendo a ontologia, só que o faz nos nós que 
representam conceitos relacionados ao conceito de survey. Parte desses conceitos está 
presente na Figura 1. Os questionamentos relacionados a esses conceitos de survey são 
então exibidos, cada qual com seu conjunto próprio de opções de resposta. A Figura 3 
ilustra dois questionamentos, cada um relativo a uma decisão associada a um conceito 
na subontologia de survey. O número ao lado de cada questionamento referencia um 
conceito de mesmo número presente na Figura 1. Em suma, a racionalização sobre as 
decisões tomadas envolve a análise dos conceitos da ontologia que estão associados a 
cada resposta dada nas decisões. Essa racionalização utiliza-se de facilidades da API 
OWL 3.0 [W3C 2010] e Protégé 4.1 [Protégé 2010], dentre as quais destacamos 
mecanismos de inferência computacional, capazes de raciocinar sobre a ontologia para 
viabilizar navegação entre seus elementos constituintes e consultas ao corpo de 
conhecimento. 
Ao final de percorrer a Ontologia de Pesquisa Científica e registrar a resposta de 
todas as decisões, a ferramenta analisa a Ontologia de Pacote do Experimento para 
determinar quais documentos devem ser gerados em função das escolhas. Os modelos 
mais importantes nessa etapa são aqueles que integram os conceitos das duas ontologias. 
É gerado um documento editável (Figura 4) com subseções já preenchidas com as 
respostas dadas pelo pesquisador a cada decisão. 
 
 
Figura 3. Fragmento da Interface. Decisões específicas à 
estratégia escolhida (survey) na Figura 2 
1 
2 
44
 
 
 
É importante salientar que a versão da ferramenta disponibilizada no link 
(http://ese.cos.ufrj.br/ConFiguradorPacote) é um protótipo. A única diferença entre essa 
versão e a completa é que o protótipo analisa apenas uma parte dos modelos OWL, que 
já foi avaliado pelo grupo ESE. A versão completa da ferramenta será disponibilizada 
para a comunidade no link supracitado após ter sido submetida a uso em estudos 
experimentais do grupo ESE que contemplem diferentes estratégias de estudo e métodos 
de pesquisa, de modo a avaliar a ferramenta em diferentes contextos. Além disso, a 
ferramenta visa apoiar inicialmente o planejamento de estudo primários. Portanto, caso 
o pesquisador decida por conduzir um estudo secundário, a ferramenta não 
disponibilizará apoio nesse sentido. Em uma versão futura esse apoio será fornecido. 
5. Arquitetura da eSPA 
eSPA é uma ferramenta de arquitetura cliente-servidor implementada utilizando a 
linguagem Java. O cliente é uma interface web que guia o pesquisador pelo 
planejamento de estudos através da apresentação de questionamentos, conforme ilustra 
as Figuras 2 e 3. A parte do servidor é composta por componentes com 
responsabilidades bem definidas (Figura 5). 
O componente principal da arquitetura é o componente OntologyWalker, que 
possui as responsabilidades básicas de interação com os modelos OWL através de 
classes específicas da API Protégé. Essa API foi escolhida em função dos modelos 
OWL terem sido criados utilizando esse sistema de gerência de ontologias. Os arquivos 
são recuperados e instanciados gradativamente em memória. A ferramenta analisa as 
Ontologias de Pesquisa Científica e de Pacote do Experimento utilizando componentes 
específicos, respectivamente o ScientificResearchOntologyWalker e o 
ExperimentationPackageOntologyWalker. O primeiro contém a lógica para visitar as 
classes OWL com metadado “decisao” preenchido. Realiza-se a recuperação do 
conhecimento envolvendo o questionamento, opções de resposta e definições que 
devem ser exibidos. Na lógica de visitação do componente 
ExperimentationPackageOntologyWalker, são identificadas as classes de documento da 
Ontologia de Pacote de Experimento que estão relacionadas a uma classe da Ontologia 
de Pesquisa Científica com metadado decisão. O componente instancia o documento 
correspondente e registra na seção a resposta dada à decisão tomada. No exemplo da 
Figura 4. Fragmento do documento 
gerado para o planejamento do survey 
45
 
Figura 2, a ferramenta visitará a classe OWL referente ao documento “plano de survey”. 
Como naquele exemplo o pesquisador optou por conduzir um survey e a ontologia 
mapeia a relação entre esse documento e o conceito “survey”, a ferramenta identifica 
que o documento “plano de survey” deve ser gerado ao final da análise da ontologia. 
Essa classe utiliza recursos de inferência da API Protégé. 
 
 
 
6. Trabalhos Futuros 
A ferramenta disponibilizada atualmente é um protótipo e analisa somente parte da 
ontologia para gerar as decisões pertinentes à etapa de planejamento. Isso se deve ao 
fato da ontologia ainda estar em processo de inspeção pelo grupo ESE, o que permite 
avaliá-la e aprimorá-la quanto à corretude e à cobertura de conceitos. Essa é uma 
atividade de pesquisa de elevada prioridade dentro do grupo e, tão logo seja concluída, a 
ferramenta poderá analisar todos os modelos ontológicos do repositório de 
conhecimento do eSEE. Portanto, será capaz de gerar um conjunto de questionamentos 
com melhor cobertura das principais decisões sobre o planejamento de estudos. Em 
seguida ao término da avaliação da ontologia para disponibilizar a versão final da 
ferramenta, pretende-se conduzir um estudo experimental para avaliação da mesma, de 
modo a compreender o impacto de sua utilização em contextos reais de planejamento de 
estudos em Engenharia de Software, além de identificar oportunidades de melhoria na 
usabilidade da interface e seqüenciamento das perguntas, o que pode contribuir para 
melhorar a lógica utilizada na análise das ontologias. Nesta avaliação, espera-se também 
comparar seu uso com a elaboração manual de planos de estudo sem apoio 
computacional à tomadas de decisão. 
Outra importante oportunidade de melhoria envolve o apoio ao planejamento de 
estudos secundários. A versão atual da ferramenta apóia apenas o planejamento de 
estudos primários, uma vez que ontologia construída até então não contempla conceitos 
de estudos secundários. Outras iniciativas de pesquisa no grupo ESE já objetivam a 
elaboração de tais modelos e, assim que forem concluídos e devidamente avaliados, 
Figura 5. Arquitetura simplificada da eSPA 
46
 
serão agregados ao repositório de conhecimento do eSEE para que a ferramenta possa 
analisá-los a fim de apoiar o planejamento desse tipo de estudo. 
7. Considerações Finais 
Esse artigo apresentou a ferramenta eSPA, capaz de recuperar conhecimento das 
ontologias do repositório do eSEE. Esse conhecimento é extraído na forma de 
questionamentos, cada qual representando uma tomada de decisão associada a um 
conceito na Ontologia de Pesquisa Científica. Ao responder as sucessivas perguntas, o 
pesquisador é guiado no planejamento considerando os detalhes de design da estratégia 
de estudo adotada. Esses detalhes são expressos como conceitos no repositório do eSEE. 
A construção da eSPA envolveu o projeto de um conjunto de componentes para análise 
da ontologia utilizando recursos da API Protégé, além de contemplar a incorporação de 
novos metadados à ontologia OWL. 
Agradecimentos 
O projeto eSEE é parte do projeto Engenharia de Software Experimental e Ciência em 
Larga Escala - CNPq (475459/2007-5) e FAPERJ. Agradecemos aos órgãos pelo apoio. 
Referências 
Lopes, V.P., Travassos, G.H., (2009a), “Estrutura do Repositório de Conhecimento de 
um Ambiente para Experimentação em Larga-escala em Engenharia de Software”,Em: Anais do XXIV Simpósio Brasileiro de Engenharia de Software (SBES'09), 
Fortaleza, CE, Brasil, Outubro. 
Lopes, V.P., Travassos, G.H., (2009b), “Experimentação em Engenharia de Software: 
Glossário de Termos”, Em: Anais do Workshop Latino-americano em Engenharia de 
Software Experimental (ESELAW'09), pp. 33-44, São Carlos, SP, Brasil, Novembro. 
Lopes, V.P., (2010), “Repositório de Conhecimento de um Ambiente de Apoio à 
Experimentação em Engenharia de Software”, Dissertação de Mestrado, 
COPPE/UFRJ. 
Mian, P. G., (2003), ODEd: Uma Ferramenta de Apoio ao Desenvolvimento de 
ontologias em um Ambiente de Desenvolvimento de Software, Dissertação de M.Sc., 
Departamento de Informática, UFES, Vitória, Brasil. 
Protégé, 2010, Disponível em: <http://Protégé.stanford.edu/>. Acesso em: 26 maio. 
2010, 17:00:00. 
Sjøberg, D.I.K., Diba, T., Jorgensen, M., (2007), “The Future of Empirical Methods in 
Software Engineering Research”, In: International Conference on Software 
Engineering (ICSE), pp. 123-156, Minneapolis, USA, May. 
Torii, K., Matsumoto, K., Nakakoji, K., Takada, S., Shima, K., (1999) “Ginger2: An 
Environment for Computer-Aided Empirical Software Engineering”, IEEE 
Transactions on Software Engineering, vol. 25, No. 4, Julho/Agosto. 
47
 
Travassos, G. H., Santos, P. S. M., Mian, P. G., Dias Neto A. C., Biolchini, J. (2008) “A 
Environment to Support Large Scale Experimentation in Software Engineering”, 13th 
IEEE International Conference on Engineering of Complex Computer Systems. 
W3C, (2010). Disponível em: <http://www.w3.org/>. Acesso em: 26 maio. 2010, 
10:00:00. 
48
 
 
 
 
 
 
 
TECHNICAL SESSION 2 
Studies with Qualitative Focus (SQF) 
 
 
 
 
 
 
 
49
Utilização de Metodologias Ágeis no Desenvolvimento de 
Software: Resultados de um Estudo Empírico 
Pedro J. F. Treccani1, Cleidson R. B. de Souza2 
1Faculdade de Computação – Universidade Federal do Pará (UFPA) 
Caixa Postal 479 – 660.75 -110 – Belém – PA – Brasil 
2IBM Brasil 
São Paulo – SP - Brasil 
pedrotreccani@gmail.com, cleidson.desouza@acm.org 
Abstract. The need for constant changes, adaptations and additions of new 
requirements on software systems is frequent on current market. Companies 
need increasingly better techniques to accommodate these changes. To assist 
these organizations on following market's fast pace, agile methods have 
proved to be suitable This paper presents preliminary findings of an empirical 
research on agile software development companies' practices, evidencing how 
agile methods are applied during the software development process. In 
particular, we describe how the refactoring activity is performed in groups, 
featuring a collaborative practice yet unexplored. 
Resumo. Constantes alterações, adaptações e adições de novos requisitos em 
sistemas são frequentes no mercado de software, o que faz com que as 
empresas necessitem de técnicas cada vez melhores para se adequarem a 
essas mudanças. Nesse contexto, as metodologias ágeis têm se mostrado 
adequadas. O objetivo deste artigo é apresentar resultados parciais de um 
estudo empírico que visa identificar como são aplicadas as metodologias 
ágeis no processo de desenvolvimento e manutenção de sistemas. Em especial 
a atividade de refatoração, que nesse tipo de metodologia é realizada 
normalmente em grupo, caracterizando uma prática colaborativa ainda pouco 
explorada. 
1. Introdução 
Organizações de desenvolvimento de software geralmente enfrentam grandes desafios 
na produção de seus sistemas. Grande parte disso está relacionado à volatilidade de seus 
requisitos (Beck, 2000), (Boehm e Turner, 2005), (Pikkarainen et al., 2008). Novas 
funcionalidades são solicitadas constantemente, bem como mudanças parciais no 
produto e até mesmo a exclusão das mesmas, causando impacto imediato no sistema a 
ser produzido. Com isso, as organizações têm a necessidade de se adaptar rapidamente à 
mudanças. Neste contexto as metodologias ágeis podem auxiliar essas organizações a 
obter o dinamismo necessário para acompanhar as mudanças de requisitos mais 
rapidamente. Essa realidade tem se destacado no mercado produtor de software, onde 
cada vez mais, as metodologias ágeis ganham espaço (Miller, 2009). 
No ano de 2001, dezessete pesquisadores da área de métodos ágeis se reuniram e 
propuseram um framework comum a todas as metodologias, chamado “Manifesto para 
Desenvolvimento Ágil de Software” (Agile Manifesto, 2001). Assim, apesar da 
50
existência de inúmeras metodologias, todas possuem premissas em comum. Algumas 
destas premissas envolvem a colaboração frequente entre os membros do time, como, 
por exemplo, o planejamento conjunto e a programação em pares, sugerindo um amplo 
potencial de pesquisa que não tem sido efetivamente explorado. Entre as exceções 
podem-se citar os trabalhos de Chong e Siino (2006), Whitworth e Biddle (2007), Dybå 
e Dingsøyr(2008) e Lindvall ET AL (2002) 
Com a divulgação do Manifesto Ágil, metodologias como Adaptive Software 
Development (ASD) (Highsmith e Cockburn, 2001), SCRUM (Schwaber e Beedle, 
2002) e eXtreme Programming (XP) (Beck e Andres, 2004) ganharam um grande 
número de adeptos e se tornaram objeto de pesquisas acadêmicas (Cohen et al., 2004). 
As metodologias ágeis possuem métodos, práticas e técnicas que podem aumentar a 
satisfação do cliente (Boehn e Turner, 2003), além de produzir um sistema com maior 
qualidade e em menor tempo (Anderson, 2003). Elas podem também prover: melhorias 
no processo de desenvolvimento, respostas rápidas a mudanças de requisitos e 
incentivos à colaboração e comunicação entre os stakeholders (Karlström e Runeson, 
2006), (Pikkarainen et al., 2008), (Fowler, 2001). 
Este artigo relata resultados preliminares de um estudo empírico realizado em 
empresas de desenvolvimento de software que utilizam metodologias ágeis. Para a 
condução do estudo foi utilizado o método qualitativo Teoria Fundamentada em Dados 
(Glaser e Strauss, 1967). Este método foi escolhido devido à necessidade dos autores de 
compreender um fenômeno específico em profundidade e também porque ele possui um 
caráter exploratório, já que existe a necessidade de compreender o comportamento das 
organizações produtoras de software para identificar pontos positivos, negativos e 
oportunidades de melhorias na utilização destas metodologias. 
Este estudo teve como base as seguintes questões de pesquisa principais: Como 
é aplicada a metodologia ágil nas empresas de software? Quais são as mudanças na 
forma como as atividades são realizadas por equipes que utilizam métodos ágeis, em 
relação à forma como são realizadas nas metodologias tradicionais no contexto de 
organizações brasileiras? No entanto no decorrer do estudo, algumas questões 
adicionais foram especificadas. 
O artigo está organizado da seguinte forma: a seção 2 trata da metodologia 
utilizada no estudo. A seção 3 caracteriza o estudo e suas variáveis. A seção 4 apresenta 
os resultados encontrados e uma discussão do trabalho e por fim a seção 5 trata das 
contribuições, limitações e trabalhos futuros. 
2. Materiais e Métodos 
2.1. Contexto das Empresas 
A coleta de dados para basear o estudo foi realizada a partir da condução de vinte e duas 
entrevistas semiestruturadas, em quatro empresas produtoras de software, situadas nos 
estados do Pará e Pernambuco. Neste estudo foram entrevistados informantes com 
perfis de desenvolvedores, analistas de testes, analistas de requisitos, líderes de equipe, 
arquitetos, scrum masters e product owner, com diversos níveis de experiência, 
selecionados segundo uma amostragem representativa de cada equipe das empresas. Por 
questões de sigilo os nomes das empresas serão preservados e identificados apenas 
como empresa I, empresaII, empresa III e empresa IV. 
51
Todas as empresas utilizam a metodologia ágil SCRUM como base de seu 
processo de desenvolvimento, incorporando também práticas de outras metodologias 
ágeis como: XP (Extreme Programming), FDD (Feature Driven Development), 
utilizando também gráficos como o burndown chart e Gantt chart (Schwaber, 2004). 
Outra característica em comum encontrada nas empresas é a organização do 
ambiente físico de trabalho. Todas possuem ambientes similares, com uma sala de 
convivência onde os colaboradores têm a liberdade para circular a qualquer momento. 
Este ambiente normalmente é utilizado para conversas informais, esclarecimentos de 
dúvidas, no planejamento de suas atividades e nas reuniões diárias (Daily Meeting) 
localizado próximo a sala de desenvolvimento, inspirado no ambiente descrito por 
(Sharp e Robinson, 2004), segundo o scrum master de uma das organizações 
Em todas as empresas foram observadas as seguintes características: (i) a 
utilização do quadro KANBAN (Kinoshita, 2008); (ii) o desenvolvimento de sistemas 
de forma colocalizada (ou seja, toda a equipe de desenvolvimento está localizada na 
mesma cidade); (iii) a baixa experiência em metodologias ágeis pelas equipes de 
desenvolvimento antes da adoção das mesmas pela empresa, o que demandou a 
realização de treinamentos na metodologia; (iv) a larga experiência da maior parte dos 
desenvolvedores nas linguagens de programação utilizadas; (v) o baixo índice de 
rotatividade de colaboradores (exceto em uma das empresas), em três das empresas 
pesquisadas não havia perda de funcionários há dois anos; (vi) a clara definição de 
papéis de desenvolvimento; e, finalmente (vii) o desenvolvimento é realizado em pares. 
A empresa I tem foco no desenvolvimento de sistemas por encomenda de 
pequeno e médio porte, atuando em diversos seguimentos (saúde, serviços, 
universidades, dentre outros). Ela produz sistemas para plataformas web e desktop 
utilizando as linguagens Java e .NET em suas aplicações e possui cerca de 20 
colaboradores. 
A empresa II atua na produção de sistemas para área da saúde. Ela possui um 
sistema legado produzido com a linguagem Delphi, que encontra-se na fase de 
manutenção e produz também novos módulos para esse sistema. A empresa possui oito 
colaboradores na área de desenvolvimento de novos módulos e 12 colaboradores na área 
de suporte e manutenção do sistema legado. 
A empresa III possui um sistema de médio porte de gerenciamento de fila de 
atendimento, esse sistema foi desenvolvido em Delphi e está em fase de manutenção. 
Esta empresa possui seis colaboradores que realizam manutenções no sistema. Existe 
um planejamento para migrar este sistema para a tecnologia Java, porém ainda em fase 
inicial. 
A empresa IV é um órgão publico do estado e possui diversos sistemas, tanto 
na fase de manutenção quanto na fase de desenvolvimento. Nesta empresa foi escolhido 
um sistema de gerenciamento de processos interno de grande porte. Este sistema esta 
sendo desenvolvido por 26 colaboradores com a linguagem de programação Java. 
2.2. Coleta e Análise de dados 
O método selecionado para auxiliar a realização da análise qualitativa foi a Teoria 
Fundamentada em Dados (do inglês, Grounded Theory) (Glaser e Strauss, 1967). A 
teoria fundamentada em dados tem por objetivo gerar, validar ou elaborar uma teoria 
52
por meio de coleta e análise realizadas de forma sistemática sobre um determinado 
fenômeno social a ser estudado (Bandeira-de-mello e Cunha, 2006). Nessa teoria são 
realizadas intercaladamente coleta e análise dos dados, onde as hipóteses são 
formuladas, avaliadas e delimitadas através da reformulação das questões e da próxima 
etapa de coleta de dados. 
Segundo Stratuss e Corbin (1998) um estudo utilizando a teoria fundamentada 
em dados deve ser divido em sete etapas. Na primeira etapa do estudo o pesquisador 
deve definir claramente o escopo da pesquisa, identificando quais são as questões de 
pesquisas pertinentes ao estudo, em qual contexto pode ser aplicado o estudo, qual o 
fenômeno que deve ser estudado, entre outros. 
Após a definição do escopo do estudo, é necessário definir qual o método de 
coleta de dados. Nesta etapa deve se analisar qual método de coleta é mais coerente com 
a pesquisa a ser conduzida, verificando viabilidade de aplicação da coleta e a 
abrangência da mesma. Como mencionado na seção anterior, foi utilizado o método de 
entrevistas semiestruturadas para coleta dos dados para a pesquisa aqui descrita. Neste 
tipo de entrevista um roteiro básico de questões é proposto, possibilitando o informante, 
expor seus pensamentos, experiências, visões ou ponto de vista, sobre determinado 
assunto. Cabe ao entrevistador realizar mais questionamentos sobre o assunto em 
questão, para melhor compreende o problema em questão (Triviños, 1987). 
O roteiro de entrevistas é composto por 59 questões abertas, que serviram 
como base inicial para guiar as entrevistas, no entanto em alguns casos foi necessária a 
realização de mais questões, com o intuito de obter maiores esclarecimentos sobre 
determinado assunto. Todas as entrevistas foram gravadas e transcritas para análise. 
As etapas de codificação têm como propósito dar um nome, ou código1, a um 
fenômeno de interesse ao pesquisador, como forma de abstrair um evento, ação ou 
interpretação de um significado. Nessa etapa os dados são divididos, conceituados e 
suas relações são estabelecidas (Strauss e Corbin, 1998). Segundo Glaser (1978) 
existem duas formas de codificação, a substantiva, realizada através da técnica de 
codificação aberta e codificação seletiva, e a codificação teórica que é realiza através da 
codificação axial. 
A etapa de codificação aberta dos dados da pesquisa descrita no artigo foi 
realizada a partir da definição de categorias (códigos) e subcategorias relativas ao 
estudo, identificação da ocorrência dessas categorias e subcategorias examinando linha 
a linha dos dados coletados e anotação de memorandos (memos) que emergiram na 
análise (Triviños, 1987). 
Para auxiliar na tarefa de codificação (atuando em todas as etapas de 
codificação) dos dados coletados foi utilizada a ferramenta MAXqda2 (Maxqda2, 
2007), que possibilita a aplicação e agrupamento das categorias e subcategorias sobre os 
dados coletados, a rastreabilidade e a geração da rede de impacto entre as categorias 
geradas. 
A fase de codificação axial tem como objetivo relacionar e agrupar as 
 
1 Um código é uma representação abstrata de determinado fator ou característica. Normalmente formado 
por uma palavra, ou um conjunto delas, responsável por identificar, ressaltar ou categorizar determinada 
característica notada pelo estudo. Um código pode representar uma subcategoria do estudo, enquanto um 
conjunto de código, ou abstração de um conjunto, representa uma categoria. 
53
categorias e subcategorias criadas na etapa anterior, analisando também a implicação 
deste agrupamento. A Figura 1 apresenta os códigos obtidos para este estudo após o 
agrupamento. 
 
Figura 1. Árvore de Codificação Axial da Pesquisa Qualitativa 
A etapa de codificação seletiva realiza o refinamento dos códigos. Nessa etapa, 
o processo de codificação é refinado provendo a questão central a qual todos os códigos 
estão relacionados. Essa questão central sumariza e relaciona todos os códigos com o 
fenômeno indicando suas implicações, causa e efeito e suas características que serão 
insumos para próxima etapa. Vale ressaltar que a teoria fundamentada em dados tem um 
processo iterativo, onde intercaladamente são realizadas: coletas e analise dos dados e 
aprimoramento da teoria, bem como dos códigos e do guia de entrevista, com o intuito 
de refinar e aprimorar a teoria proposta. Neste estudo foram realizadas três etapas de 
coletas e análises dosdados intercaladas. A questão central deste estudo é representada 
pelo rótulo Metodologia Ágil, onde todos os rótulos estão relacionados, conforme visto 
na figura 1. 
A etapa seguinte à codificação é a de amostragem teórica, onde são realizadas 
comparações entre a base de dados já codificada com os resultados de novas coletas de 
dados, para avaliar a consistência da teoria a ser gerada. Esta comparação é de suma 
importância, pois é ela que avalia a construção da teoria, auxiliando a indicar também a 
saturação teoria do tema. Por fim a atividade de elaboração da teoria e auditagem. Etapa 
está responsável por avaliar a teoria e o processo de construção da teoria. 
A aplicação da teoria fundamentada em dados permitiu atribuir significado a 
um grande volume de dados desestruturados (nesse caso, as entrevistas transcritas) 
obtidos na fase de coleta. Este estudo encontra-se em fase de refinamento. As etapas de 
amostragem teórica, saturação teórica e critérios de avaliação e auditagem do processo 
ainda não foram realizadas, uma vez que a pesquisa encontra-se em andamento. 
3. Refatoração: Aspectos encontrados 
Após a realização da coleta de dados e a utilização da teoria fundamentada em dados, 
obteve-se um entendimento mais preciso sobre o cenário das empresas estudadas. Com 
isso, foi possível identificar alguns pontos interessantes relativos à adoção de uma 
abordagem mais colaborativa das atividades, neste caso, a refatoração. 
Dentre os resultados encontrados no estudo, este artigo irá abordar a mudança 
54
na atividade de refatoração quando realizadas por equipes que utilizam métodos ágeis, 
em relação à forma como são realizadas nas metodologias tradicionais. Na subseção a 
seguir é apresentado um dos resultados encontrados nesse estudo, junto com trechos das 
entrevistas evidenciando a caracterização aplicada, bem como uma discussão acerca das 
práticas identificadas. 
3.1. Resultados 
A prática da refatoração visa realizar alterações no software sem modificar o 
comportamento externo do mesmo, modificando apenas a estrutura interna do código 
(Fowler, 1999). Ela é vista como um meio para organização de código-fonte, utilizando 
um padrão/estilo de codificação próprio da empresa, provendo melhor clareza e 
legibilidade. Um desenvolvedor da empresa I e outra da empresa IV afirmam que: 
“O que nos motiva justamente é clareza (...) retirada de código extenso. (...) melhorar a 
compreensão do código” 
Sendo esta prática ressaltada pelos desenvolvedores e pelo scrum master das 
empresas II e III. 
“É a facilidade de manutenção porque se for um pouco mais claro, você faz com que alguém 
que for dar manutenção ou colocar alguma coisa a mais ali, não tenha muitos problemas e seja 
mais rápido, seja mais ágil” 
Essa prática também é utilizada para prover escalabilidade, reutilização e para 
melhorar o desempenho do software, conforme relata o desenvolvedor da empresa I: 
“Nós demos esse olhar interno para o código, aí a gente pensou em melhorar, com a aplicação 
padrões, pra melhorar o desempenho e também a escalabilidade do sistema. (...) E outra coisa 
importante também é reutilização dos componentes” 
A partir das analises das entrevistas, nota-se que as atividades relacionadas à 
identificação da necessidade de refatoração no código-fonte são sempre realizadas de 
forma individual e manual, ad-hoc (variando de acordo com a experiência do 
desenvolvedor ou senso comum), através de leitura e/ou inspeção de código (Campbell 
e Miller, 2008). 
No entanto, Campbell e Miller (2008) ressaltam que a inspeção de código é 
uma tarefa propensa a erros, já que pode variar conforme a experiência do 
desenvolvedor que a realiza. Os desenvolvedores da empresa III ressaltam que: 
“Geralmente é pelo cheiro mesmo (bad smell - conceito de (Fowler, 1999)). Tem vez que o 
código está grande demais, normalmente na primeira leitura já conseguimos identificar onde 
refatorar (...) quando está grande demais a gente já desconfia. E quando está muito 
pulverizado”. 
Segundo um programador da empresa IV as atividades de identificação da 
necessidade de refatoração ocorrem de forma similar às empresas II e III, conforme o 
trecho abaixo: 
“Geralmente primeiro nós codificamos pra funcionar o que o cliente pediu. Depois que está 
funcionando, a gente tenta otimizar. Deixar o código mais escalável, mais fácil pra gente alterar 
depois”. 
Neste ponto, é importante ressaltar que a etapa de execução da refatoração é 
realizada em pares, similar ao pair programming, ou em grupo. Segundo os 
entrevistados, a etapa de inspeção de código é a única a ser realizada individualmente. A 
partir desta etapa todas as atividades devem ser realizadas em conjunto. Tem-se como 
55
exemplo o ocorrido na empresa II: 
“Geralmente, quando vai refatorar, não refatora só. É sempre pair programming, a gente senta 
– senta dois ou três desenvolvedores e faz a refatoração”. 
Prática também utilizada pelos colaboradores das empresas I e IV: 
“A refatoração sempre é realizada em conjunto, porque sempre tem um que sabe mais de 
determinado código, daí sempre ajuda se tiver todo mundo”. 
Vale ressaltar que a refatoração citada pelos desenvolvedores, são refatorações 
do tipo estruturais. Estas refatorações alteram a arquitetura do sistema, tendo como, por 
exemplo, a aplicação de um padrão de projeto (Fowler, 1999). Em refatorações onde a 
arquitetura do sistema será pouco afetada, como por exemplo, renomear um método 
variável ou classe, o desenvolvedor realiza individualmente, já que são consideradas 
refatorações triviais. Como explicado pelos desenvolvedores das empresas I, III e IV: 
“Quando a gente identifica que a refatoração é pequena, trivial, a gente faz logo ela. Aquelas 
refatorações mais simples, como mover um método ou renomear alguma variável. (...) Nós só 
refatoramos em equipe aquelas refatorações, complexas, aquelas que têm que mexer com a 
arquitetura do sistema ou quando tem que aplicar algum Design Patterns (...)”. 
3.2. Discussão 
A partir da observação, encontrada em quase todas as empresas, de que a atividade de 
refatoração também é uma atividade colaborativa, os autores realizaram uma revisão 
bibliográfica visando identificar possíveis ferramentas de apoio a refatoração que 
auxiliem na realização da mesma de maneira colaborativa. Entretanto, nenhuma 
ferramenta foi encontrada. Como exemplo de ferramentas que auxiliam a refatoração da 
forma tradicional foram encontradas: TREX (Baker e Evans, 2006) e CIDE (Kästner, 
Apel e Kuhlemann, 2008), entre outras. 
Este aspecto sugere que a comunidade de Engenharia de Software e também a 
de Sistemas Colaborativos pode auxiliar, de maneira significativa, as empresas 
nacionais. Há uma necessidade de criação ou modificação de ferramentas para auxiliar 
na atividade de refatoração em par ou em grupo, apoiando desde a fase de planejamento 
ate a execução. 
Vale ressaltar que a atividade de refatoração do sistema como comumente 
relatada na literatura é de forma individual (Fowler, 1999) e não de maneira 
colaborativa. A característica de código coletivo e programação em par, oriundas da 
metodologia ágil XP, apontam mudanças na forma com que estas atividades são 
realizadas pelo método tradicional, evidenciando a uma mais colaborativa do que 
individual. 
Um fator problemático encontrado a partir do estudo foi o desconhecimento de 
ferramentas que auxiliem na execução de refatoração por todas as empresas estudadas. 
Haja vista que nesta última década foi realizado um grande esforço em termos de 
produção de ferramentas, modelos e técnicas para auxiliar na atividade de refatoração e 
a criação de workshops específicos para promoção de ferramentas voltadas à 
refatoração como o WRT (Workshop on Refactoring Tools) (desde 2007). 
Como pode-se observar nas afirmações abaixo tem-se fortes indícios de quenão há absorção das técnicas desenvolvidas na academia pela indústria produtora de 
software nesta área. Segundo os desenvolvedores da empresa III: 
56
“Na verdade não existe ferramenta para fazer a refatoração (...) É porque eu não imagino o 
caso de uma ferramenta que consiga pegar duplicidade de código, essas coisas, pra ajudar a 
refatorar”. 
Este problema também ocorre nas empresas paraenses, segundo confirmação 
de desenvolvedores: 
“Não lembro que exista nenhuma desse tipo (...) Além do mais temos uma carência nesta área, 
quase nada é produzido para auxiliar [esta atividade]”. 
Outro fator problemático notado é a falta de planejamento nas atividades de 
refatoração. Constatou-se que na maioria das vezes a refatoração é identificada de forma 
ad-hoc e realizada logo após sua identificação, não sendo realizadas tarefas como: 
análise de impacto de mudanças em artefatos, estimativa de tempo e esforço requerido 
para esta nova atividade, documentação de mudanças realizadas ou qualquer registro 
dessa tarefa. Este fator foi identificado na empresa II: 
“Nosso trabalho é assim, quando a gente acha algum lugar que precisa de refatoração, a gente 
faz logo, se não der pra fazer na hora por causa do tempo, a gente deixa pra fazer num dia mais 
folgado”. 
Isto ocorre também na empresa III: 
“Não, infelizmente a gente não cria uma nova estória para as refatorações por isso que às vezes 
elas não são feitas (...) já houve sprints, que a gente viu que foi gasto muito tempo com 
refatoração, daí a gente desistiu dela e teve outro (sprint) que a gente começou a mudar e foram 
surgindo novos problemas na hora de integrar, daí nos voltamos atrás”. 
Sendo um senso comum, entre as empresas estudadas, que: 
“As refatorações para facilitar a reutilização, são as mais pesadas, gastam mais tempo e são 
mais complexas”. 
A atividade de refatoração colaborativa reafirma valores colaborativos na 
produção de software, uma vez que para realizar esta atividade é necessária a 
comunicação, iteração e principalmente colaboração entre os desenvolvedores. Outra 
característica das metodologias ágeis que corrobora com a ideia de colaboração é a 
noção do código fonte como algum coletivo, onde todos os desenvolvedores são autores 
de todo o código fonte. Esta característica promove a familiaridade dos desenvolvedores 
com o código fonte propiciando que todos auxiliem em decisões para modificá-lo. 
4. Considerações Finais 
A aplicação de metodologias ágeis no desenvolvimento de software é um tema 
relativamente recente, e que desponta atualmente como foco de grande interesse, tanto 
da indústria, como da academia. Em vista disso, o desenvolvimento deste trabalho teve 
como objetivo contribuir com o avanço no conhecimento sobre o assunto, buscando 
aprofundar-se principalmente nas mudanças de paradigma advindas da utilização de 
novas metodologias, técnicas e ferramentas na produção de software, com foco na 
atividade de refatoração. Para isso, foi realizado um estudo empírico, que utilizou a 
metodologia fundamentada em dados como método de análise. 
Apesar dos resultados ainda preliminares obtidos, este estudo pôde identificar 
algumas práticas em comum seguidas pela maioria das empresas que retornam bons 
resultados, como, por exemplo, incentivo a comunicação, inspeção de código, 
programação em par e refatoração. Por outro lado, também foram identificadas a falta 
de algumas práticas importantes como, por exemplo, testes automatizados, bem como 
57
observou-se a utilização incompleta de práticas fundamentais, como a refatoração. 
Pôde-se notar também que apesar do esforço empregado pela academia no 
desenvolvimento de ferramentas, técnicas e metodologias para auxiliar no 
desenvolvimento de software, a indústria não tem absorvido esses produtos de forma 
ampla, o que pode ser um fator determinante para grande parte dos problemas ocorridos. 
Em particular, a observação de que a atividade de refatoração é uma atividade 
colaborativa, enquanto que a literatura prévia sobre o assunto descreve a mesma como 
uma prática individual é bastante relevante e será explorada mais amplamente no futuro. 
Outra característica colaborativa é o incentivo a comunicação, realizada por diversas 
práticas da metodologia ágil. Práticas estas fundamentais no processo de 
desenvolvimento do projeto para alcançar maior qualidade no produto gerado e maior 
satisfação do cliente. 
Pretende-se obter como resultado final deste trabalho a definição de uma teoria acerca 
da abordagem diferenciada das atividades de desenvolvimento de software em 
organizações ágeis, principalmente em relação à atividade de refatoração. Atualmente 
este trabalho encontra-se na fase de amostragem teórica. Esta comparação é de suma 
importância, pois é ela que avalia a construção da teoria. Para a elaboração desta teoria 
ainda é necessário à realização de mais algumas entrevistas, possibilitando a 
comparação entre as amostras e chegar à saturação teórica do assunto. 
Alem disso será necessário realizar a pesquisa com um questionário (Survey), 
com o intuito de obter um maior número de respostas sobre temas específicos 
selecionados a partir da primeira etapa da pesquisa em questão. Este questionário é 
composto de perguntas demográficas, informações de experiência do respondente e de 
ambiente de trabalho e principalmente perguntas sobre a atividade de refatoração, com o 
intuito de pretende-se explorar a atividade de refatoração enquanto prática colaborativa. 
Agradecimentos 
Esta pesquisa tem financiamento do CNPq através do Edital Universal 2008, 
processo: 473220-2008/3, da CAPES e da Fundação de Amparo à Pesquisa do Estado 
do Pará (FAPESPA) através do Edital Universal N.° 003/2008. Os autores agradecem 
também a UFPA pelo apoio financeiro ao primeiro autor. 
5. Referências 
Agile Manifesto, “Manifesto for Agile Software Development”, 2001 
Anderson D. J, “Agile management for software engineering, applying the theory and 
constraints for business results.” Prentice Hall, Upper Saddle River, NJ, 2003 
Baker P, Evans D, “TRex – The Refactoring and Metrics Tool for TTCN-3 Test 
Specifications”, TAIC PART'06, Windsor, United Kingdom, 2006 
Bandeira-de-mello, R., Cunha, C, "Grounded Theory: Pesquisa Qualitativa em Estudos 
Organizacionais: Paradigmas, Estratégias e Métodos”, São Paulo, 2006 
Beck K, “Extreme programming explained: embrace change.” Addison-Wesley 
Longman, Boston, MA, 2000 
Beck K, Andres C, “Extreme programming explained, embrace change”, Addison-
Wesley, Boston, 2004 
Beck, K (2002) Test-Driven Development: By example, Addison- Wesley. 
58
Boehm B, Turner D, “Management challenges to implement agile processes in 
traditional development organizations.” IEEE Software, 2005 
Boehm B, Turner D, “Using risk to balance agile and plan-driven methods.” IEEE 
Comput, 2003 
Campbell D, Miller M, “Designing refactoring tools for developers.” Proceedings of the 
2nd Workshop on Refactoring Tools. Nashville, Tennessee, ACM, 2008 
Chong J, Siino R, “Interruptions on Software Teams: A Comparison of Paired and Solo 
Programmers”, Conference on Computer supported cooperative work, Canada, 2006 
Cohen, D., Lindvall, M., & Costa, P, “An introduction to agile methods.” In Advances 
in Computers (pp. 1-66). New York: Elsevier Science, 2004 
Dybå, T. and Dingsøyr, T. 2008. “Empirical studies of agile software development: A 
systematic review.” Inf. Softw. Technol, 2008Fowler, M. “Is Design Dead?. 
Appeared in Extreme Programming Explained.” Addison-wesley, 2001 
Fowler, M. “Refactoring - Improving the Design of Existing Code.” Addison, 1999 
Glaser B, Strauss A, “The discovery of grounded Theory.” Aldine de Gruyter, NY, 1967 
Glaser, B, “Theoretical sensivity”. Mill Valley: Sociology Press, 1978 
Highsmith, J. A. Cockburn, “Agile Software Development, The Business ofInnovation”, 
Computer, September 2001, pp. 120-122, 2001 
Karlström D, Runeson P, “Integrating agile software development into stage-gate managed 
product development.” Empir Softw Eng 11(2):203–225, 2006 
Kästner C, Apel S, Kuhlemann M, “Granularity in Software Product Lines”, ICSE’08, May 10–
18, 2008, Leipzig, Germany 
Kinoshita, F, “Practices of an Agile Team” Agile 2008 Conference, Canadá, 2008. 
Lindvall M., Basili V., Boehm B., Costa P., Dangle K., Shull F., Tesoriero R., Williams 
L., Zelkowitz M., “Empirical Findings in Agile Methods Source”, XP/Agile 
Universe, 2002. 
Maxqda2, http://www.maxqda.com/, 2007 
Miller L, Sy D, “Agile user experience SIG”, Conference on Human Factors in 
Computing Systems, Boston, 2009 
Pikkarainen M, Haikara J, Salo O, Abrahamsson P, Still J, “The impact of agile 
practices on communication in software development”, Empirical Software 
Engineering, 2008 
Schwaber K, “Agile Project Management with Scrum.” Microsoft Press, 2004 
Schwaber K, Beedle M, “Agile software development with SCRUM.” Prentice-Hall, Upper 
Saddle River, NJ, 2002 
Sharp H, Robinson H, “An Ethnographic Study of XP Practice”. Empirical Software 
Engineering, 2004 
Strauss, A e Corbin J, “Basics of qualitative research.” Thousands Oaks, CA, 1998 
Triviños, A, “Introdução à pesquisa em ciências sociais.” São Paulo, Atlas, 1987. 
Whitworth E, Biddle R, “Motivation and Cohesion in Agile Teams”, Conference on Agile 
processes in software engineering and extreme programming, 2007 
Zimmermann T, Sillito J, Premraj R, Breu S, “Information Needs in Bug Reports: 
Improving Cooperation Between Developers and Users”, CSCW, 2010 
59
Aplicando Te´cnicas de Grounded Theory e Retrospectiva A´gil
para Buscar Melhorias para o Curso Laborato´rio XP
Viviane A. Santos1, Alfredo Goldman1
1Instituto de Matema´tica e Estatı´stica (IME) – Universidade de Sa˜o Paulo (USP)
Caixa Postal 66281 – CEP 05315-970 – Sa˜o Paulo – SP – Brasil
{vsantos, alfredo}@ime.usp.br
Resumo. Este artigo apresenta um estudo empı´rico sobre o aprendizado de eX-
treme Programming em ambiente acadeˆmico. O estudo emprega duas aborda-
gens distintas para triangulac¸a˜o dos dados: ana´lise qualitativa com grounded
theory em um questiona´rio e retrospectiva a´gil para investigar o que o curso
precisa melhorar na visa˜o dos alunos. A partir dos resultados, ac¸o˜es de melho-
ria mais direcionadas foram estabelecidas para as pro´ximas edic¸o˜es.
Abstract. This paper presents an empirical study about learning eXtreme
Programming in an academic environment. The study employs two distinct
approaches to provide triangulation of the data: qualitative analysis with
grounded theory in a questionnaire and agile retrospective to investigate what
to improve in the course in the students point of view. From the results, specific
improvement actions were established for the next editions of the course.
1. Introduc¸a˜o
Em 2001, os me´todos a´geis foram formalmente apresentados pelo Manifesto A´gil
[Beck et al. 2001] e, desde enta˜o, teˆm recebido muita atenc¸a˜o da indu´stria e da academia
por revelar formas efetivas de desenvolver software.
O movimento pela agilidade no desenvolvimento de software tem provo-
cado uma quantidade substancial de debates e publicac¸o˜es. No entanto, dentro
do estado da arte de evideˆncias empı´ricas, este assunto ainda se mante´m escasso
[Dyba˚ et al. 2010]. Ha´ poucos estudos com rigor metodolo´gico neste campo e a maio-
ria dos esforc¸os cientı´ficos existentes encontra-se no aˆmbito de eXtreme Programming
(XP) [Beck and Andres 2004].
[Dyba˚ et al. 2010] relatam que, em ambiente acadeˆmico, a programac¸a˜o em pares
tem promovido reduc¸a˜o de 40-50% do tempo estimado para completar uma tarefa, au-
mento da satisfac¸a˜o no trabalho e qualidade de co´digo. Ao contra´rio disto, TDD (Test-
Driven Development) [Beck 2003] tem dispendido maior tempo para a implementac¸a˜o
(uma me´dia de 16%), assim como teste antes de codificar (Test-First Programming) na˜o
acelera a implementac¸a˜o. Segundo eles, a eficieˆncia na programac¸a˜o em pares depende
da experieˆncia do programador e da complexidade do sistema e das tarefas envolvidas.
1.1. Motivac¸a˜o e Objetivo de Pesquisa
A motivac¸a˜o desta pesquisa consiste no interesse dos responsa´veis pelo curso de XP da
instituic¸a˜o em melhora´-lo para as pro´ximas edic¸o˜es atrave´s de feedback dos alunos. A
estrate´gia utilizada para atingir este objetivo considerou duas abordagens distintas:
60
1. Realizac¸a˜o de pesquisa qualitativa atrave´s da ana´lise de respostas dos alunos a um
questiona´rio na˜o estruturado com questo˜es abertas1;
2. Retrospectiva final do curso com a participac¸a˜o de todos os integrantes (professor,
meta-coaches, meta-tracker, coaches e desenvolvedores).
Este artigo apresenta um estudo empı´rico que investiga o que o curso precisa me-
lhorar atrave´s da aplicac¸a˜o de te´cnicas de um me´todo de pesquisa cientı´fico em dados
de um questiona´rio e da ana´lise do relato´rio da retrospectiva final. A Sec¸a˜o 2 descreve
o curso mencionado. Na Sec¸a˜o 3 e´ apresentada a primeira abordagem realizada com os
alunos do curso, incluindo o uso de te´cnicas de grounded theory para a ana´lise qualitativa.
Ja´ na Sec¸a˜o 4 e´ relatada a segunda abordagem que corresponde a retrospectiva final. A
corroborac¸a˜o dos resultados destas abordagens diferentes e´ a contribuic¸a˜o mais relevante
deste artigo. Finalmente, na Sec¸a˜o 5 sa˜o apresentadas as ac¸o˜es de melhoria, as concluso˜es
e os trabalhos futuros.
2. Laborato´rio XP: Contexto do Curso
Desde 2001 [Goldman et al. 2004], o curso denominado Laborato´rio XP tem ofere-
cido aos alunos, de graduac¸a˜o e de po´s-graduac¸a˜o em cieˆncia da computac¸a˜o, uma
aproximac¸a˜o a` realidade de um projeto de desenvolvimento a´gil de software.
O curso conta com 1 professor, 3 meta-coaches e 51 alunos, sendo 9 coaches (den-
tre eles 1 meta-tracker), que correspondem a alunos mais experientes ou que ja´ conhecem
a metodologia, e 42 desenvolvedores integrantes de 8 equipes que conduzem projetos reais
com clientes reais2. Houve um projeto em que atuaram 2 coaches e outro em que o coach
tambe´m atuou como meta-tracker do curso, auxiliando todas as equipes na conduc¸a˜o de
tracking apropriado a`s caracterı´sticas de seus respectivos projetos. O curso tambe´m conta
com a dedicac¸a˜o de 8h semanais dos alunos, por este motivo, almoc¸o e´ oferecido para mo-
tiva´-los a dispor deste tempo para o projeto. O curso disponibiliza toda a infraestrutura
fı´sica e tecnolo´gica necessa´ria, e material para a aplicac¸a˜o da metodologia nos projetos.
Na primeira aula foram apresentados o curso, a forma de avaliac¸a˜o e os projetos.
Cada aluno escolheu ate´ treˆs projetos desejados para a formac¸a˜o das equipes, ale´m disto,
os coaches foram escolhidos. Na segunda e terceira aula, XP foi explicada aos alunos.
Separadamente, os coaches tinham aula com os meta-coaches para aprenderem mais so-
bre como atuar em um projeto a´gil. A partir de enta˜o, os alunos foram apresentados aos
seus respectivos ambientes de trabalho, projetos, coaches e clientes.
3. Primeira Abordagem: Questiona´rio Aberto
A primeira abordagem corresponde a uma pesquisa qualitativa com base em dados
empı´ricos provenientes de um questiona´rio fornecido aos alunos antes do final do curso
a fim de que pudessem expressar com mais fidelidade sua visa˜o sobre o curso. O estudo
realizado objetiva entender, pela o´tica dos alunos, o que precisa ser melhorado no curso.
3.1. Metodologia
A metodologia utilizada nesta abordagem corresponde a` coleta de dados por questiona´rio
e a` ana´lise qualitativa com Grounded Theory (GT) [Corbin and Strauss 2007].
1A forma na˜o-estruturada e indireta do questiona´rio visa incentivar os alunos a projetarem suas opinio˜es,
dificuldades, motivac¸o˜es, crenc¸as, atitudes ou sensac¸o˜essubjacentes sobre os problemas em estudo.
2Para detalhes sobre esta edic¸a˜o do curso acesse: http://www.ime.usp.br/˜gold/cursos/2010/xp2010.html
61
A coleta foi realizada de forma aberta, na˜o obrigato´ria e anoˆnima. Os integrantes
das equipes foram convidados a responder as seguintes perguntas: O que aprendeu? O que
deu certo? O que deu errado? O que poderia melhorar? e entregar suas respostas aos seus
respectivos coaches. Houve equipes em que cada integrante respondeu o questiona´rio,
mas tambe´m houve equipes que responderam o questiona´rio em conjunto e outras que
na˜o tiveram feedback de alguns integrantes, o que resultou em 44 respondentes.
O modo de coleta de dados pode implicar em vie´s de selec¸a˜o, devido a possibili-
dade de omissa˜o dos alunos por se sentirem intimidados em criticar o curso. Pore´m, todas
as equipes forneceram feedback representativo, o que minimizou este vie´s.
Para a ana´lise dos dados qualitativos, GT mais se adequava, devido se fundamentar
nos dados, lidar com fenoˆmenos do comportamento humano e permitir extrair aspectos
significativos do caso em estudo, ao inve´s de so´ transforma´-los em nu´meros.
3.2. Me´todo de Pesquisa Qualitativa Grounded Theory
O me´todo de pesquisa qualitativa denominado Grounded Theory foi criado por
[Glaser and Strauss 1967] com o objetivo de construir teoria indutiva por meio da coleta
e ana´lise interativa e sistema´tica (saturac¸a˜o teo´rica)de dados empı´ricos. Diferentemente
de outros me´todos que usam os dados para avaliar hipo´teses predefinidas, este me´todo
baseia-se nos dados coletados para gerar uma teoria fundamentada nos mesmos.
De acordo com [Urquhart et al. 2010], este me´todo possui quatro caracterı´sticas
fundamentais, que sa˜o: o seu principal propo´sito e´ a construc¸a˜o de teoria; o conhecimento
pre´vio do pesquisador na˜o deve leva´-lo a` hipo´teses pre´-formuladas e nem dificultar o sur-
gimento de noc¸o˜es fundamentadas nos dados; a ana´lise e a conceitualizac¸a˜o sa˜o geradas
atrave´s de processos intercalados de coleta e ana´lise de dados utilizando a comparac¸a˜o
constante; e os co´digos sa˜o selecionados por um processo de amostragem teo´rica.
3.2.1. Protocolo
Conforme [Corbin and Strauss 2007], o protocolo deste me´todo consiste em exami-
nar cada documento fornecido, mais de uma vez e independentemente por mais de
um pesquisador para evitar vie´s, buscando identificar unidades de significados para a
realizac¸a˜o da codificac¸a˜o aberta que, em primeira instaˆncia, procura estabelecer catego-
rias conceituais. Neste passo, e´ necessa´rio consenso entre os pesquisadores.
Em segunda instaˆncia, sa˜o identificados os relacionamentos entre as categorias
conceituais para a realizac¸a˜o da codificac¸a˜o axial. Nesta etapa, e´ necessa´rio definir uma
lo´gica de associac¸a˜o entre as categorias. Para tanto, o me´todo de comparac¸a˜o constante
e´ empregado, trabalhando “para frente e para tra´s” entre as categorias ja´ estabelecidas e
os dados originais com o objetivo de identificar fenoˆmenos relacionados, condic¸o˜es cau-
sais, contextos, estrate´gias de ac¸a˜o/interac¸a˜o e consequeˆncias das ac¸o˜es para desenvolver
categorias nocionais. Gra´ficos podem ser usados para retratar estas relac¸o˜es.
Nesta etapa, tambe´m e´ possı´vel identificar um ou mais fenoˆmenos interessantes
(dimenso˜es) dentro da amostragem teo´rica nos diversos contextos apresentados.
Em terceira instaˆncia, e´ realizada a codificac¸a˜o seletiva para identificar a(s) cate-
goria(s) principal(is), existente ou nova, para desenvolver uma narrativa descritiva (teo-
62
ria) ao redor dela(s). Em seguida, as interpretac¸o˜es da teoria sa˜o validadas e refinadas
atrave´s de integrac¸a˜o teo´rica, que consiste em relacionar a teoria resultante a` outras teo-
rias existentes a fim de gerar confirmac¸o˜es e ate´ formalizac¸o˜es.
3.3. Ana´lise dos Dados
Os dados do questiona´rio foram analisados atrave´s das etapas de codificac¸a˜o aberta e
axial. Para evitar vie´s, cada pesquisador realizou separadamente a codificac¸a˜o e dis-
cordaˆncias foram discutidas ate´ alcanc¸ar consenso.
Como so´ houve uma coleta de dados, a terceira etapa ainda na˜o foi dada como
concluı´da, devido na˜o ter sido atingida a saturac¸a˜o teo´rica. Mesmo assim, foi aplicada a
te´cnica de identificac¸a˜o de uma categoria principal para extrair a visa˜o dos alunos sobre o
curso nesta edic¸a˜o, o que na˜o significa dizer que foi gerada uma teoria, a priori.
De posse da continuidade desta pesquisa, esta visa˜o dos alunos e´ de grande utili-
dade para auxiliar na definic¸a˜o das pro´ximas coletas e ana´lises de dados intercaladas, que,
consequentemente, culminem na gerac¸a˜o de uma teoria fundamentada nos dados.
3.3.1. Codificac¸a˜o Aberta
Nesta etapa foram utilizados co´digos “in vivo” [Corbin and Strauss 2007], ou seja, basea-
dos na terminologia usada pelos informantes. A codificac¸a˜o aberta resultou em uma ma-
triz de 33 categorias conceituais, com exemplos de unidades de significado dos dados
originais e quantidade de ocorreˆncias (#). Por motivos de espac¸o, a Tabela 1 exibe ape-
nas algumas das categorias conceituais extraı´das nesta etapa3. O texto sublinhado e´ uma
pre´via de relacionamento entre categorias conceituais e e´ explicado na sec¸a˜o seguinte.
Como GT estabelece a necessidade de coletas e ana´lises intercaladas, e neste estudo so´
houve uma coleta de dados, ainda na˜o foi possı´vel validar as categorias conceituais.
Table 1. Algumas categorias conceituais selecionadas da codificac¸a˜o aberta
Id Categoria Conceitual Exemplo de Unidade de Significado #
1 Programac¸a˜o em Pares “Trabalho em pares facilita aplicac¸a˜o de boas pra´ticas e evita bugs. Ale´m de
promover que mais de uma pessoa saiba de todas as partes do co´digo”
24
2 Produtividade “Aprendemos a programar com mais agilidade (em termos de pra´tica e
qualidade)”
10
3 Qualidade de Co´digo “A meta de 100% de cobertura de testes e familiarizac¸a˜o com novas tecnologias
(Rails) foram coisas que achei que deram certo, com isso tambe´m conseguimos
desenvolver novas funcionalidades com codigo melhor”
6
4 Trabalho em Equipe “Aprendi a interatuar com o pessoal para trabalhar em colaborac¸a˜o” 53
5 Novas Tecnologias “O aprendizado de muitas novas tecnologias e ferramentas” 63
3.3.2. Codificac¸a˜o Axial
No inı´cio desta etapa, os relacionamentos explicitados pelos alunos foram sublinhados
(Tabela 1). Em seguida, utilizou-se um gra´fico para ajudar na visualizac¸a˜o destes rela-
3Para visualizar detalhes da codificac¸a˜o aberta e a lista de categorias conceituais, acesse
http://www.ime.usp.br/˜vsantos/pesquisa1/
63
cionamentos e na definic¸a˜o da lo´gica destas ligac¸o˜es para gerar categorias nocionais.
Por motivos de espac¸o, a Figura 1 apresenta o grafo resultante minimizado com
os agrupamentos existentes separados por cores4. Primeiramente foram identificados os
cliques5, depois os ciclos6 e por u´ltimo, as ligac¸o˜es simples. Houve categorias, como
por exemplo, “Carga Hora´ria do Curso”, que se relacionaram atrave´s de ligac¸o˜es sim-
ples com diferentes categorias - “Compartilhamento do Conhecimento”, “Novas Tecnolo-
gias” e “Teoria sobre XP” - no entanto, os autores escolheram agrupa´-la a` categoria que
possuı´a maior relevaˆncia dentro do contexto, buscando estar sempre fundamentada nos
dados. Va´rios casos de relacionamento na˜o resultaram em agrupamento, devido a forc¸a
da ligac¸a˜o encontrada nos relatos de determinadas categorias.
Apo´s consenso, foram estabelecidas as categorias nocionais. A Tabela 2 apresenta
o identificador da categoria (Id), seu nome juntamente com a cor referente ao seu agru-
pamento, as categorias conceituais relacionadas, com seus respectivos identificadores a`
esquerda, seguidas pelo nome e pela quantidade de ocorreˆncias entre pareˆnteses. A Figura
1 mostra o grafo resultante com as cores e o Id referenteao agrupamento das categorias.
Figure 1. Relac¸a˜o entre as categorias conceituais
Para facilitar o entendimento de cada categoria nocional gerada pelos relaciona-
mentos de categorias conceituais, a narrativa em torno delas e´ descrita conforme a seguir.
No Jogo do Planejamento, o envolvimento do “Cliente” favorece a efetividade
da “Reunia˜o de Planejamento”, facilitando o entendimento das “Histo´rias” e o projeto
da soluc¸a˜o nas “Reunio˜es Te´cnicas da Equipe” na busca de gerar valor incremental em
“Iterac¸o˜es Curtas”.
Na categoria Refatorac¸a˜o e Testes, os “Testes” influenciam na manutenc¸a˜o do
co´digo e propiciam a coragem para realizar “Refatorac¸a˜o”. Na categoria Fatores Tec-
nolo´gicos, o risco da adoc¸a˜o de “Novas Tecnologias” no projeto influenciou na “Produ-
tividade” da equipe, na “Qualidade de Co´digo” e na aplicac¸a˜o de “Padro˜es de Projeto”, o
qual foi atenuado com “Dojo e Superparing”.
Ja´ na categoria Comunicac¸a˜o e Feedback, o envolvimento da equipe na
4O grafo em tamanho original tambe´m esta´ disponı´vel em http://www.ime.usp.br/˜vsantos/pesquisa1/
5Clique e´ um subgrafo completo que para cada ve´rtice ha´ uma aresta conectando este ve´rtice a cada um
dos demais.
6Ciclo e´ um caminho que comec¸a e acaba com o mesmo ve´rtice.
64
Table 2. Categorias nocionais resultantes da codificac¸a˜o axial
Id Categoria Nocional Categorias Conceituais Relacionadas
1 Jogo do Planejamento (verde) 9) Cliente (30)
10) Reunia˜o de Planejamento (1)
12) Retrospectivas (11)
13) Histo´rias (25)
23) Reunio˜es Te´cnicas da Equipe (8)
25) Iterac¸o˜es Curtas (15)
2 Boas Pra´ticas de Programac¸a˜o (roxo) 31) Boas Pra´ticas de Programac¸a˜o (5)
3 Refatorac¸a˜o e Testes (laranja) 6) Testes (24)
33) Refatorac¸a˜o (8)
4 Comunicac¸a˜o e Feedback (rosa) 1) Programac¸a˜o em Pares (24)
4) Trabalho em Equipe (53)
8) Ambiente Informativo (8)
11) Comunicac¸a˜o (13)
17) Tracking (27)
18) Hora´rios do Curso (4)
19) Almoc¸o (9)
22) Papo em Pe´ (3)
26) Estimativas (21)
30) Comprometimento (5)
5 Fatores Tecnolo´gicos (amarelo) 2) Produtividade (10)
3) Qualidade de Co´digo (6)
5) Novas Tecnologias (63)
27) Dojo e Superparing (4)
32) Padro˜es de Projeto (2)
6 Forma do Curso (azul) 14) Carga Hora´ria do Curso (29)
15) Teoria sobre XP (24)
20) Avaliac¸a˜o (6)
28) Envolvimento do Professor e dos Meta-Coaches (8)
7 Formas de Interac¸a˜o (cyan) 7) Ambiente (9)
21) Reunia˜o de Coaches (5)
24) Compartilhamento de Conhecimento (8)
29) Coach (18)
8 Ambiente de Desenvolvimento (vermelho) 16) Ambiente de Desenvolvimento (10)
“Programac¸a˜o em Pares”, no “Papo em Pe´”, na definic¸a˜o de “Estimativas”, no “Almoc¸o”,
na atualizac¸a˜o do “Ambiente Informativo” e dos gra´ficos de “Tracking”, favorecem a
“Comunicac¸a˜o”, o “Comprometimento” e a pontualidade nos “Hora´rios do Curso” dos
integrantes para o bom andamento do “Trabalho em Equipe”.
A Forma do Curso requer maior “Envolvimento do Professor e dos Meta-
Coaches” e “Carga Hora´ria do Curso”, mais “Teoria sobre XP” e melhor “Avaliac¸a˜o”.
As Formas de Interac¸a˜o entre as equipes na˜o deveriam ocorrer apenas na “Reunia˜o de
Coaches”, devido ao grau de confianc¸a da equipe no “Coach”, assim, um melhor uso do
“Ambiente” ajuda a intensificar o “Compartilhamento de Conhecimento”.
A categoria Ambiente de Desenvolvimento na˜o se encaixou na lo´gica uti-
lizada para as categorias anteriores, no entanto, os alunos relataram sua ligac¸a˜o com
o andamento do projeto, desta forma, utilizando-se da sensibilidade e expertise dos
pesquisadores, conclui-se que Ambiente de Desenvolvimento inapto afeta o andamento
do Jogo do Planejamento. Observe que, atrave´s da comparac¸a˜o constante, foi identifi-
cada uma relac¸a˜o entre duas categorias nocionais.
Da mesma forma, a categoria Boas Pra´ticas de Programac¸a˜o tambe´m na˜o se
ligou fortemente a nenhuma outra categoria a ponto de juntar-se. No entanto, os alunos
65
relataram que facilitam o desenvolvimento e a manutenc¸a˜o do co´digo-fonte. Portanto,
Boas Pra´ticas de Programac¸a˜o tambe´m favorecem o bom andamento do Jogo do
Planejamento, influencia na Comunicac¸a˜o e Feedback, nos Fatores Tecnolo´gicos e na
Refatorac¸a˜o e Testes.
Apo´s a definic¸a˜o das categorias nocionais, conforme o protocolo, o me´todo de
comparac¸a˜o constante e´ aplicado entre as categorias e os dados originais para estabelecer
as dimenso˜es das categorias. A Tabela 3 apresenta as dimenso˜es resultantes.
Table 3. Dimenso˜es das categorias nocionais
Dimenso˜es
Id Categoria Nocional Similaridades Diferenc¸as
1 Jogo do Planeja-
mento
Eficieˆncia gradativa da equipe Acompanhamento das deficieˆncias
no desenvolvimento
2 Boas Pra´ticas de
Programac¸a˜o
Reconhecimento do valor da sua
aplicac¸a˜o
Incentivos a` sua aplicac¸a˜o
3 Refatorac¸a˜o e Testes Valorizac¸a˜o das pra´ticas Grau de dificuldade em aplicar
4 Comunicac¸a˜o e
Feedback
Eficieˆncia gradativa da equipe Acompanhamento das deficieˆncias
no desenvolvimento
5 Fatores Tecnolo´gicos Valorizac¸a˜o dos fatores tec-
nolo´gicos
Nı´vel de experieˆncia em tecnolo-
gias de mercado
6 Forma do Curso Necessidade de maior carga
hora´ria, mais teoria e maior
acompanhamento
Iniciativa dos alunos
7 Formas de Interac¸a˜o Nivelamento do aprendizado Acompanhamento das deficieˆncias
no desenvolvimento
8 Ambiente de Desen-
volvimento
Necessidade de estar inicialmente
apto ao desenvolvimento
Experieˆncia em tecnologias de mer-
cado
3.3.3. Codificac¸a˜o Seletiva
Esta te´cnica de codificac¸a˜o foi aplicada para extrair a visa˜o dos alunos sobre o curso nesta
edic¸a˜o. Isto na˜o implica em teoria, mas em subsı´dio para as pro´ximas estrate´gias de coleta
e ana´lise intercaladas, e para identificar o que o curso precisa melhorar.
Assim, as categorias Jogo do Planejamento, Boas Pra´ticas de Programac¸a˜o,
Refatorac¸a˜o e Testes, Comunicac¸a˜o e Feedback, Fatores Tecnolo´gicos, Forma do
Curso, Formas de Interac¸a˜o e Ambiente de Desenvolvimento podem ser interpretadas
como fatores essenciais ao sucesso do curso. Cada categoria conta parte da histo´ria,
nenhuma captura-a completamente. Por este motivo, um outro termo ou frase abstrata
e´ necessa´ria, uma ide´ia conceitual sob a qual todas as categorias sa˜o incluı´das. Assim,
conclui-se que a categoria principal resultante e´ “Formas de Suporte ao Aprendizado de
XP”.
Desta forma, a linha da histo´ria para melhorar o curso e´ a seguinte: O curso
Laborato´rio XP e´ de grande valor para os alunos, pois proporciona o aprendizado atrave´s
do desenvolvimento a´gil de um projeto de software em um contexto mais pro´ximo da
realidade. No entanto, necessita de mais suporte para um aprendizado mais efetivo de
66
tecnologias, conceitos e pra´ticas; de contı´nua avaliac¸a˜o dos alunos; e de reconsiderac¸a˜o
dos pre´-requisitos e da carga hora´ria do curso.
4. Segunda Abordagem: Retrospectiva Final
Na u´ltima aula do curso foi realizada uma retrospectiva a´gil adaptada com todos os par-
ticipantes objetivando coletar dados e refletir sobre o curso para estabelecer uma visa˜o
compartilhada de melhorias necessa´rias para as pro´ximas edic¸o˜es.
4.1. Metodologia
A dinaˆmica ocorreu em uma sala de aula com sesso˜es de sete minutos para a discussa˜o
civilizada de cada to´pico. O professor e os meta-coaches gerenciavam e registravam as
sesso˜es em um relato´rio. Havendo necessidade de estender a discussa˜o, outra sessa˜o de
sete minutos poderia ser criada, ate´ atingir consenso.
Esta dinaˆmica utilizou uma abordagem disciplinada, devido o grande nu´mero de
participantes e o pouco tempo para discussa˜o (duas horas-aula). Portanto, foram dispostas
cinco cadeiras na frente da sala para que interessados em relatar algo sobre o to´pico em
discussa˜o na sessa˜o pudessem se sentar e expressar sua opinia˜o, em voz alta. As dis-
cusso˜es so´ poderiam ocorrer entre as pessoassentadas nas cadeiras. O restante da sala
deveria ficar em sileˆncio, sem nenhuma conversa paralela. Dentre as cinco cadeiras, sem-
pre deveria haver uma cadeira livre para o pro´ximo interessado em discutir sobre o to´pico.
Portanto, se algue´m se sentasse na cadeira vazia remanescente, uma das quatro pessoas
sentadas, liberaria a sua pro´pria cadeira, visto que ja´ expoˆs sua visa˜o.
Antes de iniciar as sesso˜es, os alunos sugeriram to´picos para discussa˜o (17 temas).
Depois, para cada tema, houve uma votac¸a˜o do nu´mero de interessados na sua discussa˜o.
4.2. Resultados
Por questo˜es de tempo, foram discutidos os cinco temas mais votados na dinaˆmica. A
Tabela 4 lista os temas com o nu´mero de votos entre pareˆnteses, algumas transcric¸o˜es
do relato´rio e o nu´mero de sesso˜es realizadas (#). Sempre que terminava uma sessa˜o,
as considerac¸o˜es registradas pelo meta-coach eram lidas e confirmadas ou alteradas pe-
los participantes ate´ atingir consenso. O relato´rio, gerado a partir da retrospectiva final,
descreve fielmente os pontos tratados na dinaˆmica.
Table 4. Temas abordados na retrospectiva final
Id Tema Transcric¸o˜es do Relato´rio #
1 Parte teo´rica (29) “Espalhar as aulas permitiria ligar teoria a` pra´tica” 1
2 Hora´rios da disciplina e dedicac¸a˜o esper-
ada fora dos hora´rios (25)
“Talvez a disciplina merecesse mais cre´dito e mais
aulas por semana.”
1
3 Aprendizado das tecnologias (16) “Necessidade de muitas tecnologias que na˜o eram
dominadas (ex: Eclipse, Ruby, Rails, Git etc.)”
1
4 Participac¸a˜o dos meta-coaches e do profes-
sor (12)
“Ter mais proximidade entre o grupo e meta-coaches
para ter mais tempo de sentir o que esta´ OK e o que
na˜o esta´”
2
5 Crite´rio de avaliac¸a˜o (10) “Falta de feedback com crite´rios subjetivos deixa
tudo largado. Muito difı´cil melhorar.”
2
67
Os pesquisadores tambe´m atuaram na dinaˆmica como observadores participantes
do caso em estudo. Mesmo discutindo apenas cinco temas, muitos temas relacionados
tambe´m foram mencionados. O que permitiu criar uma noc¸a˜o mais clara das necessidades
mais urgentes do curso proveniente do que foi expresso na dinaˆmica.
Com a ana´lise do relato´rio, baseada na experieˆncia dos pesquisadores, e´ possı´vel
concluir que, na visa˜o dos alunos, e´ necessa´rio mais acompanhamento, apoio e feedback
dos responsa´veis pelo curso em relac¸a˜o a aprendizagem de XP, das tecnologias envolvidas
e de suas deficieˆncias no desenvolvimento do projeto.
5. Conclusa˜o
Dentre as duas abordagens estudadas percebe-se que houve uma intersec¸a˜o entre os as-
suntos tratados. A combinac¸a˜o das abordagens confere triangulac¸a˜o dos resultados.
De acordo com a observac¸a˜o dos participantes, os projetos do curso apresentaram
complexidades variadas, bem como equipes que conseguiram superar os problemas, ou-
tras que superaram parcialmente e outras que na˜o os superaram.
Para tanto, como ac¸o˜es de melhoria, sa˜o propostas soluc¸o˜es conhecidas, como
as dinaˆmicas de Coding Dojo [Sato et al. 2008], retrospectivas e minipalestras com to-
dos os alunos para incentivar a adoc¸a˜o, o aprendizado e o compartilhamento dos valores,
princı´pios e pra´ticas de XP; para prover a exposic¸a˜o mais detalhada do assunto e para
detecc¸a˜o/tratamento das deficieˆncias dos alunos durante o desenvolvimento a´gil de soft-
ware; e para facilitar a preparac¸a˜o do ambiente de desenvolvimento.
Outras ac¸o˜es de melhoria sa˜o o aumento do nu´mero de cre´ditos e, consequente-
mente, da carga-hora´ria do curso; e a reconsiderac¸a˜o da forma de composic¸a˜o das equipes,
conforme [Sfetsos et al. 2009]7, e dos crite´rios das avaliac¸o˜es perio´dicas. Ale´m de contar
com a teoria da auto-efica´cia8, visto que [Endres et al. 2009] revela que, em ambientes
acadeˆmicos, o compartilhamento do conhecimento em um grupo depende da interac¸a˜o
entre auto-efica´cia e conhecimento recı´proco esperado de seus integrantes.
Tendo em vista que o sucesso de um projeto a´gil depende do tipo de projeto e
da equipe, estes devem ser avaliados continuamente durante o curso para proporcionar o
suporte necessa´rio a`s dificuldades enfrentadas.
Este estudo corresponde ao inı´cio de uma pesquisa mais abrangente sobre melho-
ria contı´nua em me´todos a´geis. Como na˜o houve saturac¸a˜o teo´rica, devido a coleta ter sido
feita apenas uma vez e ao final do curso, os pesquisadores pretendem utilizar estes resul-
tados preliminares para especificar melhor as pro´ximas coletas (aprimorar o questiona´rio,
a amostragem teo´rica, utilizar outros tipos de coleta, etc.) e ana´lises intercaladas durante
o curso para confirmar ou refutar os resultados. Os autores tambe´m consideram construir
um reposito´rio de experieˆncias descrito conforme [Meng et al. 2007] e aplicar te´cnicas de
Aprendizagem Organizacional [Argyris and Schon 1978] para identificar formas efetivas
de gerar melhorias em organizac¸o˜es a´geis.
7O autor declara que equipes a´geis mais eficazes sa˜o aquelas que consideram a heterogeneidade dos
seus integrantes, confirmando a pra´tica XP de time completo (Whole XP Team) [Beck and Andres 2004]
8A teoria da auto-efica´cia explica que o nı´vel de confianc¸a do indivı´duo em suas habilidades e´ um forte
motivador para a realizac¸a˜o de uma determinada tarefa [Bandura 1997].
68
References
[Argyris and Schon 1978] Argyris, C. and Schon, D. A. (1978). Organizational Learning:
A Theory of Action Perspective. Addison-Wesley, MA, USA.
[Bandura 1997] Bandura, A. (1997). Self-efficacy: The exercise of control. W. H. Freeman,
New York.
[Beck 2003] Beck, K. (2003). Test-Driven Development by Example. Addison Wesley.
[Beck and Andres 2004] Beck, K. and Andres, C. (2004). Extreme Programming Ex-
plained: Embrace Change. Addison-Wesley, Boston, 2nd edition.
[Beck et al. 2001] Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham,
W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B.,
Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., and Thomas, D. (2001). Ma-
nifesto for agile software development. Available at: http://agilemanifesto.
org/.
[Corbin and Strauss 2007] Corbin, J. and Strauss, A. C. (2007). Basics of Qualitative Re-
search: Techniques and Procedures for Developing Grounded Theory. Sage Publica-
tions, Inc, 3rd edition.
[Dyba˚ et al. 2010] Dyba˚, T., Dingsoyr, T., and Moe, N. B. (2010). Agile Software Develop-
ment - Current Research and Future Directions. Springer, 1st edition.
[Endres et al. 2009] Endres, M. L., Chowdhury, S., and Rhoad, K. (2009). Effects of stu-
dent task self-efficacy and expected reciprocity on intent to share knowledge. Pa-
per presented at the Academy of Management Conference. Available at: http:
//www.ime.usp.br/˜vsantos/pesquisa1/.
[Glaser and Strauss 1967] Glaser, B. G. and Strauss, A. L. (1967). The Discovery of
Grounded Theory: Strategies for Qualitative Research. Aldine Publishing Company,
Chicago, IL, USA.
[Goldman et al. 2004] Goldman, A., Kon, F., Silva, P. J. S., and Yoder, J. (2004). Being
extreme in the classroom: Experiences teaching xp. Journal of the Brazilian Computer
Society, 10:2004.
[Meng et al. 2007] Meng, X.-x., Wang, Y.-s., Shi, L., and Wang, F.-j. (2007). A process pat-
tern language for agile methods. In APSEC ’07: Proceedings of the 14th Asia-Pacific
Software Engineering Conference, pages 374–381, Washington, DC, USA. IEEE Com-
puter Society.
[Sato et al. 2008] Sato, D. T., Corbucci, H., and Bravo, M. V. (2008). Coding dojo: An
environment for learning and sharing agile practices. AGILE Conference, 0:459–464.
[Sfetsos et al. 2009] Sfetsos, P., Stamelos, I., Angelis, L., and Deligiannis, I. (2009). An
experimental investigation of personality types impact on pair effectiveness in pair
programming. Empirical Software Engineering, 14(2):187–226.
[Urquhart et al. 2010] Urquhart, C., Lehmann,H., and Myers, M. D. (July 2010). Putting
the theory back into grounded theory: guidelines for grounded theory studies in infor-
mation systems. Information Systems Journal, 20:357–381(25).
69
 
Trabalhamos Enquanto você Trabalha: Utilizando Grounded 
Theory para identificar as vantagens do Brasil no mercado 
global de TI em função da sua posição geográfica 
Rafael Prikladnicki 
Faculdade de Informática (FACIN) 
Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS) 
90.619-900 – Porto Alegre – RS – Brasil 
rafaelp@pucrs.br
Abstract. Nations now compete in their time zone position. Indian IT has long 
positioned itself as ideal in time zone geography: we get the work done while 
you're sleeping! So, since the beginning of this decade the Brazilian IT 
industry, in order to differentiate from India, has proclaimed: we are 
accessible and easy to work with because we're working while you're working. 
In order to better understand the advantages e disadvantages of Brazil in the 
global IT market, PUCRS and American University have developed a joint 
qualitative study in the first semester of 2010. The main research method 
applied was Grounded Theory. In this paper, we present the main results of 
the study, as well as the challenges and recommendations of using Grounded 
Theory as the research method. 
Resumo. Atualmente, os países têm utilizado suas posições geográficas como 
diferencial competitivo. O mercado indiano de TI, por exemplo, tem se 
posicionado há um bom tempo como um país ideal em termos de fuso-horário: 
nós trabalhamos enquanto você está dormindo! Neste sentido, a partir do 
início desta década a indústria brasileira de TI, de forma a se diferenciar da 
Índia, declarou: nós somos acessíveis e mais fáceis para trabalhar por que 
nós trabalhamos enquanto você trabalha! De forma a entender melhor as 
vantagens e desvantagens do Brasil no mercado global de TI, a PUCRS e a 
American University desenvolveram, em parceria, um estudo qualitativo no 
primeiro semestre de 2010. O principal método de pesquisa utilizado foi 
Grounded Theory ou Teoria Fundamentada em Dados. Neste artigo são 
apresentados os principais resultados do estudo, incluindo o relato do uso de 
Grounded Theory como método de pesquisa, incluindo desafios e 
recomendações. 
1. Introdução 
O software é cada vez mais indispensável para a sociedade moderna, sendo a 
globalização uma característica fundamental. Atualmente diversas empresas estão 
distribuindo seus processos de desenvolvimento de software ao redor do mundo, 
visando ganhos de produtividade, reduções de custos e melhorias na qualidade. Neste 
contexto, o ambiente de Desenvolvimento Distribuído de Software (DDS) surge como 
um grande desafio na área de ES (Karolak, 1998; Carmel & Tjia, 2005; Audy & 
70
 
Prikladnicki, 2007; Prikladnicki et al, 2010). Do ponto de vista de negócio, os países 
têm utilizado suas posições geográficas como diferencial competitivo para o trabalho 
distribuído (Cardoso, 2006). O mercado indiano de TI, por exemplo, tem se posicionado 
há um bom tempo como um país ideal em termos de fuso-horário: nós trabalhamos 
enquanto você está dormindo! Neste sentido, a partir do início desta década a indústria 
brasileira de TI, de forma a se diferenciar da Índia, declarou: nós somos acessíveis e 
mais fáceis para trabalhar por que nós trabalhamos enquanto você trabalha! 
Para entender um pouco mais sobre as oportunidades do Brasil em função da sua 
posição geográfica, o grupo de pesquisa em Desenvolvimento Distribuído de Software 
(MuNDDoS) da PUCRS conduziu uma pesquisa inédita no país em parceria com a 
American University, de Washington, nos Estados Unidos. Diversas entidades já 
publicaram relatórios sobre o potencial do Brasil no mercado global de TI, entre elas a 
Brasscom (associação das principais empresas brasileiras de TI), o Ministério da 
Ciência e Tecnologia (MCT) e consultorias tais como IDC e ATKearney (Stefanuto & 
de Carvalho, 2005, ATKearney, 2007; ATKearney, 2009, Brasscom, 2009, KPMG, 
2009, Peres, 2009). Em todos estes relatórios o fuso-horário aparece como uma 
característica importante para trabalho remoto, mas são poucas as pesquisas que 
exploram o potencial do país como destino de projetos de TI em função da proximidade 
de fuso-horário (Cardoso, 2006). 
Desta forma, o objetivo deste artigo é relatar os resultados do estudo realizado, no qual 
se buscou entender de forma aprofundada quais são as reais vantagens do Brasil em 
função da proximidade temporal com Estados Unidos e Europa principalmente. Apesar 
de existirem diversos outros desafios ao se trabalhar de forma distribuída e global 
(Carmel & Tjia, 2005), tais como cultura e idioma, o foco deste estudo foi somente no 
fuso-horário. Para isto, definiu-se a seguinte questão de pesquisa: “Quais são as 
vantagens do Brasil no mercado global de TI em função da sua posição geográfica?” 
Para o desenvolvimento do estudo utilizou-se técnicas do método de pesquisa conhecido 
como Teoria Fundamentada em Dados, ou Grounded Theory (GT). A GT é um método 
de pesquisa que usa uma técnica indutiva baseada na análise sistemática e incremental 
de dados qualitativos (Strauss & Corbin, 2009). O objetivo da GT é gerar uma teoria 
que explica o que se observou nos dados coletados, sugerindo processos intercalados de 
coleta e análise de dados. Ela não é uma metodologia nova, e é amplamente utilizada em 
outras disciplinas das ciências sociais (Sociologia, Antropologia, etc) e até mesmo 
ciências médicas (Enfermagem e Medicina). Em função do aumento de estudos 
qualitativos em ES (de Souza & Redmiles, 2008; Conte et al, 2009), a GT mostra-se 
cada vez mais importante, mas muitos pesquisadores acabam executando o método de 
maneiras distorcidas ou até mesmo equivocadas (Suddaby, 2006). Neste sentido, além 
de apresentar os resultados do estudo desenvolvido, este artigo também apresenta uma 
reflexão sobre o uso da Grounded Theory como método de pesquisa, incluindo as 
decisões que guiaram o uso da técnica, os desafios encontrados e recomendações. 
Este artigo está organizado em 6 sessões. Na próxima sessão são apresentados os 
conceitos relacionados ao mercado global de TI. Na sessão 3 apresenta-se a Teoria 
Fundamentada em Dados. Na sessão 4 são apresentados os resultados do estudo e na 
sessão 5 é realizada uma discussão sobre o uso da GT. Na sessão 6 são apresentadas as 
conclusões. 
71
 
2. Referencial Teórico e Trabalhos Relacionados 
O Brasil possui um grande mercado de TI. Relatórios recentes indicam que o setor 
emprega em torno de 1.7 milhão de pessoas, incluindo desenvolvedores, analistas de 
sistemas e gerentes. Além disso, em 2008 o Brasil exportou o equivalente a 2.2 bilhões 
de dólares. Estes números fazem com que o mercado de TI do Brasil cresça num ritmo 
médio de 6,5% ao ano desde 2005. Mesmo que ainda seja uma potência pequena se 
comparada com a Índia (a maior delas, exportando vinte vezes mais do que o Brasil), o 
país tem um grande potencial para crescer. De acordo com a Associação Brasileira de 
Empresas de Software (ABES), em 2008 havia aproximadamente 7.800 empresas de 
software e TI no Brasil, sendo que a grande maioria tinha como foco o mercado 
doméstico. Por outro lado, enxerga-se um grande espaço para o desenvolvimento do 
potencial de exportação do Brasil nesta área. 
Quando a Índia surgiu como uma potência no mercado global de TI, um dos argumentos 
de venda era a diferença de fuso-horário e a possibilidade de usar a Índia para acelerar o 
desenvolvimento de software (os indianos trabalhavam enquanto os americanos estavam 
dormindo). Mas para algumas atividades, em que era necessária uma grande 
coordenação e comunicação, os problemas eram freqüentes. A coordenação acaba sendo 
feita por e-mail, sendo menos efetiva. Neste contexto, o Brasil surge como um potencial 
competidor,utilizando um argumento diferente para a sobreposição de fuso-horário. O 
país possui sobreposição com Estados Unidos e Europa, fazendo com que seja possível 
uma comunicação em tempo real em pelo menos uma parte do dia (Tabela 1 e Tabela 2 
– nesta tabela outros períodos de transições curtas de fuso-horário, tais como na 
primavera e no outono, não estão sendo representados). 
 4 3 2 1 Brazil 1 2 3 4 5 
 Estados Unidos Europa 
 -7 -6 -5 -4 GMT -3 +1 +2 
Tabela 1. Horário durante o inverno brasileiro 
6 5 4 3 2 1 Brazil 1 2 3 
Estados Unidos Europa 
-8 -7 -6 -5 GMT -2 0 +1 
Tabela 2. Horário durante o verão brasileiro 
Apesar de existirem estudos que analisam os desafios e vantagens dos países no 
Desenvolvimento Distribuído de Software devido a diversos fatores tais como idioma, 
diferenças culturais, conhecimento técnico, não se tem conhecimento de um estudo 
específico que analisa as vantagens do Brasil no mercado global em função da sua 
posição geográfica (fuso-horário). Isto é importante na medida em que tomadores de 
decisão dentro e fora do país estão examinando seus desafios para atuar no mercado 
global de serviços de TI. Do ponto de vista dos brasileiros, saber como usar 
corretamente a vantagem da sobreposição de fuso-horário pode ser estratégico. Por outro 
lado, executivos nos Estados Unidos e Europa podem aprender como trabalhar melhor 
com os parceiros brasileiros. Sendo assim, nas próximas sessões são apresentados os 
principais resultados do estudo, incluindo uma reflexão sobre o uso de Grounded 
Theory como método de pesquisa. 
72
 
3. Metodologia de Pesquisa 
Este estudo foi conduzido entre Janeiro e Julho de 2010. Utilizou-se uma estratégia de 
pesquisa qualitativa, do tipo exploratória, de natureza aplicada, seguindo-se o método da 
Teoria Fundamentada em Dados, ou Grounded Theory (Strauss & Corbin, 2009). A 
pesquisa qualitativa é geralmente utilizada quando é necessário descrever detalhes, criar 
descrições densas da realidade representando palavras e figuras ao invés de números. 
Além disso, pesquisas qualitativas estudam o objeto de análise em seu ambiente natural, 
sendo que o pesquisador deve aceitar que existem diferentes formas de interpretação dos 
fatos observados. Além disso, pesquisas qualitativas permitem uma compreensão mais 
abrangente de todo o fenômeno em estudo (Seaman, 2000). Já pesquisas exploratórias 
são caracterizadas por desenvolver, esclarecer e modificar conceitos e idéias, com vistas 
à formulação de novas teorias, modelos e hipóteses pesquisáveis em estudos posteriores. 
Grounded Theory foi utilizada como principal método de pesquisa, pois usa uma técnica 
indutiva baseada na análise sistemática e incremental de dados qualitativos. A partir da 
GT é possível gerar uma teoria substantiva (teoria específica para determinado grupo ou 
situação) a partir de coleta e análise de dados até alcançar o que se define por saturação 
teórica. Durante a execução de pesquisas utilizando-se de GT como principal método de 
pesquisa, etapas de coleta e análise de dados devem ser alternadas para que os resultados 
da análise possam direcionar a nova etapa de coleta de dados, sugerindo focos e novas 
abordagens que poderão modificar ou corroborar os resultados iniciais. Dessa forma, 
esta estratégia foi utilizada nesta pesquisa. 
A equipe de pesquisa contou com um pesquisador americano e outro brasileiro que 
conduziram 46 entrevistas em 15 unidades de desenvolvimento de diversas empresas. 
As empresas foram selecionadas seguindo dois critérios principais: ter uma amostra de 
pelo menos seis empresas brasileiras e outra amostra de mais seis empresas 
multinacionais estrangeiras, em pelo menos três Estados do país, sendo que algumas 
destas unidades deveriam ser caracterizadas como captive centers. As entrevistas foram 
então realizadas em 9 unidades de desenvolvimento de empresas brasileiras e 6 de 
multinacionais estrangeiras ou captive centers de multinacionais estrangeiras. As 
entrevistas foram realizadas em inglês em um total de 33 horas, em São Paulo, Rio de 
Janeiro e Porto Alegre. Além disso, também foram entrevistados três clientes ou 
parceiros estrangeiros de Portugal, da Índia e dos Estados Unidos. 
Todos os entrevistados foram questionados utilizando-se de um guia para entrevista 
semi-estruturada, que foi modificado três vezes ao longo do estudo, a partir de 
resultados parciais de entrevistas que foram sendo executadas. O Anexo I apresenta a 
segunda versão do instrumento de coleta de dados utilizado. A primeira versão foi 
elaborada pelo pesquisador americano a partir de sua experiência em estudos similares 
executados em outros países e a validação de face e conteúdo foi realizada por dois 
pesquisadores brasileiros do grupo de pesquisa em Desenvolvimento Distribuído de 
Software da PUCRS. Um pré-teste foi executado em Janeiro de 2010 com colaboradores 
brasileiros de duas empresas multinacionais estrangeiras, gerando assim pequenas 
modificações no questionário. 
No total foram estudados 22 projetos, sendo que apenas três projetos não tiveram a 
participação de Estados Unidos ou Canadá (Tabela 3). 
73
 
 
Local de interação 
 
 
Tipo de empresa 
EUA 
Canadá 
Europa 
EUA 
Canadá 
Europa 
EUA 
Canadá, 
Europa 
Europa 
Ásia 
Multinacional 5 2 6 
Brasileira 4 2 2 1 
Total 9 2 4 6 1 
Percentual 41% 9% 18% 27% 5% 
Tabela 3. Configuração dos projetos estudados 
Além disso, projetos desenvolvidos por empresas multinacionais possuíam uma 
configuração mais complexa do que projetos desenvolvidos por empresas brasileiras 
(Figura 1 e Figura 2). 
 
Figura 1. Projeto em 
multinacional 
Figura 2. Projeto em empresa 
brasileira 
A maior parte das entrevistas foi realizada durante uma semana do mês de Maio de 
2010. Por opção dos pesquisadores, as entrevistas não foram gravadas nem transcritas. 
Ao contrário, os dois pesquisadores optaram por participar de todas as entrevistas, 
tomando notas individuais. Ao final de cada dia, cada entrevista era discutida e 
codificada individualmente e todas as anotações eram transcritas para um documento 
único, com revisão de cada pesquisador. Esta sistemática de anotações e discussão ao 
final de cada dia fez com que o processo fosse mais ágil do que o processo tradicional 
de transcrição literal e codificação aberta, axial e seletiva. Desta forma, ao longo das 
entrevistas foi possível delinear descobertas relevantes e identificar itens a serem 
questionados nas rodadas seguintes. É importante destacar que esta estratégia só foi 
possível em função da maior parte das entrevistas terem sido conduzidas em um período 
de uma semana, de forma ininterrupta. Foram realizadas em média quatro entrevistas 
por dia, com análise e revisão do instrumento de coleta de dados ao final do dia. Isto se 
repetiu até alcançar a saturação teórica. Ao final, em função da não identificação de 
novas categorias nos dados coletados, algumas entrevistas agendadas para os últimos 
dias acabaram não sendo mais necessárias e, portanto, foram desmarcadas. 
4. Resultados 
Neste artigo são destacados apenas os principais resultados encontrados no estudo. O 
Brasil se beneficia da sobreposição de fuso-horário com a América do Norte e Europa. 
Quase 100% dos clientes de TI do Brasil possuem sobreposição de fuso-horário com o 
país e é uma sobreposição de conveniência para ambos os lados. Ela permite que ambos 
74
 
sejam mais interativos ao invés de trabalhar de forma altamente estruturada. Esta 
sobreposição facilita uma comunicação síncrona densa e ajuda a criar relações mais 
próximas entre os brasileiros e seus clientes estrangeiros. Por outro lado, grandes 
diferenças de fuso-horário criam dificuldades: a simples atividade de marcar uma 
reunião pode se tornar onerosa. E a relação entre os Estados Unidose países da Ásia, 
por exemplo, pode rapidamente se transformar em atrasos devido à comunicação 
inconstante. A sobreposição de fuso-horário também pode ajudar as unidades brasileiras 
a obter e reter atividades ou projetos menos estruturados que podem ser mais lucrativos. 
Foram encontrados diferentes níveis de intensidade de colaboração nas unidades 
brasileiras, sendo possível criar um framework de quatro níveis de colaboração (Tabela 
4). No nível mais baixo os profissionais apenas trocam e-mails diversas vezes ao dia. O 
nível mais alto é o que se definiu de RTSC—Real Time Simulated Co-location, que fica 
caracterizado quando unidades distantes (por exemplo, São Paulo e Carolina do Norte) 
colaboram como se estivessem no mesmo espaço físico. A simulação de proximidade 
física é viabilizada através de quatro elementos principais: sobreposição de fuso-horário 
através de pequenas mudanças do horário de trabalho; tecnologias ricas em 
compartilhamento de contexto e awareness (vídeo e áudio ligados de forma contínua, 
dados compartilhados de projetos, etc); uma cultura de time coeso nas unidades 
distribuídas; e domínio da língua inglesa. 
 
Nível 1 Comunicação assíncrona, cultura tradicional, uso esporádico de 
comunicação síncrona 
Nível 2 Uso de instant messaging, uso de tecnologia padrão para 
comunicação, vídeo usado de forma esporádica 
Nível 3 Estado da arte em tecnologia de colaboração, ferramentas de suporte a 
awareness 
Nível 4 Simulação de mesmo espaço físico, ambiente same-time, rica 
tecnologia de comunicação, vídeo 24 horas por dia, 7 dias por semana 
Tabela 4. RTSC – Real Time Simulated Co-location 
Em uma perspectiva estratégica, identificou-se que a proximidade de fuso-horário não 
influencia as decisões iniciais sobre o local do parceiro. Entretanto, decisões 
incrementais de local (mais trabalho, manutenção da relação) são sim influenciadas. Em 
uma perspectiva tática, identificou-se que o ajuste de uma equipe ao horário da outra 
não ocorre de forma sistemática no Brasil. Além disso, os brasileiros em geral evitam 
hora-extra, o trabalho em finais de semana é raro e as leis trabalhistas são restritas em 
muitos aspectos, apesar de existir alguma flexibilidade em alguns casos. Finalmente, 
foram examinadas as metodologias de desenvolvimento de software utilizadas e 
observou-se a crescente importância do movimento ágil no Brasil (todas as empresas 
analisadas estavam utilizando ou migrando para o uso de metodologias ágeis para 
desenvolvimento de software). O estudo não avaliou se as empresas estavam fazendo o 
uso correto de metodologias ágeis, mas foi possível identificar que as empresas estavam 
conseguindo uma melhor coordenação do trabalho em diferentes fusos-horário. 
75
 
5. Discussão 
5.1. Recomendações para o Brasil 
As unidades brasileiras já estão se aproveitando da sobreposição de fuso-horário com a 
América do Norte e Europa, mas podem mais. RTSC é o aspecto mais interessante (e de 
maior potencial) para as empresas neste contexto. A maior parte das empresas 
brasileiras está nos níveis mais baixos de colaboração interativa devido a uma cultura 
mais tradicional. As empresas multinacionais tendem a se posicionar em níveis mais 
altos. Nós identificamos, por exemplo, uma unidade brasileira de uma multinacional que 
trabalha no nível 4, o maior nível de colaboração. Poucas unidades brasileiras 
alcançaram níveis mais altos de interatividade com parceiros distantes, apesar de ser isto 
um dos aspectos que podem fazer diferença na relação com estes parceiros. 
Encontramos evidências de que os brasileiros gostam desta interação mais rica ao invés 
de adotar um estilo de colaboração assíncrono. 
Um risco desta abordagem é o fato de que diversas empresas ao redor do mundo não 
possuem processos de desenvolvimento de software de qualidade. A grande diferença de 
fuso-horário (por exemplo, EUA e Índia) força estas empresas a melhorar seus 
processos de desenvolvimento de forma a trabalhar de maneira efetiva. E isto tem 
ajudado algumas empresas no longo prazo. A conveniência da sobreposição de fuso-
horário significa que algumas empresas brasileiras podem acabar mantendo um processo 
de desenvolvimento imperfeito. 
5.2. Desafios e Lições no uso de Grounded Theory 
Do ponto de vista do uso de Grounded Theory como método de pesquisa, ela se mostrou 
bastante adequada para estudar fenômenos como este. O uso da técnica permitiu uma 
interação direta entre o grupo de pesquisa e o trabalho em diversas iterações até se 
chegar num conjunto de conclusões que fizessem sentido. 
Algumas observações que merecem destaquem são: 
- O uso de GT só foi possível pela possibilidade de realizar diversas entrevistas em um 
curto espaço de tempo, de forma intensa, com coleta e análise de dados de forma 
intercalada. 
- O uso de análise dos dados sem a realização da transcrição literal das entrevistas se 
mostrou bastante rica em função da disponibilidade dos dois pesquisadores durante 
todas as entrevistas. Isto fez com que se evitasse um gasto desnecessário de tempo com 
longas transcrições sob risco de utilizar apenas uma pequena parte das transcrições para 
responder a questão de pesquisa. A transcrição é necessária e bastante importante 
principalmente quando a pesquisa é conduzida por pesquisadores que estão aprendendo 
a aplicar os diferentes métodos de pesquisa existentes. Neste estudo em específico a 
equipe contava com um pesquisador americano com bastante experiência em conduções 
de estudos qualitativos e GT. Como em suas experiências anteriores era comum usar 
menos de 50% de um texto transcrito, boa parte do tempo que se gastava com 
transcrição acabava sendo desperdiçado e poderia ser gasto em outras etapas que 
influenciam diretamente os resultados da pesquisa. Neste caso optou-se por codificação 
das anotações diárias. 
76
 
- Conduzir boas entrevistas não é uma tarefa fácil. Desta forma, o pesquisador mais 
experiente (americano) acabou conduzindo as primeiras entrevistas, o que se mostrou 
bastante efetivo ao longo do processo de coleta e análise de dados. A partir da quinta 
entrevista o entrevistador principal foi intercalado para cada participante do estudo. 
- É muito difícil analisar dados qualitativos sem uma experiência prévia. Neste sentido, 
a participação de um pesquisador mais experiente foi fundamental para calibrar o 
processo. Uma sugestão neste caso é ler outros estudos que usam a técnica de GT. 
- Uma dificuldade identificada no estudo foi a de determinar quando parar. O uso de GT 
pressupõe coleta e análise de dados e comparação constante até alcançar-se a saturação 
teórica. Para isso, recomenda-se sempre refletir, ao final de um ciclo de coleta e análise 
de dados, se algo novo foi aprendido, se novos códigos foram gerados. Se a resposta for 
não, talvez este seja o momento de parar. 
- Ao conduzir um estudo utilizando-se GT deve-se procurar separar o uso de GT como 
método de pesquisa ou o uso de GT como método de análise de dados qualitativos. 
Enquanto o segundo usa técnicas de GT, o primeiro usa GT como o método principal de 
pesquisa, o que foi o caso neste estudo. É importante deixar isto claro, pois é comum 
encontrar estudos na literatura que vendem a idéia de usar GT como método de pesquisa 
enquanto usam apenas técnicas de GT (Suddaby, 2006) 
5.3. Limitações do estudo 
Este estudo contou com uma amostra limitada de unidades brasileiras de 
desenvolvimento de software. As fontes foram basicamente de brasileiros, e, portanto 
isto deve ser considerado como fator de influência nos resultados apresentados. 
5.4. Conclusão e próximos passos 
Este estudo destacou diversos desafios e oportunidades para as empresas brasileiras de 
TI que querem aumentar suas operações globais ou ainda para empresa que querem 
começar a atuar no mercado internacional. As unidades brasileirasjá estão aproveitando 
as vantagens da sobreposição do fuso-horário, mas podem mais. Algo que surpreendeu 
neste estudo foi que muitas empresas brasileiras estão buscando o mercado 
internacional, mas poucas avaliam oportunidades em função da sobreposição de fuso-
horário com Estados Unidos e Europa. Além disso, o rápido crescimento das 
metodologias ágeis no Brasil chamou a atenção, apesar de não estar diretamente 
relacionado com a questão de pesquisa. 
Este foi o primeiro estudo que analisou as vantagens do Brasil no mercado global de TI 
em função da sua posição geográfica e, portanto, não pode responder todas as questões. 
Algumas questões em aberto podem ser exploradas em estudos futuros, quais sejam: 
- Será que o fuso-horário tem alguma influência na decisão de trabalhar com Tecnologia 
de Informação no Brasil? 
- Qual a melhor configuração de sobreposição de fuso-horário para projetos 
desenvolvidos no Brasil? Será que são necessários 100% de sobreposição? 
- Será que as empresas brasileiras estão atraindo determinados tipos de projetos (mais 
complexos) em função da sobreposição de fuso-horário com Estados Unidos e Europa? 
77
 
Agradecimentos 
Este estudo foi desenvolvimento em colaboração entre o grupo MuNDDoS da PUCRS e 
a American University. 
Referências Bibliográficas 
ATKearney. “Next steps in the Strategic Agenda for the IT Offshore Outsourcing 
sector”, Capturado em http://tinyurl.com/offshoreReport, AT Kearney, Maio 2009. 
ATKearney, “Destination Latin America: A Near-Shore Alternative,” Relatório de 
pesquisa, 2007. 
Audy, J. L. N., Prikladnicki, R. “Desenvolvimento Distribuído de Software: 
Desenvolvimento de Software com Equipes Distribuídas”, Série Campus-SBC, Rio 
de Janeiro: Editora Campus-Elsevier, 2007, 211p. 
Brasscom, “Brazil IT-BPO Book 2008-2009,” Relatório de pesquisa, 2009. 
Cardoso, F. C. M., “Fatores Determinantes na Escolha do Brasil como Exportador de 
Serviços de Tecnologia de Informação,” Mestrado em Gestão Empresarial, Fundação 
Getúlio Vargas, 2006. 
Carmel, E., Tjia, P. “Offshoring Information Technology: Sourcing and Outsourcing to 
a Global Workforce”, UK: Cambridge, 2005, 282p. 
Conte, T., Cabral, R., Travassos, G. H., "Aplicando Grounded Theory na Análise 
Qualitativa de um Estudo de Observação em Engenharia de Software – Um Relato de 
Experiência," In: V Workshop "Um Olhar Sociotécnico sobre a Engenharia de Software" 
(WOSES 2009), Ouro Preto, MG, Brasil. 
Karolak, D. W. “Global Software Development – Managing Virtual Teams and 
Environments”, Los Alamitos: IEEE Computer Society, 1998, 172p. 
KPMG, “Nearshore Attraction: A América Latina acena como destino global de 
Outsourcing,” Relatório de pesquisa, 2009. 
Peres, M. (2009). “O Mercado de Serviços Offshore Brasileiro em 2008,” capturado em 
http://tinyurl.com/offshoreBrasilTese, Maio 2009. 
Prikladnicki, R., Audy, J. L. N., Shull, F., “Patterns in Effective Distributed Software 
Development," IEEE Software, 27-2, Mar-Abr 2010, pp. 12-15. 
Seaman, C. B. “Qualitative Methods in Empirical Studies of Software Engineering”, 
IEEE Transactions on Software Engineering, 25 (4), 1999, pp. 557-572. 
De Souza, C. R. B.; Redmiles, D. F. “An Empirical Study of Software Developers 
Management of Dependencies and Changes,” In: International Conference on Software 
Engineering, 2008, Leipzig. Proceedings of the International Conference on Software 
Engineering, 2008. p. 241-250. 
Stefanuto, G. N., de Carvalho, R. Q., “Perfil das Empresas Brasileiras Exportadoras de 
Software,” Relatório de pesquisa, Softex, 2005. 
Strauss, A., Corbin, J., “Pesquisa Qualitativa – Técnicas e Procedimentos para o 
Desenvolvimento de Teoria Fundamentada,” Editora Bookman, 2008. 
Suddaby, R., “From the Editors: What Grounded Theory is Not,” Academy of 
Management Journal, 49 (4), pp. 633-642, 2006. 
78
 
Anexo I 
Interview Protocol – Time Zone Challenges in Firms 
Version of April 2010 
Introduction 
Introduce ourselves and our objective 
IRB requirements (“human subjects”) 
Interview core 
1. Locations that you interact with 
o ________ (GMT ) ________ (GMT ) 
o Were these locations designed for TZ reasons? 
2. The firm/ division 
3. Work hours, overlap times and timeshifting 
o Work hours at each site: normal; peak 
o Favorite transcontinental synchronous meeting time: 
4. Task and Task Architecture / Task allocation 
o Task structure (dependency minimization?) 
o Follow the Sun 
5. Methodologies 
o Agile and special adaptations. Stand-up meeting. 
6. Technology 
o Repositories, development environments? 
7. Organic communication 
o Inter-site problem solving is mostly by … video-conferencing? email? 
o Daily phone calls / conference calls. Give us specific topics for conversation 
in recent days. At what point is travel necessary.? 
o Standup meeting? 
o Texting / IM / other interactive 
o Social Media and mash-ups. Facebook, Twitter, etc. 
8. Boundary-spanner / liaison. Who? How many? 
9. Escalation protocols. 
10. 24-hour culture. 
11. Implicit coordination across sites 
12. Performance, how is it measured? (and other outcome measures) 
o Speed, quality, cost 
o Coordination success 
o Happiness, burn-out 
Wrap-up 
Questions for us? 
Comments back to the interviewees. 
 
 
 
79
 
Um estudo exploratório dos fatores associados ao estímulo 
do aprendizado em times ágeis na indústria 
Claudia de O. Melo
1
, Carlos D. Santos Jr
1
, Gisele R. M. Ferreira
2
, Fabio Kon
1 
1
Departamento de Ciência da Computação - IME 
Universidade de São Paulo (USP) - São Paulo, SP - Brasil 
2
Departamento de Informática 
Banco Central do Brasil – Brasília, DF - Brasil 
{claudia,denner,fabio.kon}@ime.usp.br, gisele.ferreira@bcb.gov.br
Abstract. Software development involves continuous learning. The Agile 
Methods have emerged as an approach to stimulate team learning in software 
development. This article aims at better understanding the relationship 
between the adoption of Agile Methods by software projects 
and enhanced learning. For this purpose, a case study was conducted in an 
organization that embraced XP for two years. We explored the developers' 
perception of the influencing factors on their learning processes. The main 
results were that three factors related to XP practices can 
facilitate learning, potentially affecting productivity levels. 
Resumo. Desenvolver software envolve aprendizado contínuo. Métodos ágeis 
surgiram como uma abordagem para o estímulo do aprendizado em times de 
desenvolvimento de software. Este artigo tem como objetivo entender a 
relação entre a adoção de métodos ágeis por equipes de desenvolvimento e a 
aceleração do aprendizado dos seus integrantes. Para isso, um estudo de caso 
foi conduzido em uma organização que adotou XP há dois anos. Buscou-se 
explorar as percepções dos integrantes das equipes sobre a variação do 
aprendizado e seus fatores de influência. Dentre os principais resultados, 
encontraram-se três fatores relacionados às práticas de XP que podem 
facilitar o aprendizado e potencialmente afetar os níveis de produtividade. 
 1. Introdução 
O desenvolvimento de software, em todas as suas formas, é uma atividade de 
aprendizado (Kelly, 2008). Ele pode ser visto como um processo de pelo menos quatro 
atividades inter-relacionadas: o aprendizado de novas tecnologias, o aprendizado do 
domínio, a resolução de problemas do domínio com o conhecimento tecnológico e o 
aprendizado dos usuários sobre seu próprio problema e sobre o sistema em si. Para 
Arrow (1962), o aprendizado é produto da experiência. Ele só acontece ao tentar se 
resolver um problema e, portanto, só ocorre durante a atividade. Arrow considera que oaumento do progresso técnico e, portanto, da produtividade, é derivado do acúmulo de 
experiência adquirida profissionalmente. Boh et al. (2007) relatam que o aprendizado 
pela experiência aumenta o desempenho individual, dos times de desenvolvimento de 
software e da organização. Cria-se, desta maneira, a relação entre o aumento do 
aprendizado e o aumento da produtividade. 
80
 
Métodos ágeis aparecem como a manifestação de uma nova metáfora para o 
desenvolvimento de software que, dentre outras coisas, enfatiza o processo de 
aprendizado baseado na experimentação e introspecção (Nerur e Balijepally 2007). 
Dessa forma, o aprendizado pela experiência (conhecido como learning by doing) é 
usado com um dos elementos do estilo ágil de desenvolvimento - um facilitador para os 
objetivos de adaptabilidade e flexibilidade desses métodos. 
 De acordo com VersionOne (2009), a Programação Extrema, ou XP, de Beck 
(2001) é um dos métodos ágeis mais conhecidos e adotados na indústria. XP promete 
que, além de produzir software de alta qualidade com alta produtividade, pode acelerar 
o aprendizado. Segundo Beck, a introdução do princípio de rápido feedback permite a 
elevação do grau de aprendizado. Para Kerievsky (2001), o aprendizado contínuo é parte 
do espírito de XP, implícito em seus valores e implementado, até certo ponto, em suas 
práticas. 
A revisão sistemática de Dybå e Dingsøyr (2008) aponta que, apesar dos 
diversos trabalhos publicados sobre métodos ágeis, pouco se sabe sobre como esses 
métodos são realmente implantados nas empresas e que efeitos geram. A revisão mostra 
ainda que existem poucos estudos empíricos que exploram questões acerca do 
aprendizado em times ágeis na indústria, especialmente sobre os fatores que o 
influenciam. 
Este artigo descreve uma pesquisa empírica exploratória com o objetivo de 
compreender a relação entre a adoção de métodos ágeis, a aceleração do aprendizado e a 
produtividade dos times. Para isso, foi realizado um estudo de caso em uma organização 
de grande porte que já concluiu dois projetos usando métodos ágeis, especialmente as 
práticas de XP. A abordagem metodológica é mista (Tashakkori e Teddlie 2003) e 
baseia-se principalmente na Análise temática, cujo objetivo é auxiliar a síntese dos 
dados qualitativos, identificando, analisando e relatando padrões encontrados (Braun e 
Clarke 2006). Posteriormente, dados quantitativos são integrados e analisados 
estatisticamente. 
O restante do artigo está organizado da seguinte forma: a Seção 2 apresenta uma 
breve revisão da literatura relacionada, enquanto a Seção 3 descreve a metodologia do 
estudo. A Seção 4 relata os resultados qualitativos e quantitativos obtidos no estudo e a 
Seção 5 os discute em contraste com outros estudos na área de aprendizado. A Seção 6 
conclui o trabalho e aponta alguns trabalhos futuros. 
 2. XP e o aprendizado nos times 
Os efeitos de XP no aprendizado acadêmico foram recentemente explorados em vários 
trabalhos científicos. A revisão sistemática de Salleh et al. (2010) mostra que há 
evidências de que a programação em pares, prática específica de XP, melhora o 
processo de aprendizado de alunos de graduação em computação. A revisão considerou 
evidências de 73 estudos, 44 provenientes de experimentos formais e apenas 4 de 
estudos qualitativos. 
No estudo de Drobka et al. (2004) conduzido na Motorola, 55% dos 
participantes acreditam que o uso de métodos ágeis diminui a curva de aprendizado. Ao 
trabalhar em pares, os novos membros aprenderam a arquitetura rapidamente com a 
ajuda dos colegas mais experientes. O mesmo resultado ocorreu com novos contratados, 
81
 
que se tornaram produtivos em um mês de experiência com XP. Além disso, a 
produtividade individual dos engenheiros da empresa aumentou se comparada com o 
desempenho em projetos com outros métodos. As principais fontes de evidência foram 
os resultados de questionários e o histórico de produtividade da empresa. Law e Charron 
(2005) relataram que os times ágeis da TransCanada, empresa do ramo energético norte-
americano, apresentaram diminuição da curva de aprendizado e que práticas como o 
trabalho co-localizado, a programação em pares e a reunião diária promoveram o 
compartilhamento do conhecimento. As evidências foram retiradas de registros de 
retrospectivas da equipe e de observação, onde, nessa última, não fica claro o método de 
síntese dos dados coletados. 
 3. Metodologia 
Esta pesquisa é empírica e consiste no estudo de um caso na indústria, com a intenção 
de explorar possíveis relações entre a adoção de métodos ágeis, a aceleração do 
aprendizado e a variação da produtividade dos times. Esse objetivo pode ser traduzido 
em duas Questões de Pesquisa (QP): 
(QP1) Como a adoção de métodos ágeis pode influenciar o aprendizado dos times? 
(QP2) Há relação entre a adoção de métodos ágeis, o aprendizado e a produtividade dos 
times? 
 Os critérios para seleção do caso foram: i) adoção de métodos ágeis – 
especialmente XP - para o desenvolvimento de software há pelo menos um ano e 2) pelo 
menos dois projetos ágeis concluídos. Dessa forma, a organização em estudo já tem 
resultados preliminares e alguma maturidade para opinar sobre as questões de pesquisa. 
O estudo é de natureza interpretativa e indutiva (Easterbrook et al. 2008), com o 
objetivo final de gerar hipóteses que contribuam para o avanço de novas pesquisas. 
Quanto à abordagem, foram utilizados métodos mistos de pesquisa que envolvem a 
coleta e análise de dados qualitativos e quantitativos em um único estudo, com coleta 
concorrente ou sequencial, e integração dos dados em um ou mais estágios do processo 
(Tashakkori e Teddlie 2003). Essa abordagem permite neutralizar as desvantagens de 
cada método e trazer resultados mais consistentes. A pesquisa é essencialmente guiada 
pelos dados qualitativos, sendo complementada por dados quantitativos quando 
possível. Por fim, este artigo estende o estudo de caso feito por Melo e Ferreira (2010) 
sobre o impacto da adoção de métodos ágeis em uma organização de grande porte. 
3.1. Ambiente de pesquisa 
O ambiente de estudo
1
 é uma organização do ramo financeiro que emprega cerca de 700 
pessoas na área de tecnologia. Ela adotou métodos ágeis para o desenvolvimento de 
software há dois anos e concluiu alguns projetos desde então. Os sujeitos da pesquisa 
são analistas de requisitos, desenvolvedores, analistas de qualidade, gerentes, 
especialistas em testes e projetistas envolvidos em projetos ágeis. A unidade de análise é 
o integrante envolvido em um dos dois projetos ágeis já executados e finalizados. 
3.2. Instrumentos e Procedimento de coleta de dados 
Os instrumentos de coleta de dados usados foram entrevistas semi-estruturadas, 
questionário online
2
 e análise de registros históricos. As entrevistas continham questões 
 
1
 Mais informações sobre o contexto da organização podem ser obtidas em Melo e Ferreira (2010). 
2
 O questionário aplicado está disponível em: http://www.ime.usp.br/~claudia/eselaw2010 
82
 
abertas para permitir uma maior interação entre o entrevistador e o entrevistado. As 
questões procuravam incentivar os entrevistados a relatar as tarefas que promoviam o 
aprendizado e suas opiniões sobre a variação na curva de aprendizado de times ágeis. 
Oito entrevistas semi-estruturadas foram conduzidas com membros de diferentes papéis 
nos projetos, com o intuito de explorar qualitativamente a relação entre métodos ágeis, 
aceleração de aprendizado e produtividade. Todas as entrevistas foram gravadas e 
posteriormente transcritas pelos autores do estudo. Além disso, dados sobre a 
produtividade dos projetosda organização foram coletados de registros históricos. 
 O questionário online já havia sido aplicado na organização anteriormente e seus 
resultados foram relatados por Melo e Ferreira (2010). Ele continha questões em escala 
Likert sobre a experiência prévia dos participantes, assim como a opinião deles sobre o 
impacto de métodos ágeis na aceleração do aprendizado e o aumento da produtividade. 
Havia também questões abertas para capturar a opinião sobre pontos positivos e de 
melhoria dos projetos ágeis. 
A coleta de dados na organização ocorreu em dois períodos: a primeira ocorreu 
entre 19/02/10 a 31/03/10, com a análise dos registros de produtividade, realização das 
primeiras entrevistas semi-estruturadas e aplicação do questionário. A segunda ocorreu 
no período de 30/07/10 a 11/08/10, quando novas entrevistas semi-estruturadas foram 
realizadas. No total, 21 pessoas participaram das duas fases de coleta. 
Variáveis e escalas. As variáveis e escalas foram selecionadas a partir do estudo inicial 
conduzido por Melo e Ferreira (2010), que levantou, por meio de um questionário, o 
perfil dos times ágeis da instituição, assim como sua percepção sobre a aceleração do 
aprendizado. A Tabela 1 apresenta o conjunto de variáveis independentes e dependentes 
escolhidas com respectivas escalas. As variáveis independentes selecionadas descrevem 
o nível de experiência dos profissionais antes dos projetos ágeis. Já a variável 
dependente refere-se à opinião deles sobre o impacto dos métodos ágeis na aceleração 
do aprendizado de novas tecnologias, conceitos e padrões. Todas as variáveis foram 
selecionadas a partir das questões fechadas presentes no questionário mencionado. 
Tabela 1 – Variáveis e Escalas 
Variáveis Independentes Escala 
Experiência em OO 
Tempo de experiência profissional anterior em Orientação a Objetos 
Nenhuma, 1-6 Meses, 7 
Meses - 2 anos, 3 a 5 
anos, 6-9 anos, 10 ou + 
anos 
Experiência na Arquitetura 
Tempo de experiência anterior com as tecnologias da Arquitetura de 
software de referência da organização 
Experiência em Projetos 
Tempo de experiência anterior em outros projetos de software 
Variável Dependente 
Aceleração do aprendizado com métodos ágeis 
Percepção sobre o impacto de métodos ágeis na aceleração do 
aprendizado de novas tecnologias, conceitos e padrões 
Definitivamente não (1), 
não (2), talvez (3), 
Sim (4), Definitivamente 
sim (5) 
 Em função do tamanho reduzido da amostra (n=21), os dados de experiência 
foram organizados no G1 (Sem experiência = 1, Com experiência = 2), o agrupamento mais 
simples sobre os dados obtidos, apropriado para um primeiro estudo exploratório. Na 
escala original, todas as respostas „Nenhuma‟ foram enquadradas no grupo G1 – sem 
experiência e as demais no grupo G1 – com experiência. Estudos posteriores podem 
aprofundar a granularidade da análise, criando mais categorias de experiência. 
83
 
3.3. Procedimentos de análise dos dados. 
Análise qualitativa. O método usado foi o de Análise temática, uma técnica para 
identificar, analisar e relatar os padrões (ou temas) encontrados em dados qualitativos 
(Braun e Clarke 2006). Segundo Boyatzis (1998), trata-se de uma busca por temas que 
se tornem importantes para descrever um fenômeno. Ela baseia-se em um processo 
composto de três passos: i) Identificação de padrões na informação, ii) Classificação (ou 
codificação) dos padrões em temas e, por fim, iii) a interpretação do padrão. Para apoiar 
a análise dos dados foi usada a ferramenta HyperRESEARCH, que permite a 
classificação da informação a partir de códigos, assim como suas correlações. A 
codificação foi dirigida por dados (Boyatzis 1998 pp. 29-30), pois partiu somente da 
análise dos padrões das informações coletadas, não recorrendo à literatura relacionada. 
Análise quantitativa. O primeiro passo da análise foi calcular a mediana e a moda de 
cada variável selecionada. No segundo passo, a correlação não-paramétrica entre as 
variáveis independentes e a dependente foi calculada. A correlação de Spearman foi 
escolhida por representar um método bem aceito para índices de correlação de dados em 
escala ordinal (Hair et al. 2006). O software SPSS (Statistical Package for the Social 
Sciences) foi usado para os cálculos estatísticos. O tamanho da amostra de dados é 21. 
 4. Resultados 
Para responder as questões de pesquisa, os pesquisadores analisaram os dados 
qualitativos obtidos nas entrevistas e questionário (perguntas abertas) em busca de 
padrões ou temas que pudessem explicar como a adoção de métodos ágeis pode 
influenciar o aprendizado dos times (QP1), e se há alguma relação entre métodos ágeis, 
aprendizado e produtividade (QP2). Para encontrar os temas, foram realizados os 
seguintes passos: 1) codificação dos dados com base nos termos e expressões usados 
pelos participantes; 2) revisão da codificação; 3) agrupamento dos códigos em temas, 
tendo em mente as questões de pesquisa e 4) revisão e seleção dos temas com maior 
frequência e maior relação entre si e com as questões de pesquisa. 
 A Tabela 2 mostra os temas identificados e as práticas de XP relacionadas, com 
respectivas frequências. O aprendizado foi o tema mais frequente e apareceu, na maior 
parte das vezes, em uma relação causa-efeito com os demais temas encontrados. As 
práticas de XP foram mencionadas em conjunto com alguns temas, também em uma 
relação causa-efeito. A relação entre o aprendizado dos times ágeis e a produtividade 
também foi identificada na análise, mas com menor intensidade. 
Tabela 2 – Principais temas encontrados, práticas de XP e frequências 
Tema Frequência Práticas de XP relacionadas Frequência 
Aprendizado 31 Programação em pares 9 
Comunicação 9 TDD 4 
Learning-by-doing 9 Reuniões diárias 3 
Experiência prévia 7 
Feedback constante 5 
Produtividade 3 
 A Figura 1 sumariza o mapa temático desenvolvido a partir da análise 
qualitativa. Ele enfatiza as principais relações encontradas e detalhadas a seguir. 
84
 
promovem
aumenta 
(Arrow 1962, Boh et al. 2007)
APRENDIZADO
PRODUTIVIDADE
FEEDBACK
CONSTANTE
COMUNICAÇÃO
LEARNING-BY-
DOING
EXPERIÊNCIA 
PRÉVIA
Temas identificados
aceleram
Programação em 
Pares
Reuniões diárias
TDD
Práticas de XP
 
Figura 1. Mapa temático e correlações 
4.1. Aceleração do aprendizado e produtividade 
O resultado do questionário apontou que 90% dos participantes do estudo acreditam que 
métodos ágeis aceleram ou aceleram muito o aprendizado de novas tecnologias, 
conceitos e padrões. Alguns entrevistados relataram que houve de fato diminuição da 
curva de aprendizado e percepção de produtividade mais alta, visível inclusive quando 
membros de outras equipes eram alocados no projeto por um período curto, ou quando 
os membros eram inexperientes. 
"A alocação de membros externos foi muito boa porque todo mundo saiu ganhando. O 
projeto ganhou porque rapidamente essas pessoas foram produtivas para o projeto. A 
outra equipe [foi beneficiada] porque ganhou pessoas capacitadas." (Participante 2) 
"o fato de que elas tiveram produtividade alta, mesmo sendo inexperientes [..] isso é 
sinal de que elas aprenderam alguma coisa" (Participante 5) 
De fato, a análise dos registros históricos da organização mostrou que os dois 
projetos ágeis já concluídos tiveram produtividade maior que os projetos tradicionais da 
empresa. A organização mede sua produtividade pela divisão do tamanho do software 
em pontos de função do software pelo esforço em horas gasto no projeto. O projeto 1 
teve produtividade 8% maior que a média da instituição e o projeto 2 teve produtividade 
32% maior que a média da instituição. Apesar da amostra deprojetos ser pequena, 
observou-se em ambos os projetos ágeis uma percepção de aceleração do aprendizado e 
um aumento da produtividade. Isso indica que pode haver correlação entre o 
aprendizado e a produtividade de times ágeis, o que já foi mostrado em outros contextos 
por Arrow (1962) e Boh et al. (2007). 
4.2. Fatores de influência no aprendizado e as práticas de XP. 
Buscou-se explorar que fatores dos métodos ágeis exerceram influência na aceleração 
do aprendizado. Além disso, foram investigadas as limitações dessa influência. 
Experiência prévia. O resultado do questionário mostrou que 60% dos membros dos 
dois times ágeis estudados não tinham experiência na tecnologia usada em seus projetos. 
Ainda assim, os projetos obtiveram êxito em sua produtividade, como já mencionado. 
No entanto, restava a dúvida dos fatores limitantes dessa capacidade de trabalhar com 
grande parte do time inexperiente e ainda sim obter aceleração de aprendizado e 
produtividade. Os entrevistados relataram que existem requisitos mínimos para que esse 
equilíbrio ocorra. A transcrição abaixo exemplifica a questão: 
"a capacitação não chega a tanto - a capacidade de capacitar, entende? Não dá para 
ensinar pra uma pessoa, em tempo de projeto, orientação a objetos [..] tem que ter um 
85
 
mínimo de capacitação inicial [..] pelo menos um pouco de experiência profissional" 
(Participante 2) 
A análise estatística dos dados sobre a experiência prévia do membro do time 
(Tabela 3) mostra que há correlação (p < 0.05) entre a Experiência prévia em orientação a 
objetos e a percepção de Aceleração do aprendizado. O mesmo não ocorreu entre a 
Experiência na Arquitetura de software da organização e a Aceleração do aprendizado. 
Tabela 3 – Estatística descritiva e Correlações não-paramétricas 
a 
Variável Mediana Moda 
Aceleração do Aprendizado 
 (com métodos ágeis) 
1. Experiência em OO G1 2 2 .577* 
2. Experiência na Arquitetura G1 2 2 .045 
3. Experiência em projetos G1 2 2 .577* 
4. Aceleração do Aprendizado 
(com métodos ágeis) 
5 5 - 
a
 n = 21 * p < 0.05 
Em suma, o resultado da análise estatística é consistente com os resultados das 
entrevistas, onde a experiência anterior profissional e em conceitos básicos é citada 
como essencial para aceleração do aprendizado de membros de projetos ágeis. Já a 
Experiência na Arquitetura de software não se mostrou fundamental nem para a aceleração 
do aprendizado, nem para a produtividade do time. Essa triangulação entre dados 
qualitativos e quantitativos melhora a confiabilidade da análise, principalmente pelo 
reduzido tamanho da amostra (n=21). 
Comunicação e disseminação do conhecimento. Vários entrevistados com diferentes 
papéis nos projetos mencionaram a comunicação como forte influenciadora na 
aceleração do aprendizado. Eles também relataram que as práticas de XP „programação 
em pares‟, „reunião diária‟ e „retrospectiva‟ dão suporte à comunicação. 
"O aprendizado foi reforçado por algumas das práticas: programação em par, reuniões 
diárias, retrospectivas... principalmente as que envolvem interação” (Participante 1) 
 “O nível de aprendizado dos integrantes são elevados devido a grande interação do 
grupo. [..] o conhecimento de um certo integrante é facilmente compartilhado para os 
outros” (Participante 18) 
"A programação em par com rodízio, sem dúvida, acelera o aprendizado, porque a 
pessoa que é mais fraca em determinado item troca a informação com a outra, então 
ocorre uma troca muita alta" (Participante 5) 
Feedback constante. O feedback foi citado em algumas entrevistas como mecanismo de 
aceleração do aprendizado. Em XP, o feedback é um dos quatro valores básicos (Beck 
2001) relacionado ao princípio de rápido feedback, que por sua vez está relacionado à 
várias práticas do método. O feedback também está obviamente relacionado à 
comunicação, sem a qual não é possível dar o feedback. 
“Tem algumas práticas que tem correlação com a aceleração do aprendizado e acho que 
tem um valor que está embutido em várias práticas que tem relação que é o feedback. As 
pessoas podem aprender porque elas experimentam e tem reação [..] Você consegue ver 
a correlação [causa-efeito] entre elas. O TDD tem muita relação com o feedback [..] 
quando eu mexo nas coisas [código] eu rapidamente percebo que o que estou fazendo 
não funciona.” (Participante 5) 
Learning-by-doing. O aprendizado pela experiência (learning-by-doing) é uma das 
diversas abordagens existentes para ensinar e aprender. XP defende que os times devem 
86
 
aprender constantemente pela experiência, seja na concepção do design de uma 
funcionalidade, seja durante o levantamento dos requisitos do usuário. Os entrevistados 
enfatizam que esse tipo de abordagem acelera o aprendizado, citando na maior parte das 
vezes a programação em pares como prática de apoio, além da correlação com o 
Feedback constante. 
“Quando uma nova pessoa se integra à equipe, ela já chega „colocando a mão na 
massa‟, o que agiliza bastante o aprendizado” (Participante 10) 
“A vantagem da programação em par é que ela é um treinamento in loco [..] é mais 
efetivo esse tipo de treinamento [..] poder praticar o que se está aprendendo e aplicar em 
problemas reais certamente agiliza o aprendizado" (Participante 2). 
“O XP é extremo nesse sentido do „mão na massa‟. Não é a mão na massa normal que 
você faz e leva uma semana ou duas para perceber que aquilo (o código) estava errado 
[..] O rodízio de pares ajuda nisso, não demora uma outra pessoa perceber que o código 
estava ruim, não demora para você entender o porquê. Se demorar, você não aprende" 
(Participante 5) 
Os entrevistados mencionaram vantagens e desvantagens entre os treinamentos 
formais, muito comuns nos programas de capacitação das empresas, e o aprendizado 
pela experiência. Foi demonstrada uma preferência pelo aprendizado pela experiência, 
mas existem fatores limitantes, como a predisposição de ensinar e aprender de cada 
membro ou o nível de experiência prévia. Nesse caso, pode-se optar pelo treinamento. 
“A programação em pares repassa o conhecimento na hora, na prática e na quantidade 
necessária [..] não adianta dar um treinamento de duas semanas e depois pôr [a pessoa] 
pra trabalhar.” (Participante 2) 
 “..pelo menos eu não senti falta do treinamento [formal]. Depois de um tempo [de projeto] 
participei de um treinamento avançado [da arquitetura padrão] e não aprendi nada novo. 
O treinamento antes do projeto pode ser interessante para pessoas com pouca 
experiência com desenvolvimento, ou com experiência em linguagens não orientadas a 
objetos” (Participante 4). 
“Colocar uma pessoa inexperiente ao lado de uma pessoa experiente só é válido quando 
a primeira tem interesse em aprender e quando a segunda não se importe em ajudar. De 
qualquer forma, não há ajuda que resolva quando se está desinteressado” (Participante 
15) 
 5. Discussão 
A experiência prévia aparece como um fator que influencia o grau de aprendizado em 
times ágeis. O estudo mostrou que para tirar proveito dos benefícios de XP na curva de 
aprendizado, é necessário ter um mínimo de experiência conceitual e profissional. 
Todavia, conhecimentos específicos em tecnologias e padrões não se mostraram 
essenciais e podem ser adquiridos pela prática (learning-by-doing). Essa hipótese pode 
indicar uma mudança de plano de capacitação nas organizações que adotam métodos 
ágeis. Elas podem tirar vantagem do ambiente favorável ao aprendizado que XP 
proporciona e reduzir custos com alguns tipos de treinamentos considerados 
desnecessários para parte do time. 
 A Programação em pares foi citada diversas vezes pelos participantes deste 
estudo como a prática de XP que favorece a comunicação, o feedback e o learning-by-
doing.Ela tem sido considerada um mecanismo superior à programação solo por 
viabilizar o aumento da qualidade do código e promover um ambiente de aprendizado e 
construção do espírito de time (Hulkko05, Coman08). Os participantes citaram que o 
87
 
rodízio de pares foi benéfico para o aprendizado, transmitindo o conhecimento e 
aumentando o feedback. Em XP, a programação em pares incentiva a troca constante de 
tarefas entre membros do time por meio do rodízio de pares, onde as tarefas estão 
sempre relacionadas ao objetivo mais próximo do time, definido na iteração. Além 
disso, os pares de XP são formados de maneira a incluir sempre um membro mais 
experiente na execução de determinada tarefa. Um estudo de Schilling et al. (2003) 
aponta que algum grau de variação nas tarefas do trabalho pode aumentar o grau de 
aprendizado de indivíduos, times e até organizações. Quando as tarefas estão 
correlacionadas de alguma forma, a curva de aprendizado pode ser melhorada. 
Por fim, segundo Alexander et al. (1991), o feedback é a informação com a qual 
um aprendiz pode confirmar, adicionar, alterar, otimizar ou reestruturar informações na 
memória. Um dos valores fundamentais de XP é o feedback rápido e, segundo Beck 
(2001), um dos principais mecanismos de aceleração do aprendizado. A análise 
qualitativa confirmou a relação entre o feedback e a aceleração do aprendizado, onde a 
prática de Desenvolvimento Dirigido por Testes (TDD) foi especialmente citada. E, de 
fato, o conceito de TDD é baseado em ciclos curtíssimos de feedback (segundos ou 
minutos) sobre as decisões de implementação (Beck 2003). Além disso, o feedback 
constante pode ser dado pela comunicação, outro valor fundamental de XP citado como 
fator de influência sobre o aprendizado. 
 6. Conclusão e trabalhos futuros 
As relações entre métodos ágeis e o aumento do aprendizado e da produtividade de 
times da indústria ainda não foram amplamente compreendidas. Este trabalho 
apresentou os resultados de um estudo empírico exploratório sobre o impacto da adoção 
de XP no aprendizado e na produtividade. Os resultados levantam a hipótese de que 
métodos ágeis podem, mediante a satisfação de alguns requisitos mínimos, acelerar o 
aprendizado, especialmente de novas tecnologias, conceitos e padrões. Houve também 
indícios de que essa aceleração ocorreu em conjunto com o aumento da produtividade. 
No entanto, essa hipótese precisa ser testada em trabalhos futuros. Como segundo 
resultado, foram identificados quatro fatores que podem influenciar a aceleração do 
aprendizado - experiência prévia, comunicação, feedback constante e learning-by-doing, 
três deles relacionados a práticas de XP. 
 Como um estudo exploratório e interpretativo, o objetivo desta pesquisa não é 
fazer generalizações, mas sim gerar hipóteses para novos estudos. Portanto, a validade 
interna do estudo de caso tornou-se prioritária e foi tratada de algumas maneiras. A 
triangulação de fontes de dados foi realizada com entrevistas com diferentes papéis e em 
dois períodos diferentes do tempo. Em alguns casos, dois métodos de análise 
(qualitativo e quantitativo) foram usados. Apesar do tempo limitado para o estudo de 
caso, já havia um histórico de cooperação entre a organização e os pesquisadores que 
permitiu melhorar o entendimento sobre os dados levantados e analisados. 
Finalmente, este artigo faz parte de uma pesquisa em desenvolvimento que 
compreende o estudo do impacto de métodos ágeis na produtividade dos times. As 
hipóteses aqui lançadas devem ser testadas em trabalhos futuros. Pretende-se pesquisar, 
em ambiente real, como funciona o processo de aprendizado na execução das práticas 
citadas. É necessário também um aprofundamento da pesquisa sobre a relação entre o 
aumento do aprendizado e o aumento da produtividade dos times ágeis. 
88
 
Agradecimentos 
Os autores agradecem o apoio financeiro recebido da Fapesp (processo 09/10338-3). 
Referências 
Alexander, P. A., Schallert, D. L., & Hare, V. C. (1991). Coming to terms: How researchers in learning 
and literacy talk about knowledge. Review of Educational Research, 61, 315-343. 
Arrow, K. (1962) “The economic implications of learning by doing”. Review of Economic Studies 29, 
155-173. 
Beck, K. (2001) Extreme Programming Explained - Embrace Change. Addison-Wesley. 
Beck, K. (2003) Test Driven Development: By Example. Addison-Wesley. 
Boh, W. F., Slaughter, S. A., and Espinosa, J. A. 2007. “Learning from Experience in Software 
Development: A Multilevel Analysis”. Manage. Sci. 53, 8 (Aug. 2007), 1315-1331. 
Boyatzis, R.E. (1998). “Transforming qualitative information: thematic analysis and code development”. 
Sage. 
Braun, V. and Clarke, V. (2006) “Using Thematic Analysis in Psychology,” Qualitative Research in 
Psychology, 3: 77–101. 
Coman, I.D., Sillitti, A., Succi, G.: (2008) “Investigating the Usefulness of Pair-Programming in a Mature 
Agile Team”. In: Proc. of the 6th International Conference on Extreme Programming and Agile 
Processes in Software Engineering (XP2008), pp. 127–136. (2008). 
Drobka, J., Noftz, D., Raghu, R.. (2004), "Piloting XP on Four Mission-Critical Projects," IEEE 
Software, pp. 70-75, November/December. 
Dybå, T e Dingsøyr, T. (2008) “Empirical studies of agile software development: A systematic review”. 
In: Information and Software Technology, 50(9-10):833–859. 
Easterbrook, S., Singer, J., Storey, M-A, Damian, D. (2008) “Selecting Empirical Methods for Software 
Engineering Research”, In: Guide to advanced empirical software engineering, Chapter 11. Springer-
Verlag, London. Hair J.F., Black, W. C., Babin, B. J., Anderson, R. E., and Tatham, R. L. (2006), 
Multivariate data analysis, 6th ed. Upper Saddle River, NJ: Pearson Education. 
Hulkko, H., Abrahamsson, P.: “A Multiple Case Study on the Impact of Pair Programming on Product 
Quality”. In: ICSE, pp. 495–504. ACM, New York (2005). 
Kelly, A. (2008) “Changing Software Development: Learning to be Agile”. John Wiley and Sons. 
Kerievsky, Joshua (2001). "Continuous Learning", Industrial Logic Inc. Disponível em: 
http://www.industriallogic.com/xp/ContinuousLearning.pdf 
Law, A. and Charron, R. 2005. “Effects of agile practices on social factors”. In Proceedings of the 2005 
Workshop on Human and Social Factors of Software Engineering (St. Louis, Missouri, May 16 - 16, 
2005). HSSE '05. ACM, New York, NY, 1-5. 
Melo, C. O. e Ferreira, G. R. M. “Adoção de métodos ágeis em uma Instituição Pública de grande porte - 
um estudo de caso”. In Proceedings of the Brazilian Workshop for Agile Methods (WBMA 2010) in 
the Brazilian Conference on Agile Methods, pp. 112-125. June, 2010. 
Nerur, S. and Balijepally, V. (2007). “Theoretical reflections on agile development methodologies”. 
Communications of the ACM 50, 3 (Mar. 2007), 79-83. 
Salleh, N., Mendes, E., Grundy, J (2010). "Empirical Studies of Pair Programming for CS/SE Teaching in 
Higher Education: A Systematic Literature Review," IEEE Trans. on Software Engineering, vol. 99. 
Schilling, M. A., Vidal, P., Ployhart, R. E., and Marangoni, A. 2003. “Learning by Doing Something Else: 
Variation, Relatedness, and the Learning Curve”. Manage. Sci. 49, 1 (Jan. 2003), 39-56. 
Tashakkori, A. and Teddlie, C. (2003) Handbook of mixed methods in social & behavioral research. Sage 
Publications. 
VersionOne (2009). “State of Agile Development” 4th annual survey. 
89
 
 
 
 
 
 
 
TECHNICAL SESSION 3 
Experimental Studies 
(ES) 
 
 
 
 
 
 
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 1, Simone do Rocio Senger de Souza 2, Jose´Carlos Maldonado 2
1Instituto de Informa´tica – Universidade Federal de Goia´s
P.O. 131 - Goiaˆnia, GO – Brasil – 74001-970
2Instituto de Cieˆncias Matema´ticas e de Computac¸a˜o – Universidade de Sa˜o Paulo
P.O. 668 – Sa˜o Carlos, SP – Brasil – 13560-970
marllosprado@gmail.com, {jcmaldon,srocio}@icmc.usp.br
Abstract. This paper presents the results of an experimental study accomplished
inside the scope of a master’s degree project to characterize and evaluate the
cost of application and strength of testing criteria, comparing object oriented
and procedural programming paradigms. This study considers functional and
structural criteria and uses a set of programs from data structure domain. The
main goals in the execution of this research were: i) To obtain initial results
above the investigated questions; ii) To generate artifacts which could be used
as basis to define and conduct future experiments; iii) To support training and
teaching of software testing activity.
1. Introduc¸a˜o
Uma das principais finalidades da atividade de teste de software e´ descobrir erros durante
o seu desenvolvimento. Esta atividade contribui para reduc¸a˜o do custo de manutenc¸a˜o e
para a melhora da qualidade do software. Isso tem motivado a investigac¸a˜o e proposta de
estrate´gias, te´cnicas, crite´rios e ferramentas de teste para diferentes paradigmas de desen-
volvimento tais como procedimental, orientado a objetos (OO) e orientado a aspectos.
O paradigma de desenvolvimento constitui-se em um dos alicerces para o de-
senvolvimento de sistemas computacionais uma vez que define a construc¸a˜o das estru-
turas que compo˜e o software de diferentes formas. O uso de um determinado para-
digma implica em diferenc¸as desde a forma de se abstrair e representar essas estruturas
[Takashi et al. 1990] ate´ o processo e tecnologias empregados [Pressman 2002]. Neste
contexto, os paradigmas procedimental e o OO destacam-se como os dois principais uti-
lizados na pra´tica do desenvolvimento de software atual.
A existeˆncia de particularidades e a diferenc¸a no modo de entender os problemas
imposta pelos paradigmas, fornecem indı´cios da possı´vel existeˆncia de diferentes fon-
tes de erros na composic¸a˜o do software, em raza˜o dos mesmos [Vincenzi et al. 2007].
Te´cnicas e crite´rios de teste teˆm sido propostos como forma de minimizar a presenc¸a de
erros no software, por meio da definic¸a˜o de casos de teste que aumentem a probabilidade
de identificar os mesmos. Dentre as principais te´cnicas de teste propostas, destacam-se
as te´cnicas funcional, estrutural e baseada em erros. Cada uma dessas te´cnicas envolve
um conjunto de crite´rios sendo que a principal caracterı´stica que as distingue consiste na
fonte de informac¸a˜o utilizada para definir os requisitos de teste.
A comparac¸a˜o entre te´cnicas e crite´rios de teste e´ realizada utilizando-se algumas
propriedades de teste. Dentre as mais importantes, citam-se o custo, efica´cia e dificuldade
de satisfac¸a˜o (strength).
91
Grande parte dos estudos experimentais realizados ate´ o momento, para ava-
liar e comparar crite´rios de teste, foram realizados com programas implementados sob
um mesmo paradigma ou desconsiderando a influeˆncia do mesmo sobre os resultados
[Juristo et al. 2004]. Contudo, e´ importante avaliar o impacto do paradigma sobre a ativi-
dade de teste uma vez que alguns defeitos podem estar relacionados ao seu uso.
A conduc¸a˜o de um experimento controlado ou mesmo um quasi-experimento, em
geral, e´ uma atividade cara e que exige muitas prerrogativas para sua execuc¸a˜o. Um
dos grandes problemas enfrentados pelos pesquisadores, durante a realizac¸a˜o de novos
estudos experimentais em teste de software e´ a falta de uma infra-estrutura de materiais,
ferramentas e resultados adequadamente preparados, para serem usados como recurso ou
embasamento do novo experimento. Essa na˜o e´ uma preocupac¸a˜o nova e esforc¸os nesse
sentido podem ser constatados em [Rothermel 2005]. Nesse trabalho os autores fazem um
survey de va´rios artigos com resultados experimentais sobre te´cnicas de teste, reportando
as dificuldades encontradas na conduc¸a˜o dos mesmos. Em resposta a esses obsta´culos,
os autores apresentam uma infra-estrutura a qual, em suma, e´ constituı´da de programas,
verso˜es, casos de teste, defeitos e scripts ja´ estabilizados e que estariam prontos para
realizac¸a˜o e replicac¸a˜o de experimentos controlados.
Ale´m da preocupac¸a˜o com a definic¸a˜o de novos experimentos em teste de pro-
gramas, em [Myers et al. 2004], nota-se preocupac¸a˜o com o ensino da atividade de teste
desde o aprendizado da pro´pria pra´tica de programac¸a˜o. Segundo o autor, esta medida
seria uma forma de habituar os alunos desde cedo a` realizac¸a˜o dos testes juntamente com
o desenvolvimento do programa, de uma forma sistema´tica e integrada.
Sendo assim, o objetivo deste trabalho foi conduzir um estudo experimental em
teste de software, comparando crite´rios de teste estruturais aplicados a um conjunto de
programas de um determinado domı´nio, implementados nos paradigmas OO e Procedi-
mental. Com o alcance desse objetivo pretendeu-se: i) Conseguir dentro de um contexto
restrito e bem definido, realizar um estudo que caracterizasse e avaliasse o custo e a difi-
culdade de satisfac¸a˜o (strength) de crite´rios de teste funcionais e estruturais para progra-
mas nos paradigmas procedimental e OO; ii) Colaborar com a definic¸a˜o de futuros experi-
mentos e pacotes de laborato´rio. Para tanto, buscou-se a consolidac¸a˜o de um conjunto de
crite´rios, ferramentas, programas e resultados que caracterizassem o domı´nio investigado,
viabilizando a replicac¸a˜o/ampliac¸a˜o de novos estudos experimentais com base nos resul-
tados e materiais gerados; iii) Desenvolver um arcabouc¸o de artefatos que pudessem ser
reaproveitados no contexto de treinamento e capacitac¸a˜o em testes. Sendo assim, uma das
consequ¨eˆncias desse objetivo foi a escolha do domı´nio de estrutura de dados para selec¸a˜o
dos programas a serem utilizados na investigac¸a˜o do trabalho. Essa decisa˜o teve como
objetivo ampliar a gama de problemas envolvidos com cada soluc¸a˜o testada, viabilizando
ao aluno situac¸o˜es diferentes para a aplicac¸a˜o de cada te´cnica e atrelando o aprendizado
de testes a`s fases iniciais do ensino de programac¸a˜o e desenvolvimento de software.
O artigo esta´ estruturado da seguinte forma. Na Sec¸a˜o 2, a definic¸a˜o e o plane-
jamento do estudo experimental sa˜o resumidamente descritos. Na Sec¸a˜o 3, os principais
elementos da conduc¸a˜o do experimento sa˜o apresentados. Na Sec¸a˜o 4 a ana´lise reali-
zada sobre os dados coletados e´ apresentada bem como os resultados alcanc¸ados com a
realizac¸a˜o desse trabalho. A sec¸a˜o 5 apresenta as concluso˜es e perspectivas de trabalhos
futuros.
2. Definic¸a˜o
A definic¸a˜o do estudo seguiu o template Goal Question Metric [Briand et al. 1996] e e´
apresentado na tabela 1.
92
Objeto de Estudo Os objetos de estudo sa˜o os crite´rios de teste funcional e estrutural aplicados no paradigma OO e os crite´rios
de teste funcional e estrutural aplicados no paradigma procedimental.
Propo´sito O propo´sito e´ caracterizar e avaliar os crite´rios, em particular com respeito a`s diferenc¸as entre os paradigmas.
Foco de Qualidade O foco de qualidade avaliado e´ o custo e a dificuldade de satisfac¸a˜o dos crite´rios nos dois paradigmas.
Perspectivas A perspectiva do experimento e´ do ponto de vista de pesquisadores.
Contexto A investigac¸a˜o sera´ conduzida pelo pro´prio pesquisador que definiu o estudo, sobre um conjunto de programas
de estrutura de dados. O estudo e´ conduzido na forma de um estudo de variac¸a˜o Multi-Objeto, ou seja, um
participante operando sobre um conjunto de objetos.
Tabela 1. Definic¸a˜o do experimento.
O contexto do experimento foi caracterizado como sendo um estudo off-line, con-
duzido porum estudante de mestrado, abordando um problema real (identificac¸a˜o e
comparac¸a˜o de custos e strength de crite´rios de teste), em um contexto especı´fico.
2.1. Formulac¸a˜o das Hipo´teses
O estudo proposto buscou delimitar caracterı´sticas acerca de um assunto ainda desconhe-
cido, a procura de evideˆncias que pudessem ser usadas na definic¸a˜o de futuras hipo´teses.
Sendo assim, as hipo´teses propostas na˜o pretendem ser definitivas, mas foram estabeleci-
das em cara´ter pragma´tico com o intuito de viabilizar a continuidade do trabalho dentro
do processo adotado.
Admitindo-se que os custos dos crite´rios de teste sobre um conjunto de programas
sejam medidos em termos do tamanho do conjunto de teste e do nu´mero de elementos re-
queridos e que esses sejam influenciados principalmente: (i) pelo paradigma de desenvol-
vimento em que sa˜o implementados; (ii) pelas ferramentas de teste usadas; (iii) pelos tipo
de crite´rios empregados; (iv) pela habilidade do(s) testador(es) em testar adequadamente
esses programas e; (v) pelo tamanho e complexidade dos programas testados. Fixando-se
as propriedades (iii) e (iv) como sendo as mesmas para dois conjuntos de programas A e
B implementados respectivamente nos paradigmas procedimental e OO, sabendo-se que
os paradigmas de programac¸a˜o representam formas distintas de se entender e estruturar
uma mesma soluc¸a˜o, acredita-se que exista uma diferenc¸a de custo entre os conjuntos A
e B, em raza˜o das diferenc¸as de paradigmas.
Da mesma forma que os custos, admitindo-se que o strength de cada crite´rio de
teste funcional e estrutural entre dois paradigmas seja medido em termos da porcentagem
de adequac¸a˜o do conjunto de teste adequado a esse crite´rio em um paradigma sobre o
mesmo crite´rio no paradigma oposto e vice-versa, e sabendo-se que os paradigmas de
programac¸a˜o procedimental e OO representam formas distintas de se entender e estruturar
uma mesma soluc¸a˜o, acredita-se que exista uma diferenc¸a de strength entre os conjunto
A e B (mesmos da hipo´tese anterior), em raza˜o da diferenc¸a de paradigma. As hipo´teses
formais do estudo encontram-se enunciadas na tabela 2.
Primeira Hipo´tese Segunda Hipo´tese
Hipo´tese Nula: Na˜o existe diferenc¸a de custo dos crite´rios de teste, Hipo´tese Nula: Na˜o existe diferenc¸a de strength dos crite´rios de teste,
em raza˜o do paradigma, entre o conjunto A (procedimental) e B (OO). em raza˜o do paradigma, entre o conjunto A (procedimental) e B (OO).
H0 : Custo(A) = Custo(B) H0 : Strength(A) = Strength(B)
Hipo´tese Alternativa: Existe uma diferenc¸a de custo dos crite´rios de teste, Hipo´tese Alternativa: Existe uma diferenc¸a de strength dos crite´rios de teste,
em raza˜o do paradigma, entre o conjunto A (procedimental) e B (OO). em raza˜o do paradigma, entre o conjunto A (procedimental) e B (OO).
H1 : Custo(A) 6= Custo(B) H1 : Strength(A) 6= Strength(B)
Tabela 2. Hipo´teses do experimento. A` esquerda, hipo´teses nula e alternativa
relativas ao custo. A` direita, hipo´teses nula e alternativa relativas ao strength.
93
2.1.1. Varia´veis Independentes
Varia´vel independente e´ toda varia´vel que pode ser manipulada ou controlada no pro-
cesso de experimentac¸a˜o. Seguindo essa perspectiva, as principais varia´veis indepen-
dentes desse estudo foram: i) Paradigma em que os programas esta˜o implementados;
ii)Ferramentas de teste usadas; iii) Crite´rios de teste empregados; iv) Tamanho e comple-
xidade dos programas sob teste; v) Habilidade do testador na aplicac¸a˜o dos crite´rios.
Apesar de existirem todas essas varia´veis independentes, a u´nica considerada de
interesse para a investigac¸a˜o e´ o paradigma em que os programas esta˜o implementados,
constituindo-se como o u´nico fator de interesse do experimento. Esse fator, possui dois
tratamentos: paradigma de implementac¸a˜o OO e paradigma de implementac¸a˜o proce-
dimental. As demais varia´veis foram fixadas no experimento para na˜o interferirem nos
efeitos obtidos.
2.1.2. Varia´veis Dependentes
As varia´veis dependentes sa˜o aquelas nas quais e´ observado o resultado da manipulac¸a˜o
das varia´veis independentes. No caso desse estudo, as varia´veis dependentes defini-
das para descrever os custos dos crite´rios foram: i) Nu´mero de Elementos Reque-
ridos/Programa; ii) Nu´mero de Casos de Teste/Programa; iii) Nu´mero de Elementos
Requeridos Na˜o-Executa´veis/Programa; iv) Nu´mero de Elementos Requeridos/Crite´rio;
v) Nu´mero de Casos de Teste/Crite´rio; vi) Nu´mero de Elementos Requeridos Na˜o-
Executa´veis/Crite´rio. As medidas por programa correspondem a`quelas feitas para cada
programa, durante a aplicac¸a˜o de um crite´rio, em um determinado paradigma e as medidas
por crite´rio, correspondem a`quelas feitas para todos os programas, durante a aplicac¸a˜o de
um crite´rio em um determinado paradigma.
As varia´veis dependentes definidas para descrever o strength dos crite´rios foram:
i) Porcentagem de Cobertura/Programa no paradigma oposto. ii) Porcentagem de Cober-
tura/Crite´rio no paradigma oposto.
Em adic¸a˜o a`s varia´veis dependentes citadas, algumas outras me´tricas foram defi-
nidas e coletadas no estudo. O objetivo dessa coleta foi registrar propriedades que pu-
dessem ser relevantes e que estivessem correlacionadas ao comportamento das varia´veis
dependentes, descrevendo mais detalhes do cena´rio dos testes funcionais e estruturais,
com relac¸a˜o a` diferenc¸a de paradigma. Essas me´tricas podem ser ainda reaproveitadas
no contexto de futuros estudos experimentais, tanto para a derivac¸a˜o de novas hipo´teses
a partir das informac¸o˜es por elas fornecidas, quanto para comparac¸a˜o de dados de teste
provenientes de programas cujas medidas se assemelhem a`s dos programas que compo˜e
este estudo. Desta forma, um total de doze me´tricas de implementac¸a˜o foram definidas.
A saber: total de unidades (procedimentos/me´todos e construtores); total LOC (linhas de
co´digo s/ comenta´rios); total de comandos de desvio; total de comandos recursivos; total
unidades sem paraˆmetros; total de unidades c/ paraˆmetros apenas do tipo primitivo; total
de unidades c/ paraˆmetros apenas do tipo abstrato (valor ou refereˆncia); total de unidades
c/ paraˆmetros mistos (primitivos e abstratos); total de unidades sem retorno; total de uni-
dades c/ retorno do tipo primitivo; total de unidades c/ retorno do tipo abstrato(valor ou
refereˆncia) e complexidade cicloma´tica (McCabe).
2.2. Design do Experimento
O design do experimento tem impacto direto sobre a forma de analisar os resultados.
Um design experimental adequado tambe´m serve para minimizar a influeˆncia de fatores
adversos sobre os resultados obtidos.
94
Conforme estabelecido anteriormente, o estudo conte´m apenas um fator de in-
teresse, ou seja, o paradigma das implementac¸o˜es testadas, o qual pode assumir dois
tratamentos: procedimental ou orientado a objeto.
Com relac¸a˜o a`s demais varia´veis independentes fixas, foram aplicados os seguin-
tes princı´pios de design, visando a reduc¸a˜o da probabilidade de erro experimental dentro
do contexto definido:
Aninhamento dos crite´rio de teste: Diferentes crite´rios de teste implicam em
maneiras distintas de se determinar os custos e strengths em cada paradigma. Para re-
solver essa questa˜o os crite´rios de teste foram agrupados em treˆs nı´veis (funcional, estru-
tural fluxo de controle e estrutural fluxo de dados) dentro de cada paradigma, seguindo
o princı´pio de aninhamento. Os crite´rios que compo˜em o nı´vel funcional sa˜o crite´rio
Particionamento por Classe de Equivaleˆncia e crite´rio Ana´lise Valor Limite. Os crite´rio
escolhidos para compor o nı´vel Estrutural Fluxo de Controle sa˜o crite´rio Todos-No´s e
crite´rio Todas-Arestas. Os crite´rio escolhidos para compor o nı´vel Estrutural Fluxo de
Dados sa˜o crite´rio Todos-Usos e crite´rio Todos-Potenciais-Usos. Esse princı´pio permite
que cada nı´vel seja avaliadoseparadamente dentro de cada tratamento, possibilitando uma
comparac¸a˜o efetiva de condic¸o˜es (nı´veis) similares entre os dois paradigmas. Ao fator
“Paradigma” denomina-se fator aninhador e ao fator “Crite´rio de teste” fator aninhado.
Esse design foi preferido em relac¸a˜o ao cruzado (crossed design), ja´ que ele permite a
comparac¸a˜o dos paradigmas em relac¸a˜o a um mesmo tipo de crite´rio, sem implicar na
ana´lise inversa (caracterı´stica do design cruzado), ou seja, tambe´m comparar os crite´rios
em relac¸a˜o a um mesmo tipo de paradigma.
Ordem dos testes: Com a finalidade de diminuir o ganho de habilidade pela
ordem com que os programas sa˜o testados em um determinado paradigma e que a rotina
neste lhe favorec¸a ou prejudique no outro paradigma, o princı´pio da aleatoriedade foi
usado para definir a ordem em que os programas seriam testados e para cada programa,
a ordem do paradigma a ser considerado primeiro. A ordem dos testes e´ aninhada a cada
nı´vel do crite´rio, ja´ que a estrate´gia de teste definida para gerac¸a˜o dos conjuntos de teste e´
incremental e, portanto, existe uma relac¸a˜o de interdependeˆncia com relac¸a˜o ao conjunto
de teste entre os crite´rios.
Para as demais varia´veis independentes fixas na˜o foi aplicado nenhum princı´pio
de design. A varia´vel “ferramenta de teste” foi definida com um valor fixo e distinto
para cada um dos paradigmas. No paradigma procedimental, o valor foi determinado
pelo par CUTE e Poke-Tool para aplicac¸a˜o dos crite´rios funcionais e estruturais res-
pectivamente [Sommerlad and Graf 2007, Chaim 1991]. No paradigma OO, JUnit e Ja-
BUTi representam na mesma ordem, as ferramentas para aplicac¸a˜o dos crite´rios de teste
[Riehle 2008, Vincenzi et al. 2003]. Apesar de na˜o serem as mesmas ferramentas aplica-
das nos dois paradigmas, existe uma grande semelhanc¸a quanto a` forma de operar e a`s
assertivas empregadas. Ale´m disso, ambas as ferramentas de teste estrutural apo´iam os
crite´rios de interesse para o estudo.
A especificac¸a˜o dos programas que compo˜em o conjunto procedimental e´ a
mesma dos programas que compo˜em o conjunto OO. Ale´m disso, ambos os conjuntos
esta˜o balanceados (mesma quantidade de programas nos dois paradigmas).
Nesse estudo, os casos de testes foram definidos para cada programa e em cada
um dos nı´veis de crite´rios de forma incremental, ou seja, o conjunto de teste gerado para
o nı´vel funcional foi reaproveitado na construc¸a˜o do conjunto de teste estrutural fluxo de
controle e assim sucessivamente. Com isso, foi necessa´rio organizar uma estrate´gia de
teste que viabilizasse essa conduc¸a˜o de forma sistema´tica, obedecendo o design experi-
mental definido.
95
A estrate´gia de teste definida foi dividida em quatro sec¸o˜es principais. Na pri-
meira sec¸a˜o, definiu-se que seria gerado o conjunto de teste adequado aos crite´rios funci-
onais. Este conjunto de teste foi derivado da especificac¸a˜o e portanto, deveria adequar-se
aos crite´rios de teste funcionais tanto para a implementac¸a˜o procedimental quanto para
a implementac¸a˜o OO do programa. Este constituiu o conjunto base para definic¸a˜o do
conjuntos de teste na sec¸a˜o seguinte e o nu´mero de elementos requeridos nessa fase foi
determinado em termos do nu´mero de classes de equivaleˆncia e valores limites gerados.
Na sec¸a˜o seguinte foi avaliada a cobertura do conjunto adequado ao primeiro nı´vel
para o segundo nı´vel de crite´rios, ou seja, para o nı´vel dos crite´rios estruturais fluxo de
controle. As porcentagens de cobertura atingidas nos dois paradigmas foram anotadas
no formula´rio de testes de cada implementac¸a˜o e em seguida foi feita a adequac¸a˜o dos
conjuntos de testes e a determinac¸a˜o dos elementos requeridos na˜o-executa´veis para os
crite´rios estruturais deste nı´vel.
O conjunto de teste adequado obtido na segunda sec¸a˜o serviu para realimentar
os teste estruturais fluxo de dados na terceira sec¸a˜o. Da mesma maneira, as porcenta-
gens de cobertura atingidas nos dois paradigmas foram anotadas no formula´rio de testes
de cada implementac¸a˜o e em seguida foi feita a adequac¸a˜o dos conjuntos de testes e a
determinac¸a˜o dos elementos requeridos na˜o-executa´veis para os crite´rios deste nı´vel.
Na quarta e u´ltima sec¸a˜o, os conjuntos de teste adequados gerados na segunda
e terceira sec¸a˜o foram convertidos na linguagem do paradigma oposto para verificac¸a˜o
do strength dos dois tipos de teste estrutural, por meio da anotac¸a˜o da porcentagem de
cobertura obtida.
2.3. Instrumentac¸a˜o
A instrumentac¸a˜o do estudo foi elaborada em va´rias etapas, de forma a suprir as treˆs
categorias de artefatos requeridos para operac¸a˜o do experimento: objetos do experimento,
guidelines e instrumentos de medida.
A primeira categoria consiste do benchmark de programas aos quais foram apli-
cados os tratamentos do experimento. Os programas que compo˜em o benchmark foram
obtidos de [Ziviani 2005b] (programas C, representantes do paradigma Procedimental) e
[Ziviani 2005a] (programas Java, representantes do paradigma OO). Contudo, por terem
sido projetados com propo´sito acadeˆmico, esses programas precisaram de alguns ajustes
para aproveitamento no estudo. Um dos motivos foi a incompatibilidade e/ou auseˆncia
de especificac¸o˜es em um formato apropriado para os testes e independente para cada pro-
grama. O outro motivo, foi a eventual incompatibilidade das implementac¸o˜es entre os
dois paradigmas, quanto a`s func¸o˜es: algumas operac¸o˜es implementadas na linguagem
OO simplesmente na˜o existiam ou eram diferentes daquelas implementadas na lingua-
gem procedimental, apesar de se referirem a` mesma especificac¸a˜o. Devido a isso, houve
a necessidade de preparar previamente esses programas seguindo alguns procedimentos
pre´-estabelecidos no plano do experimento. Ale´m disso, as especificac¸o˜es foram reescri-
tas em um formato padra˜o, pre´-definido. Esse formato de especificac¸a˜o foi derivado e
adaptado do empregado no pacote de laborato´rio de [Basili et al. 2008].
Grande parte dos textos das especificac¸o˜es basearam-se no texto original dos livros
[Ziviani 2005b] e [Ziviani 2005a]. Esses textos foram modificados ou adaptados, con-
forme cada caso, para suprir estritamente as necessidades de operac¸a˜o do estudo (como
desvinculamento da descric¸a˜o de uma especificac¸a˜o com algum co´digo-fonte exemplo e
remoc¸a˜o de dependeˆncias entre os textos de especificac¸o˜es distintas). Esta medida foi
tomada com o intuito de interferir o mı´nimo possı´vel sobre o conteu´do do texto original
e ao mesmo tempo atender a`s necessidades impostas pelo princı´pio de aleatoriedade dos
testes, conforme definido no design experimental.
96
A aplicac¸a˜o dos tratamentos no experimento exigiu outros documentos que au-
xiliassem na execuc¸a˜o dos testes, ale´m das especificac¸o˜es. Para tanto foi concebido um
documento de implementac¸a˜o, de forma a suprir o testador das informac¸o˜es necessa´rias
para a construc¸a˜o dos casos de testes funcionais (como paraˆmetros de entrada e tipos
de retorno esperados por operac¸a˜o) sem que fosse necessa´ria a leitura do co´digo-fonte
completo.
Ale´m dos documentos de especificac¸a˜o e implementac¸a˜o, dois formula´rios foram
definidos para aplicac¸a˜o dos testes: o primeiro e´ um formula´rio auxiliar para definic¸a˜o das
classes de equivaleˆncia, durante os testes funcionais. O segundo formula´rio (formula´rio
de testes), serviu para registrar os casos de teste para cada crite´rio avaliado e as medidas
de teste auferidas.
A instrumentac¸a˜o do estudo-experimental conta ainda com os co´digos-fontes dos
programas em linguagem C e Java, as ferramentas de teste e um documento de guidelines.
3. Preparac¸a˜o da Conduc¸a˜o do Estudo
A preparac¸a˜o da operac¸a˜o do estudo se deu a partir da pro´pria definic¸a˜o do plano. Tendo-
se definido os documentos e formula´rios para execuc¸a˜o dos testes prosseguiu-secom a
adequac¸a˜o e configurac¸a˜o das ferramentas de uma maneira robusta para que pudessem
ser usadas ao longo do experimento, na expectativa de prever-se futuros problemas que
pudessem acarretar em atrasos na conduc¸a˜o dos testes.
Como uma das finalidades do estudo era viabilizar a definic¸a˜o de futuros estudos
experimentais e treinamento em teste, julgou-se adequado instalar e configurar as ferra-
mentas de forma que elas pudessem ser facilmente reaproveitadas em novos contextos
sem a necessidade do retrabalho e mantendo-se alguma garantia de um funcionamento
esta´vel. Usualmente, para este fim, especifica-se as verso˜es e os requisitos de sistema
para replicac¸a˜o de estudos com ferramentas. Contudo, muitas vezes isso na˜o e´ o sufici-
ente para eliminar dificuldades com sua instalac¸a˜o/configurac¸a˜o e na˜o diminui a chance
de interfereˆncia por alguma configurac¸a˜o extra ale´m dos requisitos exigidos. A partir
dessa necessidade, surgiu-se a ide´ia de definir uma ma´quina virtual, sobre a qual essas
ferramentas pudessem ser agrupadas e configuradas para uso direto. Dentre os benefı´cios
encontrados com essa pra´tica podem-se citar: a portabilidade na˜o so´ das ferramentas e
do sistema operacional mas de toda uma configurac¸a˜o de sistema especı´fica, a possibili-
dade de replicac¸a˜o e gerac¸a˜o de backup de forma pra´tica e relativamente ra´pida, a via-
bilidade de evoluc¸a˜o de configurac¸o˜es de ferramentas sem o comprometimento de uma
configurac¸a˜o ja´ esta´vel, a possibilidade de interrupc¸a˜o e continuac¸a˜o de uma tarefa em
datas diferentes mantendo-se o mesmo estado do sistema operacional e dos programas
utilizados e a persisteˆncia direta dos resultados gerados internamente pela co´pia em uso.
4. Ana´lise
A ana´lise dos dados foi realizada em duas fases. A primeira consistiu em apresentar todas
as medidas para cada tipo de me´trica considerada no estudo e juntamente com as medidas
de tendeˆncia central relativas, obter informac¸o˜es que pudessem ser analisadas pontual-
mente, caracterizando o contexto dos programas e dos conjuntos de teste envolvidos.
Na segunda fase uma abordagem mais rigorosa foi empregada, para verificac¸a˜o
das hipo´teses definidas no plano. A aplicac¸a˜o dos testes para verificac¸a˜o das hipo´teses
definidas no plano foi precedida de um teste de ajustamento para verificac¸a˜o da normali-
dade da distribuic¸a˜o amostral das varia´veis a serem utilizadas na verificac¸a˜o das hipo´teses.
Para este fim empregou-se o teste de Shapiro-Wilk [Conover 1998], adequ¨ado ao tamanho
da amostra considerada. O teste revelou uma distribuic¸a˜o na˜o normal dos dados amostrais
97
para as varia´veis relacionadas a`s duas hipo´teses investigadas, apontando a necessidade de
aplicac¸a˜o de um teste na˜o-parame´trico para a verificac¸a˜o das hipo´teses.
O teste na˜o parame´trico adotado foi o teste de Wilcoxon
[Hollander and Wolfe 1999]. A aplicac¸a˜o desse teste foi feita em duas etapas para
cada uma das duas hipo´teses consideradas. Essa medida foi tomada visando atender o
design experimental que subdividia os crite´rios em dois nı´veis.
Na verificac¸a˜o da primeira hipo´tese, foi revelada uma discrepaˆncia entre os resul-
tados para os crite´rios no nı´vel de fluxo de controle e no nı´vel de fluxo de dados, na˜o
rejeitando para o primeiro nı´vel e rejeitando para o segundo nı´vel. Essa dualidade foi
resolvida retomando-se a ana´lise pontual dos dados, feita na primeira parte da sec¸a˜o de
ana´lise. Nesta, as observac¸o˜es feitas sobre a me´dia, desvios padro˜es, valores mı´nimos
e ma´ximos indicavam na direc¸a˜o da na˜o rejeic¸a˜o da hipo´tese nula em ambos os nı´veis.
Ale´m disso, o valor da probabilidade de significaˆncia que rejeitou o teste de hipo´tese no
segundo nı´vel, por estar muito pro´ximo ao nı´vel de significaˆncia adotado, tambe´m foi
considerado para questionamento dessa rejeic¸a˜o.
A verificac¸a˜o da segunda hipo´tese, relacionada a` diferenc¸a de strength entre os pa-
radigmas, na˜o apresentou discrepaˆncia entre os nı´veis, na˜o conseguindo rejeitar a hipo´tese
nula tanto no nı´vel fluxo de controle quanto no nı´vel fluxo de dados.
Logo, a ana´lise pontual e estatı´stica dos dados permitiram concluir que na˜o e´
possı´vel afirmar que exista uma diferenc¸a de custo e de strength, em raza˜o dos paradig-
mas, tanto para crite´rios estruturais de fluxo de controle quanto para crite´rios de fluxo
de dados, considerando-se o domı´nio de programas investigados e o contexto no qual
a investigac¸a˜o foi realizada. Isso significa que ainda que na˜o se tenha conseguido de-
monstrar a existeˆncias dessas diferenc¸as nesta investigac¸a˜o, novos estudos experimentais
futuros devem ser realizado, considerando-se um contexto mais amplo de programas,
linguagens e participantes. Esses estudos poderiam fornecer mais evideˆncias a favor da
aceitac¸a˜o das hipo´tese nulas, ou ainda, revelar outros domı´nios em que os dados fornec¸am
evideˆncias suficientes para refuta´-las. De qualquer forma, a realizac¸a˜o desses novos ex-
perimentos podera´ agora, ser amparada pelos artefatos gerados nesse trabalho e seus re-
sultados e concluso˜es, comparados com os ja´ obtidos.
5. Concluso˜es e Trabalhos Futuros
A realizac¸a˜o deste estudo experimental permitiu comparar custo e strength de crite´rios de
teste estruturais aplicados a programas do paradigma procedimental e orientado a objetos,
no domı´nio de estrutura de dados. A finalidade da investigac¸a˜o foi prover resultados
iniciais na a´rea sobre essa questa˜o, uma vez que nenhum trabalho com tal finalidade havia
sido realizado ainda.
Conforme discutido anteriormente, a atividade e os resultados de teste esta˜o sujei-
tos a` influeˆncia de diversos fatores, dentre eles o paradigma de desenvolvimento adotado
e o domı´nio de programas considerados. Para se avaliar essas questo˜es, ale´m do co-
nhecimento de testes, a realizac¸a˜o de estudos experimentais considerando-se os termos e
processos da engenharia de software experimental se faz necessa´ria.
Para o planejamento, conduc¸a˜o e ana´lise do estudo, foram empregados os termos
e processos utilizados na experimentac¸a˜o controlada, a` medida em que estes se mostraram
apropriados. Para tanto, foram utilizados:
• O template GQM para estabelecimento do contexto da investigac¸a˜o;
• A escolha das varia´veis independentes, dependentes e a definic¸a˜o das hipo´teses de
interesse para o estudo; Ale´m das varia´veis, foi considerada a coleta de 12 me´tricas
98
de implementac¸a˜o, para caracterizac¸a˜o de propriedades esta´ticas dos programas
envolvidos no estudo.
• A elaborac¸a˜o de um design experimental que refletisse os propo´sitos comparativos
analisados; O design em questa˜o aplica os princı´pios de aninhamento, balancea-
mento e randomizac¸a˜o, sobre os fatores envolvidos no estudo.
• A ana´lise de questo˜es de validade interna, externa, de construc¸a˜o e de conclusa˜o,
relacionadas ao tipo de estudo considerado;
• A instrumentac¸a˜o adequada para construc¸a˜o e utilizac¸a˜o dos artefatos necessa´rios
a` conduc¸a˜o do estudo. Dentre os artefatos desenvolvidos constam: A definic¸a˜o
dos pro´prios templates dos documentos e formula´rios empregados no estudo; 32
documentos de especificac¸a˜o, relativos a cada programa testado no estudo; 32 pro-
gramas C e 32 programas Java, correspondentes a`s implementac¸o˜es procedimental
e OO de cada especificac¸a˜o; 1 documento de implementac¸a˜o para disponibilizac¸a˜o
das me´tricas de implementac¸a˜o e auxilio na realizac¸a˜o dos testes funcionais,
correspondente a cada uma das implementac¸o˜es envolvidas; 1 formula´rio para
descric¸a˜o das classes de equivaleˆncia de cada especificac¸a˜o, durante a realizac¸a˜o
dos testes funcionais; 1 formula´rio de teste para registro textual dos casos de teste
e coleta das medidas de teste correspondente a cada uma das implementac¸o˜es.
• A realizac¸a˜o de uma ana´lise estatı´sticasobre os dados, considerando a utilizac¸a˜o
de testes de hipo´teses.
• A definic¸a˜o de uma ma´quina virtual, contendo todos os artefatos descritos anteri-
ormente mais as ferramentas, as quais ja´ se encontram instaladas e configuradas
para uso.
A realizac¸a˜o da investigac¸a˜o nesses moldes contribui para a necessidade atual
da a´rea de engenharia de software quanto a` realizac¸a˜o de estudos experimentais com
mais rigor cientı´fico, aumentando a validade sobre as concluso˜es obtidas e viabilizando
a replicac¸a˜o/ampliac¸a˜o desses estudos em outros cena´rios. Desta forma, espera-se que o
arcabouc¸o de artefatos gerados, a experieˆncia pra´tica adquirida na execuc¸a˜o de cada etapa
do processo (plano, conduc¸a˜o e ana´lise) e os resultados obtidos ao final da investigac¸a˜o,
sejam u´teis na definic¸a˜o de futuros estudos experimentais na a´rea de testes.
Acredita-se ainda que tanto o material gerado quanto os resultados de teste, sa˜o
u´teis no contexto de ensino e treinamento de teste de software, uma vez que foram defini-
dos no domı´nio de programas de estrutura de dados e considerando este fim.
Os resultados obtidos por meio da ana´lise realizada no estudo na˜o forneceram
evideˆncias quanto a` existeˆncia de diferenc¸as de custos e de strength entre os paradigmas
procedimentais e OO, considerando o domı´nio de estrutura de dados. Ainda que esses
resultados estejam na direc¸a˜o correta com relac¸a˜o a` comparac¸a˜o de custos e strength entre
os paradigmas considerados, a realizac¸a˜o de estudos experimentais futuros considerando
um contexto mais amplo de programas, linguagens e participantes se faz necessa´rio. Esses
estudos serviriam para aumentar a confianc¸a quanto a` na˜o-rejeic¸a˜o das hipo´teses nulas
verificadas nesse trabalho, fornecendo mais evidencias a favor da aceitac¸a˜o das mesmas
ou para encontrar outros domı´nios em que as evideˆncias sejam suficientes para refuta´-las,
revelando nesse u´ltimo caso uma sensibilidade ao contexto considerado.
Trabalhos futuros que verifiquem as hipo´teses deste trabalho considerando outras
te´cnicas de teste tambe´m sa˜o oportunos. No aˆmbito do grupo de pesquisa em que este tra-
balho foi desenvolvido, outro trabalho de mestrado foi realizado considerando o contexto
de ana´lise de mutantes para verificac¸a˜o das mesmas hipo´teses. A integrac¸a˜o dos resul-
tados e artefatos gerados nos dois trabalhos colaboram para a formac¸a˜o de um corpo de
conhecimento so´lido envolvendo as treˆs principais te´cnicas de teste de programas. Mais
detalhes a respeito do planejamento, questo˜es de validade, instrumentac¸a˜o, conduc¸a˜o e
99
ana´lise do estudo esta˜o disponı´veis em [Prado 2009].
Refereˆncias
Basili, V., Green, S., Laitenberger, O., Lanubile, F., Shull, F., Sørumga˚rd, S., and Zel-
kowitz, M. (2008). Lab package for the empirical investigation of perspective-based
reading. World Wide Web.
Briand, L. C., Differding, M. C., and Rombach, H. D. (1996). Practical guidelines for
measurement-based process improvement. Software Process Improvement and Prac-
tice, 2(4):253,280.
Chaim, M. L. (1991). Poke-Tool — uma ferramenta para suporte ao teste es-
trutural de programas baseados em ana´lise de fluxo de dados. Master’s thesis,
DCA/FEEC/UNICAMP, Campinas, SP.
Conover, W. J. (1998). Practical Nonparametric Statistics. John Wiley & Sons.
Hollander, M. and Wolfe, D. A. (1999). Nonparametric Statistical Methods, 2nd Edition.
Wiley-Interscience.
Juristo, N., Moreno, A. M., and Vegas, S. (2004). Reviewing 25 years of testing technique
experiments. Empirical Software Engineering, 9(7-44):133,164.
Myers, G. J., Sandler, C., Badgett, T., and Thomas, T. M. (2004). The Art of Software
Testing. John Wiley & Sons, Inc., Hoboken, New Jersey.
Prado, M. P. (2009). Um Estudo de Caracterizac¸a˜o e Avaliac¸a˜o de Crite´rios de Teste
Estruturais entre os Paradigmas Procedimental e OO. Dissertac¸a˜o de mestrado,
ICMC/USP, Sa˜o Carlos, SP.
Pressman, R. S. (2002). Engenharia de Software. McGraw-Hill, 5nd. edition.
Riehle, D. (2008). Junit 3.8 documented using collaborations. SIGSOFT Softw. Eng.
Notes, 33(2):1–28.
Rothermel, H. D. S. E. G. (2005). Supporting controlled experimentation with testing te-
chniques: An infrastructure and its potential impact. Empirical Software Engineering:
An International Journal, 10(4).
Sommerlad, P. and Graf, E. (2007). Cute: C++ unit testing easier. In OOPSLA ’07:
Companion to the 22nd ACM SIGPLAN conference on Object oriented programming
systems and applications companion, pages 783–784, New York, NY, USA. ACM.
Takashi, T., Liesenberg, H. K. E., and Xavier, D. T. (1990). Programac¸a˜o Orientada a
Objetos – Uma visa˜o Integrada do Paradigma de Objetos. VII Escola de Computac¸a˜o,
Sa˜o Paulo - SP, 1st. edition.
Vincenzi, A. M. R., Domingues, A. L. S., Delamaro, M. E., and Maldonado, J. C. (2007).
Introduc¸a˜o ao Teste de Software, chapter Teste Orientado a Objetos e de Componentes,
pages 119,174. Campus / Elsevier, 1st edition.
Vincenzi, A. M. R., Wong, W. E., Delamaro, M. E., and Maldonado, J. C. (2003). JaBUTi:
A coverage analysis tool for Java programs. In XVII SBES – Simpo´sio Brasileiro de
Engenharia de Software, pages 79–84, Manaus, AM, Brasil.
Ziviani, N. (2005a). Projeto de Algoritmos com Implementac¸o˜es em Java e C++. Thom-
son.
Ziviani, N. (2005b). Projeto de Algoritmos com Implementac¸o˜es em Pascal e C. Thom-
son, 2nd. edition.
100
Reuso de conjuntos de casos de teste no ensino de
disciplinas introduto´rias de programac¸a˜o
Maria A. S. Brito1, Joa˜o L. Rossi1, Simone R. S. de Souza1,
Rosana T. V. Braga1
1Instituto de Cieˆncias Matema´ticas e de Computac¸a˜o – Universidade
de Sa˜o Paulo (ICMC/USP)
Caixa Postal 668 – CEP: 13560-970 – Sa˜o Carlos - SP – Brazil
{masbrit,rossi,srocio,rtvb}@icmc.usp.br
Abstract. This paper presents an experimental study to evaluate the sup-
port of test suite to improve the teaching of the introductory class in pro-
gramming. The paper investigates if test cases adequate to the reference
programs can be useful to improve the quality of the programs generated by
students these classes. The subject of the study was the manipulation of
vectors and matrices. Starting from reference programs of this subject, we
generated test cases based on functional testing technique. The test sets
were reused by students to test their programs, which were similar to refe-
rence programs. Evidence indicates that the reuse of tests suite can help to
increase the quality of equivalent programs generated by students. Besides,
introductory class students can to observe the importance of test activity.
Resumo. Este artigo descreve uma proposta de reuso de conjuntos de teste
no ensino de disciplinas introduto´rias de programac¸a˜o como alternativa
para aumento na qualidade dos programas gerados pelos alunos. Para re-
forc¸ar a validade da proposta foi realizado um estudo experimental com o
objetivo de investigar o reuso de conjuntos de teste como contribuic¸a˜o ao
aumento da qualidade dos programas implementados por alunos. O estudo
foi realizado no domı´nio de manipulac¸a˜o de vetores e de matrizes. Foram
gerados conjuntos de casos de teste funcional com base em programas de
refereˆncia. Os conjuntos de teste foram reutilizados pelos alunos para o
teste de programas equivalentes aos programas de refereˆncia. Evideˆncias
indicam que o reuso de conjuntos de teste pode contribuir para o aumento
na qualidade dos programas equivalentes gerados pelos alunos.
1. Introduc¸a˜o
O ensino de disciplinas introduto´rias de programac¸a˜o difere do ensino de outras dis-
ciplinas, pois ensinar programac¸a˜o e´ antes de qualquer coisa ensinar a resolver pro-
blemas, a construir ideias e assim, ensinar o aluno a pensar [Dijkstra 1972]. Muitas
vezes, a inexperieˆncia em lo´gica de programac¸a˜o ocasiona a necessidade do professor
despertar no aluno a capacidadepara compreensa˜o da lo´gica existente por tra´s da
mera codificac¸a˜o.
No me´todo de ensino tradicional, inicialmente sa˜o fornecidas ao aluno as
regras (estruturas da linguagem de programac¸a˜o) para que os problemas possam ser
101
solucionados. Em seguida, o professor fornece ao aluno a especificac¸a˜o do programa,
enquanto espera que o aluno construa um programa capaz de resolver o problema
proposto. Nesse caso, o aluno possui apenas a especificac¸a˜o do programa e com base
nela deve chegar ao resultado esperado, que e´ a codificac¸a˜o de um programa correto.
Nessa abordagem, o aluno cria e aplica alguns testes os quais julga suficientes e
admite que o programa esta´ correto.
A partir do estudo apresentado neste artigo, e´ proposta uma abordagem de
ensino em que o aluno recebe do professor a especificac¸a˜o do problema e um conjunto
de teste adequado a um programa equivalente ao que sera´ criado. Define-se como
programas equivalentes quaisquer dois programas P1 e P2, nos quais a mesma sa´ıda
s1 resultante do processamento da entrada e1 para P1 e´ obtida para o programa P2
se considerada a entrada e1 [Weyuker 1986]. Pore´m, em programas equivalentes as
funcionalidades podem ser implementadas de maneiras distintas.
Com base nessa ideia, a` medida que o programa e´ constru´ıdo, o aluno pode
reusar os casos de teste e avaliar se o programa em construc¸a˜o esta´ livre dos defeitos
previstos pelos casos de teste que esta˜o sendo reusados. Dessa forma, o me´todo con-
tribui para o aumento da qualidade dos programas gerados pelos alunos. Qualidade
aqui refere-se a` conformidade da implementac¸a˜o do programa com a especificac¸a˜o
do mesmo. Outra vertente dessa abordagem, e´ que, ao mesmo tempo que aprende
a programar, o aluno compreende a importaˆncia da atividade de teste de software.
O estudo envolveu a utilizac¸a˜o de dois domı´nios da programac¸a˜o para a ge-
rac¸a˜o dos conjuntos de casos de teste: manipulac¸a˜o de vetores e manipulac¸a˜o de
matrizes. O estudo foi realizado em duas turmas de cursos de computac¸a˜o do ICMC.
Em cada turma, os alunos foram divididos em dois grupos de forma aleato´ria, no
qual um grupo de alunos recebeu apenas a especificac¸a˜o do programa e o outro grupo
recebeu a especificac¸a˜o do programa e o conjunto de teste. Ao final, foram gerados
60 programas implementados pelos alunos para ana´lise. Com base nos testes de
Kruskal-Wallis conclui-se que ha´ evideˆncias de que o reuso de conjuntos de teste de
software pode contribuir para a melhoria da qualidade dos programas gerados por
alunos de cursos introduto´rios de programac¸a˜o.
Este artigo esta´ organizado da seguinte forma: Na Sec¸a˜o 2 sa˜o apresentados os
trabalhos relacionados. Na Sec¸a˜o 3 sa˜o apresentados conceitos de teste de software.
Na Sec¸a˜o 4 e´ apresentada a descric¸a˜o do estudo realizado com o planejamento e
resultados obtidos. Na Sec¸a˜o 5 sa˜o apresentadas as discusso˜es sobre o estudo. Por
fim, na Sec¸a˜o 6 sa˜o apresentadas as concluso˜es do artigo.
2. Trabalhos Relacionados
Na literatura alguns trabalhos enfatizam o reuso de teste de software. Em Wang et
al. [1997] e´ discutida a reusabilidade de testes, no contexto de programac¸a˜o orien-
tada a objetos, fazendo uso de mecanismos testa´veis embutidos no co´digo que sa˜o os
testes built-in (BIT). Nessa modalidade, os testes sa˜o explicitamente declarados na
interface do objeto. Essa flexibilidade dos BITs permite heranc¸a e reuso da mesma
forma que o reuso de func¸o˜es para um objeto.
Wang et al. [2000] propo˜em estender o reuso provido pelos testes embutidos
(BITs) aplicando-os a frameworks orientados a objetos. Num framework, os BITs
102
podem ser estruturados em classes ou outras formas, possibilitando reuso de co´digo
e das estruturas de teste. Quando as classes do framework sa˜o instanciadas, as
func¸o˜es reutiliza´veis, que ja´ conteˆm testes embutidos, tambe´m o sa˜o. Estruturas de
teste adicionais sa˜o necessa´rias apenas para func¸o˜es que sofreram reuso parcial ou
novas func¸o˜es da aplicac¸a˜o gerada.
Yao e Wang [2005] utilizam BITs para prover um framework baseado em
CORBA (Common Object Request Broker Architecture) para teste remoto de soft-
ware distribu´ıdo. Na proposta apresentada para arquitetura cliente servidor, e´
fornecido um ambiente que permite ao cliente definir testes caixa preta para com-
ponentes publicados no servidor. Essa abordagem preveˆ reuso e automatizac¸a˜o dos
testes, pois tratando-se de BITs, o cliente pode reusar os testes existentes para um
componente no servidor ou criar novos testes.
Alguns outros trabalhos seguem a linha de reuso de scrips de
teste [Wu et al. 2009, Jin 2009]. Liu e Yang [2005] apresentam uma proposta
baseada em reuso de casos de teste para prover gerac¸a˜o automa´tica de casos de
teste. A gerac¸a˜o e´ facilitada por um reposito´rio que armazena os casos de teste
e sua descric¸a˜o. A padronizac¸a˜o na descric¸a˜o e´ fundamental para que seja pos-
s´ıvel uma posterior recuperac¸a˜o dos casos de teste. Um algoritmo de mapeamento
relaciona as descric¸o˜es e os casos de teste do reposito´rio.
O conceito de teste de software tambe´m vem sendo explorado no ensino.
Hoffman et al. [1996] sugerem a inserc¸a˜o de te´cnicas de teste no ensino da disciplina
de Engenharia de Software como uma das atividades de garantia de qualidade de
software. Em Souza & Barbosa [2009] e´ apresentado um ambiente para submissa˜o
e avaliac¸a˜o de trabalhos pra´ticos. O ambiente preveˆ a utilizac¸a˜o de teste de software
como forma de aplicac¸a˜o dos conceitos abstratos de linguagem de programac¸a˜o e
como estrate´gia para facilitar a avaliac¸a˜o dos trabalhos dos alunos.
Campanha et al. [2009] apresentam os resultados de um estudo experi-
mental sobre reuso de conjuntos de casos de teste adequados ao crite´rio Ana´lise de
Mutac¸a˜o (AM) em programas equivalentes, no domı´nio de ordenac¸a˜o de vetores. Na
conduc¸a˜o do experimento, dois alunos de po´s-graduac¸a˜o desenvolveram verso˜es de
refereˆncia dos algoritmos de ordenac¸a˜o bubble sort, selection sort e insertion sort e
geraram, para cada programa implementado, conjuntos de casos de teste adequados
ao crite´rio AM. Alunos de graduac¸a˜o de uma disciplina introduto´ria de progra-
mac¸a˜o implementaram verso˜es equivalentes dos programas de refereˆncia, os quais
foram testados com os conjuntos de casos de teste gerados a partir dos programas
de refereˆncia. Concluiu-se com o experimento que o reuso de conjuntos de casos de
teste gerados a partir do crite´rio AM para programas equivalentes pode ser de fato
efetiva, podendo reduzir o custo de desenvolvimento dos testes.
Com base nesse trabalho, previu-se a possibilidade de aplicar reuso de con-
juntos de casos de teste como apoio ao ensino de disciplinas introduto´rias de progra-
mac¸a˜o. Pretende-se qualificar o reuso de conjuntos de casos de teste como instru-
mento alternativo a` especificac¸a˜o de requisitos fornecida pelo professor aos alunos,
servindo como outra informac¸a˜o sobre o programa a ser constru´ıdo. A ideia e´ que
o conjunto de teste sirva de aux´ılio quanto a` avaliac¸a˜o da corretude do programa
103
durante o desenvolvimento.
3. Teste de Software
O processo de desenvolvimento de software envolve o emprego de me´todos, te´cni-
cas e ferramentas, pore´m isso na˜o evita a ocorreˆncia de erros. Para que os erros
sejam reduzidos, existem as atividades de VV&T (Verificac¸a˜o, Validac¸a˜o e Teste de
software) que sa˜o empregadas durante o ciclo de desenvolvimento de software. A
Verificac¸a˜o e´ o processo de identificar se a construc¸a˜o do software esta´ sendo feita da
forma correta. A Validac¸a˜o envolve avaliar se o software desenvolvido obedece aos
requisitos propostos pelo cliente. A atividade de Teste de Software envolve revelar
a presenc¸a de defeitos, caso existam [Myers et al. 2004].
A atividade de teste deve estar presente durante todoo ciclo de desenvolvi-
mento, esta possui as seguintes fases ou n´ıveis: 1) teste de unidade, fase em que sa˜o
testadas as menores unidades que compo˜e o software, como procedimentos, func¸o˜es
ou me´todos e classes; 2) teste de integrac¸a˜o, fase em que e´ testada a integrac¸a˜o
entre os mo´dulos, componentes ou outras formas de unidade que compo˜e o software
e; 3) teste de sistema, em que o sistema e´ testado como um todo, os testes apli-
cados nessa fase incluem o teste de estresse, teste de seguranc¸a, de carga, dentre
outros. Ale´m dessas treˆs fases, existem tambe´m os testes de regressa˜o, realizados
quando o programa sofre alterac¸o˜es e precisa passar por novos testes que mostrem
que tanto os requisitos introduzidos, se for o caso, ou os requisitos anteriormente
testados continuam va´lidos [Delamaro et al. 2007].
Um caso de teste e´ um par formado por um ou mais valores fornecidos como
entrada ao programa mais o resultado esperado do programa para essa entrada.
Um crite´rio de teste define quais propriedades ou requisitos precisam ser testados
para avaliar a qualidade dos testes [Zhu et al. 1997]. A selec¸a˜o dos casos de teste
e´ realizada com base nos crite´rios de teste, os quais sa˜o definidos com base nas
te´cnicas de teste: estrutural, funcional e baseada em erros. Na te´cnica funcional,
o software e´ considerado uma caixa preta, o conjunto de teste e´ constru´ıdo com
base na especificac¸a˜o do software. Para o teste estrutural sa˜o testadas as estruturas
internas do software, o conjunto de teste e´ constru´ıdo com base na implementac¸a˜o do
software. Na te´cnica de teste baseada em erros, os defeitos mais comuns cometidos
no processo de desenvolvimento sa˜o utilizados para selec¸a˜o do conjunto de casos de
teste.
Com base nessas caracter´ısticas, no experimento descrito neste trabalho, o
crite´rio de teste funcional foi selecionado para gerac¸a˜o dos casos de teste, pois na˜o
exige conhecimento sobre o co´digo a ser testado e nesse caso, como trata-se de
programas equivalentes, acredita-se que seja a melhor escolha.
4. Descric¸a˜o do Estudo
Nesta sec¸a˜o e´ descrita a conduc¸a˜o do experimento, seguindo o processo definido por
Wohlin et al. [2000] .
104
4.1. Planejamento
Definic¸a˜o:
Investigar o reu´so de conjuntos de casos de teste como instrumento alternativo no
ensino de programac¸a˜o, verificando se com esse me´todo ha´ aumento da qualidade
dos programas implementados por alunos de cursos introduto´rios de programac¸a˜o.
Contexto:
Avaliac¸a˜o de programas no domı´nio de manipulac¸a˜o de vetores e manipulac¸a˜o de
matrizes, implementados em C por alunos de graduac¸a˜o dos cursos de computac¸a˜o
do ICMC. Definic¸a˜o de um conjunto de programas de refereˆncia do domı´nio de
manipulac¸a˜o de vetores e manipulac¸a˜o de matrizes a serem implementados e testados
por uma aluna de Po´s-graduac¸a˜o que gerara´ os conjuntos de casos de teste a serem
reutilizados a partir dos programas de refereˆncia. O experimento sera´ realizado
considerando dois grupos de alunos escolhidos aleatoriamente a serem avaliados e
dois programas do domı´nio de manipulac¸a˜o de vetores e manipulac¸a˜o de matrizes
P1 e P2 e conjuntos de casos de teste adequados aos programas de refereˆncia T1 e
T2 desses domı´nios para o crite´rio funcional. Numa aula pra´tica, metade dos alunos
da turma recebera´ do professor somente a especificac¸a˜o do problema e a outra parte
recebera´ ale´m da especificac¸a˜o do problema os conjuntos de casos de teste T1 e T2
apo´s implementac¸a˜o dos programas.
Hipo´teses:
Deseja-se avaliar as seguintes hipo´teses:
• Hipo´tese Nula H0 : Os alunos que possuem os conjuntos de casos de teste T1
e T2 produzira˜o programas com qualidade igual ou inferior aos alunos que
receberam apenas as especificac¸o˜es dos programas.
• Hipo´tese Alternativa H1 : Os alunos que possuem os conjuntos de casos de
teste T1 e T2 produzira˜o programas com melhor qualidade do que os alunos
que receberam apenas as especificac¸o˜es dos programas.
Varia´veis Independentes:
Especificac¸o˜es dos programas, programas de refereˆncia, conjuntos de casos de teste,
sexo dos alunos, provenieˆncia dos alunos (escola pu´blica ou privada) e experieˆncia
dos alunos (sim ou na˜o).
Varia´veis Dependentes:
Programas implementados pelos alunos e relato´rio dos questiona´rios.
Participantes:
60 alunos da disciplina de Introduc¸a˜o a` Cieˆncia da Computac¸a˜o I (ICC-1) dos cur-
sos de Bacharelado em Cieˆncia da Computac¸a˜o e Bacharelado em Informa´tica do
ICMC/USP. Foram 44 alunos do curso de Bacharelado em Cieˆncia da Computac¸a˜o
(alunos da mesma turma, mas como o experimento foi realizado em dias diferentes
e usando escolhas aleato´rias para os grupos, para ana´lise dos dados considerou-se
duas turmas com base nos dias de aplicac¸a˜o de cada estudo, obtendo-se assim as
105
turmas I e II) e 16 alunos do curso de Bacharelado em Informa´tica (turma III),
os quais desenvolveram verso˜es dos programas para serem avaliadas. Uma aluna
de po´s-graduac¸a˜o gerou os conjuntos de casos de teste adequados a um grupo de
programas de refereˆncia.
Descric¸a˜o do experimento:
Sobre os conhecimentos dos domı´nios escolhidos para os programas, considerou-se
que o conteu´do ministrado durante a disciplina era suficiente para os alunos. Na˜o
foi fornecido treinamento sobre teste de software. Durante a parte pra´tica, os alunos
de cada uma das 3 turmas foram separados em dois grupos de forma aleato´ria,
nesse caso, obedecendo a ordem alfabe´tica do dia´rio de classe. Todos os alunos
da turma responderam a um questiona´rio para o fornecimento de informac¸o˜es so-
bre sexo, provenieˆncia e experieˆncia que foram utilizadas nas ana´lises. Em seguida
um dos grupos recebeu apenas a especificac¸a˜o do programa e o outro recebeu ale´m
da especificac¸a˜o, os conjuntos de casos de teste. Cada aluno ficou responsa´vel por
implementar os programas dos domı´nios escolhidos e quando havia recebido os con-
juntos de casos de teste, testar os programas. Essa atividade foi realizada em hora´rio
de aula pra´tica e os alunos gastaram os seguintes tempos para implementac¸a˜o dos
programas: turma I - 1 hora; turma II - 2 horas e turma III - 2 horas. Nessa fase do
experimento na˜o foi admitida comunicac¸a˜o entre os alunos e nem consulta a outros
materiais.
Antes dessa atividade, uma aluna de Po´s-graduac¸a˜o envolvida no estudo im-
plementou, a partir das especificac¸o˜es dispon´ıveis em [Ascencio & Campos 2007] ,
os programas de refereˆncia e gerou os conjuntos de casos de teste a serem reuti-
lizados pelos alunos. Na segunda parte do experimento, as implementac¸o˜es e os
questiona´rios respondidos pelos alunos foram analisados. Cada programa foi com-
pilado e executado, usando os conjuntos de casos de teste previamente constru´ıdos
para atribuic¸a˜o de nota e avaliac¸a˜o quanto a` corretude. A avaliac¸a˜o dos programas
foi estabelecida segundo uma pontuac¸a˜o variando de 0 a 10 para cada programa.
Para avaliar as hipo´teses levantadas, foram realizados testes estat´ısticos de Kruskal-
Wallis. Os resultados obtidos podem ser observados Sec¸a˜o 4.2.
Validade:
Os aspectos de validade do experimento sa˜o divididos em validade interna e externa.
A validade interna busca identificar quais aspectos podem influenciar a relac¸a˜o entre
a causa e o efeito durante a realizac¸a˜o do experimento. As ameac¸as a validade interna
identificadas foram:
• Implementac¸o˜es ideˆnticas pelos alunos de graduac¸a˜o: Foram tomados alguns
cuidados durante a execuc¸a˜o do experimento para que os alunos na˜o se co-
municassem enquanto implementavam os programas. Ale´m disso, os co´digos
foram analisados individualmente e na˜o foram identificadas evideˆncias de
pla´gio.
• Simplicidade dos programas testados: Pode-se supor que devido a` simplici-
dade dos programas escolhidos, qualquer conjunto de casos de testes seria
suficientepara alcanc¸ar um n´ıvel de corretude satisfato´rio para os progra-
mas. Na˜o foi encontrado tratamento para essa ameac¸a, ja´ que o n´ıvel dos
106
alunos na˜o permitiam programas muito complexos e o tempo dispon´ıvel para
implementac¸a˜o tambe´m era reduzido.
A validade externa do experimento refere-se a` capacidade de generalizac¸a˜o
dos resultados obtidos. Como os programas estudados foram espec´ıficos do domı´nio
de manipulac¸a˜o de vetores e de matrizes, os resultados obtidos na˜o podem ser apli-
cados a outros domı´nios de programas.
4.2. Resultados
Os dados analisados foram coletados a partir dos programas escritos pelos alunos e
dos questiona´rios que eles responderam quando da aplicac¸a˜o do experimento. Na
Tabela 1 esta˜o apresentadas na primeira coluna as turmas em que o experimento foi
aplicado e nas segunda e terceira colunas, o domı´nio e a quantidade de programas
implementados. Na primeira turma foram apresentadas aos alunos as duas especifi-
cac¸o˜es, contudo, devido ao tempo reduzido que estes possu´ıam para a implementac¸a˜o
dos programas (1 hora), apenas 42, 86% dos alunos conclu´ıram os dois programas
em tempo ha´bil. Em decorreˆncia disso, a segunda implementac¸a˜o foi desconsiderada
nas ana´lises. Nas turmas II e III as duas especificac¸o˜es foram implementadas pelos
alunos. Inicialmente os dados foram separados conforme cada turma para ana´lise,
pore´m, o teste de Kruskal-Wallis forneceu evideˆncias de que na˜o havia diferenc¸as
significativas entre as turmas analisadas. Assim, as ana´lises foram realizadas sem
preocupac¸a˜o com diferenc¸as entre turmas.
Turma Domı´nio Quant. Programas
I manipulac¸a˜o de vetores 28
II manipulac¸a˜o de vetores e matrizes 16
III manipulac¸a˜o de vetores e matrizes 16
Tabela 1. Populac¸a˜o do Experimento
A Tabela 2 apresenta as varia´veis obtidas a partir do questiona´rio, as quais
tambe´m foram consideradas na ana´lise dos dados. Considerando que cada turma
foi dividida em dois grupos, a primeira coluna indica o par turma e grupo. O
grupo 1 compreende os alunos que reusaram os conjuntos de casos de teste e o
grupo 0 os alunos que na˜o reusaram os conjuntos de casos de teste. A segunda
coluna apresenta categoria e quantidade de pessoas do sexo correspondente. Nesse
caso, as categorias representam as duas opc¸o˜es de sexo para cada aluno (categoria 1
para sexo masculino e categoria 0 para sexo feminino). A terceira coluna apresenta
a categoria e a quantidade de pessoas para procedeˆncia de 2o grau. Categoria 1
significa procedeˆncia de escola pu´blica e categoria 0 significa procedeˆncia de escola
privada. A quarta coluna especifica a categoria e a quantidade de pessoas com
base na experieˆncia. Considera-se categoria 1 para aluno que possui experieˆncia em
programac¸a˜o e categoria 0 para o aluno que na˜o possui experieˆncia (esta´ estudando
C pela primeira vez na disciplina). Na Sec¸a˜o 5 esses resultados sa˜o analisados
estatisticamente e discutidos.
5. Discusso˜es
Para analisar estatisticamente se os diferentes conjuntos de casos de teste gerados
para os programas de refereˆncia quando reusados em programas equivalentes con-
tribuem para o aumento na qualidade dos programas decidiu-se realizar ana´lises
107
Turma/Grupo Categoria/Sexo Categoria/2o grau Categoria/Experieˆncia
I/Grupo 0 1/14 - 0/0 1/4 - 0/10 1/6 - 0/8
I/Grupo 1 1/13 - 0/1 1/3 - 0/11 1/7 - 0/7
II/Grupo 0 1/8 - 0/0 1/1 - 0/7 1/3 - 0/5
II/Grupo 1 1/7 - 0/1 1/1 - 0/7 1/4 - 0/4
III/Grupo 0 1/6 - 0/2 1/1 - 0/7 1/2 - 0/6
III/Grupo 1 1/7 - 0/1 1/6 - 0/2 1/4 - 0/4
Tabela 2. Informac¸o˜es Extra´ıdas dos Questiona´rios
usando o teste de Kruskal-Wallis entre os grupos da amostra e determinar se existia
diferenc¸a significativa entre os mesmos. O teste de Kruskal-Wallis permite obter
evideˆncias sobre os grupos considerados no que relaciona-se a homogeneidade dos
mesmos. Este teste foi aplicado para verificar as hipo´teses formuladas na Sec¸a˜o 4.1.
Assumiu-se como n´ıvel de confianc¸a 95% (portanto, rejeita-se a hipo´tese H0 para p-
values < 0, 05). Nos estudos realizados va´rias permutac¸o˜es foram feitas considerando
as varia´veis estudadas a fim de obter evideˆncias sobre os resultados do estudo e o
grau de adequac¸a˜o de cada varia´vel no intervalo de confianc¸a considerado.
As primeiras ana´lises tiveram como objetivo diagnosticar diferenc¸as entre as
turmas estudadas. Foi aplicado o teste de Kruskal-Wallis considerando as turmas.
No primeiro teste as turmas I, II e III foram consideradas para o grupo 0. Esse teste
forneceu evideˆncias de que na˜o havia distinc¸a˜o entre as turmas considerando o grupo
dos alunos que na˜o reusaram conjuntos de teste. Para o segundo teste foi considerado
o grupo 1 para as turmas I, II e III. Nesse caso, o teste tambe´m forneceu evideˆncias
de que na˜o havia distinc¸a˜o entre as turmas para o grupo que reusou conjuntos de
teste. Apo´s essas duas ana´lises os dados foram agrupados priorizando os grupos
(grupo 1 compreende todos os alunos que reusaram os conjuntos de casos de teste e
o grupo 0 os alunos que na˜o reusaram os conjuntos de casos de teste).
A Tabela 3 apresenta estat´ısticas dos testes realizados para comparac¸o˜es entre
os grupos 0 e 1. No primeiro teste foram considerados os dois grupos compostos
por alunos das treˆs turmas. Com base nessa ana´lise, observa-se p-value < 0.05,
significando que ha´ diferenc¸a entre os grupos comparados. Nesse caso, como os
grupos representam alunos que reusaram e alunos que na˜o reusaram os conjuntos
de casos de teste, conclui-se que a informac¸a˜o extra (os conjuntos de casos de teste
reusados) contribuiu para distinguir os grupos analisados.
Test Descric¸a˜o Kruskal-Wallis chi-squared df p-value
1 Grupo 0 das turmas I, II e III e grupo
1 das turmas I, II e III
6.5310 1 0.0106
2 Grupo 0 das turmas I e II e grupo 1
das turmas I e II
5.6268 1 0.0177
3 Grupo 0 das turmas I e II e grupo 1
da turma III
7.2585 1 0.0070
Tabela 3. Resultados das Ana´lises
Para o teste 2, tambe´m apresentado na Tabela 3, considerou-se apenas turmas
do curso de Bacharelado em Cieˆncia da Computac¸a˜o separadas entre os dois grupos.
Comparou-se o grupo 0 das turmas 1 e 2 e o grupo 1 das turmas 1 e 2. Observou-se
com o teste p-value < 0.05, indicando que mesmo considerando apenas alunos de um
so´ curso os conjuntos de casos de teste reusados contribuem para a distinc¸a˜o entre
108
os grupos. O u´ltimo teste, o teste 3, forneceu evideˆncias de que a diferenc¸a entre os
grupos perdurou, mesmo considerando os diferentes cursos e grupos, o grupo 0 das
turmas I e II e o grupo 1 da turma III. Ficando evidente nesses treˆs testes que a
informac¸a˜o extra que difere os grupos e´ a responsa´vel pela diferenc¸a observada.
Apo´s as ana´lises dos testes com base nos grupos obteve-se p-values < 0.05,
possibilitando rejeitar a hipo´tese nula e concluir a existeˆncia de diferenc¸as significa-
tivas entre os grupos. Assim, ha´ evideˆncias de que o reu´so de conjuntos de casos de
teste funcional gerados com base em programas de refereˆncia pode contribuir com
o aumento da qualidade de programas equivalentes implementados por alunos de
disciplinas introduto´rias de programac¸a˜o. Foram realizadas outras ana´lises com as
varia´veis sexo, procedeˆncia de segundo grau e experieˆncia, mas na˜o foram encon-
trados ind´ıcios de que essas varia´veis contribu´ıam com o teste de hipo´teses para a
amostra considerada.
6. Concluso˜es
Este artigo apresenta a proposta de reuso de conjuntos de casos de teste como aux´ılio
ao ensino de disciplinas introduto´rias de programac¸a˜o visando o aumento na quali-
dade dos programas gerados pelos alunos. Pore´m, na˜o e´ esperado que todo aspecto
do programa do aluno seja testado, mas sim que os casos de teste sejam capazes de
detectar erros t´ıpicos cometidos por alunos que esta˜o iniciando na programac¸a˜o, e
assim possa contribuir para o seuaprendizado.
O desenvolvimento da proposta fundamenta-se em uma metodologia baseada
em experimentac¸a˜o segundo Wholin [2001] . O estudo experimental conduzido teve
como objetivo validar essa proposta. O teste de Kruskal-Wallis forneceu evideˆncias
de que conjuntos de casos de teste funcional reusados podem auxiliar o aluno na
busca pelo aumento da qualidade de programas desenvolvidos. Espera-se que o
aluno habitue-se a testar os programas a` medida forem sendo desenvolvidos e como
consequeˆncia atribuam um grau de importaˆncia maior a atividade de teste.
Existem limitac¸o˜es a essa sistema´tica, pois casos de teste gerados a partir
dos programas de refereˆncia sera˜o reusados pelos alunos em verso˜es alternativas dos
programas de refereˆncia, de forma que o conjunto de teste reusado na˜o foi elaborado
para o programa que esta´ sendo testado (programa do aluno). Assim, na˜o se espera
que todo aspecto do programa do aluno seja testado, mas sim que os casos de teste
sejam capazes de elicitar erros t´ıpicos modelados pelos casos de teste funcionais.
Os resultados deste estudo foram baseados na amostra considerada. Como
trabalhos futuros pretende-se realizar o mesmo experimento usando outros domı´nios
e per´ıodos dos cursos e assim obter resultados mais gene´ricos em relac¸a˜o a`s hipo´teses
estudadas. Outros estudos podem ser desenvolvidos considerando-se covaria´veis (in-
formac¸o˜es extra) que possivelmente explicariam as relac¸o˜es entre os resultados dos
testes estat´ısticos. Como extensa˜o a esse trabalho, um reposito´rio pode ser utilizado
pelo professor, para armazenar os programas e conjuntos de teste a` medida que forem
sendo gerados, para serem reutilizados e contribuir para melhoria da qualidade do
material dida´tico.
109
Refereˆncias
Ascencio, A. F. G. and Campos, E. A. V. (2007). Fundamentos da Programac¸a˜o de
Computadores. Prentice Hall, 2th edition.
Campanha, D. N., Souza, S. R. S., Lemos, O. A., Barbosa, E. F., and Maldonado,
J. C. (2009). Reutilizac¸a˜o de conjuntos de teste: Um estudo no domı´nio de
algoritmos de ordenac¸a˜o. pages 114–123.
Delamaro, M. E., Maldonado, J. C., and Jino, M. (2007). Introduc¸a˜o ao Teste de
Software, volume 394 of Campus. Elsevier.
Dijkstra, E. W. (1972). Chapter i: Notes on structured programming. pages 1–82.
Hoffman, D., Strooper, P., and Walsh, P. (1996). Teaching and testing. In CSEE
’96: Proceedings of the 9th Conference on Software Engineering Education, page
248, Washington, DC, USA. IEEE Computer Society.
Jin, L. (2009). Automated functional testing of search engine. pages 97–100.
Liu, Z. and Yang, G. (2005). An automate test case generation approach: Using
match technique. Computer and Information Technology, International Confer-
ence on, 0:922–926.
Myers, G. J., Sandler, C., Badgett, T., and Thomas, T. M. (2004). The Art of
Software Testing. John Wiley & Sons, Inc., Hoboken, New Jersey.
Souza, D. M. and Barbosa, E. F. (2009). Progtest: Um ambiente para submissa˜o
e avaliac¸a˜o automa´tica de trabalhos de programac¸a˜o baseado em atividades de
teste.
Wang, Y., King, G., Court, I., Ross, M., and Staples, G. (1997). On testable object-
oriented programming. SIGSOFT Softw. Eng. Notes, 22(4):84–90.
Wang, Y., Patel, D., King, G., Court, I., Staples, G., Ross, M., and Fayad, M. (2000).
On built-in test reuse in object-oriented framework design. ACM Comput. Surv.,
page 7.
Weyuker, E. J. (1986). Axiomatizing software test data adequacy. IEEE Transac-
tions on Software Engineering, 12(12):1128–1138.
Wohlin, C. and Ho¨st, M. (2001). Special section: Controlled experiments in software
engineering. Information & Software Technology, 43(15):921–924.
Wohlin, C., Runeson, P., Ho¨st, M., Ohlsson, M. C., Regnell, B., and Wessle´n, A.
(2000). Experimentation in software engineering: an introduction. Kluwer Aca-
demic Publishers, Norwell, MA, USA.
Wu, T., Wan, Y., Xi, Y., and Chen, C. (2009). Study on the automatic test frame-
work based on three-tier data driven mechanism. pages 996–1001.
Yao, Y. and Wang, Y. (2005). A framework for testing distributed software compo-
nents. In Electrical and Computer Engineering, 2005. Canadian Conference on,
pages 1566–1569.
Zhu, H., Hall, P. A. V., and May, J. H. R. (1997). Software unit test coverage and
adequacy. ACM Comput. Surv., 29(4):366–427.
110
Evaluating a Tool for Bug-report Analysis and Search
Yguarata˜ Cerqueira Cavalcanti1,3, Paulo Anselmo da Silveira Mota1,3,
Ivan do Carmo Machado2,4, Eduardo Santana de Almeida2,3
Silvio Romero de Lemos Meira1,3
1Center for Informatics – Federal University of Pernambuco (UFPE)
2Computer Science Department – Federal University of Bahia (UFBA)
3Reuse in Software Engineering (RiSE)
{ycc,pamsn,srlm}@cin.ufpe.br, {ivan,esa}@dcc.ufba.br
Abstract. Bug report tracking systems have been used to facilitate the mainte-
nance and evolution of software. However, duplicate entries of bug reports in
such systems can considerably impact productivity within software project. This
reduction in productivity occurs because duplicate entries demand more time
for search and analysis of bug reports. In this context, this paper presents the
main problems caused by bug report duplication problem. In addition, a tool for
bug reports search and analysis (BAST) is proposed to deal with the duplication
avoidance, as well as, it also presents a case study to evaluate the tool. For the
evaluation, we compared BAST against a baseline tool in a private company for
software testing. The results showed that BAST worked better than the other
one, both to reduce the time of analysis, as well as, to reduce the number of
duplicates submitted.
1. Introduction
To improve software maintenance and evolution organizations use specific systems to
manage, track and store change requests within software projects. These systems are gen-
erally called bug report tracking systems, bug repositories, or just bug trackers [13, 18]. A
bug report is defined as a software artifact that describes some defect or enhancement that
is submitted to a bug tracker by developers, users, testers, and other possible stakeholders.
Such systems are beneficial as they allow software changes to be identified and reported
quickly [2]. Furthermore the bug report historical databases can be a useful source of
documentation for the project.
Typically, each bug report contains information, such as a bug identifier, summary
and detailed description, software version and component in which the bug appeared, de-
scribed dependencies with other bug reports (i.e. duplicate bug reports) and the assigned
developer. During the life-time of a bug report, continued updates on the bug status,
description and additional comments can be added to help resolve the bug.
Although bug trackers bring many benefits to software development, some chal-
lenges may appear as a consequence of its usage, such as: the dynamic assignment of bug
reports [1], the quality of bug report descriptions [5], and the detection of duplicate bug
reports [19]. Bug trackers also present oppurtunities to improve software development,
such as using the bug tracker historical database to: analysis of the impact of change and
effort estimation [20] and software evolution and traceability [14].
111
This work is focussed on the problem of bug report duplication problem. This
problem is characterized by the submission of two or more bug reports that describe the
same change request. The main consequence of bug report duplication problem is the
time-cost associated with managing these redundant bug reports. For example, the staff
responsible for the search and analysis of bug reports spend a considerable amount of
time dealing with bug reports that have already been submitted. Recent work [2, 7, 16]
has shown that between 10% to 30% of a bug report repository is composed of duplicate
bug reports. For moreinformation about the factors and consequences of duplicate bug
reports in software projects, we recommend to read our previous researches in [7, 8].
This paper presents a case study performed in order to evaluate a tool (BAST –
Bug Report Analysis and Search Tool) for search and analysis of bug reports. BAST was
built with the objective to reduce the amount of time needed to perform these tasks, and
to reduce the number of duplicate bug reports that are frequently submitted. Although the
related work presented different approaches for solving bug report duplication, very few
experimentation against existing tools, or inside real environments, has been done to test
them.
Moreover, the case studies present in related work does not considered about the
time spent with these tasks. As we mentioned previously, one of the consequences of the
presence of duplicate is the time spent during search and analysis, which we consider to
be the second dimension of the duplication problem. Thus, this case study is of great
contribution to the area.
The case study compared BAST against a baseline tool used inside a Motorola
test center, located in Recife, Brazil. Both the amount of duplicates and time spent with
search and analysis were analyzed in the case study. The results showed that BAST had
better performance than the other one, thus reducing the time for search and analysis and
the amount of duplicates submitted.
The remaining of this paper is organized as follow: Section 2 presents the pro-
posed tool; Section 3 presents the case study performed inside Motorola test center; Sec-
tion 4 presents the related work; and, finally, Section 5 summarizes the paper and presents
some intended future work.
2. BAST: Bug Report Analysis and Search Tool
Bug Report Analysis and Search Tool (BAST) was developed to assist in the prevention
of duplicate bug reports, as well as, to reduce the time to perform search and analysis
of bug reports. Figure 1 shows a screenshot of BAST. The top of the figure contains a
search field. The middle display shows a list of search results containing bug reports. The
bottom of the figure displays details of the selected result from the middle screen.
In the search field, the user can specify some filters such as component name,
status of the bug report, author identification (email or name). Moreover, the head of the
search results list also allows the user to sort the results according to the various columns
showed.
In addition to the search, filtering and visualization features, BAST implements
Text Mining [10] techniques to prepare the bug reports prior to analysis and extraction
of relevant information. Among such techniques, we implemented stop words removal
112
Figure 1. BAST simple screenshot.
(words that are not relevant to the ranking) and algorithms of stemming [15] to reduce the
words to his radical. Furthermore, it uses regular expressions to extract relevant informa-
tion from texts of bug reports.
To carry out searches in BAST, the user must specify keywords to characterize the
information he/she seeks. The keyword based search was chosen as it is a natural way to
perform search and it is also be a very intuitive way of expressing information needs [3].
BAST also extracts relevant information from the bug report’s content using nat-
ural language techniques [10]. For example, the tool can extract related bug reports to
help identify duplicates, references to external links and names of other people involved
informally with the bug report. These information are retrieved from the comments that
people enter during the bug report life-time.
Finally, BAST was built to be easy adopted in different contexts. There are two
ways of adopting it in a software development project: (a) to integrate the tool directly into
the database of a bug tracker, or (b) to feed BAST with the files containing the bug reports
exported from a bug tracker. Currently, BAST can import bug reports from major bug
tracking tools such as Bugzilla, Mantis, Trac. Furthermore, BAST worked with company-
specific bug tracking tools such as those used by Motorola. For more information about
the tool, we recommend to read the work presented in [6].
3. Evaluating BAST: Case Study at Motorola
We performed a case study to evaluate BAST in a test center of the Motorola located in
Recife, Brazil. In this test center, the testers perform a systematic process to test software
that is developed by Motorola in various sites around the world. As the software develop-
ment is distributed, tests are also performed distributed in different test centers. Briefly,
113
the testers receive a formal document with the tests that must be performed and, when
errors are found, bug reports should be submitted. Next we describe the objectives of the
case study, the baseline tool which BAST was compared with, the research questions of
the study, the case study design, participants, and metrics. Then we provide the interpre-
tation of the results, and discuss about the confound factors and lessons learned from the
case study.
Case study objectives. The objective of this case study was to analyze the effi-
ciency of BAST for search and analysis of bug reports, with a focus on avoiding dupli-
cates, against a baseline tool. Thus, we want to: (i) examine whether BAST can prevent
more duplicate bug reports than the baseline tool, and (ii) consider whether BAST de-
creases the time spent with search and analysis of bug reports.
Baseline tool. Currently, Motorola uses an internal tool to manage bug reports,
as well as to search the existing ones. To performs searches in this tool, the submitters
need to manually create multiple filters to specify the desired criteria for searches. Some
of the negative points were raised by submitters on the current tool: the time and com-
plexity to build the search filters, and the bug reports visualization that did not facilitate
the identification of duplicates.
Research questions. We established the following research questions that we
would like to response with this case study: a) Is BAST more effective than baseline tool
to avoid duplicates? b) Can BAST reduce the time spent to search for similar bug reports?
Case study design. The case study had two treatments, and a specific participant
(the submitter) was responsible to execute both of them. The submitter was instructed on
how he should use the tools to search and analyze the bug reports. Thus, we divided the
assessment period in two stages: the first stage (21 days), the submitter should carry out
the search and analysis first using the baseline tool, and if he did not find a similar bug
report, he should use BAST to perform the search and analysis; in the second stage (11
days), this sequence was reversed.
We designed the study in this manner to reduce the factor of confusion regarding
the knowledge of already analyzed bug reports. For example, if we chose by conducting
the study so that the submitter should perform search and analysis for the same bug reports
in both tools, the analysis in the second tool would be compromised due to the submitter
knowledge about possible existing similar bug reports.
Submitter selection. In order to carry out the case study, a specific tester, called
bug report master, was selected to be the submitter who should use both tools in parallel
during the whole period. The bug report master is the person responsible for conducting
the test cycles. When a tester has problems or questions with regard to testing or bug
report, the bug report master should be contacted to resolve the problems. Thus, this
person, besides being responsible for the search and analysis of its own bug reports, is
also responsible for doing that for people who contacted him. For example, if a tester has
doubts with respect the uniqueness of a bug report, but cannot find a similar bug report in
therepository, the bug report master should be contacted to make advanced search and
analysis. For simplicity, from now on we will call the bug report master just as submitter.
Evaluation Metrics. To analyze which tool was more efficient regarding to the
objectives defined, the following metrics were established:
114
Type of bug reports analyzed. With this metric we want to characterize the types
of bug reports that were submitted during the course of the case study.
Number of duplicate bug reports avoided. By that metric we want to know how
many bug reports that would be duplicated have been prevented with the use of our tool,
and how many have been avoided with the use of the baseline tool.
Time spent to analyze similar bug reports. This metric is concerned with the time,
in minutes, spent by submitters to search and analyze similar bug reports. For this metric,
we computed only the time for searches that found similar bug reports.
In order to gather these metrics, the submitter was responsible for recording the
types of bug reports that were analyzed, the time spent on each search and analysis, and
specifying in which tool a similar bug report was found. If a bug report was not submitted
and there were no similar bug reports for it, the submitter should specify the reason for
not submitting. Next we describe and interpret the results of the case study.
3.1. Result Analysis
During the case study, it was examined 144 bug reports by the bug report master. This
amount lead to 407 searches also performed by the bug report master, just in our tool
during the study period. However, it was not possible to have access to the number of
searches carried out in the Motorola’s tool due to issues of confidentiality. Next we de-
scribe the results considering the first and second stages of the case study execution, then
we analyze the whole period.
3.1.1. Analysis of the First Stage
During the first stage, it was analyzed 42 bug reports. It was the stage with less bug
reports to perform search and analysis. The main reason for that was due to the fact that
it was the beginning of the project. Figure 2 shows a graph with the classification of these
bug reports after the analysis performed by the submitter.
Figure 2. Respository status in first stage.
Number of duplicate bug reports avoided. Figure 3(a) shows the percentage of
duplicate bug reports that were avoided according to the tool used. In this stage, the bug
reports were analyzed using the baseline tool, and if it was not found similar bug reports, a
new analysis should be performed using BAST. Thus, the analysis made with the baseline
prevented the submission of 58% of duplicates, while BAST prevented 35%. In other
words, the baseline tool was not able to avoid 35% of the total duplicates, which were
115
avoided using BAST. In addition, 7% were avoided because the information provided by
developers. Therefore, during the first stage, the BAST had lower performance than the
baseline tool.
Average time spent on analysis of bug reports. The graph in Figure 3(b) shows
the average time spent with search and analysis in each tool. As it can be seen, the time to
do analysis was considerably reduced with the use of BAST. The average time for search
and analysis with BAST was 6.5 minutes, while it was 10.71 minutes with the baseline
tool. Thus, BAST demanded 39% less time to perform these tasks.
(a) Duplicates avoided in the first step. (b) Time spent in the first step.
Figure 3. Time spent and duplicates avoided in the first stage.
3.1.2. Analysis of the Second Stage
During the second stage, it was analyzed 99 bug reports. The amount of analysis of bug
reports increased considerably in this stage. One of the reasons for that was the increasing
of the project also, i.e. number of features implemented and test cases. Figure 4 shows a
graph with the classification of bug reports after the analysis conducted by the submitter
during this stage. According to the chart, 44% of bug reports were duplicates that had
been avoided.
Figure 4. Respository status in second stage.
Number of duplicate bug reports avoided. Figure 5(a) shows the percentage of
duplicate bug reports that were avoided according to the tool used. In this second stage,
the bug reports were analyzed first using BAST, and if it was not found similar bug reports,
a new analysis should be performed using the baseline tool. At the end of this stage, the
analysis made with the BAST avoided the submission of 89% of duplicates, while the
116
other tool avoided 7% that BAST could not avoid. In addition, 7% were avoided due to
the fact that the submitter had prior knowledge of similar bug reports.
Average time spent on analysis of bug reports. According to the graph of Figure
5(b), the average time spent with search and analysis of bug reports with both tools did
not diverged so much. However, BAST had the best performance in the second stage in
regard to the time of analysis. That is, the submitter spent less time to analyze bug reports
using BAST.
(a) Duplicates avoided in the second step. (b) Time spent in the second step.
Figure 5. Time spent and duplicates avoided in the second step.
3.1.3. Analysis of the Whole Period
Types of bug reports analyzed. Figure 6 shows the types of bug reports that were ana-
lyzed in the study. As can be seen, 53 % was composed of duplicates, which would enter
in the repository if it would not avoided. Meanwhile, only 29 % of bug reports addressed
issues not yet submitted, and thus submitted to the repository. The other types of bug re-
ports, although they were not duplicate, have not been submitted to the repository because
they were invalid.
Figure 6. Respository status.
Number of duplicate bug reports avoided. As mentioned earlier, 53% of the
bug reports were not submitted because they were duplicates. Figure 7(a) shows that
69% of those bug reports were avoided by using our tool, while only 28% have been
avoided with the baseline tool. In addition, 3% of duplicates could only be avoided due to
information provided by developers, or because the submitter already know that the bug
report was duplicate. Thus, we can answer the first question positively, where BAST is
more effective than the baseline tool.
117
(a) Duplicates avoided. (b) Time spent on search and analysis.
Figure 7. Duplicates avoided and time spent for the whole period.
Average time spent on analysis of bug reports. Figure 7(b) shows that, in gen-
eral, the average time spent to perform analysis of bug reports is reduced when using
BAST. On average, BAST saves half the time it would be spent if the submitter was using
the baseline tool. Therefore, it can be considered achieved the goal of reducing the time
spent on analysis of bug reports. Thus, we can answer the second question positively,
where BAST can reduce the time needed to search and analyze bug reports.
3.2. Confounding Factors
The results mentioned earlier showed that BAST can prevent more duplicates than the
baseline tool, while also helps reducing the time spent on analysis of bug reports. How-
ever, a few factors of confusion need to be highlighted. The first factor refers to how many
people were used to conduct the case study. As mentioned, only one submitter carried out
the study. It is a factor of confusion because we cannot generalize the results to other
submitters, with different experiences and background.
A second factor of confusion relates to the way that the tools were evaluated. The
way the case study was designed, the submitter could only perform the search and analysis
for the same bug report using both tools if no duplicates were found using the first tool of
the current stage. This is a factor of confusion because we cannot compute the average
time for the same search and analysis on different tools. In addition, if a duplicate was
foundusing the first tool, it was not possible to verify if the same duplicate would also be
found using the second tool.
We must also consider that the time to perform a second analysis can be influenced
by the first analysis. For example, if the submitter spends a certain time to do an analysis
in the first tool, but does not find any duplicate, it is likely that he will spend more time
using the second tool to find a duplicate, if able. In this regard, we must also consider the
factor of accommodation, in which the submitter tends to spend more time using the tool
that he feels more comfortable to use.
4. Related Work
The first related work was from John Anvik [2]. He analyzed potential problems raised by
bug repositories from Eclipse and Firefox projects, such as dynamic assignment of bug
reports and bug report duplication. Although our work focused only in the duplication
problem, we believe that it is a complement of Anvik’s work, since we expanded the
number of projects and variables analyzed in order to understand the problem.
118
Hiew’s work [11] presented an approach to detect duplicate bug reports using
clustering techniques. Runeson’s work [16] addressed the bug report duplication problem
using Natural Language Processing (NLP) [10]. While Wang et al. [19] proposed an
approach to detect duplicate bug reports using NLP and execution information. The exe-
cution information consists of data about software execution when an error occurs, such
as method calls or variable state.
Another work to detect duplicate bug reports was performed by Jalbert and
Weimer [12]. They proposed a system to automatically classify duplicate bug reports
as they arrive. As a differential from the others work, the system used surface features
and textual semantics in conjunction with clustering techniques.
Bettenburg et al. [4, 5] tried a different approach. Instead of avoiding duplicates,
they propose to merge the duplicate bug reports to assist developers with additional infor-
mation (such as tracebacks, or even descriptions from different points of view).
The work of Sandusky et al. [17] differs substantially from the previous ones. It
proposed a method to identify and visualize bug report networks. With such networks, it
was possible to analyze relationships and dependencies among bug reports.
5. Conclusion
In this work we described the problem of bug report duplication, which consists in sub-
mitting two or more bug reports concerning the same issue for one software project. Such
problem is critical because, due to the presence of duplicates, it demands extra time to
perform the search and analysis of bug reports during the submission phase.
Furthermore, we described a tool (BAST) developed to optimize the discovery of
duplicate bug reporting and to decrease bug report analysis time. BAST was evaluated in
a case study within a testing center of Motorola, and the results were very satisfactory. For
example, the analysis performed with our tool reduced by half the time normally spent
using the baseline tool (from Motorola) for search and analysis of bug reports. In addition,
our tool prevented more than 60% of duplicate bug reports submission, if compared with
the baseline tool.
For future work we are planning an experiment with 20 submitters to evaluate the
gains of using BAST against well know tools (such as Bugzilla, Mantis and Trac) and
inside different contexts. However, the design of the case study must be reviewed before
running the experiment. That is because the current design turn difficult to measure which
tool demands less time to perform search and analysis of bug reports. It is mainly because
of the confounding factor of accommodation, as mentioned before. Thus, a better design
to the case study would be to execute the search and analysis using only one tool in the
first moment, and using only the other tool in the second moment.
Finally, the tool will also be evolved to move from the prototype stage to a more
mature stage, and visualization techniques are being incorporated into it [9] with the ob-
jective of improving the amount of time spent and duplicates avoided.
Acknowledgement. This work was partially supported by the National Institute of
Science and Technology for Software Engineering1, funded by CNPq and FACEPE, grants
573964/2008-4, APQ-1037-1.03/08 and RHAE-559839/2009-0.
1INES - http://www.ines.org.br
119
References
[1] Anvik, J. and Murphy, G. C. (2007). Determining implementation expertise from bug reports.
In Proc. of the 4th Inter. Work. on Mining Soft. Repositories (MSR’07). IEEE.
[2] Anvik, J., Hiew, L., and Murphy, G. C. (2005). Coping with an open bug repository. In Proc.
of the 2005 OOPSLA Work. on Eclipse Tech. eXchange, pages 35–39, New York, USA. ACM.
[3] Baeza-Yates, R. A. and Ribeiro-Neto, B. A. (1999). Modern Information Retrieval. ACM.
[4] Bettenburg, N., Premraj, R., Zimmermann, T., and Kim, S. (2008a). Duplicate bug reports
considered harmful? In Inter. Conf. on Soft. Maintenance (ICSM’08), pages 337–345. IEEE.
[5] Bettenburg, N., Premraj, R., Zimmermann, T., and Kim, S. (2008b). Extracting structural
information from bug reports. In Proc. of the 2008 Inter. Work. on Mining Soft. Repositories
(MSR’08), pages 27–30. ACM.
[6] Cavalcanti, Y. C., da Cunha, C. E. A., de Almeida, E. S., and de Lemos Meira, S. R. (2009).
Bast - a tool for bug report analysis and search. In XXIII Brazilian Symp. for Soft. Eng., tools
section (SBES’2009), Fortaleza, Brazil.
[7] Cavalcanti, Y. C., de Almeida, E. S., da Cunha, C. E. A., Lucre´dio, D., and de Lemos Meira,
S. R. (2010a). An initial study on the bug report duplication problem. In Proc. of the 14th Euro.
Conf. on Soft. Maint. and Reeng. (CSMR’2010), pages 273–276, Madrid, Spain. IEEE.
[8] Cavalcanti, Y. C., da Silveira Mota, P. A., de Almeida, E. S., Lucre´dio, D., da Cunha, C. E. A.,
and de Lemos Meira, S. R. (2010b). One step more to understand the bug report duplication
problem. In XXIV Brazilian Symp. for Soft. Eng. (SBES’2010), Salvador, Brazil.
[9] da Cunha, C. E. A., Cavalcanti, Y. C., da Mota Silveira Neto, P. A., de Almeida, E. S., and
de Lemos Meira, S. R. (2010). A visual bug report analysis and search tool. In Proc. of the
22th Inter. Conf. on Soft. Eng. Know. Eng. (SEKE’2010), pages 742–747, San Franciso, USA.
[10] Feldman, R. and Sanger, J. (2007). The Text Mining Handbook: advanced approaches in
analyzing unstructured data. Cambridge University Press.
[11] Hiew, L. (2006). Assisted Detection of Duplicate Bug Reports. Master’s thesis, The Univer-
sity of British Columbia.
[12] Jalbert, N. and Weimer, W. (2008). Automated duplicate detection for bug tracking systems.
In The 38th Annual IEEE/IFIP International Conference on Dependable Systems and Networks
(DSN’08), pages 52–61. IEEE.
[13] Johnson, J. N. and Dubois, P. F. (2003). Issue tracking. Comp. in Sci. and Eng., 5(6), 71–77.
[14] Koponen, T. and Lintula, H. (2006). Are the changes induced by the defect reports in the
open source software maintenance? In H. R. Arabnia and H. Reza, editors, Proc. of the 2006
Inter. Conf. on Soft. Eng. Research (SERP’06), pages 429–435. CSREA Press.
[15] Porter, M. F. (1980). An algorithm for suffix stripping. Program, 3(14), 130–137.
[16] Runeson, P., Alexandersson, M., and Nyholm, O. (2007). Detection of duplicate defect
reports using natural language processing. In Proc. of the 29th Inter. Conf. on Soft. Eng.
(ICSE’07), pages 499–510. IEEE.
[17] Sandusky, R. J., Gasser, L., and Ripoche, G. (2004). Bug report networks: Varieties, strate-
gies, and impacts in a f/oss development community. In Proc. of the 1st Inter. Work. on Mining
Soft. Repositories (MSR’04), pages 80–84, University of Waterloo.
[18] Serrano, N. and Ciordia, I. (2005). Bugzilla, itracker, and other bug trackers. IEEE Software,
22(2), 11–13.
[19] Wang, X., Zhang, L., Xie, T., Anvik, J., and Sun,J. (2008). An approach to detecting
duplicate bug reports using natural language and execution information. In Proc. of the 30th
Inter. Conf. on Soft. Eng. (ICSE’08), pages 461–470. ACM.
[20] Weiss, C., Premraj, R., Zimmermann, T., and Zeller, A. (2007). How long will it take
to fix this bug? In Proceedings of the Fourth International Workshop on Mining Software
Repositories (MSR’07), pages 20–26. IEEE.
120
Boas Práticas para Apoiar o Gerenciamento de Tempo em 
Projetos DDS 
 
1Ana Carina M. Almeida, 1,2Ivaldir H. de F. Jr, 1Renata Souza, 1Hermano Perrelli 
 
1Universidade Federal de Pernambuco - UFPE 
Recife, PE, Brasil. 
 
2Softex Recife – Recife, PE, Brasil 
 
{acma2, ihfj, rmcrs, hermano}@cin.ufpe.br 
 
Abstract— Some researchers proof that the effort to develop software in a Distributed Software 
Development (DSD) environment is higher than in a centralized one. This paper identifies the 
main factors that could impact significantly the total effort planned; and suggests best practices 
to support the project leaders in the project time management area, regarding DSD projects. In 
other to active these results, this study was based on qualitative and quantitative methods, 
implemented in two phases. The first, based on survey, collected information from 15 DSD 
projects, and the second phase, based on interviews, captured the lessons learned from 11 
leaders of distributed projects. Both researches allowed the study of distributed development in 
its real context. 
 
Resumo— Algumas pesquisas comprovam que o esforço para desenvolver software em um 
ambiente de Desenvolvimento Distribuído de Software (DDS) é maior do que o esforço 
despendido no ambiente centralizado. Este artigo identifica os principais fatores que podem 
influenciar no aumento de esforço de um projeto de software com equipes geograficamente 
distribuídas; e propõe um conjunto de boas práticas a fim de melhor suportar os líderes no 
gerenciamento de tempo de projetos DDS. Para alcance desses resultados, esta pesquisa se 
baseou em pesquisas de natureza qualiquantitativa executada em duas fases. A primeira, 
baseada em survey, coletou informações de 15 projetos DDS, e a segunda fase, baseada em 
entrevistas, capturou os relatos de lições aprendidas de 11 líderes de projetos distribuídos. 
Ambas as pesquisas possibilitaram o estudo do desenvolvimento distribuído em seu contexto 
real. 
 
1. INTRODUÇÃO 
 
No contexto do mundo pós-moderno, observamos que muitas organizações se 
apresentam cada vez mais motivadas a aderir ao Desenvolvimento Distribuído de 
Software (DDS) [1]. Boa parte dessa motivação tem razões econômicas, ou seja, a busca 
de mão de obra especializada a um custo mais baixo, inclusive considerando a 
disponibilidade de pessoas qualificadas em várias regiões ou epicentros tecnológicos do 
mundo [1], [2]. Desta forma, é possível aproveitar o que cada região tem de melhor a 
oferecer, seja em termos de custo (recursos humanos), qualidade, agilidade, políticas de 
incentivo fiscais, capacitação e quantidade de pessoas disponíveis, entre outros 
benefícios [2]. O DDS, também conhecido como desenvolvimento multisite, diferencia-
se do desenvolvimento centralizado ou tradicional pela dispersão física, distância 
temporal, e diferença cultural entre times. Estas características trazem novos desafios 
para o processo e gerência de desenvolvimento de software, pois dificultam a 
comunicação entre equipes, coordenação e controle do projeto [1], [2], [3], [4], [17]. 
Herbsleb, nas pesquisas [5] e [6], comprova que o esforço para desenvolver um 
121
software em ambiente multisite é maior do que o esforço despendido no 
Desenvolvimento Centralizado de Software (DCS). 
Esta diferença adicional vem de aspectos não-técnicos [1], [2], [5], [6], [7], [8], [9], 
[10],[11],[12],[17] como, por exemplo, coesão das equipes, motivação, dependência 
entre sites (grupos), esforço adicional de comunicação decorrente da distância, 
transferência de conhecimento entre equipes, maior esforço de gerência de projeto e 
elaboração de documentação necessária para desenvolvimento do projeto, dentre outros 
aspectos. Pilatti et all [11] comenta que o esforço empreendido nos aspectos não-
técnicos é subestimado durante a fase de planejamento do tempo do projeto. 
Diante deste contexto, a principal contribuição deste trabalho está na identificação dos 
principais fatores que podem causar desvio de esforço através da pesquisa quantitativa; 
e sugestão de um conjunto de boas práticas a serem incorporadas no processo de 
gerenciamento de tempo através da pesquisa qualitativa. 
 
2. MOTIVAÇÃO E TRABALHOS RELACIONADOS 
 
É importante estar atento que falhas em planejamento de projeto de software foram 
registradas há mais de 15 anos, independente da forma escolhida para desenvolvimento 
do software: distribuída ou centralizada. De acordo com o relatório mais recente 
publicado pelo Standish Group, o Chaos Summary 2009 [13], foi constatado que o 
percentual de projetos de software que obtiveram sucesso decresceu quando comparado 
com os resultados dos últimos anos. No ano de 2009, 32% dos projetos obtiveram 
sucesso, ou seja, foram entregues no prazo, com o custo e escopo previstos; 44% dos 
projetos foram entregues, mas estouraram no prazo ou custo previstos; e 24% dos 
projetos falharam ou foram cancelados antes do prazo final da sua execução. Outro 
relatório, publicado pela empresa Construx em 2009, denominado Software 
Development's Classic Mistakes [14], constatou que o erro Overly Optimistic Schedules 
lidera a lista dos 10 erros clássicos que acontecem com grande frequência em projetos 
de desenvolvimento de software. Segundo a empresa que realizou a pesquisa, a causa 
raiz deste problema está na dificuldade de estimar um software. A partir dos resultados 
desses relatórios, percebemos que falhas em planejamento não ocorrem apenas em 
projetos DDS. Linda [16] aponta diversas causas de estouro em planejamento 
(estimativa) de projetos de software, independente da forma escolhida para 
desenvolvimento (distribuída ou centralizada). Apesar de constatarmos que o 
planejamento de tempo é um dos fatores críticos para o sucesso de um projeto de 
software, existe escassez de trabalhos na literatura que aborde este tema enfatizando 
soluções voltadas para planejamento de esforço. Isto pode ser explicado pela falta de 
maturidade da área de engenharia de software em DDS. Por exemplo, Siqueira [12] 
elaborou as recomendações a partir dos desafios encontrados pelos gerentes de projetos 
DDS, e soluções que foram possíveis de serem observadas empiricamente. Entretanto, 
ele não deixa claro quais são os fatores do ambiente DDS que eles tentam mitigar 
através das boas práticas. Portanto, não temos a convicção se o contexto DDS como um 
todo foi levado em consideração para elaboração das sugestões. O outro trabalho 
relacionado é da autora Anjun [18]. Esta pesquisa teve como principal propósito o 
levantamento de issues que impactam a gerência de projeto DDS, e propor sugestões de 
boas práticas. Este trabalho é interessante, pois fornece uma visão do todo, apesar de 
não enfatizar um processo ou área específica. 
 
122
 
3. METODOLOGIA DE PESQUISA E RESULTADO DO ESTUDO 
EMPÍRICO 
 
Esta pesquisa de caráter exploratório, objetiva fornecer uma visão global do fato ou 
fenômeno estudado [18]. Para tanto foram escolhidas as abordagens quantitativa e 
qualitativa [18], baseadas em survey e entrevistas, possibilitando o estudo do 
desenvolvimento distribuído em seu contexto real. Através da pesquisa quantitativa 
[18] visamos à caracterização dos projetos e identificação das possíveis causas da 
variação do esforço durante o desenvolvimento de um software de forma distribuída. Já 
a pesquisa qualitativa [18] apresenta uma maior flexibilidade no trato com o campo de 
pesquisa e possibilitao surgimento de dados e informações não esperados inicialmente 
objetivando coletar da experiência vivida em projetos DDS, as boas práticas para 
planejamento de tempo. A Figura 1 exibe as macro fases da metodologia utilizada para 
desenvolvimento deste trabalho. 
 
Figura 1. Etapas da metodologia de pesquisa. 
 
 
Etapa I - Identificação dos possíveis fatores que podem contribuir com o aumento de 
esforço em Projetos DDS 
 
Esta primeira etapa (figura 2) tem como objetivo identificar quais são os fatores do 
ambiente de desenvolvimento distribuído que podem contribuir para o aumento de 
esforço no desenvolvimento de um software em ambiente distribuído. Para 
levantamento desta informação, foi realizado primeiramente um estudo do referencial 
teórico sobre o assunto e posteriormente através da pesquisa quantitativa foi conduzida 
uma pesquisa de campo para verificação e refutação da teria estudada. 
 
Figura 2. Passo a passo da Fase I 
 
123
Após o passo “1. Estudo do referencial teórico”, foi iniciado “2. Projetar e construir o 
questionário”. O formato e sequência dos itens do questionário foram planejados para 
facilitar a análise e interpretação dos resultados. O tamanho do questionário também foi 
levado em consideração, a fim que o mesmo não se tornasse muito longo causando 
desinteresse do respondentes. Ao todo o questionário tem 17 perguntas. As questões são 
divididas em tópicos, buscando informações gerais sobre os projetos de 
desenvolvimento de software, tecnologia, forma de trabalho da equipe, comunicação 
entre sites, processo de planejamento de projeto, por fim, identificação dos fatores que 
impactam o esforço e sucesso de um projeto DDS. A grande maioria das questões é de 
caráter objetivo e alguns itens são descritivos, como pode ser visto no Apêndice A. Após 
elaboração do questionário realizou-se a “Aplicação do piloto do survey” com a 
finalidade de testar o questionário, possibilitando corrigir alguns erros, melhorar pontos 
e evitar falso resultado. O teste piloto foi aplicado com dois gerentes de projeto que 
trabalham com equipes distribuídas. Corrigindo os problemas encontrados nos testes, 
iniciou-se a “Identificação dos entrevistados”, que tem como objetivo a seleção de 
profissionais que atuam com liderança de projetos DDS, sejam eles, gerentes de projeto, 
líderes de equipe ou líderes técnicos. Definimos como população alvo líderes de 
projetos DDS no âmbito do território brasileiro. O critério utilizado para seleção da 
amostra se baseou no tempo de experiência do gerente de projeto (mínimo um ano) e 
tempo de execução do projeto (mínimo de 6 meses). O próximo passo foi a distribuição 
dos questionários através de emails e contatos por telefone, a fim de reforçar a 
importância da pesquisa. Neste sentido o questionário foi submetido a quinze líderes de 
projetos DDS no Brasil e ficou disponível on-line por um período de 15 dias no mês de 
fevereiro de 2009. Os resultados válidos foram coletados e traduzidos em gráficos 
analíticos para facilitar o entendimento e as inferências. Esses dados foram tratados 
quantitativamente através de análise de frequências com o objetivo de oferecer uma 
compreensão inicial sobre o problema apresentado. Os gráficos da pesquisa 
quantitativa estão disponíveis em www.dabanet.com.br/dds/graficos. 
 
Diante deste cenário, percebemos a importância de se gerir um projeto DDS e neste 
contexto de trabalho visualizamos vários desafios e oportunidades de negócio. O 
pesquisador Herbsleb [5], [6] observou que se gasta mais tempo do que o previsto para 
realizar uma atividade quando mais de um site está envolvido, pois é preciso que todos 
tenham o mesmo entendimento do escopo do projeto. Este alinhamento é alcançado 
através da troca de informação e negociações. Abaixo detalhamos os principais aspectos 
encontrados na literatura e validados em campo, que podem causar desvios no 
planejamento de tempo de um projeto em decorrência do desenvolvimento ser 
distribuído. Agrupamos os aspectos em três categorias da seguinte forma: 
 
 • Produto (ou Software) - Envolve os fatores relativos às características inerentes 
 ao software a ser desenvolvido, tal como arquitetura do produto. 
 
• Processo e Infra-estrutura para desenvolvimento - Envolvem métodos e 
ferramentas (infra- estrutura) que os integrantes das equipes utilizam para 
desenvolver o produto em ambiente multisite. 
 
 • Equipe - Envolve os papéis e responsabilidades dos integrantes das equipes dos 
 projetos (tarefas e limitações associadas). 
124
Além disso, as categorias foram dividas entre: teóricas e empíricas (Tabela 1 e 2), de 
acordo com a sua origem. Através dos questionários, foi possível detectar três novas 
categorias: “Integração de Código entre múltiplos sites”, ao “Nível de Experiência dos 
Líderes em DDS” e a utilização de um “Processo de Desenvolvimento Uniforme entre 
Sites”. 
 
Tabela 1. Descrição das categorias teóricas 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Tabela 2. Descrição das categorias empíricas 
 
 
 
 
 
 
 
 
 
 
 
Os aspectos mencionados nesta seção podem ser agravados caso a distância física entre 
os times seja maior, pois teremos uma grande diferença de fusos horários e pequenas 
sobreposição de horas de trabalho ocasionando atraso na comunicação da equipe e 
gerando mais tempo necessário para resolver as questões [7]. Descrevendo todos estes 
 
 
125
fatores, é possível entender o quanto é crítico considerar as características intrínsecas do 
ambiente DDS a fim de que possamos atingir um melhor planejamento de software. 
 
Etapa II - Identificação das boas práticas utilizadas na fase de gerenciamento de tempo 
de projetos DDS 
 
Esta segunda etapa, iniciada em Agosto de 2009, teve como objetivo a identificação de 
boas práticas e lições aprendidas dos líderes de projetos DDS referente à área de 
gerenciamento de tempo. Para levantamento desta informação foi escolhida a pesquisa 
qualitativa, pois apresenta uma maior flexibilidade no trato com o campo de pesquisa e 
possibilita o surgimento de dados e informações não esperados inicialmente objetivando 
coletar da experiência vivida em projetos DDS as boas práticas para planejamento de 
tempo. Para tanto, utilizou-se como instrumento de pesquisa um roteiro de entrevista 
semi-estruturada, com questões abertas (Apêndice B). O roteiro foi desenvolvido a 
partir da teoria estudada sobre gerenciamento de tempo de projeto, e também utilizando 
os fatores que podem aumentar o tempo de desenvolvimento em ambiente DDS, 
resultado da Fase I deste trabalho. Este roteiro engloba tópicos sobre planejamento e 
distribuição das atividades do projeto entre sites, forma de acompanhamento das tarefas 
à distância, coesão (suporte) e dependência entre sites, sugestões e boas práticas para 
diminuir o impacto da distância geográfica a partir das experiências vividas. Após a 
realização das entrevistas, as mesmas foram transcritas, e os dados foram categorizados 
e codificados utilizando o software Nvivo [15]. Este software facilitou a realização 
deste trabalho, pois permitiu a exportação do áudio das gravações para o mesmo e 
configuração da velocidade de reprodução, fato que otimizou a transcrição das 
entrevistas. Em janeiro de 2010, realizamos a Categorização ou Codificação dos dados. 
Nesta etapa, foram entrevistados 11 líderes de projetos DDS. Todos os Apêndices desta 
pesquisa estão disponíveis em www.dabanet.com.br/dds/apendices. 
 
Etapa III - Elaboração do conjunto de boas práticas 
 
Esta última fase foi realizada nos meses de janeiro e fevereiro de 2010, tinha como 
objetivo a elaboração do conjunto de boas práticas direcionadas à gerência de tempo de 
projetos DDS. Para tanto,foram utilizados os resultados das duas fases anteriores: 
fatores que podem contribuir com o aumento de esforço na execução de um projeto 
DDS, e também lições aprendidas e práticas utilizadas pelos líderes entrevistados. Foi 
realizada uma associação entre os fatores e as práticas exercidas pelos líderes, a fim de 
abordar de forma integral todos os fatores e agrupar as práticas por fator. Desta forma, 
as práticas foram construídas, contextualizando a situação que as mesmas podem ser 
aplicadas e em qual atividade da gerência de tempo. Estas práticas estão descritas na 
seção 4. 
 
4. PROPOSTA DE BOAS PRÁTICAS PARA GERENCIAMENTO DE 
TEMPO EM DDS 
 
O uso das boas práticas visa minimizar a influência dos fatores da dispersão geográfica 
no aumento de esforço de desenvolvimento de um software. As práticas estão 
relacionadas aos possíveis fatores encontrados nos estudos teórico e empírico que 
podem impactar no esforço de desenvolvimento através de múltiplos sites. Para 
126
desenvolver esta proposta, procuramos analisar cuidadosamente as lições aprendidas e 
propor boas práticas que fossem genéricas o suficiente para domínios distintos de 
projetos DDS. As boas práticas foram agrupadas de acordo com as atividades (em 
subseções) que compõem a gerência de tempo, a fim de orientar o Gestor. 
 
Definição da Atividade 
 
Este primeiro passo tem como objetivo a identificação das atividades necessárias para 
desenvolvimento das entregas do projeto. 
 
• Padronização de Ferramentas e Processo - Prática 1 (P1) 
 
Avaliar a necessidade de obter consenso entre os sites sobre a utilização de templates, 
ferramentas, e processos do ciclo de desenvolvimento de software comuns a todas as 
equipes. Esta prática visa minimizar esforço para integração de artefatos e comunicação 
entre os membros das equipes. Descrição da Prática P1: Considerar a atividade de 
padronização de ferramentas e processo de desenvolvimento entre os sites. 
 
• Atividades da Fase de Integração de Código – Prática 2 (P2) 
 
Avaliar a necessidade de realização de atividades necessárias para integração de código 
entre múltiplos sites, tais como: merge de código, resolução de conflitos, teste unitário 
dos componentes, teste de sanidade, reunião de avaliação de bug -atribuindo severidade, 
prioridade e responsável pelo bug, e correção de erro decorrente de integração. 
Descrição da Prática P2: Listar todas as atividades necessárias para realização da fase de 
integração do código do projeto entre os diferentes sites. 
 
• Definição da Interface de Comunicação - Prática 3 (P3) 
 
Para os módulos do sistema que forem desenvolvidos em mais de um site, considerar a 
atividade de definição do protocolo de comunicação entre os componentes que formam 
o sistema, antes de cada site iniciar o desenvolvimento. Descrição da Prática P3: 
Considerar a atividade para definição de interface de comunicação entre os 
componentes que serão desenvolvidos através de diferentes sites. 
 
• Reuniões em Proximidade Física - Prática 4 (P4) 
 
Identificar a quantidade, tipo e periodicidade de reuniões presenciais necessárias entre 
os membros dos projetos, considerando as viagens requeridas para as mesmas. 
Descrição da Prática P4: Considerar a necessidade de realização de reuniões em 
proximidade física e necessidade de viagens dos integrantes do projeto. 
 
• Aquisição de Conhecimento Cultural - Prática 5 (P5) 
 
Identificar as atividades necessárias para conhecimento e disseminação de informações 
sobre os aspectos culturais dos participantes dos projetos entre os membros dos 
diferentes sites. Descrição da Prática P5: Considerar a necessidade de estudo 
(conhecimento) da cultura dos diversos sites. 
127
Seqüenciamento da Atividade 
 
Durante a gerência de tempo, esta etapa visa realizar o seqüenciamento das atividades 
necessárias ao desenvolvimento do projeto, que foram definidas na fase anterior, 
dentificando as dependências entre as mesmas. 
 
• Sobreposição de horário de trabalho - Prática 6 (P6) 
 
Durante a etapa de seqüenciamento das atividades, na qual as dependências entre as 
tarefas serão identificadas, avalie a diferença de fuso entre os sites, a fim de usufruir o 
conceito do desenvolvimento follow-the-sun, ou seja, desenvolvimento quase que 
contínuo, possibilitando desta forma uma maior agilidade no desenvolvimento do 
produto, e conseqüentemente lançamento mais rápido do mesmo no mercado 
consumidor. Em contra partida, é importante também aproveitar os horários de 
sobreposição do trabalho entre sites para sincronizar os times com relação ao status dos 
projetos, realizando reunião com os pontos focais de cada site para esclarecimento de 
dúvidas e alinhamento sobre o desenvolvimento dos componentes do sistema. 
Descrição da Prática P6: Considerar as diferenças de horário de trabalho entre sites a 
fim de apoiar na definição do seqüenciamento das atividades, e aproveitar a existência 
de sobreposição do mesmo para reuniões de alinhamento do projeto entre as equipes. 
 
Estimativa de Recurso da Atividade 
 
Neste passo, o gerente de projetos determina o recurso (humano e material), além da 
quantidade necessária à realização das atividades. 
 
• Alocação de Recursos para Comunicação - Prática 7 (P7) 
 
No contexto de projetos DDS, as ferramentas, que serão utilizadas para comunicação 
entre os integrantes dos diferentes sites do projeto, devem possibilitar agilidade, 
compartilhamento de informação, além de proporcionar uma visão única do andamento 
das atividades para todos os integrantes. Analise o esforço e custo para preparação deste 
ambiente, identificando quais ferramentas de comunicação são necessárias para que a 
informação requerida para desenvolvimento do projeto chegue a todos os envolvidos. 
Descrição da Prática P7: Considerar os recursos materiais necessários para favorecer a 
comunicação entre sites. 
 
• Alocação de Sites - Prática 8 (P8) 
 
Avaliar a alocação de recursos, sites, necessária para a distribuição do trabalho de 
acordo com o tamanho do projeto. Sabe-se que quanto maior for a quantidade de sites 
envolvida no desenvolvimento, maior será o esforço gasto com comunicação e 
alinhamento entre times. Descrição da Prática P3: Alocar a quantidade de sites 
adequada para desenvolvimento do projeto, a fim de não sobrecarregar tanto o overhead 
de comunicação entre os sites envolvidos. 
 
 
 
128
Estimativa de Duração da Atividade 
 
Esta atividade visa identificar a quantidade de tempo (em períodos de trabalho) 
necessária para realização de cada tarefa do cronograma. 
 
• Arquitetura de Projetos Multisites - Prática 9 (P9) 
 
Devido à necessidade de divisão do trabalho entre diferentes sites, avalie a necessidade 
de considerar um percentual de esforço maior na a fase de arquitetura do software, 
quando comparado com um projeto de desenvolvimento centralizado. Durante esta fase 
do desenvolvimento, análise a estratégia de modelagem mais conveniente para o projeto 
e equipes, a fim de que a divisão do trabalho possa contribuir para diminuição do 
overhead de comunicação entre sites. Descrição da Prática P9: Considerar um 
percentual de esforço maior na fase de arquitetura de sistema voltada para projetos 
multisites. 
 
• Importação e Exportação de Mercadorias - Prática 10 (P10) 
 
Avaliar a necessidade de importação e exportação de produtos necessários para 
desenvolvimento do projeto e considerar o tempo gasto para obtenção dos mesmos. 
Descrição da Prática P10: Considerar o tempo necessário para importação e exportação 
(alfândega) de mercadorias ou produtos parciais do projeto. 
 
• Transferência de Dados - Prática 11 (P11) 
 
Considerar o tempo requerido para transferência e sincronização dos dados, código 
fonte e demais artefatos do projeto entre equipes. Para as etapas de homologaçãoe 
implantação, avaliar quais são os aspectos de segurança exigidos pelo cliente (política 
institucional), a fim de prever o tempo necessário para transferência dos dados do 
sistema para a sede do cliente durante a homologação e implantação. 
Descrição da Prática P11: Considerar o tempo para transferência de dados entre sites e 
cliente. 
 
Desenvolvimento do Cronograma 
 
Nesta etapa, construímos o cronograma do projeto, possibilitando uma visão do tempo 
total para desenvolvimento. 
 
• Calendário Anual - Prática 12 (P12) 
 
Elaborar o cronograma do projeto levando em consideração as diferenças de 
calendários, feriados de todos os sites envolvidos no desenvolvimento. 
Descrição da Prática P12: Considerar as diferenças de calendário entre os sites 
envolvidos no desenvolvimento do projeto. 
 
Controle do Cronograma 
 
Esta etapa é realizada continuamente no decorrer do projeto. Ela tem como objetivo 
129
controlar as mudanças, ou seja, inclusão, atualização, ou exclusão de alguma 
funcionalidade do escopo do projeto; ou alterações relacionadas aos recursos do projeto. 
 
• Atualização e Compartilhamento entre sites – Prática 13 (P13) 
 
Atualizar o progresso das atividades do projeto, identificando adiantamento, atraso, e 
cancelamento de requisitos. Além de atualizar os documentos do projeto e compartilhar 
visão integral do progresso do trabalho entre todos os integrantes do projeto, a fim de 
obter comprometimento com os principais marcos e que podem afetar o andamento das 
atividades entre equipes. Descrição da Prática P13: Atualizar o progresso das atividades 
do projeto e compartilhar a visão integral do status do trabalho entre todos os sites. 
 
4.1. FATORES VERSUS BOAS PRÁTICAS 
 
A Tabela 3 contém a relação entre as boas práticas sugeridas e a categoria dos possíveis 
fatores que podem impactar o esforço para desenvolvimento de software distribuído. 
 
Tabela 3 - Relação entre Categoria e Boa Prática 
 
É possível constatar que uma prática pode minimizar o impacto de um ou mais fatores. 
Como não foram identificadas práticas na literatura nem do estudo empírico, não 
laboramos boas práticas para os seguintes fatores: Projeto voltado à Inovação, Turnover, 
Nível de Experiência do Líder em DDS. 
 
5. CONCLUSÃO E TRABALHO FUTURO 
 
O desenvolvimento distribuído de software tem atraído diversas empresas a aderir a esta 
forma de trabalho. Essa estratégia favorece a diminuição do tempo de desenvolvimento 
(com a utilização do conceito follow-thesun), favorecendo o lançamento do produto 
mais rápido no mercado consumidor (reduzindo o time-to-market) [1], [2]. Apesar dos 
atrativos observamos que esta forma de desenvolver software traz alguns desafios que 
devem ser gerenciados para que o projeto obtenha sucesso. Especialmente relativos a 
equipe, processo de desenvolvimento, coordenação, controle, comunicação, devido à 
questão temporal, distância geográfica e a diferença cultural. Neste trabalho, abordamos 
os desafios encontrados na área de gerência de tempo em projetos DDS e propusemos 
um conjunto de boas práticas para esta área, visando apoiar os líderes no planejamento 
de projetos DDS. Como trabalho futuro, pretende-se realizar experimentos visando 
avaliar a proposta de boas práticas voltadas à área de gerenciamento de tempo de 
projetos DDS. 
 
130
REFERÊNCIAS 
 
[1] E. Carmel, Global software teams: collaborating across borders and time zones, 
Prentice Hall PTR, Upper Saddle River, NJ, 1999. 
[2] J. Audy and R. Prikladnicki. Desenvolvimento Distribuído de Software. Elsevier, 
Rio de Janeiro, 2008. 
[3] R. Mulcahy. Preparatório para o Exame de PMP. RMC Publications, 3 edition, 2007. 
[4] T. D. Marco. Controle de Projetos de Software. Ed. Campus, Rio de Janeiro, 1991. 
[5] J. D. Herbsleb, A. Mockus, T. A. Finholt, and R. E. Grinter. Distance, dependencies, 
and delay in a global collaboration. In CSCW ’00: Proceedings of the 2000 ACM 
conference on Computer supported cooperative work, pages 319–328. 
[6] J. D. Herbsleb, A. Mockus, T. A. Finholt, and R. E. Grinter. An empirical study of 
global software development: distance and speed. In ICSE ’01: Proceedings of the 23rd 
International Conference on Software Engineering, pages 81–90, Washington, DC, 
USA, 2001. IEEE Computer Society. 
[7] P. Keil, D. J. Paulish, and R. S. Sangwan. Cost estimation for global software 
development. In EDSER ’06: Proceedings of the 2006 international workshop on 
Economics driven software engineering research, pages 7–10, NY, USA, 2006. 
[8] E. Bradner, G. Mark, and TD Hertel. Effects of team size on participation, 
awareness, and technology choice in geographically distributed teams. In System 
Sciences, 2003. Proceedings of the 36th Annual Hawaii International Conference on, 
page 10, 2003.ACM. 
[9] D. H. James, M. Audris, A.F. Thomas, and E.G. Rebecca. An empirical 
study global software development: Distance and speed. In Proceedings of the 23rd 
International Conference on Software Engineering, Toronto, Canada, 2001. ACM. 
[10] N. Ramasubbu and R. K. Balan. Globally distributed software development project 
performance: an empirical analysis. In ESEC-FSE ’07: Proceedings of the the 6th joint 
meeting of the European software engineering conference and the ACM SIGSOFT 
symposium on The foundations of software engineering, pages 125–134, New York, 
NY, USA, 2007. ACM. 
[11] L. Pilatti, R. Prikladnicki, and J. L. N Audy. Avaliando os Impactos dos Aspectos 
Não-Técnicos da Engenharia de Software em Ambientes de Desenvolvimento Global de 
Software: Um Caso Prático. In Workshop um olhar sociotécnico sobre a Engenharia de 
Software, III, Porto de Galinhas, pages 85–96, 2007. 
[12] F. L. Siqueira and P. S. M. Silva. Recomendações para a gerência de projetos no 
desenvolvimento distribuído de software. In Anais do V Simpósio Brasileiro de 
Qualidade de Software, pages 42–56, Vila Velha, ES, 2006. SBC. 
[13] Standish Group. CHAOS Summary 2009. Technical report, Standish Group, 2009. 
[14] Construx. Software development’s classic mistakes. Technical report, 2008. 
[15] Nvivo. Disponível em http://www.nvivo9.com.br/. 
[16] Linda M. Laird. The limitations of estimation. IT Professional, 8(6):40–45, 2006. 
[17] I. H. Farias Junior, at all. Best Practices to Enhance the Communication in 
Distributed Software Development Environments. (Confenis 2010), Natal-RN. 
[18] M. Anjum, M.I. Zafar, and S.A. Mehdi. Establishing Guidelines for Management 
of Virtual Teams. 
131