-
UNIVERSIDADE ESTADUAL DO CEARÁ
CENTRO DE CIÊNCIAS E TECNOLOGIA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
MESTRADO ACADÊMICO EM CIÊNCIA DA COMPUTAÇÃO
DUANY DREYTON BEZERRA SOUSA
UMA ABORDAGEM SISTEMÁTICA MULTIOBJETIVO PARA PRIORIZAÇÃO E
RECOMENDAÇÃO DE BUGS EM REPOSITÓRIOS DE SOFTWARE LIVRE E
CÓDIGO ABERTO
FORTALEZA – CEARÁ
2016
-
DUANY DREYTON BEZERRA SOUSA
UMA ABORDAGEM SISTEMÁTICA MULTIOBJETIVO PARA PRIORIZAÇÃO E
RECOMENDAÇÃO DE BUGS EM REPOSITÓRIOS DE SOFTWARE LIVRE E CÓDIGO
ABERTO
Dissertação apresentada ao Curso de MestradoAcadêmico em Ciência da Computação doPrograma de Pós-Graduação em Ciência daComputação do Centro de Ciências e Tec-nologia da Universidade Estadual do Ceará,como requisito parcial à obtenção do título demestre em Ciência da Computação. Área deConcentração: Engenharia de Software
Orientador: Prof. PhD. Jerffeson Teixeirade Souza
FORTALEZA – CEARÁ
2016
-
Dedico este trabalho à minha esposa, Roneide
Brito, e aos meus filhos, Felipe Duan e Luís
Eduardo, a quem dedico também todos os dias
de minha vida. À minha mãe, Eunir, e minha
irmã, Laiany, por sempre acreditarem em mim.
Pai, conseguimos!
-
AGRADECIMENTOS
Agradeço primeiramente a Deus, que sempre encontra formas de me mostrar que a jornada pode
ser divertida.
À minha esposa, Roneide Brito, por ter aceito este desafio junto comigo e, por muitas vezes,
ter sido um ponto de luz em meio às dúvidas. Agradeço aos meus filhos, Felipe Duan e Luís
Eduardo, por serem meu estímulo para me tornar uma pessoa melhor.
À minha mãe, Maria Eunir, por sempre ter me mostrado como a vida deve ser conduzida.
Agradeço também à minha irmã, Laiany Sousa, por exercer a posição de tia com tanta responsa-
bilidade.
Agradeço ao Prof. PhD. Jerffeson Teixeira de Souza por ter desempenhado, com maestria, o
papel de orientador. Suas palavras se tornaram base de todo um futuro que desejo construir.
Serei sempre grato por isso.
Ao irmãos do Grupo de Otimização em Engenharia de Software (GOES.UECE): Altino Dantas,
Lucas Roque, Vanessa Veloso, Domingos Sávio, Ítalo Yeltsin e Matheus Paixão. Obrigado
por agora fazerem parte de minha família. Um agradecimento especial aos irmãos Thiago
Nascimento, Allysson Allex e Raphael Saraiva, por terem contribuído com meu sucesso, quando
até eu duvidava dele.
Ao amigos Marcos Borges e David Miranda que, junto com Altino Dantas, dividiram comigo
despesas, alegrias e tristezas.
Aos amigos e professores do Mestrado Acadêmico em Ciência da Computação (MACC) pelos
ensinamentos transmitidos com tanto profissionalismo.
Ao Prof. PhD. Paulo Henrique Mendes Maia e ao Prof. PhD. Celso Gonçalves Camilo Júnior,
por aceitarem o convite de participação e contribuição na minha banca avaliadora.
Ao reitor do Instituto Federal de Educação, Ciência e Tecnologia do Piauí (IFPI), Prof. Dr. Paulo
Henrique Gomes de Lima, por ter me incentivado a abraçar esta empreitada.
Agradeço à Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) pelo apoio
financeiro concedido nesse período.
-
“Se eu vi mais longe, foi por estar sobre os om-
bros de gigantes.”
(Isaac Newton)
-
RESUMO
A Engenharia de Software muito tem a contribuir para o processo de desenvolvimento de grandes
projetos de softwares. Desde a condução padronizada desse processo até a orientação correta em
casos de falha, todas as atividades envolvidas na evolução de um sistema contemplam a entrega
de um produto com a qualidade esperada. A tarefa de priorização de bugs em repositórios de
software de código livre e aberto, contudo, torna-se desafiadora, em razão da grande quantidade
de novas falhas que são reportadas diariamente. Assim, uma estratégia para atacar esse problema
é a automatização de algumas decisões envolvidas nesse processo, como qual a melhor ordenação
de bugs para correção. Além disso, é ideal que sejam recomendadas aos desenvolvedores tarefas
de implementação compatíveis com sua experiência ao longo dos componentes do software.
Nesse sentido, a Search Based Software Engineering surge como uma alternativa, aplicando
técnicas de otimização baseada em busca na resolução de problemas deste tipo. Este trabalho
propõe uma abordagem sistemática baseada em busca para a priorização de bugs em repositórios
de software livre e código aberto, utilizando informações dadas pelos membros da comunidade
mantenedora, determinando qual a melhor ordenação para as tarefas de correção dessas falhas,
através da aplicação de técnicas de otimização multiobjetivo. Além disso, é proposta uma estra-
tégia de recomendação de bugs, sugerindo ao desenvolvedor qual dentre as soluções encontradas
é mais compatível com seu nível de experiência em tarefas de implementação. Os resultados
demonstram que a estratégia NSGA-II apresenta-se como a melhor escolha dentre as técnicas
testadas, obtendo os melhores resultados na análise das métricas Hypervolume e Generational
Distance. Observou-se, também, que a estratégia de recomendação de bugs para correção sugeriu
soluções mais compatíveis com o nível de experiência do desenvolvedor do que o processo
aleatório de escolha.
Palavras-chave: Priorização de bugs. Otimização Multiobjetivo. Recomendação baseada em
compatibilidade. SBSE.
-
ABSTRACT
Software Engineering contributes greatly to the development process of large software projects.
Since the patterned conducting of the process to the correct orientation in case of failure, all
activities involved in the evolution of a system include the delivery of a product with the expected
quality. The bug prioritization task in free open source software repositories, however, it is
challenging, because of the large amount of new vulnerabilities that are reported daily. Thus,
a strategy to tackle this problem is to automate some decisions involved in this process, such
as how best ordination of bugs to fix. Moreover, it is ideal to recommend for developers
implementation tasks compatible with their expertise levels to particular type of activities on
software components. In this way, the Search Based Software Engineering is an alternative,
using search-based optimization techniques to solve these type of problems. This paper proposes
a search-based systematic approach to the bugs prioritization in free open source software
repositories, using information given by community members and determining how best order for
these failures remediation tasks, by applying multiobjective optmization techniques. Futhermore,
it is proposed a bug recommendation strategy, suggesting to the developer which of the solutions
is more compatible with their level of experience in implementing tasks. The results show that
the strategy NSGA-II is the best choice among the tested techniques, obtaining the best results
of the analysis and Hypervolume and Generational Distance metrics. It was also noted that the
recommendation strategy to fix bugs suggested more compatible solutions with the developer
experience level than the random selection process.
Keywords: Bugs prioritization. Multiobjective Optimization. Compatibility-based Recommen-
dation. SBSE.
-
LISTA DE ILUSTRAÇÕES
Figura 1 – Visão geral do processo convencional de evolução de software. . . . . . . . 17
Figura 2 – Processo de Correção de Emergência. . . . . . . . . . . . . . . . . . . . . . 17
Figura 3 – Cálculo do Hypervolume das soluções não-dominadas. . . . . . . . . . . . . 23
Figura 4 – Classificação de soluções em diferentes níveis, feita pelo NSGA-II. . . . . . 27
Figura 5 – Representação do funcionamento do NSGA-II. . . . . . . . . . . . . . . . . 27
Figura 6 – Representação do funcionamento do MOCell. . . . . . . . . . . . . . . . . 28
Figura 7 – Representação cálculo da aptidão da solução no algoritmo IBEA. . . . . . . 29
Figura 8 – Gráfico do número de publicações em SBSE por ano. . . . . . . . . . . . . 31
Figura 9 – Gráfico do número de publicações em SBSE por área. . . . . . . . . . . . . 31
Figura 10 – Visão geral da abordagem proposta. . . . . . . . . . . . . . . . . . . . . . . 37
Figura 11 – Média de Hypervolume obtido em cada técnica de busca. . . . . . . . . . . 52
Figura 12 – Comparação entre melhores frentes obtidas em cada técnica de busca, em
relação à métrica Hypervolume. . . . . . . . . . . . . . . . . . . . . . . . . 53
Figura 13 – Média de GD obtido em cada técnica de busca. . . . . . . . . . . . . . . . . 53
Figura 14 – Comparação entre melhores frentes obtidas em cada técnica de busca, em
relação à métrica GD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 15 – Média de Spread obtido em cada técnica de busca. . . . . . . . . . . . . . . 54
Figura 16 – Comparação entre melhores frentes obtidas em cada técnica de busca, em
relação à métrica Spread. . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 17 – Exemplo de organização dos dados em instância de Bugs coletados. . . . . . 76
Figura 18 – Exemplo de organização dos dados em instância de perfil de desenvolvedores. 77
Figura 19 – Exemplo de organização dos dados em instância de experiência exigida por
um bug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
-
LISTA DE TABELAS
Tabela 1 – Discretização do valor de prioridade de um bug, no intervalo [0,1]. . . . . . 46
Tabela 2 – Discretização do valor de severidade de um bug, no intervalo [0,1]. . . . . . 46
Tabela 3 – Média e desvio-padrão dos valores de cada métrica avaliada ao longo de 30
execuções dos algoritmos de busca. . . . . . . . . . . . . . . . . . . . . . . 51
Tabela 4 – Interpretação do valor de p-value, resultante do teste de Kruskal-Wallis. . . 56
Tabela 5 – Resultado do Teste de Kruskal-Wallis. . . . . . . . . . . . . . . . . . . . . 56
Tabela 6 – Resultado dos Testes de Mann-Whitney com correção pelo método de Bon-
ferroni, e Teste  de Vargha-Delaney. . . . . . . . . . . . . . . . . . . . . . 57
Tabela 7 – Distância Euclidiana(DE) entre experiências exigidas para resolução de bugs
de uma solução recomendada e outra escolhida aleatoriamente, em relação
ao conjunto de experiências do desenvolvedor. . . . . . . . . . . . . . . . . 59
Tabela 8 – As Leis de Lehman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
-
LISTA DE ABREVIATURAS E SIGLAS
AG Algoritmo Genético
ES Engenharia de Software
GRASP Greedy Randomized Adaptive Search Procedure
KDE K Desktop Environment
SBSE Search Based Software Engineering
SVM Support Vector Machines
-
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1 MOTIVAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . 16
2.1 ENGENHARIA DE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1 Evolução de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.2 Manutenção de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 REPOSITÓRIOS DE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . 18
2.3 OTIMIZAÇÃO MATEMÁTICA . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1 Métricas para Comparação de Soluções . . . . . . . . . . . . . . . . . . 22
2.3.1.1 Hypervolume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1.2 Generational Distance(GD) . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1.3 Spread(∆) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.2 Meta-heurísticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 COMPUTAÇÃO EVOLUTIVA . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.1 Inspiração Biológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.2 NSGA-II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.3 MOCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.4 IBEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 SEARCH BASED SOFTWARE ENGINEERING . . . . . . . . . . . . . . . 29
2.6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . 33
3.1 TRABALHOS RELACIONADOS A BUGS . . . . . . . . . . . . . . . . . 33
3.2 TRABALHOS SOBRE PRIORIZAÇÃO DE REQUISITOS . . . . . . . . . 35
4 ABORDAGEM PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1 ETAPA DE PRIORIZAÇÃO DE BUGS . . . . . . . . . . . . . . . . . . . . 38
4.1.1 Modelagem Matemática do Problema . . . . . . . . . . . . . . . . . . . 39
4.2 ETAPA DE RECOMENDAÇÃO DE SOLUÇÃO PARA O DESENVOLVEDOR 40
4.2.1 Modelagem Matemática da Função de Compatibilidade . . . . . . . . . 41
-
4.3 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 ESTUDO EMPÍRICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1 QUESTÕES DE PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.1 Complexidade do Problema . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.2 Instância de bugs coletados . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.3 Instância com perfil dos desenvolvedores . . . . . . . . . . . . . . . . . . 47
5.2.4 Instância com experiência exigida pelo bug . . . . . . . . . . . . . . . . . 48
5.2.5 Técnicas de busca utilizadas nos experimentos . . . . . . . . . . . . . . . 48
5.2.6 Métricas para avaliação das técnicas adotadas . . . . . . . . . . . . . . . 49
5.2.7 Geração da população inicial . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.8 Geração da Frente Real . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.9 Parametrização dos Algoritmos . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.10 Utilização do framework jMetal . . . . . . . . . . . . . . . . . . . . . . . 50
5.3 RESULTADOS E ANÁLISES . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4 AMEAÇAS À VALIDADE . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . 63
6.1 CONTRIBUIÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2 LIMITAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.3 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
GLOSSÁRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
APÊNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
APÊNDICE A – Artigo publicado - SSBSE 2015 - Challenge Track . . . . 70
APÊNDICE B – Modelo de Instância de Bugs Coletados . . . . . . . . . . 76
APÊNDICE C – Modelo de Instância de Perfil de Desenvolvedores . . . . 77
APÊNDICE D – Modelo de Instância com Experiência exigida por um bug 78
ANEXOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
ANEXO A – Leis de Lehman . . . . . . . . . . . . . . . . . . . . . . . . 80
-
13
1 INTRODUÇÃO
O desenvolvimento de um software não encerra quando ele é entregue ao cliente.
Após sua implantação em produção, mudanças no foco do domínio onde o sistema está em
funcionamento ou mudanças nas expectativas dos usuários podem afetá-lo consideravelmente,
segundo Sommerville (2011). Como exemplo destas alterações podemos citar as mudanças de
porte em uma empresa, necessidade da adição de uma nova funcionalidade ou a adequação do
sistema a uma nova arquitetura.
Essas mudanças, quando acrescentadas em sistemas que já se encontram em utili-
zação pelos usuários, podem ocasionalmente inserir novas falhas. Conforme aumenta o porte
do sistema desenvolvido, mais complexo ele se torna e mais desafiador é sua manutenção e
evolução. Entretanto, isso torna-se um dilema no desenvolvimento de softwares livres de código
aberto pois, nesse caso, é estimulada a participação dos usuários que compõem a comunidade
mantenedora, permitindo que o número de falhas relatadas aumente consideravelmente.
Grandes projetos de software livre e de código aberto possuem seus repositórios
de bugs disponíveis ao público em geral. São exemplos disso os projetos: Apache Software
Foundation1, KDE2, Mozilla Foundation3 e Eclipse4. Para a aplicação dos experimentos descritos
neste trabalho foi selecionado o repositório de bugs de um componente do projeto KDE, chamado
Kate Editor.
O subprojeto Kate Editor é um editor de texto multiplataforma e multidocumento
bastante popular, escrito na liguagem C/C++ e com suporte a plugins. O website desse projeto5
contem referências para o repositório de código-fonte e um repositório de bugs. Este último
contém várias informações úteis ao processo de priorização de bugs, tais como severidade do
bug, nível de prioridade, precedência entre bugs, estado atual de um bug, histórico de alterações
em tarefas de correção de bugs e comentários realizados por usuários do repositório.
Assim, neste trabalho é proposta e avaliada uma abordagem sistemática baseada em
busca para a priorização e recomendação de bugs para correção em repositórios de software
livre e código aberto, utilizando um processo de otimização multiobjetivo, considerando as
informações sobre os bugs providas pelos usuários do repositório.1 2 3 4 5
https://issues.apache.org/jira/http://bugs.kde.org/http://bugzilla.mozilla.orghttps://bugs.eclipse.org/bugs/http://kate-editor.org/
-
14
1.1 MOTIVAÇÃO
Repositórios de bug têm um papel vital na qualidade do software, especialmente
em projetos de software livre e código aberto. Como vantagens podemos mencionar a ampla
participação dos usuários da comunidade reportando problemas no código-fonte, sugerindo
melhorias e discutindo acerca das falhas informadas, conforme sugere Anvik et al. (2006).
Entretanto, em razão do crescimento em larga escala dos sistemas atuais, o número de bugs em
repositórios cresce significativamente. Assim, o gerenciamento de todas essas informações pode
ser considerado como uma tarefa complexa a ser executada, incluindo a decisão sobre quais
bugs têm maior urgência em ser corrigidos. Geralmente, um desenvolvedor tem que decidir por
conta própria quais devem ser corrigidos primeiro entre todos aqueles disponíveis, baseando-se
em algum critério pessoal. Portanto, é importante para um repositório oferecer um processo
inteligente de priorização e recomendação de bugs para correção que estimule desenvolvedores a
selecionar os mais importantes bugs a corrigir.
Nesse sentido, a Engenharia de Software Baseada em Busca, ou Search Based
Software Engineering (SBSE), propõe o uso de técnicas de inteligência artificial para resolver
problemas complexos em Engenharia de Software. Atividades de priorização são frequentemente
exploradas nesse campo, dadas as muitas oportunidades de serem aplicadas no processo de
desenvolvimento de software. Contudo, até esse momento, nenhum estudo prévio que tenha
investigado priorização de bugs em repositórios de software livre utilizando conceitos de SBSE
foi conduzido.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste trabalho é propor uma método para a priorização e recomen-
dação de bugs a serem corrigidos em repositórios de projetos de software livre e código aberto,
levando em consideração o quão valiosa é a correção desse bug para a comunidade mantenedora
e o nível de semelhança existente entre o nível de experiência exigido pelo bug e a experiência
do desenvolvedor.
-
15
1.2.2 Objetivos Específicos
Para alcançar o objetivo geral deste trabalho, foram definidos os seguintes objetivos
específicos:
a) Propor um modelo matemático multiobjetivo para a priorização de bugs em
repositórios de software livre e código aberto;
b) Propor uma estratégia de recomendação de bugs ao desenvolvedor, onde o
nível de experiência exigido para sua correção seja o mais próximo possível da
experiência do profissional envolvido;
c) Avaliar empiricamente diferentes técnicas de busca, visando averiguar qual
produz melhores resultados.
-
16
2 FUNDAMENTAÇÃO TEÓRICA
2.1 ENGENHARIA DE SOFTWARE
O crescente aumento da complexidade dos softwares tem tornado o seu desenvol-
vimento mais desafiador com o passar do tempo. As diferentes características desses sistemas,
de cunho abstrato e intangível, fazem com que esse processo não seja regido pelos métodos de
produção convencionais.
Na transição entre as décadas de 1960 e 1970, a inexistência de técnicas difundidas
que padronizassem a atividade de desenvolvimento de software, em conjunto com o aumento
da demanda por novos sistemas, fez com que a maioria desses projetos não lograssem sucesso
(SOMMERVILLE, 2011). A troca de experiências entre os grupos também era dificultada,
visto que cada equipe adotava sua metodologia própria de construção do produto de software.
Posteriormente, esse cenário ficou conhecido como "A Crise do Software"(WAZLAWICK,
2013), e tem como problemas característicos:
• Falhas nas estimativas de prazo e orçamento;• Ineficiência no atendimento das funcionalidades solicitadas pelos clientes;• Projetos difíceis de serem gerenciados;• Código-fonte de difícil manutenção e evolução.
Todos esses fatores contribuem para a baixa qualidade do produto construído. No
cenário atual, é possível perceber que estes problemas ainda permanecem presentes no processo
de desenvolvimento de software, fato que contribui para a afirmação de senso comum que a crise
de software ainda existe.
Com o objetivo de minimizar os efeitos dessa crise e aumentar a qualidade do
software construído, a Engenharia de Software (ES) busca reunir conhecimento de boas práticas
na condução desse processo. Segundo Sommerville (2011), "a ES é uma disciplina da engenharia
cujo o foco está em todos os aspectos da produção de software, desde os estágios iniciais da
especificação do sistema até a sua manutenção, quando o sistema já está sendo usado."
Como fruto de um desenvolvimento profissional de um software, Sommerville
(2011) ainda enumera atributos essenciais de um bom software, como aceitabilidade, eficiência,
manutenibilidade e confiança e proteção. O autor define manutenibilidade como sendo a
capacidade do produto evoluir de forma a atender às necessidades dos usuários, e considera a
mudança do software como um "requisito inevitável de um ambiente de negócio". É justamente
-
17
esse aspecto que serve de fundamento para a realização deste trabalho.
2.1.1 Evolução de Software
Conforme Pressman (2006), o software de computador está sujeito a mudanças.
Essas modificações, segundo ele, conduzem esse processo e são originárias das correções de
erros, adaptações do sistema a novos ambientes, das solicitações de novas funcionalidades por
parte dos usuários ou quando o produto tem de ser readaptado para oferecer benefícios em um
contexto mais atual. A figura 1 mostra uma visão geral das atividades envolvidas no processo
convencional de evolução.
Figura 1 – Visão geral do processo convencional de evolução de software.
Fonte – Adaptado de Sommerville (2011).
O processo de construção do software pode variar dependendo do tipo de sistema
que esteja sendo desenvolvido e/ou do tipo de organização envolvida. Em se tratando de projetos
de software livre e código aberto, mais especificamente de seus repositórios de bugs, observa-se
que a estratégia adotada para tarefas de correção de falhas relatadas não segue este modelo à
risca, mas sim aquele apontado por Sommerville (2011) como sendo o processo de correção de
emergência, que dispensa algumas etapas do processo de análise formal da mudança. A figura 2
ilustra a simplicidade dessa abordagem.
Figura 2 – Processo de Correção de Emergência.
Fonte – Adaptado de Sommerville (2011).
Com a intenção de compreender melhor a dinâmica da evolução dos sistemas,
Sommerville (2011) explica que, nas décadas de 1970 e 1980, os pesquisadores Lehman e
Belady realizaram vários estudos empíricos sobre como as mudanças afetam o ciclo de vida do
software. Essa pesquisa foi complementada com estudos realizados na década de 1990, onde
-
18
foram investigados o efeito do feedback nesses processos de evolução. Como resultado desse
trabalho foi proposto um conjunto de leis relativas às mudanças de sistema, chamadas "Leis de
Lehman", descritas na tabela 8 presente no Apêndice A.
Conforme resultados desse estudo, a primeira lei reforça a ideia que a manutenção
de um software é um processo inevitável.
2.1.2 Manutenção de Software
Normalmente encarado como um componente à parte do ciclo de vida do software,
a manutenção do sistema faz parte do processo geral de mudança ao qual o produto está sujeito
e está intimamente ligada às alterações que este sofre. Segundo Sommerville (2011), essas
mudanças "podem ser simples correções de erros de codificação, até mudanças mais extensas
para correção de erros de projeto, ou melhorias para corrigir erros de especificação ou acomodar
novos requisitos".
Há três tipos distintos de manutenção de software:
a) Correção de defeitos: refere-se a manutenção de problemas gerados em outras
fases do desenvolvimento de software. Erros de codificação, erros de projetos
e erros de coleta e especificação de requisitos são exemplos de falhas que se
enquadram nesta categoria;
b) Adaptação ambiental: modificações no software com o intuito de acomodar as
constantes mudanças que acontecem no ambiente externo. O sistema, então,
deve ser adaptado a este novo cenário;
c) Adição de funcionalidade: este tipo de manutenção é necessária quando mudan-
ças organizacionais ou de negócios ocorrem, resultando no surgimento de novos
requisitos de software.
Apesar dessa classificação, habitualmente não há de fato uma separação entre elas.
Como exemplo disso, pode-se citar o cenário onde há uma adaptação do software a uma nova
plataforma e, com a adição de novos componentes, sejam adicionadas novas funcionalidades que
antes não eram possíveis.
2.2 REPOSITÓRIOS DE SOFTWARE
Os projetos de software livre e código aberto também sofrem os impactos do aumento
da complexidade dos sistemas desenvolvidos, além de possuírem o agravante de que seu time de
-
19
desenvolvimento geralmente ser distribuído, o que dificulta a coordenação e comunicação dos
integrantes. A comunidade mantenedora também encontra-se distribuída globalmente. Todos
esses fatores contribuem para tornar o gerenciamento da evolução e manutenção deste software
uma atividade realmente desafiadora.
Entretanto, essas comunidades fazem uso de uma estratégia que ameniza os fatores
citados: a utilização de repositórios de software. Os repositórios que abrigam esses projetos
podem manter tanto o código-fonte do sistema desenvolvido, como um servidor de controle de
versões do software, quanto servir de base de dados de relatos de novas falhas e solicitações de
novas funcionalidades, conhecido como repositório de bugs ou issue tracking systems. Conforme
Anvik (2007), o uso de repositórios de bugs pode melhorar o processo de desenvolvimento de
software de várias formas:
a) Permite manter um controle sobre como está a evolução do software, ao conhecer
quantos problemas relatados estão sendo corrigidos;
b) Reduz o problema da comunicação em equipes globalmente distribuídas;
c) Permite determinar o nível de experiência de um desenvolvedor em diferentes
áreas do produto, ao manter controle sobre seu histórico de participação em
atividades de implementação;
d) Permite melhorar a qualidade do sistema produzido;
e) Mantém os participantes da comunidade a par do estado dos problemas relatados.
Em repositórios de softwares livres a participação da comunidade é bastante estimu-
lada. Há várias formas de se contribuir, indo desde a simples utilização do software produzido
e informando falhas ou necessidade de novas funcionalidades, até a participação ativa como
desenvolvedor. São disponibilizadas várias maneiras de interação com o repositório, como é o
caso da possibilidade de se escolher, através de votação, um determinado bug a ser corrigido
ou nova funcionalidade a ser implementada, para que sinalize à equipe de desenvolvimento
que este componente é importante para a comunidade. Além disso, é possível também realizar
comentários e acompanhar relatórios de falhas, permitindo manter o conhecimento da evolução
do mesmo.
Cabe lembrar que as características variam de um provedor de repositórios para outro,
mantendo entre os mesmos um grande número de informações semelhantes. Neste trabalho
são identificados os tipos de usuários que formam a comunidade mantenedora e descritas as
informações que devem ser fornecidas pelo repositório para serem utilizadas na abordagem
proposta.
-
20
2.3 OTIMIZAÇÃO MATEMÁTICA
Segundo Gaspar-Cunha et al. (2013), a Otimização é o campo do conhecimento
matemático cujas técnicas tem por objetivo encontrar valores extremos de funções, sendo eles
máximos ou mínimos, em certos domínios. Como exemplo disso pode-se citar o clássico
problema do caixeiro viajante, no qual um vendedor precisa visitar todos os elementos de
conjunto de N cidades e retornar para a cidade de onde iniciou o percurso, sem visitá-las mais
de uma vez. Neste cenário, todas as cidades possuem estradas que as ligam às restantes. O
objetivo deste problema de otimização é minimizar o quanto possível os custos com esse trajeto.
Entenda-se por "custo"qualquer métrica escolhida para mensurar a qualidade de uma solução,
como tempo total gasto ou menor distância percorrida. Pode-se observar que o problema conta
com três elementos fundamentais, sendo eles:
a) Objetivo: minimizar os custos gerados com o trajeto escolhido;
b) Limitações: visitar todas as N cidades, sendo que a primeira cidade e a última
são exatamente a mesma; as cidades só podem ser visitadas uma vez;
c) Incógnitas: cidades envolvidas.
Como solução para esse problema tem-se uma relação priorizada de cidades a serem
visitadas, onde o custo deste trajeto seja o menor possível dentre as soluções avaliadas e que as
limitações sejam todas respeitadas.
Diante do exposto, Lisboa (2002) conclui que tem-se três conceitos fundamentais da
otimização matemática que podem ser definidos. O primeiro deles são as variáveis de decisão,
aqui representadas pelas incógnitas do problema, a serem estabelecidas pela solução do modelo.
O segundo são as restrições, que corresponde às limitações do problema, e que de fato restringem
os possíveis valores das variáveis de decisão. O terceiro conceito é a função objetivo, que pode
ser descrita como uma função matemática que define a forma como é avaliada uma solução em
razão das variáveis de decisão.
Essa busca por soluções é delimitada pelo domínio no qual é aplicada a otimização
que, conforme Gaspar-Cunha et al. (2013), "é a região do espaço de variáveis da função na qual
se procura determinar seu extremo". Esse domínio corresponde, em linhas gerais, ao "conjunto
das diferentes soluções que estão disponíveis para o problema", e pode ser composto de variáveis
de natureza contínua ou discreta. A região do espaço de variáveis de decisão onde as soluções
atendem as restrições do problema é denominada região factível.
-
21
A função 2.1 descreve um exemplo de formulação para problemas de otimização.
mininizar f (x),
sujeito a gi(x)≤ 0 para i = {1,2,3, · · · ,m},
h j(x) = 0 para j = {1,2,3, ..., p},
x ∈Ω,
(2.1)
onde f (x) é a função que se deseja minimizar, g(x) e h(x) são as funções que representam as
restrições do problema e Ω é o conjunto de todas as soluções possíveis. A variável x representa
uma solução do conjunto Ω, que para ser considerada válida deve satisfazer as funções g(x) e
h(x), denominadas restrições do problema. A formulação descrita visa minimizar o valor da
função f (x).
Observa-se nessa formulação que há somente um objetivo envolvido, o de minimizar
a função f (x). A isto denomina-se otimização mono-objetivo. Neste tipo de otimização, há a
busca por uma única solução, denominada solução ótima, resultante da avaliação feita através
da única função objetivo existente. Na comparação entre as soluções candidatas a ordenação
é total, onde pode-se determinar qual delas é a melhor. Assim, tem-se que f (x)≤ f (y) ou quef (x)≥ f (y), para todo x e y.
No entanto, Gaspar-Cunha et al. (2013) afirmam que, em situações práticas, é
comum que seja considerado mais de um objetivo. Por exemplo, numa variação do problema do
caixeiro viajante poderiam ser considerados os objetivos de maximizar o número de visitas a
clientes considerados mais importantes enquanto se busca minimizar o gasto total de combustível.
Esse tipo de otimização que possui mais de um objetivo envolvido denomina-se otimização
multiobjetivo.
A função 2.2 descreve o exemplo de uma formulação para problemas de otimização
multiobjetivo.
mininizar fm(x), m = {1,2, · · · ,M}
sujeito a gi(r)≤ 0 para r = {1,2,3, · · · ,R},
h j(S) = 0 para s = {1,2,3, · · · ,S},
x ∈Ω.
(2.2)
Um processo de otimização multiobjetivo não gera apenas uma, mas um conjunto de
-
22
soluções. Um subconjunto dessas soluções possui qualidade superior às outras, mas não entre
si. A esse conjunto dá-se o nome de Frente de Pareto, ou conjunto Pareto-ótimo, que possui
as melhores soluções geradas pelo processo multiobjetivo. Em situações onde já se conhece
a melhor Frente de Pareto possível para um determinado problema, nomeia-se essa frente de
Frente de Pareto Real, ou simplesmente Frente Real. Visto que para cada objetivo analisado há a
produção de um valor de avaliação em cada solução, a comparação entre soluções pode ser feita
através da utilização de métricas específicas para esse tipo de otimização.
2.3.1 Métricas para Comparação de Soluções
Para comparação de desempenho das soluções geradas num processo de otimização
multiobjetivo com diferentes técnicas de busca, como aplicado neste trabalho, é desejável que
sejam analisadas ao menos duas características. Uma delas é a convergência das soluções
obtidas, enquanto a outra é a dispersão da frente obtida, com as avaliações sendo feitas em
relação à Frente Real(DEB, 2001). As métricas selecionadas para esse objetivo são Hypervolume,
Generational Distance e Spread, e estão descritas logo a seguir.
2.3.1.1 Hypervolume
A métrica Hypervolume, proposta por Zitzler (1999), calcula a área do espaço de
busca dominado pelo conjunto solução, ou Frente de Pareto, e definido a partir de um ponto de
referência. O cálculo desse indicador segue os seguintes passos:
- Toma-se o conjunto Q de soluções da Frente de Pareto a ser avaliada, dispostas no espaço
de busca;
- Toma-se um ponto de referência W , dominado por todos os pontos do conjunto avaliado;
- Calcula-se a área do retângulo vi formado entre cada solução si e ponto W . Caso haja mais
de dois objetivos, é calculada a área do hipercubo formado entre esses pontos;
- Calcula-se a área resultante da união de todos os retângulos ou hipercubos obtidos.
A figura 3 exibe a representação gráfica do Hypervolume das soluções não-dominadas.
A equação 2.3 mostra a formulação matemática dessa métrica.
HV = volume
|Q|⋃
i=1
vi
(2.3)
Quanto mais próximas as soluções de uma frente de Pareto estiverem de uma Frente
-
23
Figura 3 – Cálculo do Hypervolume das soluções não-dominadas.
Fonte – Deb (2001).
Real, e quanto melhor for sua distribuição, maior o valor dado pela métrica de Hypervolume.
2.3.1.2 Generational Distance(GD)
Essa métrica calcula a distância euclidiana média, no espaço de busca, entre o
conjunto Q de soluções de uma frente de Pareto, em relação ao conjunto de soluções da Frente
Real. Essa métrica informa também informa sobre a convergência das soluções da frente obtida
em relação à Frente Real P e, quanto mais próximo de zero estiver seu valor, mais próximas
essas soluções estarão. A equação 2.4 mostra a formulação matemática do cálculo.
GD =
√∑|Q|i=1 d
2i
n(2.4)
O valor de di é a menor distância euclidiana de uma solução i ∈ Q a uma soluçãoda Frente Real P, e mostra o quanto essa solução está distante da solução mais próxima de
Frente Real. Portanto, é desejável obter valores mais baixos nessa métrica. Para que o cálculo de
Generational Distance(GD) esteja correto, recomenda-se um conjunto P com muitas soluções.
2.3.1.3 Spread(∆)
Esta métrica é utilizada para medir a dispersão das soluções de uma frente Q em
relação à Frente Real P. Isso mede a diversidade das soluções, ou seja, como essas soluções
estão espalhadas no espaço de busca, em relação à Frente Real. Sua formulação é dada pela
-
24
seguinte equação:
∆ = ∑Mm=1 d
em +∑
|Q|i=1 |di− d̄|
∑Mm=1 dem + |Q|d̄(2.5)
onde di pode ser qualquer medida de distância entre soluções vizinhas, e d̄ é o valor médio entre
essas medidas de distância. O parâmetro dem é a distância entre as soluções extremas da Frente
Real P e a frente Q, correspondendo à m-ésima função objetivo. M indica o número de objetivos
do problema. Quanto mais próximo de zero for o valor obtido nessa métrica, melhor será a
distribuição das soluções em relação à Frente Real.
2.3.2 Meta-heurísticas
Há técnicas clássicas de otimização que, em casos especiais, conseguem obter de
forma confiável a solução exata de um problema. Gaspar-Cunha et al. (2013) explicam que, no
caso de variáveis de decisão de natureza contínua, métodos como o SIMPLEX e a técnica de
pontos interiores da programação convexa são capazes de encontrar a melhor solução para um
problema (chamado ótimo global) de maneira computacionalmente eficiente. Em problemas de
Otimização Combinatória, onde as variáveis de decisão são de natureza discreta, dependendo da
complexidade do problema também podem ser adotadas técnicas exatas que garantem encontrar
o ótimo global.
Entretanto, muitas vezes o esforço computacional envolvido é tão grande que torna
inviável a adoção de tais técnicas. No caso do problema do caixeiro viajante descrito anteri-
ormente, considerando-se N = 10, haverá um conjunto de 3.628.800 possibilidades a serem
testadas. Caso o tempo de cálculo de cada solução seja 01 segundo, o processamento total
durará 2.520 dias, ou quase 07 anos. Para contornar este problema, é recomendado o uso de
heurísticas, definidas como sendo um procedimento de busca que não oferece garantias da
qualidade das soluções em relação ao ótimo global mas que, após um número finito de passos,
tende a oferecer uma solução que seja melhor que a vasta maioria das soluções disponíveis. Em
algumas situações, técnicas aplicadas a um tipo de problema podem ser utilizadas em outros de
natureza diferente, sem necessariamente atingir o ótimo global. Denomina-se de ótimo local os
pontos do espaço de busca que possuem o maior valor em relação à soluções vizinhas, mas não
obrigatoriamente em relação ao todo.
As heurísticas são normalmente aplicadas em problemas de contexto específico para
-
25
o qual são desenvolvidas. Contudo, há um conjunto dessas técnicas que possuem propósito mais
geral e são pautadas em processos estocásticos, podendo ser aplicadas em uma variedade mais
abrangente de problemas de otimização combinatória, denominadas meta-heurísticas. Dentre
elas, podemos citar a Têmpera Simulada, NSGA-II, MOCell, IBEA, Algoritmos Genéticos,
Busca Tabu e GRASP. Neste estudo foram utilizadas três meta-heurísticas para problemas
multiobjetivos: NSGA-II, MOCell e IBEA.
2.4 COMPUTAÇÃO EVOLUTIVA
Em termos de heurísticas, há um tipo específico inspirado na observação de mecanis-
mos de adaptação dos seres vivos. Gaspar-Cunha et al. (2013) justificam essa fundamentação
com base nas respostas adequadas de tais mecanismos da natureza para problemas de grande
complexidade. Como exemplo dessas práticas naturais, tem-se a adaptação das espécies ao
ambiente através da evolução natural, a busca por alimentos realizada de maneira coordenada
por uma colônia de formigas e o voo dos bandos de pássaros aparentemente aleatório, mas
coletivamente organizado.
Com base em estudos realizados, técnicas de otimização foram propostas adaptando
conceitos extraídos dessas observações ao ambiente computacional. A ideia central é que o
conhecimento seja de alguma forma transmitido e melhorado através das gerações, permitindo
a evolução da espécie. Esse é o conceito por trás do termo Computação Evolutiva e, segundo
Gaspar-Cunha et al. (2013):
"Acredita-se que a estrutura de tais mecanismos naturais de adaptação possa sertransposta com sucesso para a construção de mecanismos computacionais deadaptação destinados a tratar de problemas de otimização de alta complexidade".
Dessa forma, foram desenvolvidas algumas estratégias que implementam esses
conceitos de forma particular e adequada, como os Algoritmos Genéticos e Programação Ge-
nética. Entretanto, a inspiração biológica já não é o único fator motivador na construção desse
tipo de técnica, havendo dentro da Computação Evolutiva métodos cujas justificativas sejam
essencialmente matemática e computacional.
2.4.1 Inspiração Biológica
O cientista Charles Darwin, no século XIX, realizou um estudo a fim de compreender
como se dava o processo de diversidade biológica entre as diferentes espécies de seres vivos.
-
26
Naquela época, através de um alto poder de observação, percebeu que animais de uma mesma
espécie que habitavam ecossistemas distintos possuíam características levemente diferentes,
adaptando-os à região onde viviam.
Essa pesquisa deu origem à Teoria da Evolução das Espécies, de onde surgem termos
como a seleção natural, que representa a competição de indivíduos por recursos limitados, como
alimentos e fêmeas para reprodução. Os indivíduos que não estejam mais adaptados a esse
processo possuem uma menor probabilidade de gerar descendentes, o que indica uma menor
probabilidade de ter seus genes propagados através de outras gerações. A combinação entre
características genéticas de indivíduos que compõem a população dá origem a novos indivíduos,
que são semelhantes a seus pais, mas não possuem nenhuma garantia de serem mais adaptados.
A transmissão dos genes através do processo de evolução natural é explicada pela Teoria da
Hereditariedade, proposta pelo monge agostiniano e botânico Gregor Mendel.
A seguir, serão explicadas as três meta-heurísticas para problemas multiobjetivos
selecionadas para este trabalho: NSGA-II, MOCell e IBEA.
2.4.2 NSGA-II
Proposto por Deb et al. (2000), o algoritmo Non-Dominated Sorting Genetic Algo-
rithm, chamado também de NSGA-II, baseia-se em uma ordenação elitista das soluções de uma
população total, classificando-as em diferentes níveis, de acordo com a quantidade de soluções
que a dominam. A figura 4 ilustra o processo de classificação dessas soluções, onde as aquelas
que compõem o nível 1 não são dominadas por nenhuma outra, aquelas que compõem o nível 2
são dominadas por apenas uma solução, e assim por diante, até que todas as soluções do conjunto
estejam classificadas. O autor ainda propôs uma técnica chamada crowding distance, utilizada
para se calcular o nível de aglomeração de soluções em um dado ponto do espaço de busca.
O NSGA-II inicialmente gera uma população inicial Pt , de tamanho N. Entre os
indivíduos dessa população é realizado o processo de cruzamento (crossover) e mutação, e uma
nova população Qt é gerada, sendo também de tamanho N. Os indivíduos dessas duas populações
são unidos, constituindo uma nova população Rt de tamanho 2N. A partir disso, as soluções
são classificadas em diferentes níveis, conforme previamente explicado. Dentro de cada nível
as soluções são ordenadas segundo o valor de crowding distance. Após ordenação total dessa
população, são selecionadas as primeiras N soluções para comporem a nova população. A figura
5 ilustra o funcionamento do NSGA-II descrito.
-
27
Figura 4 – Classificação de soluções em diferentes níveis, feita pelo NSGA-II.
Fonte – Elaborada pelo autor.
Figura 5 – Representação do funcionamento do NSGA-II.
Fonte – Deb et al. (2000).
2.4.3 MOCell
O algoritmo MOCell, proposto por Nebro et al. (2009), é uma adaptação do algoritmo
cGA (cellular Genetic Algorithm) para problemas multiobjetivos. Nesse algoritmo, os indivíduos
da população são organizados numa malha bidimensional, onde são formadas células contendo
uma solução como referência e sua vizinhança. Para cada solução, o algoritmo seleciona dois pais
de sua vizinhança, realizando o cruzamento entre os mesmos, a fim de se obter uma solução filha,
que sofrerá mutação e será avaliada. Essa nova solução é adicionada tanto na população auxiliar
quanto num arquivo externo, um mecanismo que armazena soluções não-dominadas encontradas
durante o processo de busca. Ao término da iteração, a população atual é substituída pela auxiliar,
e através de um mecanismo de feedback permite que soluções da população sejam substituídas
por soluções do arquivo externo. Segundo Nebro et al. (2009), isso permite guiar o processo
de busca em direção a soluções não-dominadas já encontradas, melhorando a capacidade de
-
28
intensificação. A figura 6 ilustra o funcionamento do algoritmo MOCell.
Figura 6 – Representação do funcionamento do MOCell.
Fonte – Adaptado de Nebro et al. (2009).
2.4.4 IBEA
O algoritmo IBEA, proposto por Zitzler e Künzli (2004), é um algoritmo evolucio-
nário multiobjetivo que considera no processo de otimização algum indicador arbitrário, como
o Hypervolume, além do convencional valor de aptidão da solução. É necessário, então que se
defina qual indicador será utilizado como objetivo.
Para cada par ordenado de soluções é calculado o valor dessa aptidão. Como exemplo,
considere duas soluções dispostas no espaço de busca. Suas posições são determinadas pelos
valores de aptidão calculado pelas funções objetivo do problema. Considere, também, que o
indicador escolhido para o cálculo da aptidão final da solução tenha sido o Hypervolume. Para se
obter o valor do indicador I de uma solução em relação à outra, encontra-se o volume da área
dominada por uma solução e não-dominada pela outra. Dessa forma, levando-se em consideração
uma duas soluções A e B, o cálculo do indicador I(A,B) é referente à área dominada pela solução
A e não-dominada pela solução B.
Esse indicador é calculado entre cada par ordenado de soluções, fazendo com que
uma solução tenha vários valores desse indicador. O valor de aptidão final é obtido pelo somatório
de todos os valores do indicador I para uma solução. O cálculo é dado por:
f (xi) = ∑x j∈(P−{xi})
−e−I({x2},{x1})k (2.6)
onde k é um fator de escalonamento dependente de I e do problema, e deve ser maior que zero.
-
29
Figura 7 – Representação cálculo da aptidão da solução no algoritmo IBEA.
Fonte – Adaptado de Nebro et al. (2009).
Esse cálculo representa uma medida de perda de qualidade na convergência em relação à Frente
Real, quando o indicador I for o Hypervolume. Conclui-se que, quanto maior for seu valor,
melhor é a solução.
2.5 SEARCH BASED SOFTWARE ENGINEERING
Durante o desenvolvimento de sistemas podem surgir problemas onde a subjetividade
humana não seja a técnica mais precisa a ser utilizada, como é o caso de problemas com
soluções difíceis em relação ao atendimento das restrições ou cujos interesses envolvidos sejam
conflitantes, onde a melhoria de um determinado aspecto impacta negativamente em outro.
Nesses casos em que encontrar a solução exata para um problema pode ser praticamente inviável,
determinar soluções com qualidade próxima à melhor possível, ou que pelo menos estejam
dentro de uma margem de tolerância aceitável, pode ser o ideal (HARMAN; JONES, 2001).
Neste sentido, em Harman e Jones (2001) é cunhado o termo Search Based Software
Engineering (SBSE), ou Engenharia de Software Baseada em Busca, onde os autores propõem
a aplicação de técnicas de otimização na resolução de problemas complexos da Engenharia
de Software, demonstrando que muitos dos problemas dessa área podem ser redefinidos como
problemas de busca, sendo resolvidos com algoritmos inteligentes, como os algoritmos evolucio-
nários e as meta-heurísticas. A indicação desse tipo de técnica dá-se pelo fato dos problemas
reais em Engenharia de Software envolverem muitas variáveis e formas de avaliação bastante
complexas. Muitas vezes esses problemas são definidos como NP-completo (HARMAN, 2007).
Convém citar que apesar de existirem trabalhos anteriores nesse contexto (MILLER; SPOONER,
-
30
1976), foi a partir de Harman e Jones (2001) que a SBSE passou a se desenvolver enquanto área.
Harman e Jones (2001) e Harman et al. (2012) definem o que é necessário para que
haja a conversão dos problemas de ES em problemas de busca, sendo:
• Representação do Problema, que deve corresponder a como a solução serárepresentada em ambiente computacional;
• Função de Avaliação, definida em termos da representação da solução;• Um conjunto de Operadores de Manipulação, que atuam dinamicamente sobre o
processo evolucionário.
Uma vez que o problema se adapte às condições descritas, Harman e Clark (2004)
explica que para lograr sucesso na aplicação das técnicas de SBSE é necessário que as métricas
adotadas na função de avaliação do problema apresente algumas características, como:
a) Grande espaço de busca: pequenos espaços de busca permitem sua exploração
completa. Entretanto, em espaços de buscas grandes (praticamente infinitos) a
adoção destas técnicas é justificada;
b) Baixa complexidade computacional: a busca por soluções requer várias (talvez
milhares) de avaliações da qualidade de uma solução. O impacto do custo
computacional dessa avaliação é inversamente proporcional à suas chances de
sucesso nessa aplicação;
c) Continuidade aproximada: descontinuidade em excesso pode prejudicar o pro-
cesso de busca, pois toda otimização baseada em busca se baseia no direciona-
mento dado pela função de avaliação. Portanto, quanto menos contínua é essa
função, menos ela pode contribuir nessa direção;
d) Ausência de solução ótima conhecida: em casos onde a solução ótima é conhe-
cida, não há a necessidade de se utilizar técnicas de otimização baseadas em
busca.
Diversos problemas da ES são abordados nos trabalhos de SBSE, como priorização
de requisitos (BAGNALL et al., 2001), planejamento de releases de software (RUHE; SALIU,
2005), manutenção de software (O’KEEFFE; CINNÉIDE, 2008), geração de dados para teste de
software (LAKHOTIA et al., 2007).
O gráfico na figura 8 mostra a quantidade de publicação em SBSE por ano, no
período compreendido entre 1975 e 2015.
O gráfico na figura 9 mostra a quantidade de publicações em SBSE por área. Observa-
se que a grande parcela dos trabalhos encontra-se no campo dos testes de software, sendo
-
31
Figura 8 – Gráfico do número de publicações em SBSE por ano.
Fonte – Adaptado de (ZHANG et al., 2015).
responsável por mais da metade das publicações geradas. A área de manutenção, tema abordado
nesta pesquisa, ocupa o segundo lugar em volume de publicações.
Figura 9 – Gráfico do número de publicações em SBSE por área.
Fonte – Adaptado de (ZHANG et al., 2015).
-
32
2.6 CONCLUSÃO
Este capítulo apresentou uma fundamentação teórica contendo os temas abordados
neste estudo. Inicialmente, foram explicados os motivos que levaram ao surgimento e evolução
da Engenharia de Software. Mostrou-se, também, como a evolução e manutenção do software
ganharam espaço, objetivando suportar o crescimento em larga escala da produção de softwares
mais complexos. Foi apresentado o conceito de repositórios de bugs, bem como a sua importância
no ciclo de vida dos software mantidos por uma comunidade.
Discutiu-se conceitos de otimização matemática, e foi explicado como se dá a for-
mulação de problemas mono-objetivos e multiobjetivos. A apresentação das métricas utilizadas
na comparação de soluções de técnicas multiobjetivos ajuda na compreensão da abordagem pro-
posta, bem como a explanação sobre as técnicas de busca adotadas. Por fim, foram apresentados
conceitos de Engenharia de Software baseada em Busca, e como outros trabalhos tem relação
com esta abordagem.
-
33
3 TRABALHOS RELACIONADOS
Este trabalho é pioneiro no tratamento do problema da priorização de bugs no campo
da Engenharia de Software Baseada em Busca. Devido a isso, a seleção de trabalhos relacionados
que contribuam nessa pesquisa inclui artigos científicos publicados no campo da Aprendizagem
de Máquina, em razão da natureza similar dos trabalhos. Além disso, traçou-se um paralelo
entre o problema abordado neste trabalho e o problema da priorização de requisitos, já bastante
discutido na comunidade de SBSE, em razão da similaridade existente entre ambos.
Dessa forma, este capítulo encontra-se dividido em duas seções. A primeira relata
trabalhos no campo da Aprendizagem de Máquina que buscam, em sua maioria, automatizar a
triagem de bugs. A segunda seção relata trabalhos no campo da SBSE que tratam da priorização
de requisitos para implementação, visto que este problema tem uma certa semelhança com o
assunto abordado neste estudo.
3.1 TRABALHOS RELACIONADOS A BUGS
Ao tempo em que faz uma caracterização sobre o funcionamento dos repositórios de
bugs nos projetos Eclipse e Firefox, os autores propõem em Anvik et al. (2005) uma abordagem
baseada em aprendizado de máquina para automatizar as tarefas de triagem de novos bugs e
a detecção de relatórios duplicados, que ocorre quando mais de um usuário informa a mesma
falha. Para a atividade de triagem foi usado o classificador SVM que, através da análise de oito
meses de histórico de dados do repositório Eclipse, conseguiu sugerir corretamente a pessoa que
atualmente implementou determinada tarefa com uma taxa de acerto em torno de 57%.
Em Kanwal e Maqbool (2010) os autores apresentam uma abordagem baseada
em aprendizado de máquina, utilizando especificamente o classificador SVM, que pretende
automaticamente atribuir um nível de prioridade para novos bugs informados, reduzindo o
esforço humano e economizando tempo e recursos que podem ser utilizados na realização das
tarefas de implementação. Os autores concluíram que há viabilidade na aplicação das técnicas
de classificação para atribuição automática de prioridade em bugs. Similarmente, em Kanwal
e Maqbool (2012), os autores propõem uma abordagem baseada em classificação de dados,
utilizando o classificador de Naïve Bayes e SVM para automaticamente priorizar os novos bugs
informados. Neste trabalho os autores concluíram que os resultados do classificador SVM foram
melhores que o algoritmo de Naïve Bayes para características textuais, enquanto que para as
categóricas o inverso foi observado. A diferença principal entre os dois trabalhos é a adição do
-
34
classificador Naïve Bayes, onde os autores identificaram que há determinadas circunstâncias em
que a acurácia desta técnica é maior.
A proposta descrita em Sharma et al. (2012) foca na predição do nível de prioridade
de um novo bug, baseado em técnicas de classificação como SVM, Naïve Bayes, k-Nearest
Neighbors e Neural Network, nos repositórios dos projetos Eclipse e Open Office1. O estudo
concluiu que tanto o SVM quanto a Neural Network atingiram alta acurácia, quando comparadas
aos algoritmos k-NN e Naïve Bayes.
Para mensurar a quantidade de experiência que um desenvolvedor possui em relação
a tarefas de manutenção, duas abordagens são propostas em Anvik e Murphy (2007). A primeira
delas determina a experiência a partir da análise de logs em repositórios de código-fonte, e a
segunda utiliza dados de um repositório de bugs, ambos do projeto Eclipse Plataform. Apesar de
atribuir níveis falsos de experiência para alguns desenvolvedores, as duas abordagens obtiveram
bons resultados. Já em Ma et al. (2009), os autores avaliam a viabilidade de calcular a experiência
de um desenvolvedor levando em conta a frequência de uso de determinado método no código-
fonte. Neste trabalho há uma seção que trata especificamente da quantificação da experiência do
desenvolvedor.
Em Anvik et al. (2006) é aplicado um algoritmo de aprendizado de máquina supervi-
sionado para sugerir um pequeno conjunto de possíveis desenvolvedores capazes de realizar a
correção de determinado bug, considerando um histórico de dados. Analisando os repositórios
dos projetos Eclipse e Firefox, atingiu-se níveis de precisão entre 57% e 64%. Baseada nesta
abordagem, em Anvik (2006) o autor propõe um estudo subsequente para avaliar o quão eficaz
foi a técnica aplicada, através de resultados de avaliação humana. Em Shokripour et al. (2013),
é proposta uma abordagem para recomendação de atribuição de tarefas de correção de bugs a
desenvolvedores, dividida em duas etapas. A primeira trata de predizer quais arquivos serão
afetados na resolução do bug, e isto é feito através do processo de extração de substantivos de
várias fontes de informação. A segunda etapa consiste em recomendar desenvolvedores baseado
na informação sobre quem previamente corrigiu falhas na região de código-fonte que sofrerá
alterações.1
http://www.openoffice.org/qa/issue_handling/submission_gateway.html
-
35
3.2 TRABALHOS SOBRE PRIORIZAÇÃO DE REQUISITOS
Os objetivos dos trabalhos que abordam priorização de requisitos em SBSE incluem
decidir em qual ordem os requisitos do software devem ser implementados, levando em consi-
deração fatores que maximizem o valor de negócio, como redução de riscos para o projeto ou
minimização do tempo de entrega do sistema, e buscando reduzir o esforço humano envolvido
nesta tarefa, gerando uma economia desse recurso.
Assim, em Baker et al. (2006) é apresentada uma abordagem automatizada de priori-
zação e seleção de componentes de software para implementação. No experimento conduzido
foram utilizados algoritmos gulosos e têmpera simulada. Os testes revelaram que a abordagem
proposta atingiu resultados melhores que a mesma atividade executada por especialistas humanos,
e que quando comparados os algoritmos, a têmpera simulada obteve melhores resultados.
Em Brasil et al. (2011) é apresentada uma abordagem baseada em otimização
multiobjetivo para o problema da priorização de requisitos de software, tendo como objetivos a
maximização do valor de negócio agregado e da satisfação do cliente, além da minimização dos
riscos do projeto. Ainda busca atender às restrições de precedência técnica entre requisitos e
respeitar os limites de tempo e orçamento disponíveis. Nos experimentos foram utilizados os
algoritmos genéticos NSGA-II, MOCell e um algoritmo de busca randômica. Em todos os testes
a busca randômica foi superada pelos outros dois algoritmos e, quando comparados NSGA-II e
MOCell, o segundo apresentou menor tempo de execução.
Já em Tonella et al. (2010) e Tonella et al. (2013), os autores tratam a priorização de
requisitos com um algoritmo genético capaz de incorporar o desejo humano, chamado algoritmo
genético interativo, afetando diretamente o processo de busca com as preferências elucidadas dos
usuários. Em ambos os estudos os autores comprovaram a robustez do algoritmo na presença
de erros ocasionados pela participação do usuário, tornando a técnica aplicável também em
contextos onde a influência do ser humano é apenas parcialmente confiável.
Por fim, em Pitangueira et al. (2015) é realizada uma revisão sistemática e um
mapeamento da literatura da área de seleção e priorização de requisitos em SBSE. Através deste
estudo os autores investigaram, analisaram, categorizaram e classificaram as abordagens em
SBSE que atacam esse problema, fornecendo um delimitador do estado da arte nessa área.
-
36
4 ABORDAGEM PROPOSTA
Este capítulo apresenta a abordagem proposta neste trabalho para a priorização de
bugs em repositórios de software livre e código aberto, dividindo-a em duas seções. A primeira
é referente ao processo de otimização multiobjetivo utilizado na etapa de geração das soluções
priorizadas. A segunda seção aborda a estratégia utilizada para recomendar ao desenvolvedor a
solução mais adequada do conjunto de soluções Pareto-ótimo, considerando-se para isso a sua
experiência em resolução de bugs nos diversos componentes do sistema.
Repositórios de bugs em projetos de software livre de código aberto costumam
receber diariamente novas informações de falhas descobertas. Essa é uma atividade estimulada
pela própria comunidade de usuários, pois é através da coleta e tratamento desses bugs que se dá
a evolução do sistema desenvolvido.
Entretanto, em virtude do número limitado de desenvolvedores disponíveis para
realizar as implementações das correções, decidir quais destes defeitos devem ser corrigidos e
em qual ordem essas tarefas devem ser executadas torna-se uma atividade desafiadora, conforme
explicado no capítulo 2. Sendo assim, propõe-se neste trabalho uma abordagem multiobjetivo que
recomende uma lista priorizada de bugs mais adequada ao nível de experiência do desenvolvedor,
considerando tanto o desejo do responsável técnico pela triagem dos bugs, quanto a opinião da
comunidade mantenedora.
A abordagem sugerida é composta por duas etapas, sendo elas:
a) Etapa de priorização dos bugs a serem recomendados ao desenvolvedor, considerando-
se as informações fornecidas por diferentes membros do repositório;
b) Etapa de recomendação de solução mais adequada ao desenvolvedor, levando-se
em conta seu nível de experiência nos diversos componentes do sistema.
A partir disso torna-se necessário definir, de forma abrangente, quais dados serão
utilizados como entrada das etapas referidas. Para tal, analisou-se como se dá a participação dos
contribuidores em repositórios de bugs, como Mozilla (2015) e KDE (2015), e constatou-se a
definição clara de três papéis:
a) Contribuidor comum: representado por qualquer usuário da comunidade. Pode
reportar novas falhas, acompanhar a evolução das correções implementadas,
participar de discussões através de comentários e opinar com seu voto sobre
quais bugs devem ser corrigidos. Não é exigido nenhum conhecimento técnico
prévio sobre o problema avaliado;
-
37
b) Especialista no domínio: possui as mesmas permissões do contribuidor comum,
além do conhecimento técnico sobre o domínio do repositório. Tem como atri-
buição principal definir o nível de prioridade que a resolução de um determinado
bug tem para o sistema, informando também que nível de experiência esse bug
demanda em relação aos diferentes componentes do sistema;
c) Desenvolvedor contribuidor: também possui as mesmas permissões do contribuir
comum. É exigido desse papel conhecimento técnico nas tarefas de implementa-
ção das correções, que podem estar associadas desde atividades de programação
de código-fonte até produção de documentação do sistema.
A Figura 10 mostra uma visão geral da abordagem proposta e como ocorre a relação
entre esse papéis.
Figura 10 – Visão geral da abordagem proposta.
Fonte – Elaborado pelo autor
Nesta ilustração, observa-se a sequência de passos que compõem esta abordagem.
Os passos 1, 2 e 3 já existem em repositórios de bugs atualmente. No passo 1, o contribuidor
relata um provável novo bug no software mantido. Em seguida, o especialista do domínio realiza
a triagem desse bug, confirmando sua existência ou rejeitando-o. Em caso de aceite, esse novo
bug é adicionando ao repositório, onde através do passo 3 os membros da comunidade expressam
-
38
o quão relevante ele é. O passo 4 indica o processo de otimização multiobjetivo proposto por
este trabalho, onde há a geração de um conjunto de soluções. Então, no passo 5 é utilizada
uma estratégia de recomendação, também proposta aqui, da solução mais adequada ao nível de
experiência do desenvolvedor.
Dado o ineditismo de pesquisas sobre priorização de bugs em SBSE, foi conduzido
um estudo preliminar onde apresentou-se uma abordagem mono-objetivo para este problema em
repositórios de software livre e código-aberto, com o intuito de verificar a viabilidade da proposta
junto à comunidade científica da área de SBSE. Nesse estudo também foram consideradas
as informações produzidas pelos papéis mencionados anteriormente, e definida uma função
ponderada de avaliação que atendia aos objetivos descritos no início deste capítulo.
O processo de otimização mono-objetivo torna mais simples a compreensão dos seus
resultados, uma vez que o espaço de busca torna-se mais definido que no processo de otimização
multiobjetivo (ABRAHAM; JAIN, 2005). Porém, embora os problemas do mundo real possam
ser expressos em termos de um único objetivo, eles seriam mais adequadamente formulados
em termos de múltiplos objetivos (GASPAR-CUNHA et al., 2013). Como resultado desse
processo têm-se não mais uma única solução para o problema, mas um conjunto de soluções
com qualidade equivalente. Assim, durante a evolução desta pesquisa, optou-se pela adoção do
processo de otimização multiobjetivo. Para mais detalhes sobre a abordagem mono-objetivo
encontra-se disponível no Apêndice A o artigo publicado no 7th International Symposium on
Search-Based Software Engineering.
4.1 ETAPA DE PRIORIZAÇÃO DE BUGS
A priorização de bugs em repositórios de software livre e código aberto consiste
em encontrar a melhor ordenação de bugs a serem corrigidos, considerando-se nessa decisão a
participação dos mais variados tipos de usuários que fazem parte da comunidade mantenedora.
As opiniões fornecidas pelos participantes tanto podem ser baseadas em critérios técnicos, como
no caso dos especialistas do domínio que definem a prioridade na correção de um determinado
bug, quanto apenas definidas pelo desejo pessoal em ter uma determinada falha corrigida ou uma
nova funcionalidade implementada. Além disso, há também a opinião sobre o quão impactante é
o bug para o funcionamento do software, levando-se em conta as consequências do surgimento
deste.
Visando lidar com tal problema, levantou-se que tipo de informações devem ser
-
39
fornecidas pelo repositório, de modo a capturar a opinião dos tipos de usuários definidos na seção
anterior. A relação das informações necessárias e que devem ser informadas pelo repositório é
dada a seguir:
a) A relevância de um bug, expressando o interesse que os membros da comunidade
mantenedora tem pela resolução de um determinado bug ou pela implementação
de uma nova funcionalidade. Não requer conhecimento técnico do software
mantido pelo repositório, e pode ser dado por qualquer contribuidor;
b) A prioridade de um bug, definindo o nível de antecedência que sua resolução
possui em relação a outros. Esta informação deve ser fornecida por um especia-
lista do domínio com conhecimento técnico capaz de determinar se a correção de
uma falha ou implementação de nova funcionalidade é mais urgente que outras;
c) A severidade de um bug, representando o quão grave é a limitação imposta pelo
mesmo ao funcionamento do software. Não exige conhecimento técnico sobre o
produto mantido.
d) A relação de precedência técnica dos bugs, informando quando a resolução de
um bug depende necessariamente da correção de outros. Exige conhecimento
técnico acerca das relações entre as diversas partes do sistema.
Estas informações são utilizadas como valores de entrada na formulação matemática
deste problema, como descrito adiante.
4.1.1 Modelagem Matemática do Problema
Considere B = {b1,b2,b3, · · · ,bN} o conjunto de todos os bugs reportados, ondeN é o número de bugs presentes no repositório disponíveis para a priorização. Considere
P = {p1, p2, p3, · · · , pM} um vetor de bugs do conjunto B, com ordenação específica, onde M éum parâmetro previamente definido pelo administrador do repositório, e que representa o número
de bugs apresentados em uma solução. Assim, a proposta de priorização de bugs concebida neste
trabalho consiste em:
Maximizar importance(P),
Minimizar risk(P),
sujeito a pos(P,bi)< pos(P,b j),se bi ≺ b j e b j ∈ P,
(4.1)
onde pos(P,bi) retorna a posição do bug bi no vetor P se bi ∈ P, e ∞ caso contrário. A restrição
-
40
definida nesse problema é referente à precedência técnica entre bugs, onde a correção de um bug
depende diretamente da resolução de outro. Assim, o vetor P representa uma possível solução
para o problema.
A função importance(P) estimula a resolução antecipada de bugs considerados de
maior prioridade pelo responsável técnico pela triagem dos bugs, ao tempo em que busca atender
ao desejo dos membros da comunidade mantenedora pela resolução de um determinado conjunto
de bugs. Esta função é dada por:
importance(P) =N
∑i=1
[priorityi + relevancei
2× (M− pos(P,bi)+1)× isIn(P,bi)
](4.2)
onde priorityi indica a prioridade dada por um especialista do domínio ao bug bi. relevancei
representa a relevância que o bug bi tem para os membros da comunidade mantenedora. A
função isIn(P,bi) indica quando bi está em P, retornando 1 se bi ∈ P, e 0 caso contrário. Ovalores de priorityi relevancei devem ser expressos por um número no intervalo [0,1]. A posição
que um bug bi ocupa em P reflete diretamente no valor de importance(P), sendo que a função
aumenta conforme os bugs com maior prioridade e/ou relevância são antecipados em P.
A função risk(P) incentiva a correção antecipada de bugs considerados mais severos,
reduzindo o risco da implementação tardia dos mesmos. Quanto maior é o risco associado a
um bug, mais cedo deve ser sua correção, minimizando, assim, os efeitos de sua existência. A
função é dada por:
risk(P) =N
∑i=1
severityi× pos(P,bi)× isIn(P,bi) (4.3)
onde severityi é o valor de severidade atribuído ao bug bi por um membro da comunidade
mantenedora. O valor de severity, assim como o de priority e relevance, deve ser expresso por
um número no intervalo [0,1]. A função risk(P) é diretamente afetada pelo posicionamento dos
bugs em P, tendo seu valor diminuído à medida que bugs com valor de severidade mais altos são
antecipados em P.
4.2 ETAPA DE RECOMENDAÇÃO DE SOLUÇÃO PARA O DESENVOLVEDOR
Como resultado do processo de otimização multiobjetivo tem-se um conjunto de
soluções ditas não-dominadas, que constituem a Frente de Pareto, consideradas as melhores em
termos de qualidade dentre todas as soluções geradas. Entretanto, surge com isso a dificuldade
-
41
em decidir qual a mais adequada ao desenvolvedor, tornando a seleção da melhor solução uma
atividade desafiadora e, por vezes, exaustiva. Caso a escolha seja realizada por um ser humano, a
fadiga causada por essa sobrecarga pode comprometer o resultado final.
Uma alternativa para mitigar esse problema é selecionar-se a solução da frente que
melhor equilibre os objetivos tratados, buscando minimizar as perdas em todos os eixos do
espaço de busca. Todavia, não há garantias que a solução eleita como a melhor contenha um
conjunto de bugs para os quais o desenvolvedor consiga implementar uma correção, seja por não
possuir a experiência que o bug exige em determinado componente do software, ou simplesmente
por não possuir motivação pessoal em corrigí-lo.
Propõe-se, então, uma forma de recuperar uma solução da Frente de Pareto na qual
a experiência exigida pelo bug nos diversos componentes do software se aproxime o máximo
possível da experiência possuída pelo desenvolvedor. Para isso, é necessário que algumas
informações sejam disponibilizadas pelo repositório, sendo elas:
a) Histórico do desenvolvedor contendo sua participação em tarefas de correção de
bugs, permitindo identificar em quais componentes do sistema se concentra sua
experiência e/ou sua preferência de atuação;
b) Opinião técnica de um especialista do domínio acerca do nível de experiência
exigida de um desenvolvedor em certos componentes do software para a efetiva
correção de um bug.
O cálculo da diferença entre a experiência exigida na resolução de um bug e a
possuída pelo desenvolvedor é realizado apenas para aquele membro que, em dado momento,
demanda uma solução para o problema, e não para todo o conjunto de membros desenvolvedores
ao mesmo tempo, visto que não há como saber quais destes encontram-se realmente disponíveis
para a execução das tarefas de correção de bugs. Este cálculo é aplicado apenas nos componentes
do software onde o bug possua alguma exigência.
4.2.1 Modelagem Matemática da Função de Compatibilidade
Considere C = {c1,c2,c3, · · · ,cD} o conjunto de todos os componentes do soft-ware mantido pelo repositório, onde D é o número total de componentes. Considere H =
{h1,h2,h3, · · · ,hD} o conjunto da experiência apresentada pelo desenvolvedor em cada com-ponente do software, onde hi representa o quanto de experiência o desenvolvedor d possui no
componente ci. Considere, também, E = {e1,e2,e3, · · · ,eD} o conjunto da experiência exigida
-
42
para a resolução de um bug em cada componente do software, onde ei representa o nível de
experiência exigido no componente ci para a resolução de um determinado bug. Assim, a função
que realiza o cálculo da compatibilidade entre o nível de experiência possuído pelo desenvolvedor
e o exigido pelos bugs que compõem uma solução é dada por:
compatibility(P,d) =[(M+1)M
2
]−
M
∑i=1
√√√√
D
∑j=1
(e j−h j
)2× require(bi,c j)
× (M− i+1)
(4.4)
onde M é o número de bugs presentes no vetor-solução P, e a função require(bi,c j) indica se o
bug bi exige alguma experiência no componente c j, retornando 1 se c j > 0, e 0 caso contrário.
A função compatibility(P) calcula a distância euclidiana entre os valores de ex-
periência exigidos por um bug bi e os valores de experiência possuídos pelo desenvolvedor
num componente c j, multiplicando o valor resultante pelo complemento da posição desse bug
em P, de forma que distâncias existentes em bugs colocados nas posições iniciais tenham um
impacto negativo mais significante para a solução. Quanto maior o valor obtido pela função
compatibility(P), mais similares são os valores de experiência exigida pelos bugs e possuída
pelo desenvolvedor.
4.3 CONCLUSÃO
Neste capítulo apresentou-se uma proposta de abordagem sistemática para a priori-
zação e recomendação de bugs em repositórios de software livre e código-aberto. Definiu-se,
também, como se dá a participação de diferentes papéis no repositório, elencando-se os prin-
cipais tipos de usuários e suas respectivas funções. Dessa forma, foi possível estipular o que é
necessário obter de informação no repositório, e se esse dado tem caráter técnico ou não.
A abordagem apresentada constitui-se de duas etapas. A primeira consiste em
priorizar os bugs disponíveis para correção no repositório, através de um processo de otimização
multiobjetivo, considerando-se a opinião técnica acerca do nível de urgência de um bug e
o desejo da comunidade mantenedora do software em corrigi-lo. Além disso, incentiva a
correção antecipada de bugs considerados mais severos, a fim de evitar danos maiores ao
sistema. Demonstrou-se, através de modelagem matemática, as funções importance(P) e
risk(P), denotadas como objetivos do processo de otimização.
Contudo, a estratégia proposta gera um conjunto de soluções com qualidade equi-
valente, o que pode ocasionar em uma sobrecarga de trabalho ao desenvolvedor no momento
-
43
em que este for selecionar uma solução para o problema. Propõe-se, então, uma forma de
recomendação da solução mais adequada para o desenvolvedor, considerando-se a maior compa-
tibilidade possível entre os níveis de experiência apresentados por ele e os exigidos pelos bugs
recomendados.
-
44
5 ESTUDO EMPÍRICO
Este capítulo descreve o estudo realizado para validar a abordagem multiobjetivo
proposta para priorizar bugs a serem corrigidos em repositórios de rastreamento de defeitos
(Bug Tracking Systems) de projetos de software livre e código aberto, bem como para avaliar
os resultados alcançados durante esse processo. Este estudo foi realizado utilizando-se dados
do repositório de bugs do projeto KDE, mais especificamente no subprojeto Kate Editor1.
Inicialmente apresentam-se as questões de pesquisa que nortearam este trabalho. A seguir,
é definida a metodologia adotada na aplicação dos experimentos, descrevendo detalhes da
composição das instâncias utilizadas, da configuração das meta-heurísticas escolhidas e as
métricas usadas para comparação de desempenho dos algoritmos testados. Após isso, há
a apresentação dos resultados obtidos, seguidos de suas respectivas análises. Por fim, são
estabelecidas as ameaças à validade e tecidas as considerações finais. Para permitir a replicação
deste experimento, todas as instâncias, resultados e código-fonte estão disponíveis para acesso
público2.
5.1 QUESTÕES DE PESQUISA
A abordagem proposta neste trabalho é constituída de duas etapas. A primeira diz
respeito ao processo de otimização multiobjetivo utilizado na priorização dos bugs disponíveis
no repositório do Kate Editor, e a segunda etapa é referente ao processo de recomendação de uma
solução para um desenvolvedor, baseado na equivalência entre o nível de experiência exigido
para corrigir um bugs e aquele possuído por um desenvolvedor. Assim, este experimento foi
conduzido de modo a responder as duas questões de pesquisa descritas a seguir:
QP01: De acordo com as métricas de desempenho adotadas, qual das técnicas de busca
avaliadas obteve melhores resultados?
QP02: Dado o conjunto final de soluções produzidas, qual o resultado prático da aplicação
da estratégia de recomendação proposta?
5.2 METODOLOGIA
Para a realização deste experimento foram construídas três instâncias distintas,
sendo duas compostas com informações pertinentes aos bugs disponíveis no repositório e uma1 2
http://kate-editor.org/http://goes.uece.br/duanydreyton/dissertacao/
-
45
com informações referentes aos desenvolvedores. A complexidade envolvida no processo de
priorização em repositórios de bugs e a consequente escolha de meta-heurísticas multiobjetivo,
além do processo de aquisição dos dados e construção das instâncias são descritos descrito a
seguir.
5.2.1 Complexidade do Problema
Para este trabalho, tem-se um total de 280 bugs coletados para estudo. Desejando-
se, hipoteticamente, que seja gerada uma lista priorizada contendo 30 bugs para correção e
seguindo-se a norma de arranjos simples, tem-se aproximadamente 1,30∗1075 formas diferentesde compor uma solução, desprezando-se a única ocorrência de restrição de precedência técnica
presente no conjunto de dados. A magnitude deste valor contribui na decisão sobre a utilização
de meta-heurísticas para a tarefa de priorização de bugs, visto que a adoção de técnicas exaustivas
que testassem todas as alternativas diferentes de solução consumiria quantidades muito altas de
tempo computacional.
Além disso, conforme análise de correlação linear realizada entre os valores obtidos
pelas funções-objetivo apontou, os objetivos modelados matematicamente para o processo de
otimização são conflitantes, pois seus valores crescem no mesmo sentido. Uma vez que a função
importance(P) é de maximização e a função risk(P) é de minimização, é desejável que os valores
obtidos por essas funções cresçam em sentidos opostos. Com isso, é pertinente a adoção de uma
técnica de otimização multiobjetivo, dada a dificuldade em conciliar os interesses envolvidos em
cada uma dessas funções. A análise de correlação linear é descrita na Seção 5.3.
5.2.2 Instância de bugs coletados
A instância dataset-bugs-kate contém detalhes sobre todos os bugs disponíveis para
resolução no repositório do Kate Editor, até a data de 19 de fevereiro de 2016, e conta com um
total de 280 bugs. Assume-se que um bug está disponível para resolução quando ele encontra-se
em algum desses três estados:
a) Unconfirmed: bugs que foram recentemente adicionados ao repositório, mas
ainda não foram devidamente confirmados e aceitos como sendo válidos;
b) Confirmed: bugs considerados como válidos e disponíveis para serem corrigidos;
c) Reopened: bugs que em algum momento foram encerrados, mas posteriormente
necessitaram ser reabertos.
-
46
Bugs do tipo Unconfirmed foram considerados nesta abordagem por potencialmente
serem convertidos em Confirmed.
Durante a análise dos dados, a informação relevante presente no repositório para ser
usada no modelo proposto foi identificada