Predição de falhas em sistemas abertos de requisição de software

(1)

Universidade Federal Fluminense

Instituto de Computa¸

c˜

ao

Departamento de Ciˆ

encia da Computa¸

c˜

ao

LUCAS PINHEIRO PAIM

PREDI ¸

C ˜

AO DE FALHAS EM SISTEMAS

ABERTOS DE REQUISI ¸

C ˜

AO DE SOFTWARE

Niter´

oi-RJ

2017

(2)

LUCAS PINHEIRO PAIM

PREDI ¸C ˜AO DE FALHAS EM SISTEMAS ABERTOS DE REQUISI ¸C ˜AO DE SOFTWARE

Trabalho submetido ao Curso de Bacharelado em Ciência da Computa¸cão da Universidade Federal Fluminense como requisito parcial para a obten¸cão do t´ıtulo de Bacharel em Ciência da Computa¸cão.

Orientadora: Prof. Aline Marins Paes Carvalho

Niter´oi-RJ 2017

(3)

(4)

(5)

v

Agradecimentos

Agrade¸co aos meus pais Afonso e Silvia, pelos esfor¸cos realizados para me proporcionar uma boa educa¸cão, sem a qual eu não teria chegado até aqui. Também agrade¸co aos meus irmãos e minha familia pelo apoio. Agrade¸co a todos meus professores pelas li¸cões

e especialmente minha orientadora, Aline Paes, pelos ensinamentos e pela confian¸ca depositada em mim para realiza¸c˜ao deste trabalho.

(6)

Resumo

Sistemas de Gerenciamento de Requisi¸cões online são ferramentas que podem ser utilizadas para acompanhar e apoiar o ciclo de vida de um software. É através dessas ferramentas que usuários, desenvolvedores e administradores podem reportar defeitos em um software ou podem solicitar melhorias a partir da cria¸cão de uma requisi¸cão. Porém,

a quantidade de solicita¸cões de um projeto pode ser muito grande e o esfor¸co para analisar todas as requisi¸cões pode se tornar inviável. Decidir qual requisi¸cão deve ser priorizada, aceita ou rejeitada se torna uma tarefa complexa. Nesse cenário, assumindo

que uma requisi¸cão possui uma falha uma ferramenta que possa classificar o tipo falha poderia ser útil. Uma requisi¸cão com grandes chances de se tornar uma falha poderia ser

revisada com objetivo de mitigar esse risco. Esse trabalho extrai e analisa dados históricos de requisi¸cões de um projeto real chamado Mozilla Firefox que possuiam alguma falha e utiliza técnicas e algoritmos de Aprendizado de Máquina para constru¸cão de um modelo de previsão de tipos de falhas de software, a partir de requisi¸cões feitas no

Sistema de Gerenciamento Online chamado Bugzilla. Além de atributos estruturais, como quantidade de participantes, data transcorrida entre a requisi¸cão e a associa¸cão de

um desenvolvedor, comentários feitos pelos participantes da discussão também são levados em considera¸cão. Parte dos dados das requisi¸cões são utilizados para treinamento do modelo e outra parte para avalia¸cão. Os resultados experimentais obtidos a partir dos dados não utilizados para o treinamento são satisfatórios e mostram

que esse modelo poderia apoiar administradores no momento de tomar decisões Palavras-chave: Sistemas Abertos de Requisi¸cão de Software; Aprendizado de Máquina;

(7)

vii

Abstract

Online Feature Request Management Systems are tools used to follow and support the life cycle of a software. From such tools, the stakeholders can report bugs or create feature requests. However, the number of possible bugs and requests in a large project

can be massive and the necessary time and effort to analyze all of them may not be feasible. Deciding which request should be prioritized, accepted or rejected can turn into

a complex task. In this scenario, assuming that a request have some failure, a tool that can predict the type of a possible failure in a request would be useful. One request with

high chances of becoming a failure could be revised in order to mitigate this risk. This work extracts and analyzes historical feature requests and bug reports data of a real

project called Mozilla Firefox and then uses Machine Learning techniques and algorithms to create a model to predict software failures in a Feature Request Management System called Bugzilla. Besides structural attributes such as number of

participants in the discussion and date of an assignment, the words included at the comments are also taken into account. Part of the original data is used to train the model and the other part is used to make predictions from the induced models. The predictive experimental results are satisfactory and show that this model could be useful

to support the stakeholders to take decisions.

Keywords: Open Request Management Systems; Machine Learning; Data Mining; Text Mining; Dimensionality Reduction

(8)

Sum´

ario

Resumo vi Abstract vii Lista de Figuras x Lista de Tabelas xi 1 Introdu¸c˜ao 1

1.1 Objetivos e Contribui¸c˜oes . . . 2

1.2 Organiza¸c˜ao do Texto . . . 3

2 Fundamenta¸cão Teórica 4 2.1 Sistemas de Gerenciamento de Requisi¸cões de Software . . . 4

2.2 Aprendizado de M´aquina . . . 8

2.2.1 Exemplos de Algoritmos de Aprendizado Supervisionado . . . 10

2.2.2 Redu¸c˜ao de Dimensionalidade . . . 12

2.3 Pr´e-Processamento . . . 13

2.4 Trabalhos Relacionados . . . 15

3 Predi¸c˜ao de Falhas em Projetos de Software com Atributos Estruturais e de Linguagem Natural 18 3.1 Vis˜ao Geral . . . 18

3.2 Extra¸c˜ao de Dados . . . 20

3.3 Sele¸c˜ao de Atributos . . . 24

3.3.1 Tratamento dos Atributos de Linguagem Natural . . . 25

3.4 Indu¸c˜ao do Classificador . . . 26 viii

(9)

ix 4 Resultados Experimentais 28 4.1 Base de Dados . . . 28 4.2 Metodologia Experimental . . . 29 4.3 Resultados . . . 30 4.4 Resultados Obtidos . . . 31 5 Conclus˜ao 36

(10)

Lista de Figuras

2.1 Ciclo de Vida de uma Requisi¸c˜ao. [Bugzilla Lifecycle] . . . 7

2.2 SVM . . . 10

2.3 Sigmoid . . . 12

3.1 Workflow. . . 19

3.2 Requisi¸c˜ao 171702 - Mozilla Firefox. . . 21

3.3 Hist´orico (parte 1) Requisi¸c˜ao 171702 - Mozilla Firefox. . . 23

3.4 Hist´orico (parte 2) Requisi¸c˜ao 171702 - Mozilla Firefox. . . 23

3.5 Coment´arios da Requisi¸c˜ao 171702 - Mozilla Firefox. . . 25

(11)

xi

Lista de Tabelas

4.1 Logistic Regression. . . 31 4.2 Naive Bayes. . . 32 4.3 Random Forest. . . 33 4.4 SVM. . . 33 4.5 SVMS . . . 33

4.6 Matriz Confus˜ao (M´edia) Naive Bayes PCA . . . 34

4.7 Matriz Confus˜ao (Mediana) Naive Bayes PCA . . . 34

4.8 Matriz Confus˜ao (M´edia) Naive Bayes LDA 1000 . . . 34

4.9 Matriz Confus˜ao (Mediana) Naive Bayes LDA 1000 . . . 34

4.10 Matriz Confus˜ao (M´edia) RF LDA 1000 . . . 35

(12)

Cap´ıtulo 1

Introdu¸

c˜

ao

Sistemas de Gerenciamento de Requisi¸cões de Software online são ferramentas utilizadas por pessoas envolvidas em um projeto durante a evolu¸cão de um sistema. A partir de tais sistemas, cujo exemplo mais utilizado e conhecido é o Bugzilla1_{, usu´}_{arios, gerentes e}

desenvolvedores podem relatar defeitos e solicitarem melhorias em um

software [Bird et al. 2008]. Os grandes projetos possuem muitas requisi¸cões de software e decidir qual delas deve ser de fato implementada, e dentre estas qual é a mais prioritária, qual requer mais aten¸cão e o quanto de tempo se deve analisar uma

requisi¸c˜ao acaba se tornando um problema.

Aceitar uma requisi¸cão de software a partir de uma análise muito rápida, sem que todos os requisitos tenham sido entendidos pode impactar negativamente o software no futuro, devido à introdu¸cão de falhas e consequente interrup¸cão do desenvolvimento. Por outro

lado, uma análise muito longa pode ser um desperd´ıcio de tempo e recursos, principalmente se a requisi¸cão for rejeitada. Esse problema se agrava em sistemas de requisi¸cão online, visto que qualquer usuário, em qualquer lugar do mundo, pode abrir

uma solicita¸cão. Prever de forma automática quais requisi¸cões tem mais chances de falhar poderia ajudar a tomar uma decisão de aceitar/rejeitar uma requisi¸cão. Essa monografia proprõe a constru¸cão de uma ferramenta de previsão de alguns tipos de

falhas em requisi¸cões inseridas em um sistema de utilizando Aprendizado de Máquina [Mitchell 1997, Abu-Mostafa, Magdon-Ismail e Lin 2012]. Para tanto, é essencial que dados históricos sejam coletados de requisi¸cões passadas, ao mesmo tempo

em que uma poss´ıvel falha seja identifica e categorizada, sem a direta interven¸c˜ao

1_{https : //www.bugzilla.org/}

(13)

2 humana.

1.1 Objetivos e Contribui¸

c˜

oes

O objetivo principal desta monografia é classificar automaticamente o tipo de falha de projeto que pode surgir a partir de uma requisi¸cão de software, usando somente as informa¸cões já existentes em um sistema de gerenciamento de requisi¸cão de software. Além dos metadados associados à requisi¸cão, tais como participantes envolvidos, tempo

decorrido entre a inclusão da requisi¸cão e uma resposta, consideraremos também os comentários inclu´ıdos no sistema, tanto pelos desenvolvedores e gerentes como também

pelos usu´arios .

Para possibilitar a constru¸cão de um modelo capaz de prever falhas em projetos de requisi¸cão de software a partir da análise dos dados de uma requisi¸cão, foram implementados quatro componentes principais: (1) coleta de dados históricos de requisi¸cões de software e classifica¸cão dos tipos de falhas encontradas; (2) conversão dos meta-dados coletados para um formato processável por uma ferramenta de aprendizado de máquina (3) aplica¸cão de técnicas de Aprendizado de Máquina para constru¸cão de um modelo de previsão de falhas futuras; (4) análise dos resultados obtidos através dos

testes realizados no modelo.

[Fitzgerald, Letier e Finkelstein 2012] primeiramente definiram alguns tipos de falhas, coletaram atributos a partir de meta-dados (atributos estruturais) e coment´arios das requisi¸c˜oes (atributos de palavras). Depois, os autores usaram os algoritmos Decision Table, Naive Bayes, Linear Regression and M5P-Tree algorithms para predizer o tipo de

falha de que ocorreu em uma requisi¸cão de forma automática. Nesse trabalho, utilizamos os mesmos tipos de falhas definidos no trabalho anterior. Além disso, consideramos os algoritmos que obtiveram os melhores e piores resultados, bem como

outros algoritmos que tem se mostrado úteis no aprendizado de máquina a partir de textos. Como atributos oriundos de palavras tendem a gerar valores esparsos, experimentamos dois algoritmos de redu¸cão de dimensionalidade que não foram

(14)

1.2 Organiza¸

c˜

ao do Texto

Primeiramente serão explicados os conceitos e fundamentos necessários para o entendimento do projeto no cap´ıtulo 2. No cap´ıtulo 3 serão apresentadas as ferramentas

constru´ıdas para a extra¸cão de dados e para o aprendizado do modelo de previsão de falhas. Os testes realizados e os resultados obtidos serão apresentados no cap´ıtulo 4. Por

(15)

Cap´ıtulo 2

Fundamenta¸

c˜

ao Te´

orica

Nesse capitulo são abordados os conceitos e defini¸cões necessários para o entendimento do trabalho. A Se¸cão 2.1 define e apresenta um exemplo de Sistema de Gerenciamento

de Requisi¸cões de Software, a saber, é explicado como o Bugzilla gerencia relatórios de erros e solicita¸cões de melhorias em softwares diversos. A Se¸cão 2.2 apresenta uma breve

revisão sobre aprendizado de máquina. A Se¸cão 2.3 mostra as principais técnicas de pré-processamento de texto, e que serão utilizadas nesse trabalho para tratamento dos

comentários de requisi¸cões. Finalmente, a Se¸cão 2.4 revisa os principais pontos associados ao trabalho que motivou o desenvolvimento dessa monografia, bem como

outros trabalhos relacioados ao tema explorado aqui.

2.1 Sistemas de Gerenciamento de Requisi¸

c˜

oes de

Software

Sistemas de gerenciamento de requisi¸cão de software são ferramentas que gerenciam erros (bugs) e requisi¸cões de mudan¸cas de um determinado projeto de software. Muitos

projetos de c´odigo aberto, tais como Firefox 1 _{e Tomcat} 2_{, bem como alguns softwares}

proprietários, utilizam tais sistemas para fazer todo gerenciamento e acompanhamento de erros e melhorias de um projeto, tendo como base as requisi¸cões e sugestões de

usuários. Atualmente, tais ferramentas são disponibilizadas online, de forma que qualquer pessoa interessada no uso, melhorias e atualiza¸cões do software é capaz de

1

https://www.mozilla.org/en-US/firefox

2_{http://tomcat.apache.org/}

(16)

submeter requisi¸cões de novos atributos, contribuir para discussões no processo de desenvolvimento, sugerir peda¸cos de código que resolveriam erros e acompanhar as discussões e modifica¸cões implementadas. Tanto desenvolvedores, como gerentes e usuários podem reportar e particpar da discussão em trilhas espec´ıficas. Além das discussões, um conjunto de meta-dados costumam ser associados com as requisi¸cões, para que seja poss´ıvel recuperar facilmente informa¸cões como o status da requisi¸cão, o

desenvolvedor associado à requisi¸cão, outras requisi¸cões relacionadas, etc [Cleland-Huang et al. 2009].

O Bugzilla3 _´_{e um exemplo bastante conhecido e utilizado de sistema de gerenciamento}

de requisi¸cão de software. A partir dele é poss´ıvel que qualquer pessoa, seja um usuário do software, desenvolvedor, ou administrador, reporte um erro ou fa¸ca uma requisi¸cão de uma melhoria desejada ou necessária no software. Uma vez que uma requisi¸cão foi feita,

todos os usuários podem fazer comentários sobre essa requisi¸cão, anexar arquivos e acompanhar todo o ciclo de vida dessa requisi¸cão.

Particularmente, o ciclo de vida de uma requisi¸c˜ao do Bugzilla ´e especificado de forma simplificada a seguir:

1. Um usuário cria uma requisi¸cão reportando um erro ou pedindo uma melhoria do software. Inicialmente, essa requisi¸cão fica com status de ”Unconfirmed”, pois ainda ´

e necessária a confirma¸cão de que a situa¸cão relatada pelo usuário pode ser válida. A partir desse momento, outros usuários podem comentar, perguntar e argumentar na requisi¸cão criada.

2. Após algum tempo, um usuário que possua um perfil com privilégios para confirmar uma requisi¸cão e que julgue, a partir das informa¸cões dispon´ıveis, que o pedido feito pelo usuário é válido, muda o status da requisi¸cão para ”New”. O status ”New”significa que a requisi¸cão está confirmada, e nesse momento um desenvolvedor pode ser escolhido para desenvolver a altera¸cão no software que (desejavelmente) resolverá o erro ou a implementa¸cão da melhoria requisitada.

3. Quando um desenvolvedor é escolhido, o status da requisi¸cão é alterado para ”As-signed”.

3

(17)

6 4. Ao término do desenvolvimento da requisi¸cão, o status é alterado para ”Resolved”.

O status ”Resolved”recebe um dos poss´ıveis tipos de resolu¸c˜ao: FIXED: A corre¸c˜ao do erro (ou melhoria) foi desenvolvida.

DUPLICATE: Existe outra requisi¸cão que fez a mesma solicita¸cão. WONTFIX: A corre¸cão do erro (ou melhoria) não será desenvolvida. WORKSFORME: Não foi poss´ıvel reproduzir o erro.

INVALID: O pedido feito na requisi¸cão não é válido.

5. Após o desenvolvimento, são realizados testes sobre a requisi¸cão desenvolvida. Caso a requisi¸cão seja de fato aprovada pelos testes de qualidade e a posi¸cão de imple-mentar a melhoria desenvolvida seja mantida, o status da requisi¸cão passa a ser ”Verified”, e o peda¸co de código desenvolvido está livre para ser integrado ao soft-ware. Caso a equipe de qualidade rejeite a implementa¸cão desenvolvida, a requisi¸cão pode ser reaberta, possivelmente voltando para estado de em desenvolvimento. O status de ”REOPEN”ainda pode ser atingido após a verifica¸cão, caso a equipe de qualidade tenha falhado em verificar algum problema, ou o problema tenha apare-cido novamente no software.

6. Ap´os essa integra¸c˜ao, o bug tem seu estado final alterado para ”Closed”.

A figura ?? exibe o ciclo de vida com todos os status poss´ıveis de uma requisi¸c˜ao, bem como as transi¸c˜oes entre eles.

A comunica¸cão em requisi¸cões de software é feita através de comentários, e essa comunica¸cão pode ter falhas como ambiguidade, inconsistência e omissões. Essas falhas

de comunica¸cão podem se transformar em falhas no processo de desenvolvimento de software e no produto. Uma requisi¸cão de software pode ser rejeitada precocemente quando o correto era ser aceita. O tempo até que seja notado que a requisi¸cão deveria

ter sido aceita é um tempo perdido, pois a requisi¸cão já poderia ter sido resolvida e o usuário estaria mais satisfeito. Em contrapartida, pode ser que uma requisi¸cão seja aceita precocemente sem que todos os requisitos tenham sido bem entendidos e isso cause

uma falha no futuro, fazendo com que o desenvolvimento seja interrompido, ou um bug seja introduzido. S˜ao esses os tipos de falhas que desejamos prever antes de tomar uma

(18)

(19)

8 decisão de aceitar ou rejeitar uma requisi¸cão de software. Como não é trivial realizar

essas predi¸cões manualmente, serão utilizadas técnicas de aprendizado de máquina.

2.2 Aprendizado de M´

aquina

Estamos acostumados a desenvolver programas em que, a partir de uma entrada, é implementado um processamento para transformar tal entrada em uma sa´ıda. Por exemplo, um programa com objetivo de somar dois valores receberia uma entrada (valores “1” e “3”), faria um processamento (somar “1” mais “3”) e produziria como sa´ıda o resultado dessa soma (“4”). A fun¸cão de soma é conhecida e por isso é fácil desenvolver esse programa. Existem diversas outras situa¸cões em que a fun¸cão que necessitamos é desconhecida. Suponha que queremos desenvolver um programa que classifique se um

email é spam ou não. Não conhecemos nenhuma fun¸cão que possa ser facilmente implementada de forma a fazer esssa determina¸cão.

Assim, para construir essa fun¸c˜ao desconhecida, podemos utilizar t´ecnicas e algoritmos de aprendizado de

máquina [Mitchell 1997, Alpaydin 2009, Abu-Mostafa, Magdon-Ismail e Lin 2012]. Poder´ıamos ter, por exemplo, um conjunto de emails antigos e cada email com uma classifica¸cão informando se um email é spam ou não. Esse conjunto de dados é chamado

de conjunto de treinamento e ele é composto por atributos e uma classe (ou rótulo). Os atributos são os dados de entrada, e a classe é o dado de sa´ıda. Para o exemplo acima,

os atributos poderiam ser os campos assunto, corpo do email, remetente, destinatário, bem como cada palavra que constitui o corpo do email. A classe seria um campo informando se aquele email é spam ou não. O conjunto de treinamento é usado para

descobrir de forma automática a fun¸cão desconhecida. Para medir o desempenho da fun¸cão aprendida, é necessário usar outro conjunto de dados, com emails que não perten¸cam ao conjunto de treinamento, chamado de conjunto de testes. Já utilizamos

softwares que possuem aprendizado de máquina frequentemente no nosso dia a dia e muitas vezes não percebemos. Toda vez que fazemos uma busca no Google, existe um algoritmo de aprendizado que aprendeu a classificar páginas web. Quando entramos no

nosso email, há um filtro que aprendeu a identificar se um email é spam ou não. Formalmente, aprendizado de máquina é definido a seguir [Mitchell 1997]:

(20)

“Um programa aprende a partir de uma experincia E, com rela¸c˜ao a uma classe de tarefas T , com medida de desempenho P , se seu desempenho em T , medido por P ,

melhora com E.”

Usando o exemplo do programa para classificar um email como spam ou n˜ao-spam e a defini¸c˜ao acima, temos:

• Tarefa T: Classificar emails como spam ou n˜ao-spam.

• Medida de desempenho: Percentagem de emails classificados corretamente.

• Experiência de treinamento: conjunto de dados com emails antigos contendo a clas-sifica¸cão se um email é spam ou não.

As abordagens existentes de Aprendizado de Máquina são classificadas em Aprendizado supervisionado, Aprendizado não-supervisionado e Aprendizado por refor¸co. Em aprendizado de máquina supervisionado, tanto os valores dos atributos como o rótulo do

exemplo são fornecidos de antemão. Os algoritmos supervisionados podem ser de regressão ou de classifica¸cão. Os algoritmos supervisionados de regressão têm por objetivo descobrir uma fun¸cão cuja sa´ıda não é discreta. Suponha que queremos aprender a estimar o valor de uma casa a partir do seu tamanho. Ter´ıamos um conjunto

de treinamento contendo dados hist´oricos de diversas casas com diversos tamanhos e seus respectivos valores. O trabalho do algoritmo seria criar uma fun¸c˜ao h, tal que, dado

um valor x (tamanho da casa), ter´ıamos uma resposta y (valor da casa). Os algoritmos de classifica¸cão têm por objetivo descobrir uma fun¸cão cuja sa´ıda é discreta. Como exemplo de algoritmo de classifica¸cão temos um programa para classificar se um email é spam ou não. Nesse caso, ter´ıamos um conjunto de treinamento contendo emails antigos com os rótulos de spam ou não-spam. O objetivo do algoritmo é construir uma fun¸cão

que classifique novos emails como spam ou n˜ao-spam.

No aprendizado não-supervisionado não são especificados rótulos para os exemplos no conjunto de dados. O algoritmo analisa os exemplos fornecidos e tenta agrupá-los de alguma maneira. Suponha, por exemplo, uma empresa que tenha um banco de dados de informa¸cões sobre clientes. O objetivo do algoritmo seria agrupar os clientes em diversos

segmentos. O conjunto de treinamento n˜ao contem nenhum r´otulo informando qual cliente pertence a qual grupo, mas mesmo assim o algoritmo faz um agrupamento os

(21)

10 clientes. O algoritmo K-means ´e um exemplo de algoritmo de aprendizado

n˜ao-supervisionados.

Finalmente, no aprendizado de m´aquina por refor¸co os agentes devem aprender o comportamento ideal a partir de feedbacks positivos e negativos. Por exemplo, uma

gorjeta alta para um agente taxista pode significar que o agente fez alguma a¸c˜ao positiva. Em contrapartida um feeback negativo, como a ausˆencia de uma gorjeta pode

significar que o agente fez algo errado ou deixou de fazer alguma a¸c˜ao.

2.2.1 Exemplos de Algoritmos de Aprendizado Supervisionado

Neste trabalho, utilizamos de regras espec´ıficas para rotular os exemplos. Assim, os algoritmos utilizados no trabalho pertencem a categoria de aprendizado supervisionado.

Dessa forma, explicamos com mais detalhes os algoritmos que ser˜ao experimentados no cap´ıtulo 4.

Figura 2.2: SVM

O SVM [Scholkopf e Smola 2001, Cortes e Vapnik 1995] é uma técnica de classifica¸cão supervisionada baseada em fun¸cões de kernel. Suponha um ambiente bidimensional em que desejamos separar duas classes distintas (circulos e quadrados) conforme ilustrado na Figura 2.2. Existem diversas maneiras de realizar essa separa¸cão, mas o algoritmo busca

(22)

um hiperplano ótimo que separa essas duas classes. O hiperplano ótimo é o hiperplano de separa¸cão com margem máxima. A margem máxima é obtida pela distância entre o

hiperplano e os vetores mais próximos a ele, que são chamados de vetores suportes. Para encontrar os hiperplanos, é necessário encontrar os pesos que maximizam a margem entre as classes. Em um exemplo com duas classes, temos as equa¸cões 2.1 e 2.2,

no caso de uma fun¸c˜ao de kernel linear.

wT ∗ xt + w0 ≥ +1 f or rt = +1 (2.1) wT ∗ xt + w0 ≤ −1 f or rt = −1 (2.2) onde wT é um vetor de pesos, xT é o vetor de atributos, wo é o valor do bias e rt é o

rótulo para a classes. O critério também pode ser relaxado para permitir que alguns exemplos sejam classificados incorretamente, aceitando então uma boa margem que não

necessariamente é a ótima (e que é mais dif´ıcil de encontrar). Alé disso, é importante ressaltar que as fórmulas acima induzem uma separa¸cão linear entre os dados. Quando não é esse o caso, é usado um truque de kernel, para transformar o espa¸co de atributos.

Random Forest [Breiman 2001] é uma técnica de classifica¸cão supervisionada de aprendizado de máquina baseada em diversas árvores de decisão. A partir do conjunto

de treinamento inicial são constru´ıdos diversos subconjuntos aleatórios, contendo os atributos e seus respectivos rótulos. Para cada subconjunto criado, uma árvore de decisão distinta é induzida a partir dos dados. No momento de avalia¸cão, os dados a

serem classificados devem passar por todas árvores de decisão e cada uma terá uma resposta (diferente ou não). É feito um ranking com as respostas dadas pelas árvores de

decis˜ao e aquela resposta com maior valor, ser´a a resposta final.

Naive Bayes é uma técnica de classifica¸cão supervisionada de Aprendizado de Máquina baseada no Teorema de Bayes4_{. O algoritmo assume que os valores dos atributos s˜}_ao

independentes dos outros valores. Uma fruta, por exemplo, pode ser classificada como uma melancia se for grande, com exterior de cor verde e interior de cor vermelho. O classificador Naive Bayes considera que esses três atributos (tamanho, cor externa, cor interna) contribuem independentemente para a probabilidade da fruta ser uma melancia. A regressão log´ıstica é um tipo de modelo de classifica¸cão probabil´ıstico que possui como

objetivo estimar o valor de classe de uma vari´avel dependente a partir de outras

4

(23)

12 variáveis discretas e/ou cont´ınuas [Hosmer 2000]. É baseada na fun¸cão sigmoide, ilustrada na figura 2.3, a qual varia entre 0 e 1, logo, indica a probabilidade de algo

acontecer ou n˜ao acontecer.

Figura 2.3: Sigmoid

2.2.2 Redu¸

c˜

ao de Dimensionalidade

Em diversas situa¸cões, a quantidade de atributos associados a um exemplo é maior do que um algoritmo de aprendizado pode suportar. Outro problema associado à quantidade de atributos vem do fato que muitas vezes estes não são relevantes o suficiente para serem adotados na fun¸cão a ser aprendida. Porém, é dif´ıcil determinar de

antem˜ao e a olho nu quais atributos deveriam ser removidos, de forma a ainda ter uma amostra significativa do problema. Nesses casos, podem ser utilizadas t´ecnicas de

redu¸cão de dimensionalidade [Roweis e Saul 2000]. Nesse trabalho, inclu´ımos a possibilidade de utiliza¸cão de duas técnicas distintas, a saber, a Análise de Componentes

Principais (PCA) [Jolliffe 2002] e a An´alise de Discriminantes

Lineares(LDA) [Izenman 2013]. A análise de Componentes Principais é um método estat´ıstico muito usado para reduzir o número de atributos de um conjunto de dados. O

procedimento usa uma transforma¸c˜ao ortogonal para converter atributos possivelmente correlacionados em um conjunto de atributos linearmente n˜ao correlacionados. Estes

´

ultimos são chamados de componentes principais. Os atributos que possuem pouca variância entre todos os dados não tem muita utilidade, por isso o PCA busca por

(24)

atributos que possuam grande variância entre um conjunto de atributos. Novos atributos são criados através da combina¸cão dos atributos já existentes.

Assim como o PCA, o LDA também é uma transforma¸cão linear usada para redu¸cão de dimensionalidade. No entando, o LDA é supervisionado e por isso procura a maximizar

a variˆancia que melhor separa as classes.

2.3 Pr´

e-Processamento

Durante o ciclo de vida de uma requisi¸cão diversos comentários são feitos. Quando o usuário reporta um erro, ou sugere uma melhoria, é através daquele primeiro comentário

que as pessoas envolvidas no projeto vão tentar interpretar, entender e julgar, a partir das informa¸cões conhecidas, se o reporte do usuário é valido ou não. De certa forma, são as informa¸cões contidas nos comentários que possuem a justificativa de uma determinada requisi¸cão ter sido aceita ou rejeitada. É provável que falhas nessa comunica¸cão gerem

falhas futuras no software. [Fitzgerald, Letier e Finkelstein 2012] adicionaram ao seu conjunto de treinamento alguns atributos relacionado aos coment´arios. Entendemos que

as informa¸cões contidas nos comentários são importantes e, quando adicionadas como atributos ao nosso conjunto de treinamento podem gerar resultados melhores. Entretanto, para que os textos dos comentários possam se tornar atributos do conjunto

de treinamento, é necessário realizar algumas técnicas de pré-processamento de texto. Essas técnicas envolvem a limpeza dos dados, para que apenas as palavras relevantes

sejam consideradas e a convers˜ao dos dados para atributos, usando alguma t´enica espec´ıfica, por exemplo Bag of Words [Nahm e Mooney 2002]. A seguir, especificamos

as t´ecnicas usadas nesse trabalho. • Tratamento de marca¸c˜ao de HTMLs

Tags de marca¸cão HTML/XML e caracteres especiais não são relevantes para os algoritmos de aprendizado de máquina, por isso é importante realizar uma limpeza para remo¸cão desses itens irrelevantes antes de realizar o processamento.

• Tokeniza¸cão: A tokeniza¸cão é o primeiro estágio do pré-processamento de um texto. Nele, o texto representado por uma seqüência de caracteres é agrupado em um pri-meiro n´ıvel segundo fronteiras delimitadas por caracteres primitivos como espa¸co (“

(25)

14 ”), v´ırgula, ponto etc. Cada grupo de caracteres estabelecido no primeiro n´ıvel é chamado de token. A seqüência desses grupos, por sua vez, é chamada de tokens-tream. Tanto os grupos de caracteres, como os delimitadores se tornam tokens na nova seqüência, o único caractere descartado é o espa¸co em branco. [Aranha 2007] Exemplo: O jogador, que está de camisa verde, marcou o gol da vitória.

Tokens: [O] [jogador] [,] [que] [est´a] [de] [camisa] [verde] [,] [marcou] [o] [gol] [da] [vit´oria] [.]

• Remo¸cão de Stopwords: Consiste em eliminar palavras que não devem ser conside-radas no texto, chamadas de stopwords, pois elas não apresentam relevância para o processo de classifica¸cão. Normalmente, as stopwords são artigos, pronomes e outras classes de palavras auxiliares.

• Lematiza¸cão: Esse processo consiste em uma normaliza¸cão lingu´ıstica para reduzir as palavras de um texto para uma forma mais simples, removendo prefixos e sufixos e transformando conjuga¸cões verbais para infinitivo. Por exemplo, as palavras gato, gata, gatos, gatas são todas formas do mesmo lema: gato.

• Sinonimia: sinônimos são palavras bastante diferentes que contêm o mesmo signi-ficado. Assim, uma técnica utilizada em pré-processamento de textos consiste em reduzir vários sinônimos para um único representante. Como existem diversos tra-balhos apontando a dificuldade de obter sinônimos exatos, com alguns linguistas até mesmo afirmando que estes não existem, pois nem sempre guardam o mesmo significado, optamos por não usar essa técnica no presente trabalho.

Para converter as palavras oriundas da limpeza de dados em atributos, usamos nesse trabalho a técnica de Bag of Words [Zhang, Jin e Zhou 2010]. Essa é uma técnica para

classifica¸cão de textos que considera senten¸cas e documentos como um conjunto das palavras que os formam. Assim, as palavras passam a ser o vetor de atributos e alguma medida associada a cada uma delas será o valor. Comumente, são utilizadas as seguintes

medidas de valora¸c˜ao das palavras:

• Booleano: essa medida usa uma representa¸cão binária como valor dos atributos. Quando a palavra está presente no documento, o valor do atributo é zero, e caso contrário é 1.

(26)

• Frequˆencia do termo: nesse caso o valor associado a uma palavra ser´a a quantidade de vezes que ela aparece em um exemplo.

• TF-IDF (term frequency-inverse document frequency): existem algumas palavras que são muito utilizadas em todos os textos e geralmente não têm tanta relevância

para a classifica¸cão de um documento. Assim, a medida TD-IDF [Baeza-Yates, Ribeiro-Neto et al. 1999] aumenta o valor de uma palavra proporcionalmente à frequência dessa palavra em

um documento, mas diminui o valor dela de acordo com a frequência em que essa palavra aparece em todos os textos, ou seja, a frequência do termo no exemplo é multiplicada por um fator de pondera¸cão. A equa¸cão ?? mostra como esse valor é computado tf idf (pi, ej) = tf (pi, ej) × idf (pi) (2.3) idf (pi) = log N #epi (2.4) onde pié uma palavra, ejum exemplo, tf(pi, ej) é a quantidade de vezes que a palavra

pi aparece no exemplo ej, N ´e a quantidade de exemplos e #epi ´e a quantidade de

exemplos em que a palavra pi aparece.

2.4 Trabalhos Relacionados

[Fitzgerald, Letier e Finkelstein 2012] propõem a constru¸cão de um modelo de previsão de falhas em requisi¸cões de software. Uma requisi¸cão de software pode ser um relato de

um erro ou uma solicita¸c˜ao de melhoria de software. O autor definiu cinco tipos de falhas comuns que acontecem no processo de desenvolvimento de software e criou um

extrator de dados em PHP para colher informa¸c˜oes das requisi¸c˜oes de software de grandes projetos (Apache, Eclipse, Firefox, KDE, Netbeans, Thunderbird, e Wikimedia)

que utilizam o sistema de gerenciamento de requisi¸cões Bugzilla. A partir dos dados extra´ıdos é feita uma classifica¸cão das requisi¸cões que possuem falhas de software, baseadas nas cinco tipos de falhas diferentes sugeridas pelo autor. A idéia é criar um modelo de previsão de falhas em requisi¸cões a partir da análise de dados históricos de requisi¸cões antigas. Esse modelo aprende com os dados antigos e quando recebe novos

(27)

16 dados de uma requisi¸c˜ao poderia informar a probabilidade de um certo tipo de falha ocorrer baseado no seu aprendizado. Abaixo seguem as descri¸c˜oes dos tipos de falhas

identificadas pelo autor:

• Reported product failure: Quando uma requisi¸cão foi aceita como válida, foi de-senvolvida, integrada, mas após algum tempo existe pelo menos um bug report confirmado associado àquela requisi¸cão.

• Abandoned Implementation: Quando uma feature request foi aceita como válida, associada a um desenvolvedor, um peda¸co do código foi enviado à requisi¸cão, mas o desenvolvimento daquela feature foi abandonada antes da feature ser integrada ao produto, o que significa que tempo e dinheiro foram desperdi¸cados analisando e desenvolvendo uma feature que foi abandonada.

• Rejection Reversal: Quando uma feature request é rejeitada, mas algum tempo depois ela é aceita. Essa feature não deveria ter sido rejeitada. Nesse caso, o tempo desde que a feature foi rejeitada e depois foi aceita é perdido. Esse tempo perdido poss´ıvelmente poderia ter sido usado para desenvolver aquela feature, integrado mais rapidamente ao produto e o cliente estaria satisfeito mais rapidamente.

• Stalled development: Quando uma requisi¸cão é aceita, mas fica muito tempo sem nenhuma mudan¸ca de status. O tempo em questão é parametrizável. Esse tempo de estagna¸cão é um tempo perdido em que a feature poderia já estar integrada no software ou marcada como uma feature que não será implementada (WONTFIX). • Removed Feature: Quando uma requisi¸cão é aceita, desenvolvida, integrada ao

pro-duto, mas após algum tempo essa feature é removida. Foi gasto tempo e dinheiro em discussões, especifica¸cões e desenvolvimento de uma feature que não precisava ter sido desenvolvida.

Um ponto a ser observado é que para que as falhas sejam identificadas o mais fielmente poss´ıvel à realidade, é necessário que os usuários dos sistemas de gerenciamento de requisi¸cão de software possuam uma cultura de atualizar os sistemas constantemente. Quanto mais atualiza¸cões corretas e constantes forem feitas nos posts de um projeto,

(28)

Existem outros trabalhos com foco na predi¸cão de falhas de software usando Aprendizado de Máquina. [Fenton e Neil 1999] fazem uma análise sobre a predi¸cão de

falhas de software. Eles analisam várias abordagens para detectar se o software irá falhar em tempo de execu¸cão. Isso poderia complementar nosso trabalho adicionando

deteçcão de falhas de tempo de execu¸cão e nos daria uma outra perspectiva sobre porque uma falha pode ocorrer. A abordagem deles também nos daria um motivo para

uma requisi¸cão não ser resolvida quando uma futura falha é detectada. O artigo ”An Analytical Approach to Architecture-Based Software Reliability Prediction” [Gokhale et al. 1998] aborda o mesmo problema. Ele tenta ver no futuro se

um componente irá falhar. A abordagem do autor apresenta uma contribui¸cão interessante para predi¸cão de falhas em tempo de execu¸cão. Isso significa que o tempo gasto naquele componente pode ser usado para sinalizar quando ele falhou. Ele também

explora outras caracteristicas das falhas que seriam úteis observar, como a cobertura de testes no código. Isso significa que não há componentes suficientes testados no software. Se um componente tem uma baixa cobertura de testes, ele tem mais chance de ter uma

falha em tempo de execu¸c˜ao.

Por ´ultimo, [Procaccino et al. 2002]tentam encontrar o que leva um desenvolvimento de software a falhar. No artigo, eles formulam quais features ou situa¸c˜oes que influenciam

no sucesso, desde o envolvimento de clientes à defini¸cão do escopo, eles tentam medir sua influência na falha do software. Isso poderia ser usado como uma feature extra no

(29)

Cap´ıtulo 3

Predi¸

c˜

ao de Falhas em Projetos de

Software com Atributos Estruturais

e de Linguagem Natural

Nesse capitulo serão introduzidos os detalhes referentes à implementa¸cão do arcabou¸co desenvolvido para a predi¸cão de falhas de projeto associadas a requisi¸cões de software. Em linhas gerais, são necessários três processos principais: (1) a coleta dos meta-dados

presentes em uma requisi¸cão com falha, a partir do servi¸co de gerenciamento de requisi¸cões; (2) a conversão e tratamento dos dados brutos para uma base de dados processável por uma ferramenta de aprendizado de máquina, bem como a defini¸cão da classe de falha; e (3) o processo de treinamento e valida¸cão dos modelos, gerados a partir das bases de dados. Nesse cap´ıtulo, apresentamos a ferramenta desenvolvida, come¸cando

pela vis˜ao geral dos processos utilizados na mesma, e seguindo para uma explica¸c˜ao detalhada de cada componente.

3.1 Vis˜

ao Geral

A Figura 3.1 ilustra em alto n´ıvel os componentes implementados e utilizados no sistema, bem como a comunica¸c˜ao existente entre eles.

Os dados de requisi¸c˜oes de software s˜ao obtidos do Bugzilla1 _{em formato XML/JSON}

por um programa chamado Extrator. Esses dados s˜ao analisados e um conjunto com

1

https://bugzilla.org/

(30)

(31)

20 informa¸cões a respeito das requisi¸cões que apresentaram algum tipo de falha é gerado.

Esse conjunto passa por uma limpeza de informa¸cões, de forma a extrair os atributos que foram identicados como relevante em [Fitzgerald, Letier e Finkelstein 2012], bem como o tratamento dos atributos de linguagem natural. Então, esse dataset pode ou não

passar por um processo de redu¸cão de dimensionalidade. Por fim o dataset é divido em folds, onde uma parte do conjunto é utilizada para treinamento e a outra parte é

utilizada para valida¸c˜ao.

3.2 Extra¸

c˜

ao de Dados

A extra¸cão dos dados das requisi¸cões de software é feita por um extrator desenvolvido na linguagem Java. Esse programa extrator faz uma consulta em uma API [Bugzilla REST API] passando parâmetros espec´ıficos para cada tipo de falha. O resultado dessa consulta são as requisi¸cões candidatas a possuirem uma falha. Essas requisi¸cões foram denominadas de candidatas pois nesse momento ainda não é poss´ıvel garantir que há uma falha. Para cada requisi¸cão candidata é feita uma análise no campo

histórico e algumas regras são aplicadas para garantir que a requisi¸cão analisada possui uma falha.

A Figura 3.2 ilustra a p´agina principal de uma requisi¸c˜ao de software referente ao projeto Mozilla Firefox.

Para todos tipos de falhas são utilizados os seguintes parâmetros: • Data inicial, referente à data de cria¸cão do bug.

• Data Final, referente `a data de cria¸c˜ao do bug. • Produto, referente ao nome do software.

Os demais parˆametros variam de acordo com o tipo de falha que se deseja buscar, conforme a descri¸c˜ao abaixo:

• Parˆametros para Abandoned Implementation: campo status com valor RESOLVED. campo resolution com valor WONTFIX.

(32)

Figura 3.2: Requisi¸c˜ao 171702 - Mozilla Firefox. • Parˆametros para Product Failure:

campo status com valor RESOLVED. campo resolution com valor FIXED. campo depends on n˜ao vazio.

• Parˆametros Rejection Reversal:

campo status com valor VERIFIED. campo resolution com valor FIXED. • Parˆametros Removed Feature:

campo status com valor RESOLVED. campo resolution com valor WONTFIX. • Parˆametros Stalled Development:

campo status com valor ASSIGNED.

O retorno dessa consulta é um XML com uma lista dos IDs das requisi¸cões que satisfazem os critérios informados. Para cada ID dessa lista, é feito uma nova requisi¸cão

(33)

22 As regras a seguir são verificadas para garantir que uma requisi¸cão possui uma falha. É

importante ressaltar que a ordem das regras ´e importante, ou seja, para que um determinado tipo de falha ocorra, os eventos abaixo devem ocorrer na ordem descrita.

• Abandoned Implementation

O campo status possuiu o valor ASSIGNED em algum momento. Houve uma mudan¸ca no campo resolution para WONTFIX. Exemplo: [Abandoned Implementation Failure Example]. • Product Failure

O campo resolution possuiu o valor FIXED em algum momento. O campo depends on foi adicionado.

Exemplo: [Product Failure Example]. • Rejection Reversal

O campo resolution possuiu o valor WONFIX em algum momento. O campo resolution mudou para FIXED.

O campo status mudou de RESOLVED para VERIFIED. Exemplo: [Rejection Reversal Failure Example].

• Removed Feature

O campo resolution possuiu o valor FIXED em algum momento. O campo status mudou de RESOLVED para REOPENED. O campo resolution mudou para WONTFIX.

Exemplo: [Removed Feature Failure Example]. • Stalled Development

O campo status possuiu o valor ASSIGNED em algum momento.

O campo status n˜ao foi alterado por um periodo maior ou igual a 365 dias. Exemplo: [Stalled Development Failure Example].

(34)

As Figuras 3.3 e 3.4 ilustram o hist´orico da requisi¸c˜ao 171702 do projeto Mozilla Firefox. Perceba que em 30-09-2002 o campo resolution teve seu valor alterado para WONTFIX.

Depois, em 20-10-2002 o campo resolution teve seu valor alterado para FIXED e em 17-07-2003 o campo status teve seu valor alterado para VERIFIED. De acordo com

nossas regras estabelecidas, essa sequˆencia de a¸c˜oes caracteriza a falha Rejection Reversal.

Figura 3.3: Hist´orico (parte 1) Requisi¸c˜ao 171702 - Mozilla Firefox.

(35)

24

3.3 Sele¸

c˜

ao de Atributos

Uma vez confirmado que uma requisi¸cão possui um tipo de falha, é feita uma nova requisi¸cão na API [Bugzilla REST API], solicitando todas as informa¸cões da requisi¸cão,

inclusive os comentários. A partir de todas essas informa¸cões, são constru´ıdos os atributos descritos abaixo, que chamamos de estruturais, para distinguir dos atributos

de linguagem:

• bugId: n´umero que identifica uma requisi¸c˜ao de software.

• feature1: número de participantes na discussão (a quantidade de usuários, desen-volvedores ou gerentes que fizeram algum comentário).

• feature2: número total de envolvidos (a quantidade de elementos no conjunto união dos participantes na discussão e dos integrantes da CC − list).

• feature3: número de participantes (a quantidade de elementos no conjunto união dos participantes na discussão e de quem recebeu a atribui¸cão de desenvolver o software (campo assigned − to da CC − list)).

• feature4 n´umero de posts feitos pela pessoa que iniciou a requisi¸c˜ao da melhoria ou reparo.

• feature5: porcentagem de posts feitos pela pessoa que iniciou a requisi¸c˜ao da me-lhoria ou reparo.

• feature6: número de posts feitos pela pessoa que recebeu a atribui¸cão de desenvolver a requisi¸cão.

• feature7: porcentagem de posts feitos pela pessoa que recebeu a atribui¸c˜ao de de-senvolver a requisi¸c˜ao.

• feature8: número total de posts (comentários). • feature9: média de palavras em cada post.

• feature10: n´umero total de palavras em toda a discuss˜ao.

(36)

• feature12: média do tempo decorrido entre os comentários. • feature13: maior tempo decorrido entre os comenários.

• feature14: tempo total decorrido do in´ıcio ao fim da discuss˜ao. ´

E poss´ıvel notar o campo CC − list na imagem 3.2.

3.3.1 Tratamento dos Atributos de Linguagem Natural

A figura 3.5 ilustra alguns coment´arios realizados na requisi¸c˜ao 171702 do projeto Mozilla Firefox.

Figura 3.5: Coment´arios da Requisi¸c˜ao 171702 - Mozilla Firefox.

Todos os comentários de uma requisi¸cão passam por um tratamento para que seja poss´ıvel que palavras se tornem atributos do dataset. Esse processo de limpeza é feito por um script escrito na linguagem Python que inicialmente remove caracteres especiais

e marca¸cões de HTML. A seguir, são executados os processos de tokeniza¸cão, lematiza¸cão e remo¸cão de stop words, usando a ferramenta escrita em Python Natural

Language Toolkit (NLTK) [Bird 2006]. Por último, para que seja poss´ıvel usar a abordagem de Bag of Words, é executada a vetoriza¸cão de palavras usando a classe CountV ectorizer presente na biblioteca Scikit-Learn [Pedregosa et al. 2011]. Ao final,

(37)

26 s˜ao criados novos atributos contendo a frequˆencia de cada palavra considerada como

relevante pelo passo anterior.

Abaixo são descritos os passos de pré-processamento de texto em alto n´ıvel: • remover marca¸cões HTML

• remover carateres especiais • lematizar palavras

• remover stop words

• criar atributos bag of words

3.4 Indu¸

c˜

ao do Classificador

Redu¸cão de Dimensionalidade Como as palavras dos comentários das requisi¸cões de software são transformados em atributos, é poss´ıvel que o conjunto de treinamento fique com um número muito alto de atributos. Assim, antes da indu¸cão do classificador

propriamente dito, foram utilizadas as duas técnicas de redu¸cão de dimensionalidade abaixo, com o objetivo de selecionar os atributos mais importantes para o treinamento e descartar os menos importantes. Ambos os métodos foram executados a partir do kit de ferramentas de aprendizado de máquina chamado SciKit- Learn [Pedregosa et al. 2011]. • Principal component analysis (PCA), presente no módulo decomposition do

SciKit-Learn.

• Linear discriminant analysis (LDA), presente no m´odulo discriminant analysis do SciKit-Learn.

Finalmente, os classificadores podem ser gerados a partir do conjunto de dados reduzido pelo PCA ou LDA, ou ainda sem o processo de redu¸c˜ao, usando o conjunto original.

Para a execu¸cão do classificador, é utilizado o método de valida¸cão cruzada estratificada [Kohavi et al. 1995], que mantém a propor¸cão de exemplos de cada classe nos folds. A separa¸cão dos conjuntos é feita antecipadamente à indu¸cão do classificador,

de forma a comparar corretamente os mesmos conjuntos de valida¸cão. Para tanto, são utilizados métodos da classe StratifiedKFold, presente no pacote model selection,

(38)

Classificadores Finalmente, os modelos podem ser induzidos usando algoritmos de aprendizado supervisionados. É importante ressaltar que o algoritmo de classifica¸cão deve conseguir lidar com múltiplas classes (e não apenas uma classe binária), pois temos 5 poss´ıveis falhas como rótulo. Os algoritmos cujos resultados serão exibidos no próximo

cap´ıtulo e suas respectivas implementa¸c˜oes no Sci kit Learn s˜ao: • Support Vector Machines, presente no pacote sklearn.

• Random Forest, presente no pacote sklearn.ensemble. • Naive Bayes, presente no pacote sklearn.naive bayes.

• Logistic Regression, presente no pacote sklearn.linear mode.

As implementa¸cões dos algoritmos de classifica¸cão também foram utilizadas a partir do Kit de ferramentas Scikit-Learn. É importante salientar que a escolha dos algoritmos se

deu pelas seguintes raz˜oes: (1) o estudo anterior [Fitzgerald, Letier e Finkelstein 2012] apresentou os melhores resultados com o algoritmo Logistic Regression, considerando,

além dele, um algoritmo que aprende uma árvore de decisão, outro que aprende uma tabela de decisão e o Naive Bayes. Os dois últimos casos apresentaram os piores resultados. Assim, consideramos o algoritmo que se comportou melhor no estudo anterior, mas também o que se comportou pior, pois gostar´ıamos de ver seus resultados com um método de redu¸cão de dimensionalidade. É importante ressaltar que o método de Bag-of-Words tem uma tendência a gerar tabelas muito esparsas, pois muitas palavras aparecerão apenas poucas vezes em alguns exemplos, o que pode prejudicar os resultados do algoritmo. Dessa forma, ao usar o método PCA, que combina atributos com pouca variância, é poss´ıvel que a esparsidade seja diminu´ıda e os resultados fiquem melhores. Além do Naive Bayes e do Logistic Regression, selecionamos o algoritmo indutor de

SVMs, visto que esta é uma das técnicas que apresenta melhores resultados em problemas de classifica¸cão, e o Random Forest, por ser um método que combina várias classificadores (árvores de decisão), na tentativa de produzir um resultado final melhor.

(39)

Cap´ıtulo 4

Resultados Experimentais

Nesse cap´ıtulo é apresentada uma prova de conceito sobre a aplica¸cão desenvolvida. Na se¸cão 4.1 serão mostrados os parâmetros escolhidos e amostras obtidas. Na se¸cão 4.2 serão mostradas as técnicas de Aprendizado de Máquina que foram aplicadas e na se¸cão

4.3 ser˜ao mostrados os resultados obtidos.

4.1 Base de Dados

O sistema de requisi¸cão utilizado para fazer a coleta foi o Bugzilla. Como queremos verificar o desempenho da predi¸cão em requisi¸cões futuras, coletamos os dados até a data da rejei¸cão, no caso da falha de Rejection Reversal e até a data em que o software foi associado para desenvolvimento, no caso das demais falhas. Os dados de requisi¸cões de software foram obtidos do projeto Mozilla Firefox1_{. A motiva¸c˜}_{ao para escolha desse}

projeto é o alto número de requisi¸cões de software dispon´ıveis. Os seguintes critérios de filtro foram utilizados para a busca dos dados:

• Produto: Firefox

• Data inicial: 01/01/2001 • Data final: 31/12/2016

As regras citadas na se¸cão 3.2 para determinar se uma requisi¸cão possui uma falha foram aplicadas ao resultado da consulta e abaixo é apresentada uma rela¸cão entre os

tipos de falha e a quantidade de falhas obtidas:

1_{https://bugzilla.mozilla.org/}

(40)

• Abandoned Implemenation (216) • Product Failure (1430)

• Rejection Reversal (50) • Removed Feature (16) • Stalled Development (153)

Para cada categoria de falha foi gerado um arquivo com todos os atributos mostrados na se¸cão 3.3. A partir desse arquivo com todos atributos é feita a limpeza dos comentários

para que sejam gerados os atributos referentes às palavras, conforme explicado na subse¸cão 3.3.1. Assim, são criados os atributos referentes a cada palavra, onde o valor

desses atributos é a frequência dessa palavra no texto (bag of words). Esses novos atributos são adicionados no arquivo. Por fim, o arquivo ficou com 1865 linhas

(exemplos) e 5016 colunas (atributos).

4.2 Metodologia Experimental

Foram executadas diversas combina¸cões de algoritmos com objetivo de analisar quais desempenhariam um melhor resultado. Nessa Se¸cão são descritas quais foram as técnicas e algoritmos utilizados. A técnica de valida¸cão cruzada foi utilizada em todas

execu¸cões, com fold de tamanho 5, na tentativa de obter uma amostra não muito reduzida da classe minoritária em cada conjunto de valida¸cão. Abaixo seguem as

descri¸c˜oes dos nomes dados aos experimentos de combina¸c˜oes dos algoritmos: • LR = Logistic Regression

• SVM = C-Support Vector Classification, com parˆametro (kernel=’rbf’) • SVMS = C-Support Vector Classification, com parˆametro (kernel=’sigmoid’) • NAIVE = Gaussian Naive Bayes

• RF = Random Forest, com 10 ´arvores.

• LDA X = Latent Dirichlet Allocation, onde X é o número de tópicos utilizado como parâmetro.

(41)

30 • PCA = Principal component analysis

4.3 Resultados

As tabelas 4.1, 4.2, 4.3, 4.4 e 4.5 apresentam os resultados obtidos em cada t´ecnica utilizada. Observa-se que o dataset utilizado foi o mesmo para todas abordagens, mas

h´a uma diferen¸ca da quantidade de atributos devido a redu¸c˜ao de dimensionalidade. Para comparar os resultados, usamos as seguintes medidas, considerando cada tipo de

falha:

• True Positive, que indica a quantidade de exemplos em que o modelo acertou a falha espec´ıfica.

• False Positive, que representa a quantidade de exemplos em que o modelo indicou que havia uma falha espec´ıfica, mas n˜ao havia.

• False Negative, que representa a quantidade de exemplos em que o modelo n˜ao indicou que havia uma falha espec´ıfica, mas havia.

• Precision, que é é definido pela equa¸cão 4.1 T rueP ositive

T rueP ositive + F alseP ositive (4.1) • Recall ´e definido pela equa¸c˜ao 4.2

T rueP ositive

T rueP ositive + F alseN egatives (4.2) • Score (F-measure) é definido pela equa¸cão 4.3 que é a média, considerando os valores de cada classe. Foi utilizada a classe f1 score presente no pacote sklearn.metrics. da biblioteca Scikit-Learn.

2 × P recision × Recall

(42)

4.4 Resultados Obtidos

O gráfico 4.1 mostra a rela¸cão entre os algoritmos executados e os scores obtidos, considerando ou não o método de redu¸cão de dimensionalidade. De modo geral, o algoritmo que apresentou o melhor desempenho foi o Random Forest, pois obteve resultados de score acima de 70% para todos os casos. De fato, esse algoritmo é reportado na literatura como um dos melhores classificadores atualmente, por combinar

v´arios classificadores em um.

Podemos perceber que a combina¸cão do algoritmo Logistic Regression com os métodos de redu¸cão de dimensionalidade pioraram seu desempenho. Esse não foi o caso do algoritmo Naive Bayes especificamente com o PCA, que foi o melhor resultado de score obtido dentre todos. Com isso, podemos verificar o que foi apontado na se¸cão anterior, ou seja, que o Naive Bayes, considerando um método de redu¸cão de dimensionalidade, pode obter resultados melhores. Em contrapartida, o Naive Bayes LDA1000 obteve o

pior desempenho de todos. Por outro lado, o uso do PCA com o Random Forest aumentou ligeiramente o desempenho desse classificador, enquanto os métodos de redu¸cão de dimensionalidade não fizeram diferen¸ca para o SVM, considerando ambas as

fun¸cões de kernel avaliadas, conforme ilustrado no gráfico 4.1. O gráfico 4.1 ilustra os resutlados obtidos cada classificador.

As Tabelas 4.1, 4.2, 4.3, 4.4 mostram os valores exatos de F-Measure obtidos para cada algoritmo, considerando o uso ou n˜ao da redu¸c˜ao de dimensionalidade.

Tabela 4.1: Logistic Regression. Algoritmo Score Atributos LR 0.7118741249 5016 LR LDA 10 0.6655410705 10 LR LDA 100 0.6655410705 100 LR LDA 1000 0.6655410705 1000 LR LDA 2500 0.6655410705 2500 LR PCA 0.4653787013 1865

As Tabelas 4.6, 4.7, 4.8 e 4.9 mostram as matrizes de confus˜ao media e mediana dos algoritmos que apresentaram o melhor e pior score respectivamente.

(43)

32

Figura 4.1: Resultados Tabela 4.2: Naive Bayes.

Algoritmo Score Atributos NAIVE 0.6056121937 5016 NAIVE LDA 10 0.2252752526 10 NAIVE LDA 100 0.1611353361 100 NAIVE LDA 1000 0.0590723223 1000 NAIVE LDA 2500 0.112579222 2500 NAIVE PCA 0.8297727133 1865

As tabelas 4.10 e 4.11 exibem as matrizes de confus˜ao do Random Forest LDA 1000. As classes das matrizes de confus˜ao seguem a seguinte legenda:

• classe1: Abandoned Implementation • classe2: Product Failure

• classe3: Rejection Reversal • classe4: Removed Feature

(44)

Tabela 4.3: Random Forest.

Algoritmo Score Atributos RF 0.7211616791 5016 RF LDA 10 0.7307122836 10 RF LDA 100 0.7132594853 100 RF LDA 1000 0.7419300619 1000 RF LDA 2500 0.7288338979 2500 RF PCA 0.7604083831 1865 Tabela 4.4: SVM.

Algoritmo Score Atributos SVM 0.6655410705 5016 SVM LDA 10 0.6655410705 10 SVM LDA 100 0.6655410705 100 SVM LDA 1000 0.6655410705 1000 SVM LDA 2500 0.6655410705 2500 SVM PCA 0.6655410705 1865 Tabela 4.5: SVMS

Algoritmo Score Atributos SVMS 0.6655410705 5016 SVMS LDA 10 0.6655410705 10 SVMS LDA 100 0.6655410705 100 SVMS LDA 1000 0.6655410705 1000 SVMS LDA 2500 0.6655410705 2500 SVMS PCA 0.6655410705 1865 • classe5: Stalled Development

Podemos ver que boa parte dos erros cometidos foram de classificar outras classes como a classe 2. Isso era de se esperar, visto que essa ´e a classe majorit´aria. De todo modo, podemos ver que o melhor resultado acerta mais as classes do que erra para a maioria

(45)

34 Tabela 4.6: Matriz Confus˜ao (M´edia) Naive Bayes PCA

classe1 classe2 classe3 classe4 classe5 classe1 42.20 1.00 0.00 0.00 0.00 classe2 36.00 231.00 14.00 0.00 5.00 classe3 0.00 0.60 8.60 0.00 0.80 classe4 0.00 0.20 2.20 0.40 0.40 classe5 0.00 0.60 10.00 0.80 19.20 Tabela 4.7: Matriz Confus˜ao (Mediana) Naive Bayes PCA

classe1 classe2 classe3 classe4 classe5 classe1 42.00 1.00 0.00 0.00 0.00 classe2 0.00 282.00 0.00 0.00 2.00 classe3 0.00 0.00 9.00 0.00 0.00 classe4 0.00 0.00 3.00 0.00 0.00 classe5 0.00 0.00 8.00 0.00 23.00 Tabela 4.8: Matriz Confus˜ao (M´edia) Naive Bayes LDA 1000

classe1 classe2 classe3 classe4 classe5 classe1 12.20 0.20 30.00 0.40 0.40 classe2 77.00 8.60 186.60 2.00 11.80 classe3 2.40 0.20 7.40 0.00 0.00 classe4 0.60 0.20 2.40 0.00 0.00 classe5 9.60 0.40 19.20 0.40 1.00

Tabela 4.9: Matriz Confus˜ao (Mediana) Naive Bayes LDA 1000 classe1 classe2 classe3 classe4 classe5 classe1 0.00 0.00 40.00 0.00 0.00 classe2 5.00 7.00 256.00 0.00 13.00 classe3 0.00 0.00 9.00 0.00 0.00 classe4 0.00 0.00 3.00 0.00 0.00 classe5 0.00 0.00 26.00 0.00 1.00

(46)

Tabela 4.10: Matriz Confusão (Média) RF LDA 1000 classe1 classe2 classe3 classe4 classe5 classe1 27.80 15.00 0.00 0.00 0.40 classe2 22.80 246.80 3.20 0.40 12.80 classe3 0.00 6.60 2.40 0.00 1.00 classe4 0.00 2.40 0.40 0.00 0.40 classe5 0.20 25.00 1.00 0.00 4.40 Tabela 4.11: Matriz Confusão (Mediana) RF LDA 1000

classe1 classe2 classe3 classe4 classe5 classe1 26.00 17.00 0.00 0.00 0.00 classe2 2.00 272.00 1.00 0.00 6.00 classe3 0.00 6.00 2.00 0.00 1.00 classe4 0.00 2.00 0.00 0.00 0.00 classe5 0.00 25.00 1.00 0.00 5.00

(47)

Cap´ıtulo 5

Conclus˜

ao

Esse trabalho tinha por objetivo a constru¸cão de uma ferramenta de previsão de falhas em projetos de software, a partir de solicita¸cões de melhorias ou reparos relatadas em

Sistemas de Gerenciamentos de Requisi¸cões online. Para obter um modelo preditivo, foram utilizadas técnicas de Aprendizado de Máquina. Como metodologia, primeiramente, foram coletadas informa¸cões de diversas requisi¸cões existentes e depois foram aplicadas algumas regras para obtermos aquelas requisi¸cões que possuiam algum dos tipos de falhas, definidas em um estudo anterior. A partir do conjunto de dados das

requisi¸cões de software com falhas, foram criados atributos estruturais e atributos de palavras, coletadas a partir da discussão realizada pelos usuários, desenvolvedores e gerenciadores da requisi¸cão. Para que as palavras pudessem ser vistas como atributos na base de dados, foram aplicadas técnicas de pré-processamento de texto, com o intuito de

dimunir a quantidade de palavras relevantes, e o m´etodo de Bag of Words, para que valores pudessem ser atribu´ıdos a tais palavras.

Geralmente, o conjunto de atributos gerados pelo método de Bag-of-words é demasiadamente grande e esparso. Assim, os testes também utilizaram dois métodos de

redu¸cão de dimensionalidade a partir do conjunto de atributos original. Com a técnica de valida¸cão cruzada, separamos uma parte do conjunto de dados para o treinamento e

constru¸cão do modelo, enquanto outra parte foi separada para teste e avalia¸cão do mesmo. Após a aplica¸cão de diversas técnicas e algoritmos variados de classifica¸cão foi

feita uma an´alise entre os resultados obtidos.

Os dados utilizados nesse trabalho s˜ao referentes ao projeto Mozilla Firefox. Podemos constatar que o melhor resultado obtido foi aplicando o Naive Bayes com o m´etodo PCA

(48)

de redu¸cão de dimensionalidade, cuja medida F ficou em 0,82. O método Random Forest com PCA também obteve um score bom, de 0.76. Outro ponto de observa¸cão é que a redu¸cão de dimensionalidade não impactou o SVM, pois obtivemos o mesmo score com e

sem a aplica¸cão da redu¸cão de dimensionalidade. O Logistic Regression funcionou melhor sem redu¸cão de dimensionalidade, chegando a um score de 0.71. O pior desempenho encontrado foi o LDA com 1000 tópicos + Naive Bayes, com score de 0.05.

Esse trabalho analisou somente dados do Projeto Mozilla Firefox. Como trabalhos futuros, poderiam ser analisados dados de outros projetos. Al´em disso, seria interessante

identificar quais os atributos que se mostraram mais relevantes para os melhores resultados obtidos, na tentativa de explicar o motivo da falha.

Nesse trabalho foram utilizados as técnicas PCA e LDA com objetivo de reduzir a esparsidade nas tabelas geradas pelo Bag-of-Words, em um trabalho futuro outras técnicas de redu¸cão de dimensionalidade e sele¸cão de atributos poderiam ser aplicadas. Outra poss´ıvel extensão é incluir não apenas os casos de falha, como também os casos de

sucesso, para que o modelo de predi¸cão possa classificar também requisi¸cões que não apresentarão falhas. Nesse caso, um modelo

hier´arquico [Cesa-Bianchi, Gentile e Zaniboni 2006] pode ser aplicado, de forma que primeiro seja classificada a falha ou sucesso e em seguida o tipo da falha. Outra

possibilidade é incluir atributos obtidos de um método de análise de

sentimentos [Liu e Zhang 2012], de forma que sentimentos positivos e negativos possam também ser usados para indicar qual o caminho que os comentários estão apontando.

Finalmente, como os relacionamentos entre os usuários e desenvolvedores e seus comentários e entre as próprias requisi¸cões também podem ser bons indicativos de

poss´ıveis falhas, gostar´ıamos de aplicar t´ecnicas de Aprendizado

Relacional [Raedt 2008, Getoor 2007] para que atributos desse tipo sejam levados em considera¸c˜ao.

(49)

Referˆ

encias Bibliogr´

aficas

[Abandoned Implementation Failure Example]ABANDONED Implementation Failure Example. [Online; accessed December 28, 2016]. Dispon´ıvel em: <https : //bz.apache.org/bugzilla/showactivity.cgi?id = 34868>.

[Abu-Mostafa, Magdon-Ismail e Lin 2012]ABU-MOSTAFA, Y. S.; MAGDON-ISMAIL, M.; LIN, H.-T. Learning from data. [S.l.]: AMLBook Singapore, 2012. v. 4.

[Alpaydin 2009]ALPAYDIN, E. Introduction to Machine Learning. second. [S.l.]: The MIT Press, 2009.

[Aranha 2007]ARANHA, C. N. Uma abordagem de pré-processamento automático para minera¸cão de textos em português: Sob o enfoque da inteligência computacional. 2007. [Baeza-Yates, Ribeiro-Neto et al. 1999]BAEZA-YATES, R.; RIBEIRO-NETO, B. et al.

Modern information retrieval. [S.l.]: ACM press New York, 1999. v. 463.

[Bird et al. 2008]BIRD, C. et al. Latent social structure in open source projects. In: Proce-edings of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2008, Atlanta, Georgia, USA, November 9-14, 2008. [S.l.]: ACM, 2008. p. 24–35. ISBN 978-1-59593-995-1.

[Bird 2006]BIRD, S. Nltk: the natural language toolkit. In: ASSOCIATION FOR COM-PUTATIONAL LINGUISTICS. Proceedings of the COLING/ACL on Interactive pre-sentation sessions. [S.l.], 2006. p. 69–72.

[Breiman 2001]BREIMAN, L. Random forests. Machine learning, Springer, v. 45, n. 1, p. 5–32, 2001.

[Bugzilla Lifecycle]BUGZILLA Lifecycle. [Online; accessed July 9, 2016]. Dispon´ıvel em: <https://www.bugzilla.org/docs/2.18/html/lifecycle.html>.

(50)

[Bugzilla REST API]BUGZILLA REST API. [Online; accessed December 28, 2016]. Dis-pon´ıvel em: <https : //wiki.mozilla.org/Bugzilla : RESTAP I>.

[Cesa-Bianchi, Gentile e Zaniboni 2006]CESA-BIANCHI, N.; GENTILE, C.; ZANI-BONI, L. Incremental algorithms for hierarchical classification. Journal of Machine Le-arning Research, v. 7, n. Jan, p. 31–54, 2006.

[Cleland-Huang et al. 2009]CLELAND-HUANG, J. et al. Automated support for mana-ging feature requests in open forums. Communications of the ACM, ACM, v. 52, n. 10, p. 68–74, 2009.

[Cortes e Vapnik 1995]CORTES, C.; VAPNIK, V. Support-vector networks. Machine le-arning, Springer, v. 20, n. 3, p. 273–297, 1995.

[Fenton e Neil 1999]FENTON, N. E.; NEIL, M. A critique of software defect prediction models. Software Engineering, IEEE Transactions on, IEEE, v. 25, n. 5, p. 675–689, 1999.

[Fitzgerald, Letier e Finkelstein 2012]FITZGERALD, C.; LETIER, E.; FINKELSTEIN, A. Early failure prediction in feature request management systems: an ex-tended study. Requir. Eng., v. 17, n. 2, p. 117–132, 2012. Dispon´ıvel em: <http://dx.doi.org/10.1007/s00766-012-0150-7>.

[Getoor 2007]GETOOR, L. Introduction to statistical relational learning. [S.l.]: MIT press, 2007.

[Gokhale et al. 1998]GOKHALE, S. S. et al. An analytical approach to architecture-based software reliability prediction. In: IEEE. Computer Performance and Dependability Sym-posium, 1998. IPDS’98. Proceedings. IEEE International. [S.l.], 1998. p. 13–22.

[Hosmer 2000]HOSMER, S. L. D. W. Applied Logistic Regression. [S.l.: s.n.], 2000. [Izenman 2013]IZENMAN, A. J. Linear discriminant analysis. In: Modern Multivariate

Statistical Techniques. [S.l.]: Springer, 2013. p. 237–280.

[Jolliffe 2002]JOLLIFFE, I. Principal component analysis. [S.l.]: Wiley Online Library, 2002.

(51)

40 [Kohavi et al. 1995]KOHAVI, R. et al. A study of cross-validation and bootstrap for accu-racy estimation and model selection. In: Ijcai. [S.l.: s.n.], 1995. v. 14, n. 2, p. 1137–1145. [Liu e Zhang 2012]LIU, B.; ZHANG, L. A survey of opinion mining and sentiment

analy-sis. In: Mining text data. [S.l.]: Springer, 2012. p. 415–463.

[Mitchell 1997]MITCHELL, T. Machine Learning. New York: McGraw-Hill, 1997.

[Nahm e Mooney 2002]NAHM, U. Y.; MOONEY, R. J. Text mining with information extraction. In: AAAI 2002 Spring Symposium on Mining Answers from Texts and Kno-wledge Bases. [S.l.: s.n.], 2002. v. 1.

[Pedregosa et al. 2011]PEDREGOSA, F. et al. Scikit-learn: Machine learning in python. Journal of Machine Learning Research, v. 12, n. Oct, p. 2825–2830, 2011.

[Procaccino et al. 2002]PROCACCINO, J. D. et al. Case study: factors for early pre-diction of software development success. Information and software technology, Elsevier, v. 44, n. 1, p. 53–62, 2002.

[Product Failure Example]PRODUCT Failure Example. [Online; accessed December 28, 2016]. Dispon´ıvel em: <https : //bugzilla.mozilla.org/showactivity.cgi?id = 451995>.

[Raedt 2008]RAEDT, L. D. Logical and relational learning. [S.l.]: Springer Science & Business Media, 2008.

[Rejection Reversal Failure Example]REJECTION Reversal Failure Exam-ple. [Online; accessed December 28, 2016]. Dispon´ıvel em: <https : //bugzilla.mozilla.org/showactivity.cgi?id = 171702>.

[Removed Feature Failure Example]REMOVED Feature Failure Exam-ple. [Online; accessed December 28, 2016]. Dispon´ıvel em: <https : //netbeans.org/bugzilla/showactivity.cgi?id = 171465>.

[Roweis e Saul 2000]ROWEIS, S. T.; SAUL, L. K. Nonlinear dimensionality reduction by locally linear embedding. Science, American Association for the Advancement of Science, v. 290, n. 5500, p. 2323–2326, 2000.

[Scholkopf e Smola 2001]SCHOLKOPF, B.; SMOLA, A. J. Learning with kernels: support vector machines, regularization, optimization, and beyond. [S.l.]: MIT press, 2001.

(52)

[Stalled Development Failure Example]STALLED Development Failure Exam-ple. [Online; accessed December 28, 2016]. Dispon´ıvel em: <https : //bugzilla.mozilla.org/showactivity.cgi?id = 1130284>.

[Zhang, Jin e Zhou 2010]ZHANG, Y.; JIN, R.; ZHOU, Z.-H. Understanding bag-of-words model: a statistical framework. International Journal of Machine Learning and Cyber-netics, Springer, v. 1, n. 1-4, p. 43–52, 2010.