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