Proceedings of 7th Experimental Software Engineering Latin American Workshop (ESELAW 2010)

Tamanho: px
Começar a partir da página:

Download "Proceedings of 7th Experimental Software Engineering Latin American Workshop (ESELAW 2010)"

Transcrição

1 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

2

3 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, CD-ROM, 4 ¾ pol. Patrocinadores: CNPq, FAPEG, FUNAPE, SIAGRI. ISBN: Engenharia de Software. 2. Workshop. I. Vincenzi, Auri Marcelo Rizzo. II. Conte, Tayana Uchoa. III. Prado, Marllos Paiva. IV. Título CDU: :061.3

4 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

5 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

6 Committees Chairs Auri M. R. Vincenzi (INF-UFG, Brazil) General Chair Tayana U. Conte (UFAM, Brazil) Program Chair Steering Committee Guilherme Horta Travassos José Carlos Maldonado Márcio Eduardo Delamaro Manoel G. de Mendonça Neto Sandra C. P. F. Fabbri Program Committee Andreas Jedlitschka Arilo Dias Neto Carla Lima Reis Cleidson de Souza Daniela Cruzes Eduardo Almeida Ellen Francine Barbosa Emilia Mendes Fabio Queda Bueno da Silva Giovanni Cantone Guilherme Travassos Jeffrey Carver José Carlos Maldonado Juliano Oliveira Manoel G. de Mendonça Neto Marcela Genero Márcio Eduardo Delamaro Marco Antônio Pereira Araújo Marcos Chaim Oscar Dieste Oscar Pastor Plínio Leitão-Júnior Rafael Prikladnicki Raul Sidnei Wazlawick Sandra C. P. F. Fabbri Sergio Ochoa Simone Souza (COPPE-UFRJ, Brazil) (ICMC-USP, Brazil) (ICMC-USP, Brazil) (UFBA, Brazil) (DC-UFSCAR, Brazil) (Fraunhofer IESE, German) (UFAM, Brazil) (UFPA, Brazil) (IBM Brasil, Brazil) (NTNU, Norway) (UFBA-RiSE, Brazil) (ICMC-USP, Brazil) (The University of Auckland, New Zealand) (UFPE, Brazil) (University of Rome TorVergata, Italy) (COPPE-UFRJ, Brazil) (University of Alabama, USA) (ICMC-USP, Brazil) (UFG, Brazil) (UFBA, Brazil) (University of Castilla-La Mancha, Spain) (ICMC-USP, Brazil) (COPPE-UFRJ, Brazil) (EACH-USP, Brazil) (Universidad Politécnica de Madrid, Spain) (Universitat Politècnica de València, Spain) (UFG, Brazil) (PUCRS, Brazil) (UFSC, Brazil) (DC-UFSCar, Brazil) (Universidad de Chile, Chile) (ICMC-USP, Brazil)

7 Organizing Committee Local Arrangements Chair Cristiane Bastos Rocha Ferreira Edmundo Sérgio Spoto Tutorial And Short Course Session Guilherme Horta Travassos Publication Chair Marllos Paiva Prado (INF-UFG, Brazil) (INF-UFG, Brazil) (COPPE-UFRJ, Brazil) (INF-UFG, Brazil) External Reviewers Adailton Lima Alline Lemos Fabiano Cutigi Ferrari Gleison Santos Katia Felizardo Leandro Oliveira Maria Istela Cagnin Paulo Masiero Mayara Figueiredo Pedro Treccani Rodrigo Reis Rogério Eduardo Garcia Rosana Braga Valdemar Neto (UFPA, Brazil) (UFPA, Brazil) (ICMC-USP, Brazil) (UNIRIO, Brazil) (ICMC USP, Brazil) (INF-UFG, Brazil) (UFMS, Brazil) (ICMC - USP, Brazil) (UFPA, Brazil) (UFPA, Brazil) (UFPA, Brazil) (UNESP, Brazil) (ICMC-USP, Brazil) (UFG, Brazil)

8 Conteúdo Invited Talk 2 Comparative Analysis of Meta-Analysis Methods: When to Use Which (Oscar Dieste) Developing Software Technologies through Experimentation: Experiences from the Battlefield (Guilherme Travassos) Short Courses 6 Introdução a Métricas e Medição de Software (Emília Mendes) Aggregation of Software Engineering Experiments (Oscar Dieste) Technical Session 1 -Systematic Reviews and Experimental Software Engineering Support 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, Ana Regina Rocha, Gleison Santos) 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. Correia dos Santos, Camila Cunha Borges, David E. S. Carneiro, Fabio Q. B. da Silva) Avaliação da Ferramenta StArt Utilizando o Modelo TAM e o Paradigma GQM (Elis Hernandes, Augusto Zamboni, Andre Di Thommazo, Sandra Fabbri) Uma Ferramenta de Apoio ao Planejamento de Estudos Experimentais em Engenharia de Software (Vitor Pires Lopes, Guilherme Horta Travassos) 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. Treccani, Cleidson R. B. de Souza) Aplicando Técnicas de Grounded Theory e Retrospectiva Ágil Para Buscar Melhorias Para o Curso Laboratório XP (Viviane A. Santos, Alfredo Goldman) 60 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) Um Estudo Exploratório dos Fatores Associados ao Estímulo do Aprendizado em Times Ágeis na Indústria (Claudia de O. Melo, Carlos D. Santos Jr, Gisele R. M. Ferreira, Fabio Kon) Experimental Studies 90 Resultados de um Estudo de Caracterização e Avaliação de Critérios de Teste Estruturais Entre os Paradigmas Procedimental e OO (Marllos Paiva Prado, Simone do Rocio Senger de Souza, José Carlos Maldonado) Reuso de Conjuntos de Casos de Teste no Ensino de Disciplinas Introdutórias de Programação (Maria A. S. Brito, João L. Rossi, Simone R. S. de Souza, Rosana T. V. Braga)

9 Evaluating a Tool for Bug-report Analysis and Search (Yguaratã Cerqueira Cavalcanti; Paulo Anselmo da Silveira Mota; Ivan do Carmo Machado; Eduardo Santana de Almeida; Silvio Romero de Lemos Meira) Boas Práticas para Apoiar o Gerenciamento de Tempo em Projetos DDS (Ana Carina M. Almeida, Ivaldir H. de F. Jr, Renata Souza, Hermano Perrelli)

10 INVITED TALK 3

11 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 decisionmaking 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 nonstatistical procedures. He has published some papers on the field (i.e., Understanding the Customer: What Do We Know about Requirements 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 4

12 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 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 Contact him at 5

13 INVITED SHORT COURSES 6

14 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 curso visa 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

15 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 nonstatistical procedures. He has published some papers on the field (i.e., Understanding the Customer: What Do We Know about Requirements 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 8

16 TECHNICAL SESSION 1 Systematic Reviews and Experimental Software Engineering Support (SRESES) 9

17 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 CEP 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 Rio de Janeiro, RJ {natalia, 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 importâ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 ocorrê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] [Kalinowski 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 problema 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 conhecimento implícito, tais como diagrama de Ishikawa, entrevista e sessões de brainstorming. 10

18 Contudo, há um risco inerente à adoção deste tipo de técnicas para obter as informaçõ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 abordagem visa auxiliar a captura de informações relevantes a respeito do problema selecionado (apoiada por um processo definido e modelos (templates) de documentos) e analisar 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 dependentes do conhecimento do pesquisador, permitindo que a pesquisa seja repetida por outros pesquisadores e os resultados possam ser comparados. No contexto deste trabalho, um estudo baseado em revisão sistemática foi conduzido com o objetivo de identificar estudos com propostas de execução do processo de Análise de Causas de Problemas 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 trabalho. 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 trabalhos encontrados, verificou-se a importância da etapa de identificação de causas de problemas 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 problemas no âmbito organizacional na área de engenharia de software, tais como: desvio 11

19 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 delimitado, 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 somente alguns destes itens serão detalhados neste artigo. A descrição completa do protocolo é 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étodos, processos e ferramentas, com relação a procedimentos para identificação das causas raiz de problemas, do ponto de vista de pesquisadores, no contexto acadêmico e industrial. Questões de pesquisa - A partir do objetivo do estudo, foi elaborada uma questão principal Que técnicas, métodos, processos e ferramentas têm sido propostos e/ou utilizados 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 problemas? ; (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 expressã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

20 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 seguindo 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 ferramentas 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 busca, o filtro anterior também não garante que todo o material coletado seja útil no contexto da pesquisa. Por isso, as publicações selecionadas na 2ª etapa devem ser lidas completamente, 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), foram 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 Experiences with Defect Prevention R.G. Mays, C.L. Jones et al An Application of Causal Analysis to the Software Modification J. Collofello e B. 3 Process Gosalia 1993 Software Failure Analysis for High Return Process Improvement 4 Decisions R. Grady Root Cause Analysis for Beginners J. Rooney e L. Heuvel Defect Analysis: Basics Techniques for Management and Learning D. Card 2005 Implementing Causal Analysis and Resolution in Software Development Projects: The MiniDMAIC Approach zerra et al. F. Gonçalves, C. Be 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 "causeand-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

21 cionadas devido ao bom funcionamento e abrangência de suas máquinas de busca, evidenciadas em alguns trabalhos, como o de SANTOS (2008). Após a execução da expressã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 definidos não estava sendo retornada. Após analisar as palavras-chaves dos artigos de controle, 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 publicaçõ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 indexado ainda não retornado na máquina de busca Scopus. Após esta alteração, verificou-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 detalhadamente as publicações que estavam sendo retornadas, separando-as por área de conhecimento (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 publicaçõ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 impossibilidade 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 estudo. Por outro lado, foi observado a partir do cálculo do índice de relevância (apresentado 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 Scopus. 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 índice de relevância), decidiu-se incluir também esta área de conhecimento na pesquisa. 14

22 Tabela 2 Resultados da análise dos artigos retornados por área de conhecimento Área de conhecimento Nº total de Nº de resumos lidos selecionadas relevância 1 Nº de publicações Índice de publicações Engenharia ,35 Medicina Ciência da Computação Enfermagem ,08 Engenharia Química ,44 Ciências Sociais ,63 Física e Astrologia ,67 Energia ,67 Ciência de Materiais Negócio, Gerência e Contabilidade ,43 Matemática 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 artigos de controle indexados na máquina de busca fossem retornados. Com isto, a expressã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 ministrados 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 apresentam 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 partir 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 Como primeira etapa da seleção dos estudos, a expressão de busca definida foi executada na máquina de busca Scopus. Esta execução retornou 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 selecionadas 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 selecionadas. Quanto mais próximo de 1 o índice estiver, melhor é a relevância das publicações da área para o estudo. 15

23 Para atender à terceira etapa de seleção, as 42 publicações foram lidas completamente e, destas, somente 14 atendiam a, pelo menos, um dos critérios de inclusão definidos. Foram extraídas as informações das 14 publicações consideradas dentro do escopo 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 Software Modification Process, Software Practice and Experience, 23(10), pp Resumo da publicação Os autores sugerem uma adaptação do processo de análise de causas de falhas de software para atividades 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 entrevistar o indivíduo responsável pela inserção do defeito no software. Aconselha-se que a entrevista seja informal 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 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 publicações, sendo 25 novas publicações comparadas à execução anterior. A partir da leitura 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 completamente 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 possível responder, parcialmente, às questões da pesquisa. 16

24 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 verificou sua aplicabilidade para a área de engenharia de software. Além disto, estas abordagens 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 informação sobre quais dados são coletados em muitos trabalhos. No entanto, nos trabalhos 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, detalhes 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ínimas 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 crité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 tipo de defeito 17

25 introduzido. Dentro deste contexto, o esquema de classificação Orthogonal Defect Classification (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 objetiva e ao mesmo tempo preservando a qualidade dos dados capturados. Este fato motiva estudos mais aprofundados nesta área, para que as organizações consigam identificar as verdadeiras causas de seus problemas e mantenham uma gerência proativa eficiente. Este fato corroborou a proposta da abordagem em analisar a causa raiz do problema utilizando métodos de pesquisa qualitativa (Grounded Theory), por meio da definiçã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 resultados obtidos. Tal limitação pode ser resolvida a partir da execução do protocolo do estudo 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 baseado em revisão sistemática utilizado como base para a elaboração da abordagem proposta para identificação de causas de problemas utilizando Grounded Theory. Este estudo 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á indí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, reexecuçõ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

26 Referências BASILI, V., ROMBACH, H., 1988, "The Tame Project: Towards Improvement-Oriented Software Environments", IEEE Transactions on Software Engineering, v. 14, n. 6, pp 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, Advances in Computers, vol. 65, pp COLLOFELLO, J. S., GOSALIA B. P., 1993, An Application of Causal Analysis to the Software Modification Process, Software-Practice and Experience, v. 23, n. 10, pp , October. DEW, J. R., 1991, In Search of the Root Cause. Quality Progress, vol. 24, n. 3, pp 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 ENDRES, A., 1975, An Analysis of Errors and their Causes in System Program, IEEE Transactions on Software Engineering, SE-1, pp 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, Empirical Software Engineering, vol. 14, n. 2, pp GRADY, R. B., 1996, Software Failure Analysis for High return Process Improvement Decisions, Hewlett-Packard Journal, v. 47, n. 4, pp , August. KALINOWSKI, M., TRAVASSOS, G. H., CARD, D. N., 2008, Towards a Defect Prevention Based Process Improvement Approach. 34th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), pp , 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 LATINO, R. J., 2005, The Application of PROACT RCA to Terrorism/Counter Terrorism Related Events, Lecture Notes in Computer Science, pp LESZAK, M., PERRY, D., STOLL, D., 2000, A Case Study in Root Cause Defect Analysis. International Conference on Software Engineering (ICSE 2000), pp , 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 ROONEY, J., HEUVEL, L., 2004, Root Cause Analysis for Beginners, Quality Progress, pp , 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 , Pune, India, February. SCHOTS, N. C. L., 2010, Uma Abordagem para a Identificação de Causas de Problemas Utilizando 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 Procedures for Developing Grounded Theory, Second Edition, Sage Publications. 19

27 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 Recife PE Brasil 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ão da 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

28 (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 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 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 Fase 4 Análise e validação dos artigos para eliminação de duplicações e leitura completa dos estudos selecionados pelos pesquisadores. 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

29 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 (7)... estar completo comunicação em DDS (4)... apresentar alguma influência da comunicação em (8)... ser original (não possuir duplicações) projetos de DDS 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 Não Estudos Repetidos Incompletos Relevantes Relevantes Primários IEEEXplore ACM ScienceDirect EI Compendex Scopus TOTAL 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

30 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 estudos selecionados 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

31 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. Fatores Tabela 7. Fatores identificados nas equipes de software. FA1. Fatores sociais (Confiança, interação, integração, motivação, cooperação e coesão) FA2. Falta de confiança na língua nativa 24 Estudos Primários [EP2], [EP3], [EP4], [EP6], [EP10], [EP11], [EP14], [EP15], [EP16], [EP17], [EP18], [EP19], [EP21], [EP23], [EP24], [EP26], [EP28], [EP32], [EP33] [EP5], [EP9], [EP14], [EP15], [EP16],

32 FA3. Dificuldade de expressão FA4. Preferências meios de comunicação baseada em texto FA5. Satisfação no trabalho FA6. Conhecimentos técnicos FA7. Personalidade [EP18], [EP19], [EP20], [EP21], [EP22], [EP27], [EP33] [EP9], [EP14], [EP18], [EP22], [EP24], [EP25], [EP30], [EP31] [EP5], [EP10], [EP29] [EP9], [EP16], [EP17] [EP18], [EP19], [EP23], [EP24], [EP33] [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 FE1. Aúdio Conferência (teleconferência, chamadas de conferência ou conferência via Internet) FE2. Telefone FE3. Video conferência FE4. NetMeeting FE5. Chat ou Messenger FE6. Conferência de Dados FE7. VOIP FE8. Compartilhamento de documentos FE9. Fóruns FE10. Intranet ou websites FE11. Wiki FE12. FE13. PowerPoint FE14. Calendários FE15. Fax FE16. Collanos FE17. Bugzilla FE18. TeamSpace Estudos Primários [EP5], [EP9], [EP11], [EP12], [EP14], [EP19], [EP20], [EP21], [EP22], [EP27], [EP31], [EP32] [EP3], [EP5], [EP9], [EP11], [EP14], [EP15], [EP27], [EP1], [EP5], [EP8], [EP10], [EP11], [EP14], [EP24] [EP9], [EP15], [EP25] [EP5], [EP6], [EP8], [EP9], [EP11], [EP18], [EP24], [EP26], [EP27], [EP28], [EP29] [EP1], [EP11] [EP5], [EP9] [EP9], [EP10], [EP12], [EP18], [EP26], [EP27] [EP5], [EP18], [EP24] [EP2], [EP5], [EP9], [EP11], [EP12] [EP12] [EP1], [EP3], [EP4], [EP5], [EP6], [EP8], [EP9], [EP10], [EP12], [EP13], [EP14], [EP15], [EP18], [EP19], [EP20], [EP21], [EP22], [EP26], [EP29], [EP31], [EP32] [EP11], [EP12] [EP5], [EP9] [EP14] [EP27] [EP15] [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 D3. Diferença de fuso horário FE1, FE2, FE3, FE4, FE5, FE7, FE8, FE10, FE12, FE14, FE15 FE1, FE2, FE3, FE4, FE5, FE7, FE8, FE10, FE12, FE14, 25 [EP4], [EP9], [EP14], [EP20], [EP22], [EP24], [EP25], [EP31], [EP32] [EP9], [EP14], [EP20], [EP22], [EP24], [EP25], [EP31]

33 D4. Reunião face-to-face FE15 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 D7. Atraso da informação D8. Meio de comunicação deficiente D9. Planejamento da Comunicação FE1, FE2, FE3, FE4, FE5, FE8, FE12, FE15, FE17 FE1, FE2, FE4, FE5, FE7, FE8, FE10, FE12, FE14, FE15, FE17 FE1, FE2, FE4, FE5, FE7, FE8, FE10, FE12, FE14, FE15, FE16, FE17, FE1, FE2, FE3, FE5, FE7, FE8, FE9, FE10, FE12, FE14, [EP14], [EP15], [EP26] [EP3], [EP9], [EP10], [EP14], [EP15], [EP24], [EP26] [EP9], [EP14], [EP15], [EP27] [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 FE1, FE2, FE3, FE4, FE5,FE8, (Confiança, interação, FE9, FE10, FE12, FE13, FE15, integração, motivação, FE17 cooperação e coesão) FA2. Falta de confiança na língua nativa FA3. Dificuldade de expressão FA4. Preferências meios de comunicação baseada em texto FA5. Satisfação no trabalho FA6. Conhecimentos técnicos FA7. Personalidade FE1, FE3, FE4, FE5, FE7, FE8, FE9, FE10, FE12, FE14, FE15, FE16, FE17, FE1, FE2, FE3, FE4, FE5, FE7, FE10, FE12, FE14, FE15 FE1, FE2,FE3, FE5, FE7, FE8, FE9, FE10, FE12, FE14 FE1, FE2, FE4, FE5, FE7, FE8, FE9, FE10, FE12, FE14 FE1, FE3, FE5, FE8, FE9, FE12 FE1, FE2, FE3, FE5, FE8, FE9, FE12, FE15 [EP1], [EP6], [EP15], [EP10], [EP11], [EP14], [EP15], [EP16], [EP18], [EP19], [EP21], [EP24], [EP26], [EP28], [EP32] [EP5], [EP9], [EP14], [EP15], [EP18], [EP19], [EP20], [EP21], [EP22], [EP27], [EP9], [EP14], [EP22], [EP24], [EP25], [EP31] [EP5], [EP10], [EP29] [EP9] [EP18], [EP19], [EP24] [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 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

34 identificados nas equipes. Algumas das dificuldades identificadas podem ser amenizadas por meio das ferramentas como audioconferência, , 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, 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,

35 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, [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: [EP3] Korkala, M. Abrahamsson, P. Communication in Distributed Agile Development: A Case Study. Conference on Software Engineering and Advanced Applications, [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): [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, [EP6] Nguyen, T.; Wolf, T.; Damian, D. Global software development and delay: Does distance still matter? IEEE International Conference on Global Software Engineering, 2008: [EP7] Geyer, W.; Richter, H.; Fuchs, L. et al. A Team Collaboration Space Supporting Capture and Access of Virtual Meetings. ACM, 2001: [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): [EP9] Thissen, M.; Page, J.; Bharathi, M.; Austin, T. Communication Tools for Distributed Software Development Teams. ACM, 2007 : [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: [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:

36 [EP12] Almeida, A.; Junior, I. Managing Communication among Geographically Distributed Teams: a Brazilian Case. Springer Berlin Heidelberg, 2009:35: [EP13] Calefato, F 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): [EP15] Damian, D.; Izquierdo, L.; Singer, J.; Kwan, I Awareness in the Wild: Why Communication Breakdowns Occur. International Conference on Global Software Engineering (ICGSE 07). [EP16] Gowda, R 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 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: [EP19] Huang, H.; Trauth, E. Cultural Influences and Globally Distributed Information Systems Development: Experiences from Chinese IT Professionals. Communications of the ACM. 2007: [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: [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: [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): [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 Student Communication Challenges in Distributed Software Engineering Environments. Innovation and Technology in Computer Science Education (ITiCSE 05), [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: [EP28] Lin, C.; Standing, C.; Liu, YC. A model to develop effective virtual teams. Journal Decision Support Systems, 2008:45: [EP29] Gutwin C, Penner R, Schneider K Group awareness in distributed software development. Computer Supported Cooperative Work (CSCW 04), [EP30] Prikladnicki R. Exploring Propinquity in Global Software Engineering. IEEE International Conference on Global Software Engineering, 2009: [EP31] Ehrlich, K.; Chang, K Leveraging expertise in global software teams: Going outside boundaries. International Conference on Global Software Engineering (ICGSE'06), [EP32] French, A.; Layzell, P A Study of Communication and Cooperation in Distributed Software Project Teams. International Conference on Software Maintenance (ICSM'98), [EP33] Kommeren, R. Phili EP experiences in global distributed software development. Empir Software Eng, 2007 :12:

37 Avaliação da ferramenta StArt utilizando o modelo TAM e o paradigma GQM Elis Hernandes 1, Augusto Zamboni 1, Andre Di Thommazo 2, Sandra Fabbri 1 1 Departamento de Computação - Universidade Federal de São Carlos (UFSCar) 2 Instituto Federal de Educação, Ciência e Tecnologia de São Paulo (IFSP) {elis_hernandes, Abstract: Context: The tool named StArt was developed to 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ósgraduaçã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

38 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 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 Definir o objetivo e planejar a - Identificar a necessidade da Revisão Sistemática; Planejamento Revisão Sistemática - Definir os objetivos da pesquisa; Execução (Condução, Seleção de estudos e Extração de Informações) Publicação dos Resultados Executar o planejamento feito no protocolo, buscar estudos primários e selecionar os estudos primários para serem sintetizados Sintetizar os estudos primários que atendem ao propósito da revisão - Criar o protocolo (planejar a RS); - 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; - 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

39 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 lelos 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

40 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

41 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. Questã o Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Figura 4. GQM para avaliar a StArt Tabela 2. Questões usadas no GQM Descrição Questã Descrição o Qual atividade exigida no processo de revisão sistemática você Considero a StArt fácil de usar Q10 julga ser a mais DIFÍCIL Depois de conhecer o processo de revisão sistemática, você A StArt me permitiu executar a revisão modificou sua forma de realizar revisão bibliográfica? Q11 sistemática em conformidade com o processo definido na literatura Você tentou aplicar novamente o processo de revisão sistemática após a disciplina realizada no segundo semestre de 2009? Qual seu grau de concordância com a afirmação: "A revisão sistemática é fundamental para a qualidade de uma pesquisa acadêmica" Foi fácil aprender a utilizar a StArt Consegui utilizar a StArt da forma que eu queria Eu entendia o que acontecia na minha interação com a StArt Foi fácil ganhar habilidade no uso da StArt Foi fácil lembrar como realizar uma revisão sistemática com o uso da StArt Q12 Q13 Q14 Q15 Usar a StArt melhorou o meu desempenho durante a execução das atividades do processo de revisão sistemática que foram realizadas. Usar a StArt facilitou a execução das atividades que compõem o processo da revisão sistemática Usar a StArt melhorou minha produtividade na execução das atividades do processo de revisão sistemática que foram realizadas. Eu considero a StArt útil para executar minha(s) revisão sistemática 34

42 Métrica M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 Tabela 3. Métricas usadas no GQM Descrição Número de pessoas que escolheram elaboração do protocolo Número de pessoas que escolheram criação das strings de busca Número de pessoas que escolheram busca de artigos nas máquinas de busca Número de pessoas que escolheram selecionar os artigos que serão lidos por completo Número de pessoas que escolheram extrair informações dos artigos lidos por completo Número de pessoas que escolheram sumarizar o resultado da revisão sistemática Número de pessoas que escolheram SIM Número de pessoas que escolheram NÃO Número de pessoas que escolheram Concordo totalmente Número de pessoas que escolheram Concordo amplamente Número de pessoas que escolheram Concordo parcialmente Número de pessoas que escolheram Discordo totalmente Número de pessoas que escolheram Discordo amplamente 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 > M i, i= 2, 3, 4, 5 e 6 atividade de maior dificuldade é a elaboração do protocolo 2 M2 > M i, i=1, 3, 4, 5 e 6 atividade de maior dificuldade é a criação das strings de busca 3 M3 > M i, i = 1, 2, 4, 5 e 6 atividade de maior dificuldade é a busca de artigos nas máquinas de busca 4 M4 > M i, i= 1, 2, 3, 5 e 6 atividade de maior dificuldade é selecionar os artigos que serão lidos por completo 5 M5 > M i, i= 1, 2, 3, 4 e 6 atividade de maior dificuldade é extrair informações dos artigos lidos por completo 6 M6 > M i, 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 Para Q4: M9 + M10 + M11 8 M12 + M13 + M14 9 Para Q i, i = 5 a 10: M9 M10 + M Para Q i,, i=5 a 10: M9 M10 + M11 e M10 M11 Para Q i,, i=5 a 10: M9 M10 + M11 e M11 M10 12 Para Q i,, i=11 a 15: M9 M10 + M Para Q i,, i=11 a 15: M9 M10 + M11 e M10 M11 Para Q i,, i=11 a 15: M9 M10 + M11 & M11 M10 Para Q i,, i= 5 a 10: M14 + M13 + M12 M9 + M10 + M11 Para Q i,, i=11 a 15: M14 + M13 + M12 M9 + M10 + M11 a RS é vista como um recurso fundamental para a qualidade de uma pesquisa acadêmica 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 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 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 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 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 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 identificar se 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 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 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

43 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 Coleta de dados O primeiro questionário (objetivos 1 e 2 do GQM) foi enviado por 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 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) Busca de Selecionar os Extrair Sumarizar o Criação Elaboração artigos nas artigos que informações/ resultado da das strings Outra do protocolo máquinas de serão lidos por dados dos artigos revisão de busca busca completo lidos por completo sistemática Q1) Qual atividade exigida no processo de revisão sistemática você julga ser a mais DIFÍCIL: Tabela 6. Dados coletados no questionário 1 (perguntas 2 e 3) Q2) Depois de conhecer o processo de revisão sistemática, você modificou sua forma de realizar revisão bibliográfica? Q3) Você tentou aplicar novamente o processo de revisão sistemática após a disciplina realizada no segundo semestre de 2009? Sim Não 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"

44 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, ) 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, & 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

45 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, ) 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 à facilidade de 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

46 Referências Basili, V. R., C. Caldiera, H.D. Rombach, (1994). Goal Question Metric Paradigm. Encyclopedia of Software Engineering. John Wiley & Sons, pp 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 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 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 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 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 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 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 , 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

47 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 , CEP , Rio de Janeiro Brasil {vitorlopes, 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ãoobservâ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

48 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 tomadas pelo 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

49 [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. 2 1 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. 42

50 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. Figura 2. Fragmento da Interface. Decisão sobre qual estratégia de estudo será adotada (survey) 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 43

51 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. 1 2 Figura 3. Fragmento da Interface. Decisões específicas à estratégia escolhida (survey) na Figura 2 44

52 É 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 Figura 4. Fragmento do documento gerado para o planejamento do survey 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 45

53 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 Figura 5. Arquitetura simplificada da espa 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, 46

54 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 , 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 , 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

55 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

56 TECHNICAL SESSION 2 Studies with Qualitative Focus (SQF) 49

57 Utilização de Metodologias Ágeis no Desenvolvimento de Software: Resultados de um Estudo Empírico Pedro J. F. Treccani 1, Cleidson R. B. de Souza 2 1 Faculdade de Computação Universidade Federal do Pará (UFPA) Caixa Postal Belém PA Brasil 2 IBM Brasil São Paulo SP - Brasil 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

58 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, empresa II, empresa III e empresa IV. 51

59 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 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

60 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ódigo 1, 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

61 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 dos dados 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

62 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 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

63 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: 3.2. Discussão 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 (...). 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 que nã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

64 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

65 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: /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

66 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 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 of Innovation, Computer, September 2001, pp , 2001 Karlström D, Runeson P, Integrating agile software development into stage-gate managed product development. Empir Softw Eng 11(2): , 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á, 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, Maxqda2, 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, practices on communication in software development, Engineering, 2008 The impact of agile Empirical Software 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, 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,

67 Aplicando Técnicas de Grounded Theory e Retrospectiva Ágil para Buscar Melhorias para o Curso Laboratório XP Viviane A. Santos 1, Alfredo Goldman 1 1 Instituto de Matemática e Estatística (IME) Universidade de São Paulo (USP) Caixa Postal CEP São Paulo SP Brasil {vsantos, Resumo. Este artigo apresenta um estudo empírico sobre o aprendizado de extreme Programming em ambiente acadêmico. O estudo emprega duas abordagens distintas para triangulação dos dados: análise qualitativa com grounded theory em um questionário e retrospectiva ágil para investigar o que o curso precisa melhorar na visão dos alunos. A partir dos resultados, ações de melhoria mais direcionadas foram estabelecidas para as próximas ediçõ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. Introdução Em 2001, os métodos ágeis foram formalmente apresentados pelo Manifesto Ágil [Beck et al. 2001] e, desde então, têm recebido muita atenção da indústria e da academia por revelar formas efetivas de desenvolver software. O movimento pela agilidade no desenvolvimento de software tem provocado uma quantidade substancial de debates e publicações. No entanto, dentro do estado da arte de evidências empíricas, este assunto ainda se mantém escasso [Dybå et al. 2010]. Há poucos estudos com rigor metodológico neste campo e a maioria dos esforços científicos existentes encontra-se no âmbito de extreme Programming (XP) [Beck and Andres 2004]. [Dybå et al. 2010] relatam que, em ambiente acadêmico, a programação em pares tem promovido redução de 40-50% do tempo estimado para completar uma tarefa, aumento da satisfação no trabalho e qualidade de código. Ao contrário disto, TDD (Test- Driven Development) [Beck 2003] tem dispendido maior tempo para a implementação (uma média de 16%), assim como teste antes de codificar (Test-First Programming) não acelera a implementação. Segundo eles, a eficiência na programação em pares depende da experiência do programador e da complexidade do sistema e das tarefas envolvidas Motivação e Objetivo de Pesquisa A motivação desta pesquisa consiste no interesse dos responsáveis pelo curso de XP da instituição em melhorá-lo para as próximas edições através de feedback dos alunos. A estratégia utilizada para atingir este objetivo considerou duas abordagens distintas: 60

68 1. Realização de pesquisa qualitativa através da análise de respostas dos alunos a um questionário não estruturado com questões abertas 1 ; 2. Retrospectiva final do curso com a participaçã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 melhorar através da aplicação de técnicas de um método de pesquisa científico em dados de um questionário e da análise do relatório da retrospectiva final. A Seção 2 descreve o curso mencionado. Na Seção 3 é apresentada a primeira abordagem realizada com os alunos do curso, incluindo o uso de técnicas de grounded theory para a análise qualitativa. Já na Seção 4 é relatada a segunda abordagem que corresponde a retrospectiva final. A corroboração dos resultados destas abordagens diferentes é a contribuição mais relevante deste artigo. Finalmente, na Seção 5 são apresentadas as ações de melhoria, as conclusões e os trabalhos futuros. 2. Laboratório XP: Contexto do Curso Desde 2001 [Goldman et al. 2004], o curso denominado Laboratório XP tem oferecido aos alunos, de graduação e de pós-graduação em ciência da computação, uma aproximação à realidade de um projeto de desenvolvimento ágil de software. O curso conta com 1 professor, 3 meta-coaches e 51 alunos, sendo 9 coaches (dentre eles 1 meta-tracker), que correspondem a alunos mais experientes ou que já conhecem a metodologia, e 42 desenvolvedores integrantes de 8 equipes que conduzem projetos reais com clientes reais 2. Houve um projeto em que atuaram 2 coaches e outro em que o coach também atuou como meta-tracker do curso, auxiliando todas as equipes na condução de tracking apropriado às características de seus respectivos projetos. O curso também conta com a dedicação de 8h semanais dos alunos, por este motivo, almoço é oferecido para motivá-los a dispor deste tempo para o projeto. O curso disponibiliza toda a infraestrutura física e tecnológica necessária, e material para a aplicação da metodologia nos projetos. Na primeira aula foram apresentados o curso, a forma de avaliação e os projetos. Cada aluno escolheu até três projetos desejados para a formação das equipes, alé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 sobre como atuar em um projeto ágil. A partir de então, os alunos foram apresentados aos seus respectivos ambientes de trabalho, projetos, coaches e clientes. 3. Primeira Abordagem: Questionário Aberto A primeira abordagem corresponde a uma pesquisa qualitativa com base em dados empíricos provenientes de um questionário fornecido aos alunos antes do final do curso a fim de que pudessem expressar com mais fidelidade sua visão sobre o curso. O estudo realizado objetiva entender, pela ótica dos alunos, o que precisa ser melhorado no curso Metodologia A metodologia utilizada nesta abordagem corresponde à coleta de dados por questionário e à análise qualitativa com Grounded Theory (GT) [Corbin and Strauss 2007]. 1 A forma não-estruturada e indireta do questionário visa incentivar os alunos a projetarem suas opiniões, dificuldades, motivações, crenças, atitudes ou sensações subjacentes sobre os problemas em estudo. 2 Para detalhes sobre esta edição do curso acesse: gold/cursos/2010/xp2010.html 61

69 A coleta foi realizada de forma aberta, não obrigatória e anô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 questionário, mas também houve equipes que responderam o questionário em conjunto e outras que não tiveram feedback de alguns integrantes, o que resultou em 44 respondentes. O modo de coleta de dados pode implicar em viés de seleção, devido a possibilidade de omissão dos alunos por se sentirem intimidados em criticar o curso. Porém, todas as equipes forneceram feedback representativo, o que minimizou este viés. Para a análise dos dados qualitativos, GT mais se adequava, devido se fundamentar nos dados, lidar com fenômenos do comportamento humano e permitir extrair aspectos significativos do caso em estudo, ao invés de só transformá-los em números Método de Pesquisa Qualitativa Grounded Theory O mé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 análise interativa e sistemática (saturação teórica)de dados empíricos. Diferentemente de outros métodos que usam os dados para avaliar hipóteses predefinidas, este método baseia-se nos dados coletados para gerar uma teoria fundamentada nos mesmos. De acordo com [Urquhart et al. 2010], este método possui quatro características fundamentais, que são: o seu principal propósito é a construção de teoria; o conhecimento prévio do pesquisador não deve levá-lo à hipóteses pré-formuladas e nem dificultar o surgimento de noções fundamentadas nos dados; a análise e a conceitualização são geradas através de processos intercalados de coleta e análise de dados utilizando a comparação constante; e os códigos são selecionados por um processo de amostragem teórica Protocolo Conforme [Corbin and Strauss 2007], o protocolo deste método consiste em examinar cada documento fornecido, mais de uma vez e independentemente por mais de um pesquisador para evitar viés, buscando identificar unidades de significados para a realização da codificação aberta que, em primeira instância, procura estabelecer categorias conceituais. Neste passo, é necessário consenso entre os pesquisadores. Em segunda instância, são identificados os relacionamentos entre as categorias conceituais para a realização da codificação axial. Nesta etapa, é necessário definir uma lógica de associação entre as categorias. Para tanto, o método de comparação constante é empregado, trabalhando para frente e para trás entre as categorias já estabelecidas e os dados originais com o objetivo de identificar fenômenos relacionados, condições causais, contextos, estratégias de ação/interação e consequências das ações para desenvolver categorias nocionais. Gráficos podem ser usados para retratar estas relações. Nesta etapa, também é possível identificar um ou mais fenômenos interessantes (dimensões) dentro da amostragem teórica nos diversos contextos apresentados. Em terceira instância, é realizada a codificação seletiva para identificar a(s) categoria(s) principal(is), existente ou nova, para desenvolver uma narrativa descritiva (teo- 62

70 ria) ao redor dela(s). Em seguida, as interpretações da teoria são validadas e refinadas através de integração teórica, que consiste em relacionar a teoria resultante à outras teorias existentes a fim de gerar confirmações e até formalizações Análise dos Dados Os dados do questionário foram analisados através das etapas de codificação aberta e axial. Para evitar viés, cada pesquisador realizou separadamente a codificação e discordâncias foram discutidas até alcançar consenso. Como só houve uma coleta de dados, a terceira etapa ainda não foi dada como concluída, devido não ter sido atingida a saturação teórica. Mesmo assim, foi aplicada a técnica de identificação de uma categoria principal para extrair a visão dos alunos sobre o curso nesta edição, o que não significa dizer que foi gerada uma teoria, a priori. De posse da continuidade desta pesquisa, esta visão dos alunos é de grande utilidade para auxiliar na definição das próximas coletas e análises de dados intercaladas, que, consequentemente, culminem na geração de uma teoria fundamentada nos dados Codificação Aberta Nesta etapa foram utilizados códigos in vivo [Corbin and Strauss 2007], ou seja, baseados na terminologia usada pelos informantes. A codificação aberta resultou em uma matriz de 33 categorias conceituais, com exemplos de unidades de significado dos dados originais e quantidade de ocorrências (#). Por motivos de espaço, a Tabela 1 exibe apenas algumas das categorias conceituais extraídas nesta etapa 3. O texto sublinhado é uma prévia de relacionamento entre categorias conceituais e é explicado na seção seguinte. Como GT estabelece a necessidade de coletas e análises intercaladas, e neste estudo só houve uma coleta de dados, ainda não foi possível validar as categorias conceituais. Table 1. Algumas categorias conceituais selecionadas da codificação aberta Id Categoria Conceitual Exemplo de Unidade de Significado # 1 Programação em Pares Trabalho em pares facilita aplicação de boas práticas e evita bugs. Além de promover que mais de uma pessoa saiba de todas as partes do código 2 Produtividade Aprendemos a programar com mais agilidade (em termos de prática e qualidade) 3 Qualidade de Código A meta de 100% de cobertura de testes e familiarização com novas tecnologias (Rails) foram coisas que achei que deram certo, com isso também conseguimos desenvolver novas funcionalidades com codigo melhor 4 Trabalho em Equipe Aprendi a interatuar com o pessoal para trabalhar em colaboração 53 5 Novas Tecnologias O aprendizado de muitas novas tecnologias e ferramentas Codificação Axial No início desta etapa, os relacionamentos explicitados pelos alunos foram sublinhados (Tabela 1). Em seguida, utilizou-se um gráfico para ajudar na visualização destes rela- 3 Para visualizar detalhes da codificação aberta e a lista de categorias conceituais, acesse vsantos/pesquisa1/ 63

71 cionamentos e na definição da lógica destas ligações para gerar categorias nocionais. Por motivos de espaço, a Figura 1 apresenta o grafo resultante minimizado com os agrupamentos existentes separados por cores 4. Primeiramente foram identificados os cliques 5, depois os ciclos 6 e por último, as ligações simples. Houve categorias, como por exemplo, Carga Horária do Curso, que se relacionaram através de ligações simples com diferentes categorias - Compartilhamento do Conhecimento, Novas Tecnologias e Teoria sobre XP - no entanto, os autores escolheram agrupá-la à categoria que possuía maior relevância dentro do contexto, buscando estar sempre fundamentada nos dados. Vários casos de relacionamento não resultaram em agrupamento, devido a força da ligação encontrada nos relatos de determinadas categorias. Apó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 agrupamento, as categorias conceituais relacionadas, com seus respectivos identificadores à esquerda, seguidas pelo nome e pela quantidade de ocorrências entre parênteses. A Figura 1 mostra o grafo resultante com as cores e o Id referente ao agrupamento das categorias. Figure 1. Relação entre as categorias conceituais Para facilitar o entendimento de cada categoria nocional gerada pelos relacionamentos de categorias conceituais, a narrativa em torno delas é descrita conforme a seguir. No Jogo do Planejamento, o envolvimento do Cliente favorece a efetividade da Reunião de Planejamento, facilitando o entendimento das Histórias e o projeto da solução nas Reuniões Técnicas da Equipe na busca de gerar valor incremental em Iterações Curtas. Na categoria Refatoração e Testes, os Testes influenciam na manutenção do código e propiciam a coragem para realizar Refatoração. Na categoria Fatores Tecnológicos, o risco da adoção de Novas Tecnologias no projeto influenciou na Produtividade da equipe, na Qualidade de Código e na aplicação de Padrões de Projeto, o qual foi atenuado com Dojo e Superparing. Já na categoria Comunicação e Feedback, o envolvimento da equipe na 4 O grafo em tamanho original também está disponível em vsantos/pesquisa1/ 5 Clique é um subgrafo completo que para cada vértice há uma aresta conectando este vértice a cada um dos demais. 6 Ciclo é um caminho que começa e acaba com o mesmo vértice. 64

72 Table 2. Categorias nocionais resultantes da codificação axial Id Categoria Nocional Categorias Conceituais Relacionadas 1 Jogo do Planejamento (verde) 9) Cliente (30) 10) Reunião de Planejamento (1) 12) Retrospectivas (11) 13) Histórias (25) 23) Reuniões Técnicas da Equipe (8) 25) Iterações Curtas (15) 2 Boas Práticas de Programação (roxo) 31) Boas Práticas de Programação (5) 3 Refatoração e Testes (laranja) 6) Testes (24) 33) Refatoração (8) 4 Comunicação e Feedback (rosa) 1) Programação em Pares (24) 4) Trabalho em Equipe (53) 8) Ambiente Informativo (8) 11) Comunicação (13) 17) Tracking (27) 18) Horários do Curso (4) 19) Almoço (9) 22) Papo em Pé (3) 26) Estimativas (21) 30) Comprometimento (5) 5 Fatores Tecnológicos (amarelo) 2) Produtividade (10) 3) Qualidade de Código (6) 5) Novas Tecnologias (63) 27) Dojo e Superparing (4) 32) Padrões de Projeto (2) 6 Forma do Curso (azul) 14) Carga Horária do Curso (29) 15) Teoria sobre XP (24) 20) Avaliação (6) 28) Envolvimento do Professor e dos Meta-Coaches (8) 7 Formas de Interação (cyan) 7) Ambiente (9) 21) Reunião de Coaches (5) 24) Compartilhamento de Conhecimento (8) 29) Coach (18) 8 Ambiente de Desenvolvimento (vermelho) 16) Ambiente de Desenvolvimento (10) Programação em Pares, no Papo em Pé, na definição de Estimativas, no Almoço, na atualização do Ambiente Informativo e dos gráficos de Tracking, favorecem a Comunicação, o Comprometimento e a pontualidade nos Horá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 Horária do Curso, mais Teoria sobre XP e melhor Avaliação. As Formas de Interação entre as equipes não deveriam ocorrer apenas na Reunião de Coaches, devido ao grau de confiança da equipe no Coach, assim, um melhor uso do Ambiente ajuda a intensificar o Compartilhamento de Conhecimento. A categoria Ambiente de Desenvolvimento não se encaixou na lógica utilizada para as categorias anteriores, no entanto, os alunos relataram sua ligaçã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, através da comparação constante, foi identificada uma relação entre duas categorias nocionais. Da mesma forma, a categoria Boas Práticas de Programação também não se ligou fortemente a nenhuma outra categoria a ponto de juntar-se. No entanto, os alunos 65

73 relataram que facilitam o desenvolvimento e a manutenção do código-fonte. Portanto, Boas Práticas de Programação também favorecem o bom andamento do Jogo do Planejamento, influencia na Comunicação e Feedback, nos Fatores Tecnológicos e na Refatoração e Testes. Após a definição das categorias nocionais, conforme o protocolo, o método de comparação constante é aplicado entre as categorias e os dados originais para estabelecer as dimensões das categorias. A Tabela 3 apresenta as dimensões resultantes. Table 3. Dimensões das categorias nocionais Dimensões Id Categoria Nocional Similaridades Diferenças 1 Jogo do Planejamento 2 Boas Práticas de Programação Eficiência gradativa da equipe Reconhecimento do valor da sua aplicação Acompanhamento das deficiências no desenvolvimento Incentivos à sua aplicação 3 Refatoração e Testes Valorização das práticas Grau de dificuldade em aplicar 4 Comunicação e Feedback Eficiência gradativa da equipe 5 Fatores Tecnológicos Valorização dos fatores tecnológicos 6 Forma do Curso Necessidade de maior carga horária, mais teoria e maior acompanhamento Acompanhamento das deficiências no desenvolvimento Nível de experiência em tecnologias de mercado Iniciativa dos alunos 7 Formas de Interação Nivelamento do aprendizado Acompanhamento das deficiências no desenvolvimento 8 Ambiente de Desenvolvimento Necessidade de estar inicialmente apto ao desenvolvimento Experiência em tecnologias de mercado Codificação Seletiva Esta técnica de codificação foi aplicada para extrair a visão dos alunos sobre o curso nesta edição. Isto não implica em teoria, mas em subsídio para as próximas estratégias de coleta e análise intercaladas, e para identificar o que o curso precisa melhorar. Assim, as categorias Jogo do Planejamento, Boas Práticas de Programação, Refatoração e Testes, Comunicação e Feedback, Fatores Tecnológicos, Forma do Curso, Formas de Interação e Ambiente de Desenvolvimento podem ser interpretadas como fatores essenciais ao sucesso do curso. Cada categoria conta parte da história, nenhuma captura-a completamente. Por este motivo, um outro termo ou frase abstrata é necessária, uma idéia conceitual sob a qual todas as categorias são incluídas. Assim, conclui-se que a categoria principal resultante é Formas de Suporte ao Aprendizado de XP. Desta forma, a linha da história para melhorar o curso é a seguinte: O curso Laboratório XP é de grande valor para os alunos, pois proporciona o aprendizado através do desenvolvimento ágil de um projeto de software em um contexto mais próximo da realidade. No entanto, necessita de mais suporte para um aprendizado mais efetivo de 66

74 tecnologias, conceitos e práticas; de contínua avaliação dos alunos; e de reconsideração dos pré-requisitos e da carga horária do curso. 4. Segunda Abordagem: Retrospectiva Final Na última aula do curso foi realizada uma retrospectiva ágil adaptada com todos os participantes objetivando coletar dados e refletir sobre o curso para estabelecer uma visão compartilhada de melhorias necessárias para as próximas edições Metodologia A dinâmica ocorreu em uma sala de aula com sessões de sete minutos para a discussão civilizada de cada tópico. O professor e os meta-coaches gerenciavam e registravam as sessões em um relatório. Havendo necessidade de estender a discussão, outra sessão de sete minutos poderia ser criada, até atingir consenso. Esta dinâmica utilizou uma abordagem disciplinada, devido o grande número de participantes e o pouco tempo para discussão (duas horas-aula). Portanto, foram dispostas cinco cadeiras na frente da sala para que interessados em relatar algo sobre o tópico em discussão na sessão pudessem se sentar e expressar sua opinião, em voz alta. As discussões só poderiam ocorrer entre as pessoas sentadas nas cadeiras. O restante da sala deveria ficar em silêncio, sem nenhuma conversa paralela. Dentre as cinco cadeiras, sempre deveria haver uma cadeira livre para o próximo interessado em discutir sobre o tópico. Portanto, se alguém se sentasse na cadeira vazia remanescente, uma das quatro pessoas sentadas, liberaria a sua própria cadeira, visto que já expôs sua visão. Antes de iniciar as sessões, os alunos sugeriram tópicos para discussão (17 temas). Depois, para cada tema, houve uma votação do número de interessados na sua discussão Resultados Por questões de tempo, foram discutidos os cinco temas mais votados na dinâmica. A Tabela 4 lista os temas com o número de votos entre parênteses, algumas transcrições do relatório e o número de sessões realizadas (#). Sempre que terminava uma sessão, as considerações registradas pelo meta-coach eram lidas e confirmadas ou alteradas pelos participantes até atingir consenso. O relatório, gerado a partir da retrospectiva final, descreve fielmente os pontos tratados na dinâmica. Table 4. Temas abordados na retrospectiva final Id Tema Transcrições do Relatório # 1 Parte teórica (29) Espalhar as aulas permitiria ligar teoria à prática 1 2 Horários da disciplina e dedicação esperada fora dos horários (25) Talvez a disciplina merecesse mais crédito e mais aulas por semana. 3 Aprendizado das tecnologias (16) Necessidade de muitas tecnologias que não eram dominadas (ex: Eclipse, Ruby, Rails, Git etc.) Participação dos meta-coaches e do professor (12) Ter mais proximidade entre o grupo e meta-coaches para ter mais tempo de sentir o que está OK e o que não está 5 Critério de avaliação (10) Falta de feedback com critérios subjetivos deixa tudo largado. Muito difícil melhorar

75 Os pesquisadores também atuaram na dinâmica como observadores participantes do caso em estudo. Mesmo discutindo apenas cinco temas, muitos temas relacionados também foram mencionados. O que permitiu criar uma noção mais clara das necessidades mais urgentes do curso proveniente do que foi expresso na dinâmica. Com a análise do relatório, baseada na experiência dos pesquisadores, é possível concluir que, na visão dos alunos, é necessário mais acompanhamento, apoio e feedback dos responsáveis pelo curso em relação a aprendizagem de XP, das tecnologias envolvidas e de suas deficiências no desenvolvimento do projeto. 5. Conclusão Dentre as duas abordagens estudadas percebe-se que houve uma interseção entre os assuntos tratados. A combinação das abordagens confere triangulação dos resultados. De acordo com a observação dos participantes, os projetos do curso apresentaram complexidades variadas, bem como equipes que conseguiram superar os problemas, outras que superaram parcialmente e outras que não os superaram. Para tanto, como ações de melhoria, são propostas soluções conhecidas, como as dinâmicas de Coding Dojo [Sato et al. 2008], retrospectivas e minipalestras com todos os alunos para incentivar a adoção, o aprendizado e o compartilhamento dos valores, princípios e práticas de XP; para prover a exposição mais detalhada do assunto e para detecção/tratamento das deficiências dos alunos durante o desenvolvimento ágil de software; e para facilitar a preparação do ambiente de desenvolvimento. Outras ações de melhoria são o aumento do número de créditos e, consequentemente, da carga-horária do curso; e a reconsideração da forma de composição das equipes, conforme [Sfetsos et al. 2009] 7, e dos critérios das avaliações periódicas. Além de contar com a teoria da auto-eficácia 8, visto que [Endres et al. 2009] revela que, em ambientes acadêmicos, o compartilhamento do conhecimento em um grupo depende da interação entre auto-eficácia e conhecimento recíproco esperado de seus integrantes. Tendo em vista que o sucesso de um projeto ágil depende do tipo de projeto e da equipe, estes devem ser avaliados continuamente durante o curso para proporcionar o suporte necessário às dificuldades enfrentadas. Este estudo corresponde ao início de uma pesquisa mais abrangente sobre melhoria contínua em métodos ágeis. Como não houve saturação teórica, devido a coleta ter sido feita apenas uma vez e ao final do curso, os pesquisadores pretendem utilizar estes resultados preliminares para especificar melhor as próximas coletas (aprimorar o questionário, a amostragem teórica, utilizar outros tipos de coleta, etc.) e análises intercaladas durante o curso para confirmar ou refutar os resultados. Os autores também consideram construir um repositório de experiências descrito conforme [Meng et al. 2007] e aplicar técnicas de Aprendizagem Organizacional [Argyris and Schon 1978] para identificar formas efetivas de gerar melhorias em organizações ágeis. 7 O autor declara que equipes ágeis mais eficazes são aquelas que consideram a heterogeneidade dos seus integrantes, confirmando a prática XP de time completo (Whole XP Team) [Beck and Andres 2004] 8 A teoria da auto-eficácia explica que o nível de confiança do indivíduo em suas habilidades é um forte motivador para a realização de uma determinada tarefa [Bandura 1997]. 68

76 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 Explained: 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). Manifesto for agile software development. Available at: org/. [Corbin and Strauss 2007] Corbin, J. and Strauss, A. C. (2007). Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory. Sage Publications, Inc, 3rd edition. [Dybå et al. 2010] Dybå, T., Dingsoyr, T., and Moe, N. B. (2010). Agile Software Development - Current Research and Future Directions. Springer, 1st edition. [Endres et al. 2009] Endres, M. L., Chowdhury, S., and Rhoad, K. (2009). Effects of student task self-efficacy and expected reciprocity on intent to share knowledge. Paper 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 pattern language for agile methods. In APSEC 07: Proceedings of the 14th Asia-Pacific Software Engineering Conference, pages , Washington, DC, USA. IEEE Computer 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: [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): [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 information systems. Information Systems Journal, 20: (25). 69

77 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) Porto Alegre RS Brasil 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 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 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

78 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

79 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 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 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 , 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) Brazil Estados Unidos Europa GMT Tabela 1. Horário durante o inverno brasileiro Brazil Estados Unidos Europa GMT 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

80 3. Metodologia de Pesquisa Este estudo foi conduzido entre Janeiro e Julho de 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

81 Local de interação EUA EUA EUA Europa Europa Canadá Canadá, Tipo de empresa Canadá Ásia Europa Europa Multinacional Brasileira Total 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 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

82 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 Unidos e 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 s 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 Nível 2 Nível 3 Nível 4 Comunicação assíncrona, cultura tradicional, uso esporádico de comunicação síncrona Uso de instant messaging, uso de tecnologia padrão para comunicação, vídeo usado de forma esporádica Estado da arte em tecnologia de colaboração, ferramentas de suporte a awareness 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

83 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 fusohorário significa que algumas empresas brasileiras podem acabar mantendo um processo de desenvolvimento imperfeito 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

84 - 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 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 brasileiras já 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 fusohorá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

85 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 AT Kearney, Maio ATKearney, Destination Latin America: A Near-Shore Alternative, Relatório de pesquisa, 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 , Relatório de pesquisa, 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, 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, Peres, M. (2009). O Mercado de Serviços Offshore Brasileiro em 2008, capturado em Maio Prikladnicki, R., Audy, J. L. N., Shull, F., Patterns in Effective Distributed Software Development," IEEE Software, 27-2, Mar-Abr 2010, pp Seaman, C. B. Qualitative Methods in Empirical Studies of Software Engineering, IEEE Transactions on Software Engineering, 25 (4), 1999, pp 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, p Stefanuto, G. N., de Carvalho, R. Q., Perfil das Empresas Brasileiras Exportadoras de Software, Relatório de pesquisa, Softex, Strauss, A., Corbin, J., Pesquisa Qualitativa Técnicas e Procedimentos para o Desenvolvimento de Teoria Fundamentada, Editora Bookman, Suddaby, R., From the Editors: What Grounded Theory is Not, Academy of Management Journal, 49 (4), pp ,

86 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? ? 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 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

87 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 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 o aumento 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

88 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

89 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 norteamericano, 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 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 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: 82

90 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 projetos da 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. Variáveis Independentes Tabela 1 Variáveis e Escalas Experiência em OO Tempo de experiência profissional anterior em Orientação a Objetos 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 Escala Nenhuma, 1-6 Meses, 7 Meses - 2 anos, 3 a 5 anos, 6-9 anos, 10 ou + anos 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

91 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 ), 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 é 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

92 Práticas de XP Reuniões diárias Programação em Pares promovem EXPERIÊNCIA PRÉVIA LEARNING-BY- DOING FEEDBACK CONSTANTE aceleram APRENDIZADO aumenta (Arrow 1962, Boh et al. 2007) TDD COMUNICAÇÃO PRODUTIVIDADE Temas identificados 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 de projetos 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) 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

93 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 G * 2. Experiência na Arquitetura G Experiência em projetos G * 4. Aceleração do Aprendizado (com métodos ágeis) 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

94 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-bydoing. 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

95 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

96 Agradecimentos Os autores agradecem o apoio financeiro recebido da Fapesp (processo 09/ ). 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, Arrow, K. (1962) The economic implications of learning by doing. Review of Economic Studies 29, 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 Learning from Experience in Software Development: A Multilevel Analysis. Manage. Sci. 53, 8 (Aug. 2007), 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: 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 (2008). Drobka, J., Noftz, D., Raghu, R.. (2004), "Piloting XP on Four Mission-Critical Projects," IEEE Software, pp , 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): 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 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: Law, A. and Charron, R 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 June, Nerur, S. and Balijepally, V. (2007). Theoretical reflections on agile development methodologies. Communications of the ACM 50, 3 (Mar. 2007), 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 Learning by Doing Something Else: Variation, Relatedness, and the Learning Curve. Manage. Sci. 49, 1 (Jan. 2003), Tashakkori, A. and Teddlie, C. (2003) Handbook of mixed methods in social & behavioral research. Sage Publications. VersionOne (2009). State of Agile Development 4 th annual survey. 89

97 TECHNICAL SESSION 3 Experimental Studies (ES) 90

98 Resultados de um estudo de caracterização e avaliação de critérios de teste estruturais entre os paradigmas procedimental e OO Marllos Paiva Prado 1, Simone do Rocio Senger de Souza 2, José Carlos Maldonado 2 1 Instituto de Informática Universidade Federal de Goiás P.O Goiânia, GO Brasil Instituto de Ciências Matemáticas e de Computação Universidade de São Paulo P.O. 668 São Carlos, SP Brasil 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. Introdução Uma das principais finalidades da atividade de teste de software é descobrir erros durante o seu desenvolvimento. Esta atividade contribui para redução do custo de manutenção e para a melhora da qualidade do software. Isso tem motivado a investigação e proposta de estratégias, técnicas, critérios e ferramentas de teste para diferentes paradigmas de desenvolvimento tais como procedimental, orientado a objetos (OO) e orientado a aspectos. O paradigma de desenvolvimento constitui-se em um dos alicerces para o desenvolvimento de sistemas computacionais uma vez que define a construção das estruturas que compõe o software de diferentes formas. O uso de um determinado paradigma implica em diferenças desde a forma de se abstrair e representar essas estruturas [Takashi et al. 1990] até o processo e tecnologias empregados [Pressman 2002]. Neste contexto, os paradigmas procedimental e o OO destacam-se como os dois principais utilizados na prática do desenvolvimento de software atual. A existência de particularidades e a diferença no modo de entender os problemas imposta pelos paradigmas, fornecem indícios da possível existência de diferentes fontes de erros na composição do software, em razão dos mesmos [Vincenzi et al. 2007]. Técnicas e critérios de teste têm sido propostos como forma de minimizar a presença de erros no software, por meio da definição de casos de teste que aumentem a probabilidade de identificar os mesmos. Dentre as principais técnicas de teste propostas, destacam-se as técnicas funcional, estrutural e baseada em erros. Cada uma dessas técnicas envolve um conjunto de critérios sendo que a principal característica que as distingue consiste na fonte de informação utilizada para definir os requisitos de teste. A comparação entre técnicas e critérios de teste é realizada utilizando-se algumas propriedades de teste. Dentre as mais importantes, citam-se o custo, eficácia e dificuldade de satisfação (strength). 91

99 Grande parte dos estudos experimentais realizados até o momento, para avaliar e comparar critérios de teste, foram realizados com programas implementados sob um mesmo paradigma ou desconsiderando a influência do mesmo sobre os resultados [Juristo et al. 2004]. Contudo, é importante avaliar o impacto do paradigma sobre a atividade de teste uma vez que alguns defeitos podem estar relacionados ao seu uso. A condução de um experimento controlado ou mesmo um quasi-experimento, em geral, é uma atividade cara e que exige muitas prerrogativas para sua execução. Um dos grandes problemas enfrentados pelos pesquisadores, durante a realização de novos estudos experimentais em teste de software é a falta de uma infra-estrutura de materiais, ferramentas e resultados adequadamente preparados, para serem usados como recurso ou embasamento do novo experimento. Essa não é uma preocupação nova e esforços nesse sentido podem ser constatados em [Rothermel 2005]. Nesse trabalho os autores fazem um survey de vários artigos com resultados experimentais sobre técnicas de teste, reportando as dificuldades encontradas na condução dos mesmos. Em resposta a esses obstáculos, os autores apresentam uma infra-estrutura a qual, em suma, é constituída de programas, versões, casos de teste, defeitos e scripts já estabilizados e que estariam prontos para realização e replicação de experimentos controlados. Além da preocupação com a definição de novos experimentos em teste de programas, em [Myers et al. 2004], nota-se preocupação com o ensino da atividade de teste desde o aprendizado da própria prática de programação. Segundo o autor, esta medida seria uma forma de habituar os alunos desde cedo à realização dos testes juntamente com o desenvolvimento do programa, de uma forma sistemática e integrada. Sendo assim, o objetivo deste trabalho foi conduzir um estudo experimental em teste de software, comparando critérios de teste estruturais aplicados a um conjunto de programas de um determinado domínio, implementados nos paradigmas OO e Procedimental. 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 dificuldade de satisfação (strength) de critérios de teste funcionais e estruturais para programas nos paradigmas procedimental e OO; ii) Colaborar com a definição de futuros experimentos e pacotes de laboratório. Para tanto, buscou-se a consolidação de um conjunto de critérios, ferramentas, programas e resultados que caracterizassem o domínio investigado, viabilizando a replicação/ampliação de novos estudos experimentais com base nos resultados e materiais gerados; iii) Desenvolver um arcabouço de artefatos que pudessem ser reaproveitados no contexto de treinamento e capacitação em testes. Sendo assim, uma das conseqüências desse objetivo foi a escolha do domínio de estrutura de dados para seleção dos programas a serem utilizados na investigação do trabalho. Essa decisão teve como objetivo ampliar a gama de problemas envolvidos com cada solução testada, viabilizando ao aluno situações diferentes para a aplicação de cada técnica e atrelando o aprendizado de testes às fases iniciais do ensino de programação e desenvolvimento de software. O artigo está estruturado da seguinte forma. Na Seção 2, a definição e o planejamento do estudo experimental são resumidamente descritos. Na Seção 3, os principais elementos da condução do experimento são apresentados. Na Seção 4 a análise realizada sobre os dados coletados é apresentada bem como os resultados alcançados com a realização desse trabalho. A seção 5 apresenta as conclusões e perspectivas de trabalhos futuros. 2. Definição A definição do estudo seguiu o template Goal Question Metric [Briand et al. 1996] e é apresentado na tabela 1. 92

100 Objeto de Estudo Propósito Foco de Qualidade Perspectivas Contexto Os objetos de estudo são os critérios de teste funcional e estrutural aplicados no paradigma OO e os critérios de teste funcional e estrutural aplicados no paradigma procedimental. O propósito é caracterizar e avaliar os critérios, em particular com respeito às diferenças entre os paradigmas. O foco de qualidade avaliado é o custo e a dificuldade de satisfação dos critérios nos dois paradigmas. A perspectiva do experimento é do ponto de vista de pesquisadores. A investigação será conduzida pelo próprio pesquisador que definiu o estudo, sobre um conjunto de programas de estrutura de dados. O estudo é conduzido na forma de um estudo de variação Multi-Objeto, ou seja, um participante operando sobre um conjunto de objetos. Tabela 1. Definição do experimento. O contexto do experimento foi caracterizado como sendo um estudo off-line, conduzido por um estudante de mestrado, abordando um problema real (identificação e comparação de custos e strength de critérios de teste), em um contexto específico Formulação das Hipóteses O estudo proposto buscou delimitar características acerca de um assunto ainda desconhecido, a procura de evidências que pudessem ser usadas na definição de futuras hipóteses. Sendo assim, as hipóteses propostas não pretendem ser definitivas, mas foram estabelecidas em caráter pragmático com o intuito de viabilizar a continuidade do trabalho dentro do processo adotado. Admitindo-se que os custos dos critérios de teste sobre um conjunto de programas sejam medidos em termos do tamanho do conjunto de teste e do número de elementos requeridos e que esses sejam influenciados principalmente: (i) pelo paradigma de desenvolvimento em que são implementados; (ii) pelas ferramentas de teste usadas; (iii) pelos tipo de crité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 programação representam formas distintas de se entender e estruturar uma mesma solução, acredita-se que exista uma diferença de custo entre os conjuntos A e B, em razão das diferenças de paradigmas. Da mesma forma que os custos, admitindo-se que o strength de cada critério de teste funcional e estrutural entre dois paradigmas seja medido em termos da porcentagem de adequação do conjunto de teste adequado a esse critério em um paradigma sobre o mesmo critério no paradigma oposto e vice-versa, e sabendo-se que os paradigmas de programação procedimental e OO representam formas distintas de se entender e estruturar uma mesma solução, acredita-se que exista uma diferença de strength entre os conjunto A e B (mesmos da hipótese anterior), em razão da diferença de paradigma. As hipóteses formais do estudo encontram-se enunciadas na tabela 2. Primeira Hipótese Hipótese Nula: Não existe diferença de custo dos critérios de teste, em razão do paradigma, entre o conjunto A (procedimental) e B (OO). H0 : Custo(A) = Custo(B) Hipótese Alternativa: Existe uma diferença de custo dos critérios de teste, em razão do paradigma, entre o conjunto A (procedimental) e B (OO). H1 : Custo(A) Custo(B) Segunda Hipótese Hipótese Nula: Não existe diferença de strength dos critérios de teste, em razão do paradigma, entre o conjunto A (procedimental) e B (OO). H0 : Strength(A) = Strength(B) Hipótese Alternativa: Existe uma diferença de strength dos critérios de teste, em razão do paradigma, entre o conjunto A (procedimental) e B (OO). H1 : Strength(A) Strength(B) Tabela 2. Hipóteses do experimento. À esquerda, hipóteses nula e alternativa relativas ao custo. À direita, hipóteses nula e alternativa relativas ao strength. 93

101 Variáveis Independentes Variável independente é toda variável que pode ser manipulada ou controlada no processo de experimentação. Seguindo essa perspectiva, as principais variáveis independentes desse estudo foram: i) Paradigma em que os programas estão implementados; ii)ferramentas de teste usadas; iii) Critérios de teste empregados; iv) Tamanho e complexidade dos programas sob teste; v) Habilidade do testador na aplicação dos critérios. Apesar de existirem todas essas variáveis independentes, a única considerada de interesse para a investigação é o paradigma em que os programas estão implementados, constituindo-se como o único fator de interesse do experimento. Esse fator, possui dois tratamentos: paradigma de implementação OO e paradigma de implementação procedimental. As demais variáveis foram fixadas no experimento para não interferirem nos efeitos obtidos Variáveis Dependentes As variáveis dependentes são aquelas nas quais é observado o resultado da manipulação das variáveis independentes. No caso desse estudo, as variáveis dependentes definidas para descrever os custos dos critérios foram: i) Número de Elementos Requeridos/Programa; ii) Número de Casos de Teste/Programa; iii) Número de Elementos Requeridos Não-Executáveis/Programa; iv) Número de Elementos Requeridos/Critério; v) Número de Casos de Teste/Critério; vi) Número de Elementos Requeridos Não- Executáveis/Critério. As medidas por programa correspondem àquelas feitas para cada programa, durante a aplicação de um critério, em um determinado paradigma e as medidas por critério, correspondem àquelas feitas para todos os programas, durante a aplicação de um critério em um determinado paradigma. As variáveis dependentes definidas para descrever o strength dos critérios foram: i) Porcentagem de Cobertura/Programa no paradigma oposto. ii) Porcentagem de Cobertura/Critério no paradigma oposto. Em adição às variáveis dependentes citadas, algumas outras métricas foram definidas e coletadas no estudo. O objetivo dessa coleta foi registrar propriedades que pudessem ser relevantes e que estivessem correlacionadas ao comportamento das variáveis dependentes, descrevendo mais detalhes do cenário dos testes funcionais e estruturais, com relação à diferença de paradigma. Essas métricas podem ser ainda reaproveitadas no contexto de futuros estudos experimentais, tanto para a derivação de novas hipóteses a partir das informações por elas fornecidas, quanto para comparação de dados de teste provenientes de programas cujas medidas se assemelhem às dos programas que compõe este estudo. Desta forma, um total de doze métricas de implementação foram definidas. A saber: total de unidades (procedimentos/métodos e construtores); total LOC (linhas de código s/ comentários); total de comandos de desvio; total de comandos recursivos; total unidades sem parâmetros; total de unidades c/ parâmetros apenas do tipo primitivo; total de unidades c/ parâmetros apenas do tipo abstrato (valor ou referência); total de unidades c/ parâmetros mistos (primitivos e abstratos); total de unidades sem retorno; total de unidades c/ retorno do tipo primitivo; total de unidades c/ retorno do tipo abstrato(valor ou referência) e complexidade ciclomática (McCabe) Design do Experimento O design do experimento tem impacto direto sobre a forma de analisar os resultados. Um design experimental adequado também serve para minimizar a influência de fatores adversos sobre os resultados obtidos. 94

102 Conforme estabelecido anteriormente, o estudo contém apenas um fator de interesse, ou seja, o paradigma das implementações testadas, o qual pode assumir dois tratamentos: procedimental ou orientado a objeto. Com relação às demais variáveis independentes fixas, foram aplicados os seguintes princípios de design, visando a redução da probabilidade de erro experimental dentro do contexto definido: Aninhamento dos critério de teste: Diferentes critérios de teste implicam em maneiras distintas de se determinar os custos e strengths em cada paradigma. Para resolver essa questão os critérios de teste foram agrupados em três níveis (funcional, estrutural fluxo de controle e estrutural fluxo de dados) dentro de cada paradigma, seguindo o princípio de aninhamento. Os critérios que compõem o nível funcional são critério Particionamento por Classe de Equivalência e critério Análise Valor Limite. Os critério escolhidos para compor o nível Estrutural Fluxo de Controle são critério Todos-Nós e critério Todas-Arestas. Os critério escolhidos para compor o nível Estrutural Fluxo de Dados são critério Todos-Usos e critério Todos-Potenciais-Usos. Esse princípio permite que cada nível seja avaliado separadamente dentro de cada tratamento, possibilitando uma comparação efetiva de condições (níveis) similares entre os dois paradigmas. Ao fator Paradigma denomina-se fator aninhador e ao fator Critério de teste fator aninhado. Esse design foi preferido em relação ao cruzado (crossed design), já que ele permite a comparação dos paradigmas em relação a um mesmo tipo de critério, sem implicar na análise inversa (característica do design cruzado), ou seja, também comparar os critérios em relaçã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 são testados em um determinado paradigma e que a rotina neste lhe favoreç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 é aninhada a cada nível do critério, já que a estratégia de teste definida para geração dos conjuntos de teste é incremental e, portanto, existe uma relação de interdependência com relação ao conjunto de teste entre os critérios. Para as demais variáveis independentes fixas não foi aplicado nenhum princípio de design. A variá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 aplicação dos critérios funcionais e estruturais respectivamente [Sommerlad and Graf 2007, Chaim 1991]. No paradigma OO, JUnit e Ja- BUTi representam na mesma ordem, as ferramentas para aplicação dos critérios de teste [Riehle 2008, Vincenzi et al. 2003]. Apesar de não serem as mesmas ferramentas aplicadas nos dois paradigmas, existe uma grande semelhança quanto à forma de operar e às assertivas empregadas. Além disso, ambas as ferramentas de teste estrutural apóiam os critérios de interesse para o estudo. A especificação dos programas que compõem o conjunto procedimental é a mesma dos programas que compõem o conjunto OO. Além disso, ambos os conjuntos estã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 critérios de forma incremental, ou seja, o conjunto de teste gerado para o nível funcional foi reaproveitado na construção do conjunto de teste estrutural fluxo de controle e assim sucessivamente. Com isso, foi necessário organizar uma estratégia de teste que viabilizasse essa condução de forma sistemática, obedecendo o design experimental definido. 95

103 A estratégia de teste definida foi dividida em quatro seções principais. Na primeira seção, definiu-se que seria gerado o conjunto de teste adequado aos critérios funcionais. Este conjunto de teste foi derivado da especificação e portanto, deveria adequar-se aos critérios de teste funcionais tanto para a implementação procedimental quanto para a implementação OO do programa. Este constituiu o conjunto base para definição do conjuntos de teste na seção seguinte e o número de elementos requeridos nessa fase foi determinado em termos do número de classes de equivalência e valores limites gerados. Na seção seguinte foi avaliada a cobertura do conjunto adequado ao primeiro nível para o segundo nível de critérios, ou seja, para o nível dos critérios estruturais fluxo de controle. As porcentagens de cobertura atingidas nos dois paradigmas foram anotadas no formulário de testes de cada implementação e em seguida foi feita a adequação dos conjuntos de testes e a determinação dos elementos requeridos não-executáveis para os critérios estruturais deste nível. O conjunto de teste adequado obtido na segunda seção serviu para realimentar os teste estruturais fluxo de dados na terceira seção. Da mesma maneira, as porcentagens de cobertura atingidas nos dois paradigmas foram anotadas no formulário de testes de cada implementação e em seguida foi feita a adequação dos conjuntos de testes e a determinação dos elementos requeridos não-executáveis para os critérios deste nível. Na quarta e última seção, os conjuntos de teste adequados gerados na segunda e terceira seção foram convertidos na linguagem do paradigma oposto para verificação do strength dos dois tipos de teste estrutural, por meio da anotação da porcentagem de cobertura obtida Instrumentação A instrumentação do estudo foi elaborada em várias etapas, de forma a suprir as três categorias de artefatos requeridos para operação do experimento: objetos do experimento, guidelines e instrumentos de medida. A primeira categoria consiste do benchmark de programas aos quais foram aplicados os tratamentos do experimento. Os programas que compõ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 propósito acadêmico, esses programas precisaram de alguns ajustes para aproveitamento no estudo. Um dos motivos foi a incompatibilidade e/ou ausência de especificações em um formato apropriado para os testes e independente para cada programa. O outro motivo, foi a eventual incompatibilidade das implementações entre os dois paradigmas, quanto às funções: algumas operações implementadas na linguagem OO simplesmente não existiam ou eram diferentes daquelas implementadas na linguagem procedimental, apesar de se referirem à mesma especificação. Devido a isso, houve a necessidade de preparar previamente esses programas seguindo alguns procedimentos pré-estabelecidos no plano do experimento. Além disso, as especificações foram reescritas em um formato padrão, pré-definido. Esse formato de especificação foi derivado e adaptado do empregado no pacote de laboratório de [Basili et al. 2008]. Grande parte dos textos das especificações basearam-se no texto original dos livros [Ziviani 2005b] e [Ziviani 2005a]. Esses textos foram modificados ou adaptados, conforme cada caso, para suprir estritamente as necessidades de operação do estudo (como desvinculamento da descrição de uma especificação com algum código-fonte exemplo e remoção de dependências entre os textos de especificações distintas). Esta medida foi tomada com o intuito de interferir o mínimo possível sobre o conteúdo do texto original e ao mesmo tempo atender às necessidades impostas pelo princípio de aleatoriedade dos testes, conforme definido no design experimental. 96

104 A aplicação dos tratamentos no experimento exigiu outros documentos que auxiliassem na execução dos testes, além das especificações. Para tanto foi concebido um documento de implementação, de forma a suprir o testador das informações necessárias para a construção dos casos de testes funcionais (como parâmetros de entrada e tipos de retorno esperados por operação) sem que fosse necessária a leitura do código-fonte completo. Além dos documentos de especificação e implementação, dois formulários foram definidos para aplicação dos testes: o primeiro é um formulário auxiliar para definição das classes de equivalência, durante os testes funcionais. O segundo formulário (formulário de testes), serviu para registrar os casos de teste para cada critério avaliado e as medidas de teste auferidas. A instrumentação do estudo-experimental conta ainda com os códigos-fontes dos programas em linguagem C e Java, as ferramentas de teste e um documento de guidelines. 3. Preparação da Condução do Estudo A preparação da operação do estudo se deu a partir da própria definição do plano. Tendose definido os documentos e formulários para execução dos testes prosseguiu-se com a adequação e configuraçã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 condução dos testes. Como uma das finalidades do estudo era viabilizar a definição de futuros estudos experimentais e treinamento em teste, julgou-se adequado instalar e configurar as ferramentas de forma que elas pudessem ser facilmente reaproveitadas em novos contextos sem a necessidade do retrabalho e mantendo-se alguma garantia de um funcionamento estável. Usualmente, para este fim, especifica-se as versões e os requisitos de sistema para replicação de estudos com ferramentas. Contudo, muitas vezes isso não é o suficiente para eliminar dificuldades com sua instalação/configuração e não diminui a chance de interferência por alguma configuração extra além dos requisitos exigidos. A partir dessa necessidade, surgiu-se a idéia de definir uma máquina virtual, sobre a qual essas ferramentas pudessem ser agrupadas e configuradas para uso direto. Dentre os benefícios encontrados com essa prática podem-se citar: a portabilidade não só das ferramentas e do sistema operacional mas de toda uma configuração de sistema específica, a possibilidade de replicação e geração de backup de forma prática e relativamente rápida, a viabilidade de evolução de configurações de ferramentas sem o comprometimento de uma configuração já estável, a possibilidade de interrupção e continuação de uma tarefa em datas diferentes mantendo-se o mesmo estado do sistema operacional e dos programas utilizados e a persistência direta dos resultados gerados internamente pela cópia em uso. 4. Análise A análise dos dados foi realizada em duas fases. A primeira consistiu em apresentar todas as medidas para cada tipo de métrica considerada no estudo e juntamente com as medidas de tendência central relativas, obter informações que pudessem ser analisadas pontualmente, caracterizando o contexto dos programas e dos conjuntos de teste envolvidos. Na segunda fase uma abordagem mais rigorosa foi empregada, para verificação das hipóteses definidas no plano. A aplicação dos testes para verificação das hipóteses definidas no plano foi precedida de um teste de ajustamento para verificação da normalidade da distribuição amostral das variáveis a serem utilizadas na verificação das hipóteses. Para este fim empregou-se o teste de Shapiro-Wilk [Conover 1998], adeqüado ao tamanho da amostra considerada. O teste revelou uma distribuição não normal dos dados amostrais 97

105 para as variáveis relacionadas às duas hipóteses investigadas, apontando a necessidade de aplicação de um teste não-paramétrico para a verificação das hipóteses. O teste não paramétrico adotado foi o teste de Wilcoxon [Hollander and Wolfe 1999]. A aplicação desse teste foi feita em duas etapas para cada uma das duas hipóteses consideradas. Essa medida foi tomada visando atender o design experimental que subdividia os critérios em dois níveis. Na verificação da primeira hipótese, foi revelada uma discrepância entre os resultados para os critérios no nível de fluxo de controle e no nível de fluxo de dados, não rejeitando para o primeiro nível e rejeitando para o segundo nível. Essa dualidade foi resolvida retomando-se a análise pontual dos dados, feita na primeira parte da seção de análise. Nesta, as observações feitas sobre a média, desvios padrões, valores mínimos e máximos indicavam na direção da não rejeição da hipótese nula em ambos os níveis. Além disso, o valor da probabilidade de significância que rejeitou o teste de hipótese no segundo nível, por estar muito próximo ao nível de significância adotado, também foi considerado para questionamento dessa rejeição. A verificação da segunda hipótese, relacionada à diferença de strength entre os paradigmas, não apresentou discrepância entre os níveis, não conseguindo rejeitar a hipótese nula tanto no nível fluxo de controle quanto no nível fluxo de dados. Logo, a análise pontual e estatística dos dados permitiram concluir que não é possível afirmar que exista uma diferença de custo e de strength, em razão dos paradigmas, tanto para critérios estruturais de fluxo de controle quanto para critérios de fluxo de dados, considerando-se o domínio de programas investigados e o contexto no qual a investigação foi realizada. Isso significa que ainda que não se tenha conseguido demonstrar a existências dessas diferenças nesta investigação, novos estudos experimentais futuros devem ser realizado, considerando-se um contexto mais amplo de programas, linguagens e participantes. Esses estudos poderiam fornecer mais evidências a favor da aceitação das hipótese nulas, ou ainda, revelar outros domínios em que os dados forneçam evidências suficientes para refutá-las. De qualquer forma, a realização desses novos experimentos poderá agora, ser amparada pelos artefatos gerados nesse trabalho e seus resultados e conclusões, comparados com os já obtidos. 5. Conclusões e Trabalhos Futuros A realização deste estudo experimental permitiu comparar custo e strength de critérios de teste estruturais aplicados a programas do paradigma procedimental e orientado a objetos, no domínio de estrutura de dados. A finalidade da investigação foi prover resultados iniciais na área sobre essa questão, uma vez que nenhum trabalho com tal finalidade havia sido realizado ainda. Conforme discutido anteriormente, a atividade e os resultados de teste estão sujeitos à influência de diversos fatores, dentre eles o paradigma de desenvolvimento adotado e o domínio de programas considerados. Para se avaliar essas questões, além do conhecimento de testes, a realização de estudos experimentais considerando-se os termos e processos da engenharia de software experimental se faz necessária. Para o planejamento, condução e análise do estudo, foram empregados os termos e processos utilizados na experimentação controlada, à medida em que estes se mostraram apropriados. Para tanto, foram utilizados: O template GQM para estabelecimento do contexto da investigação; A escolha das variáveis independentes, dependentes e a definição das hipóteses de interesse para o estudo; Além das variáveis, foi considerada a coleta de 12 métricas 98

106 de implementação, para caracterização de propriedades estáticas dos programas envolvidos no estudo. A elaboração de um design experimental que refletisse os propósitos comparativos analisados; O design em questão aplica os princípios de aninhamento, balanceamento e randomização, sobre os fatores envolvidos no estudo. A análise de questões de validade interna, externa, de construção e de conclusão, relacionadas ao tipo de estudo considerado; A instrumentação adequada para construção e utilização dos artefatos necessários à condução do estudo. Dentre os artefatos desenvolvidos constam: A definição dos próprios templates dos documentos e formulários empregados no estudo; 32 documentos de especificação, relativos a cada programa testado no estudo; 32 programas C e 32 programas Java, correspondentes às implementações procedimental e OO de cada especificação; 1 documento de implementação para disponibilização das métricas de implementação e auxilio na realização dos testes funcionais, correspondente a cada uma das implementações envolvidas; 1 formulário para descrição das classes de equivalência de cada especificação, durante a realização dos testes funcionais; 1 formulário de teste para registro textual dos casos de teste e coleta das medidas de teste correspondente a cada uma das implementações. A realização de uma análise estatística sobre os dados, considerando a utilização de testes de hipóteses. A definição de uma máquina virtual, contendo todos os artefatos descritos anteriormente mais as ferramentas, as quais já se encontram instaladas e configuradas para uso. A realização da investigação nesses moldes contribui para a necessidade atual da área de engenharia de software quanto à realização de estudos experimentais com mais rigor científico, aumentando a validade sobre as conclusões obtidas e viabilizando a replicação/ampliação desses estudos em outros cenários. Desta forma, espera-se que o arcabouço de artefatos gerados, a experiência prática adquirida na execução de cada etapa do processo (plano, condução e análise) e os resultados obtidos ao final da investigação, sejam úteis na definição de futuros estudos experimentais na área de testes. Acredita-se ainda que tanto o material gerado quanto os resultados de teste, são úteis no contexto de ensino e treinamento de teste de software, uma vez que foram definidos no domínio de programas de estrutura de dados e considerando este fim. Os resultados obtidos por meio da análise realizada no estudo não forneceram evidências quanto à existência de diferenç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 direção correta com relação à comparação de custos e strength entre os paradigmas considerados, a realização de estudos experimentais futuros considerando um contexto mais amplo de programas, linguagens e participantes se faz necessário. Esses estudos serviriam para aumentar a confiança quanto à não-rejeição das hipóteses nulas verificadas nesse trabalho, fornecendo mais evidencias a favor da aceitação das mesmas ou para encontrar outros domínios em que as evidências sejam suficientes para refutá-las, revelando nesse último caso uma sensibilidade ao contexto considerado. Trabalhos futuros que verifiquem as hipóteses deste trabalho considerando outras técnicas de teste também são oportunos. No âmbito do grupo de pesquisa em que este trabalho foi desenvolvido, outro trabalho de mestrado foi realizado considerando o contexto de análise de mutantes para verificação das mesmas hipóteses. A integração dos resultados e artefatos gerados nos dois trabalhos colaboram para a formação de um corpo de conhecimento sólido envolvendo as três principais técnicas de teste de programas. Mais detalhes a respeito do planejamento, questões de validade, instrumentação, condução e 99

107 análise do estudo estão disponíveis em [Prado 2009]. Referências Basili, V., Green, S., Laitenberger, O., Lanubile, F., Shull, F., Sørumgård, S., and Zelkowitz, 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 Practice, 2(4):253,280. Chaim, M. L. (1991). Poke-Tool uma ferramenta para suporte ao teste estrutural de programas baseados em aná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 Caracterização e Avaliação de Critérios de Teste Estruturais entre os Paradigmas Procedimental e OO. Dissertação de mestrado, ICMC/USP, Sã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 techniques: 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 , New York, NY, USA. ACM. Takashi, T., Liesenberg, H. K. E., and Xavier, D. T. (1990). Programação Orientada a Objetos Uma visão Integrada do Paradigma de Objetos. VII Escola de Computação, São Paulo - SP, 1st. edition. Vincenzi, A. M. R., Domingues, A. L. S., Delamaro, M. E., and Maldonado, J. C. (2007). Introduçã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 Simpósio Brasileiro de Engenharia de Software, pages 79 84, Manaus, AM, Brasil. Ziviani, N. (2005a). Projeto de Algoritmos com Implementações em Java e C++. Thomson. Ziviani, N. (2005b). Projeto de Algoritmos com Implementações em Pascal e C. Thomson, 2nd. edition. 100

108 Reuso de conjuntos de casos de teste no ensino de disciplinas introdutórias de programação Maria A. S. Brito 1, João L. Rossi 1, Simone R. S. de Souza 1, Rosana T. V. Braga 1 1 Instituto de Ciências Matemáticas e de Computação Universidade de São Paulo (ICMC/USP) Caixa Postal 668 CEP: São Carlos - SP Brazil Abstract. This paper presents an experimental study to evaluate the support of test suite to improve the teaching of the introductory class in programming. 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 reference 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 introdutórias de programação como alternativa para aumento na qualidade dos programas gerados pelos alunos. Para reforçar a validade da proposta foi realizado um estudo experimental com o objetivo de investigar o reuso de conjuntos de teste como contribuição ao aumento da qualidade dos programas implementados por alunos. O estudo foi realizado no domínio de manipulação de vetores e de matrizes. Foram gerados conjuntos de casos de teste funcional com base em programas de referência. Os conjuntos de teste foram reutilizados pelos alunos para o teste de programas equivalentes aos programas de referência. Evidências indicam que o reuso de conjuntos de teste pode contribuir para o aumento na qualidade dos programas equivalentes gerados pelos alunos. 1. Introdução O ensino de disciplinas introdutórias de programação difere do ensino de outras disciplinas, pois ensinar programação é antes de qualquer coisa ensinar a resolver problemas, a construir ideias e assim, ensinar o aluno a pensar [Dijkstra 1972]. Muitas vezes, a inexperiência em lógica de programação ocasiona a necessidade do professor despertar no aluno a capacidade para compreensão da lógica existente por trás da mera codificação. No método de ensino tradicional, inicialmente são fornecidas ao aluno as regras (estruturas da linguagem de programação) para que os problemas possam ser 101

109 solucionados. Em seguida, o professor fornece ao aluno a especificação do programa, enquanto espera que o aluno construa um programa capaz de resolver o problema proposto. Nesse caso, o aluno possui apenas a especificação do programa e com base nela deve chegar ao resultado esperado, que é a codificação de um programa correto. Nessa abordagem, o aluno cria e aplica alguns testes os quais julga suficientes e admite que o programa está correto. A partir do estudo apresentado neste artigo, é proposta uma abordagem de ensino em que o aluno recebe do professor a especificação do problema e um conjunto de teste adequado a um programa equivalente ao que será criado. Define-se como programas equivalentes quaisquer dois programas P 1 e P 2, nos quais a mesma saída s 1 resultante do processamento da entrada e 1 para P 1 é obtida para o programa P 2 se considerada a entrada e 1 [Weyuker 1986]. Porém, em programas equivalentes as funcionalidades podem ser implementadas de maneiras distintas. Com base nessa ideia, à medida que o programa é construído, o aluno pode reusar os casos de teste e avaliar se o programa em construção está livre dos defeitos previstos pelos casos de teste que estão sendo reusados. Dessa forma, o método contribui para o aumento da qualidade dos programas gerados pelos alunos. Qualidade aqui refere-se à conformidade da implementação do programa com a especificação do mesmo. Outra vertente dessa abordagem, é que, ao mesmo tempo que aprende a programar, o aluno compreende a importância da atividade de teste de software. O estudo envolveu a utilização de dois domínios da programação para a geração dos conjuntos de casos de teste: manipulação de vetores e manipulação de matrizes. O estudo foi realizado em duas turmas de cursos de computação do ICMC. Em cada turma, os alunos foram divididos em dois grupos de forma aleatória, no qual um grupo de alunos recebeu apenas a especificação do programa e o outro grupo recebeu a especificação do programa e o conjunto de teste. Ao final, foram gerados 60 programas implementados pelos alunos para análise. Com base nos testes de Kruskal-Wallis conclui-se que há evidê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 introdutórios de programação. Este artigo está organizado da seguinte forma: Na Seção 2 são apresentados os trabalhos relacionados. Na Seção 3 são apresentados conceitos de teste de software. Na Seção 4 é apresentada a descrição do estudo realizado com o planejamento e resultados obtidos. Na Seção 5 são apresentadas as discussões sobre o estudo. Por fim, na Seção 6 são apresentadas as conclusões do artigo. 2. Trabalhos Relacionados Na literatura alguns trabalhos enfatizam o reuso de teste de software. Em Wang et al. [1997] é discutida a reusabilidade de testes, no contexto de programação orientada a objetos, fazendo uso de mecanismos testáveis embutidos no código que são os testes built-in (BIT). Nessa modalidade, os testes são explicitamente declarados na interface do objeto. Essa flexibilidade dos BITs permite herança e reuso da mesma forma que o reuso de funções para um objeto. Wang et al. [2000] propõem estender o reuso provido pelos testes embutidos (BITs) aplicando-os a frameworks orientados a objetos. Num framework, os BITs 102

110 podem ser estruturados em classes ou outras formas, possibilitando reuso de código e das estruturas de teste. Quando as classes do framework são instanciadas, as funções reutilizáveis, que já contêm testes embutidos, também o são. Estruturas de teste adicionais são necessárias apenas para funções que sofreram reuso parcial ou novas funções da aplicação gerada. Yao e Wang [2005] utilizam BITs para prover um framework baseado em CORBA (Common Object Request Broker Architecture) para teste remoto de software distribuído. Na proposta apresentada para arquitetura cliente servidor, é fornecido um ambiente que permite ao cliente definir testes caixa preta para componentes publicados no servidor. Essa abordagem prevê reuso e automatizaçã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 geração automática de casos de teste. A geração é facilitada por um repositório que armazena os casos de teste e sua descrição. A padronização na descrição é fundamental para que seja possível uma posterior recuperação dos casos de teste. Um algoritmo de mapeamento relaciona as descrições e os casos de teste do repositório. O conceito de teste de software também vem sendo explorado no ensino. Hoffman et al. [1996] sugerem a inserção de té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] é apresentado um ambiente para submissão e avaliação de trabalhos práticos. O ambiente prevê a utilização de teste de software como forma de aplicação dos conceitos abstratos de linguagem de programação e como estratégia para facilitar a avaliação dos trabalhos dos alunos. Campanha et al. [2009] apresentam os resultados de um estudo experimental sobre reuso de conjuntos de casos de teste adequados ao critério Análise de Mutação (AM) em programas equivalentes, no domínio de ordenação de vetores. Na condução do experimento, dois alunos de pós-graduação desenvolveram versões de referência dos algoritmos de ordenação bubble sort, selection sort e insertion sort e geraram, para cada programa implementado, conjuntos de casos de teste adequados ao critério AM. Alunos de graduação de uma disciplina introdutória de programação implementaram versões equivalentes dos programas de referência, os quais foram testados com os conjuntos de casos de teste gerados a partir dos programas de referência. Concluiu-se com o experimento que o reuso de conjuntos de casos de teste gerados a partir do crité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 conjuntos de casos de teste como apoio ao ensino de disciplinas introdutórias de programação. Pretende-se qualificar o reuso de conjuntos de casos de teste como instrumento alternativo à especificação de requisitos fornecida pelo professor aos alunos, servindo como outra informação sobre o programa a ser construído. A ideia é que o conjunto de teste sirva de auxílio quanto à avaliação da corretude do programa 103

111 durante o desenvolvimento. 3. Teste de Software O processo de desenvolvimento de software envolve o emprego de métodos, técnicas e ferramentas, porém isso não evita a ocorrência de erros. Para que os erros sejam reduzidos, existem as atividades de VV&T (Verificação, Validação e Teste de software) que são empregadas durante o ciclo de desenvolvimento de software. A Verificação é o processo de identificar se a construção do software está sendo feita da forma correta. A Validação envolve avaliar se o software desenvolvido obedece aos requisitos propostos pelo cliente. A atividade de Teste de Software envolve revelar a presença de defeitos, caso existam [Myers et al. 2004]. A atividade de teste deve estar presente durante todo o ciclo de desenvolvimento, esta possui as seguintes fases ou níveis: 1) teste de unidade, fase em que são testadas as menores unidades que compõe o software, como procedimentos, funções ou métodos e classes; 2) teste de integração, fase em que é testada a integração entre os módulos, componentes ou outras formas de unidade que compõe o software e; 3) teste de sistema, em que o sistema é testado como um todo, os testes aplicados nessa fase incluem o teste de estresse, teste de segurança, de carga, dentre outros. Além dessas três fases, existem também os testes de regressão, realizados quando o programa sofre alterações e precisa passar por novos testes que mostrem que tanto os requisitos introduzidos, se for o caso, ou os requisitos anteriormente testados continuam válidos [Delamaro et al. 2007]. Um caso de teste é um par formado por um ou mais valores fornecidos como entrada ao programa mais o resultado esperado do programa para essa entrada. Um critério de teste define quais propriedades ou requisitos precisam ser testados para avaliar a qualidade dos testes [Zhu et al. 1997]. A seleção dos casos de teste é realizada com base nos critérios de teste, os quais são definidos com base nas técnicas de teste: estrutural, funcional e baseada em erros. Na técnica funcional, o software é considerado uma caixa preta, o conjunto de teste é construído com base na especificação do software. Para o teste estrutural são testadas as estruturas internas do software, o conjunto de teste é construído com base na implementação do software. Na técnica de teste baseada em erros, os defeitos mais comuns cometidos no processo de desenvolvimento são utilizados para seleção do conjunto de casos de teste. Com base nessas características, no experimento descrito neste trabalho, o critério de teste funcional foi selecionado para geração dos casos de teste, pois não exige conhecimento sobre o código a ser testado e nesse caso, como trata-se de programas equivalentes, acredita-se que seja a melhor escolha. 4. Descrição do Estudo Nesta seção é descrita a condução do experimento, seguindo o processo definido por Wohlin et al. [2000]. 104

112 4.1. Planejamento Definição: Investigar o reúso de conjuntos de casos de teste como instrumento alternativo no ensino de programação, verificando se com esse método há aumento da qualidade dos programas implementados por alunos de cursos introdutórios de programação. Contexto: Avaliação de programas no domínio de manipulação de vetores e manipulação de matrizes, implementados em C por alunos de graduação dos cursos de computação do ICMC. Definição de um conjunto de programas de referência do domínio de manipulação de vetores e manipulação de matrizes a serem implementados e testados por uma aluna de Pós-graduação que gerará os conjuntos de casos de teste a serem reutilizados a partir dos programas de referência. O experimento será realizado considerando dois grupos de alunos escolhidos aleatoriamente a serem avaliados e dois programas do domínio de manipulação de vetores e manipulação de matrizes P 1 e P 2 e conjuntos de casos de teste adequados aos programas de referência T 1 e T 2 desses domínios para o critério funcional. Numa aula prática, metade dos alunos da turma receberá do professor somente a especificação do problema e a outra parte receberá além da especificação do problema os conjuntos de casos de teste T 1 e T 2 após implementação dos programas. Hipóteses: Deseja-se avaliar as seguintes hipóteses: Hipótese Nula H0 : Os alunos que possuem os conjuntos de casos de teste T 1 e T 2 produzirão programas com qualidade igual ou inferior aos alunos que receberam apenas as especificações dos programas. Hipótese Alternativa H1 : Os alunos que possuem os conjuntos de casos de teste T 1 e T 2 produzirão programas com melhor qualidade do que os alunos que receberam apenas as especificações dos programas. Variáveis Independentes: Especificações dos programas, programas de referência, conjuntos de casos de teste, sexo dos alunos, proveniência dos alunos (escola pública ou privada) e experiência dos alunos (sim ou não). Variáveis Dependentes: Programas implementados pelos alunos e relatório dos questionários. Participantes: 60 alunos da disciplina de Introdução à Ciência da Computação I (ICC-1) dos cursos de Bacharelado em Ciência da Computação e Bacharelado em Informática do ICMC/USP. Foram 44 alunos do curso de Bacharelado em Ciência da Computação (alunos da mesma turma, mas como o experimento foi realizado em dias diferentes e usando escolhas aleatórias para os grupos, para análise dos dados considerou-se duas turmas com base nos dias de aplicação de cada estudo, obtendo-se assim as 105

113 turmas I e II) e 16 alunos do curso de Bacharelado em Informática (turma III), os quais desenvolveram versões dos programas para serem avaliadas. Uma aluna de pós-graduação gerou os conjuntos de casos de teste adequados a um grupo de programas de referência. Descrição do experimento: Sobre os conhecimentos dos domínios escolhidos para os programas, considerou-se que o conteúdo ministrado durante a disciplina era suficiente para os alunos. Não foi fornecido treinamento sobre teste de software. Durante a parte prática, os alunos de cada uma das 3 turmas foram separados em dois grupos de forma aleatória, nesse caso, obedecendo a ordem alfabética do diário de classe. Todos os alunos da turma responderam a um questionário para o fornecimento de informações sobre sexo, proveniência e experiência que foram utilizadas nas análises. Em seguida um dos grupos recebeu apenas a especificação do programa e o outro recebeu além da especificação, os conjuntos de casos de teste. Cada aluno ficou responsável por implementar os programas dos domínios escolhidos e quando havia recebido os conjuntos de casos de teste, testar os programas. Essa atividade foi realizada em horário de aula prática e os alunos gastaram os seguintes tempos para implementação dos programas: turma I - 1 hora; turma II - 2 horas e turma III - 2 horas. Nessa fase do experimento não foi admitida comunicação entre os alunos e nem consulta a outros materiais. Antes dessa atividade, uma aluna de Pós-graduação envolvida no estudo implementou, a partir das especificações disponíveis em [Ascencio & Campos 2007], os programas de referência e gerou os conjuntos de casos de teste a serem reutilizados pelos alunos. Na segunda parte do experimento, as implementações e os questionários respondidos pelos alunos foram analisados. Cada programa foi compilado e executado, usando os conjuntos de casos de teste previamente construídos para atribuição de nota e avaliação quanto à corretude. A avaliação dos programas foi estabelecida segundo uma pontuação variando de 0 a 10 para cada programa. Para avaliar as hipóteses levantadas, foram realizados testes estatísticos de Kruskal- Wallis. Os resultados obtidos podem ser observados Seção 4.2. Validade: Os aspectos de validade do experimento são divididos em validade interna e externa. A validade interna busca identificar quais aspectos podem influenciar a relação entre a causa e o efeito durante a realização do experimento. As ameaças a validade interna identificadas foram: Implementações idênticas pelos alunos de graduação: Foram tomados alguns cuidados durante a execução do experimento para que os alunos não se comunicassem enquanto implementavam os programas. Além disso, os códigos foram analisados individualmente e não foram identificadas evidências de plágio. Simplicidade dos programas testados: Pode-se supor que devido à simplicidade dos programas escolhidos, qualquer conjunto de casos de testes seria suficiente para alcançar um nível de corretude satisfatório para os programas. Não foi encontrado tratamento para essa ameaça, já que o nível dos 106

114 alunos não permitiam programas muito complexos e o tempo disponível para implementação também era reduzido. A validade externa do experimento refere-se à capacidade de generalização dos resultados obtidos. Como os programas estudados foram específicos do domínio de manipulação de vetores e de matrizes, os resultados obtidos não podem ser aplicados a outros domínios de programas Resultados Os dados analisados foram coletados a partir dos programas escritos pelos alunos e dos questionários que eles responderam quando da aplicação do experimento. Na Tabela 1 estã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 especificações, contudo, devido ao tempo reduzido que estes possuíam para a implementação dos programas (1 hora), apenas 42, 86% dos alunos concluíram os dois programas em tempo hábil. Em decorrência disso, a segunda implementação foi desconsiderada nas análises. Nas turmas II e III as duas especificações foram implementadas pelos alunos. Inicialmente os dados foram separados conforme cada turma para análise, porém, o teste de Kruskal-Wallis forneceu evidências de que não havia diferenças significativas entre as turmas analisadas. Assim, as análises foram realizadas sem preocupação com diferenças entre turmas. Turma Domínio Quant. Programas I manipulação de vetores 28 II manipulação de vetores e matrizes 16 III manipulação de vetores e matrizes 16 Tabela 1. População do Experimento A Tabela 2 apresenta as variáveis obtidas a partir do questionário, as quais também foram consideradas na aná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 nã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 opçõ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 procedência de 2 o grau. Categoria 1 significa procedência de escola pública e categoria 0 significa procedência de escola privada. A quarta coluna especifica a categoria e a quantidade de pessoas com base na experiência. Considera-se categoria 1 para aluno que possui experiência em programação e categoria 0 para o aluno que não possui experiência (está estudando C pela primeira vez na disciplina). Na Seção 5 esses resultados são analisados estatisticamente e discutidos. 5. Discussões Para analisar estatisticamente se os diferentes conjuntos de casos de teste gerados para os programas de referência quando reusados em programas equivalentes contribuem para o aumento na qualidade dos programas decidiu-se realizar análises 107

115 Turma/Grupo Categoria/Sexo Categoria/2 o grau Categoria/Experiê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. Informações Extraídas dos Questionários usando o teste de Kruskal-Wallis entre os grupos da amostra e determinar se existia diferença significativa entre os mesmos. O teste de Kruskal-Wallis permite obter evidências sobre os grupos considerados no que relaciona-se a homogeneidade dos mesmos. Este teste foi aplicado para verificar as hipóteses formuladas na Seção 4.1. Assumiu-se como nível de confiança 95% (portanto, rejeita-se a hipótese H0 para p- values < 0, 05). Nos estudos realizados várias permutações foram feitas considerando as variáveis estudadas a fim de obter evidências sobre os resultados do estudo e o grau de adequação de cada variável no intervalo de confiança considerado. As primeiras análises tiveram como objetivo diagnosticar diferenç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 evidências de que não havia distinção entre as turmas considerando o grupo dos alunos que nã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 também forneceu evidências de que não havia distinção entre as turmas para o grupo que reusou conjuntos de teste. Após essas duas aná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 não reusaram os conjuntos de casos de teste). A Tabela 3 apresenta estatísticas dos testes realizados para comparações entre os grupos 0 e 1. No primeiro teste foram considerados os dois grupos compostos por alunos das três turmas. Com base nessa análise, observa-se p-value < 0.05, significando que há diferença entre os grupos comparados. Nesse caso, como os grupos representam alunos que reusaram e alunos que não reusaram os conjuntos de casos de teste, conclui-se que a informação extra (os conjuntos de casos de teste reusados) contribuiu para distinguir os grupos analisados. Test Descrição Kruskal-Wallis chi-squared df p-value 1 Grupo 0 das turmas I, II e III e grupo das turmas I, II e III 2 Grupo 0 das turmas I e II e grupo das turmas I e II 3 Grupo 0 das turmas I e II e grupo 1 da turma III Tabela 3. Resultados das Análises Para o teste 2, também apresentado na Tabela 3, considerou-se apenas turmas do curso de Bacharelado em Ciência da Computaçã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 só curso os conjuntos de casos de teste reusados contribuem para a distinção entre 108

116 os grupos. O último teste, o teste 3, forneceu evidências de que a diferenç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 três testes que a informação extra que difere os grupos é a responsável pela diferença observada. Após as análises dos testes com base nos grupos obteve-se p-values < 0.05, possibilitando rejeitar a hipótese nula e concluir a existência de diferenças significativas entre os grupos. Assim, há evidências de que o reúso de conjuntos de casos de teste funcional gerados com base em programas de referência pode contribuir com o aumento da qualidade de programas equivalentes implementados por alunos de disciplinas introdutórias de programação. Foram realizadas outras análises com as variáveis sexo, procedência de segundo grau e experiência, mas não foram encontrados indícios de que essas variáveis contribuíam com o teste de hipóteses para a amostra considerada. 6. Conclusões Este artigo apresenta a proposta de reuso de conjuntos de casos de teste como auxílio ao ensino de disciplinas introdutórias de programação visando o aumento na qualidade dos programas gerados pelos alunos. Porém, não é 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 estão iniciando na programação, e assim possa contribuir para o seu aprendizado. O desenvolvimento da proposta fundamenta-se em uma metodologia baseada em experimentação segundo Wholin [2001]. O estudo experimental conduzido teve como objetivo validar essa proposta. O teste de Kruskal-Wallis forneceu evidê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 à medida forem sendo desenvolvidos e como consequência atribuam um grau de importância maior a atividade de teste. Existem limitações a essa sistemática, pois casos de teste gerados a partir dos programas de referência serão reusados pelos alunos em versões alternativas dos programas de referência, de forma que o conjunto de teste reusado não foi elaborado para o programa que está sendo testado (programa do aluno). Assim, nã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 genéricos em relação às hipóteses estudadas. Outros estudos podem ser desenvolvidos considerando-se covariáveis (informações extra) que possivelmente explicariam as relações entre os resultados dos testes estatísticos. Como extensão a esse trabalho, um repositório pode ser utilizado pelo professor, para armazenar os programas e conjuntos de teste à medida que forem sendo gerados, para serem reutilizados e contribuir para melhoria da qualidade do material didático. 109

117 Referências Ascencio, A. F. G. and Campos, E. A. V. (2007). Fundamentos da Programaçã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). Reutilização de conjuntos de teste: Um estudo no domínio de algoritmos de ordenação. pages Delamaro, M. E., Maldonado, J. C., and Jino, M. (2007). Introdução ao Teste de Software, volume 394 of Campus. Elsevier. Dijkstra, E. W. (1972). Chapter i: Notes on structured programming. pages 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 Liu, Z. and Yang, G. (2005). An automate test case generation approach: Using match technique. Computer and Information Technology, International Conference on, 0: Myers, G. J., Sandler, C., Badgett, T., and Thomas, T. M. (2004). Software Testing. John Wiley & Sons, Inc., Hoboken, New Jersey. The Art of Souza, D. M. and Barbosa, E. F. (2009). Progtest: Um ambiente para submissão e avaliação automática de trabalhos de programação baseado em atividades de teste. Wang, Y., King, G., Court, I., Ross, M., and Staples, G. (1997). On testable objectoriented programming. SIGSOFT Softw. Eng. Notes, 22(4): 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 Transactions on Software Engineering, 12(12): Wohlin, C. and Höst, M. (2001). Special section: Controlled experiments in software engineering. Information & Software Technology, 43(15): Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., and Wesslén, A. (2000). Experimentation in software engineering: an introduction. Kluwer Academic Publishers, Norwell, MA, USA. Wu, T., Wan, Y., Xi, Y., and Chen, C. (2009). Study on the automatic test framework based on three-tier data driven mechanism. pages Yao, Y. and Wang, Y. (2005). A framework for testing distributed software components. In Electrical and Computer Engineering, Canadian Conference on, pages Zhu, H., Hall, P. A. V., and May, J. H. R. (1997). Software unit test coverage and adequacy. ACM Comput. Surv., 29(4):

118 Evaluating a Tool for Bug-report Analysis and Search Yguaratã Cerqueira Cavalcanti 1,3, Paulo Anselmo da Silveira Mota 1,3, Ivan do Carmo Machado 2,4, Eduardo Santana de Almeida 2,3 Silvio Romero de Lemos Meira 1,3 1 Center for Informatics Federal University of Pernambuco (UFPE) 2 Computer Science Department Federal University of Bahia (UFBA) 3 Reuse in Software Engineering (RiSE) Abstract. Bug report tracking systems have been used to facilitate the maintenance 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 generally 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, described 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 challenges 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

119 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 more information 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 proposed tool; Section 3 presents the case study performed inside Motorola test center; Section 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 ( 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

120 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 information 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 natural 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 companyspecific 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 development is distributed, tests are also performed distributed in different test centers. Briefly, 113

121 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 interpretation 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 efficiency of BAST for search and analysis of bug reports, with a focus on avoiding duplicates, 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 decreases 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 complexity 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 the repository, 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

122 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 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 describe the results considering the first and second stages of the case study execution, then we analyze the whole period 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

123 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 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 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

124 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 Analysis of the Whole Period Types of bug reports analyzed. Figure 6 shows the types of bug reports that were analyzed 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 reports, 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

125 (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 general, 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 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. However, 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 found using 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

Uso dos Resultados de um Estudo Baseado em Revisão Sistemática para Elaborar uma Proposta Inicial de Pesquisa

Uso dos Resultados de um Estudo Baseado em Revisão Sistemática para Elaborar uma Proposta Inicial de Pesquisa VII Experimental Software Engineering Latin American Workshop (ESELAW 2010) Uso dos Resultados de um Estudo Baseado em Revisão Sistemática para Elaborar uma Proposta Inicial de Pesquisa Natália Chaves

Leia mais

Um Mapeamento Sistemático da Pesquisa sobre a Influência da Personalidade na Engenharia de Software

Um Mapeamento Sistemático da Pesquisa sobre a Influência da Personalidade na Engenharia de Software 1 1 2 Um Mapeamento Sistemático da Pesquisa sobre a Influência da Personalidade na Engenharia de Software Shirley Jacinto (ssj@cin.ufpe.br) Orientador: Fabio Q. B. da Silva (fabio@cin.ufpe.br) Questões

Leia mais

Uma Análise da História do VEM, WBVS e WMSWM

Uma Análise da História do VEM, WBVS e WMSWM VEM Uma Análise da História do VEM, WBVS e WMSWM Renato Novais, Thiago S. Mendes, Fernando Teles Instituto Federal da Bahia (IFBA) Salvador Bahia Brasil {renato,thiagosouto,fernandoteles}@ifba.edu.br Abstract.

Leia mais

Uma Abordagem para Condução de Iniciativas de Melhoria de Processos de Software

Uma Abordagem para Condução de Iniciativas de Melhoria de Processos de Software Uma Abordagem para Condução de Iniciativas de Melhoria de Processos de Software Mariano Montoni, Cristina Cerdeiral, David Zanetti, Ana Regina Rocha COPPE/UFRJ - Universidade Federal do Rio de Janeiro

Leia mais

Um Framework de Engenharia de Requisitos para Desenvolvimento de Produtos de Software

Um Framework de Engenharia de Requisitos para Desenvolvimento de Produtos de Software Um Framework de Engenharia de Requisitos para Desenvolvimento de Produtos de Software Carina Alves Centro de Informática Universidade Federal de Pernambuco (UFPE) Caixa Postal 50732-970 Recife PE Brazil

Leia mais

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil Elicitação de Requisitos a partir de Modelos de Processos de Negócio e Modelos Organizacionais: Uma pesquisa para definição de técnicas baseadas em heurísticas Marcos A. B. de Oliveira 1, Sérgio R. C.

Leia mais

Avaliando modelos arquiteturais através de um checklist baseado em atributos de qualidade

Avaliando modelos arquiteturais através de um checklist baseado em atributos de qualidade Avaliando modelos arquiteturais através de um checklist baseado em atributos de qualidade Aluno: Rafael Ferreira Barcelos barcelos@cos.ufrj.br Orientador: Guilherme Horta Travassos ght@cos.ufrj.br Nível:

Leia mais

Geração automática de suíte de teste para GUI a partir de Rede de Petri

Geração automática de suíte de teste para GUI a partir de Rede de Petri Raquel Jauffret Guilhon Geração automática de suíte de teste para GUI a partir de Rede de Petri Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do grau de Mestre pelo

Leia mais

Metodologia para Planejamento, Execução e Controle de Teste de Software. Roteiro

Metodologia para Planejamento, Execução e Controle de Teste de Software. Roteiro Metodologia para Planejamento, Execução e Controle de Teste de Software Arilo Claudio Dias Neto - acdn@cos.ufrj.br Gladys Machado P. S. Lima - gladysmp@cos.ufrj.br Guilherme Horta Travassos - ght@cos.ufrj.br

Leia mais

Critérios para Apoiar a Decisão Sobre o Momento de Parada dos Testes de Software

Critérios para Apoiar a Decisão Sobre o Momento de Parada dos Testes de Software Critérios para Apoiar a Decisão Sobre o Momento de Parada dos Testes de Software Victor Vidigal Ribeiro Guilherme Horta Travassos {vidigal, ght}@cos.ufrj.br Agenda Introdução Resultados da revisão Corpo

Leia mais

Mapeamento Sistemático sobre Métricas no Contexto de Métodos Ágeis aplicadas a Teste de Software

Mapeamento Sistemático sobre Métricas no Contexto de Métodos Ágeis aplicadas a Teste de Software sobre Métricas no Contexto de Métodos Ágeis aplicadas a Teste de Software Thaynã Gonçalves Mota Arilo Claudio Dias Neto (arilo@icomp.ufam.edu.br) Roteiro deste apresentação Introdução 2 Problema e Motivação

Leia mais

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Rodrigo Araujo Barbalho 1, Marília Paulo Teles 2, Sandro Ronaldo Bezerra Oliveira 1,2 1 Faculdade de Computação

Leia mais

Tese / Thesis Work Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java

Tese / Thesis Work Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java Licenciatura em Engenharia Informática Degree in Computer Science Engineering Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java Performance analysis of large distributed

Leia mais

Reuso de Software. Caixa Postal 10.011 CEP 86057-970 Londrina PR Brasil. cezbastos@gmail.com, jgpalma@uel.br

Reuso de Software. Caixa Postal 10.011 CEP 86057-970 Londrina PR Brasil. cezbastos@gmail.com, jgpalma@uel.br Reuso de Software Cezar Bastos Filho 1, Jandira Guenka Palma 1 1 Departamento de Computação Universidade Estadual de Londrina (UEL) Caixa Postal 10.011 CEP 86057-970 Londrina PR Brasil cezbastos@gmail.com,

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

Transformação de um Modelo de Empresa em Requisitos de Software

Transformação de um Modelo de Empresa em Requisitos de Software Transformação de um Modelo de Empresa em Requisitos de Software Fábio Levy Siqueira 1 and Paulo Sérgio Muniz Silva 2 1 Programa de Educação Continuada da Poli-USP, São Paulo, Brazil 2 Escola Politécnica

Leia mais

Ahrend, Jan-Marten. Requirements Elicitation in Startup Companies.

Ahrend, Jan-Marten. Requirements Elicitation in Startup Companies. Ahrend, Jan-Marten. Requirements Elicitation in Startup Companies. Dieste, O.; Juristo, N.; Shull, F., "Understanding the Customer: What Do We Know about Requirements Elicitation Mestrando: Rafael Carvalho

Leia mais

O início de um estudo sistemático sobre ferramentas de gerenciamento de riscos para Projetos de Software

O início de um estudo sistemático sobre ferramentas de gerenciamento de riscos para Projetos de Software O início de um estudo sistemático sobre ferramentas de gerenciamento de riscos para Projetos de Software Márcia Ribeiro dos Santos 1, Luanna Lopes Lobato 1,2 1 Departamento de Ciência da Computação Universidade

Leia mais

Definição de Critérios para Análise Comparativa de Modelos de Referência para Desenvolvimento Global de Software

Definição de Critérios para Análise Comparativa de Modelos de Referência para Desenvolvimento Global de Software Definição de Critérios para Análise Comparativa de Modelos de Referência para Desenvolvimento Global de Software Leonardo Pilatti, Jorge Luis Nicolas Audy Faculdade de Informática Programa de Pós Graduação

Leia mais

MODELOS DE REFERÊNCIA PARA BIBLIOTECAS: a experiência do SIBi/USP

MODELOS DE REFERÊNCIA PARA BIBLIOTECAS: a experiência do SIBi/USP MODELOS DE REFERÊNCIA PARA BIBLIOTECAS: a experiência do SIBi/USP Teresinha das Graças Coletta 1, Maria Helena Di Francisco 2, Fabio Muller Guerrini³, Thyerre de Castro Ramazzi 4 1 Mestrado, Escola de

Leia mais

Online Collaborative Learning Design

Online Collaborative Learning Design "Online Collaborative Learning Design" Course to be offered by Charlotte N. Lani Gunawardena, Ph.D. Regents Professor University of New Mexico, Albuquerque, New Mexico, USA July 7- August 14, 2014 Course

Leia mais

Análise Probabilística de Semântica Latente aplicada a sistemas de recomendação

Análise Probabilística de Semântica Latente aplicada a sistemas de recomendação Diogo Silveira Mendonça Análise Probabilística de Semântica Latente aplicada a sistemas de recomendação Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do título de

Leia mais

Avaliação do Processo de atendimento de demandas de produtos de software da Embrapa

Avaliação do Processo de atendimento de demandas de produtos de software da Embrapa Avaliação do Processo de atendimento de demandas de produtos de software da Embrapa Edméia Leonor Pereira de Andrade Embrapa edmeia.andrade@embrapa.br AngélicaToffano Seidel Calazans Caixa Econômica Federal

Leia mais

Uma Abordagem para a Avaliação de Processos de Desenvolvimento de Software Baseada em Risco e Conformidade

Uma Abordagem para a Avaliação de Processos de Desenvolvimento de Software Baseada em Risco e Conformidade Rafael de Souza Lima Espinha Uma Abordagem para a Avaliação de Processos de Desenvolvimento de Software Baseada em Risco e Conformidade Dissertação de Mestrado Dissertação apresentada como requisito parcial

Leia mais

Lucas Figueiredo Gonçalves

Lucas Figueiredo Gonçalves Lucas Figueiredo Gonçalves Master s student in Computer Graphics at Federal University of Rio de Janeiro luccashappy@gmail.com Summary I m a Master s student in Computer Graphics at Federal University

Leia mais

A meus pais, Ari e Célia, sempre presentes, todo o meu amor incondicional!

A meus pais, Ari e Célia, sempre presentes, todo o meu amor incondicional! ii A meus pais, Ari e Célia, sempre presentes, todo o meu amor incondicional! iii Agradeço à Deus, esta força maior, pela vida, pela sabedoria e pelo amor. Mas, sobretudo, por me ensinar saber fazer ser

Leia mais

Course Computer Science Academic year 2012/2013 Subject Social Aspects of Computers ECTS 5

Course Computer Science Academic year 2012/2013 Subject Social Aspects of Computers ECTS 5 Course Computer Science Academic year 2012/2013 Subject Social Aspects of Computers ECTS 5 Type of course Compulsory Year 2º Semester 2nd sem Student Workload: Professor(s) Natalia Gomes, Ascensão Maria

Leia mais

User interface evaluation experiences: A brief comparison between usability and communicability testing

User interface evaluation experiences: A brief comparison between usability and communicability testing User interface evaluation experiences: A brief comparison between usability and communicability testing Kern, Bryan; B.S.; The State University of New York at Oswego kern@oswego.edu Tavares, Tatiana; PhD;

Leia mais

EPLNA_2012. Ciclo de Garantia da Qualidade Analítica: tendências e etapas fundamentais para a fornecer resultados confiáveis

EPLNA_2012. Ciclo de Garantia da Qualidade Analítica: tendências e etapas fundamentais para a fornecer resultados confiáveis Ciclo de Garantia da Qualidade Analítica: tendências e etapas fundamentais para a fornecer resultados confiáveis Prof. Dr. Igor Renato Bertoni Olivares Top 02 in analytical chemistry Impact Factor - 6,6

Leia mais

Requisitos de Ferramentas de Gestão de Projetos de Desenvolvimento de Software

Requisitos de Ferramentas de Gestão de Projetos de Desenvolvimento de Software Requisitos de Ferramentas de Gestão de Projetos de Desenvolvimento de Software Keyla Guimarães Macharet Brasil 1 1 Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) CEP

Leia mais

Usando Modelos Para Apoiar a Especificação e Verificação de Requisitos de Ubiquidade

Usando Modelos Para Apoiar a Especificação e Verificação de Requisitos de Ubiquidade Usando Modelos Para Apoiar a Especificação e Verificação de Requisitos de Ubiquidade Leonardo Mota, Jobson Massollar, Guilherme Horta Travassos Federal University of Rio de Janeiro/COPPE/PESC Caixa Postal

Leia mais

FATEsC - Uma Ferramenta de apoio ao teste estrutural de componentes

FATEsC - Uma Ferramenta de apoio ao teste estrutural de componentes FATEsC - Uma Ferramenta de apoio ao teste estrutural de componentes Vânia Somaio Teixeira 1,2, Marcio Eduardo Delamaro 1, Auri Marcelo Rizzo Vincenzi 3 1 Programa de Pós-graduação em Ciência da Computação

Leia mais

Semestre do plano de estudos 1

Semestre do plano de estudos 1 Nome UC Inglês CU Name Código UC 6 Curso LEC Semestre do plano de estudos 1 Área científica Gestão Duração Semestral Horas de trabalho 54 ECTS 2 Horas de contacto TP - 22,5 Observações n.a. Docente responsável

Leia mais

Evolução de Requisitos na Metodologia Ágil

Evolução de Requisitos na Metodologia Ágil Evolução de Requisitos na Metodologia Ágil Thiago Cabral 1,*, Rafael Soares 1, Fernanda Alencar 1, 2 1 Programa de Pós Graduação em Engenharia da Computação, Universidade de Pernambuco, Rua Benfica, 455

Leia mais

MODELAGEM VISUAL DE UM SOFTWARE PARA O GERENCIAMENTO DAS COMUNICAÇÕES EM GESTÃO DE PROJETOS

MODELAGEM VISUAL DE UM SOFTWARE PARA O GERENCIAMENTO DAS COMUNICAÇÕES EM GESTÃO DE PROJETOS 127 MODELAGEM VISUAL DE UM SOFTWARE PARA O GERENCIAMENTO DAS COMUNICAÇÕES EM GESTÃO DE PROJETOS VISUAL MODELING OF SOFTWARE FOR COMMUNICATION MANAGEMENT IN PROJECT MANAGEMENT Ricardo Rall 1 Arilson José

Leia mais

Digital Cartographic Generalization for Database of Cadastral Maps

Digital Cartographic Generalization for Database of Cadastral Maps Mariane Alves Dal Santo marianedalsanto@udesc.br Francisco Henrique de Oliveira chicoliver@yahoo.com.br Carlos Loch cloch@ecv.ufsc.br Laboratório de Geoprocessamento GeoLab Universidade do Estado de Santa

Leia mais

Monitoramento de Métricas de Segurança da Informação

Monitoramento de Métricas de Segurança da Informação Monitoramento de Métricas de Segurança da Informação Rafael Seidi Shigueoka¹, Bruno Bogaz Zarpelão¹ 1 Departamento de Computação Universidade Estadual de Londrina (UEL) Caixa Postal 10.011 CEP 86057-970

Leia mais

MANUTENÇÃO DE SOFTWARE

MANUTENÇÃO DE SOFTWARE MANUTENÇÃO DE SOFTWARE Francisco Luiz Sobrinho, Samily Rocha Gois Faculdade de Tecnologia SENAC Goiânia/GO (SENAC/GO) Av. Independência número 1002 - CEP 74645-010 Setor Leste Vila Nova - Goiânia GO Brasil

Leia mais

LINGUAGEM DE ESPECIFICAÇÃO E DESCRIÇÃO (SDL) APLICADA AO PROCESSO DE VERIFICAÇÃO E VALIDAÇÃO DE SISTEMAS REATIVOS

LINGUAGEM DE ESPECIFICAÇÃO E DESCRIÇÃO (SDL) APLICADA AO PROCESSO DE VERIFICAÇÃO E VALIDAÇÃO DE SISTEMAS REATIVOS LINGUAGEM DE ESPECIFICAÇÃO E DESCRIÇÃO (SDL) APLICADA AO PROCESSO DE VERIFICAÇÃO E VALIDAÇÃO DE SISTEMAS REATIVOS Fabiana Fraga Ferreira Bacharelanda em Sistemas de Informação Bolsista de Iniciação Científica

Leia mais

2012 State of the Industry Survey

2012 State of the Industry Survey 2012 State of the Industry Survey Contact Information Por favor, preencha suas informações de contato (* indicates required information) Nome * Título * Title Razão Social completa da Empresa/Organização

Leia mais

NORMAS PARA AUTORES. As normas a seguir descritas não dispensam a leitura do Regulamento da Revista Portuguesa de Marketing, disponível em www.rpm.pt.

NORMAS PARA AUTORES. As normas a seguir descritas não dispensam a leitura do Regulamento da Revista Portuguesa de Marketing, disponível em www.rpm.pt. NORMAS PARA AUTORES As normas a seguir descritas não dispensam a leitura do Regulamento da Revista Portuguesa de Marketing, disponível em www.rpm.pt. COPYRIGHT Um artigo submetido à Revista Portuguesa

Leia mais

e-lab: a didactic interactive experiment An approach to the Boyle-Mariotte law

e-lab: a didactic interactive experiment An approach to the Boyle-Mariotte law Sérgio Leal a,b, João Paulo Leal a,c Horácio Fernandes d a Departamento de Química e Bioquímica, FCUL, Lisboa, Portugal b Escola Secundária com 3.º ciclo Padre António Vieira, Lisboa, Portugal c Unidade

Leia mais

ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO DE FELGUEIRAS

ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO DE FELGUEIRAS Curricular Unit Plan ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO DE FELGUEIRAS CURSO Licenciatura em Engenharia Informática U.C. GESTÃO DE PROJECTOS INFORMÁTICOS Horas presenciais / Ano 56 Ano Lectivo 2010

Leia mais

Requisitos para ferramentas de registro de defeitos de software

Requisitos para ferramentas de registro de defeitos de software Requisitos para ferramentas de registro de defeitos de software Alessandro Liebmam Departamento de Ciência da Computação Instituto de Ciências Exatas Universidade Federal de Minas Gerais (UFMG) CEP: 31270-010

Leia mais

Uma Experiência de Engenharia de Requisitos em Empresas de Software

Uma Experiência de Engenharia de Requisitos em Empresas de Software Uma Experiência de Engenharia de Requisitos em Empresas de Software Carina Frota Alves Centro de Informática, Universidade Federal de Pernambuco, Brasil cfa@cin.ufpe.br Resumo. Este artigo apresenta uma

Leia mais

Indicações de Abordagens para Rastreabilidade de Requisitos no contexto do MR-MPS-SW por meio de uma Revisão Sistemática da Literatura

Indicações de Abordagens para Rastreabilidade de Requisitos no contexto do MR-MPS-SW por meio de uma Revisão Sistemática da Literatura X Workshop Anual do MPS (WAMPS 2014) Indicações de Abordagens para Rastreabilidade de Requisitos no contexto do MR-MPS-SW por meio de uma Revisão Sistemática da Literatura Apresentador: Paulo Malcher Autores:

Leia mais

O USO DA TECNOLOGIA DE SIMULAÇÃO NA PRÁTICA DOCENTE NA ÁREA DE ENGENHARIA DE PRODUÇÃO

O USO DA TECNOLOGIA DE SIMULAÇÃO NA PRÁTICA DOCENTE NA ÁREA DE ENGENHARIA DE PRODUÇÃO 1 GT2 O USO DA TECNOLOGIA DE SIMULAÇÃO NA PRÁTICA DOCENTE NA ÁREA DE ENGENHARIA DE PRODUÇÃO Renato Fares Khalil Marco Aurélio Bossetto José Fontebasso Neto.br Orientadora: Profa. Dra. Irene Jeanete Lemos

Leia mais

Implementando MPS BR nível F como preparação para certificação CMMi nível 3

Implementando MPS BR nível F como preparação para certificação CMMi nível 3 Implementando MPS BR nível F como preparação para certificação CMMi nível 3 Analia Irigoyen Ferreiro Ferreira 1, Roberta Cerqueira 1, Gleison Santos 2 1 BL Informática Ltda. Av. Visconde do Rio Branco

Leia mais

Avaliação de técnicas de seleção de quadros-chave na recuperação de informação por conteúdo visual

Avaliação de técnicas de seleção de quadros-chave na recuperação de informação por conteúdo visual Avaliação de técnicas de seleção de quadros-chave na recuperação de informação por conteúdo visual Shênia Salvador de Pinho, Kleber J. F. Souza Instituto de Ciências Exatas e Informática PUC Minas Guanhães,

Leia mais

Artigos científicos / Scientific articles

Artigos científicos / Scientific articles Artigos científicos / Scientific articles Rev. Ibirapuera, São Paulo, n. 1, p. 31-35, jan./jun. 2011 REUSO DE REQUISITOS PARA FAMÍLIAS DE PRODUTOS EM SISTEMAS EMBARCADOS Cristiano Marçal Toniolo Universidade

Leia mais

A contribuição do geomarketing para o processo decisório de localização de empresas de varejo: Um estudo de caso em uma empresa de vestuário feminino

A contribuição do geomarketing para o processo decisório de localização de empresas de varejo: Um estudo de caso em uma empresa de vestuário feminino Maurício Sequeira Corujo A contribuição do geomarketing para o processo decisório de localização de empresas de varejo: Um estudo de caso em uma empresa de vestuário feminino Dissertação de Mestrado Dissertação

Leia mais

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Audrey B. Vasconcelos, Iuri Santos Souza, Ivonei F. da Silva, Keldjan Alves Centro de Informática Universidade

Leia mais

Banca examinadora: Professor Paulo N. Figueiredo, Professora Fátima Bayma de Oliveira e Professor Joaquim Rubens Fontes Filho

Banca examinadora: Professor Paulo N. Figueiredo, Professora Fátima Bayma de Oliveira e Professor Joaquim Rubens Fontes Filho Título: Direção e Taxa (Velocidade) de Acumulação de Capacidades Tecnológicas: Evidências de uma Pequena Amostra de Empresas de Software no Rio de Janeiro, 2004 Autor(a): Eduardo Coelho da Paz Miranda

Leia mais

Desenvolvimento de Software Livre

Desenvolvimento de Software Livre Relevância dos Requisitos no Desenvolvimento de Software Livre Elisa Yumi Nakagawa, Norberto Fukuta da Cruz, José Carlos Maldonado 1 Departamento de Ciências de Computação Instituto de Ciências Matemáticas

Leia mais

Escolha e implantação de uma metodologia de desenvolvimento de software: um estudo de caso para o Laboratório de Aplicação em Tecnologia da Informação

Escolha e implantação de uma metodologia de desenvolvimento de software: um estudo de caso para o Laboratório de Aplicação em Tecnologia da Informação Escolha e implantação de uma metodologia de desenvolvimento de software: um estudo de caso para o Laboratório de Aplicação em Tecnologia da Informação Elton A. dos Santos Departamento de Informática e

Leia mais

Um processo para construção de software mais transparente

Um processo para construção de software mais transparente Um processo para construção de software mais transparente Eduardo Almentero 1, and Julio Cesar Sampaio do Prado Leite 1 1 Pontifícia Universidade Católica do Rio de Janeiro, PUC - Rio, Brasil {ealmentero,

Leia mais

Leonardo Pereira Rodrigues dos Santos

Leonardo Pereira Rodrigues dos Santos Leonardo Pereira Rodrigues dos Santos Desenvolvimento de serviços na área de educação: uma aplicação de análise conjunta nos cursos de mestrado em administração de empresas DISSERTAÇÃO DE MESTRADO DEPARTAMENTO

Leia mais

Software product lines. Paulo Borba Informatics Center Federal University of Pernambuco

Software product lines. Paulo Borba Informatics Center Federal University of Pernambuco Software product lines Paulo Borba Informatics Center Federal University of Pernambuco Software product lines basic concepts Paulo Borba Informatics Center Federal University of Pernambuco Um produto www.usm.maine.edu

Leia mais

Ficha da Unidade Curricular

Ficha da Unidade Curricular ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO DE FELGUEIRAS CURSO Licenciatura em Engenharia Informática U.C. SISTEMAS DE INFORMAÇÃO Ficha da Unidade Curricular Horas presenciais / Ano 56 Ano Lectivo 2010 / 2011

Leia mais

Uma Abordagem para Tratamento de Regras de Negócio nas Fases Iniciais do Desenvolvimento

Uma Abordagem para Tratamento de Regras de Negócio nas Fases Iniciais do Desenvolvimento Uma Abordagem para Tratamento de Regras de Negócio nas Fases Iniciais do Desenvolvimento Marco Antonio De Grandi, Valter Vieira de Camargo, Edmundo Sérgio Spoto Centro Universitário Eurípides de Marília

Leia mais

JULIANO AUGUSTO DE SOUZA OLIVEIRA

JULIANO AUGUSTO DE SOUZA OLIVEIRA UNIVERSIDADE DE RIBEIRÃO PRETO CENTRO DE CIÊNCIAS EXATAS, NATURAIS E TECNOLÓGICAS PÓS-GRADUAÇÃO LATO SENSU EM BANCO DE DADOS JULIANO AUGUSTO DE SOUZA OLIVEIRA IMPLEMENTAÇÃO DE UM SISTEMA DE CONTROLE DE

Leia mais

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS SOCIAIS APLICADAS PROGRAMA DE PÓS-GRADUAÇÃO EM ADMINISTRAÇÃO

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS SOCIAIS APLICADAS PROGRAMA DE PÓS-GRADUAÇÃO EM ADMINISTRAÇÃO UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS SOCIAIS APLICADAS PROGRAMA DE PÓS-GRADUAÇÃO EM ADMINISTRAÇÃO PROCESSO DE IMPLANTAÇÃO DE UM SISTEMA INTEGRADO DE GESTÃO EM UMA ORGANIZAÇÃO

Leia mais

Apoio à Decisão Gerencial na Alocação de Recursos Humanos em Projetos de Software Ahilton Silva Barreto ahilton@cos.ufrj.br

Apoio à Decisão Gerencial na Alocação de Recursos Humanos em Projetos de Software Ahilton Silva Barreto ahilton@cos.ufrj.br Apoio à Decisão Gerencial na Alocação de Recursos Humanos em Projetos de Software Ahilton Silva Barreto ahilton@cos.ufrj.br Orientadores: Márcio de Oliveira Barros e Cláudia Maria Lima Werner {marcio,

Leia mais

ControlPro: Uma Ferramenta de Acompanhamento de Projetos Integrada a um Ambiente de Desenvolvimento de Software

ControlPro: Uma Ferramenta de Acompanhamento de Projetos Integrada a um Ambiente de Desenvolvimento de Software ControlPro: Uma Ferramenta de Acompanhamento de Projetos Integrada a um Ambiente de Desenvolvimento de Software Rodrigo Dal Moro, Julio Cesar Nardi, Ricardo de Almeida Falbo Departamento de Informática

Leia mais

Engenharia de Software no Curso de Ciência da Computação

Engenharia de Software no Curso de Ciência da Computação Engenharia de Software no Curso de Ciência da Vera Maria B. Werneck; Rosa Maria E. M. da Costa; Maria Clicia Stelling de Castro; Alexandre Sztajnberg; Paulo Eustáquio D. Pinto; Roseli S.Wedemann Departamento

Leia mais

Universidade do Minho. Escola de Engenharia. UC transversais Programas Doutorais 1º semestre 2012-13. 11 de outubro 2012

Universidade do Minho. Escola de Engenharia. UC transversais Programas Doutorais 1º semestre 2012-13. 11 de outubro 2012 Universidade do Minho Escola de Engenharia UC transversais Programas Doutorais 1º semestre 2012-13 11 de outubro 2012 1 2 2 courses offered in the first semestre: Métodos de Investigação em Engenharia

Leia mais

Aplicando Mensuração em Microempresas de Software para Suporte da Gerência de Projetos

Aplicando Mensuração em Microempresas de Software para Suporte da Gerência de Projetos Aplicando Mensuração em Microempresas de Software para Suporte da Gerência de Projetos Alessandra Anacleto¹, Christiane Gresse von Wangenheim² 1 Universidade Federal de Santa Catarina, Trindade, 88049-200

Leia mais

desenvolvimento de software em indústria, comunidades acadêmicas e científicas uma fábrica de software?... joa@ufrpe.br silvio@cesar.org.

desenvolvimento de software em indústria, comunidades acadêmicas e científicas uma fábrica de software?... joa@ufrpe.br silvio@cesar.org. desenvolvimento de software em indústria, comunidades acadêmicas e científicas uma fábrica de software?... joa@ufrpe.br silvio@cesar.org.br laboratórios de desenvolvimento... Produção de Software: histórico

Leia mais

Analysis, development and monitoring of business processes in Corporate environment

Analysis, development and monitoring of business processes in Corporate environment Analysis, development and monitoring of business processes in Corporate environment SAFIRA is an IT consulting boutique known for transforming the way organizations do business, or fulfil their missions,

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

inciência Iniciação Científica Embrapa Anais da X Jornada de Iniciação Científica da Embrapa Amazônia Ocidental

inciência Iniciação Científica Embrapa Anais da X Jornada de Iniciação Científica da Embrapa Amazônia Ocidental inciência Iniciação Científica Embrapa Anais da X Jornada de Iniciação Científica da Empresa Brasileira de Pesquisa Agropecuária Ministério da Agricultura, Pecuária e Abastecimento Anais da X Jornada de

Leia mais

Gestão Hospitalar O caso de hospitais privados do Rio de Janeiro

Gestão Hospitalar O caso de hospitais privados do Rio de Janeiro Alexandre Cunha Lobo de Melo Gestão Hospitalar O caso de hospitais privados do Rio de Janeiro Dissertação de mestrado Dissertação de mestrado apresentada ao Departamento de Administração da Pontifícia

Leia mais

Seleção de Técnicas de Teste Baseado em Modelos

Seleção de Técnicas de Teste Baseado em Modelos Seleção de Técnicas de Teste Baseado em Modelos Autor: Arilo Claudio Dias Neto 1 {ariloclaudio@gmail.com} Programa: Programa de Engenharia de Sistemas e Computação COPPE/UFRJ Data da defesa: 23 de Novembro

Leia mais

METODOLOGIAS ESTATÍSTICAS APLICADAS A DADOS DE ANÁLISES QUÍMICAS DA ÁGUA PRODUZIDA EM UM CAMPO MADURO DE PETRÓLEO

METODOLOGIAS ESTATÍSTICAS APLICADAS A DADOS DE ANÁLISES QUÍMICAS DA ÁGUA PRODUZIDA EM UM CAMPO MADURO DE PETRÓLEO UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE TECNOLOGIA CT CENTRO DE CIÊNCIAS EXATAS E DA TERRA CCET PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA E ENGENHARIA DE PETRÓLEO - PPGCEP DISSERTAÇÃO DE MESTRADO

Leia mais

Identificando a Formação de Ilhas de Conhecimento em Projetos de Software

Identificando a Formação de Ilhas de Conhecimento em Projetos de Software Identificando a Formação de Ilhas de Conhecimento em Projetos de Software Francisco Vanderson de Moura Alves 1, Pedro de Alcântara dos Santos Neto 1, Werney Ayala Luz Lira 1, Ricardo de Andrade Lira Rabêlo

Leia mais

Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial

Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial Lucas A. de Oliveira, Rui A. R. B. Figueira, Expedito C. Lopes Mestrado em Sistemas e Computação Universidade de Salvador (UNIFACS)

Leia mais

Proposta de Modelo de Desenvolvimento de Sistema de Medição de Desempenho Logístico

Proposta de Modelo de Desenvolvimento de Sistema de Medição de Desempenho Logístico Winston Carvalho Santana Proposta de Modelo de Desenvolvimento de Sistema de Medição de Desempenho Logístico DISSERTAÇÃO DE MESTRADO DEPARTAMENTO DE ENGENHARIA INDUSTRIAL Programa de Pós-Graduação Profissional

Leia mais

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos.

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos. A GESTÃO DE PROJETOS EXISTENTE NA NORMA DO-178B Matheus da Silva Souza, matheusdasilvasouza@gmail.com Prof. Dr. Luiz Alberto Vieira Dias, vdias@ita.br Instituto Tecnológico de Aeronáutica Praça Marechal

Leia mais

Engenharia de Software Aplicada ao Projeto, Desenvolvimento e Manutenção de Sistemas para Gestão de Comunidades e de Conteúdos Educacionais na Web

Engenharia de Software Aplicada ao Projeto, Desenvolvimento e Manutenção de Sistemas para Gestão de Comunidades e de Conteúdos Educacionais na Web Engenharia de Software Aplicada ao Projeto, Desenvolvimento e Manutenção de Sistemas para Gestão de Comunidades e de Conteúdos Educacionais na Web Cláudia Maria Lima Werner, Rodrigo Pereira dos Santos,

Leia mais

Requisitos de Ferramentas de Apoio aos Processos de Medição de Software. Marco Aurélio Vilaça de Melo

Requisitos de Ferramentas de Apoio aos Processos de Medição de Software. Marco Aurélio Vilaça de Melo Requisitos de Ferramentas de Apoio aos Processos de Medição de Software Marco Aurélio Vilaça de Melo Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) Belo Horizonte MG

Leia mais

Um Processo Controlável de Desenvolvimento de Software Focado na Gestão da Qualidade em Pequenos Projetos

Um Processo Controlável de Desenvolvimento de Software Focado na Gestão da Qualidade em Pequenos Projetos Daniel Catunda Marreco Um Processo Controlável de Desenvolvimento de Software Focado na Gestão da Qualidade em Pequenos Projetos Dissertação de Mestrado Dissertação apresentada como requisito parcial para

Leia mais

Uma Implementação do Processo de Medição usando a Spider-MPlan

Uma Implementação do Processo de Medição usando a Spider-MPlan Uma Implementação do Processo de Medição usando a Spider-MPlan Simone Nayara Costa Carneiro 1, Sandro Ronaldo Bezerra Oliveira 1 1 Faculdade de Computação Instituto de Ciências Exatas e Naturais Universidade

Leia mais

Estrutura Organizacional para a Realização de Negócios Eletrônicos em Empresas Tradicionais: Um Estudo de Caso

Estrutura Organizacional para a Realização de Negócios Eletrônicos em Empresas Tradicionais: Um Estudo de Caso Universidade de São Paulo Faculdade de Economia, Administração e Contabilidade Departamento de Administração Programa de Pós-Graduação em Administração Estrutura Organizacional para a Realização de Negócios

Leia mais

Eduardo Alves de Oliveira. eduaopec@yahoo.com.br IME Instituo Militar de Engenharia LES PUC-Rio Laboratório de Engenharia de Software da Puc - Rio

Eduardo Alves de Oliveira. eduaopec@yahoo.com.br IME Instituo Militar de Engenharia LES PUC-Rio Laboratório de Engenharia de Software da Puc - Rio Eduardo Alves de Oliveira eduaopec@yahoo.com.br IME Instituo Militar de Engenharia LES PUC-Rio Laboratório de Engenharia de Software da Puc - Rio Processo de Desenvolvimento de Software; Produtividade:

Leia mais

Cowboys, Ankle Sprains, and Keepers of Quality: How Is Video Game Development Different from Software Development?

Cowboys, Ankle Sprains, and Keepers of Quality: How Is Video Game Development Different from Software Development? Cowboys, Ankle Sprains, and Keepers of Quality: How Is Video Game Development Different from Software Development? Emerson Murphy-Hill Thomas Zimmermann and Nachiappan Nagappan Guilherme H. Assis Abstract

Leia mais

Gaia Inventário: um Modelo para Gestão da Configuração, Inventário e Ativos de Serviços de Tecnologia da Informação

Gaia Inventário: um Modelo para Gestão da Configuração, Inventário e Ativos de Serviços de Tecnologia da Informação Gaia Inventário: um Modelo para Gestão da Configuração, Inventário e Ativos de Serviços de Tecnologia da Informação Natali Silva Honda 1, Bruno Bogaz Zarpelão 1 1 Departamento de Computação Universidade

Leia mais

Ficha de unidade curricular Curso de Doutoramento

Ficha de unidade curricular Curso de Doutoramento Ficha de unidade curricular Curso de Doutoramento Unidade curricular História do Direito Português I (Doutoramento - 1º semestre) Docente responsável e respectiva carga lectiva na unidade curricular Prof.

Leia mais

Gerador de Sítios de Grupos de Pesquisa com Inclusão Automática de Conteúdo Baseada na Plataforma Lattes

Gerador de Sítios de Grupos de Pesquisa com Inclusão Automática de Conteúdo Baseada na Plataforma Lattes Gerador de Sítios de Grupos de Pesquisa com Inclusão Automática de Conteúdo Baseada na Plataforma Lattes Bruno Rego Salomé, Fátima L. S. Nunes, Marcos Lordello Chaim Escola de Artes, Ciências e Humanidades

Leia mais

Um Estudo Exploratório Dos Fatores Associados Ao Estímulo Do Aprendizado Em Times Ágeis Na Indústria

Um Estudo Exploratório Dos Fatores Associados Ao Estímulo Do Aprendizado Em Times Ágeis Na Indústria Um Estudo Exploratório Dos Fatores Associados Ao Estímulo Do Aprendizado Em Times Ágeis Na Indústria Claudia Melo 1, Carlos Santos Jr 1, Gisele Ferreira 2, Fabio Kon 1 11/11/2010 1 IME-USP 2 Banco Central

Leia mais

Reitor / President Marcos Macari, Ph.D. Vice-Reitor /Vice-President Herman Jacobus Cornelis Voorwald, Ph.D.

Reitor / President Marcos Macari, Ph.D. Vice-Reitor /Vice-President Herman Jacobus Cornelis Voorwald, Ph.D. UNIVERSIDADE ESTADUAL PAULISTA JULIO DE MESQUITA FILHO Reitor / President Marcos Macari, Ph.D. Vice-Reitor /Vice-President Herman Jacobus Cornelis Voorwald, Ph.D. Pró-Reitora de Pós-Graduação / Graduate

Leia mais

Uma Ferramenta para Recuperação de Modelos de Processo de Software Reutilizáveis

Uma Ferramenta para Recuperação de Modelos de Processo de Software Reutilizáveis Uma Ferramenta para Recuperação de Modelos de Processo de Software Reutilizáveis Ernani de O. Sales #, Salomão F. de Freitas #, *, Rodrigo Quites Reis #, * # Laboratório de Engenharia de Software *Programa

Leia mais

Implantação de Medição no Processo de Desenvolvimento de Software Relato de Experiência e Lições Aprendidas

Implantação de Medição no Processo de Desenvolvimento de Software Relato de Experiência e Lições Aprendidas Implantação de Medição no Processo de Desenvolvimento de Software Relato de Experiência e Luciana Nascimento 1 Talita Vieira Ribeiro 1 Adailton Magalhães Lima 1 Carla Alessandra Lima Reis 1 Rodrigo Quites

Leia mais

Uma Abordagem para Gerência Estratégica de Portfólio com Foco na Seleção de Projetos

Uma Abordagem para Gerência Estratégica de Portfólio com Foco na Seleção de Projetos Uma Abordagem para Gerência Estratégica de Portfólio com Foco na Seleção de Projetos Adler Diniz de Souza 1,2, Ana Regina Rocha 1, Gleison Santos 1, Tiago Vinícius Paiva do Carmo 2, Douglas Batista Alexandre

Leia mais

Fatores que Influenciam na Migração do Processo de Melhoria de Software baseado em MPS para o CMMI nas Empresas Brasileiras

Fatores que Influenciam na Migração do Processo de Melhoria de Software baseado em MPS para o CMMI nas Empresas Brasileiras Fatores que Influenciam na Migração do Processo de Melhoria de Software baseado em MPS para o CMMI nas Empresas Brasileiras Rhavy Maia Guedes, Ellen Poliana Ramos Souza, Alexandre Lins de Vasconcelos.

Leia mais

Aplicação de Métodos baseado em Processos de Negócio para Desenvolvimento de Serviços

Aplicação de Métodos baseado em Processos de Negócio para Desenvolvimento de Serviços Aplicação de Métodos baseado em Processos de Negócio para Desenvolvimento de Serviços Luan Lima 1, Ricardo Diniz Sul 1,2, Leonardo Guerreiro Azevedo 1,2,3 1 Departamento de Informática Aplicada (DIA) Universidade

Leia mais

DESENVOLVIMENTO DE UMA FERRAMENTA PARA A GESTÃO DE UM SERVIÇO DE INFORMAÇÃO, BASEADO NA INTERAÇÃO UNIVERSIDADE E SOCIEDADE: O CASO DO UFSCAR

DESENVOLVIMENTO DE UMA FERRAMENTA PARA A GESTÃO DE UM SERVIÇO DE INFORMAÇÃO, BASEADO NA INTERAÇÃO UNIVERSIDADE E SOCIEDADE: O CASO DO UFSCAR DESENVOLVIMENTO DE UMA FERRAMENTA PARA A GESTÃO DE UM SERVIÇO DE INFORMAÇÃO, BASEADO NA INTERAÇÃO UNIVERSIDADE E SOCIEDADE: O CASO DO UFSCAR Roniberto Morato do Amaral 1, Pedro Ivo Silveira Andretta 2,

Leia mais

Indicadores de Pesquisa, Desenvolvimento e Inovação (P,D&I) em Software e Serviços de TI: o Caso da Lei do Bem (nº 11.196/05)

Indicadores de Pesquisa, Desenvolvimento e Inovação (P,D&I) em Software e Serviços de TI: o Caso da Lei do Bem (nº 11.196/05) Universidade de Brasília Indicadores de Pesquisa, Desenvolvimento e Inovação (P,D&I) em Software e Serviços de TI: o Caso da Lei do Bem (nº 11.196/05) Rafael Henrique Rodrigues Moreira BRASÍLIA 2014 Universidade

Leia mais

Melhoria da Qualidade de Produto e de Processo de Software a partir da Análise de Indicadores de Teste

Melhoria da Qualidade de Produto e de Processo de Software a partir da Análise de Indicadores de Teste Melhoria da Qualidade de Produto e de Processo de Software a partir da Análise de Indicadores de Teste ERIKA DE FREITAS NITA CI&T SYSTEMS S/A www.cit.com.br Resumo Atualmente, a maioria das empresas de

Leia mais

Mestrado em Ciências Jurídicas Especialização em História do Direito 2015-16

Mestrado em Ciências Jurídicas Especialização em História do Direito 2015-16 Mestrado em Ciências Jurídicas Especialização em História do Direito Unidade curricular História do Direito Português I (1º sem). Docente responsável e respectiva carga lectiva na unidade curricular Prof.

Leia mais