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

Transcrição

1 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 1, Ricardo de Sousa Britto 1 1 Easii - Laboratório de Engenharia de Software e Informática Industrial DC - Departamento de Computação CCN - Centro de Ciências da Natureza UFPI - Universidade Federal do Piauí Brasil vanderson.moura.vm@gmail.com, pasn@ufpi.edu.br werney.zero@gmail.com, ricardoalr@ufpi.edu.br, rbritto@ufpi.edu.br Abstract. The formation of islands of knowledge is common when it comes to teamwork, especially in software development projects, where there are groups working on specific features. The formation of groups of developers who dominate part of the software may result in problems for the project. However, companies have difficulty avoiding the formation of these islands. Therefore, this paper proposes a method for identifying islands of knowledge, from the extraction of data from a Version Control System (VCS), formed during the development of software projects. Resumo. A formação de ilhas de conhecimento é algo comum quando se trata de trabalho em equipe, especialmente em projetos de desenvolvimento de software, onde existem grupos que trabalham em funcionalidades específicas. A formação de grupos de desenvolvedores que dominam parte do software pode acarretar em problemas para o projeto. Contudo, as empresas têm dificuldade em evitar a formação dessas ilhas. Com isso, este trabalho propõe um método para identificar ilhas de conhecimento, a partir da extração de dados de um Sistema de Controle de Versão (SCV), formadas ao decorrer do desenvolvimento de projetos de software. 1. Introdução Em um projeto de desenvolvimento de software é comum que a equipe participante seja dividida em grupos, de tal forma que cada grupo ataque uma parte específica do produto. Isso é algo comum não só apenas no âmbito de projetos de software, mas em qualquer projeto que envolva o trabalho em equipe. No entanto, a divisão do trabalho, especialmente em projetos de software, pode ocasionar o que chamamos de ilhas de conhecimento, que podem ser compreendidas como o domínio de parte do software, ou seja, do código associado a essa parte, por apenas um grupo de pessoas, ou em um nível mais extremo, por apenas uma única pessoa. Desse fato decorre a dificuldade de manutenção do software, sendo exigido que tal pessoa participe de toda e qualquer ação que envolva o componente do software de sua

2 propriedade [Teles 2004]. Neste trabalho é definido como especialista aquele desenvolvedor que domina uma entidade de código específica, o que caracteriza a formação de ilha de conhecimento. A existência de ilhas de conhecimento pode gerar grandes gargalos ao projeto, uma vez que, por mais que existam pessoas ou desenvolvedores para atuar em uma parte específica, sempre existe a necessidade de participação de um mesmo recurso. Outro complicador associado a formação de desenvolvedores que dominam componentes particulares é o comprometimento da qualidade e legibilidade do código, uma vez que existe, fundamentalmente, apenas uma opinião sobre uma área específica de um projeto. Contudo, é fato que as empresas atuais ainda enfrentam esse problema, por uma série de razões. Além disso, muitas delas não sabem que isso acontece, embora tenham grandes indícios disso, e sabem menos ainda como poderiam detectar esse tipo de complicação. Por conta disso, é proposto neste trabalho um método para identificar ilhas de conhecimento em projetos de software. A abordagem proposta se baseia na extração e análise de dados a partir de um Sistema de Controle de Versão ou CVS (do inglês Control Version System). A partir dos dados extraídos, são criadas métricas que indicam o quão cada desenvolvedor domina determinadas partes do projeto, com base nas operações realizadas sobre as mesmas. Este trabalho está estruturado como segue: a Seção 2 apresenta o referencial teórico, que descreve alguns conceitos necessários para um bom entendimento do trabalho; a Seção 3 apresenta alguns trabalhos relacionados; a Seção 4 descreve o método proposto; a Seção 5 discute a aplicação do método proposto em um estudo de caso; e a Seção 6 apresenta a conclusão e direções para trabalhos futuros. 2. Sistemas de Controle de Versão Geralmente, grandes projetos de desenvolvimento de software utilizam Sistemas de Controle de Versão (SCV), que são muito utilizados atualmente para armazenar o códigofonte, permitindo também um fácil compartilhamento de código entre toda a equipe de desenvolvimento. Além disso, esses sistemas de controle mantém um registro de todas as operações feitas no projeto e o desenvolvedor responsável por cada modificação realizada. A cada nova modificação feita sobre um arquivo ou conjunto de arquivos é gerado uma nova versão [Spinellis 2005], ou seja, um novo estado do projeto. Com isso, caso alguma alteração precise ser desfeita, basta apenas retornar à uma versão anterior Sistema de versionamento centralizado Neste tipo de sistema de controle de versão, todo o código do projeto fica armazenado em um único repositório central [De Alwis and Sillito 2009] ou servidor, onde todos os desenvolvedores podem obter a última versão de um arquivo do projeto e trabalhem simultaneamente sobre o mesmo arquivo. A ideia de um servidor centralizado pode ser um gargalo a esses tipos de sistemas, já que desenvolvimento será interrompido caso o servidor venha a ficar indisponível. Apesar disso, os riscos podem ser controlados e os SCV s centralizados são

3 comumente utilizados por oferecerem simplicidade de uso e uma rápida curva de aprendizagem [Brindescu et al. 2014]. Além disso, estes sistemas oferecem a possibilidade de respostas rápidas em relação ao envio e recebimento de arquivos do servidor. Dentre os sistemas de versionamento centralizados mais populares está o Subversion ou SVN, descrito em [Sussman et al. 2007] Sistema de versionamento distribuído Diferentemente do versionamento central, no SCV distribuído o comando de checkout (primeiro download) não é obtido apenas os arquivos, mas sim o projeto como um todo. Assim, cada máquina de trabalho da equipe servirá como um servidor, deixando de lado a exigência de um repositório central [De Alwis and Sillito 2009]. Estes tipos de sistemas surgiram para evitar problemas ligados a existência de um servidor único, o que acontece nos sistemas centralizados. Além de permitir a iteração simultânea da equipe de projeto com o servidor, o versionamento distribuído permite também a iteração direta entre membros da equipe de desenvolvimento [Rodriguez-Bustos and Aponte 2012]. 3. Trabalhos Relacionados Estudos somente voltados à identificação de ilhas de conhecimento formadas em projetos de software ainda não puderam ser identificados. Porém, alguns trabalhos que visam avaliar as atividades realizadas por desenvolvedores já foram feitos. Estas atividades representam por exemplo, o número de aquivos criados ou modificados, ou até mesmo o total de commits gerados, elas podem indicar informações relevantes a cerca de um projeto. Em [Fritz et al. 2014] é apresentado um modelo para definição do nível de conhecimento dos desenvolvedores sobre partes específicas do projeto, porém sem o apoio de SCV, como proposto neste trabalho. O modelo se baseia na apresentação de questionários aos desenvolvedores, que são formulados ao longo do desenvolvimento do projeto com auxílio de uma ferramenta. Além disso, a autoria e interações realizadas por cada desenvolvedor sobre o código-fonte são analisadas de maneira também automatizada. São apresentados estudos de caso com diferentes projetos para avaliação do modelo proposto. Os resultados obtidos mostram uma certa robustez do modelo proposto, que apresentou eficácia em variados ambientes de desenvolvimento de software. Já os autores em [Moura et al. 2014] utilizam SCV para extração de novas métricas formuladas sob operações (em nível de linha e arquivo) de adição, eliminação e modificações realizadas por desenvolvedores em arquivos do projeto. Porém, diferentemente deste trabalho, as métricas extraídas são utilizadas para representar o montante de operações realizadas pela equipe de desenvolvimento. Duas abordagens de comparação entre desenvolvedores são apresentadas. A primeira delas visa agrupar os desenvolvedores por classes hierarquicamente dominadas; a segunda mostra a similaridade entre os desenvolvedores a partir de uma apresentação gráfica. Um estudo de caso foi realizado em um projeto real de desenvolvimento de software. Os resultados obtidos foram apresentados ao gerente de projeto por meio de um questionário e segundo o gerente os resultados estariam muito próximos do esperado.

4 4. Método Proposto O método aqui proposto para identificação de ilhas de conhecimento é divido em duas etapas: extração de dados do SCV e determinação do grau de conhecimento dos desenvolvedores, ou seja, do número de alterações em nível de arquivo (ALT arquivo ) e linha (ALT linha ) feitas pelos por cada um. A Figura 1 apresentada estas etapas. Figura 1. Etapas do método proposto 4.1. Extração de dados do SCV Para extração de dados do SCV foi desenvolvido um Extrator que se utiliza de uma API para sistemas de versionamento centralizado. Os dados extraídos do SCV referem-se, por exemplo, às revisões do projeto e seus arquivos modificados, deletados ou adicionados, bem como o desenvolvedor responsável por cada revisão. Com o registro das operações realizadas pelos desenvolvedores, será possível obter a porcentagem de alterações (P alt ) realizadas por cada um em relação ao arquivos no projeto. Esta etapa será detalhada na subseção 4.2 seguinte Determinar o grau de conhecimento dos desenvolvedores Nesta etapa são obtidos o número de alterações em nível linha e arquivo. Para obter as alterações em nível de linha, é extraído o Diff do arquivo que foi alterado. O Diff indica a diferença unificada de um dado arquivo, ou seja, apresenta as linhas adicionadas, modificadas ou excluídas deste arquivo entre duas revisões específicas. A Figura 2 apresenta um exemplo de resultado obtido a partir da realização do Diff em um arquivo de teste. Figura 2. Exemplo de resultado da execução do Diff de um arquivo Pode-se perceber que o Arquivo A foi alterado entre as revisões X e Y. No exemplo dado, tem-se então uma operação de M OD caracterizada pela exclusão do conteúdo representado por linha 1 e adição de um novo, representado por linha 1.1. Há também uma operação de adição simples, caracterizada pela inclusão de um novo conteúdo (linha 2) no arquivo. Para determinar o número de alterações em nível de linha é considerado apenas os as operações de ADD e MOD. Com isso, é analisado a diferença unificada de todos arquivos modificados por cada desenvolvedor do projeto. É registrado também quem foram os desenvolvedores que

5 modificaram cada arquivo, bem como o número de alterações em nível de arquivo e linhas realizadas por cada um. P alt = ALT arquivo + ALT linha ALT total (1) A partir daí é possível, então, calcular a porcentagem de alterações realizadas pelos desenvolvedores, representada pela Equação 1, onde ALT arquivo representa a quantidade de vezes em que o arquivo foi alterado, ALT linha é dado pela soma entre o número de ADD e MOD em nível de linha, e ALT total representa todas as alterações realizadas pela a equipe de desenvolvimento sobre o mesmo arquivo. A porcentagem de alterações calculada indicará se um desenvolvedor é especialista ou não em uma dada entidade de código, ou seja, se há a formação de ilha de conhecimento. 5. Resultados O método proposto foi aplicado em um projeto real de uma empresa de desenvolvimento de software local. Foi analisado um módulo de um Sistema de Gestão de Planos de Saúde, que contava com uma equipe composta por 10 desenvolvedores. O sistema foi desenvolvido em linguagem Java e sua estrutura interna é composta por vários projetos e vários pacotes representando grupos funcionais específicos. A partir da extração e análise dos dados do projeto foi obtido a porcentagem de alterações P alt realizadas pelos desenvolvedores em cada arquivo do grupo funcional usado na avaliação. A Figura 3 apresenta essa porcentagem de alterações em cada classe de um grupo funcional do projeto, identificado aqui como P acote X. Figura 3. Porcentagem de alterações feitas pelos desenvolvedores Neste trabalho foi definido o percentual acima de 80% de alterações feitas por um único desenvolvedor para caracterizá-lo como especialista em uma entidade de código específica. Com base nisso, pode-se perceber que no P acote X são identificados três especialistas: o Desenvolvedor A mantem domínio sobre as Classes 2, 4, 5, 7, 9 e 10; o Desenvolvedor B domina 1 e 3, e por fim, o Desenvolvedor E é especialista na Classe 6. A partir dos resultados ficou evidenciado que a grande maioria das classes pertencentes ao pacote P acote X é associada a um especialista, ou seja, em 9 das 10

6 classes foram identificadas ilhas de conhecimento, com exceção da Classe 8, onde o Desenvolvedor A foi o responsável pelo maior percentual de alterações, porém atingindo aproximadamente 77% do total. 6. Conclusão e Trabalhos Futuros A identificação de ilhas de conhecimento em projetos de software é uma tarefa complexa. Neste trabalho foi desenvolvido um método baseado na extração de dados de um SCV que proporcionou bom referencial sobre as operações feitas pelos desenvolvedores sobre o código-fonte do projeto. O método apresentado neste trabalho se encontra em uma versão inicial, podendo ser ainda mais aprimorado, a fim de buscar resultados mais precisos. Como trabalhos futuros, por exemplo, as operações de DEL podem ser acrescentadas no cálculo do número de alterações em nível de linhas, considerando as deleções feitas no arquivo. Também podem ser consideradas as operações de ADD em nível de arquivo a fim avaliar a autoria de entidades de código, além de datas das operações realizadas pelos desenvolvedores, levando em consideração as alterações feitas mais recentemente. Contudo, os resultados obtidos foram satisfatórios, o método aqui proposto mostrou-se de grande valia na identificação de ilhas que formam-se ao longo do desenvolvimento de sistemas de software, o que proporcionará benefícios consideráveis para projetos, e consequentemente para as empresas responsáveis. Referências Brindescu, C., Codoban, M., Shmarkatiuk, S., and Dig, D. (2014). How do centralized and distributed version control systems impact software changes? In Proceedings of the 36th International Conference on Software Engineering, pages ACM. De Alwis, B. and Sillito, J. (2009). Why are software projects moving from centralized to decentralized version control systems? In Cooperative and Human Aspects on Software Engineering, CHASE 09. ICSE Workshop on, pages IEEE. Fritz, T., Murphy, G. C., Murphy-Hill, E., Ou, J., and Hill, E. (2014). Degree-ofknowledge: Modeling a developer s knowledge of code. ACM Transactions on Software Engineering and Methodology (TOSEM), 23(2):14. Moura, M. H. D. d., Nascimento, H. A. D. d., and Rosa, T. C. (2014). Extracting new metrics from version control system for the comparison of software developers. In Software Engineering (SBES), 2014 Brazilian Symposium on, pages IEEE. Rodriguez-Bustos, C. and Aponte, J. (2012). How distributed version control systems impact open source software projects. In Proceedings of the 9th IEEE Working Conference on Mining Software Repositories, pages IEEE Press. Spinellis, D. (2005). Version control systems. Software, IEEE, 22(5): Sussman, B. C., Brian, W. F., and Pilato, C. M. (2007). Version control with subversion: for subversion1. 5. TBA, California. Teles, V. M. (2004). Extreme programming. São Paulo: Novatec.