5. Experimento e Análise dos Resultados
5.1. Avaliação do Presley
5.1.4. Instrumentação
A simulação foi produzida tendo como entrada os registros da lista de discussão, o código- fonte, seu respectivo histórico na ferramenta de controle de versão e a documentação do projeto, disponíveis em http://lucene.apache.org.
A primeira informação inserida no Presley foi a documentação do projeto, pois sem o seu conteúdo não seria possível identificar o assunto abordado nas mensagens enviadas. O Javadoc (disponível em http://lucene.apache.org/java/2_4_1/index.html) foi utilizado para a extração das palavras-chaves que descrevem os conhecimentos envolvidos no projeto Lucene. Cada descrição de classe ou subpacote no Javadoc teve seu conteúdo transferido para arquivos com extensão txt e representava o conhecimento incluso no desenvolvimento do pacote principal na qual a classe ou subpacote estava contido.
O passo seguinte foi a inclusão das mensagens, para representar o nível de interesse dos desenvolvedores sobre os conhecimentos anteriormente definidos. Como os e-mails da lista de discussão do projeto Lucene estavam agrupados por mês e ano de envio em arquivos no formato MBox foi necessário desenvolver um sistema aparte para coletar os seguintes dados:
• Quem enviou o primeiro e-mail de uma discussão;
• Qual foi o assunto, o conteúdo e a data de envio do e-mail anterior;
• E quem foram os demais participantes da discussão realizada.
Após a identificação do conhecimento abordado, os dados coletados das discussões realizadas no ano de 2008 foram inseridos no banco de dados do Presley. Ao todo foram utilizados 6.327 e-mails registrados em 2008 e enviados por 292 participantes da lista de discussão. Entre os participantes, 17 deles também tinham registros de alterações no histórico do código-fonte.
52 Os registros de discussões realizadas no ano de 2009 foram armazenados em dois arquivos para a execução do experimento. O primeiro arquivo continha dados sobre o e-mail que iniciou a discussão entre os desenvolvedores e serviu como a mensagem de solicitação de recomendação de especialistas, enquanto o segundo arquivo continha a identificação das pessoas que responderam o e-mail e serviu para confrontar com os especialistas recomendados pelo Presley.
Através da ferramenta de controle de versão utilizada no projeto Lucene foram coletadas as versões do código-fonte necessárias para a execução do experimento e o histórico de alterações dos arquivos. O histórico na ferramenta de controle de versão conteve 10.764 registros de alterações de código fonte, distribuído entre setembro de 2001 a julho de 2009.
5.1.5.
Execução
Para a execução do experimento, foram selecionados todos os e-mails enviados de janeiro a junho do ano de 2009 que haviam recebido ao menos uma resposta. Os e-mails coletados (375) foram agrupados pelos meses de envio, totalizando 1187. A Tabela 5-1 apresenta a quantidade de e-mails por quantidade de respostas enviadas e a Tabela 5-2 por mês de envio.
Tabela 5-1: Quantidade de e-mails por quantidade de respostas enviadas
Quantidade de respostas enviadas Quantidade de e-mails
1 185 2 89 3 41 4 31 5 8 6 8 7 6 8 3 9 1 10 1 14 1 15 1
Com o objetivo de também simular a evolução da implementação do software junto com a comunicação realizada, seis versões dos arquivos de código fonte do Lucene, representando
53 cada mês de envio de e-mail, foram extraídos da ferramenta de controle de versão do projeto. A Tabela 5-3 contém as informações sobre cada versão utilizada.
Tabela 5-2: Quantidade de e-mails por Mês
Mês Quantidade de e-mails Janeiro 51 Fevereiro 37 Março 54 Abril 86 Maio 59 Junho 88
Tabela 5-3: Informações das versões do código fonte utilizado
Data da modificação Mês de referência Quantidade de linhas de código-fonte
30/12/2008 Janeiro 59.064 30/01/2009 Fevereiro 61.326 28/02/2009 Março 61.604 31/03/2009 Abril 62.214 30/04/2009 Maio 63.917 31/05/2009 Junho 65.093
Durante a execução do experimento, os arquivos extraídos do Javadoc eram adicionados ao Presley e relacionados ao conhecimento equivalente. Para isso, os nomes dos pacotes principais do Lucene foram cadastrados como os títulos dos conhecimentos existentes e as palavras-chaves que formam o conhecimento eram extraídas dos arquivos txt que descreviam as classes pertencentes aos pacotes descritos.
Para obter as recomendações, os e-mails com as questões dos desenvolvedores e os arquivos de código-fonte eram sempre utilizados com o mesmo mês de referência, ou seja, quando os e-mails do experimento eram de janeiro, os arquivos deviam ser do mesmo mês.
5.1.6.
Análise e Interpretação
Ao fim da execução do projeto, as recomendações realizadas pelo Presley foram coletadas para o cálculo das três perspectivas: precisão, cobertura e acurácia. A análise foi realizada utilizando gráficos, com recomendações de até sete especialistas, feitos por cada entrada utilizada pelo Presley.
54 Como descrito anteriormente, o Presley utiliza como parâmetros de entrada a comunicação realizada pelos desenvolvedores e os registros de alterações no código fonte do software em desenvolvimento. Para melhor entendimento dos gráficos apresentados, a comunicação, contida na lista de e-mails do projeto Lucene, será rotulada como C e o histórico de alterações no código fonte como H.
Avaliando a importância do histórico do código-fonte: esta análise foi realizada no
objetivo de verificar se o uso do histórico de alterações no código-fonte melhora a qualidade das recomendações realizadas pelo Presley.
A Figura 5-1 apresenta a precisão geral (com todos os e-mails extraídos da lista de discussão do Lucene) e a precisão nos casos de sucesso (no qual ao menos um especialista foi recomendado corretamente) das recomendações realizadas pelo Presley, apenas com a comunicação dos desenvolvedores (+C -H) e com as duas entradas (+C +H); enquanto que a Figura 5-2 apresenta a cobertura, e a Figura 5-3, a acurácia das recomendações realizadas pelo Presley nas mesmas condições.
55
Figura 5-2: Comparativo da Cobertura Geral (a) e de Sucesso (b) apenas com a Comunicação
Figura 5-3: Comparativo da acurácia apenas com a Comunicação
Apenas pelo gráfico, não é possível identificar a melhor precisão, cobertura e acurácia entre as recomendações realizadas com e sem o histórico do código fonte. Porém, ao calcular a média dos valores encontrados, presente na Tabela 5-4, a precisão geral (28,91%), a cobertura geral (49,90%) e acurácia (71,23%) das recomendações feitas pelo histórico de modificações de código fonte mais a comunicação realizada pelos desenvolvedores melhoram as recomendações do Presley comparado ao simples uso da comunicação dos desenvolvedores (28,73%, 49,54% e 70,97%).
56
Tabela 5-4: Média comparativa das métricas coletas nas recomendações apenas com a comunicação
+C+H +C-H
Geral Com Sucesso Geral Com Sucesso
Precisão 0,289196372 0,427390715 0,287393197 0,426398276
Cobertura 0,49901542 0,696508854 0,495351927 0,694336646
Acurácia 0,712380952 0,709714286
A precisão encontrada rejeita a hipótese nula Hn1 e valida a hipótese alternativa Ha1:
precisão do Presley >= precisão apenas da comunicação realizada no projeto; a cobertura
rejeita a hipótese nula Hn2 e valida a hipótese alternativa Ha2: cobertura do Presley >=
cobertura apenas da comunicação realizada no projeto; e a acurácia rejeita a hipótese nula Hn3 e valida a hipótese alternativa Ha3: acurácia do Presley >= acurácia apenas da
comunicação realizada no projeto.
Avaliando a importância da comunicação: a intenção é identificar se a comunicação
realizada entre os desenvolvedores colabora na qualidade das recomendações realizadas pelo Presley.
A Figura 5-4 apresenta a precisão geral e nos casos de sucesso das recomendações realizadas; a Figura 5-5, a cobertura geral e nos casos de sucesso; e a Figura 5-6, acurácia das recomendações.
57
Figura 5-5: Comparativo da Cobertura Geral (a) e de Sucesso (b) apenas com o histórico do código-fonte
Figura 5-6: Comparativo da acurácia apenas com o histórico do código-fonte
A média da precisão geral e com sucesso da Tabela 5-5 (28,11% e 52,58%) demonstra que a precisão das recomendações feitas pelo Presley apenas pelo histórico das alterações de código fonte é superior ao uso das duas entradas disponíveis (28,92% e 42,73%), impossibilitando rejeitar a hipótese nula Hn4 e validar a hipótese alternativa Ha4: precisão do
Presley >= precisão apenas do histórico do código-fonte.
Tabela 5-5: Média comparativa das métricas coletas nas recomendações apenas com o histórico do código fonte
+C+H -C+H
Geral Com Sucesso Geral Com Sucesso
Precisão 0,289196372 0,427390715 0,281165533 0,525765646
Cobertura 0,49901542 0,696508854 0,37247619 0,67976225
58 Apesar de não obter a precisão desejada, o principal objetivo do Presley é encontrar ao menos uma pessoa que realmente possa ajudar um desenvolvedor com dificuldades na implementação do código fonte. Por isso, os valores de cobertura e de acurácia são considerados mais importantes na definição da qualidade das recomendações feitas pelo Presley.
As médias de cobertura (49,90% e 69,65%) e acurácia (71,24%), presente na Tabela 5-5, evidenciam que o histórico de modificações de código fonte mais a comunicação realizada pelos desenvolvedores melhoram as recomendações do Presley comparado ao simples uso da comunicação no projeto, com cobertura geral de 37,24% e de sucesso 67,98% e acurácia de 54,63%.
Através dos resultados de cobertura e acurácia encontrados, é possível rejeitar a hipótese nula Hn5 e validar a hipótese alternativa Ha5: cobertura do Presley >= cobertura
apenas do histórico do código-fonte, assim como rejeitar a hipótese nula Hn6 e validar a
hipótese alternativa Ha6: acurácia do Presley >= acurácia apenas do histórico do código-
fonte.
Apesar da hipótese alternativa Ha4 não ter sido válida, as demais hipóteses aprovadas
demonstram que as recomendações realizadas pelo Presley são melhores quando existe a combinação do histórico de alterações no código fonte e da comunicação realizada no projeto.
Os resultados encontrados indicam que a comunicação ocorrida no projeto é uma fonte de informação importante na descoberta dos especialistas no código-fonte, pois, ao analisar os conhecimentos envolvidos nas mensagens trocadas entre os desenvolvedores, é possível saber suas preferências e capacidade em responder as solicitações de ajuda, esta última não é possível apenas com análise do histórico de alterações no código-fonte. Outro fator positivo na comunicação está na possibilidade do desenvolvedor ter a liberdade de demonstrar interesses em determinadas partes do projeto, mas que ainda não teve possibilidade de atuar. Estes fatores podem contribuir numa melhor identificação dos especialistas no projeto quando se utiliza os registros de comunicação entre os desenvolvedores.
59
Avaliando a qualidade das recomendações para cada fonte de dados: o objetivo em realizar
esta análise é averiguar se a comunicação tem um grau de relevância maior na identificação dos especialistas confrontado ao histórico de alterações no código fonte.
A Figura 5-7 apresenta a precisão geral e nos casos de sucesso das recomendações realizadas; a Figura 5-8, cobertura; e a Figura 5-9, acurácia das recomendações.
Figura 5-7: Precisão Geral (a) e de Sucesso (b) das Recomendações de cada Fonte de Dados do Presley
60
Figura 5-9: Acurácia das Recomendações de cada Fonte de Dados do Presley
Através da Tabela 5-6, com a média dos valores obtidos nas figuras apresentadas anteriormente, é possível determinar a melhor fonte de informação para o Presley. Apesar de não obter uma boa precisão nos casos de sucesso (42,64% apenas com a comunicação e 52,58% com histórico do código), a comunicação superou o histórico de código fonte nas demais métricas. As coberturas geral e com sucesso obtidas pelas recomendações feitas com o histórico de código fonte foram de 37,25% e 67,98% contra 49,54% e 69,43% conquistados pela comunicação. Na acurácia, o mesmo cenário é repetido: a comunicação, com 70,97%, é melhor que o histórico de código fonte, com 54,63%.
Os valores indicam que a comunicação realizada entre os desenvolvedores no projeto tem um grau de importância maior comparado ao histórico de alterações no código fonte.
Tabela 5-6: Média comparativa das métricas coletas nas recomendações com e sem comunicação
+C-H -C+H
Geral Com Sucesso Geral Com Sucesso
Precisão 0,287393197 0,426398276 0,281165533 0,525765646
Cobertura 0,495351927 0,694336646 0,37247619 0,67976225
Acurácia 0,709714286 0,546285714
Avaliando a qualidade das recomendações comparada a outras ferramentas: para verificar
se o Presley realiza recomendações de qualidade seria necessário encontrar a melhor ferramenta disponível na literatura e executar o mesmo experimento realizado com o Presley. Como não foi possível realizar essa atividade durante o experimento as hipóteses nulas Hn7, Hn8 e Hn9 não puderam ser testadas; porém, através das métricas de precisão,
61 cobertura e acurácia das abordagens discutidas no capítulo 3 e disponíveis em (McDonald, 2001; Minto e Murphy, 2007; Sindhgatta, 2008; Ye et al., 2007; Anvik et al., 2006; Kagdi et al., 2008; Vivacqua e Lieberman, 2000), foi possível avaliar as recomendações feitas pelo Presley.
A Tabela 5-7 apresenta informações sobre a precisão, cobertura e acurácia das abordagens utilizadas por cada autor identificado na literatura e pelo Presley. Da mesma forma como foram feitas as avaliações anteriores, os valores adotados para avaliar as recomendações do Presley foram divididos entre geral e casos de sucesso. Nesta tabela se encontram o resultado das recomendações do Presley realizadas com o uso das duas fontes de informação.
Tabela 5-7: Métricas coletadas dos artigos com modelos de descoberta de especialistas em código-fonte
Autores Projeto de Experimento Precisão Cobertura Acurácia
(McDonald, 2001) Empresa identificada como MSC
72% (Minto e Murphy, 2007) Eclipse,
Bugzilla, Firefox 37% 28% 16% 49% 38% 21% (Sindhgatta, 2008) Projeto identificado
apenas como de
ferramenta de
modelagem UML
68% 93%
(Ye et al., 2007) Lucene 75%
(Anvik et al., 2006) Firefox, Eclipse, Gcc 59% 57% 06% 2% 7% 0,3% (Kagdi et al., 2008) kdelibs, kdenetwork,
kdebase, kdemulimedia, Kdesdk, Apache - Httpd, gcc, koffice Varia de 43% a 82% entre os projetos utilizados (Vivacqua e Lieberman, 2000) Experts-Exchange fórum 85%
Presley (Geral) Lucene 29% 50%
Presley (Com Sucesso) Lucene 43% 70% 71%
Apesar dos valores de precisão (29%) e cobertura (50%) obtidos pelo Presley na situação geral não serem ruins, o filtro das mensagens selecionadas para o experimento influenciou no resultado final do experimento ao não avaliar se o conteúdo do e-mail era suficiente para identificar o conhecimento envolvido. Porém, nos casos de sucesso, é
62 possível representar os e-mails no qual o Presley conseguiu identificar o conhecimento abordado ou algum código-fonte presente no Lucene, por isto os valores dos casos de sucesso serão adotados como critério de avaliação com outras ferramentas.
A abordagem desenvolvida pelo Sindhgatta (2008) obteve a melhor precisão (68%) e cobertura (93%) comparada às demais abordagens. No experimento realizado, um membro chave do projeto foi escolhido para especificar dez atividades e os conceitos chaves que as envolvem. Baseado dos conceitos chaves informados, a abordagem desenvolvida recomendou um conjunto de desenvolvedores para as atividades, que foram comparadas a lista oito de desenvolvedores indicados pelo membro chave.
Diferente da abordagem de Sindhgatta (2008), o Presley busca identificar automaticamente os conceitos (tratados como conhecimentos) nas mensagens de dúvidas dos desenvolvedores para em seguida recomendar os especialistas e o volume de solicitações de especialistas utilizados no experimento (375 e-mails) foi muito superior ao volume adotado por Sindhgatta (2008) (10 atividades). Por conta destas diferenças, a abordagem analisada obteve vantagens que dificultam a comparação entre as métricas de precisão e cobertura coletadas no Presley.
Com a exclusão do trabalho do Sindhgatta (2008), a melhor precisão obtida está no trabalho desenvolvido por Anvik e colegas (2006) (com 59% no melhor caso). No experimento realizado, os dados de entrada foram coletados do repositório de bugs do projeto selecionado, entre setembro de 2004 a maio de 2005, que permitiu obter um conjunto de 9.752 relatórios de bugs para treinar a maquina de aprendizagem (machine learning) desenvolvida. Após realizar a filtragem dos relatórios de bugs registrados em maio de 2005, apenas 22 relatos foram selecionados para encontrar os especialistas. Da mesma forma, abordagem escolhida pelos autores também dificulta a comparação direta. Assim como no Presley, esta abordagem classifica o conteúdo textual da sua fonte de informação de forma automática. Apesar de não conseguir uma precisão melhor (43%) é possível que em outros projetos o Presley obtenha melhores percentuais, da mesma forma como aconteceu no próprio trabalho realizado por Anvik e colegas (2006).
Observando agora a melhor cobertura, principal métrica observada no experimento realizado, a abordagem desenvolvida por Minto e Murphy (2007) conseguiu a melhor
63 porcentagem entre os trabalhos coletados (49%), porém foi superada pela porcentagem conquistada pelo Presley (70%). No experimento realizado por esta abordagem, os dados de entrada foram coletados do repositório de bugs do projeto selecionado no período de dois anos e permitiu obter um conjunto de 182 bugs como solicitações de especialistas. A abordagem de Minto e Murphy (2007) tem o mesmo objetivo do Presley, conseguir de proporcionar um meio de comunicação entre desenvolvedores que precisam de ajuda para resolver algum determinado problema no código-fonte.
Na última métrica utilizada, Vivacqua e Lieberman (2000) desenvolveu uma abordagem no qual conseguiu 85% de acurácia. O objetivo deste trabalho é classificar o conhecimento dos usuários no domínio de programação Java através da análise dos códigos- fonte criados ao longo do projeto. Para avaliá-lo, foi desenvolvido um protótipo com o perfil de dez usuários e executado vinte solicitações de especialistas. Após isto, foi verificado se os especialistas sugeridos seriam capazes de responder as perguntas do questionário extraídas do fórum Experts-Exchange. Apesar do Presley ter uma menor acurácia (71%), o valor obtido pode ser considerado importante na avaliação da qualidade das recomendações, indicando uma boa porcentagem de acerto perante todas as abordagens encontradas (com variação de 43% a 85%).
Avaliando a distribuição das métricas por quantidade de especialistas: por fim, é
necessário distribuir os e-mails selecionados no experimento por quantidade de respostas recebidas e por quantidade de recomendações para avaliar a situação no qual o Presley melhor recomenda. A Figura 5-10 e Figura 5-11 apresentam a precisão (a) e a cobertura (b) nos casos gerais e de sucesso, respectivamente, com os e-mails divididos por quantidade de respostas recebidas. Já a Figura 5-12 apresenta a acurácia nesta mesma divisão.
64
Figura 5-10: Precisão (a) e a Cobertura (b) gerais das Recomendações por Quantidade de Respostas dos E-mails
Figura 5-11: Precisão (a) e a Cobertura (b) nos casos de sucesso das Recomendações por Quantidade de Respostas dos E- mails
Figura 5-12: Acurácia das Recomendações por Quantidade de Respostas dos E-mails
Como 84% das mensagens utilizadas no experimento contêm três ou menos respostas, convém analisar o comportamento do Presley apenas para estas mensagens recomendando três pessoas. Para o caso geral, a ferramenta obteve precisão 24% e
65 cobertura 50%. Porém, como argumentado anteriormente, os casos de sucesso representam melhor a qualidade das recomendações geradas. Desta forma, a precisão e cobertura são elevadas para 36% e 77% respectivamente, com a acurácia seria 65%.
Já na situação de mensagens com quatro ou menos respostas, que corresponde a 92% do total, com a ferramenta recomendando quatro pessoas, Presley obteve precisão 20% e cobertura 52% no geral; precisão 29%, cobertura 74% e acurácia 71% apenas nos casos de sucesso.
Este resultado indica que, na maioria das ocasiões, o Presley conseguiria recomendar corretamente duas pessoas, aumentando a possibilidade de sucesso na resolução do problema enfrentado. Por fim, ao observar a acurácia obtida pelo Presley em e-mails com sete ou menos respostas e para sete recomendações, 79% dos e-mails teriam ao menos uma recomendação correta e permitiria ao remetente resolver o problema postado.
5.2.Conclusão
Este capítulo apresentou as fases de definição, planejamento, execução, análise, interpretação e apresentação da avaliação da qualidade das recomendações de especialistas do Presley. O estudo analisou a possibilidade dos desenvolvedores, em se usando a ferramenta, terem um menor esforço em localizar os especialistas para os problemas enfrentados durante a implementação do código fonte.
Mesmo com apenas um projeto, a análise mostrou que o Presley pode ajudar na colaboração entre equipes distribuídas de desenvolvimento de software e diminuir o tempo necessário para iniciar a comunicação.
Adicionalmente, o experimento identificou o indício da comunicação registrada nos e-mails fornecer informações valiosas na identificação dos especialistas ao ponto de superar a identificação feita através do histórico de alterações no código-fonte. Esta evidência possibilita a geração de novas hipóteses sobre o valor do conteúdo existente em fontes de informação textuais. Informações existentes em e-mails, relatórios de bugs ou até nas descrições das atividades desempenhadas pelos desenvolvedores registradas em
66 ferramentas de apoio a coordenação do projeto (como os cronogramas) podem fornecer dados importantes na formação dos perfis dos especialistas.
Espera-se com indício encontrado, iniciar de uma investigação mais profunda sobre como a classificação dos conhecimentos, contidos nos registros de comunicação entre os desenvolvedores, e poder ajudar na identificação dos especialistas existentes de projetos de software.
No próximo capítulo, serão apresentadas as conclusões deste trabalho, as principais contribuições e as direções para trabalhos futuros.
67
6.
Conclusão
O Desenvolvimento Distribuído de Software tem sido adotado por várias empresas que buscam novos mercados, menores custos no desenvolvimento de software e melhor qualidade nos seus produtos. Como discutido no capítulo 2, existem diversos problemas de comunicação em equipes distribuídas, entre estes, a dificuldade de saber a quem contatar quando se tem alguma problema durante a implementação do software pode gerar atrasos que refletem negativamente no cronograma do projeto, principalmente quando as equipes estão separadas temporalmente.
Os capítulos 3 e 5 apresentaram sete Sistemas de Recomendação de Especialistas em