A abordagem de acompanhamento objetiva avaliar a contribuição individual do desenvolvedor através de quatro atributos: (i) volume da contribuição; (ii) complexidade média por método; (iii) introdução de bugs; (iv) contribuição em correção de bugs. Cada
atributo é avaliado através de um conjunto de métricas que, por sua vez, são extraídas através de minerações de repositórios de software. As métricas e as minerações usadas pela abordagem são baseadas naquelas apresentadas por (COSTA et al., 2014), com exceção das métricas que avaliam o atributo (ii) de complexidade média por método, que foi elaborado no contexto desta dissertação de mestrado.
A escolha das métricas baseadas em (COSTA et al., 2014) se justifica por duas razões: (i) permitem avaliar a contribuição individual dos desenvolvedores através de diferentes atributos, como produção de código-fonte, participação em correção de bugs e introdução de
bugs no sistema; e (ii) foi um trabalho conduzido por um membro do mesmo grupo de
pesquisa do qual em que o autor e orientador desta dissertação fazem parte, havendo, portanto, motivações relacionadas à continuidade da pesquisa realizada anteriormente. Diversas outras métricas poderiam ser usadas, contudo, com o intuito de não sobrecarregar o usuário da abordagem com muitas informações, optou-se por escolher um conjunto de métricas que avaliassem os quatro atributos apresentados na segunda coluna da Tabela 2.
Tabela 2 - Equivalência entre os atributos
Atributos avaliados por Costa (2012) Atributos avaliados pela abordagem
Tamanho dos commits Volume de contribuição
Resolução de bugs prioritários Contribuição em correção de bugs
Commits defeituosos Introdução de bugs
- Complexidade média por método
A Tabela 2 apresenta a equivalência entre os atributos avaliados por (COSTA, 2012) e a abordagem apresentada nesse capítulo. É importante salientar que as implementações das minerações desenvolvidas por (COSTA et al., 2014) sofreram algumas melhorias ao serem incorporadas na abordagem discutida neste capítulo, conforme discutido a seguir.
As primeiras melhorias foram realizadas nas minerações que quantificam o tamanho dos commits. O principal problema com as minerações originais era o fato de utilizarem o diff do próprio repositório de código (Subversion), que é limitado, pois não indica quais linhas de código foram modificadas. No Subversion, quando uma linha de código é modificada, ele considera que a linha original (antes de ser modificada) foi removida, e a linha modificada foi adicionada logo abaixo, conforme ilustrado no commit hipotético ilustrado na Figura 6.
Figura 6 - Modificando uma linha de código no Subversion (Costa, 2012)
No commit hipotético ilustrado na Figura 6, Alice, autora do commit, modificou o operador menor-ou-igual para o operador menor. O Subversion, contudo, não indica que aquela linha foi modificada, mas indica, com um sinal de menos, a linha antes da modificação, e com um sinal de mais indica a linha após a modificação. Tal mineração empregada por (COSTA, 2012) pode resultar em falsos-positivos, pois ela pode contabilizar que linhas foram adicionadas e removidas, quando na realidade elas foram apenas modificadas.
Esse problema foi corrigido quando essas métricas foram incorporadas à abordagem desde trabalho. Para solucioná-lo, a mineração não utiliza mais o diff do Subversion, mas sim uma biblioteca externa de diff textual7. Ou seja, quando a mineração identifica um artefato Java modificado no commit, ela faz o download do conteúdo desse artefato antes e depois da modificação, e usa esse diff para contabilizar exatamente quantas linhas foram adicionadas, modificadas e removidas. Dessa forma, a melhoria realizada nessas métricas não só corrige o problema dos falso-positivos, como também oferece um novo e importante indicador, que é a quantidade exata de linhas modificadas.
Outro indicador que foi incorporado a abordagem, mas que não existia na suíte de métricas proposta originalmente por (COSTA, 2012) é a métrica que quantifica o número de métodos removidos pelo desenvolvedor. Outra melhoria realizada foi em relação à identificação de commits defeituosos. A mineração usada por (COSTA, 2012) (Seção 2.3.1.1) possui apenas uma única estratégia para identificação de commits defeituosos. Uma nova estratégia foi elaborada e incorporada à abordagem desta dissertação, que identifica commits
defeituosos de código que ainda não foram para produção. Os detalhes dessa nova estratégia são apresentados na Seção 3.3.3.
Dependendo da dinâmica de trabalho de onde as métricas estão sendo aplicadas, a estratégia adotada por (COSTA, 2012) para quantificar o número de bugs prioritários resolvidos por cada desenvolvedor pode apresentar alguns problemas. O primeiro problema pode ocorrer quando não for o desenvolvedor que finalize/conclua a tarefa de correção de erro prioritário. Dependendo da dinâmica de trabalho, isso pode ser realizado por um gerente de software, por um testador ou mesmo alguém externo à equipe.
Devido à estratégia de atribuir a conclusão da tarefa ao desenvolvedor que mudou seu estado para concluída/finalizada, outro problema que pode ocorrer é quando mais de um desenvolvedor tiver contribuído para a conclusão da tarefa. Apenas o desenvolvedor que alterou o estado da tarefa será considerado.
Dessa forma, outra mudança realizada em relação às métricas originais propostas por (COSTA, 2012) foi aplicada à métrica de resolução de bugs prioritários. Conforme o nome deixa claro, a métrica considera apenas tarefas de correção de bugs de alta prioridade, portanto não contabiliza tarefas de correção de menor prioridade, e dessa forma pode dar a falsa interpretação de que um dado desenvolvedor possa ter uma contribuição na correção de erros menor do que de fato ele teve durante o período analisado. A métrica relativa à contribuição em correção de bugs, proposta na abordagem avaliada por este estudo, leva em conta qualquer tarefa de correção, independente da prioridade atribuída a ela.
Finalmente, a abordagem proposta nesta dissertação é composta por uma nova métrica que é capaz de identificar como o desenvolvedor de software distribuiu a complexidade ciclomática de sua contribuição, permitindo que o gerente de software possa avaliar a qualidade da codificação de cada desenvolvedor, tendo em vista o esforço de manutenção futuro do código que aquele desenvolvedor produz. Os detalhes dessa mineração são apresentados na Seção 3.3.2.