Hareland and Rampersad Model

A metodologia utilizada para a condução dos estudos desta dissertação é composta por quatro atividades: (i) Seleção do Projeto, (ii) Classificação dos desenvolvedores, (iii) Mineração de Repositórios de Software e (iv) Análise dos resultados obtidos. A Figura 3.3 (ver Apêndice A) apresenta a sequencia em que elas ocorrem. Cada atividade é descrita a seguir:

Seleção dos projetos. Primeiramente, ocorreu a seleção dos projetos a serem analisados. O critério principal considerado para a seleção foi os tipos de repositórios de software que o projeto disponibilizou. Por exemplo, os sistemas de controle de versão, listas de e-mails, assim como os sistemas de controle de mudanças, precisaram ser compatíveis com os tipos de minerações, que podem ser coletados pela ferramenta de suporte disponível.

Classificação dos desenvolvedores através do uso de técnicas de mineração de processos. Posteriormente, ocorreu o trabalho de classificação dos desenvolvedores por meio do uso de técnicas de mineração de processos. Tal classificação envolveu a caracterização dos papéis assumidos pelos desenvolvedores atuantes no projeto por meio da contribuição realizada por cada um deles nos os repositórios dos projetos. Para que um desenvolvedor fosse classificado em um papel específico ele teve que atender aos critérios para este papel. Os critérios de cada papel são explicados na Seção 3.4.1.

Mineração de repositórios de software. Uma vez tendo classificado os desenvolvedores, foram realizadas as minerações de repositórios objetivando avaliar a contribuição dos desenvolvedores por meio das ações que estes realizaram durante o desenvolvimento. As minerações executadas em ambos os estudos foram: (i) mineração de commits defeituosos, (ii) mineração da complexidade dos commits, e (iii) mineração de bugs prioritários.

Análise dos resultados obtidos. Após a execução das minerações de repositórios de software, ocorreu a etapa de análise dos resultados. É nesta etapa que se procura responder as perguntas de pesquisa definidas para guiar os estudos. Por exemplo, pode-se identificar que os desenvolvedores periféricos de um projeto open source realizam mais commits defeituosos do que os desenvolvedores core e ativos do mesmo projeto.

3.4.1. Procedimento para a classificação dos desenvolvedores

Na etapa de classificação dos desenvolvedores, os papéis foram baseados na classificação definida em (NAKAKOJI, YAMAMOTO, et al., 2002) e os critérios utilizados para enquadrar os desenvolvedores em cada papel foram baseados nos critérios apresentados em (PONCIN, SEREBRENIK e VAN DEN BRAND, 2011), pois o trabalho também realiza uma classificação de desenvolvedores a partir das ações dos repositórios, utilizando mineração de processos. A seguir são apresentados, de forma resumida, os requisitos necessários para a classificação em cada papel:

Líder do projeto. É envolvido desde o inicio do projeto, e é o responsável pela visão e direcionamento geral do projeto. Os requisitos para o líder do projeto são:

• Estar envolvido desde o início do projeto

• Deve ter adicionado arquivos no repositório de código • Deve ter modificado arquivos no repositório de código

Desenvolvedor core. É o desenvolvedor que está envolvido no projeto por um período relativamente longo. Para responder as questões de pesquisa, os desenvolvedores core serão considerados como os mais experientes. Os requisitos são:

• Deve possuir fechamento de bugs no sistema de controle de mudanças • Deve estar contribuindo no projeto por 36 meses

• Deve ter um maior número de modificações no repositório de código do que a média de desenvolvedores

• Deve possuir adições no repositório de código

Desenvolvedor ativo. São os desenvolvedores que contribuem de maneira regular com funcionalidades e também corrigem defeitos, no entanto não precisam ter 36 meses no projeto. Os requisitos são:

• Deve possuir fechamento de bugs no sistema de controle de mudanças • Deve possuir modificações no repositório de código

• Deve possuir adições no repositório de código

• Deve possuir um período de regularidade com, pelo menos, uma contribuição a cada mês.

Desenvolvedor periférico. São os desenvolvedores com contribuições esporádicas e irregulares para as funcionalidades do sistema e geralmente possuem um período de envolvimento pequeno no projeto, embora isto não seja uma regra. Os requisitos para este papel são:

• Deve possuir modificação no repositório de código

• Deve possuir adições de arquivos no repositório de código • Não precisa ter correções de defeitos

Corretor de defeitos. São os desenvolvedores que corrigem os defeitos descobertos tanto por eles mesmos quanto pelos outros. Os requisitos são:

• Deve possuir fechamento de bugs no sistema de controle de mudanças • Deve possuir modificações no repositório de código

• Não deve estar incluso nas outras categorias

Reportador de defeitos. Este papel é a contraparte do testador nos projetos open source. Os reportadores de defeitos precisam das seguintes ações para serem classificados

como tal:

• Deve possuir abertura de bugs no sistema de controle de mudanças • Deve possuir emails enviados na lista de email

Leitor. Realiza atividades que vão além da utilização do sistema, ele inspeciona o código e entende como o sistema funciona.

Usuário passivo. É atraído pela funcionalidade do sistema open source, mas não tem a intenção de contribuir com ele.

Vale ressaltar que nenhum desenvolvedor pode ocupar dois papéis ao mesmo tempo. Para os estudos conduzidos neste trabalho, apenas os papéis líder de projeto, desenvolvedor core,

desenvolvedor ativo, desenvolvedor periférico e corretor de defeitos foram considerados na

classificação. O papel reportador de defeitos, por não possuir commits e não contribuir com modificações diretas no código, não está incluso no objetivo do estudo, ou seja, a avaliação da contribuição sob as perspectivas dos commits realizados e bugs solucionados. Os papéis leitor e usuário passivo também não foram considerados pelos mesmos motivos. A seguir, é apresentado o procedimento que foi utilizado para realizar a classificação dos desenvolvedores em papéis. A Figura 3.4 (ver Apêndice A) apresenta o procedimento executado na classificação. Primeiramente, a ferramenta FRASR é utilizada para coletar as atividades que os desenvolvedores realizaram, nos diferentes repositórios.

Por exemplo, para cada desenvolvedor, a ferramenta coleta quantos e-mails foram enviados, quantas adições de arquivos foram feitas, quantos defeitos foram fechados por eles, etc. O FRASR consegue identificar o mesmo desenvolvedor em diferentes repositórios

através do algoritmo de developer matching, que é baseado na heurística definida em (PONCIN, SEREBRENIK e VAN DEN BRAND, 2011). Tal heurística consiste em identificar a correspondência entre as contas (aliases) dos desenvolvedores nos diferentes tipos de repositórios. Após a identificação das ações realizadas pelos desenvolvedores, um arquivo de log é gerado pelo FRASR no formato MXML. Este arquivo é utilizado para alimentar a ferramenta ProM que realiza a execução dos algoritmos de mineração de processos. Os algoritmos utilizados para os estudos desta dissertação foram: o OTM e o DCA (Seção 2.3.1.2) (Seção 2.3.1.1).

As Figuras 3.5 e 3.6 (ver Apêndice A) demonstram a utilização dos algoritmos OTM e DCA, respectivamente. A técnica OTM exibe, para cada desenvolvedor, a quantidade de ações realizadas por eles em um determinado repositório de software. Por exemplo, a Figura 3.5 ilustra que o desenvolvedor Linus possui 4.216 envios de emails e fechou 2.640 issues. A intenção do algoritmo é mostrar para o usuário, aquelas pessoas que estão trabalhando nas mesmas tarefas em um determinado processo. No entanto, no contexto desta pesquisa, a técnica foi utilizada somente para auxiliar na contabilização das atividades.

Já a técnica DCA demonstra quais ações o desenvolvedor realizou ao longo do tempo. Por exemplo, na Figura 3.6 (ver Apêndice A), um ponto azul indica que um e-mail foi criado naquele instante, enquanto que um ponto roxo indica que uma modificação de arquivo no repositório de código foi realizada. A técnica DCA é importante na mineração de processos, pois permite que as ações dos desenvolvedores (casos) sejam analisadas ao longo do tempo, o que permitiu a classificação deles em papéis como desenvolvedor core, ou desenvolvedor

periférico. Tendo explicado a metodologia utilizada nos estudos conduzidos por este trabalho,

o capítulo as seguir (Capítulo 4) descreve a aplicação desta metodologia em cada estudo.

4. ESTUDOS EMPÍRICOS DE AVALIAÇÃO DA CONTRIBUIÇÃO DE