THIAGO DO NASCIMENTO FERREIRA ABORDAGENS INTERATIVAS USANDO ALGORITMO DE OTIMIZAÇÃO POR COLÔNIA DE FORMIGA PARA O PROBLEMA DO PRÓXIMO RELEASE

Transcrição

1 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 THIAGO DO NASCIMENTO FERREIRA ABORDAGENS INTERATIVAS USANDO ALGORITMO DE OTIMIZAÇÃO POR COLÔNIA DE FORMIGA PARA O PROBLEMA DO PRÓXIMO RELEASE FORTALEZA CEARÁ 2015

2 THIAGO DO NASCIMENTO FERREIRA ABORDAGENS INTERATIVAS USANDO ALGORITMO DE OTIMIZAÇÃO POR COLÔNIA DE FORMIGA PARA O PROBLEMA DO PRÓXIMO RELEASE Dissertação apresentada ao Curso de Mestrado Acadêmico em Ciência da Computação do Programa de Pós-Graduação em Ciência da Computação do Centro de Ciências e Tecnologia da Universidade Estadual do Ceará, como requisito parcial à obtenção do título de mestre em Ciência da Computação. Área de Concentração: Ciência da Computação Orientador: Prof. Dr. Jerffeson Teixeira de Souza FORTALEZA CEARÁ 2015

3 Dados Internacionais de Catalogação na Publicação Universidade Estadual do Ceará Sistema de Bibliotecas Ferreira, Thiago do Nascimento Ferreira. Abordagens Interativas usando Algoritmo de Otimização por Colônia de Formiga para o Problema do Próximo Release [recurso eletrônico] / Thiago do Nascimento Ferreira Ferreira CD-ROM: il.; 4 ¾ pol. CD-ROM contendo o arquivo no formato PDF do trabalho acadêmico com 102 folhas, acondicionado em caixa de DVD Slim (19 x 14 cm x 7 mm). Dissertação (mestrado acadêmico) Universidade Estadual do Ceará, Centro de Ciências e Tecnologia, Mestrado Acadêmico em Ciência da Computação, Fortaleza, Área de concentração: Ciência da Computação. Orientação: Prof. Dr. Jerffeson Teixeira de Souza. 1. Problema do Próximo Release. 2. Otimização Interativa. 3. Otimização por Colônia de Formiga. I. Título.

4

5 Dedico este trabalho aos meus pais, Bernardo Filho e Cleide Nascimento, pela constante fonte de inspiração e dedicação e a minha noiva, Rebeca Almeida, por todo amor, carinho e compreensão.

6 AGRADECIMENTOS À Deus por todas as graças alcançadas e pelos momentos de sabedoria e esclarecimento quando tudo parecia duvidoso e sem sentido; Aos meus pais pela força e dedicação ao longo dessa caminhada e por fornecerem as condições para que eu me dedicasse ao mestrado. Obrigado por sempre acreditarem em mim e por estarem sempre ao meu lado. Simplesmente, obrigado por existirem; À minha irmã Thais e os demais familiares por fazerem parte da minha vida e pelos momentos de descontração que tornaram essa caminhada um pouco mais amena; À minha noiva, Rebeca, que ao longo desses sete anos esteve ao meu lado me apoiando e me incentivando, principalmente nesta reta final, tendo sempre muita paciência, compreensão, carinho e amizade. Obrigado pelas cobranças e pelo sacrifício de momentos que poderíamos estar juntos para que eu continuasse e concluísse mais uma etapa de nossas vidas; Meu especial agradecimento ao Professor Dr. Jerffeson Teixeira de Souza por me orientar no tempo que estive presente no laboratório e neste estudo, sempre com muita paciência, motivação, confiança e apoio; Ao professor Dr. Gustavo Augusto Lima de Campos pelas ótimas ideias trocadas no exame de qualificação que serviram para ampliar os horizontes dessa pesquisa; Aos professores Dr. Paulo Henrique Mendes Maia e Dra. Silvia Regina Vergilio por aceitarem o convite de participação na minha banca avaliadora, contribuindo e enriquecendo esta pesquisa; Aos colegas do Grupo de Otimização em Engenharia de Software (GOES) pelo companheirismo, amizade e convivência que renderam momentos muito divertidos. Obrigado pela rica troca de ideias nos almoços e jantares no Restaurante Universitário; Ao Allysson Allex, pelas inúmeras discussões, brincadeiras, conversas e trocas de experiências principalmente na reta final do mestrado. Agradeço também ao Altino Dantas, pela ajuda no experimento e coleta dos resultados desta pesquisa; Ao Matheus Paixão, pelas discussões polêmicas dentro do laboratório com o intuito de abrir nossas mentes para novos horizontes, além de ser um grande exemplo de sucesso e superação dentro do GOES; Aos meus amigos que cujos os nomes não vou mencionar devido ao tamanho da lista. Obrigado a todos pelos momentos de descontração; À TODOS que deram sua contribuição direta ou indiretamente para que mais esta etapa de minha formação pudesse se concretizar.

7 I am lost! Where is the line?! (A Bug s Life, Walt Disney, 1998)

8 RESUMO Escolher quais são os requisitos que serão selecionados para o próximo release é um tarefa complexa devido ao orçamento limitado disponível e ao envolvimento de vários fatores que muitas vezes são conflitantes entre si. Dentro deste contexto, surge a área de Engenharia de Software Baseada em Busca (Search Based Software Engineering - SBSE) com o objetivo de aplicar métodos automáticos de busca na resolução de problemas complexos da área de Engenharia de Software. Entretanto, muitas das abordagens utilizadas em SBSE não consideram, durante o processo de busca, os aspectos subjetivos humanos devido à dificuldade de modelar de forma objetiva (ou matematicamente) as preferências do usuário. Esta limitação pode ocasionar uma certa insegurança por parte dos engenheiros de software e gerentes de projeto na hora de aceitar as soluções geradas por estes métodos, tendo em vista que o seu conhecimento teórico e de domínio não foi devidamente incorporado na solução final. Sabendo disso, este trabalho estudou possíveis formas de incorporar a subjetividade humana dentro do algoritmo de Otimização por Colônia de Formiga (Ant Colony Optimization - ACO), propondo características de interação que algoritmos dessa natureza devem possuir. Além do mais, esse trabalho propõe algumas abordagens interativas dando a possibilidade do usuário final escolher aquela abordagem que mais se adapta a sua realidade. Por fim, dentre as abordagens interativas propostas, uma foi selecionada e avaliada através de um estudo empírico realizado em duas instâncias baseadas em softwares reais e uma artificial com a participação de seres humanos e simuladores. Os resultados desses experimentos mostram que a perda de score da solução gerada pela abordagem interativa usando ACO é relativamente pequena quando comparada com a alta quantidade de preferências do usuário que foram atendidas pelo algoritmo. Além disso, os resultados apontam que a escolha do ACO como algoritmo interativo gerou baixa quantidade de interações com o usuário principalmente devido a sua capacidade de gerar boas soluções com poucas iterações. Palavras-chave: Problema do Próximo Release. Otimização Interativa. Otimização por Colônia de Formiga.

9 ABSTRACT Choosing which requirements will be selected for the next software release is a complex task due to limited budget and the presence of several factors, which are often conflicting with one another. In this context, the Search Based Software Engineering (SBSE) field arises, aiming at applying automatic search methods to solve complex Software Engineering problems. However, most of the approaches applied in SBSE do not consider human subjective aspects during the search process, due to the difficulty in objectively (or mathematically) modeling the user s preferences. This limitation may cause some unwillingness on software engineers and project managers to accept the solutions generated by these methods, given that their theoretical and domain knowledge were not properly incorporated in the final solution. With that in mind, this work studied possible ways of incorporating human subjectivity within the Ant Colony Optimization algorithm (ACO), proposing interaction features which algorithms of this nature must poses. Moreover, this work proposes some interactive approaches giving the possibility of the end user to choose the approach that best suits his/her context. Finally, among the proposed interactive approaches, one was selected and evaluated through an empirical study over two based on real software and one artificial instances with the participation of human subjects and simulators. The results of these experiments show that the score lost of the solutions generated by the ACO-based interactive approach is relatively small compared with the high amount of user preferences that were satisfied by the algorithm. In addition, results indicate that the choice of ACO as interactive algorithm generated a low amount of user interactions mainly due to its ability to generate good solutions with few iterations. Keywords: Next Release Problem. Interactive Optimization. Ant Colony Optimization

10 LISTA DE ILUSTRAÇÕES Figura 1 Conjunto de soluções factíveis e grau de dominância em um problema de minimização com dois objetivos Figura 2 Dominância de Pareto em Problemas de Otimização com Minimização de dois objetivos Figura 3 Número de Publicações em SBSE entre 1976 e Figura 4 Proporção de áreas de pesquisas em SBSE entre 1976 e Figura 5 Processo de Entrega Incremental Figura 6 Experimento da Ponte Binária Figura 7 Exemplo de construção de uma solução por uma formiga no algoritmo ACO. 31 Figura 8 Exemplo de uma iteração para formiga k Figura 9 Resumo de sistemas que utilizam Otimização Interativa Figura 10 Sistema de Interação com o Usuário para Avaliação do Projeto de Software. 42 Figura 11 TSPAntSim - Sistema Interativo usando ACO para o TSP Figura 12 Momento da Interação À Priori Figura 13 Momento da Interação In-the-loop Figura 14 Momento da Interação À Posteriori Figura 15 Valores de Parâmetros como Informação Requerida Figura 16 Seleção de Requisitos como Informação Requerida Figura 17 Divisão em Categorias como Informação Requerida Figura 18 Avaliação do Release como Informação Requerida Figura 19 Interface de Usuário desenvolvida para o Estudo Empírico Figura 20 Resultados da Validação Automática para a métrica pre f erenciasatendidas 82 Figura 21 Resultados da Validação Automática para a métrica f atordereducao Figura 22 Resultados da Validação Automática na variação do peso da função score (γ) e da função pre f (δ)

11 LISTA DE TABELAS Tabela 1 Semelhanças e diferenças entre as formigas reais e o algoritmo ACO Tabela 2 Principais variações do Algoritmo ACO Tabela 3 Síntese das Abordagens Interativas Tabela 4 Síntese das Vantagens e Desvantagens das Abordagens Interativas propostas 73 Tabela 5 Configurações do Algoritmo iaco no Estudo Empírico Tabela 6 Resultados da Validação Manual para a métrica pre f erenciasatendidas para o dataset Tabela 7 Resultados da Validação Manual para a métrica pre f erenciasatendidas para o dataset Tabela 8 Resultados da Validação Manual para a métrica f atordereducao Tabela 9 Perfil dos Participantes do Estudo Empírico Tabela 10 Resultados da função pre f erenciaatendidas para o dataset Tabela 11 Resultados da função f atordereducao para o dataset Tabela 12 Resultados da função pre f erenciaatendidas para o dataset Tabela 13 Resultados da função f atordereducao para o dataset Tabela 14 Resultados da função pre f erenciaatendidas para o rand Tabela 15 Resultados da função f atordereducao para o rand

12 LISTA DE ALGORITMOS 1 Algoritmo de Otimização por Colônia de Formiga Algoritmo ACO Interativo por Configuração de Parâmetro Algoritmo ACO Interativo por Preferência no Release Algoritmo ACO Interativo por Comparação Par-a-Par Algoritmo ACO Interativo por Classificação de Requisitos Algoritmo ACO Interativo por Avaliação Preditiva do Release Algoritmo ACO Interativo por Avaliação do Release Algoritmo ACO Interativo por Substituição de Requisitos

13 LISTA DE ABREVIATURAS E SIGLAS ACO ACS AS EA ES GA GRASP GUI HC IACO IEC IGA JSSP MoCELL NRP NSGAII SA SBSE TSP Ant Colony Optimization. Ant Colony System. Ant System. Evolutionary Algorithm. Engenharia de Software. Genetic Algorithm. Greedy Randomized Adaptive Search Procedure. Graphical User Interface. Hill Climbing. Interactive Ant Colony Optimization. Interactive Evolutionary Computation. Interactive Genetic Algorithm. Job Shop Scheduling Problem. Multiobjective Cellular. Next Release Problem. Non-dominated Sorting Genetic Algorithm. Simulated Annealing. Search Based Software Engineering. Travelling Salesman Problem.

14 SUMÁRIO 1 INTRODUÇÃO MOTIVAÇÃO OBJETIVO GERAL OBJETIVOS ESPECÍFICOS ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA PROBLEMAS DE OTIMIZAÇÃO SEARCH-BASED SOFTWARE ENGINEERING PROBLEMA DO PRÓXIMO RELEASE OTIMIZAÇÃO POR COLÔNIA DE FORMIGA OTIMIZAÇÃO POR COLÔNIA DE FORMIGA APLICADO AO NRP OTIMIZAÇÃO INTERATIVA CONSIDERAÇÕES FINAIS TRABALHOS RELACIONADOS TÉCNICAS DE BUSCA APLICADAS AO PROBLEMA DO PRÓXIMO RELEASE ALGORITMOS INTERATIVOS EM SBSE CONSIDERAÇÕES FINAIS ABORDAGENS INTERATIVAS COM ACO CARACTERÍSTICAS DA INTERAÇÃO Momento da Interação Tipo de Informação Requerida do Usuário Forma de Incorporação da Informação Quantidade de Interações Critério de Parada ABORDAGENS INTERATIVAS Interação por Configuração de Parâmetros Interação por Preferência no Release Interação por Comparação Par-a-Par Interação por Classificação de Requisitos

15 4.2.5 Interação por Avaliação Preditiva do Release Interação por Avaliação do Release Interação por Substituição de Requisitos CONSIDERAÇÕES FINAIS ESTUDO EMPÍRICO QUESTÕES DE PESQUISAS MÉTRICAS CONFIGURAÇÕES EXPERIMENTAIS RESULTADOS E DISCUSSÕES AMEAÇAS À VALIDADE CONSIDERAÇÕES FINAIS CONCLUSÕES E TRABALHOS FUTUROS CONTRIBUIÇÕES DO TRABALHO LIMITAÇÕES TRABALHOS FUTUROS REFERÊNCIAS APÊNDICES APÊNDICE A Perfil dos Participantes no Estudo Empírico APÊNDICE B Resultados da RQ

16 15 1 INTRODUÇÃO A Engenharia de Software é a área da computação que se ocupa de todos os aspectos da produção de um software, desde as fases iniciais (quando ocorre a especificação do sistema) até a manutenção, quando o software entra em produção (SOMMERVILLE, 2010). Por se tratar de todos os aspectos da produção de um software, a área possui diversos problemas que são considerados complexos, ou seja, podem apresentar um elevado número de possíveis soluções para resolvê-los. Dentre esses problemas, é possível citar a dificuldade de selecionar os requisitos que deverão ser liberados no próximo release (entrega), o problema da alocação de tarefas, a seleção de casos e geração de dados de testes dentre outros. Devido a essa complexidade, métodos automáticos de resolução de problemas estão sendo empregados como forma de auxiliar engenheiros de software e gerentes de projeto a tomar decisões apoiado nas soluções geradas por tais métodos. Nessa situação, surge a Engenharia de Software Baseada em Busca (Search Based Software Engineering - SBSE) que tem como objetivo utilizar técnicas de busca para otimizar a construção de soluções para os problemas da área da Engenharia de Software (HARMAN; JONES, 2001). Essas técnicas são normalmente algoritmos metaheurísticos utilizados devido à sua capacidade de gerar boas soluções rapidamente e ao mesmo tempo, serem aplicáveis a diversos outros problemas. A ideia principal de SBSE consiste basicamente em modelar matematicamente os problemas como problemas de Otimização Combinatória para que, em seguida, algoritmos de busca sejam aplicados. Na literatura é possível encontrar diversas metaheurísticas como, por exemplo, Têmpera Simulada (Simulated Annealing - SA) (KIRKPATRICK; GELATT; VECCHI, 1983), Algoritmo Genético (Genetic Algorithm - GA) (HOLLAND, 1975), NSGAII (Non-dominated Sorting Genetic Algorithm) (DEB et al., 2002), MoCELL (Multiobjective Cellular) (NEBRO et al., 2009) e Otimização por Colônia de Formiga (Ant Colony Optimization - ACO) (DORIGO; BIRATTARI; STUTZLE, 2006), que foram aplicadas e obtiveram sucesso gerando boas soluções na área de SBSE. Segundo Linhares et al. (2010), os primeiros artigos que utilizaram essas técnicas de otimização para resolver os problemas da Engenharia de Software foram escritos no início da década de 1970 mas somente em 2001 o termo Search-Based Software Engineering foi criado por Harman e Jones (2001). O crescimento da área estabeleceu-se nos últimos dez anos com diversos artigos publicados na área de seleção de casos de testes (MAIA et al., 2009; YOO; HARMAN, 2007), alocação em projetos (ANTONIOL; PENTA; HARMAN, 2004), manutenção

17 16 de software (PENTA, 2012), gerência de projetos (PENTA et al., 2007), planejamento de releases (SOUZA et al., 2011; COLARES et al., 2009), manutenção e engenharia reversa (HARMAN; HIERONS; PROCTOR, 2002) dentre outros. Outro problema bastante conhecido da área de SBSE é o problema definido inicialmente por Bagnall, Rayward-Smith e Whittley (2001) chamado Problema do Próximo Release (Next Release Problem - NRP) que tem como objetivo selecionar um conjunto de requisitos que farão parte do próximo release de forma que maximize a satisfação dos clientes e cuja seleção não ultrapasse o limite máximo do orçamento disponível definido para o release. Na literatura é possível encontrar várias técnicas de resolução do Problema do Próximo Release. Dentre elas, é possível citar o trabalho de Sagrado, Aguila e Orellana (2010), onde os autores fazem um estudo comparativo com a aplicação das metaheurísticas Têmpera Simulada, Algoritmo Genético e Otimização por Colônia de Formiga no problema. Mais recentemente, os autores Mausa et al. (2013) aplicam a técnica da Subida da Encosta (Hill Climbing) na versão do problema NRP em larga escala, ou seja, quando a instância do problema possui alta quantidade de requisitos (acima de 500 requisitos). Desde a sua criação, o ACO tem sido aplicado a vários problemas de otimização, apresentando resultados promissores principalmente pela sua capacidade de gerar boas soluções com pouca quantidade de iterações. O algoritmo foi desenvolvido por Dorigo (1992) e tem como inspiração biológica o comportamento das colônias de formigas, baseando-se principalmente na busca da formiga por alimentos. Verificou-se que as formigas, à medida que se movimentavam, liberavam um composto químico chamado feromônio. Quando uma fonte de comida fosse encontrada, a formiga voltava para o ninho deixando no caminho uma quantidade de feromônio proporcional à quantidade de comida encontrada. A esse processo dá-se o nome de Estigmergia. Ele se baseia em um sistema de realimentação positiva e negativa, ou seja, torna os melhores caminhos mais atraentes para outras formigas e permite que piores caminhos sejam esquecidos com o tempo (PERRETTO, 2005). As técnicas automatizadas de busca superam em qualidade e viabilidade outras técnicas já utilizadas para resolver os diversos problemas da Engenharia de Software (COLARES et al., 2009; LI; CHAUDRON; LADAN, 2010; WALCOTT et al., 2006). Além disso, o trabalho desenvolvido por Souza et al. (2010) mostra que as respostas dadas por humanos são superadas por técnicas automatizadas em alguns problemas da Engenharia de Software, comprovando assim a competitividade dessas ferramentas com as soluções geradas pelos humanos diante dos

18 17 problemas. Apesar dessas técnicas mostrarem melhor desempenho em relação às técnicas manuais, muitas vezes as soluções geradas não incorporam as preferências ou avaliações subjetivas do usuário, ou seja, ignoram, por exemplo, as experiências e opiniões de um engenheiro de software ou gerente de projetos na busca por uma solução. Essa limitação pode ocasionar uma certa insegurança por parte dos usuários de aceitar as soluções geradas por tais métodos, tendo em vista que o seu conhecimento teórico e de domínio não foi devidamente incorporado na solução final. É nesse contexto que a interatividade humana torna-se importante com o uso de técnicas que permitem o usuário interagir com o processo de busca explicitando as suas preferências e, com isso, fazer com que os algoritmos encontrem soluções que, ao mesmo tempo, sejam boas e que consideram as preferências do usuário. Na literatura existem diversos trabalhos que utilizam técnicas interativas em algoritmos de busca como, por exemplo, no problema de remodularização de software (BAVOTA et al., 2012) e no problema de seleção, priorização e alocação de caso de testes (MAIA, 2011). 1.1 MOTIVAÇÃO A Engenharia de Requisitos é aceita como sendo uma das etapas mais importantes no processo de desenvolvimento de software, principalmente porque ela trabalha com o ponto mais crítico no problema de projetar um software para o cliente: os requisitos. Além de ser reconhecida como sendo a base da funcionalidade do sistema, ela é determinantemente crítica na qualidade do software. Alguns estudos empíricos mostram que os erros nos requisitos são os mais numerosos, os mais caros e os que consomem mais tempo para corrigir (AURUM; WOHLIN, 2005). Muitas vezes, a qualidade de um software é medida de acordo com a capacidade que ele tem de atender às demandas vindas tanto do cliente quanto do usuário. Por isso, as empresas têm como grande desafio a identificação e principalmente, o entendimento das regras de negócio com o propósito de garantir que o software desenvolvido atenda todas as expectativas do cliente ou usuário e com isso, diminuir, por exemplo, o custo do retrabalho (BERANDER; ANDREWS, 2005). Neste âmbito, existe atualmente uma forte tendência de dividir o software em pequenas partes compostas por um conjunto básico de funcionalidades previamente definidas,

19 18 visando atender às expectativas do cliente e, com isso, diminuir os riscos do projeto. Essas pequenas partes recebem o nome de releases e possuem como grande vantagem o rápido feedback que os clientes e demais stakeholders (pessoas envolvidos de forma direta ou indireta com o sistema) podem emitir a cerca de tudo o que foi desenvolvido, uma vez que começam a utilizar o software mais cedo. Diante disso, uma vez definido e especificado cada requisito do sistema, técnicas automatizadas interativas estão sendo utilizadas como forma de selecionar os requisitos que farão parte do próximo release. Essas técnicas, além de tornar o processo mais humanizado, permitem que engenheiros de software e gerentes de projeto expressem a sua opinião durante a busca e, com isso, consigam gerar soluções que, além de atender a necessidade do cliente, contenham avaliações subjetivas por parte dos envolvidos os quais os métodos não-interativos teriam dificuldade de perceber. Por fim, a otimização interativa surge também com o objetivo de incorporar aspectos subjetivos durante o processo de busca que são difíceis de ser modelados matematicamente. Um das técnicas mais utilizadas na busca interativa é uso de algoritmos evolucionários (Evolutionary Algorithm - EA) que possuem uma longa história de sucesso nesse tipo de busca. Ser o mais utilizado não é necessariamente uma boa motivação científica (SIMONS; SMITH; WHITE, 2014) e, sabendo disso, a performance de algoritmos evolucionários (EI- BEN; SMITH, 2003) e algoritmos de Otimização por Colônia de Formiga (DORIGO; CARO; GAMBARDELLA, 1999) foram comparados por Simons e Smith (2012) no problema de Projeto de Software, que tem como objeto encontrar o melhor design de classes que minimize o acoplamento entre classes, maximize a simetria entre atributos e métodos no design como um todo e maximize a simetria entre atributos e métodos entre classes individuais. Os resultados mostram que Algoritmos Evolucionários são superiores dado um orçamento computacional alto (em número de iterações) e mais robusto no problema de Projeto de Software contendo um alto número de classes. Entretanto, se o orçamento computacional é limitado, o algoritmo ACO encontra soluções com alta qualidade em menos iterações. Se o problema de Design de Software possui número alto de métodos e atributos, o ACO encontra soluções boas na metade do número de iterações disponíveis. Diante deste fato, as abordagens interativas descritas neste trabalho são implementadas usando o algoritmo ACO devido à sua capacidade de gerar boas soluções em menos iterações e, com isso, contornar um dos grandes problemas da área de otimização interativa que é o

20 19 problema da fadiga (ou cansaço) humano. A utilização de abordagens interativas com o algoritmo ACO utilizada neste trabalho não possui aplicações na literatura no Problema do Próximo do Release. Portanto, a abordagem interativa mostra-se bastante promissora principalmente pela contribuição que irá trazer para o meio científico com a aplicação de um novo algoritmo interativo em um problema bastante conhecido. Assim, diante do problema de decidir quais os requisitos serão selecionados para o próximo release, da capacidade do ACO de gerar boas soluções rapidamente e da incapacidade de modelar matematicamente todos os aspectos subjetivos durante o processo de busca, este trabalho tem como proposta caracterizar as formas de incorporar a subjetividade humana dentro do algoritmo de Otimização por Colônia de Formiga e do Problema do Próximo Release além de propor algumas abordagens interativas, fornecendo aos usuários a possibilidade de escolher qual abordagem se adapta mais à sua realidade. 1.2 OBJETIVO GERAL Caracterizar as formas de incorporação da subjetividade humana e desenvolver abordagens interativas usando o algoritmo ACO para o Problema do Próximo Release em que o usuário possa expressar as suas preferências durante o processo de busca. 1.3 OBJETIVOS ESPECÍFICOS Para alcançar o objetivo geral descrito na Seção 1.2, os seguintes objetivos específicos foram definidos: a) Identificar as características que um algoritmo interativo usando ACO deve possuir para incorporar as preferências do usuário; b) Elaborar abordagens interativas usando ACO para o Problema do Próximo Release que contenham diversas características de interação em sua implementação; c) Identificar as vantagens e desvantagens das abordagens propostas; d) Desenvolver e apresentar resultados de experimentos realizados em algumas instâncias pré-definidas para demonstrar a aplicabilidade e a viabilidade de uma das abordagens propostas; e) Comparar os resultados obtidos pelas abordagens com respostas de especialistas

21 20 da área. 1.4 ESTRUTURA DO TRABALHO Este trabalho está organizado em seis capítulos, incluindo a presente introdução, que são descritos a seguir. O Capítulo 2 apresenta a fundamentação teórica utilizada neste trabalho apresentando a definição de Problemas de Otimização e explicando detalhadamente os seus tipos. Em seguida, o capítulo mostra uma visão geral sobre a área de SBSE além de apresentar a modelagem matemática utilizada no NRP. Além disso, é apresentado o algoritmo ACO com sua inspiração biológica juntamente com a sua modelagem para o NRP. Por fim, a Otimização Interativa é apresentada mostrando os principais conceitos e problemas da área. O Capítulo 3 detalha os principais trabalhos relacionados a esta dissertação. Temas como métodos automatizados de resolução do NRP e Algoritmos Interativos em SBSE são descritos no capítulo destacando as suas principais contribuições para a literatura. O Capítulo 4 apresenta as características identificadas ao se incorporar a subjetividade humana dentro do ACO aplicado ao NRP, além de mostrar as abordagens interativas que foram geradas por essas características apresentando o algoritmo, as vantagens e desvantagens de cada abordagem. O Capítulo 5 apresenta os resultados encontrados no estudo empírico que foi realizado selecionando uma das abordagens propostas neste trabalho com o objetivo de demonstrar a aplicabilidade e a viabilidade desta proposta. Por fim, o Capítulo 6 apresenta as conclusões do trabalho, suas contribuições, limitações e relaciona possíveis trabalhos futuros.

22 21 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo é realizado um estudo mais aprofundado sobre cada conteúdo abordado nesta proposta. Inicialmente é apresentada a definição de Problemas de Otimização, descrevendo os seus tipos e sua modelagem. Em seguida é descrita a área de SBSE na qual este trabalho está inserido e a definição do Problema do Próximo Release. Por fim, são apresentados o algoritmo de Otimização por Colônia de Formiga e o conceito de Otimização Interativa. 2.1 PROBLEMAS DE OTIMIZAÇÃO Determinar os valores extremos de uma função, buscando encontrar o maior ou o menor valor que uma função pode assumir em um dado intervalo pode ser definido como Problema de Otimização (ANDRADE, 1998). Em seu trabalho, Deb (2008) define que um Problema de Otimização consiste em encontrar soluções viáveis (que não extrapolem as restrições) que correspondam a valores extremos em um ou mais objetivos (funções). Os problemas de otimização são muito comuns em nosso dia a dia e aparecem, por exemplo, quando procuramos determinar qual a melhor forma de cortar uma chapa de aço em uma fábrica de fazer geladeiras buscando minimizar a perda ou ainda encontrar a rota de distribuição de produtos que tenha a menor distância e que percorra várias cidades. O Problema de Otimização pode ser composto por uma ou mais funções com o objetivo de maximizar ou minimizar o valor da cada uma. A quantidade de funções define a qual categoria esses problemas pertencem. São elas: mono-objetivos e multi-objetivos. Os problemas mono-objetivos são problemas que possuem apenas uma função a ser otimizada. Já os problemas multi-objetivos, são problemas que possuem mais de uma função a ser otimizada. A definição formal de um problema de otimização mono-objetivo tem o seguinte formato: minimizar (ou maximizar) sujeito a f (x) g i (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 otimizar (minimizar ou maximizar), g(x) e h(x) são as funções

23 22 que representam as restrições do problema e Ω é o conjunto de todas as soluções disponíveis. A variável x representa uma solução do conjunto Ω e que para ser válida, deve respeitar todas as restrições do problema, ou seja, ela deve satisfazer as funções g(x) e h(x). Em seu trabalho, Hashimoto (2004) define o problema de otimização multi-objetivo como sendo: minimizar (ou maximizar) z = f 1 (x), f 2 (x), f 3 (x),..., f n (x) (2.2) sujeito a x X onde: X = Espaço de Decisões x = (x 1,x 2,...,x n ) X = Vetor de decisão Z = A imagem de X ou espaço objetivo z = (z 1,z 2,...,z n ) Z = Vetor Objetivo (2.3) X = {x X : g(x) b} = Conjunto de Soluções Factíveis g(x) = Restrições Em um Problema de Otimização multi-objetivo, em geral, não existe uma única solução que seja ótima para todos os objetivos. Isso acontece devido a natureza conflitante entre os objetivos do problema. É possível observar na Figura 1 o problema de minimizar as funções f 1 (x) e f 2 (x). A solução A oferece um valor para f 1 mas um valor maior para f 2 se comparado com a solução no ponto B, de modo que a diminuição de uma função objetivo implica no aumento da outra. Como uma solução pode ser melhor em um objetivo e pior em outro, surge então o conceito de Dominância de Pareto como critério de comparação entre soluções em problemas multi-objetivos. Em Dominância de Pareto, uma solução pode ser dominada e não-dominada por outra solução. quando: Em seu trabalho, Deb (2008) define que uma solução S 1 domina outra solução S 2 a) A solução S 1 não é pior que S 2 em todos os objetivos; b) A solução S 1 é melhor em pelo menos um dos objetivos

24 23 Figura 1 Conjunto de soluções factíveis e grau de dominância em um problema de minimização com dois objetivos. Fonte: Hashimoto (2004) Na Figura 2 é possível ver o conceito de Dominância de Pareto onde as soluções A e B dominam a solução C, as soluções E e F são dominadas pela solução C e as soluções D e G são indiferentes a C, ou seja, são soluções que são melhores que C em um dos objetivos e por isso não pode se afirmar que eles dominam ou são dominadas. Figura 2 Dominância de Pareto em Problemas de Otimização com Minimização de dois objetivos. Fonte: Adaptada de Maia (2011) O conjunto de todas as soluções não-dominadas fazem parte de conjunto chamado Frente de Pareto que representa todas as boas soluções para o problema. Portanto, os algoritmos

25 24 que resolvem problemas mono-objetivos retornam como saída uma única solução, enquanto os algoritmos que resolvem os problemas multi-objetivos retornam uma Frente de Pareto. 2.2 SEARCH-BASED SOFTWARE ENGINEERING A Engenharia de Software (ES) é o ramo da computação dedicada ao processo de desenvolvimento de software desde a fase de especificação do sistema até a sua manutenção (quando entra em produção) (SOMMERVILLE, 2010). Diante disso, engenheiros de software e gerentes de projeto enfrentam em seu cotidiano diversos problemas complexos, ou seja, problemas para os quais encontrar a solução ideal é teoricamente impossível ou intratável na prática (HARMAN et al., 2012). Ao longo do tempo foi observado que diversos desses problemas poderiam ser tratados como problema de otimização e, com isso, aplicar os mais variados métodos automáticos de busca para encontrar a solução e, assim, ajudar engenheiros e gerentes na resolução dos problemas. Dada essa possibilidade de utilização de algoritmos de busca em problemas da Engenharia de Software, surge então uma nova e promissora área chamada Engenharia de Software Baseada em Busca (Search Based Software Engineering - SBSE) que tem como principal característica a conversão dos problemas da ES em problemas de otimização, e a aplicação de metaheurísticas na tentativa de encontrar boas soluções para os problemas da área (HARMAN; JONES, 2001; COLANZI et al., 2013). Antes da área ser definida por Harman e Jones (2001), vários outros trabalhos já abordavam os problemas da Engenharia de Software aplicando técnicas de otimização como forma de resolução. Dentre eles, é possível citar o trabalho do Miller e Spooner (1976) que abordou a geração de dados de teste e o trabalho do Dolado (2000) que trabalhava com a predição de custo em software. Desde o seu surgimento em 2001, a área vem se consolidando com cada vez mais trabalhos publicados conforme pode ser observado na Figura 3. As técnicas de busca podem ser aplicadas a diversas áreas que compõem a Engenharia de Software como, por exemplo, Testes, Requisitos, Ferramentas e Técnicas de Codificação e Manutenção. Apesar de 50% dos trabalhos em SBSE serem trabalhos da área de teste de software (HARMAN; MANSOURI; ZHANG, 2009), outros problemas em Engenharia de Software são abordados com SBSE como, por exemplo, trabalhos na área de alocação em projetos (ANTONIOL; PENTA; HARMAN, 2004), gerência de projetos (PENTA et al., 2007),

26 25 Figura 3 Número de Publicações em SBSE entre 1976 e Fonte: Adaptada de Zhang, Harman e Mansouri (2011) manutenção de software (PENTA, 2012), planejamento de releases (SOUZA et al., 2011; COLARES et al., 2009), arquitetura da linha de produto de software (COLANZI, 2014) dentre outros. Mais detalhes sobre as disciplinas da Engenharia de Software, utilizando a classificação da ACM, que SBSE foi aplicada desde o ano de 1976 até 2014 podem ser observados na Figura 4. Figura 4 Proporção de áreas de pesquisas em SBSE entre 1976 e Fonte: Adaptada de Zhang, Harman e Mansouri (2011) Em seu trabalho, Harman e Jones (2001) definem que, para transformar um problema da engenheira de software em um problema de busca, é necessário definir: a) Uma representação do problema, ou a definição da estrutura de dados, que seja

27 26 possível fazer uma manipulação simbólica; b) Uma função de Fitness responsável por calcular o valor de uma solução gerada para o problema; c) Um conjunto de operadores para manipular as soluções geradas. Uma vez definida a representação do problema, a função de fitness e os operadores, basta aplicar as metaheurísticas e assim encontrar a solução do problema. Existem diversas metaheurísticas na literatura que são bastante utilizadas em SBSE como, por exemplo, Algoritmos Genéticos, Têmpera Simulada, Subida da Encosta (Hill Climbing - HC) e ACO (BURKE; KENDALL, 2006). Segundo Harman e Clark (2004), para que SBSE obtenha sucesso nos problemas os quais ela é aplicada, é necessário que o problema contenha algumas características importantes. São elas: a) Espaço de busca grande - Como o espaço de busca é grande, não é possível explorá-lo completamente (ou exaustivamente) em busca da melhor solução; b) Continuidade Aproximada - Muita descontinuidade pode enganar os algoritmos de busca pois todas as abordagens utilizam a função de fitness como método avaliativo. Quanto menos contínua a função de fitness, menos orientação ela fornece aos algoritmos; c) Ausência de Solução Ótima - A SBSE é normalmente aplicada quando, para um dado problema, não se tem conhecimento da melhor solução que o resolve. Quando não se consegue chegar na solução ótima, busca-se então a solução mais próxima da ótima; d) Baixa Complexidade Computacional - A busca pela melhor solução requer milhares de avaliações usando a função de fitness. Portanto, a complexidade para calcular o fitness de uma solução deve ser baixa pois ela pode se tornar crítica no processo de busca. Por fim, Harman, Mansouri e Zhang (2009) apresentam uma revisão detalha de todas as pesquisas realizadas em SBSE até então, incluindo as áreas de pesquisa, técnicas utilizadas e, principalmente, os resultados que foram alcançados. Além disso, os autores ainda apresentam os desafios para o futuro e os problemas da área que ainda estão em abertos sugerindo assim áreas onde a SBSE ainda pode ser aplicada.

28 PROBLEMA DO PRÓXIMO RELEASE Atualmente, existe uma forte tendência no mercado de se adotar metodologias que visem a atender rapidamente às necessidades do cliente, obtendo assim um rápido feedback sobre o que está sendo desenvolvido. Esse modelo, também chamado de Modelo Incremental, faz uso de pequenas entregas de funcionalidades chamadas de releases. Apesar de ter se tornado popular atualmente por conta das Metodologias Ágeis (MANIFESTO..., 2014), essa técnica de desenvolvimento já é utilizada desde a década de 1970 (LARMAN; BASILI, 2003). O Modelo Incremental é basicamente um processo onde a especificação, o projeto, a implementação e o teste são realizados em fases intercaladas. Assim, uma série de releases são definidas e a cada entrega, um incremento do software deverá ser disponibilizado. A Figura 5 ilustra como funciona um processo de entrega incremental. Nela é possível observar a fase inicial de especificação dos requisitos composto pelos estados 1, 2 e 3 e pela fase de iteração (ou ciclo) responsável por desenvolver o incremento do sistema e que está representado na figura pelos estados 4, 5, 6 e 7. Figura 5 Processo de Entrega Incremental. Fonte: Adaptada de Sommerville (2010) No entanto, definir quais são os requisitos que farão parte do próximo release é uma tarefa difícil, principalmente devido à possibilidade de existirem vários clientes envolvidos no projeto e do orçamento limitado do release. É neste contexto que surge o Problema do Próximo Release (Next Release Problem - NRP) que tem como objetivo selecionar os requisitos que farão parte do próximo release, sem extrapolar o orçamento máximo definido para ele. O trabalho do Bagnall, Rayward-Smith e Whittley (2001) surge na literatura como sendo um dos primeiros a aplicar algoritmos heurísticos no NRP. Nele, os autores aplicaram três instâncias do algoritmo Subida da Encosta, duas instâncias do algoritmo Têmpera Simulada e

29 28 algoritmo guloso em um conjunto de dados gerados aleatoriamente. Os resultados mostraram que a Têmpera Simulada encontrou as melhores soluções. Seja R = {r 1,r 2,...,r n } o conjunto de todos os requisitos que deverão ser implementados no sistema atual e C = {c 1,c 2,...,c m } o conjunto de clientes atendidos pelo sistema. Cada cliente m terá um peso w m Z + que mede a importância do cliente para a empresa. O cliente tem a possibilidade de definir a importância que cada requisito traz para ele. Seja V um conjunto de m x n valores que representa a importância que um cliente m fornece para cada requisito n. v 1,1 v 1,2 v 1,n v V = 2,1 v 2,2 v 2,n v m,1 v m,2 v m,n (2.4) Dada a importância do requisito j e o peso w de cada cliente, a satisfação de selecionar um requisito j é dada pelo somatório dos produtos dos pesos do cliente pela importância que cada um fornece ao requisito j. A satisfação de um requisito j é dada: s j = m i=0 w i v i j (2.5) Sabendo que R R é o conjunto de requisitos selecionados para o próximo release, o score do conjunto é dada pelo somatório da satisfação de todos os requisitos que foram selecionados, sendo representada por: score(r ) = j R s j (2.6) Cada requisito r j R é associado a um custo, e j Z +. Dessa forma, o custo do release selecionado é dado pelo somatório dos custos dos requisitos selecionados, representado pela função: custo(r ) = j R e j (2.7)

30 29 Por fim, sabendo que B é o orçamento máximo definido para o release, o Problema do Próximo Release consiste em: maximizar score(r ) sujeito a custo(r ) B (2.8) 2.4 OTIMIZAÇÃO POR COLÔNIA DE FORMIGA Geralmente, sociedades de insetos sociais, mas especificamente colônia de formigas, representam sistemas distribuídos que, apesar da simplicidade dos seus indivíduos, apresentam um nível de organização social altamente estruturado. Devido a essa organização, as colônias de formigas podem realizar tarefas complexas que, em alguns casos, excedem as capacidades individuais de uma única formiga (DORIGO; STÜTZLE, 2004). Diante disso, diversos algoritmos baseados em colônia de formigas foram desenvolvidos inspirados neste comportamento observados no mundo real. A ideia principal é que os princípios da auto-organização permitem o comportamento altamente coordenado entre as formigas reais. Esses princípios são explorados para coordenar as populações de agentes artificiais que colaboram para resolver problemas computacionais. A coordenação das atividades pelas formigas reais são realizadas através de um mecanismo chamado Estigmergia (do inglês stigmergy), termo introduzido por Grassé (1959) que define um mecanismo de coordenação indireta entre agentes ou ações. O princípio da estigmergia é que o traço deixado no ambiente por qualquer ação estimula o desempenho de outra ação, pelo mesmo agente, ou por agentes diferentes. No caso das formigas, este traço é deixado por uma substância química chamada Feromônio que, em alta concentração, aumenta a probabilidade de outras formigas seguirem o mesmo caminho. O funcionamento é simples: as formigas saem do ninho em busca do alimento seguindo direções aleatórias. Quando uma fonte de comida é encontrada, ela retorna ao ninho depositando feromônio no chão, gerando assim uma trilha entre o ninho e a fonte de comida. As outras formigas do ninho, ao sentir a substância no chão, tendem a seguir a mesma trilha de feromônio deixado pela formiga anterior e assim, também chegar a fonte de comida. Existem na literatura diversos trabalhos de pesquisadores que estudam este comportamento entre as formigas, mas um experimento realizado por Deneubourg et al. (1990) e Goss et al. (1989) chamado Experimento da Ponte Binária (ver Figura 6) mostrou que além de seguir

31 30 as trilhas de feromônio deixado no chão, as formigas percorriam a menor distância entre o ninho e a fonte de comida. Isso de fato acontecia devido a alta concentração de feromônio na trilha durante muito tempo e a evaporação de feromônio em trilhas onde as formigas gastavam bastante tempo para encontrar a fonte de comida (DORIGO; STÜTZLE, 2004). Figura 6 Experimento da Ponte Binária. Fonte: Deneubourg et al.; Goss et al. (1990, 1989) Diante deste contexto, Dorigo (1992) desenvolveu uma metaheurística baseada no comportamento das formigas chamada Otimização por Colônia de Formiga (do inglês, Ant Colony Optimization ou ACO). O algoritmo tenta reproduzir o comportamento das formigas no processo de busca da solução desde a escolha do caminho a ser seguido até o processo de atualização da trilha de feromônio. A Otimização por Colônia de Formiga possui algumas características semelhantes e diferentes com as formigas reais. Essas características podem ser vistas na Tabela 1. Tabela 1 Semelhanças e diferenças entre as formigas reais e o algoritmo ACO Características Semelhantes As formigas se movem de forma assíncrona e aleatória em busca das soluções Decisão estocástica sobre o caminho a ser percorrido, baseado na informação local Sequência de movimentos locais entre os estados do ambiente Evaporação do feromônio (utilizado para buscar novas soluções) Características Diferentes O mundo é discreto e as movimentações são transições entre os estados do ambiente A formiga possui um estado interno que representa a memória A atualização do feromônio é proporcional à qualidade da solução encontrada A formiga possui algumas capacidades extras como, por exemplo, previsão da qualidade de estados futuros e otimização local Fonte: Adaptada de Caro e Dorigo; Dorigo e Gambardella (1998, 1997a)

32 31 No ACO, o problema é representado como um grafo G = (V,A) onde as formigas percorrem construindo a solução, passando pelos vértices e pelas arestas depositando feromônio nas arestas. Na Figura 7 é possível ver a formiga construindo a sua solução percorrendo o grafo partindo inicialmente do vértice 5 e chegando até o vértice 1, obtendo como uma solução o caminho Figura 7 Exemplo de construção de uma solução por uma formiga no algoritmo ACO. Fonte: Elaborada pelo Autor O algoritmo ACO pode ser descrito como: Algoritmo 1: Algoritmo de Otimização por Colônia de Formiga início Atribua os valores dos parâmetros; Inicialize as trilhas de feromônios; enquanto não atingir o critério de parada faça para cada formiga faça Construa as Soluções; fim Aplique Busca Local (Opcional); Atualize o Feromônio; fim fim Desenvolvido por Dorigo, Maniezzo e Colorni (1996), o Ant System (AS) foi o primeiro algoritmo ACO implementado que foi aplicado no Problema do Caixeiro Viajante (Travelling Salesman Problem - TSP) (DORIGO; GAMBARDELLA, 1997a). Quando uma formiga k está no vértice i vai para o vértice j, ela utiliza a seguinte regra de proporção pseudoaleatória

33 32 definida como: p k i j = [τ i j ] α [η i j ] β h N k i [τ ih ] α [η ih ] β, se j N k i 0, caso contrário (2.9) onde: p k i j é a probabilidade que a formiga k tem de ir do vértice i para o vértice j; τ i j é quantidade de feromônio entre os vértices i e j; η i j é informação heurística entre os vértices i e j; α define a importância do feromônio na escolha do vértice; β define a importância da informação heurística na escolha do vértice; Ni k é o conjunto de vértices disponível para a formiga k no vértice i. Na Equação 2.9 é possível perceber que basta fazer β = 0 para que a formiga leve em consideração somente o feromônio depositado na aresta para escolher o próximo vértice. Entretanto, fazendo α = 0, a formiga irá levar em consideração somente a informação heurística entre os vértices. Ao final do processo de construção das soluções por cada formiga, a quantidade de feromônio de todas as arestas é atualizada com operações de evaporação e depósito onde: a) Evaporação - Evita que o feromônio acumulado cresça indefinidamente além de permitir esquecer decisões ruins do passado. b) Depósito - Guia as outras formigas na escolha das suas soluções definindo o quão bom é seguir por essa aresta. As operações de depósito e evaporação do feromônio são realizadas utilizando a seguinte fórmula de atualização: τ i j = (1 ρ) τ i j + ρ τ i j (2.10) onde ρ é a taxa de atualização do feromônio e τ i j representa a quantidade de feromônio que será depositado na aresta entre os vértices i e j. Esse valor vai depender do problema que está sendo aplicado. Dentre as inúmeras variações do ACO (ver a Tabela 2), uma das mais utilizadas, é a Ant Colony System (ACS) desenvolvido por Dorigo e Gambardella (1997b) tendo como

34 33 principais características a inserção de atualização local de feromônio, modificação na função de transição do vértice i para o vértice j, além de definir que o processo de atualização global será feito somente pela formiga que encontrou a melhor solução até o momento. Tabela 2 Principais variações do Algoritmo ACO Algoritmos ACO Principais Referências Ant System (AS) (DORIGO, 1992; DORIGO; MANIEZZO; COLORNI, 1996) Elitist AS (DORIGO, 1992; DORIGO; MANIEZZO; COLORNI, 1996) Ant-Q (DORIGO; GAMBARDELLA, 1996) Ant Colony System (DORIGO; GAMBARDELLA, 1997a; DORIGO; GAMBARDELLA, 1997b) MAX MIN AS (STÜTZLE, 1997) Rank-based AS (BULLNHEIMER; HARTL; STRAUSS, 1997) Fonte: Elaborada pelo autor. No algoritmo ACS, a função de transição entre os vértices i e j é definida como: j = argmax u N k{[τ iu ] [η iu ] β }, i se q q 0 (2.11) p k i j, caso contrário onde q é uma variável aleatória uniformemente distribuída entre [0,1] e q 0 determinará se a formiga fará prospecção (quando a formiga simplesmente escolhe o maior [τ iu ][n iu ] β ) ou exploração (quando ela faz a busca usando probabilidade de escolher um vértice, o que permite ela explorar outros lugares no espaço de busca). O processo de atualização local do feromônio é feito sempre que uma formiga sai do vértice i e vai para o vértice j e não somente no final como descrito no algoritmo AS. Essa atualização é feita seguindo a fórmula: τ i j = (1 µ) τ i j + µ τ 0 (2.12) onde µ é a taxa de decaimento localmente do feromônio e τ 0 representa a quantidade de feromônio depositado que vai depender do problema no qual está sendo aplicado o algoritmo. 2.5 OTIMIZAÇÃO POR COLÔNIA DE FORMIGA APLICADO AO NRP Ao se optar pela utilização do ACO para resolução do NRP, cada formiga encontra um conjunto de requisitos que farão parte do próximo release percorrendo um grafo direcionado totalmente conectado onde cada vértice representa um requisito.

35 34 Segundo Sagrado, Aguila e Orellana (2010), em uma iteração, cada formiga contrói uma solução R atravessando os vértices de um grafo somente uma vez. Quando uma formiga k está no vértice i, o próximo vértice j é selecionado estocasticamente dentro de um conjunto de vértices visíveis a partir de i chamado vis k (i) (ou vizinhança opcional). Um vértice j está disponível para uma formiga k se, e somente se, o vértice j ainda não foi visitado pela formiga e a inclusão do requisito j não ultrapassa o custo máximo disponível para o release. Com isso, vis k (i) é expresso por: vis k (i) = { j custo(r ) + e j B} (2.13) onde e j representa o custo do requisito j e B o orçamento máximo disponível para o próximo release. A seleção do vértice j quando uma formiga k está no vértice i é definida por: j = argmax u visk (i){[τ iu ] [η iu ] β }, se q q 0 (2.14) p k i j, caso contrário onde β controla a importância da informação heurística η iu do trajeto, q é uma variável uniformemente distribuída entre [0,1] e q 0 o parâmetro que especifica se a formiga fará exploração ou prospecção. A informação heurística do trajeto entre o vértice i e o vértice j (no NRP é conhecida com Medida de Produtividade para o Desenvolvimento de Software) é dada por: η i j = µ s j e j (2.15) onde µ é uma constante de normalização, s j e e j a satisfação e o custo do requisito j respectivamente. Quando q > q 0, a escolha do vértice j é definida pela regra proporcional pseudoaleatória: p k i j = [τ i j ] α [η i j ] β h visk (i) [τ ih ] α [η ih ] β, se j vis k (i) 0, caso contrário (2.16)

36 35 onde α e β representam a importância do feromônio e da informação heurística entre os vértices i e j respectivamente. No Problema do Próximo Release, a atualização do feromônio é feita local e globalmente pela formiga. A atualização global é definida como: τ i j = (1 ρ) τ i j + ρ τ i j (2.17) onde ρ representa a taxa de evaporação do feromônio, τ i j = score(r best ) score(r) a quantidade de feromônio depositado, R best representa a melhor solução encontrada até o momento e R é o conjunto de todos os requisitos disponíveis. A atualização local é definida como: τ i j = (1 ϕ) τ i j + ϕ τ 0 (2.18) onde τ 0 representa a quantidade de feromônio inicial das arestas e é definido por τ 0 = 1 score(r). A Figura 8 mostra o processo de construção de uma solução por uma formiga k em uma iteração do algoritmo. Inicialmente, a formiga é posicionada no vértice 2 que foi escolhido aleatoriamente. Nesse instante, a vizinhança opcional é composta pelos vértices 1, 3, 4 e 5 (o vértice 2 não foi incluído porque ele já foi selecionado para o release). Na Figura 8c, o vértice 5 não faz parte da vizinhança opcional pois, a sua inclusão, extrapola o orçamento definido para o release e, por isso, a formiga não pode visitá-lo. Por fim, a Figura 8d mostra a formiga no vértice 3 e nenhum vértice disponível na vizinhança obrigatória. A inclusão dos vértices 1 e 5 extrapola o limite máximo do release e por isso, chega ao fim o percurso da formiga nessa interação, gerando assim como uma possível solução do problema o conjunto R = {2,4,3} com score(r ) = 7 e cost(r ) = OTIMIZAÇÃO INTERATIVA Vários métodos automáticos são propostos na literatura como forma de resolução de problemas complexos enfrentados pelos usuários no seu dia a dia. Os resultados apresentados por estes métodos mostram-se promissores mas um grande desafio surge durante a aplicabilidade e eficácia de tais métodos: como o processo de busca foi feito sem a efetiva participação do usuário, aceitar tais resultados pode causar uma certa insegurança, tendo em vista que o seu conhecimento teórico e de domínio não foi devidamente incorporado na solução final. Além disso, estes

37 36 Figura 8 Exemplo de uma iteração para formiga k. Fonte: Adaptada de Sagrado, Aguila e Orellana (2010) métodos não consideram, durante o processo de busca, os aspectos subjetivos humanos devido à dificuldade de modelar de forma objetiva (ou matematicamente) as preferências do usuário. Diante deste problema, surge o conceito de Otimização Interativa que tem como objetivo incluir o usuário no processo de busca e assim, interagindo com o algoritmo, ajudar a descobrir soluções que além de serem boas matematicamente, possuem as preferências do usuário. Uma estratégia bastante comum na Otimização Interativa é colocar o usuário como tomador de decisão, avaliando as soluções geradas pelo algoritmos. Neste processo, todo o seu conhecimento e aspectos psicológicos são incorporados no processo de busca (HARMAN; MANSOURI; ZHANG, 2009). A Figura 9 apresenta a estrutura de um sistema onde o seu processo de busca utiliza Otimização Interativa. Na figura é possível observar a execução do algoritmo em dois ciclos: um ciclo interno e o ciclo externo. O ciclo interno é responsável por executar algoritmos que gerem soluções candidatas que, posteriormente, serão avaliadas por uma função de fitness. Já o ciclo externo é responsável por buscar e apresentar ao usuário uma solução para que o mesmo faça a sua avaliação. O feedback é capturado pelo gerenciador de interações e enviado para o ciclo

38 37 interno. Figura 9 Resumo de sistemas que utilizam Otimização Interativa. Fonte: Adaptada de Marculescu, Feldt e Torkar (2012) Baseado nisso, surge então a Computação Evolucionária Interativa (Interactive Evolutionary Computation - IEC), um ramo da Otimização Interativa que baseia-se em dois princípios: a avaliação do usuário e métodos de busca baseados em Algoritmos Evolucionários ou Programação Genética (TAKAGI, 2001). Segundo Takagi (2001), a Computação Evolucionária Interativa possui duas definições principais: a definição mais restrita afirma que a IEC é a tecnologia na qual os algoritmos são baseados em Computação Evolucionária com o objetivo de otimizar sistemas alvos através da avaliação subjetiva humana como valor de fitness. Outra definição mais abrangente e uma das mais utilizadas encontrada na literatura define a IEC como sendo a tecnologia que otimiza sistemas alvo tendo uma interface humano-máquina interativa. A IEC tem sido utilizada em várias áreas nos últimos anos como, por exemplo, na área de artes e animações gráficas, música, design editorial, design industrial, geração de imagem facial, processamento de fala e síntese, adaptação de aparelhos auditivos, realidade virtual, recuperação de mídia em banco de dados, mineração de dados, processamento de imagens, controle e robótica, indústria alimentar, geofísica, educação, entretenimento (TAKAGI, 2001). Um problema bastante comum em IEC é o problema da fadiga humana. A fadiga humana pode ser definida como sendo um estado fisiológico de redução da capacidade de desempenho mental ou físico do humano, que neste contexto, é ocasionado pela excessiva carga de interação entre o usuário e o algoritmo (SIMONS; SMITH; WHITE, 2014). Como o usuário está dentro do processo de busca, este cansaço (fadiga) pode levar a, por exemplo, avaliações negativas em soluções consideradas boas ou avaliações positivas em soluções consideradas ruins. Diversos estudos na literatura propõem formas de resolver o problema da fadiga

39 38 humana. Por exemplo, alguns sistemas de IEC buscam as soluções acelerando a convergência do algoritmo com pequenas populações e poucas gerações (CALEB-SOLLY; SMITH, 2007). Outras abordagens propõe a discretização de valores de fitness contínuos em cinco ou sete níveis facilitando a tomada de decisão por parte do usuário, sem comprometer significativamente a convergência (OHSAKI; TAKAGI; OHYA, 1998). Miller (1956) ainda sugere organizar as informações sucessivamente em uma sequência de pedaços para ajudar o usuário a estender o limite da fadiga, ou seja, fazer com que a fadiga demore a acontecer. 2.7 CONSIDERAÇÕES FINAIS Este capítulo apresentou uma revisão teórica relativa aos principais conceitos sobre Problemas de Otimização e suas formulações, além da definição e possíveis aplicações de Search-Based Software Engineering. De maneira geral, os conceitos apresentados ressaltam a importância da área de SBSE que, apesar de ser nova, está apresentando ótimos resultados em problemas ditos complexos na área de Engenharia de Software. Além disso, foi apresentada neste capítulo a definição do problema que será abordado neste trabalho, o Problema do Próximo Release, mostrando a sua motivação e a formulação matemática comumente utilizada. Em seguida, foi apresentado o algoritmo de Otimização por Colônia de Formiga, especificando a inspiração biológica, o algoritmo e as principais variações encontradas na literatura. Ainda nesta seção, um exemplo simples de execução do algoritmo foi apresentado, mostrando o funcionamento de uma formiga ao selecionar os requisitos para o próximo release. Por fim, uma proposta de adaptação do algoritmo ACO desenvolvido por Sagrado, Aguila e Orellana (2010) para resolver o NRP foi exposta bem como o conceito de Otimização Interativa, mostrando as suas definições, principais problemas da área e possíveis soluções para acelerar a convergência dos algoritmos. Buscando mitigar o problema da fadiga humana na Otimização Interativa, o ACO foi escolhido devido a sua capacidade de gerar boas soluções em poucas iterações, necessitando assim poucas interações do usuário. No próximo capítulo serão apresentados os trabalhos relacionados a esta pesquisa.

40 39 3 TRABALHOS RELACIONADOS Este capítulo tem como objetivo apresentar os trabalhos relacionados às principais abordagens propostas na literatura para resolver o problema de seleção de requisitos, focando especialmente nos trabalhos desenvolvidos dentro do contexto de SBSE. Apresenta ainda alguns trabalhos envolvendo algoritmos interativos em SBSE que não necessariamente propõem uma metodologia para a resolução deste problema mas que estão relacionadas ao tema. 3.1 TÉCNICAS DE BUSCA APLICADAS AO PROBLEMA DO PRÓXIMO RELEASE Como explicado na Seção 2.3, o Problema do Próximo Release consiste em selecionar um conjunto de requisitos para o próximo release onde o orçamento do conjunto não pode ultrapassar o orçamento máximo estipulado para o release. Diversos trabalhos na literatura abordam este problema e suas variações usando os mais diversos algoritmos como forma de resolução. Um dos primeiros trabalhos sobre NRP foi o trabalho desenvolvido por Bagnall, Rayward-Smith e Whittley (2001) onde eles apresentam a primeira formulação do problema que tem como objetivo maximizar a importância dos clientes atendidos pela seleção. Para validar a proposta, os autores realizam testes com métodos exatos, gulosos e heurísticos como, por exemplo, algoritmo GRASP (Greedy Randomized Adaptive Search Procedure), Subida da Encosta e Algoritmo Genético. Os resultados mostram que para pequenas instâncias o algoritmo exato obtém os melhores resultados mas para grandes instâncias, a Têmpera Simulada gerou as melhores soluções. Ainda neste contexto, Sagrado, Aguila e Orellana (2010) fazem um estudo comparativo entre Algoritmo Genético, Têmpera Simulada e ACO aplicado ao NRP. Nesse estudo, os autores mostram que o ACO consegue encontrar soluções com o máximo de satisfação do cliente no limite do orçamento estipulado para o release. Já o Algoritmo Genético mostra uma performance parecida com o ACO mas com uma grande variabilidade na satisfação e por fim, a Têmpera Simulada encontra os piores resultados tanto no limite de orçamento máximo do release quanto na satisfação dos clientes. Como o estudo anterior não abordava as interdependências existentes entre os requisitos, Ferreira e Souza (2012) fizeram um estudo comparativo entre ACO, Algoritmo Genético e Têmpera Simulada aplicado ao NRP com o uso de interdependência entre requisitos. Neste

41 40 problema, as interdependências como, por exemplo, custo (selecionar um requisito altera o custo de outro requisito), valor (selecionar um requisito altera valor de outro requisito) e precedência (selecionar um requisito somente se outro for selecionado) foram incorporados na escolha do conjunto de requisitos. O trabalho mostrou que o ACO encontrou as melhores soluções comparadas com as outras metaheurísticas mas com um tempo em média 28% maior. Os trabalhos anteriores abordavam o problema do NRP usando instâncias artificiais, ou seja, instâncias que tinham os seus valores gerados aleatoriamente e normalmente com poucos requisitos. Pensando nisso, Mausa et al. (2013) aplicaram quatro variações do algoritmo de Subida da Encosta e duas variações da Têmpera Simulada ao NRP com instâncias reais, além de usar um grande conjunto de requisitos com o objetivo de tornar o problema mais próximo da realidade. Os resultados mostram que a Têmpera Simulada gerou as melhores soluções além de mostrar que o algoritmo de Subida da Encosta gera soluções que dão uma visão mais ampla sobre o espaço de busca e que, por isso, seus resultados não podem ser negligenciados. Abordagens usando otimização exata também foram aplicadas ao NRP no trabalho de Freitas, Coutinho e Souza (2011). Apesar do Algoritmo Genético encontrar soluções que são em média 30% melhor que as soluções geradas pela Têmpera Simulada, como era esperado, todas as soluções geradas foram inferiores às soluções geradas pelos métodos exatos. Existem também na literatura abordagens multiobjetivos desenvolvidas para o Problema do Próximo Release. Um dos trabalhos mais conhecidos da área é o trabalho realizado por Zhang, Harman e Mansouri (2007) que argumenta que a formulação multiobjetivo é a mais realista, mostrando que essa abordagem representa um cenário que possui bastante complexidade e demandas conflitantes. Neste trabalho, a abordagem busca soluções que maximizem a satisfação do cliente e minimizem o custo da seleção. Para validar a proposta, os autores apresentam um estudo empírico realizado com Busca Aleatória, Single-Objective GA, Pareto GA e NSGAII. Os resultados mostram que o NSGA-II superou as outras técnicas na busca pela frente de Pareto mas que o Single-Objective GA teve um desempenho melhor em encontrar regiões extremas ao longo da frente de Pareto. Em trabalhos mais recentes envolvendo o NRP, Paixão e Souza (2013) utilizaram conceito de incertezas para selecionar um conjunto de requisitos que tiveram o seu valor de custo e satisfação estimado de forma equivocada. Nesse trabalho, a solução gerada, chamada de solução robusta, mostrou-se um pouco inferior mas com a grande vantagem de trabalhar com estimativas erradas, algo bastante comum no dia a dia de engenheiros de software e gerentes de

42 41 projeto. Por fim, Araújo e Paixão (2014) propõem a utilização de um Algoritmo Genético Interativo com aprendizado de máquina como forma de substituir o usuário no processo de avaliação das soluções geradas para o Problema do Próximo Release. Na abordagem o usuário é convidado a avaliar as soluções geradas fornecendo ao algoritmo uma nota que representa o quão satisfeito ele está com a solução gerada. Como forma de validar a abordagem os autores utilizaram simuladores responsáveis por representar o perfil de avaliação de possíveis usuários do sistema. Os resultados mostram que o algoritmo conseguiu gerar soluções que são cerca de 70% similar quando comparado com as soluções alvos utilizadas nos simuladores. 3.2 ALGORITMOS INTERATIVOS EM SBSE Vários trabalhos em SBSE utilizam algoritmos interativos (ZHANG; HARMAN; MANSOURI, 2011) como forma de resolução de problemas da área e, assim, agregando a opinião humana dentro do processo de busca, aumentar a aceitação e a confiabilidade das soluções geradas por métodos automáticos. Diversos autores propõem o uso de Algoritmo Genético Interativo (Interactive Genetic Algorithm - IGA) como forma de resolução destes problemas. Em seu trabalho, Simons (2011) desenvolveu um Algoritmo Genético Interativo para encontrar o melhor design Projeto de Software em um sistema composto por classes, atributos e métodos, com a ajuda do usuário avaliando as melhores soluções geradas pelo algoritmo. Nessa abordagem, o IGA gera soluções que, posteriormente, serão avaliadas pelo usuário de acordo com as suas preferências. No sistema desenvolvido o usuário visualiza o design de software gerado pelo algoritmo e tem a possibilidade de interagir com o sistema usando estrelas que representam o quão boa é a solução gerada pelo algoritmo: quanto mais estrelas, melhor o design, quanto menos estrelas pior o design. Detalhes sobre a interface podem ser vistos na Figura 10. Buscando integrar o desenvolvedor dentro do processo de re-modularização de software, Bavota et al. (2012) desenvolvem um Algoritmo Genético Interativo que, agregando as avaliações subjetivas do desenvolvedor, consegue encontrar distribuição de componentes em módulos melhor do que os algoritmos sem nenhuma interatividade e, principalmente, consegue gerar boas soluções com poucas interações com o usuário. Para capturar a avaliação subjetiva do usuário, o algoritmo utiliza a abordagem de solicitar ao usuário que avalie se dois componentes devem ou não fazer parte do mesmo módulo. Com este feedback, o algoritmo penaliza as

43 42 Figura 10 Sistema de Interação com o Usuário para Avaliação do Projeto de Software. Fonte: Simons (2011) soluções geradas que não estão de acordo com a avaliação do usuário. Algoritmos Genéticos Interativos têm sido aplicados também em priorização de requisitos. O processo de priorização de requisitos pode ser visto como uma relação de ordem dentro de um conjunto de requisitos usando algum critério de ordenação como, por exemplo, restrição de tempo ou disponibilidade de orçamento. Em seu trabalho, Tonella, Susi e Palma (2010) utilizam a interatividade como forma de minimizar a quantidade de comparação par-a-par no processo de priorização de requisitos, incorporando as preferências do usuário quando existe um empate entre dois requisitos. Em trabalhos mais recentes, Marculescu, Feldt e Torkar (2013) apresentam um sistema para teste de software baseado em busca interativa. O trabalho tem como objetivo incluir o especialista de domínio, através da reponderação da função objetivo, dentro do processo de busca. Uma grande vantagem da abordagem é a capacidade de incluir usuários que não tenham, necessariamente, conhecimento de engenharia de software ou gerência de projetos no processo de busca. Apesar de não existir em grande quantidade, na literatura também é possível encontrar

44 43 alguns trabalhos que utilizam algoritmo ACO Interativo como forma de resolução dos problemas em SBSE. Em seu trabalho, Uğur e Aydin (2009) desenvolveram um software de Simulação e Análise Baseado em Web chamado TSPAntSim para o Problema do Caixeiro Viajante. Neste sistema, o usuário tem a possibilidade de escolher além dos parâmetros que os algoritmos utilizarão, qual a variação do ACO ele deseja executar (Ant Colony System, Elitist Ant System e etc). No final da execução, o sistema ainda fornece diversos dados estatísticos inclusive análise em tempo real da execução do algoritmo. Na Figura 11 é possível observar o funcionamento do sistema além do relatório gerado por ele. Figura 11 TSPAntSim - Sistema Interativo usando ACO para o TSP. Fonte: Uğur e Aydin (2009) Trabalhos recentes mostram que o algoritmo ACO pode superar os Algoritmos Evolucionários em busca do Projeto de Software com melhores valores fitness em poucas quantidades de iterações (SIMONS; SMITH, 2012; SIMONS; SMITH, 2013). Baseado nisso, Simons, Smith e White (2014) propõem um algoritmo interativo usando ACO, chamado iaco (Interactive Ant Colony Optimization), com o objetivo de auxiliar o designer a encontrar o melhor design de classes no problema de Projeto de Software. No algoritmo, soluções são geradas e apresentadas ao usuário onde ele, por sua vez, avalia as melhores soluções. Ele ainda tem a possibilidade de, caso a solução gerada seja boa, interromper o processo de busca. Além disso o algoritmo decide o momento em que será realizado a interação com o usuário em uma iteração chamada iteração interativa. Quando o algoritmo consegue gerar soluções que estão obtendo boas avaliações, ele tende a interagir menos com usuário; quando gera soluções que estão obtendo péssimas avaliações, ele tende a interagir mais com o usuário. Na área da otimização multiobjetivo, Xing, Chen e Yang (2007) reportam o uso de

45 44 um ACO Interativo Fuzzy aplicado ao problema Flexible Job Shop Scheduling Problem (JSSP) que, usando n atividades em m máquinas, consiste em determinar uma atribuição e uma sequência de operações em todas as máquinas que minimize a carga horária total, a maior carga de trabalho e o tempo de conclusão máxima das máquinas. Uma das características da abordagem é que ela permite a interação entre o usuário e o ACO através da alteração dos níveis de aspiração. Na prática, o usuário pode achar conveniente definir uma função de decisão usando expressões de linguagem natural. No trabalho, a função de decisão é definida com base no método de Yager (??) para a agregação de múltiplos objetivos em uma função de decisão única usando declarações linguisticamente quantificados. Os resultados obtidos a partir do experimento indicam que a abordagem proposta é uma abordagem viável e eficaz para o problema. Outros trabalhos como, por exemplo, o trabalho do Albakour et al. (2011), demonstra que o algoritmo ACO pode ser utilizado em um processo de aprendizado contínuo para busca interativa utilizando logs de consultas. Os experimentos foram realizados em mais de um milhão de consultas que foram coletadas em um mecanismo de busca de uma universidade durante três anos. Nesta abordagem, cada vértice representa uma frase da consulta e as arestas representam a possibilidade de refinamento. A interação com usuário é tratada como uma jornada de uma formiga, atualizando inclusive o feromônio dos trajetos, o que representa, por exemplo, que quanto mais feromônio na aresta, melhor será o refinamento e, consequentemente, a sugestão para o usuário. Os resultados encontrados depois de validações automáticas mostram que o ACO interativo obteve desempenho significativamente melhor do que a abordagem baseada em regra de associação. 3.3 CONSIDERAÇÕES FINAIS Este capítulo procurou mostrar as principais abordagens encontradas na literatura para lidar com o problema de seleção de requisitos e algoritmos interativos utilizados no contexto de SBSE. Com relação aos trabalhos encontrados na literatura sobre seleção de requisitos somente o trabalho do Araújo e Paixão (2014) utiliza-se apropriadamente de uma modelagem interativa, ou seja, solicitando ao usuário que avalie uma seleção de requisitos, incorporam os fatores subjetivos dentro do processo de busca. Isso mostra que não existem muitos trabalhos na literatura que se preocupam em propor abordagens interativas para o NRP. Além disso, é possível encontrar alguns algoritmos interativos em SBSE que utili-

46 45 zam ACO como método automático mas nenhum deles foi aplicado ao Problema do Próximo Release. Isso torna a proposta deste trabalho inovadora em SBSE não só pela caracterização das abordagens interativas mas também pelo algoritmo interativo utilizando ACO. No próximo capítulo será apresentado, de forma detalhada, as características que algoritmos interativos usando ACO possuem, como também serão apresentadas algumas abordagens desenvolvidas usando as características levantadas mostrando o seu algoritmo, vantagens e desvantagens.

47 46 4 ABORDAGENS INTERATIVAS COM ACO Este capítulo tem como objetivo apresentar abordagens interativas usando o ACO para o Problema do Próximo Release. Inicialmente, são apresentadas as características de interação, mostrando quais os momentos e as formas de incorporar as preferências do usuário. Em seguida são apresentadas algumas abordagens interativas usando ACO que foram desenvolvidas baseadas na seleção de algumas das características de interação descritas. 4.1 CARACTERÍSTICAS DA INTERAÇÃO Na literatura sobre otimização interativa é possível encontrar as mais variadas formas de incorporar a subjetividade dentro do processo de busca. Estas formas de incorporação, em alguns casos, são desenvolvidas especificamente para o problema abordado ou o algoritmo utilizado. Por exemplo, em algumas abordagens o usuário é convidado a avaliar algumas soluções geradas pelos algoritmos (SIMONS; SMITH; WHITE, 2014). Em outras, o usuário expressa as suas preferências avaliando se dois elementos devem está juntos ou separados em um dado contexto (BAVOTA et al., 2012), ou ainda, o algoritmo utiliza as preferências do usuário para desempatar dois elementos que são, matematicamente, iguais (TONELLA; SUSI; PALMA, 2010) Existem diversas formas de incorporar as preferências do usuário na evolução de um algoritmo ACO. Por exemplo, uma interface gráfica (Graphical User Interface - GUI) rica em detalhes pode ser utilizada para capturar as preferências do usuário na seleção de parâmetros antes de executar o algoritmo (UĞUR; AYDIN, 2009) ou ainda, uma interface onde o usuário tem a possibilidade de interagir durante a execução do algoritmo avaliando soluções (SIMONS; SMITH, 2012). Dentre as várias possibilidades de interação com o algoritmo ACO e o problema NRP encontradas em outros trabalhos da literatura, este identificou e caracterizou as formas de incorporar a subjetividade humana dentro do algoritmo ACO utilizado para resolver o Problema do Próximo Release. As características identificadas foram: Momento da Interação, Tipo de Informação Requerida do Usuário, Forma de Incorporação da Informação, Quantidade de Interações e Critério de Parada. A seguir, cada característica é descrita com seus tipos e definições.

48 Momento da Interação As preferências do usuário podem ser incorporadas em vários momentos durante a execução do algoritmo.?? (??) aborda esses momentos dizendo que o momento À Priori é o onde o tomador de decisão deve especificar suas preferências antes do processo de busca automático e, oposto a isso, o método À Posteriori executa o processo de busca sem qualquer preferência do usuário e, no final, provê um conjunto de soluções alternativas. A característica Momento da Interação é responsável por definir em qual instante a interação com o usuário irá ocorrer. Esse instante pode ser dividido em três tipos: À Priori, In-the-loop e À Posteriori. A seguir, os três tipos são descritos. À Priori: Quando as preferências do usuário são incorporadas antes da execução do algoritmo. Neste momento, o usuário precisa emitir as suas preferências antes que qualquer solução seja gerada pelo algoritmo. A Figura 12 representa este momento da interação. Figura 12 Momento da Interação À Priori Fonte: Elaborada pelo Autor In-the-loop: Quando as preferências do usuário são incorporadas durante a execução do algoritmo. Enquanto o algoritmo está buscando a melhor solução, ele pode parar a busca para pedir ao usuário que expresse suas preferências para uma dada situação e com a informação fornecida, continuar o processo de busca. Neste tipo de momento, não existe uma quantidade exata de interações podendo o usuário interagir uma ou mais vezes durante a busca. A Figura 13 representa este momento da interação. À Posteriori: Quando as preferências do usuário são incorporadas no final da execução do algoritmo. Neste tipo de momento, o algoritmo executa a busca por soluções do problema e no final da execução o usuário escolhe aquela que mais o agradou. O momento À Posteriori

49 48 Figura 13 Momento da Interação In-the-loop Fonte: Elaborada pelo Autor é bastante comum em algoritmos multiobjetivos onde a saída do algoritmo é um conjunto de soluções ótimas, cabendo ao usuário escolher a melhor solução baseado em suas preferências. A Figura 14 representa este momento da interação. Figura 14 Momento da Interação À Posteriori Fonte: Elaborada pelo Autor Tipo de Informação Requerida do Usuário Durante o momento da interação com o usuário, o algoritmo ACO pode apresentar algumas informações as quais o usuário deve analisar e fornecer a sua avaliação subjetiva sobre o que foi apresentado. Para o Problema do Próximo Release, o algoritmo pode requerer que o usuário expresse suas preferências, por exemplo, disponibilizando valores para parâmetros, selecionando requisitos, dividindo os requisitos em categorias ou avaliando um release completo. Com isso, foram criados quatro tipos de informação requeridas que são descritas a seguir.

50 49 Valores de Parâmetros: Uma forma simples de interação é solicitar que o usuário escolha valores para alguns parâmetros do algoritmo. Por exemplo, definir os valores dos parâmetros α e β no algoritmo ACO para determinar a influência do feromônio e da informação heurística respectivamente na escolha do próximo vértice da formiga. Outro exemplo seria definir a quantidade de feromônio inicial de todas as arestas ou ainda, a quantidade de iterações que o algoritmo irá executar. A Figura 15 representa este tipo de informação requerida. Figura 15 Valores de Parâmetros como Informação Requerida Fonte: Elaborada pelo Autor Seleção de Requisitos: Para este tipo de informação requerida, o algoritmo ACO apresenta um conjunto de requisitos L = {R 1,R 2,...,R k } onde o usuário deve selecionar alguns destes requisitos e fornecer para o algoritmo. Por exemplo, o algoritmo apresenta um conjunto de requisitos e o usuário escolhe os dois requisitos que têm a maior satisfação. A Figura 16 representa este tipo de informação requerida. Figura 16 Seleção de Requisitos como Informação Requerida Fonte: Elaborada pelo Autor Divisão em Categorias: Na Divisão por Categorias, o algoritmo ACO apresenta ao usuário um conjunto de requisitos L = {R 1,R 2,...,R k } e um conjunto de categorias C = {C 1,C 2,...,C m } onde o objetivo é que o usuário atribua uma categoria a cada requisito do

51 50 conjunto L (um requisito só pode ser classificado em uma única categoria). Por exemplo, seja L = {R 1,R 2 } e C = {C 1,C 2,C 3 } o conjunto de categorias onde cada uma representa o nível de satisfação por determinado requisito, uma possível divisão seria R 1 C 2 e R 2 C 1. A Figura 17 representa este tipo de informação requerida. Figura 17 Divisão em Categorias como Informação Requerida Fonte: Elaborada pelo Autor Avaliação do Release: Outra forma de capturar as preferências do usuário é apresentar um release e pedir para que ele faça a avaliação subjetiva, atribuindo um valor que irá representar a sua satisfação em relação aquele release. Neste caso, quanto maior o valor atribuído ao release, maior é a sua preferência pelos requisitos selecionados. Caso contrário, quanto menor o valor, menor a sua preferência pelos requisitos selecionados. A Figura 18 representa este tipo de informação requerida. Figura 18 Avaliação do Release como Informação Requerida Fonte: Elaborada pelo Autor Forma de Incorporação da Informação As preferências do usuário podem ser incorporadas no algoritmo ACO de várias formas. Por exemplo, durante a busca, a formiga pode ter uma probabilidade maior de selecionar

52 51 um vértice que tenha maior preferência ou os requisitos que não têm uma boa avaliação por parte do usuário podem não pertencer a vizinhança opcional da formiga (Equação 2.13). A forma de incorporação pode ser dividida em cinco tipos: Parâmetros, Função Objetivo, Informação Heurística do Trajeto, Composição da Vizinhança Opcional e Direta. Todas as cinco formas são descritas a seguir. Parâmetros: Quando as preferências do usuário são incorporadas nos parâmetros do algoritmo. Neste tipo de incorporação, as preferências do usuário serão responsáveis por definir, por exemplo, a quantidade de interações do algoritmo, quantidade de feromônio inicial ou ainda a influência do feromônio do trajeto ou da informação heurística na escolha do próximo vértice. Função Objetivo: Quando as preferências do usuário são incorporadas na função objetivo do problema. Neste tipo de incorporação, a avaliação do usuário pode servir como um reforço na avaliação da solução (ou seja, aumentar o valor de fitness) ou uma penalidade na avaliação da solução (ou seja, diminuir o valor de fitness). Informação Heurística do Trajeto: Outra forma de incorporar as preferências do usuário é, por exemplo, aumentar a probabilidade da formiga escolher um vértice que foi bem avaliado e diminuir a probabilidade de escolher um vértice que não foi bem avaliado pelo usuário. Por exemplo, se a formiga está no vértice i e vai para o vértice j bem avaliado pelo usuário, o valor da informação heurística η i j terá um acréscimo. Caso contrário, seu valor será diminuído. Composição da Vizinhança Opcional: Nessa forma de incorporação, as preferências do usuário são levadas em consideração no momento de compor a vizinhança opcional das formigas. Por exemplo, os requisitos mais bem avaliados pelo usuário terão uma chance maior de estarem na vizinhança opcional e com isso serem selecionados. Já os requisitos menos avaliados terão uma probabilidade menor de estarem na vizinhança opcional e com isso, uma menor chance de serem selecionados. Direta: Esta forma de incorporação é dada pela manipulação direta da solução gerada pelo algoritmo. Ou seja, as preferências do usuário irão refletir na adição de novos ou remoção de elementos que fazem parte da solução. Por exemplo, o usuário pode retirar um requisito da solução o qual ele achou ter um custo muito elevado ou adicionar um requisito que ele acha fundamental a sua presença no release. A diferença entre a incorporação na Informação Heurística do Trajeto e na Composição da Vizinhança Opcional é que, na primeira, todos os requisitos podem ser selecionados

53 52 mesmo os menos avaliados. No caso da segunda, existe uma probabilidade de requisitos menos avaliados não fazerem parte da vizinhança opcional e, por isso, nunca serem selecionados pela formiga. Além disso, o algoritmo interativo pode utilizar uma ou mais formas de incorporação da informação no processo de busca permitindo que ele consiga encontrar soluções que possuam mais as preferências do usuário. É possível perceber também que nenhuma forma de incorporação foi definida utilizando o feromônio do trajeto das formigas. Um exemplo simples seria reforçar (aumentar) a quantidade de feromônio na trilha para todos os requisitos desejáveis. Acredita-se que o feromônio do trajeto é algo particular do comportamento e interação das formigas e por isso, somente elas podem alterar o seu valor. Apesar deste trabalho não propor uma interação (manipulação direta) sobre o feromônio do percurso, as preferências do usuário são incorporadas na atualização do feromônio mesmo que indiretamente pois a quantidade de feromônio depositado é proporcional a qualidade da melhor solução encontrada (solução essa que já tem as preferências do usuário) Quantidade de Interações Em algoritmos interativos, a busca pela melhor solução exige que o usuário participe do processo interagindo uma ou mais vezes. A participação ideal é quando o usuário interage com o algoritmo em todas as iterações avaliando cada solução gerada pelo algoritmo. Naturalmente, isto não é possível devido a quantidade excessiva de interações que poderiam fazer com que o usuário desenvolvesse fadiga humana, ou seja, um estado onde ele está cansado fisicamente ou psicologicamente e que poderia afetar a qualidade das avaliações e consequentemente das soluções geradas. Diante disso, a Quantidade de Interações é uma característica de interação para o algoritmo ACO Interativo que determina a quantidade de interações que o algoritmo realizará com o usuário afim de capturar as suas preferências. Esta característica pode ser do tipo Fixa ou Dinâmica como descritas a seguir. Fixa: A quantidade de interações é do tipo Fixa quando o algoritmo sabe anteriormente quantas e quando as interações com o usuário deverão ocorrer. Por exemplo, o algoritmo deverá interagir x vezes com o usuário em todas as iterações pares. Dinâmica: A quantidade de interações é do tipo Dinâmica quando o próprio algo-

54 53 ritmo define quantas e quando as interações deverão ser realizadas baseado nas preferências fornecidas pelo usuário durante o processo de busca. Por exemplo, o algoritmo pode interagir pouco com o usuário diante de ótimas avaliações ou muito diante de péssimas avaliações Critério de Parada Uma prática comum em algoritmos de busca é utilizar o número de iterações, número de avaliações de uma solução ou estagnação como critério de parada do processo de busca. Em um algoritmo interativo, onde a solução gerada é construída baseada nas preferências do usuário, mesmo que o algoritmo não tenha atingido nenhum destes critérios, a solução gerada até então pode ser muito boa para o usuário e por isso, ele pode decidir encerrar o processo de busca. Sabendo disso, foram identificadas como características da interação o Critério de Parada de um algoritmo ACO Interativo. Esta característica pode ser dividida em Número de Iterações, Número de Avaliações, Estagnação ou Decisão do usuário. Os tipos de Critérios de Parada são descritos a seguir. Número de Iterações: Neste critério de parada o algoritmo ACO irá evoluir gerando novas soluções até alcançar o número máximo de iterações. Quando atingir, o algoritmo encerra o processo de busca. Número de Avaliações: Outra opção de parada do algoritmo é contabilizar quantas vezes uma solução gerada pelo ACO Interativo foi avaliada, ou seja, quantas vezes o valor de f itness foi calculado. Quando chegar ao limite estipulado de avaliações, o algoritmo encerra o processo de busca. Estagnação: Também conhecido como convergência, este critério de parada é utilizado quando o algoritmo não consegue gerar soluções melhores e por isso, todas as formigas tendem a andarem pelo mesmo percurso. Neste caso, quando um intervalo de iterações for atingido sem que o algoritmo consiga gerar novas soluções, o algoritmo encerrará o processo de busca. Decisão do Usuário: No critério de parada por Decisão do Usuário, o algoritmo ACO irá evoluir gerando novas soluções até que, em um dado momento, ele pergunta ao usuário se é o momento de parar. Neste momento o usuário pode, por exemplo, visualizar a melhor solução como base para tomar a decisão de encerrar ou não o processo. Mesmo que o usuário tenha a possibilidade de encerrar o processo de busca, é necessário que outro critério seja adicionado para evitar que o algoritmo execute indefinidamente.

55 ABORDAGENS INTERATIVAS Na Seção 4.1, foram descritas diversas características de interação que um algoritmo ACO Interativo para o Problema do Próximo Release pode conter. Várias abordagens interativas podem ser geradas combinando cada uma dessas características. Sabendo disso, nesta seção é apresentado a descrição, algoritmo, vantagens e desvantagens de algumas abordagens que foram elaboradas selecionando as características descritas anteriormente. A Tabela 3 contém uma síntese das principais abordagens interativas, destacando o momento da interação, o tipo de informação requerida do usuário, a forma de incorporação da informação, quantidade de interações e critério de parada das abordagens.

56 55 Tabela 3 Síntese das Abordagens Interativas Abordagem Interativa Momento da Interação Tipo de Informação Requerida do Usuário Forma de Incorporação da Informação Quantidade de Interações Critério de Parada Interação por Configuração de Parâmetrotros À Priori e In-the-loop Valores de Parâme- Parâmetros Fixa Decisão do Usuário Interação por Preferência no Release À Priori e In-the-loop Divisão em Categoriarística Função Objetivo e Informação Heu- Fixa Decisão do Usuário do Trajeto Interação por Comparação Par-a-Par In-the-loop Seleção de Requisitos Função Objetivo Fixa Número de Iterações Interação por Classificação de Requisitorias À Priori Divisão em Catego- Informação Heurística do Trajeto Fixa Número de Iterações Interação por Avaliação Preditiva do In-the-loop Avaliação do Release Função Objetivo Dinâmica Decisão do Usuário Release Interação por Avaliação do Release À Priori e In-the-loop Avaliação do Release Composição da Vizinhança Opcional Fixa Número de Iterações Interação por Substituição de Requisitos À Posteriori Seleção de Requisitos Direta Fixa Número de Iterações Fonte: Elaborada pelo autor.

57 Interação por Configuração de Parâmetros A Interação por Configuração de Parâmetros é uma das mais simples. Esta interação ocorre durante o processo de busca, onde o usuário é responsável por escolher (ou calibrar) os parâmetros que o algoritmo ACO irá utilizar. Caso a solução gerada não apresente bons resultados, ele pode simplesmente reconfigurar os parâmetros e executar novamente o algoritmo. Apesar de ser interativa, essa forma muitas vezes não captura as preferências do usuário sobre o problema visto que, em algumas situações, o usuário é o especialista do domínio mas não necessariamente conhece o algoritmo ACO. Além disso, essa interação obriga que o usuário tenha um conhecimento mínimo sobre o algoritmo com o qual ele vai interagir.

58 57 O Algoritmo 2 exemplifica a aplicação dessa interação no algoritmo ACO: Algoritmo 2: Algoritmo ACO Interativo por Configuração de Parâmetro Entrada: Conjunto de Requisitos Saída: Release selecionado início Define os parâmetros para o valor padrão do algoritmo; enquanto não atingir o critério de parada faça se a iteração é interativa então se o usuário aceita a solução gerada então Encerra o processo de busca; fim senão Apresenta os parâmetros ao usuário; Usuário define os novos valores; Reinicia o contador de iterações; fim fim senão Constrói as Soluções; Aplica Busca Local (Opcional); Atualiza o Feromônio; fim fim fim Nessa abordagem do ACO Interativo, o usuário tem a liberdade de escolher os valores para os seguintes parâmetros: a) α: Influência do feromônio na escolha do próximo vértice; b) β: Influência da informação heurística na escolha do próximo vértice; c) q 0 : Variável que define a probabilidade da escolha do próximo vértice ser por prospecção ou exploração; d) τ 0 : Variável que define a quantidade inicial de feromônio do trajeto;

59 58 e) ρ: Taxa de evaporação do feromônio; f) Quantidade de Iterações do algoritmo; g) Tipo do Algoritmo ACO utilizado (ACS, AS, Ant-Q dentre outros). A seguir serão apresentadas as vantagens e desvantagens desta abordagem: Vantagens a) Não há conflito entre as preferências - Todos os parâmetros do algoritmo são independentes; b) Não há repetição de preferências; c) É possível desfazer as preferências já definidas. Desvantagens a) Requer alto esforço cognitivo do usuário na hora de expressar as suas preferências; b) Usuário necessita ter conhecimento sobre o algoritmo; c) Sensível a quantidade de interações - O algoritmo pode não gerar boas soluções com poucas interações Interação por Preferência no Release Nesta abordagem interativa, o usuário expressa as suas preferências especificando quais requisitos ele gostaria ou não de ver no próximo release. Ou ainda, manter determinados requisitos sem preferência alguma. A interação com o usuário ocorre antes e durante a busca das soluções onde todos os requisitos são apresentados ao usuário não necessitando que ele expresse a opinião para todos os requisitos de uma só vez. Seja P = {p 1, p 2,..., p n } o vetor que representa as preferências do usuário para cada requisito. O algoritmo apresenta todos os requisitos ao usuário e captura suas preferências por determinados requisitos seguindo as regras definidas como: p j = 1 se o usuário gostaria de ver o requisito r j no release 0 se o usuário não tem nenhuma preferência definida pelo requisito r j 1 se o usuário não gostaria de ver o requisito r j no release (4.1) Inicialmente todos os requisitos possuem preferência definida como p j = 0, ou seja, nenhuma preferência definida. Com base nessas informações, o algoritmo incorporará as

60 59 informações que estão em P na informação heurística entre o vértice i e o vértice j da seguinte forma: η i j = (s j /e j ) µ se p j = 1 (s j /e j )/µ se p j = 1 (s j /e j ) caso contrário. (4.2) onde µ N é um parâmetro definido no inicio do algoritmo que representa a importância da preferência do usuário na escolha do próximo vértice pela formiga e s j e e j são a satisfação e o custo do requisito j respectivamente. As preferências do usuário também são levadas em consideração na hora de avaliar uma solução gerada pelo algoritmo e não só na hora de guiar a busca de uma formiga. Assim, a modelagem do NRP é definida como: maximizar γ score(r ) + δ pre f (R ) sujeito a custo(r ) B (4.3) onde B representa o orçamento máximo disponível para o release e γ e δ representam a importância da função score e da função pre f na hora de avaliar uma solução respectivamente. A função pre f pode ser definida como: pre f (R ) = r i R pre f erenciasatendidas(r i ) 1 + r j P tempre f erencia(r j ) (4.4) onde: pre f erenciasatendidas(r i ) = 1 se r i R e p i = 1 1 se r i / R e p i = 1 0 caso contrário (4.5) e 1 se p j = 1 ou p j = 1 tempre f erencia(r j ) = 0 caso contrário (4.6)

61 60 O Algoritmo 3 apresenta as características dessa abordagem interativa: Algoritmo 3: Algoritmo ACO Interativo por Preferência no Release Entrada: Conjunto de Requisitos Saída: Release selecionado início Apresenta todos os requisitos ao usuário; Usuário expressa suas preferências; Atualiza vetor de preferências P; enquanto não atingir o critério de parada faça se a iteração é interativa então Apresenta a melhor solução ao usuário; se o usuário aceita a solução gerada então Encerra o processo de busca; fim senão Usuário expressa suas preferências; Atualiza vetor de preferências P; fim fim senão Constrói as Soluções; Aplica Busca Local (Opcional); Atualiza o Feromônio; fim fim fim Vantagens A seguir serão apresentadas as vantagens e desvantagens desta abordagem: a) Não há conflito entre as preferências; b) Não há repetição de preferências; c) É possível desfazer as preferências já definidas;

62 61 d) Usuário não necessita ter conhecimento sobre o algoritmo; e) Não é sensível a quantidade de interações - O algoritmo consegue gerar boas soluções com poucas interações. Desvantagens a) Requer alto esforço cognitivo do usuário na hora de expressar as suas preferências Interação por Comparação Par-a-Par Nesta abordagem interativa o usuário participa durante a busca escolhendo um requisito entre dois apresentados, qual ele prefere ver dentro do release. Os dois requisitos apresentados ao usuário são selecionados aleatoriamente a partir da melhor solução encontrada na iteração. Seja Q = {r 1,r 2,...,r p } o conjunto de requisitos que foram selecionados pelo usuário por comparação par-a-par. Nesta abordagem, quanto mais requisitos marcados como preferências estiverem dentro do release, melhor será a solução; quanto menos requisitos marcados como preferências estiverem fora do release, pior será a solução. Para isso, a função que calcula o score de um dado release é definida como: score(r ) = r j R s j (1 + k r j Q e r j / R i) (4.7) onde R R é o conjunto de requisitos selecionados para o próximo release, k > 0 é coeficiente de importância da penalidade, ou seja, representa o fator de redução do valor da função objetivo e i é a quantidade de requisitos que foram marcados como preferenciais pelo usuário e não estão presentes no release selecionado.

63 62 O Algoritmo 4 apresenta as características dessa abordagem interativa: Algoritmo 4: Algoritmo ACO Interativo por Comparação Par-a-Par Entrada: Conjunto de Requisitos Saída: Release selecionado início fim enquanto não atingir o critério de parada faça fim Constrói as Soluções; Aplica Busca Local (Opcional); se a iteração é interativa então fim Seleciona a melhor solução da iteração; para j=1... nfeedback faça Seleciona aleatoriamente dois requisitos r i e r j pertencentes a melhor fim solução da iteração; Apresenta ao usuário r i e r j ; Usuário escolhe qual dos dois requisitos ele prefere; Adiciona o requisito selecionado no conjunto Q; Penaliza soluções que não estejam de acordo com as preferências do usuário; Atualiza o Feromônio; O parâmetro nfeedback do algoritmo representa a quantidade de pares de requisitos que serão apresentados ao usuário na iteração interativa. Se um requisito já estiver dentro do conjunto Q ele não é adicionado novamente. A seguir serão apresentadas as vantagens e desvantagens desta abordagem: Vantagens a) Requer baixo esforço cognitivo do usuário na hora de expressar as suas preferências; b) Usuário não necessita ter conhecimento sobre o algoritmo; c) Não é sensível a quantidade de interações - O algoritmo consegue gerar boas

64 63 soluções com poucas interações. Desvantagens a) Repetição de Preferências - Ao selecionar os pares de requisitos o algoritmo pode apresentar ao usuário um requisito que já pertence a Q; b) Conflito entre as preferências - O usuário não pode escolher os dois requisitos apresentados mesmo ele preferindo ambos; c) Não é possível desfazer as preferências já definidas Interação por Classificação de Requisitos Para o usuário decidir somente quem deve estar ou não no release pode ser suficientemente realista principalmente porque esta decisão não dá a flexibilidade suficiente para que o usuário expresse as suas preferências: ele vai ter que escolher uma ou outra opção. A interação por Classificação de Requisitos surge como forma de suprir a necessidade do usuário de definir, por exemplo, a qualidade de um requisito selecionando valores de variáveis linguísticas que se aproximam mais das suas preferências. Os possíveis valores são expressos de acordo com o conjunto F = {Sem Nenhuma Prioridade, Sem Prioridade Imediata, Tanto Faz, Prioritário, Altamente Prioritário}. Seja Q = {r 1,r 2,...,r n } o vetor que guarda as preferências do usuário sobre a classificação de todos os requisitos disponíveis, segundo o conjunto F. As preferências do usuário são capturadas antes de executar a busca e incorporadas na informação heurística do trajeto entre o vértice i e o vértice j seguindo esta regra: ( ) s 0 j e j Se r j foi classificado como Sem Nenhuma Prioridade η i j = ( ) s n n j 2 e ( j s j e j ) n Se r j foi classificado como Sem Prioridade Imediata Se r j foi classificado como TantoFaz (4.8) ( ) s n+ n j 2 e j ( s j e j ) 2n Se r j foi classificado como Prioritário Se r j foi classificado como Altamente Prioritário onde n representa a importância da preferência do usuário na escolha do próximo vértice pela formiga e s j e e j a satisfação e o custo do requisito respectivamente. No cálculo da informação heurística, a formiga terá uma probabilidade maior de escolher requisitos que foram definidos como Altamente Prioritário e Prioritário e uma probabi-

65 64 lidade menor de selecionar requisitos que foram marcados como Sem Prioridade Imediata e Sem Nenhuma Prioridade. O Algoritmo 5 representa essa abordagem interativa: Algoritmo 5: Algoritmo ACO Interativo por Classificação de Requisitos Entrada: Conjunto de Requisitos Saída: Release selecionado início Apresenta todos os requisitos para o usuário; Usuário classifica os requisitos segundo o conjunto F; Adiciona a classificação em Q; enquanto não atingir o critério de parada faça Constrói as Soluções; Aplica Busca Local (Opcional); Atualiza o Feromônio; fim fim A seguir serão apresentadas as vantagens e desvantagens desta abordagem: Vantagens a) Usuário não necessita ter conhecimento sobre o algoritmo; b) Não é sensível a quantidade de interações - O algoritmo consegue gerar boas soluções mesmo com pouca interação; c) Não há repetição de preferências; d) Não há conflito entre as preferências. Desvantagens a) Requer alto esforço cognitivo do usuário na hora de expressar as suas preferências; b) Não é possível desfazer as preferências já definidas Interação por Avaliação Preditiva do Release No processo de busca interativa do melhor release para o projeto, o usuário pode não se sentir confortável em expor suas preferências para um requisito isoladamente pois ele

66 65 sabe que a presença de outro requisito pode interferir em sua opinião. Neste modelo de interação, o usuário tem a possibilidade de avaliar o release completamente e não somente um requisito, fornecendo uma nota que representará a sua preferência pelo release selecionado. Essa nota será então somada (reforço) a satisfação subjetiva do release. A modelagem do Problema do Próximo Release é descrita como: maximizar γ score(r ) + δ nota(r ) sujeito a cost(r ) B (4.9) onde R é o conjunto de requisitos selecionados, γ e δ representam a importância da função score e da função nota na hora de avaliar uma solução respectivamente e B é o orçamento máximo disponível para o release. Na iteração interativa a melhor solução dela será apresentada ao usuário solicitando que ele defina uma nota entre 1 e 10 (intervalo discreto) representando o quão bom é aquela solução. Essa nota poderá representar, por exemplo, que o usuário está plenamente satisfeito com os requisitos selecionados atribuindo uma nota 10 ou dizer que não está satisfeito com o release atribuindo uma nota 1. Como a preferência do usuário é solicitada na função objetivo, não é possível perguntar para o usuário a nota de todas as soluções geradas pois isso causaria fadiga humana devida à quantidade de elevada avaliações. Por isso, um modelo de regressão linear múltipla foi utilizado como forma de predizer a nota do usuário dado um conjunto de requisitos. O modelo é descrito como: nota(r ) = w 0 + n i=0 w i v i (4.10) onde w i é o peso do requisito i inicializado com 1/n sendo n o número de requisitos, v i tem o valor 1 se no release R o requisito i foi marcado como selecionado e 0 caso contrário. Como forma de diminuir o número de interações com o usuário, o próprio algoritmo irá calcular o momento de fazer as interações. Por exemplo, quando o algoritmo perceber que está gerando soluções com notas baixas (por exemplo, menor do que 5), ele irá interagir com o usuário em um intervalo menor entre as interações. Caso as notas fornecidas pelo usuário sejam altas (por exemplo, maior do que 5), o algoritmo irá interagir em um intervalo maior entre as interações.

67 66 O Algoritmo 6 representa essa abordagem: Algoritmo 6: Algoritmo ACO Interativo por Avaliação Preditiva do Release Entrada: Conjunto de Requisitos Saída: Release selecionado início Inicialize os Pesos; enquanto não atingir o critério de parada faça se a iteração é interativa então Seleciona a melhor solução da iteração; Apresenta ao usuário; O usuário avalia com uma nota a solução apresentada; se o usuário estiver satisfeito com a solução então finalizar processo de busca; fim Calcula os coeficientes de regressão; Ajusta os pesos; fim Constrói as Soluções; Aplica Busca Local (Opcional); Atualiza os Feromônio; fim fim A seguir serão apresentadas as vantagens e desvantagens desta abordagem: Vantagens a) Usuário não necessita ter conhecimento sobre o algoritmo; b) Não há conflito entre as preferências; c) Não há repetição de preferências - Mesmo que o usuário avalie mais de uma vez o mesmo release, o resultado gerado tende a ser melhor. Desvantagens a) Sensível a quantidade de interações - O algoritmo pode não gerar boas soluções com poucas interações;

68 67 b) Requer alto esforço cognitivo do usuário na hora de expressar as suas preferências; c) Não é possível desfazer as preferências já definidas Interação por Avaliação do Release Como visto na Subseção 4.2.5, o usuário tem a possibilidade de analisar um release selecionado e fazer a sua avaliação usando notas para denotar o quão bom é aquele release para ele. Essa nota é incorporada em uma função de regressão que irá simular as notas do usuário nas iterações não-interativas. Na Interação por Avaliação do Release as notas fornecidas pelo usuário são utilizadas como forma de aumentar ou diminuir a probabilidade de um requisito ser selecionado pela formiga. A nota que o usuário utilizou para avaliar um release é utilizada para calcular a probabilidade de todos os requisitos. Quanto maior a probabilidade, maior será a chance desse requisito aparecer na vizinhança opcional; caso contrário, quanto menor a probabilidade, menor a chance do mesmo aparecer na vizinhança opcional. Como as preferências do usuário são incorporadas na composição da vizinhança opcional da formiga, um requisito com baixa probabilidade pode nunca ser selecionado para o release gerando assim uma abordagem onde as preferências do usuário podem se comportar como restrição do problema. Seja P = {p 1, p 2,..., p n } o vetor responsável por guardar a probabilidade de um requisito i ser escolhido para compor a vizinhança opcional da formiga. O vetor P é atualizado de acordo com a nota recebida pelo usuário seguindo a fórmula de atualização: P j = (1 π) P j + π p (4.11) onde π é a taxa de atualização da probabilidade, ou seja, o valor que será utilizado para aumentar ou diminuir a probabilidade P j e p é a função de reforço. Inicialmente todos os requisitos possuem a probabilidade de serem escolhidos definida em 50%. Sempre que o usuário interagir com a busca, todos os requisitos terão a sua probabilidade reduzida por π e somente aqueles que foram selecionados terão a sua probabilidade

69 68 reforçada de acordo com a nota dada. A função de reforço é dada pela regra: p = T E Se r j R 0 caso contrário (4.12) onde E representa a maior nota que o usuário pode fornecer e T representa a nota do usuário fornecida para o release R. Assim, quando uma formiga k está no vértice i e vai para o vértice j, ela escolhe estocasticamente o vértice seguinte de acordo com o conjunto vis k (i) definido como: vis k (i) = { j e f f (R ) + e j B e p < P j } (4.13) onde e f f (R ) é o custo dos requisitos já selecionados, e j é o custo do requisito j, p um número gerado aleatoriamente (0 < p < 1) e P j a probabilidade do requisito j está na vizinhança opcional. Nessa abordagem, uma solução aleatória é gerada no início para que antes de executar a primeira iteração, o algoritmo já tenha conhecimento prévio das preferências do usuário e assim aumentar a chance de alguns requisitos fazerem parte da vizinhança opcional.

70 69 O algoritmo gerado pela proposta pode ser definido como: Algoritmo 7: Algoritmo ACO Interativo por Avaliação do Release Entrada: Conjunto de Requisitos Saída: Release selecionado início Gera um release aleatório; Apresenta o release para avaliação do usuário; O usuário avalia o release gerado; Atualiza o vetor de probabilidades; enquanto não atingir o critério de parada faça se a iteração é interativa então Seleciona o release ótimo; Apresenta o release para avaliação do usuário; O usuário avalia o release gerado; Atualiza o vetor de probabilidades; fim Constrói as Soluções; Aplica Busca Local (Opcional); Atualiza o Feromônio; fim fim A seguir serão apresentadas as vantagens e desvantagens desta abordagem: Vantagens a) Usuário não necessita ter conhecimento sobre o algoritmo; b) Não é sensível a quantidade de interações - O algoritmo consegue gerar boas soluções mesmo com pouca interação; c) Não há repetição de preferências; d) Não há conflito entre as preferências. Desvantagens a) Requer alto esforço cognitivo do usuário na hora de expressar as suas preferências;

71 70 b) Não é possível desfazer as preferências já definidas Interação por Substituição de Requisitos No processo de busca interativa, o usuário pode querer deixar a responsabilidade de gerar boas soluções com o algoritmo e querer interagir somente no final do processo, fazendo uma avaliação sobre a solução gerada e se não for do seu agrado, alterar a solução. Nessa abordagem interativa, o usuário expressa as suas preferências no final do processo de busca onde ele tem a possibilidade de alterar a solução final gerada pelo algoritmo adicionando ou removendo elementos de acordo com as suas preferências. Como forma de ajudar o usuário no processo de alteração da solução, é fornecido a ele um conjunto composto por todos os requisitos que foram os mais visitados pelas formigas e que não foram selecionados por elas para fazerem parte da solução. Através deste mecanismo, o usuário poderá adicionar ou remover requisitos da solução final, lembrando que o processo de adição de requisitos deve respeitar a restrição do problema, ou seja, para adicionar um requisito, o usuário deverá remover um ou mais requisitos se for necessário para que não extrapole o orçamento máximo definido. Seja Q = {q 1,q 2,...,q n } o conjunto responsável por guardar a quantidade de vezes que o requisito i foi incluindo em uma solução R gerada pela formiga. O algoritmo dessa

72 71 abordagem pode ser descrito como: Algoritmo 8: Algoritmo ACO Interativo por Substituição de Requisitos Entrada: Conjunto de Requisitos Saída: Release selecionado início enquanto não atingir o critério de parada faça Constrói as Soluções; Incrementa o contador de cada requisito; Aplica Busca Local (Opcional); Atualiza o Feromônio; fim Remove do conjunto Q os requisitos da melhor solução; Ordena o conjunto Q; Apresenta o release selecionado e o conjunto Q ao usuário; Usuário manipula a solução de acordo com suas preferências adicionando ou removendo requisitos do release. fim A seguir serão apresentadas as vantagens e desvantagens desta abordagem: Vantagens a) Usuário não necessita ter conhecimento sobre o algoritmo; b) Não é sensível a quantidade de interações - O algoritmo consegue gerar boas soluções mesmo com pouca interação; c) Não há repetição de preferências; d) É possível desfazer as preferências já definidas. Desvantagens a) Requer alto esforço cognitivo do usuário na hora de expressar as suas preferências; b) Conflito entre as preferências.

73 CONSIDERAÇÕES FINAIS Este capítulo apresentou as característica de interação que são identificadas quando o algoritmo ACO interativo é aplicado ao NRP, mostrando os seus tipos e definições. São elas: Momento da Interação, o Tipo de Informação Requerida do Usuário, a Forma de Incorporação da Informação, a Quantidade de Interações e o Critério de Parada. Em seguida, algumas abordagens interativas foram desenvolvidas tomando como base as características levantadas e apresentadas mostrando a sua modelagem, algoritmo, vantagens e desvantagens. Como forma de resumir as características das abordagens, a Tabela 4 apresenta o resumo das vantagens e desvantagens encontradas em cada algoritmo. Dentre as abordagens propostas, uma foi escolhida para a realização de um estudo empírico. No próximo capítulo serão apresentados os resultados desse estudo.

74 73 Tabela 4 Síntese das Vantagens e Desvantagens das Abordagens Interativas propostas Abordagem Interativa Conhecimento Sobre o Algoritmo Interação por Configuração de Parâmetros Interação por Preferência no Release Interação por Comparação Par-a-Par Interação por Classificação de Requisitos Interação por Avaliação Preditiva do Release Interação por Avaliação do Release Interação por Substituição de Requisitos Esforço Requerido para Expor as Preferências Sensível a Quantidade de Interações Conflito entre as Preferências Repetição de Preferências Sim Alto Sim Não Não Sim Não Alto Não Não Não Sim Não Baixo Não Sim Sim Não Não Alto Não Não Não Não Não Alto Sim Não Não Não Não Alto Não Não Não Não Não Alto Não Sim Não Sim Desfazer as Preferências Fonte: Elaborada pelo autor.

75 74 5 ESTUDO EMPÍRICO No capítulo anterior, diversas abordagens interativas foram propostas mas, em geral, a única forma para conhecer o desempenho de um algoritmo ACO interativo para resolver o Problema do Próximo Release é experimentalmente. Sabendo disso, escolheu-se a abordagem interativa por Preferência no Release descrita na Seção onde o algoritmo gerado foi chamado de iaco. Esta abordagem foi escolhida por ser as que utiliza mais características de interação entre as abordagens propostas. Neste capítulo são expostos os resultados do estudo empírico realizado com a abordagem interativa selecionada. Inicialmente são apresentadas as questões de pesquisas que basearam este estudo seguidas pelas métricas utilizadas para responder cada uma. Posteriormente são apresentadas as configurações, resultados e discussões do experimento. Por fim, são apresentadas as ameaças a validade e algumas considerações finais. 5.1 QUESTÕES DE PESQUISAS Buscando verificar se a abordagem selecionada oferece meios suficientes para incluir a opinião humana nas soluções geradas pelo iaco e, com isso, gerar soluções que contenham as preferências do usuário, os experimentos descritos neste capítulo objetivam responder às três questões de pesquisas (RQs) descritas a seguir: RQ1: O algoritmo iaco consegue gerar soluções que contenham mais preferências do usuário do que um algoritmo não interativo? RQ2: Qual é o impacto no score das soluções geradas pelo iaco na tentativa de atender às preferências do usuário? RQ3: Qual a influência que a função score exerce sobre a função pre f quando altera-se o peso dos parâmetros na função objetivo? Para responder as questões de pesquisa, testes foram realizados utilizando simuladores e seres humanos. Os testes onde os simuladores foram utilizados são chamados de Validação Automática; testes onde os seres humanos foram utilizados são chamados de Validação Manual. Para a validação automática, foi desenvolvido um simulador com o propósito de representar um possível perfil de avaliação, tal qual explorado em (ARAÚJO; PAIXÃO, 2014). Tal simulador é responsável por gerar uma solução-alvo, ou seja, um subconjunto de requisitos que o usuário consideraria como um ótimo release. Assim, quando houver a necessidade de

76 75 saber se determinado requisito deve estar ou não presente no próximo release, basta consultar a solução-alvo previamente elaborada e verificar sua presença. É importante notar que o principal propósito de tal componente não é a representação fiel de um ser humano e sim, demonstrar sua influência no processo de busca. Para a validação manual, uma interface de usuário foi desenvolvida e um grupo de usuários da ferramenta foi convidado a auxiliar no processo de seleção dos requisitos e, consequentemente, emitir suas respectivas preferências sobre quais requisitos deveriam estar ou não no próximo release. 5.2 MÉTRICAS Para responder a RQ1, utilizaram-se os métodos de validação manual e automática. Para isso, a métrica preferenciasatendidas foi desenvolvida com o propósito de comparar as soluções geradas pela abordagem interativa e não interativa. Esta métrica representa a quantidade de preferências atendidas na solução sobre a quantidade de preferências disponíveis no vetor de preferências P (Equação 4.1). Neste caso, se a métrica retornar 0 significa que nenhuma das preferências definidas pelo usuário foram atendidas. Caso contrário, se a métrica retornar 1, significa que todas as preferências do usuário foram atendidas. Esta métrica pode ser definida como: pre f erenciasatendidas(r,p) = ri R 1 + ri / R 1 p i =1 p i = 1 1 r i R p i =1 ou p i = 1 (5.1) Com relação a resposta da RQ2, também utilizaram-se ambos os métodos de validação automática e manual. Esta questão tem como objetivo avaliar a perda ou impacto no score gerada pelo iaco e, para isso, a métrica Fator de Redução foi utilizada. Ela representa a porcentagem de perda, em termos de score(), da solução gerada pelo iaco em comparação com a solução gerada por um método não interativo. Neste caso, se o valor da métrica for 0 significa que a solução gerada pelo iaco é exatamente a solução gerada pelo método não interativo. Caso contrário, se a métrica retornar 1, a solução gerada tem score = 0, ou seja, nenhum requisito foi selecionado. Esta métrica pode ser definida como: f atordereducao(r ) = 1 score(r iaco ) score(r NaoInterativo ) (5.2)

77 76 Por fim, para responder a RQ3, os pesos referentes a função score (γ) e a função pre f (δ ) foram variados no intervalo [0,1] a fim de verificar a influência empírica de cada componente na função objetivo do problema. Para avaliar os resultados, as métricas f atordereducao e pre f erenciasatendidas foram utilizadas. 5.3 CONFIGURAÇÕES EXPERIMENTAIS Para realizar a validação manual, um grupo de 11 participantes das mais diversas área do desenvolvimento de software foi convidado a participar deste estudo empírico. Os participantes possuem entre 6 meses e 14 anos de experiência no mercado de trabalho gerando um total de 84,5 e média 7,68 anos de experiência na área. Todos os participantes possuem ensino superior completo sendo que 7 possuem Pós-Graduação concluída e 4 possuem Pós-Graduação em andamento até a realização deste estudo. Informações detalhadas sobre os participantes estão relatadas no Apêndice A. A proposta foi avaliada em três datasets, sendo que os dois primeiros dataset s são baseados em aplicações reais e foram disponibilizados por Karim e Ruhe (2014). O terceiro dataset foi gerado a partir de valores aleatórios. Os datasets são caracterizados como: a) O primeiro dataset (dataset-1) é baseado no Microsoft Word (processador de texto) e é constituído por 50 requisitos e 4 clientes; b) O segundo dataset (dataset-2) é oriundo do software ReleasePlanner TM. O ReleasePlanner TM é um sistema proprietário de suporte a decisão utilizado na elaboração de estratégias e planejamento operacional de releases (RUHE, 2003). Esse dataset é composto por 25 requisitos e 9 clientes; c) O terceiro dataset (rand-100) possui 100 requisitos e 4 clientes com informações geradas aleatoriamente. A validação manual foi realizada utilizando o dataset-1 e o dataset-2. A escolha destes dataset s se deve a disponibilidade da descrição dos requisitos o que, para alguns usuários, significou um elemento fundamental como critério de decisão. Nesta validação o algoritmo apresenta ao usuário a melhor solução encontrada a cada 10 iterações. Neste momento, o usuário tem a possibilidade de fazer alterações nas preferências e continuar a busca por novas soluções ou ainda, tem a possibilidade de encerrar o processo quando estiver satisfeito com a solução apresentada. Para realizar a validação manual, uma interface de usuário foi desenvolvida em prol

78 77 de uma melhor usabilidade no processo de seleção dos requisitos (veja a Figura 19). Nela, é possível visualizar os requisitos que estão disponíveis para a seleção (linhas brancas) e os requisitos que foram selecionados pelo iaco para o próximo release (linhas verdes). Quando o usuário está satisfeito com a solução apresentada, ele pode clicar no botão stop, caso contrário, ele pode fazer alterações nas suas preferências (expressando se gostaria ou não de ver determinado requisito no próximo release) e clicar no botão continue para gerar novas soluções. Figura 19 Interface de Usuário desenvolvida para o Estudo Empírico Fonte: Elaborada pelo Autor A validação manual foi dividida em três fases. Na primeiro fase, buscando mitigar a influência do fator desconhecimento da ferramenta nos resultados gerados pelo estudo empírico, o usuário foi convidado a utilizar a ferramenta utilizando uma instância de teste com 10 requisitos buscando entender e tirar todas as suas dúvidas sobre o processo. Na segunda fase, o usuário foi convidado a analisar a solução gerada pelo algoritmo não interativo, buscando observar se a solução gerada contém alguns dos requisitos que ele julgava importantes para serem incluídos no próximo release. Na terceira e última fase, o usuário foi convidado a interagir