Ameaças à validade

Esta seção apresenta as ameaças que podem comprometer os resultados obtidos nos estudos empíricos desta dissertação. Primeiramente, a Seção 4.3.1 apresenta a ameaça referente à mineração de commits defeituosos realizada em ambos os estudos e, em seguida, a Seção 4.3.2 apresenta as ameaças referentes à amostra de dados utilizada para as minerações

de commits defeituosos e tamanho de commits, ambas realizadas no projeto da empresa

privada. Por fim, a Seção 4.3.3 explana a ameaça relacionada à classificação utilizada para os projetos de software investigados.

4.3.1. Ameaça à validade da mineração de commits defeituosos

A mineração de repositório de software, tanto a executada no projeto do ArgoUML, quanto no projeto da empresa privada, podem não estar contabilizando somente as mudanças que injetaram defeitos no momento em que foram introduzidas no repositório de código, mas podem estar contabilizando mudanças que a partir de uma determinada mudança de requisito passaram a ser um defeito. Por exemplo, na Figura 4.55 (ver APÊNDICE A) o autor João adicionou um código para uma aplicação on-line de um cinema, que verifica a faixa etária do cliente. Caso a faixa etária seja compatível com a do filme, o sistema habilita a compra do ingresso.

Um requisito da aplicação mudou, e agora é possível as pessoas abaixo da faixa etária comprarem os ingressos desde que apresentem os responsáveis por delas. O autor Pedro adicionou as seguintes alterações no código Figura 4.56 (ver APÊNDICE A), no entanto, esqueceu-se de adaptar o método assistirFilme1(), o que gera um defeito. Estando ciente do defeito, a equipe solicita que a Aline corrija o problema. A Figura 4.57 (ver APÊNDICE A) ilustra a correção feita pela Aline.

A mineração de commits defeituosos aplicada nos estudos, ao identificar o commit da Aline na revisão 3, localizará o local da correção e executará o comando blame para identificar qual o commit que foi responsável por introduzir a linha e que teve de ser modificada para que o bug fosse corrigido. O autor apresentado pelo comando blame, será o João, no entanto, o conteúdo adicionado pelo João já esteve certo, apenas o requisito que mudou. Dessa forma, cenários como esse podem levar a identificação de falsos commits defeituosos.

Uma possível maneira de se lidar com esta ameaça seria, ao encontrar um commit defeituoso, procurar identificar se houve alguma requisição de nova funcionalidade para o sistema (ex: verificar o sistema de controle de mudanças) entre o período que o commit

defeituoso foi gerado e o período que o commit que corrigiu o defeito foi gerado. Desta

forma, os commits defeituosos que foram corrigidos por outros commits após várias requisições de funcionalidades novas poderiam ser analisados separadamente.

4.3.2. Ameaça à validade das minerações de commits defeituosos e tamanho de commits do projeto da empresa privada

As minerações de commits defeituosos e tamanho de commits, executadas no projeto da empresa privada, não permitiu o processamento de todos os commits dos desenvolvedores, dado o seu volume, até a apresentação deste trabalho. Portanto, os dados utilizados para realizar a análise foram parciais, embora representem um número bastante significativo. A Tabela 4.42 (ver APÊNDICE B) exibe o período das amostras utilizadas para cada mineração.

O período da amostra utilizada para a análise dos resultados da mineração de commits defeituosos foi de 1º de janeiro de 2008 a 1º de janeiro de 2009, enquanto que o da minheração de tamanho de commits foi de 4 de abril de 2008 a 8 de Agosto de 2008. Portanto, os dados computados podem não representar o a situação real da contribuição dos desenvolvedores no projeto referente a estas duas minerações. Pretendemos até a conclusão desta dissertação, finalizar tais minerações com o objetivo de verificar se os resultados já obtidos com a amostra analisada refletem de fato os resultados de commits de todo o projeto.

4.3.3. Ameaça à validade da classificação de desenvolvedores

Na condução de ambos os estudos empíricos realizados nesta dissertação, houve uma etapa de classificação dos desenvolvedores de acordo com as ações que eles realizaram ao longo dos repositórios. No projeto ArgoUML, as contas dos desenvolvedores diferem entre os repositórios de software, por exemplo, para a lista de e-mails é utilizada conta

sergio.lopes@tigris.org, enquanto que no repositório de código, a conta utilizada é “slopes”. Para identificar que duas contas diferentes dizem respeito ao mesmo desenvolvedor, utilizamos a heurística da ferramenta FRASR. No entanto, caso ocorra alguma falha em encontrar as contas, pode ocorrer de se conseguir capturar apenas a conta que possui ações no

repositório de código e não a que possui ações na lista de e-mails. Contudo, pelo fato das minerações conduzidas neste trabalho utilizarem primordialmente as informações dos repositórios de código, todas as contas encontradas que possuíram ações de adições,

modificações ou deleções de arquivos foram consideradas, independente de possuírem ou não

ações na lista de e-mails ou no sistema de controle de mudanças. Alem disto, para a classificação dos papéis de desenvolvedor core, ativo e periférico, as ações na lista de e-mails não são requisitos essenciais, portanto, caso não se encontrasse as ações neste repositório, não se teria um impacto significativo.

4.4.Sumário

Este capítulo descreveu os estudos que foram realizados como parte deste trabalho de mestrado. Primeiramente, a classificação dos desenvolvedores para cada projeto investigado foi descrita. Posteriormente, cada mineração executada foi explanada e, finalmente, os resultados obtidos em cada mineração foram descritos para ambos os projetos: ArgoUML e o projeto da empresa privada.

5. BACKHOE: INFRAESTRUTURA DESENVOLVIDA PARA A MINERAÇÃO DE