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 OLIVEIRA PINHEIRO

UMA ABORDAGEM DE OTIMIZAÇÃO DINÂMICA PARA O PROBLEMA DE

AGENDAMENTO DE TAREFAS EM PROJETOS DE SOFTWARE

FORTALEZA – CEARÁ
2017
 THIAGO OLIVEIRA PINHEIRO

UMA ABORDAGEM DE OTIMIZAÇÃO DINÂMICA PARA O PROBLEMA DE

AGENDAMENTO DE TAREFAS EM PROJETOS DE SOFTWARE

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 Tec-
nologia 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Á
2017
 Dados Internacionais de Catalogação na Publicação

Universidade Estadual do Ceará

Sistema de Bibliotecas

Pinheiro, Thiago Oliveira.

Uma abordagem de otimização dinâmica para o
problema de agendamento de tarefas em projetos de
software [recurso eletrônico] / Thiago Oliveira
Pinheiro. - 2017.
1 CD-ROM: il.; 4 ¾ pol.

CD-ROM contendo o arquivo no formato PDF do

trabalho acadêmico com 72 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, 2017.
Área de concentração: Ciência da Computação.
Orientação: Prof. Dr. Jerffeson Teixeira de Souza.

1. Engenharia de Software Baseada em Busca. 2.

Agendamento de Tarefas em Projetos de Software. 3.
Otimização Dinâmica. 4. Algoritmo Genético. I. Título.
À toda minha família, pelo suporte e apoio que
tive.
 AGRADECIMENTOS

À minha família, por todo o seu suporte e apoio em todos os momentos difíceis e por terem me
ajudado a construir o meu caráter e chegar aonde estou.
Aos meus companheiros de trabalho, que estiveram ao meu lado durante estes anos que se
passaram.
A esta universidade, seu corpo docente, direção e administração que oportunizaram a janela de
onde hoje vislumbro um horizonte superior.
Aos amigos do GOES (Grupo de Otimização em Engenharia de Software), pelo companheirismo,
apresentações e debates técnicos que foram de fundamental importância para construção do
conhecimento que adquiri durante esta jornada.
Agradeço a todos os professores por proporcionarem a mim o conhecimento não apenas racional,
mas a manifestação do caráter e afetividade da educação no processo de formação profissional,
em especial aos mestres Valdísio Viana, Paulo Henrique Maia, Leonardo Sampaio, Gustavo
Lima de Campos e Mariela Cortés.
Ao meu orientador professor Jerffeson Teixeira por toda instrução técnica, inspiração e principal-
mente pelos demais conhecimentos.
Aos grandes amigos que tenho, por compreenderem minhas muitas ausências neste período e
pelos bons momentos que passamos juntos.
A todos, que direta ou indiretamente, contribuíram para a realização deste trabalho.
“Através dos séculos existiram homens que de-
ram os primeiros passos, por novas estradas, ar-
mados com nada além de sua própria visão.”
(Ayn Rand)
 RESUMO

A Engenharia de Software preconiza uma série de boas práticas para que o desenvolvimento e
manutenção de software possa fluir de maneira organizada, a fim de melhorar a produtividade e a
qualidade dos sistemas desenvolvidos. Entretanto devido ao imediatismo de resposta exigido por
algumas organizações, muitas dessas práticas são ignoradas em prol de rápidas validações ou
novas funcionalidades críticas que surgem a todo momento. A consequência deste ato pode ser
muito grave, a ponto de comprometer o crescimento da própria organização. Embora este cenário
não seja desejado, ele se repete com grande frequência em muitas organizações. Sendo assim, se
faz necessário encontrar uma maneira de se trabalhar a distribuição de tarefas de modo eficaz,
procurando responder de maneira rápida e continuar agregando valor à organização. Contudo,
montar o planejamento de execução das tarefas de maneira eficiente é um esforço desafiador,
pois é preciso analisar uma quantidade muito grande de possibilidades. Este cenário se torna
mais desafiador quando a demanda por novas tarefas é constante.
Deste modo, a Engenharia de Software Baseada em Busca surge como uma alternativa para
solucionar o problema, aplicando técnicas de otimização baseada em busca. Este trabalho
apresenta uma proposta para a solução do Problema de Agendamento em Projetos de Software,
utilizando informações referentes à experiência do time envolvido e o nível de habilidades
necessárias para a execução das tarefas, determinando a melhor distribuição de tarefas entre a
equipe, a fim de minimizar o tempo total de execução em um determinado período. A proposta
deste trabalho ainda apresenta um aspecto reativo, onde a busca pela solução deve se adaptar às
mudanças ocorridas na instância estudada. Para tanto, uma formulação dinâmica foi elaborada
para o referido problema e um Algoritmo Genético foi adaptado para geração das soluções.
Considerando instâncias artificiais, a abordagem foi avaliada em vários cenários de execução
diferentes. Demonstrou-se, empiricamente, que fazendo uso da representação de solução adotada
neste trabalho, o reaproveitamento de soluções em uma abordagem dinâmica é notável em
situações onde novas pessoas são adicionadas à instância estudada. Entretanto ao se adicionar
um lote de novas tarefas, o reaproveitamento não apresenta ganhos significativos em relação a
uma abordagem tradicional.

Palavras-chave: Evolução de Software. Alocação de Tarefas. Problemas de Otimização Dinâ-

micos. Algoritmos Genéticos. Problema de Agendamento em Projetos de Software. Engenharia
de Software Baseada em Busca.
 ABSTRACT

The Software Engineering recommends a number of good practices such that the development
and maintenance of software can flow in an organized way, focusing to improve productivity
and quality of generated software. However, due to the required short term response time of
some organizations, many of these practices are ignored in favor of quick validations or critical
new features that arise continually. The price to be paid in situations like this can be very high,
possibly compromising the organization’s growth. Although this scenario is not desired, it is
repeated frequently in many organizations. Therefore, it is necessary to find a way to distribute
tasks effectively, seeking to respond quickly and keep adding value to the organization. However,
build an efficient plan for tasks execution is challenging. There’s a large amount of possibilities.
to analyse in a scenario where demand for new tasks is continuous. This scenario becomes even
more challenging when the demand for new tasks is continuous.
Thus, the Search Based Software Engineering is an alternative to work on the problem by
applying search-based optimization techniques. This work presents a proposal to the Software
Project Scheduling Problem, using information regarding the experience of the involved team and
nature of the tasks to be performed, determining the best distribution of tasks among the team, in
order to minimize the total execution time within a given period. The proposal of this work also
presents a reactive aspect, where the execution of the solution must adapt the changes occurred in
the studied instance. For this, a dynamic formulation was elaborated for the mentioned problem
and a Genetic Algorithm was adapted to generate the solutions. Considering artificial instances,
the approach was evaluated in several different scenarios. It has been empirically demonstrated
that using the solution representation adopted in this work, the reuse of solutions in a dynamic
approach is remarkable in situations where new employee are added to the studied instance.
However, when a lot of new tasks are added, reuse does not present significant gains compared
to a traditional approach.

Keywords: Software Evolution. Tasks Allocation. Dynamic Optimization Problems. Genetic

Algorithms. Software Project Scheduling Problem. Search Based Software Engineering.
 LISTA DE ILUSTRAÇÕES

Figura 1 – Modelo Espiral de Desenvolvimento e Evolução . . . . . . . . . . . . . 22

Figura 2 – Distribuição de esforço de manutenção . . . . . . . . . . . . . . . . . . 23
Figura 3 – Alocação da Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figura 4 – Fluxograma de um AG . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figura 5 – Seleção pela Roleta Simples . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 6 – Crossover de um ponto . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figura 7 – Mutação Simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figura 8 – Número de publicações de SBSE por ano . . . . . . . . . . . . . . . . . 33
Figura 9 – Número de publicações de SBSE por Área . . . . . . . . . . . . . . . . 35
Figura 10 – Planejamento inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 11 – Planejamento alterado . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 12 – Grafo com Precedência entre Tarefas . . . . . . . . . . . . . . . . . . . 49
Figura 13 – Evolução fitness médio no cenário de acréscimo de pessoas . . . . . . . 57
Figura 14 – Evolução fitness médio no cenário de acréscimo de tarefas . . . . . . . 58
Figura 15 – Relação entre ARRt e stabtF,EA . . . . . . . . . . . . . . . . . . . . . . . . 60
Figura 16 – Cenários de execução com 25 tarefas. . . . . . . . . . . . . . . . . . . . 61
Figura 17 – Cenários de execução com 50 tarefas. . . . . . . . . . . . . . . . . . . . 62
Figura 18 – Cenários de execução com 100 tarefas. . . . . . . . . . . . . . . . . . . 63
 LISTA DE TABELAS

Tabela 2 – Amostra de valores escalados . . . . . . . . . . . . . . . . . . . . . . . . 42

Tabela 3 – Média e desvio padrão de fitness ao final da primeira e segunda modi-
ficação dos cenários de execução de i_25_10, valores do teste Â12 entre
cada configuração de µ com relação à configuração µ = 0 (abordagem
tradicional), e indicação de diferença estatística ao se variar µ em rela-
ção a µ0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Tabela 4 – Valores ARRt calculados por taxa de µ. . . . . . . . . . . . . . . . . . . 59
 LISTA DE QUADROS

Quadro 1 – Instâncias do Experimento . . . . . . . . . . . . . . . . . . . . . . . . 48

Quadro 2 – Legenda do Quadro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
 LISTA DE ABREVIATURAS E SIGLAS

ACO Ant Colony Optimization

AG Algoritmo Genético
CE Computação Evolucionária
CP Constraint Programming
DCOP Dynamic Constrained Optimization Problems
DOP Dynamic Optimization Problems
EDO Evolutionary Dinamic Optimization
ES Engenharia de Software
GRASP Greedy Randomized Search Procedures
IA Inteligência Artificial
OD Otimização Dinâmica
PBIL Population-Based Incremental Learning
PMX Partially Matched Crossover
SBSE Search Based Software Engineering
SPMP Software Project Management Problem
SPSP Software Project Scheduling Problem
TI Tecnologia da Informação
TR Tratamento de Restrições
 LISTA DE SÍMBOLOS

α Nível de significância em testes estatísticos

µ Percentual de propagação genética

M Diferença estatística insignificantemente maior

O Diferença estatística insignificantemente menor

N Diferença estatística significantemente maior

H Diferença estatística significantemente menor

 SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1 MOTIVAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 ORGANIZAÇÃO DO TRABALHO . . . . . . . . . . . . . . . . . . . . . 18
2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . 20
2.1 ENGENHARIA DE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1 Evolução de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.2 Manutenção de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.3 Cronograma do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 OTIMIZAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Otimização Matemática . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.2 Otimização Dinâmica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.3 Metaheurísticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.3.1 Computação Evolutiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.3.2 Algoritmos Genéticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 ENGENHARIA DE SOFTWARE BASEADA EM BUSCA . . . . . . . . . 32
3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . 36
3.1 TRABALHOS SOBRE OTIMIZAÇÃO DINÂMICA . . . . . . . . . . . . . 36
3.2 TRABALHOS SOBRE AGENDAMENTO DE TAREFAS . . . . . . . . . . 37
4 ABORDAGEM PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1 ESTIMATIVA DE ESFORÇO . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 AGENDAMENTO DE TAREFAS . . . . . . . . . . . . . . . . . . . . . . 42
4.3 REPRESENTAÇÃO DA SOLUÇÃO . . . . . . . . . . . . . . . . . . . . . 44
5 ESTUDO EMPÍRICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1 QUESTÕES DE PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.1 Instâncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.2 Técnica de Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.3 Métricas de Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.3.1 Métricas utilizadas em EDOs . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2.3.2 Análise Estatistíca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3 RESULTADOS E ANÁLISES . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.1 Comparativo entre abordagem tradicional e dinâmica . . . . . . . . . . 55
5.3.2 Análise da evolução da performance após mudanças . . . . . . . . . . . 57
5.3.3 Outros Cenários de Execução . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4 AMEAÇAS À VALIDADE . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1 CONTRIBUIÇÕES DO TRABALHO . . . . . . . . . . . . . . . . . . . . 66
6.2 LIMITAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.3 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
 16

1 INTRODUÇÃO

Em muitos cenários, o desenvolvimento de um software não é finalizado após a

entrega ao cliente. Após a implantação de uma versão inicial em ambiente de produção, algumas
informações sobre a atual operação do sistema são colhidas. Estas informações são analisadas e
podem provocar grandes alterações no foco e planejamento inicial do projeto.
Este processo de constantes incrementos e evolução pode ocasionalmente inserir
falhas no software desenvolvido. Dependendo da cultura organizacional e das medidas tomadas
na evolução do software, a quantidade e criticidade de falhas pode variar bastante. Conforme
o tamanho e escopo do sistema desenvolvido evoluem, ele se torna mais complexo e sua
manutenção e evolução mais desafiadoras. Em situações de entrega contínua, é comum ter que
decidir entre a entrega de uma nova funcionalidade ou a correção de um problema antigo, seja
ele um bug ou um débito técnico. Em muitos cenários, esta tomada de decisão é um processo
constantemente repetido, o que torna o fato de replanejar a execução das demandas um processo
contínuo e oneroso.

1.1 MOTIVAÇÃO

Segundo Sommerville (2001), existe uma necessidade constante e inevitável de

evolução por parte de todo software que espera manter-se ativo por um longo período de
tempo. As organizações investem grandes quantias de dinheiro em seus softwares e se tornam
completamente dependentes desses sistemas, que se tornam ativos de negócios críticos.
Com a necessidade de responder de forma ágil às mais variadas demandas entre
os projetos organizacionais, muitas vezes não há espaço para boas práticas de Engenharia de
Software, o que gera uma série de problemas como bugs em diversas áreas do software, o acúmulo
de débitos técnicos, reimplementação de diversas funcionalidades, descuido no gerenciamento
de recursos, falta de automação de diversos processos, problemas com o empacotamento e a
distribuição de releases dos softwares, entre outros.
Mesmo com tantos problemas relacionados a software sendo gerados devido ao
crescimento do negócio, em um momento inicial estes problemas se pagam por permitirem
uma rápida evolução da operação da organização, entretanto em um determinado momento
eles se tornarão tão problemáticos e caros que o próprio crescimento da organização pode ser
comprometido.
A manutenção e o suporte de software são atividades contínuas que ocorrem por todo
 17

o ciclo de vida de um aplicativo. Durante essas atividades, defeitos são corrigidos, aplicativos
são adaptados a um ambiente operacional ou de negócio em mutação, melhorias são implementa-
das por solicitações dos interessados e é fornecido suporte aos usuários quando integram um
aplicativo em seu fluxo de trabalho pessoal ou corporativo (PRESSMAN, 2011). Atividades
de manutenção são comuns no dia a dia de uma equipe de desenvolvimento e operação de
sistemas. Cabe ao gerente responsável encontrar a melhor maneira de resolvê-las, considerando
suas criticidades e os recursos humanos disponíveis, alocando as pessoas mais adequadas para a
realização de cada tarefa e satisfazendo as prioridades estratégicas da organização.
Sendo assim, se faz necessária uma metodologia eficaz para planejamento e repla-
nejamento de tarefas, especialmente neste cenário de demandas contínuas. Este planejamento
deve estar alinhado aos objetivos da organização e deve ser feito de modo inteligente, onde a
execução de tarefas seja o mais eficaz e eficiente possível e a entrega de valor para a organização
seja maximizada.
Técnicas computacionais para planejar projetos de software são um passo crucial no
processo de desenvolvimento de software dentro de um setor altamente competitivo. O Problema
de Agendamento de Projetos de Software (Software Project Scheduling Problem, ou SPSP)
relaciona-se com a decisão de quem faz o que durante a vida útil de um projeto de software,
envolvendo principalmente atividades intensivas de recursos humanos (LUNA et al., 2014).
Xiao, Ao e Tang (2013) afirmam que o problema SPSP é NP-Difícil e possui questões
de otimização combinatória extremamente difíceis, além de ser um processo exaustivo e propenso
a erros para serem feitos por seres humanos.
A Engenharia de Software Baseada em Busca, ou Search Based Software Engineering
(SBSE), propõe o uso de técnicas de busca para resolver problemas complexos em Engenharia
de Software (HARMAN; JONES, 2001). Atividades de SPSP são problemas combinatórios que
apresentam um grande espaço de busca a ser explorado, o que as tornam elegíveis para uma
abordagem via SBSE.

1.2 OBJETIVOS

1.2.1 Objetivo Geral

O objetivo geral deste trabalho é propor uma abordagem para solucionar o problema
de agendamento de execução de tarefas em projetos de software em um ambiente com demanda
contínua de tarefas, levando em consideração a prioridade e precedência entre elas de modo
 18

que o tempo de execução do total seja o menor possível. Para atingir este objetivo é necessário
alocar tarefas para as pessoas mais aptas a realizá-las, respeitando as restrições mencionadas.
A abordagem proposta neste trabalho possui uma característica dinâmica, pois deve adaptar a
solução corrente à uma nova instância (caracterizada pelo acréscimo de novas tarefas ou recursos).
Espera-se que a abordagem dinâmica proposta contribua para que as tarefas sejam concluídas o
mais brevemente possível. Além disso deseja-se observar se o tempo de convergência da solução
nesta abordagem pode ser menor que o tempo de convergência encontrado em uma abordagem
tradicional, onde não há aproveitamento (ou adaptação) das soluções anteriores.

1.2.2 Objetivos Específicos

Para alcançar o objetivo geral deste trabalho, foram definidos os seguintes objetivos
específicos:
a) Selecionar um modelo matemático que estime o tempo de realização de tarefas
por determinada pessoa;
b) Fazer um comparativo entre a abordagem tradicional e dinâmica com base nos
dados coletados do experimento;
c) Propor uma representação da solução do problema em uma codificação aplicável
para Algoritmos Genéticos e que possam ser utilizadas no processo de adaptação
da solução;
d) Desenvolver uma ferramenta onde será possível visualizar as soluções obtidas e
executar uma série de simulações em diferentes instâncias;
e) Testar o comportamento da abordagem dinâmica fazendo uso de diferentes taxas
de reaproveitamento de soluções.

1.3 ORGANIZAÇÃO DO TRABALHO

O conteúdo deste trabalho está organizado em seis capítulos, incluindo a presente

introdução. Cada capítulo é apresentado a seguir:
O Capítulo 2 discorre sobre o referencial teórico em que este trabalho se fundamenta.
Inicialmente apresenta-se conceitos sobre as áreas da Engenharia de Software que motivaram
esta pesquisa: Evolução de Software, Manutenção de software e Cronograma de Projetos. Além
disso são apresentados os tópicos sobre otimização dinâmica, e otimização matemática, com um
foco em meta heurísticas, onde é descrito o funcionamento de Algoritmos Genéticos.
 19

O Capítulo 3 traz os principais trabalhos relacionados às ideias centrais desta pes-

quisa. Trabalhos que discorrem sobre conceitos de otimização dinâmica, técnicas utilizadas
e métricas de avaliação utilizadas para medir a eficiência dos mesmos são apresentados neste
capítulo. Em seguida, são apontados trabalhos relacionados ao agendamento de tarefas, onde se
discute técnicas e modelagens utilizadas em situações semelhantes à abordada neste trabalho.
No Capítulo 4 é apresentado a abordagem levantada neste trabalho sobre o Agenda-
mento de Tarefas em Projetos de Software em um contexto Dinâmico. Descreve-se os principais
atributos considerados pela abordagem e um método de estimativa de tempo de execução é
apresentado. Em seguida, é apresentado o modelo que descreve o objetivo e as restrições
consideradas nesta abordagem. Por fim, é descrito o modelo de representação e soluções do
problema.
O Capítulo 5 descreve detalhes sobre o estudo empírico realizado para avaliar a
abordagem proposta. Encontram-se detalhes acerca das instâncias utilizadas no estudo, os
detalhes de parâmetros utilizados pela abordagem, as métricas de avaliação utilizadas no trabalho
e os resultados coletados após os experimentos conduzidos.
Por fim, no Capítulo 6 são apresentadas as considerações finais sobre o trabalho,
algumas limitações encontradas e perspectivas de evolução sobre a pesquisa são levantadas.
 20

2 FUNDAMENTAÇÃO TEÓRICA

2.1 ENGENHARIA DE SOFTWARE

A Engenharia de Software (ES) é uma disciplina da engenharia cujo o foco está em

todos os aspectos da produção de software, desde os estágios iniciais da especificação do sistema
até a sua manutenção, quando o sistema já está sendo usado (SOMMERVILLE, 2001). Dentre
estes aspectos incluem-se áreas de especificação, desenvolvimento, manutenção e evolução de
sistemas de software. Além disso, a ES faz uso de inúmeras ferramentas e práticas de gerência
de projetos objetivando a melhora da produtividade e qualidade de produtos de software.
Desenvolver (e manter) um software de alta qualidade é uma tarefa desafiadora pois
é preciso cumprir uma série de atributos que demandam planejamento e capacitação para uma
execução eficiente. Dentre os atributos desejados em um software de boa qualidade, Sommerville
(2001) destaca:
a) Manutenibilidade: o software deve evoluir para atender novos requisitos e mu-
danças;
b) Confiável: o software deve ser assertivo e executar suas funções com precisão e
livre de defeitos;
c) Seguro: o software deve manter informações críticas sob sigilo e disponibilizá-las
somente para usuários autorizados;
d) Eficiência: o software não deve desperdiçar os recursos do sistema;
e) Alta disponibilidade: O software deve estar pronto para atender os requisitos a
qualquer momento;
f) Reusável: o software (ou partes dele) deve ser facilmente reusável e poder-se
integrar com outras ferramentas ou processos;
g) Usabilidade: o software deve ser fácil de usar pelos usuários para os quais ele foi
projetado.
Entretanto, o cumprimento destes atributos está sujeito à restrições de prazo e orça-
mento limitado, onde muitas vezes não é possível alcançar a qualidade desejada, especialmente
em softwares que possuem uma abrangência de escopo muito grande e/ou complexo. Dentre os
principais problemas encontrados neste processo estão:
• Falhas nas estimativas de prazo e orçamento;
• Código-fonte de difícil manutenção e evolução;
 21

• Ineficiência no atendimento das funcionalidades solicitadas pelos clientes;

• Projetos incapazes de serem gerenciados.
Visando maximizar a qualidade desejada e minimizar o impacto dos problemas
encontrados no desenvolvimento de softwares, a ES busca reunir conhecimento de boas práticas
para uma condução sistemática desse processo. O processo de software é uma sequência de
atividades que leva à produção de um produto de software. As quatro atividades principais
de um processo de software são: especificação, desenvolvimento, validação e evolução. A
fundamentação base para a realização deste trabalho está no tratamento que a ES dá à evolução
do software.

2.1.1 Evolução de Software

O desenvolvimento de um software, por muitas vezes, não é finalizado na sua entrega.

Após a implantação de um sistema, o mesmo deverá sofrer mudanças para se adaptar a novas
condições ou regras de negócio. Além disto, algumas partes do sistema poderão ser ajustadas para
corrigir erros encontrados em produção ou até mesmo para se adaptar a condições não previstas
inicialmente. Novas ferramentas ou modificações na plataforma em que o software é baseado
podem impactar na produtividade e fluxo de trabalho das equipes envolvidas. Modificações não
funcionais como a otimização de uma funcionalidade, melhoria na segurança e refatorações para
o melhor reaproveitamento de componentes são comuns durante o projeto. Portanto, é bastante
comum que evoluções incrementais surjam durante a vida útil de um sistema.
Neste cenário de modificações constantes, é comum que várias empresas concentrem
seus esforços na manutenção de softwares já existentes, do que na criação de novos softwares.
Erlikh, citado por Sommerville (2001), sugere que 85-90% dos custos organizacionais de
software são custos de evolução. A evolução de um software pode ser iniciada pela mudança de
regras de negócio, notificações de defeitos ou até mesmo por alguma modificação na comunicação
com outros sistemas.
A ES pode ser pensada como um processo em espiral com requisitos, projeto,
implementação e testes se repetindo ao longo da vida útil do projeto, como retratado na figura
1. Uma situação bastante comum em projetos de software é a percepção ou necessidade de
ajustes após a entrega de uma release, todavia, é possível ocorrer a necessidade de evolução
antes mesmo da implantação da versão atual do sistema.
O processo de evolução pode ser adaptado dependendo do tipo de software a ser
 22

Figura 1 – Modelo Espiral de Desenvolvimento e Evolução

Fonte – Sommerville (2001).

mantido, do processo de desenvolvimento adotado por uma organização e da expertise da equipe

encarregada.
As propostas de mudança são responsáveis pelo direcionamento da evolução de um
sistema. Elas podem vir com o requerimento de mudança de requisitos ainda não implementados,
solicitações de novos requisitos, reporte de falhas pelos patrocinadores do projeto e novas ideias
para a melhoria do sistema. Ideias que podem partir da equipe técnica ou até mesmo da equipe
de negócio. Este processo de evolução é cíclico e continua por toda a vida útil do projeto.

2.1.2 Manutenção de Software

Sommerville (2001) afirma que a Manutenção de Software é o processo de modificar

um sistema após a sua entrega. Estas modificações podem ser meras correções de erros de código,
até mudanças para correção de erros de projeto, ou melhorias para corrigir erros de especificação
ou acomodar novos requisitos.
Há três tipos distintos de manutenção de software:
a) Correção de defeitos: engloba erros de código ou erros no projeto do sistema;
b) Adaptação de ambiente: adaptações por conta de mudanças de hardware, plata-
forma de execução;
c) Adição de funcionalidades: adaptações para suprir a demanda de novas funciona-
lidades ou mudança nas regras de negócio.
Apesar dessa classificação, não há de fato uma separação clara entre elas. Um
cenário comum é quando há uma adaptação do software para uma nova plataforma e, novas fun-
cionalidades podem ser criadas (ou melhoradas) de modo que aproveitem os novos componentes
inseridos pelo novo ambiente.
 23

Ainda segundo Sommerville (2001), as pesquisas concordam que a manutenção de

software ocupa uma proporção maior dos orçamentos de TI do que o desenvolvimento. A Figura
2 mostra uma aproximação da distribuição de esforço de manutenção. A figura não é uma regra
geral para todas as organizações, mas a maior parte do orçamento de manutenção é gasto em
novas funcionalidades do que em ajuste de falhas.

Figura 2 – Distribuição de esforço de manutenção

Fonte – Sommerville (2001).

Normalmente é mais caro adicionar novas funcionalidades depois que um sistema

está em operação do que implementar a mesma funcionalidade durante a fase de desenvolvimento.
Sommerville (2001) ainda destaca que as razões para isso são:
a) Estabilidade da equipe: após a fase de desenvolvimento, a equipe costuma a se
separar e uma nova equipe de manutenção é formada. Esta nova equipe precisa
investir muito esforço para entender o sistema, para posteriormente ter segurança
em implementar novas funcionalidades;
b) Práticas ruins de desenvolvimento: a falta de estabilidade da equipe pode provo-
car o não incentivo de boas práticas de programação e manter o software com
um bom nível de manutenibilidade;
c) Inexperiência: equipe de manutenção é geralmente inexperiente ou não está
familiarizada com a aplicação;
d) Idade do sistema: sistemas antigos podem ter sido desenvolvidos sem usar
técnicas modernas de ES, sua documentação pode estar inconsistente com a
versão mais atual, entre outros problemas.
 24

2.1.3 Cronograma do Projeto

Cronograma de Projeto é o processo de decisão de como o trabalho de um projeto

será organizado em tarefas diferentes, como e quando estas tarefas serão executadas. Um período
de tempo é estimado para completar cada tarefa, o esforço requerido e quem irá trabalhar em
cada tarefa. Em termos de planejamento, um cronograma é criado no início de um projeto, mas
costuma ser refinado e modificado no decorrer do projeto. A Figura 3 representa a alocação de
tarefas para os membros de uma equipe.

Figura 3 – Alocação da Equipe

Fonte – Sommerville (2001).

De acordo com Sommerville (2001), o tempo estimado para a execução das tarefas
deve durar em média uma semana e não mais de dois meses. Caso a execução planejada seja
maior do que isso, a tarefa deve ser quebrada e readequada para fins de planejamento e adaptação
ao cronograma.
Definir uma estimativa precisa para um cronograma é uma tarefa difícil, pois há
muita incerteza envolvida nas fases iniciais do projeto. Segundo Pressman (2011) as estimativas
de custo e esforço nunca serão uma ciência exata. Muitas variáveis - fatores humanos, técnicos,
ambientais e políticos - podem afetar o custo final do software e o esforço necessário para
desenvolvê-lo.
Estimativas iniciais são formadas com base em requisitos em um nível muito alto de
abstração, que muitas vezes não leva em consideração detalhes de implementação e restrições da
tecnologias adotadas. Em alguns casos, a equipe (e suas habilidades) envolvida no projeto ainda
 25

é desconhecida pelos responsáveis pela estimativa.

Mesmo com toda a incerteza, as organizações envolvidas com o processo de desen-
volvimento precisam levantar estimativas de custo e tempo. Sommerville (2001) sugere duas
técnicas para este propósito:
1. Baseada em experiência: a estimativa é baseada na experiência do gerente em projetos
passados e no seu domínio sobre a aplicação;
2. Modelagem de custo: uma formulação baseada em estimativas dos atributos do produto e
características do processo, como a experiência da equipe envolvida, é usada para calcular
o esforço necessário para o projeto.
Uma das maiores dificuldades com as técnicas baseadas em experiências passadas é
que o próximo projeto pode não ter características comuns com projetos passados. O desenvolvi-
mento de software costuma sofrer mudanças rapidamente e um novo projeto pode fazer uso de
técnicas ou tecnologias desconhecidas pela equipe. Nestas situações a experiência prévia pode
gerar uma estimativa falha tornando ainda mais difícil a tarefa de estimativa de cronograma do
projeto.

2.2 OTIMIZAÇÃO

2.2.1 Otimização Matemática

De acordo com Lemaréchal (2006) um problema de otimização matemática, ou

simplesmente problema de otimização, tem a seguinte forma:

minimize f0 (x)
(2.1)
sujeito a fi (x) ≤ bi , i = 1, ..., m.

O vetor x = (x1 , ..., xn ) contém as variáveis de otimização do problema, a função

f0 : Rn → R é a função objetivo, as funções fi : Rn → R, i = 1, ..., m são as inequações de restrição
e as constantes b1 , ..., bm são os limites das restrições. Um vetor x∗ é tido como ótimo ou uma
solução para o problema (2.1), se ele possuir o menor valor objetivo entre todos os vetores que
satisfaçam as restrições.
Dependendo da forma da função objetivo e das inequações de restrição, os problemas
de otimização podem ser classificados de maneiras diferentes. O problema (2.1) pode ser
classificado como um problema linear se as funções f0 (x) e fi (x) forem lineares.
 26

Uma grande variedade de problemas práticos que envolvem tomada de decisão pode
ser convertida na forma de um problema de otimização matemática. De fato, a otimização
matemática se tornou uma importante ferramenta em várias áreas. Ela é amplamente usada nas
áreas da engenharia, automação de projetos eletrônicos, problemas de projeto e operação de
redes, finanças, gestão da cadeia de abastecimento, agendamento e muitas outras áreas.
Em boa parte destes cenários, a otimização matemática é usada para auxiliar a
tomada de decisão humana, projetistas e operadores de sistemas, que supervisionam o processo,
checam os resultados e modificam o problema quando necessário. Os envolvidos na tomada de
decisão são encarregados de executar as ações sugeridas pela solução do problema de otimização.
Um método de encontrar uma solução de problemas de otimização é desenvolver um
algoritmo que calcula a solução do problema (com alguma precisão), de um problema específico
em uma determinada classe de problemas de otimização. Um grande esforço vem sendo aplicado,
desde a década de 40, para desenvolver algoritmos que solucionem problemas de otimização de
várias classes diferentes, analisar suas propriedades e desenvolver softwares eficientes.
A habilidade em solucionar o problema (2.1) pode variar consideravelmente e
depende de fatores como a forma das funções objetivas e restritivas, quantidade de variáveis e
restrições e estruturas especiais como a esparsidade (quando determinadas restrições dependem
de poucas variáveis).
Lemaréchal (2006) também afirma que mesmo quando as funções objetivo e inequa-
ções de restrição são suaves (por exemplo, polinomiais) o problema de otimização (2.1) torna-se
difícil de ser resolvido. Entretanto para uma classe de problemas existem algoritmos efetivos
que podem solucionar até mesmo problemas muito grandes contendo milhares de variáveis e
restrições. Dois importantes exemplos são a Programação Linear e o Método dos Mínimos
Quadrados.
Otimização não linear (ou Programação não linear) é o termo usado para descrever
problemas de otimização que possuem funções objetivas ou restritivas não lineares. Atualmente
não há métodos efetivos conhecidos para solucionar problemas de programação não linear. Até
mesmo problemas simples com poucas variáveis podem se tornar desafiadores ou até mesmo
intratáveis.
Na otimização local não há um compromisso com a procura do valor ótimo de x.
Ao invés disso busca-se um valor com um ótimo local, que minimiza a função objetivo entre os
pontos factíveis próximos ao ótimo local, mas não garante ser o menor valor dentre as regiões
factíveis.
 27

Na otimização global a(s) melhor(es) solução(ões) é(são) encontrada(s), entretanto a

eficiência é severamente comprometida. Até mesmo problemas com poucas variáveis podem
tomar muito tempo para chegar à solução desejada (horas ou dias).

2.2.2 Otimização Dinâmica

Na literatura de otimização em ambientes dinâmicos, pesquisadores definem proble-

mas de otimização que sofrem mudanças com o tempo como problemas dinâmicos ou problemas
com dependência de tempo. Este trabalho é focado em um problema de otimização dinâmica (Dy-
namic Optimization Problems, ou DOPs), que são uma classe especial de problemas dinâmicos
que são solucionados por um algoritmo de otimização.
Solucionar um DOP é uma tarefa desafiadora, pois não requer apenas que um al-
goritmo de otimização encontre a resposta ótima de um dado problema, mas que encontre a
nova solução ótima com o passar do tempo e o problema é continuamente modificado. Com-
putação Evolutiva e Inteligência de Enxames são boas ferramentas para solucionar DOPs, suas
inspirações naturais de sistemas auto organizáveis e evolução biológica sempre foram temas de
ambientes dinâmicos. O estudo de aplicação de Algoritmos Evolutivos e técnicas semelhantes
para solucionar DOPs é denominada otimização evolutiva em ambientes dinâmicos ou otimização
dinâmica evolucionária (evolutionary dynamic optimization, ou EDO).
A definição de um problema de otimização dinâmica dada por Nguyen, Yang e
Branke (2012) é que dado um problema dinâmico ft , um algoritmo de otimização G para
solucionar ft e um dado período de otimização [t begin ,t end ], ft é chamado de problema de
otimização dinâmica no período [t begin ,t end ] se durante [t begin ,t end ] o espaço de busca que G usa
para representar ft mudar e G tiver que reagir a esta mudança provendo novas soluções ótimas.
Em processos de otimização estáticos o objetivo é encontrar o ótimo global o mais
rápido possível. Quando considerado um problema com mudanças com o tempo, o objetivo é
encontrar o novo ótimo. A suposição geral é que o problema, após a mudança, está de algum
modo relacionado ao seu estado anterior e portanto o algoritmo de otimização deve aproveitar o
máximo possível a sua experiência de busca passada e com isso avançar com a busca da nova
solução ótima mais rapidamente.
No trabalho de Nguyen, Yang e Branke (2012) uma série de trabalhos em EDO
foram revisados e várias abordagens de otimização foram levantadas, entre elas estão:
1. Detecção de mudanças: abordagens tomam ações explícitas para responder a mudanças
 28

no ambiente. As modificações são informadas para o algoritmo ou o algoritmo detecta a

mudança;
2. Introduzir diversidade na ocorrência de mudanças: a convergência em ambientes dinâmicos
pode ser prejudicial pois se o espaço de busca for modificado em uma área não coberta
pelo algoritmo, ele não estará apto a reagir de maneira efetiva e pode falhar na busca
do novo ótimo global. Uma saída para este problema é aumentar a diversidade após a
detecção da mudança;
3. Manter a diversidade durante a busca: mantém a diversidade durante todo o processo de
busca para evitar a possibilidade de toda a população convergir para um único ponto e ser
incapaz de encontrar uma nova solução ótima;
4. Abordagens de memória: para reaproveitar soluções anteriores, poupar tempo de processa-
mento e guiar o processo de busca. A memória também pode ser utilizada para manter a
diversidade da busca;
5. Abordagens preditivas: em alguns casos as mudanças em ambientes dinâmicos podem
exibir padrões com características previsíveis;
6. Métodos autoadaptativos: esta abordagem faz uso da natureza auto adaptativa de EAs e
outras metaheurísticas para lidar com as mudanças de ambiente;
7. Abordagens multi populacionais: nesta abordagem trata a evolução de múltiplas subpopu-
lações ao mesmo tempo, mantendo assim a diversidade de soluções.

2.2.3 Metaheurísticas

Heurísticas e metaheurísticas surgiram como alternativas aos métodos exatos para

resolução de problemas de otimização de alta complexidade computacional que não podem ser
resolvidos em tempo polinomial (NP-completos).
Segundo Fávero e Belfiore (2012) uma heurística pode ser definida como um proce-
dimento de busca guiada pela intuição, por regras e ideias, visando encontrar uma boa solução.
Já a meta heurística representa uma combinação de procedimentos de busca com estratégias
de mais alto nível, incluindo intensificação e diversificação, buscando escapar de ótimos locais
com o intuito de encontrar soluções muito próximas ao ótimo global, porém sem a garantia da
otimalidade. Como exemplo de metaheurística, pode-se citar a Busca Tabu (GLOVER; LA-
GUNA, 1997), Têmpera Simulada (SKIŚCIM; GOLDEN, 1983), GRASP - Greedy Randomized
Adaptive Search Procedures (FEO; RESENDE, 1995), Algoritmos Genéticos (LINDEN, 2006),
 29

Colônia de Formigas (DORIGO; BLUM, 2005), Enxame de Partículas (POLI; KENNEDY;

BLACKWELL, 2007), entre outros.

2.2.3.1 Computação Evolutiva

A computação evolutiva, também conhecida como algoritmos evolucionários, funci-

ona mantendo uma população de estruturas, chamadas de indivíduos ou cromossomos, que se
comporta de forma semelhante à teoria da evolução das espécies, de Darwin.
Segundo LINDEN (2006) os algoritmos evolucionários usam modelos computacio-
nais dos processos naturais de evolução como uma ferramenta para resolver problemas. Apesar
de haver uma grande variedade de modelos computacionais propostos, todos eles têm em comum
o conceito de simulação da evolução das espécies através de seleção, mutação e reprodução,
processos que dependem do “desempenho” dos indivíduos desta espécie dentro do “ambiente”.
Sistemas Evolutivos tentam resolver problemas acumulando conhecimento sobre
o problema e utilizando essas informações para gerar soluções aceitáveis. As maiores apli-
cabilidades dessa área da Inteligência Artificial, ou IA, são em problemas de otimização e
busca.
As seções a seguir descrevem com mais profundidade as técnicas de Computação
Evolutiva, ou CE.

2.2.3.2 Algoritmos Genéticos

Os Algoritmos Genéticos (AG) são algoritmos de otimização global, baseados nos

mecanismos de seleção natural e da genética. Eles operam sobre uma população de soluções
candidatas em paralelo, podendo assim fazer uma busca em diferentes áreas do espaço de busca.
Como resultado, tais técnicas têm maior chance de atingir as áreas mais próximas do objetivo do
espaço de busca.
Os AGs têm se mostrado eficientes na busca de soluções ótimas, ou aproximadamente
ótimas, em uma grande variedade de problemas. Além de seguir uma estratégia de gerar e testar
soluções de maneira eficiente, são capazes de convergir para soluções aceitáveis (ótimas ou
próximas às ótimas).
Os AGs funcionam da seguinte maneira: é gerada uma população inicial com um
conjunto aleatório de indivíduos que podem ser vistos como possíveis soluções do problema. Em
seguida a população é avaliada e cada indivíduo recebe uma nota que representa sua capacidade
 30

adaptativa em determinado ambiente. Esta nota é gerada por uma função adaptativa ou fitness.
Uma parcela dos mais aptos é mantida enquanto os menos aptos são descartados.
Em exemplos de minimização, o AG avalia cada indivíduo com uma nota. A partir
deste parâmetro, ele seleciona os indivíduos com menor valor representativo (em casos de
maximização, seriam selecionados os indivíduos com maior valor representativo). Os indivíduos
selecionados são então submetidos a operadores de cruzamento, ou crossover, e mutação, gerando
assim uma nova população que será submetida novamente ao mesmo processo da população
anterior. Este processo iterativo de uma população gerar uma ou mais populações é chamado de
evolução e cada população dentro de um contexto evolutivo é chamada de geração. Este processo
continua se repetindo até que uma solução satisfatória seja encontrada.
Rezende (2003) afirma que os Algoritmos Genéticos são uma espécie de busca
aleatória direcionada, pois exploram informações históricas para encontrar novos pontos de
busca onde são esperados melhores desempenhos.
O AG trabalha com populações de indivíduos ou cromossomos. O cromossomo
é uma estrutura de dados, geralmente um vetor, que representa uma possível solução para o
problema de otimização. Cada unidade básica do cromossomo, ou elemento do vetor, é chamada
de gene.
De maneira geral, um AG pode ser brevemente descrito através do fluxograma
apresentado na Figura 4. O fluxograma mostra as fases de um Algoritmo Genético:

Figura 4 – Fluxograma de um AG

Fonte – LOBO (2005).

 31

a) Na fase de População é gerada uma população aleatória ou não de indivíduos

(cromossomos). A qualidade e a quantidade dessa população inicial podem
influenciar o desempenho e/ou a qualidade do resultado final do algoritmo;
b) A Avaliação de Aptidão é uma função específica para o problema a ser resolvido.
Ela fornece um parâmetro de proximidade da solução em relação ao conjunto de
parâmetros fornecidos pelo próprio problema. A função de aptidão ou fitness, é
aplicada à toda população, avaliando seus os indivíduos;
c) Na Seleção, o operador de seleção escolherá os indivíduos de melhor valor
(aptidão) para o próximo passo. Vários métodos são usados para o critério de
seleção, dentre os mais conhecidos está o método da roleta viciada, onde a
soma das aptidões representam uma totalidade. Cada parcela (aptidão) pode ser
representada como uma fatia de um gráfico de pizza, ou roleta, onde o conjunto
de fatias forma o total. Esta metodologia é usada para que indivíduos com pouca
aptidão ainda tenham oportunidade, embora remota, de serem selecionados a
fim de preservar a variabilidade genética da população. É importante entender
que se apenas os melhores indivíduos se reproduzirem, a população tenderá a ser
composta de indivíduos cada vez mais semelhantes (convergência genética).

Figura 5 – Seleção pela Roleta Simples

Fonte – Elaborada pelo autor.

d) O Cruzamento ou crossover é um dos conhecidos operadores genéticos. Nesta

fase, dois indivíduos oriundos da fase de seleção são cruzados para gerar novos
indivíduos. Existem vários operadores de crossover, dentre os quais o mais
conhecido é o crossover de um ponto, no qual um ponto de corte em comum à
dois indivíduos é selecionado e, em seguida, suas caudas são trocadas gerando
 32

dois novos indivíduos.

Figura 6 – Crossover de um ponto

Fonte – LOBO (2005).

Em alguns casos, a representação da solução no cromossomo não aceita uma troca

direta. Um caso conhecido é quando o cromossomo é uma lista ordenada, como
uma lista ordenada das cidades a ser percorrida no problema do Caixeiro Viajante.
Para estes casos, existem uma série métodos de recombinação para cromossomos
ordenados, entre elas encontra-se o PMX (Partially Matched Crossover). O
PMX escolhe dois locais de cruzamento uniformemente ao acaso, entre das
permutações, definindo assim uma seção de correspondência usada para efetuar
um cruzamento através de operações de troca de posição por posição (BACK;
FOGEL; MICHALEWICZ, 1999).
e) A Mutação é o operador genético que tem como finalidade garantir novas so-
luções na população, é o operador de mutação. Este operador recebe como
parâmetro uma probabilidade extremamente baixa (na ordem de 0,5%). Um
número entre 0 e 1 é sorteado, se o valor for menor que a probabilidade parame-
trizada, então o operador atua sobre o gene em questão.

Figura 7 – Mutação Simples

Fonte – LOBO (2005).

f) No caso do Critério de parada, diferentes critérios podem ser usados para fina-
lizar a execução de um AG, tais como: (a) uma quantidade predeterminada de
gerações; (b) ou quando uma aptidão média ou do melhor indivíduo não melhorar
 33

mais; (c) ou ao conhecer a resposta máxima/mínima da função objetivo.

2.3 ENGENHARIA DE SOFTWARE BASEADA EM BUSCA

A Engenharia de Software tem como foco todos os aspectos da produção de software.

Mesmo sendo uma área focada na atuação humana nos processos de software, seja sobre a
qualidade ou performance de código produzido, a extração/interpretação de requisitos ou o
gerenciamento de pessoas e tarefas, a ES também pode atuar em problemas onde a subjetividade
humana não é a alternativa mais precisa na solução de um problema. Alguns desses problemas
possuem características restritivas ou conflitantes, múltiplas variáveis e formas de avaliação
complexas que possuem uma quantidade enorme de soluções a serem exploradas na busca pela
melhor solução possível.
Técnicas de otimização e busca já vêm sendo adotadas em outras subáreas da Enge-
nharia, como Engenharia Mecânica, Engenharia Química, Engenharia Biomédica, Engenharia
Civil e Engenharia Eletrônica. A Engenharia de Software, sendo uma disciplina de Engenharia,
pode se beneficiar destas técnicas de maneira semelhante.
O termo SBSE (Search Based Software Engineering, ou Engenharia de Software
Baseada em Busca) foi criado por Harman e Jones (2001), onde os autores propõem a aplicação de
técnicas de otimização na resolução de problemas complexos encontrados na área da Engenharia
de Software, demonstrando que muitos dos problemas dessa área podem ser redefinidos como
problemas de busca. Dentre os problemas complexos encontrados na área de Engenharia de
Software, muitos são definidos como NP-completo (HARMAN, 2007). É válido destacar que
antes da criação do termo SBSE, já existiam trabalhos referentes a esse contexto (MILLER;
SPOONER, 1976), entretanto foi a partir de Harman e Jones (2001) que a SBSE começou a
evoluir como área de pesquisa. A Figura 8 mostra a evolução de publicações na área.
Dentre as condições que reformulam um problema tradicional da Engenharia de
Software em um problema de busca, Harman e Jones (2001) destacam:
a) Representação da solução: corresponde a como a solução será representada em
um ambiente computacional. Esta representação pode variar entre vetor binário,
um grafo ou mesmo uma árvore;
b) Função de Avaliação: é definida baseada na representação da solução e é utili-
zada como uma métrica de qualidade da solução;
c) Operadores: são mecanismos utilizados para manipulação das soluções onde é
 34

Figura 8 – Número de publicações de SBSE por ano

Fonte – Adaptado de Zhang, Harman e Mansouri (2016).

possível gerar uma nova solução a partir de outra já existente.

Dado que o problema se adeque às condições descritas, Harman e Clark (2004)
destacam características que justificam o uso de funções de avaliação em problemas de SBSE.
Entre eles estão:
a) Grande espaço de busca: em casos de um pequeno espaço de busca, uma busca
exaustiva é suficiente. Entretanto em grandes espaços de busca a adoção desta
técnica é justificada;
b) Baixa complexidade computacional: a busca por soluções demanda um nú-
mero alto de avaliações de qualidade entre as possibilidades de solução explora-
das. Portanto quanto menor o custo computacional de avaliação, mais rápido o
espaço de busca será explorado;
c) Continuidade aproximada: caso a função de avaliação seja descontínua, o
processo de busca pode não ser guiado corretamente, e por consequência deixar
de explorar áreas promissoras;
d) Ausência de solução ótima conhecida: se houver um método com a capacidade
encontrar a solução ótima, não há necessidade de utilizar uma meta-heurística
que não oferece a mesma garantia.
Dentre os problemas de Engenharia de Software abordados pela SBSE, encontram-se
 35

áreas como priorização de requisitos (BAGNALL; RAYWARD-SMITH; WHITTLEY, 2001),

planejamento de releases de software (AKKER et al., 2005), manutenção de software (SENG;
STAMMEL; BURKHART, 2006), geração de dados para teste de software (KOREL, 1990),
engenharia orientada a serviços (WADA et al., 2011), otimizadores de compiladores (DUBACH
et al., 2007) e avaliação de qualidade (BOUKTIF; SAHRAOUI; ANTONIOL, 2006), estimativa
de custo de projeto (WU et al., 2011), entre outras. O gráfico na Figura 9 mostra a quantidade de
publicações em SBSE por área.

Figura 9 – Número de publicações de SBSE por Área

Fonte – Adaptado de Zhang, Harman e Mansouri (2016).

Um vasto leque de técnicas de otimização e busca podem e vêm sendo aplicados.

Entre os mais usados estão, Busca Local, Têmpera Simulada, Algoritmos Genéticos e Programa-
ção Genética. Entretanto, independente da técnica de busca escolhida é a função de avaliação
que captura a informação crucial, ela é o fator que diferencia uma boa solução de uma ruim.
 36

3 TRABALHOS RELACIONADOS

Este trabalho foca no uso de técnicas de otimização dinâmica sobre o Problema

de Agendamento em Projetos de Software (Software Project Scheduling Problem, ou SPSP).
Devido a isso, a seleção de trabalhos relacionados que contribuem para esta pesquisa inclui
artigos científicos publicados no campo da otimização dinâmica e estudos sobre o problema de
agendamento de tarefas.
Desta forma, este capítulo encontra-se dividido em duas seções. A primeira seção
relata trabalhos de otimização dinâmica. A segunda relata trabalhos no campo da alocação e
agendamento de tarefas.

3.1 TRABALHOS SOBRE OTIMIZAÇÃO DINÂMICA

Muitos eventos aleatórios são associados com a execução do planejamento opera-

cional das organizações. Uma tarefa pode ser adiada, ou executada mais cedo que o esperado.
Algumas restrições operacionais podem ser introduzidas por causa de novas regulamentações ou
regras de negócio. Em alguns casos, pode haver mudança na importância dos objetivos associa-
dos ao seu planejamento inicial. Essas modificações geram um grande impacto no planejamento,
que deve se adaptar rapidamente às novas condições do ambiente durante sua execução.
O trabalho de Nguyen e Yao (2012) apresenta investigações sobre as característi-
cas que tornam Problemas de Otimização Dinâmica com Restrições (Dynamic Constrained
Optimization Problems - DCOPs) difíceis de serem resolvidos por algoritmos de otimização
dinâmica (OD) e tratamento de restrições (TR) já existentes. Um conjunto de problemas com
características dinâmicas é introduzido e testado com estratégias de OD e TR. Os resultados
confirmam que DCOPs possuem características especiais que afetam significativamente a perfor-
mance dos algoritmos. Os resultados também revelam observações interessantes onde a presença
ou combinação de diferentes tipos de restrições tornam o problema mais fácil de ser resolvido
para certos algoritmos. Baseado na análise dos resultados uma lista com potenciais requisitos
que um algoritmo deve cumprir para solucionar DCOPs é proposta.
Simões e Costa (2003) afirmam que a maior limitação de um AG ao lidar com um
ambiente dinâmico é a tendência para a maior parte dos membros de uma população convergirem
prematuramente para uma região particular do espaço de busca, tornando difícil para o AG
encontrar outras soluções após mudança no ambiente. Diversas abordagens são testadas para
superar esta limitação introduzindo diversidade à população ou fazendo uso da memória para
 37

ajudar o algoritmo quando situações passadas forem observadas no futuro. Nesse trabalho é
proposto um AG inspirado por ideias de sistemas imunológicos a fim de lidar com ambientes
dinâmicos.
Já Bui et al. (2012) propõe uma abordagem computacional para a adaptação dentro
do contexto de planejamento. Esta abordagem modela um problema de planejamento dinâmico
como um problema de otimização multiobjetivo e um mecanismo evolucionário é incorporado,
adaptando a solução atual para novas situações quando ocorrer mudanças. O conjunto de soluções
não-dominadas pode ser percebido como um rico conjunto de dados que pode ser usado para
apoiar o processo de adaptação sobre o efeito das mudanças. Nesse trabalho é proposto um
método baseado no conceito de centróides sobre um número de mudanças em um espaço de
tempo, a cada intervalo é obtido um conjunto de soluções. O planejamento de missões de campo
de batalha foi usado para experimentações e análises.

3.2 TRABALHOS SOBRE AGENDAMENTO DE TAREFAS

O problema de planejamento de projetos já foi extensivamente explorado na literatura.

Tipicamente este tipo de problema é caracterizado por restrições de recursos, restrições de
precedência e objetivos a serem otimizados. O problema de planejamento de projetos na área
da Engenharia de Software envolve mais que limitações de recursos, bem como multitarefa
dentro de um determinado período. Nesse contexto dá-se o nome de Problema de Gerenciamento
de Projetos de Software (Software Project Management Problem - SPMP) ou Problema de
Agendamento de Projetos de Software (Software Project Scheduling Problem - SPSP).
O trabalho de Jin e Yao (2014) expande o problema SPMP levando em consideração
a eficiência de determinadas equipes no planejamento de projetos. Esta adaptação é nomeada
de T-SPMP. As instâncias do T-SPMP especificam que a combinação de pessoas em um time
aumenta ou diminui o tempo para a realização de uma tarefa. Pela natureza NP-Difícil do
problema, o método de otimização heurístico Aprendizado Incremental Baseado em Populações
(Population-Based Incremental Learning ou PBIL) foi utilizado. Ao final do trabalho uma
comparação de soluções de instâncias do SPMP e T-SPMP é realizada.
Em Luna et al. (2014) é apresentada uma abordagem multiobjetivo para trabalhar
com dois objetivos conflitantes em problemas de SPSP: custo e duração do projeto. Nesse traba-
lho são analisados a escalabilidade de 8 algoritmos multi-objetivos em instâncias de tamanhos
crescentes. Os algoritmos utilizados foram clássicos da literatura (NSGA-II, PAES, e SPEA2) e
 38

propostas mais recentes (DEPT, MOCell, MOABC, MO-FA, e GDE3). Das experimentações
conduzidas, os resultados sugerem que PAES é o que apresenta as melhores características de
escalabilidade.
Já em Xiao, Ao e Tang (2013) é proposto um algoritmo efetivo para solucionar
problemas de SPSP. É proposto um algoritmo chamado ACS-SPSP, que é baseado em Otimização
de Colônia de Formigas (Ant Colony Optimization ou ACO). Seis heurísticas foram projetadas
para considerar fatores de esforço de tarefas, alocação de pessoas e importância de tarefas.
O algoritmo proposto é comparado a um Algoritmo Genético para solucionar 30 instâncias
aleatórias de SPSP. O resultados experimentais mostram que o algoritmo proposto é promissor e
pode obter melhores soluções que as prévias soluções encontradas com o AG.
Por fim em Hladik et al. (2008) é apresentado uma abordagem original baseada
em programação com restrições (Constraint Programming ou CP) para solucionar a alocação
estática de tarefas de tempo real. O problema consiste em atribuir tarefas periódicas para
processadores distribuídos no contexto de escalonamento preemptivo com prioridade fixa. Duas
novas abordagens são propostas e validadas com resultados experimentais. A abordagem é
completa (se um problema não tiver solução, o algoritmo pode provar), também é não paramétrica
(não necessita de ajuste de parâmetros) permitindo assim que uma grande diversidade de modelos
seja facilmente considerada.
 39

4 ABORDAGEM PROPOSTA

As organizações estão em constante evolução para melhoria contínua de sua operação,

seja aumentando sua receita, procurando novas formas de maximizar seus lucros como a atuação
em novos nichos de mercado, aumentar a efetividade dos seus canais de venda ou diminuindo
suas despesas procurando ser mais eficaz e eficiente em sua operação, procurando otimizar seus
fluxos de trabalho ou otimizar o uso de recursos utilizados em sua produção.
Na constante procura de melhorar seus processos, muitas ideias surgem e precisam
ser validadas o mais breve possível. Muitas dessas ideias envolvem a integração e comunicação
de diversos setores. Nestas situações a necessidade de softwares que deem suporte a validação e
concretização destas concepções é muito alta.
Em cenários como este, muitas vezes os softwares de apoio de operações evoluem
juntamente com a organização. Durante este processo de crescimento, os softwares são cons-
tantemente adaptados para suprir as novas necessidades que surgem no decorrer do processo.
Deste modo, precisam ser ajustados para que possam agregar valor o mais rápido possível à
organização.
Para que a equipe responsável pelo desenvolvimento, manutenção e evolução de
softwares entregue valor à organização de maneira eficiente, se faz necessário elaborar um
cronograma de tarefas para os membros da equipe.
O Problema de Agendamento de Projetos de Software (Software Project Scheduling
Problem, ou SPSP) tem como objetivo encontrar o agendamento ótimo de tarefas para um projeto
de software de modo que as restrições de recurso e precedência sejam satisfeitas e o custo final
do projeto, em termos de recursos humanos e tempo de projeto sejam minimizados (XIAO; AO;
TANG, 2013). Luna et al. (2014) ainda afirma que devido à complexidade computacional e ao
tamanho dos projetos atuais, os problemas de SPSP não pode ser resolvido eficientemente usando
algoritmos completos, já que enumerar todo o espaço de busca exigiria anos de computação.
A proposta deste trabalho é adaptar o problema SPSP em um cenário dinâmico
onde o número de tarefas a ser executadas cresce continuamente. Como o propósito é a entrega
de valor de maneira mais efetiva, o principal objetivo desta proposta é minimizar o tempo de
execução das tarefas planejadas. Para isto é preciso distribuir as tarefas para as pessoas mais
aptas para executar cada uma delas, respeitando suas restrições de precedência e prioridade.
Sendo assim, uma pessoa que possui mais experiência nas áreas de exigência de uma determinada
tarefa poderá concluí-la com mais velocidade que uma pessoa menos apta.
 40

Este capítulo detalha a abordagem proposta dividindo-a em duas etapas. São elas:
a) Estimativa de esforço (ou tempo necessário) para a conclusão de uma tarefa por
uma determinada pessoa;
b) Agendamento das tarefas a serem realizadas respeitando as restrições de priori-
dade e precedência de tarefas.
O principal foco deste trabalho é a análise do método de otimização para o problema
de agendamento de tarefas em projetos de software em um ambiente dinâmico. Neste ambiente
o número de tarefas e pessoas varia continuamente, assim como a experiência exigida para a
conclusão de cada tarefa e a experiência de cada pessoa envolvida. Sendo assim, a técnica usada
neste trabalho para a estimativa de esforço é apenas uma ideia inicial.
Para o aprimoramento da estimativa de esforço para a conclusão de tarefas é ne-
cessário investigar a base de dados histórica de uma determinada organização e a partir destas
informações, criar um modelo mais acurado de estimativa de tempo. Tal estimativa pode ser
melhor trabalhada explorando técnicas de Mineração de Dados e Aprendizagem de Máquina.

4.1 ESTIMATIVA DE ESFORÇO

Considerando T = {t1 ,t2 , ...,tN } o conjunto de tarefas a serem executadas, N é o

número total de tarefas. E = {e1 , e2 , ..., eM } é o conjunto de pessoas disponíveis para execução
de tarefas, M é o número total de pessoas disponíveis. Stask
i = (si1 , si2 , ..., sik ) são os dados
contendo os valores de habilidades necessárias para completar uma tarefa i, onde 1 6 i 6 N e
i ∈ N e k é o número total de habilidades exigidas. Já Semployee
j = (s j1 , s j2 , ..., s jk ) são os dados
contendo os valores de habilidades (ou experiência) que a pessoa j possui, onde 1 6 j 6 N e
j ∈ N.
Deste modo, pode-se exemplificar uma situação onde uma hipotética tarefa t3 requer
habilidade alta em interface gráfica (5), regular em documentação (3) e baixa em liderança (1).
O conjunto Stask
3 = (5, 3, 1) seria a definição de habilidades requeridas para completar t3 . De
modo semelhante, outro hipotético conjunto S2employee = (2, 1, 3) seria o conjunto representando
a expertise de uma pessoa e2 nas respectivas áreas de conhecimento.
Para definir a aptidão uma pessoa na realização de uma determinada tarefa é preciso
definir uma métrica de similaridade entre pessoas e tarefas. De acordo com Segaran (2007)
existem várias métricas de similaridade como distância Euclidiana, similaridade de Jaccard,
similaridade de Pearson, distância Cosseno, distância Manhattan, entre outras. Este trabalho fez
 41

uso da similaridade de Pearson para encontrar o grau de aptidão entre tarefas e pessoas, que é
definida pela equação:

employee
cov(Stask
i ,Sj )
ρ(Stask ,Semployee ) = , (4.1)
i j σStask σSemployee
i j

onde cov é a covariância e σStask é o desvio padrão de Stask

i . Já a função cov é cada pela seguinte
i

forma:

employee
cov(Stask
i ,Sj ) = E[(Stask
i − µStask )(Semployee
j − µSemployee )], (4.2)
i j

onde E é o valor esperado e µStask é a média aritmética de X.

i

Ao fazer uso da equação ρ(Stask ,Semployee ) uma matriz AMxN é gerada. Esta matriz
i j
contém valores de similaridade entre [−1, 1], que representam a aptidão de uma pessoa j na
execução de uma tarefa i. Se os valores se aproximam de 1, a pessoa é adequada para a resolução
da tarefa, a medida que esse valor se aproxima de −1, menos a pessoa é adequada para solucionar
a tarefa. A matriz resultante AMxN é apresentada da seguinte forma:
 
a1,1 a1,2 · · · a1,n
 
 a2,1 a2,2 · · · a2,n
 

AMxN =
 .. .. .. ..
 (4.3)
.

 . . . 
 
am,1 am,2 · · · am,n

A matriz AMxN é um bom indicador de aptidão entre tarefas e pessoas, entretanto ela
não indica uma estimativa de tempo de conclusão de tarefa. Para efeitos de simplificação da
experimentação a ser realizada, esses valores serão escalonados para definir um prazo limite para
a execução das tarefas. A ideia é escalar os valores de modo que quando a similaridade for 1, a
tarefa será executada em até 2 horas. Já se o valor -1 ela será executada em 80 horas (equivalente
a 10 dias úteis com 8 horas de trabalho).
Portanto, para transformar a matriz AMxN em uma matriz BMxN que contém as
estimativas em horas de tempo de execução de cada tarefa, cada elemento ai j da matriz AMxN ,
deve passar pela equação linear bi j = d39 × (−ai j + 1) + 2e. A tabela 2 contém uma amostra
de similaridades (ai j ) convertidas em estimativas de tempo (bi j ) após o uso da equação. Sendo
 42

assim a matriz BMxN conterá valores com as estimativas de tempo de execução de tarefas entre
[2, 80] e será representada por:
 
b b1,2 · · · b1,n
 1,1 
· · · b2,n
 
 b2,1 b2,2 
BMxN =
 .. .. .. ..
 (4.4)
.

 . . . 
 
bm,1 bm,2 · · · bm,n

Tabela 2 – Amostra de valores escalados

Similaridade (ai j ) Estimativa de Tempo em horas (bi j )

-1 80
-0.75 71
-0.5 61
-0.25 51
0 41
0.25 32
0.5 22
0.75 12
1 2

Fonte – Elaborado pelo autor

4.2 AGENDAMENTO DE TAREFAS

A modelagem proposta neste trabalho tem como objetivo uma entrega de valor mais
eficiente, de modo a alocar as tarefas para as pessoas mais aptas a solucioná-las para que a
conclusão de todas as tarefas seja o mais rápido possível. Para atender o caráter dinâmico, a
modelagem sempre considera o momento m, que representa o estado (pessoas e tarefas) onde
a instância do problema se encontra. Um exemplo aplicado do conceito de m seria se em um
determinado momento hipotético m1 a instância do problema conta com 20 tarefas a serem
executadas, já em um momento m2 ela conta com 25 tarefas.
A restrição de precedência define que em caso de uma tarefa b depender de uma
tarefa a, a mesma só poderá ser executada após o término de a. Entretanto, para atender o caráter
dinâmico proposto neste trabalho, faz se necessário destacar que esta restrição é referente a um
determinado momento m e que em outra ocasião pode assumir valores diferentes, portanto:

end(ta , m) ≤ begin(tb , m), se ta ≺ tb ,ta e tb ∈ T em m. (4.5)

 43

A restrição de prioridade, onde uma tarefa de alta prioridade deve ser executada
antes de uma tarefa de prioridade mais baixa, pode ser conflitante com a restrição de precedência.
Um exemplo desta situação seria se uma tarefa ta precedesse tb e o mesmo tb tiver uma prioridade
mais alta que ta em um momento m. Neste caso hipotético, ainda que a prioridade de tb seja
mais alta, no momento m do planejamento, ela deve ser executada após o término de ta . Portanto,
a restrição de prioridade é uma restrição suave e deve ser formulada de maneira a penalizar o
tempo máximo de execução caso não seja priorizada. Logo a função de penalidade pode ser
definida por:


1 + priority(tb ,m)−priority(ta ,m)

se priority(ta , m) < priority(tb , m)
maxprioritym
penalty(ta ,tb , m) =
1 se priority(ta , m) ≥ priority(tb , m).


(4.6)
A função penalty(ta ,tb , m) retorna um percentual a ser adicionado ao tempo de
execução de uma tarefa tb levando em consideração uma tarefa ta , que em um momento m,
foi alocada anteriormente. Se a prioridade da tarefa anterior, definida por priority(ta , m), for
maior ou igual a tarefa atual, definida por priority(tb , m), nenhuma penalidade de tempo será
acrescentada, caso contrário uma punição percentual é calculada a partir da diferença entre as
prioridades sobre maxprioritym , o maior valor possível entre as prioridades, será acrescido ao
tempo de planejamento.
O cálculo do tempo de execução de todas as tarefas delegadas para uma pessoa j em um
momento m pode ser obtido pela seguinte fórmula:

N
workingTime(ei , m) = bi1 yi1 + ∑ bi j yi j × penalty(xi j−1 , xi j , m), (4.7)
j=2

onde bi j é um elemento da matriz BMxN , que representa o tempo estimado para a execução de
uma pessoa i por uma tarefa j e yi j é um valor onde y ∈ {0, 1} e indica se a pessoa ei irá de
fato executar a tarefa j no tempo estimado bi j no momento m. Já xi j possui um valor entre
x ∈ {1, 2, ..., N} e representa um vetor com a ordem das tarefas a serem executadas por ei no
mesmo momento m.
M
Cada tarefa deve ser alocada para apenas uma pessoa, sendo assim a restrição ∑ yi j =
i=1
1 para todo j ∈ {1, 2, ..., N} é definida. O vetor contendo a ordem de tarefas a serem executadas
por ei não pode possuir valores repetidos (exceto o valor zero que indica que determinada
 44

tarefa não será executada por ei ), logo a restrição é definida por alldiff_except0(xi∗ , m) para todo
i ∈ {1, 2, ..., M}.
O agendamento de tarefas possui um caráter combinatório e tem como objetivo
minimizar o maior período de execução de todas as tarefas alocadas por pessoa, ou seja minimizar
o máximo valor de workingTime(ei , m) possível entre as M pessoas envolvidas. Sendo assim o
problema pode ser representado pela seguinte formulação:

minimize max∀i∈M workingTime(ei , m)

sujeito a
M
∑ yi j = 1, ∀ j ∈ {1, 2, ..., N}
i=1
alldiff_except0(xi∗ , m), ∀i ∈ {1, 2, ..., M} (4.8)

end(ta , m) ≤ begin(tb , m), se ta ≺ tb ,ta e tb ∈ T

yi j ∈ {0, 1}, ∀i ∈ {1, 2, ..., M} e ∀ j ∈ {1, 2, ..., N}
xi j ∈ {0, 1, ..., N}, ∀i ∈ {1, 2, ..., M} e ∀ j ∈ {1, 2, ..., N}.

Em resumo, a abordagem proposta tem como objetivo alocar tarefas para os in-
divíduos mais aptos a solucioná-las, de modo a minimizar o maior período de execução das
tarefas entre todos os envolvidos, respeitando as restrições de precedência e punindo soluções
com prioridades mal distribuídas. Dessa forma, espera-se que a abordagem possa encontrar
continuamente, dado um ambiente com constante acréscimo de tarefas e alta rotatividade de
pessoas, uma boa distribuição de tarefas entre os envolvidos de modo a minimizar o tempo total
de execução de tarefas e entregar valor a organização o mais rápido possível.

4.3 REPRESENTAÇÃO DA SOLUÇÃO

Para explicar a representação da solução do problema, esta seção descreve um cenário

fictício básico, onde um conjunto de 5 pessoas (Thiago, Vanessa, Altino, Alysson, Thayse) devem
concluir a execução de 13 tarefas (Atividades A, B, C, D, E, F, G, H, I, J, L, M, N) de prioridade
baixa, que não possuem precedências entre si. Inicialmente um planejamento não ótimo é gerado,
como pode ser visto na figura 10. Ainda neste momento inicial, pode-se observar pela figura 10
que o tempo estimado de conclusão de todas as tarefas, ou o tempo máximo de trabalho que uma
pessoa terá para concluir suas tarefas, leva aproximadamente 14 dias.
Nas seções anteriores, foi explicado que o tempo estimado de conclusão de uma
atividade é diferente quando alocado para outras pessoas. Este fato revela a natureza de com-
 45

Figura 10 – Planejamento inicial

Fonte – Elaborada pelo autor.

plexidade combinatória do problema. Sendo assim uma atividade alocada para outra pessoa
pode mudar drasticamente o tempo total de execução. Um exemplo seria realocar a tarefa F, que
inicialmente pertencia a Vanessa e no novo planejamento será alocada para Thayse, como mostra
a figura 11. Neste novo planejamento a execução das tarefas leva 12 dias, sendo assim 2 dias de
trabalho foram economizados com o novo planejamento.

Figura 11 – Planejamento alterado

Fonte – Elaborada pelo autor.

Em termos de representação este problema pode ser expresso por um conjunto de

letras e números no seu momento inicial:

P = {A, B,C, 1, D, E, F, 2, G, H, I, 3, J, L, 4, M, N}, (4.9)

onde cada letra representa sua respectiva tarefa e cada número seria um ponto de
corte. Os pontos de corte representam a divisão de tarefas entre cada pessoa, na representação
4.9 ela aponta que as tarefas {A, B,C} serão executadas pela primeira pessoa (Thiago), as tarefas
{D, E, F} serão executadas pela segunda pessoa (Vanessa) e assim por diante.
 46

No segundo momento, como mostra a figura 11, a representação pode ser dada por:

P = {A, B,C, 1, D, E, 2, G, H, I, 3, J, L, 4, M, N, F}, (4.10)

sendo assim, o total de pontos de cortes (4) é diferente do número de pessoas

disponíveis (5). Isto acontece pois o número de pontos de corte é o total de pessoas menos
um (4 = 5 - 1). De modo geral, um problema que possui N tarefas e M pessoas possuirá uma
representação com tamanho N + M - 1, onde cada elemento da representação possuirá um valor
único e cada valor será referente a uma tarefa ou ponto de corte.
 47

5 ESTUDO EMPÍRICO

Este capítulo descreve o estudo realizado para validar a abordagem dinâmica proposta
para alocar tarefas em projetos de software, as instâncias utilizadas, métricas coletadas e testes
realizados com o objetivo de avaliar os resultados alcançados durante este processo. Este
estudo foi realizado utilizando dados fictícios que foram gerados para simular um ambiente
real. O capítulo apresenta as questões de pesquisa que orientam este trabalho. A seguir, é
apresentada a metodologia adotada na aplicação dos experimentos, descrevendo detalhes das
instâncias utilizadas, da configuração do AG utilizado e as métricas usadas para comparação
de desempenho dos algoritmos testados. Após isso, há a apresentação dos resultados obtidos,
seguidos por suas respectivas análises. Por fim, são estabelecidas as ameaças à validade e as
considerações finais. Para permitir a replicação deste experimento, todas as instâncias, resultados
e código-fonte estão disponíveis para acesso público1 .
Para testar a natureza dinâmica do experimento, uma instância aleatória do problema
será gerada, inicialmente a base será formada por 3 pessoas e 25 tarefas a serem alocadas.
Para cada tarefa haverá informações de precedência, prioridade e o conjunto de habilidades
necessárias para a execução da tarefa. Para cada pessoa, haverá o conjunto de habilidades com o
grau de experiência devidamente informado.

5.1 QUESTÕES DE PESQUISA

Como forma de avaliar a abordagem proposta, foi conduzido um estudo experimental

delineado pelas seguintes questões de pesquisa:
QP1: A abordagem dinâmica teria uma diferença significativa no resultado final em
relação a uma abordagem tradicional?
QP2: Qual o impacto observado no valor de fitness da solução corrente no momento
da modificação da instância?
QP3: Dentre as abordagens dinâmicas, os valores da taxa de propagação genética
apresentam relação com as métricas de reaproveitamento de soluções?
QP4: O mesmo comportamento observado na abordagem dinâmica pode ser verifi-
cado em instâncias com um maior número de variáveis e restrições?
Para elucidar tais questionamentos, foram realizados testes a partir de instâncias
artificias do Problema de Agendamento em Projetos de Software. Além disso, para simular um
1 <http://goes.uece.br/thiagooliveira/rts/>
 48

comportamento dinâmico, uma série de modificações foram planejadas de modo que ocorressem
durante o processo de otimização de forma controlada. Para a execução dos testes foi aplicado
um Algoritmo Genético como mecanismo de busca em conjunto com um Observer (GAMMA et
al., 1995) que monitora as modificações na instância. Estes e outros aspectos do experimento
serão detalhados nas próximas seções.

5.2 METODOLOGIA

Para a realização deste experimento foram construídas 3 instâncias distintas, cada

uma contendo informações sobre as tarefas a serem executadas e dados sobre as pessoas que
serão usadas para executar as tarefas. O detalhamento dos dados é descrito a seguir.

5.2.1 Instâncias

As 3 instâncias utilizadas neste trabalho são compostas, inicialmente, por 3 pessoas.

Entretanto, cada instância possui um número inicial de tarefas diferentes (25, 50 e 100). As
tarefas da menor instância se encontram repetidas nas demais instâncias, ou seja, a instância que
contém 100 tarefas, contém todas as tarefas da instância de 50, que por sua vez contém todas as
tarefas da instância de tamanho 25.
Para cada uma das três instâncias mencionadas, três novas variações com níveis de
precedência diferentes são geradas (10%, 25% e 50%), gerando um total de 9 instâncias a serem
testadas. Portanto, em uma instância de tamanho 100 com nível de precedência de 25% ocorrem
25 precedências distintas.
A nomenclatura de cada uma das 9 instâncias possui informações referentes a essas
variações. Por exemplo, uma determinada instância i_50_25 possui 50 tarefas e 25% de nível de
precedência. O quadro 1 exibe a relação de instâncias utilizadas neste experimento.

Quadro 1 – Instâncias do Experimento

Tarefas / Precedência 10% 25% 50%
25 i_25_10 i_25_25 i_25_50
50 i_50_10 i_50_25 i_50_50
100 i_100_10 i_100_25 i_100_50

Fonte – Elaborado pelo autor

Dentre as informações das pessoas envolvidas se encontram dados referentes ao

conjunto de dez habilidades básicas requeridas pela organização e o nome da pessoa. Já sobre as
 49

tarefas, pode-se encontrar informações sobre o seu identificador, o título da tarefa, sua criticidade,
o identificador de outra tarefa que a mesma venha a preceder, e o conjunto de habilidades que a
tarefa demanda para ser concluída.
As informações de prioridade de uma tarefa são classificadas como Minor (Baixa),
Major (Alta) e Critical (Crítica). Já as informações sobre precedência entre tarefas indicam que
elas possuem uma dependência de execução acíclica, ou seja, se uma tarefa A precede uma tarefa
B e a tarefa B precede uma tarefa C, é impossível que a tarefa C preceda a tarefa A. A figura 12
mostra um grafo com a relação de precedência entre as tarefas na instância i_25_50, onde 50%
de 25 tarefas são 13 (12,5 arredondados) precedências, que são representadas pelas arestas do
grafo.

Figura 12 – Grafo com Precedência entre Tarefas

Fonte – Elaborada pelo autor.

O conjunto de habilidades, apresentados tanto pelas pessoas quanto tarefas envolvidas

nas instâncias, são dados que representam a experiência requerida para a execução de uma tarefa,
e a experiência adquirida de cada uma das pessoas envolvidas. Neste experimento foi definido
um conjunto de dez habilidades, onde cada informação assume um valor entre 0 e 5. Com base
nessas informações, a estimativa de tempo de execução das tarefas é calculada. Os detalhes sobre
a definição desta estimativa podem ser visto na seção 4.1.
Além das definições do estado inicial das instâncias, é preciso um planejamento
sobre as modificações em cada uma delas. Este planejamento será necessário para efetuar as
modificações na instância durante a execução do experimento. Os dois tipos de perturbações
planejadas são:
1. Adicionar 5 novas tarefas durante do experimento, para simular um ambiente real onde
novas tarefas de diversas prioridades e precedências surgem constantemente;
2. Acréscimo de pessoas para simular o crescimento de uma equipe real.
 50

Para cada instância, estas perturbações são agendadas para ocorrer 2 vezes em
intervalos de 30 segundos. Portanto, para cada uma das 9 instâncias são executadas simulações
em 2 cenários diferentes, totalizando 18 cenários de execução.

5.2.2 Técnica de Busca

Para implementação do AG utilizado neste trabalho foi utilizado o Jenetics (WI-

LHELMSTÖTTER, 2016), uma biblioteca voltada a área de Algoritmos Evolutivos baseada em
Java. Contudo a biblioteca não tem suporte a abordagens dinâmica, o que exigiu a criação de
novas classes que pudessem adaptar a biblioteca para a realidade proposta neste trabalho.
Em termos de implementação, uma classe usando o padrão Observer foi criada para
analisar a instância utilizada, e no momento que uma modificação na instância ocorrer, seja ao
adicionar uma nova tarefa ou uma nova pessoa, uma sequência de passos é tomado:
1. O Observer sinaliza a modificação para o AG, que paralisa sua execução;
2. Uma parcela parametrizável (taxa de propagação genética) da população do AG é separada;
3. Cada indivíduo desta parcela é adaptado para a nova realidade da instância;
4. Por fim a execução do AG é reiniciada utilizando esta parcela adaptada como população
inicial.
No início da execução, a população inicial do AG é gerada aleatoriamente. A parcela
da população que é reaproveitada para uma próxima execução é definida por um parâmetro,
que caracteriza a natureza dinâmica do problema, chamado de propagação genética, que é uma
das variáveis a ser considerada na questão 1. Além do parâmetro de natureza dinâmica, o AG
mantém todas as suas configurações originais durante o processo, eles são:
• População contendo 500 indivíduos;
• Elitismo com duração máxima de até 100 gerações;
• Método da Roleta Simples como seletor de indivíduos;
• Cruzamento com taxa de 80% para cromossomos ordenados usando Partially
Matched Crossover (PMX);
• Taxa de mutação de 5%.
O processo de adaptação é dado no momento que um conjunto de soluções (indiví-
duos no AG) precisa ser modificado para adaptar-se à nova realidade da instância. Este processo é
executado de forma reativa e é realizado quando um novo item, pessoa ou tarefa, é adicionada ou
removida da instância. Em termos de representação, as soluções sofrem uma alteração simples,
 51

que pode ser encarada como uma remoção ou acréscimo de um item em uma estrutura de lista.
Embora a modificação se dê de maneira simples, dependendo do tipo de item a
ser acrescido ou removido, a alteração pode causar um impacto grande no espaço de busca.
Por exemplo, se em um determinado momento uma solução P assumir a forma P1 e houver o
acréscimo de duas novas pessoas, ela tomará a forma P2 .

P1 = {A, B,C, 1, D, E, F, 2, G, H, I, 3, J, L, 4, M, N}
(5.1)
P2 = {A, B,C, 1, D, E, F, 2, G, H, I, 3, J, L, 4, M, N, 5, 6}

Como discutido na seção 4.3, a nova representação preserva a alocação das tarefas
para as 5 pessoas iniciais e adiciona 2 novas pessoas sem nenhuma tarefa alocada inicialmente,
mas que eventualmente receberão tarefas mais apropriadas que estavam alocadas para as 5
pessoas do estado anterior. Esta alteração não traria nenhuma mudança efetiva ao valor de fitness
da solução, já que as mesmas tarefas ainda estariam alocadas para as mesmas pessoas. Contudo,
se a mesma solução na forma P1 tiver o acréscimo de 5 novas tarefas e ao assumir uma nova
forma P3 , as novas tarefas serão alocadas para uma única pessoa. Se esta pessoa não tiver uma
boa afinidade com as novas tarefas, elas irão tomar muito tempo para serem concluídas e poderão
afetar de maneira drástica o valor de fitness da solução.

P1 = {A, B,C, 1, D, E, F, 2, G, H, I, 3, J, L, 4, M, N}
(5.2)
P3 = {A, B,C, 1, D, E, F, 2, G, H, I, 3, J, L, 4, M, N, O, P, Q, R, S}

A remoção de itens se comporta de forma semelhante. No caso da remoção de uma

pessoa, todas as tarefas que estavam alocadas para a pessoa removida serão alocadas para outra
pessoa, na mesma ordem que se encontravam. Já no caso da remoção de tarefas o valor de fitness
tende a diminuir, exceto se houver alguma quebra na restrição de precedência. Em ambos os
casos de remoção haverá um impacto notável no valor de fitness da solução.
A implementação realizada para este trabalho torna o processo de otimização reativo
às mudanças observadas na instância, de modo a aproveitar o conhecimento adquirido (via
propagação genética) sobre o espaço de busca já explorado. Embora a implementação esteja
pronta para se adaptar a qualquer tipo de mudança, nos experimentos deste trabalho cada
mudança é planejada previamente e devem ocorrer a cada 30 segundos. Estas modificações
podem acrescentar uma nova pessoa, ou adicionar um lote de 5 novas tarefas em cada uma delas.
 52

Devido ao grande tempo necessário para a realização de uma grande quantidade de simulações,
este trabalho não realizou experimentos que com remoção de tarefas ou pessoas.

5.2.3 Métricas de Avaliação

O objetivo central do problema é minimizar o tempo total de execução das tarefas,

entretanto como apresentado pela equação 4.8, o problema apresenta restrições de precedência e
prioridades. Devido às restrições encontradas no problema, o mero cálculo do tempo máximo
de execução de tarefas (que precisa ser minimizado) não é o suficiente para ser tratado como
fitness. É preciso penalizar as soluções que apresentam quebra de restrições, deste modo regras
de penalizações são estabelecidas. A restrição de precedência é tida como uma restrição mais
rígida, pois em caso de conflito entre as duas restrições ela deve ter a prioridade em termos de
resolução. Deste modo para o tratamento de restrições de precedência é adicionado ao fitness
uma penalidade alta, proporcional ao número de precedências violadas. Já para as restrições de
prioridade é adicionado ao fitness uma penalidade proporcional ao número de tarefas alocadas
em prioridades indevidas. As penalidades tendem a ser um mecanismo que oferece resistência à
tentativa de minimizar o fitness, ou seja, na tentativa de procurar um menor fitness, o AG tende a
favorecer as soluções com menor número de restrições.
A evolução do valor de fitness calculado pelo AG, embora não represente necessaria-
mente o valor ótimo que uma solução do problema possa ter, pode servir como uma métrica de
exploração do espaço de busca. Deste modo, além de servir como métrica de comparação entre
execuções com parâmetros diferentes, a análise da evolução do fitness pode servir como uma
medida de performance baseada no comportamento.

5.2.3.1 Métricas utilizadas em EDOs

Medidas de performance baseada em comportamento avaliam se EDOs exibem

certos comportamentos que se acreditam ser úteis em ambientes dinâmicos. Exemplos destes
comportamentos são: manter uma alta diversidade durante a execução; rápida recuperação da
performance quando uma mudança ocorre; e limitar a queda de fitness quando uma mudança
ocorre Nguyen e Yao (2012). Este trabalho usa uma métrica de velocidade de convergência após
a modificação.
A métrica de Taxa de Recuperação Absoluta (Absolute Recovery Rate, ou ARR) é
usada para analisar o quão rápido um algoritmo converge para o ótimo global antes da próxima
 53

mudança na instância. Na sua definição original, o cálculo do ARR demanda que o valor
da solução ótima do problema seja conhecido. Entretanto, este valor é desconhecido e uma
adaptação foi necessária, gerando a definição de uma métrica adaptada chamada ARRt , onde o
valor ótimo é substituído pelo melhor valor conhecido (ótimo ou sub-ótimo) que é dada pela
fórmula:

p(i)
∑ [ fbest (i, j) − fbest (i, 1)]
1 m j=1 (5.3)
ARRt = ∑ ,
m i=1 p (i) [ f ∗ (i) − fbest (i, 1)]

onde fbest (i, j) é o valor de fitness da melhor solução desde a última modificação
encontrada pelo algoritmo até a j-ésima geração do período de mudança i, m é o número de
modificações e p (i), i = 1:m é o número de gerações a cada período de modificação i e f ∗ (i) é o
melhor valor conhecido durante a i-ésima modificação. O valor do ARRt será 1 no melhor caso
quando o algoritmo for capaz de se recuperar e convergir imediatamente após a mudança, do
contrário terá uma valor igual a 0 se o algoritmo não for capaz de convergir rapidamente.
Quanto a métrica sobre a variação de performance, Nguyen e Yao (2012) também
cita estudos que desenvolveram medidas para avaliar a habilidade de algoritmos em restringir a
queda (ou subida, em caso de minimização) do fitness quando mudanças ocorrem. A medida
de estabilidade sobre a variação da performance é calculada pela diferença do fitness entre as
medidas de acurácia do algoritmo considerado entre os dois momentos avaliados. As equações
de acurácia (equação 5.4) e estabilidade (equação 5.5) são descritas abaixo:
 
(t) (t)
F bestF,EA − MinF
(t) (5.4)
accuracyF,EA = (t) (t)
MaxF − MinF

(t) (t−1) (t)

stabF,EA = accuracyF,EA − accuracyF,EA , (5.5)

 
(t) (t)
onde F bestF,EA é o fitness da melhor solução no tempo t, MaxF é o maior valor
(t)
de fitness no espaço de busca explorado no tempo t e MinF é o menor valor de fitness no espaço
(t)
de busca explorado. Já o valor de stabF,EA é definido pela diferença da acurácia no tempo t e o
momento imediatamente antes. Nos experimentos realizados neste trabalho o tempo t utilizado é
logo após a ocorrência de uma mudança, entretanto se houver mais de uma modificação, a média
dos valores de estabilidade é calculada.
 54

5.2.3.2 Análise Estatistíca

Para fins estatísticos, cada um dos 18 cenários de execução são simulados 30 vezes
cada. Este número de execuções é sugerido em Arcuri e Briand (2011) e se deve à natureza
estocástica da estratégia de busca. Ao término das simulações, métricas pertencentes à Estatística
Descritiva como média e desvio padrão são calculados para cada um dos 18 cenários.
No entanto, devido à grande variância da amostra, fazer uso de apenas métricas de
Estatística Descritiva pode levar a conclusões equivocadas (ARCURI; BRIAND, 2011). Deste
modo, os autores recomendam a utilização de testes estatísticos para a avaliação de resultados
produzidos por metaheurística.
Um teste estatístico é utilizado quando se pretende verificar se duas ou mais amostras
são estatisticamente diferentes, ou seja, se há diferença significativa entre os resultados gerados
ao fazer uso de configurações distintas. Para estes casos, assume-se uma hipótese nula H0 onde
as amostras comparadas não apresentam diferenças significativas entre si. Duas situações podem
ocorrer: a primeira, chamada Erro 1 ao se rejeitar a hipótese nula quando na verdade ela é
verdadeira. A segunda situação, chamada de Erro 2, ocorre quando aceita-se uma hipótese falsa.
Os testes geram um p-value, que é a probabilidade de ocorrência do Erro 1 na comparação entre
as amostras. Outro elemento encontrado nesse tipo de teste é o nível de significância α, que
representa o maior valor de p-value admitido para rejeitar a hipótese nula (ARCURI; BRIAND,
2011).
Dois tipos de testes podem ser aplicados de acordo com a distribuição probabilística
apresentada pelos dados das amostras. No caso das amostras seguirem uma distribuição normal,
testes paramétricos como o Student T devem ser utilizados, caso as amostras não sigam uma
distribuição normal, recomenda-se o uso de testes não-paramétricos como por exemplo, teste U
de Mann-Whitney (ARCURI; BRIAND, 2011). Dentre os testes não-paramétricos, encontra-se o
Wilcoxon signed-rank que tem por finalidade comparar duas amostras pareadas.
Embora sejam utilizados com muita frequência para demonstrar a diferença esta-
tística entre amostras, os testes de significância por hipóteses nulas não oferecem informações
sobre a magnitude do evento observado, tampouco conferem precisão de estimativa estatística
do efeito da magnitude (NAKAGAWA; CUTHILL, 2007). Para calcular a magnitude entre a
diferença entre amostras testes de magnitude de efeito (effect size) costumam a ser utilizados.
Em termos comparativos um teste de effect size serve para determinar o quão mais eficiente é
uma abordagem em relação a outra através da análise de seus resultados.
 55

Dentre os testes de magnitude de efeito, encontra-se o teste Vargha-Delaney (VARGHA;

VARGHA; DELANEY, 2000), onde a probabilidade de um valor aleatório selecionado de uma
amostra 1 seja numericamente maior que outro valor aleatório de uma amostra 2. A comparação
entre as amostras 1 e 2 é representada por Â12 . O quadro 2 apresenta o nível de magnitude de
efeito em relação ao valor calculado de Â12 .

Quadro 2 – Legenda do Quadro

Magnitude Valores
Negligenciável Â12 <= 0.56
Pequena 0.56 < Â12 <= 0.64
Média 0.64 < Â12 <= 0.71
Grande 0.71 < Â12 <= 1

Fonte – (VARGHA; VARGHA; DELA-

NEY, 2000)

5.3 RESULTADOS E ANÁLISES

A seguir serão apresentados os resultados analisados e os dados relativos ao ex-

perimento automático compreendendo as questões de pesquisa QP1, QP2, QP3 e QP4. Por
limitação de espaço nem todas os dados deste experimento estão aqui dispostos, contudo, estes
podem ser consultados online na página de suporte 2 da pesquisa.

5.3.1 Comparativo entre abordagem tradicional e dinâmica

Esta seção conduz uma análise sobre a instância i_25_10 em seus dois cenários
de execução (acréscimo de pessoas e de tarefas). O percentual de propagação genética, µ é a
variável a ser comparada neste experimento. Em uma abordagem tradicional não há nenhum
reaproveito de conhecimento do espaço de busca no momento que a instância é modificada, logo
não há propagação genética entre diferentes estados da instância. Esta situação é reproduzida
quando µ = 0.
A tabela 3 mostra a média e desvio padrão, realizadas sobre as 30 execuções, do
resultado final obtido após as duas modificações planejadas na instância. Além disso, apresenta
os resultados do teste Â12 (Vargha-Delaney) e apresenta a indicação da diferença estatística
(Wilcoxon signed-rank) entre os valores de fitness de cada configuração de µ com os valores
obtidos sem considerar as preferências, ou seja, quando µ = 0.
2 <http://goes.uece.br/thiagooliveira/rts/>
 56

Tabela 3 – Média e desvio padrão de fitness ao final da primeira e segunda modificação

dos cenários de execução de i_25_10, valores do teste Â12 entre cada
configuração de µ com relação à configuração µ = 0 (abordagem tradicional),
e indicação de diferença estatística ao se variar µ em relação a µ0 .

employee task
instance change µ fitness (avg) fitness (std) µ0 sig fitness (avg) fitness (std) µ0 sig

0,00 235,333 25,541 - - 339,267 19,478 - -

0,30 246,933 21,325 0,63 N 343,533 23,026 0,54 M
first 0,60 251,833 25,767 0,68 N 342,700 25,972 0,52 M
0,90 249,833 27,179 0,63 M 339,500 19,564 0,53 M
1,00 245,933 22,760 0,62 M 334,267 22,975 0,44 O
0,00 173,633 17,135 - - 376,700 22,696 - -
0,30 176,700 20,765 0,55 M 387,933 18,355 0,66 N
second 0,60 186,833 21,689 0,68 N 384,000 26,909 0,58 M
0,90 185,167 27,556 0,63 M 386,600 24,869 0,63 M
1,00 178,133 23,916 0,55 M 389,133 31,417 0,63 M

Fonte – Elaborado pelo autor

Nota – O símbolo M indica que o fitness médio é insignificantemente maior do que o fitness médio obtido com a
configuração de µ0 , O (insignificantemente menor), N (significantemente maior) e H (significantemente
menor), tudo isso considerando-se 0,05 como nível de significância.

A primeira linha de cada um dos momentos de mudança na instância representa a

execução da abordagem tradicional (µ = 0), ou seja, foram produzidos sem considerar um fator
de propagação genética. Por exemplo, no cenário de execução onde a modificação da instância é
o acréscimo de pessoas (employee), pode se verificar que os fitness médios de 235,333 e 173,633
foram alcançados após a primeira e segunda modificação, respectivamente.
Novamente tomando os dados de employee, mas agora analisando as linhas onde µ
= 0,3, isto é, resultados obtidos com a menor taxa de propagação genética testada neste estudo,
verifica-se os valores de fitness médio de 246,933 e 176,700 foram alcançados após a primeira
e segunda modificação. Estes resultados mostram que embora o nível de propagação genética
tenha aumentado entre os experimentos, o resultado médio final após a modificação acabou
aumentando. Este aumento no entretanto é considerado de pequena magnitude (µ0 ≤ 0, 64) por
Â12 e significantemente maior no primeiro caso (N) por Wilcoxon.
Ampliando esta análise para todas os cenários de execução e os 5 valores de µ
utilizados neste experimento, constata-se que o uso de uma taxa de propagação genética acaba
por ter um aumento no valor de fitness, no entanto este aumento é considerado na maioria
dos casos como de pequena magnitude ou até mesmo apresentando uma diferença considerada
insignificante.
 57

Então, respondendo a QP1: "A abordagem dinâmica teria uma diferença significativa
no resultado final em relação a uma abordagem tradicional?", pode-se afirmar que em relação
ao resultado final sobre a instância i_25_10, que o uso de uma abordagem dinâmica não traz
necessariamente um resultado melhor que uma abordagem tradicional. Os resultados mostram
que ao contrário da intuição inicial, os resultados finais, no geral, acabam tendo uma performance
levemente pior em uma abordagem dinâmica. Entretanto, na maior parte dos resultados finais
essa diferença se mostra estatisticamente insignificante.

5.3.2 Análise da evolução da performance após mudanças

O objetivo desta seção é analisar o impacto da mudança da instância sobre o valor

de fitness durante o processo de otimização. Ainda fazendo uso dos dados coletados sobre as
experiências realizadas na instância i_25_10, a figura 13 representa a evolução da média de
fitness no cenário de execução onde uma pessoa é adicionada durante o processo. Já a figura
14 apresenta a evolução da média de fitness no cenário de execução onde 5 novas tarefas são
adicionadas durante o processo. Cada gráfico apresenta as evoluções considerando os diferentes
valores utilizados de µ.

Figura 13 – Evolução fitness médio no cenário de acréscimo de pessoas

Fonte – Elaborada pelo autor.

As mudanças planejadas ocorrem a cada 30 segundos (primeiro momento em 29

segundos e segundo momento em 59 segundos). É possível visualizar nos gráficos que ao atingir
os momentos de mudança uma perturbação ocorre no processo e afeta a convergência até então
 58

atingida pelo processo de otimização.

A figura 13 mostra claramente que a execução usando a abordagem tradicional (linha
vermelha) apresenta um pico no momento da mudança. Este pico evidencia o fato que nenhuma
solução anterior foi reaproveitada. Neste exato momento uma nova população aleatória foi
gerada, o que levou a um fitness distante do valor anterior. As execuções usando abordagem
dinâmica, representadas pelos demais valores de µ, mostram um comportamento semelhante,
onde uma pequena queda em relação ao valor anterior pode ser observada.

Figura 14 – Evolução fitness médio no cenário de acréscimo de tarefas

Fonte – Elaborada pelo autor.

Já na figura 14 pode-se observar que tanto a abordagem tradicional quanto a dinâmica

apresentam um comportamento semelhante. Em ambos os casos o valor do fitness após a mudança
sofre um aumento e em seguida convergem em uma taxa semelhante.
Essas diferenças visuais durante as mudanças na abordagem dinâmica, onde o
acréscimo de uma pessoa apresenta um impacto mais suave em relação ao acréscimo de tarefas,
podem ser explicadas pela representação da solução utilizada e o processo de adaptação. O
acréscimo de uma pessoa tende a diminuir o fitness da solução, pois logo após adaptar as soluções,
a alocação se mantém a mesma, a nova pessoa se encontra sem nenhuma tarefa e as tarefas
alocadas anteriormente serão distribuídas para a nova pessoa no decorrer da execução. Já o
acréscimo de tarefas tende a aumentar o valor do fitness, pois logo após a mudança, as novas
tarefas serão alocadas para uma única pessoa causando um aumento abrupto no valor de fitness.
A velocidade de convergência observada nos gráficos acima pode ser confirmada
 59

com o uso da métrica de taxa de recuperação absoluta (ARRt ). Os valores dessa métrica variam
entre 0 e 1, quanto mais próximo de 1, maior a velocidade de recuperação. Além da taxa
da convergência, outra métrica relevante é a estabilidade da diferença de performance após
a mudança (stabtF,EA ). Assim como a taxa de recuperação absoluta, os valores dessa métrica
variam entre 0 e 1, mas podem ser negativos, caso exista uma melhoria de performance entre os
estados da instância.

Tabela 4 – Valores ARRt calculados por taxa de µ.

µ employee task
ARRt stabtF,EA ARRt stabtF,EA

0,00 0,74 0,45 0,78 0,82

0,30 0,50 -0,05 0,75 0,82
0,60 0,48 -0,03 0,74 0,82
0,90 0,50 -0,03 0,71 0,82
1,00 0,53 -0,04 0,76 0,83

Fonte – Elaborado pelo autor.

Nota – Cálculos efetuados sobre a execução mé-
dia.

A tabela 4 contém os resultados das duas métricas citadas por cenário de execução.
Pode-se observar que os maiores valores absolutos de stabtF,EA estão relacionados às situações
onde há um grande impacto no valor de fitness após a mudança. Contudo, os maiores valores
de ARRt se encontram nas execuções que apresentam picos elevados no momento da mudança.
Esses valores se devem ao fato que a convergência foi mais rápida nesses casos.
A figura 15 representa a relação entre os valores absolutos das métricas ARRt e
stabtF,EA . É possível observar que há um agrupamento claro entre as execuções dinâmicas com
perfil de execução diferente (mudança de pessoas e mudança de tarefas).
Então, respondendo a QP2: "Qual o impacto observado no valor de fitness da solução
corrente no momento da modificação da instância?", pode-se afirmar que o impacto sofrido na
solução da instância i_25_10 depende do tipo de modificação realizada. Em virtude da repre-
sentação da solução adotada pelo algoritmo, o acréscimo de novas tarefas acaba apresentando
um impacto muito forte na solução corrente. Além do alto impacto, a abordagem dinâmica
apresenta uma velocidade de convergência semelhante a de uma abordagem tradicional. Já o
acréscimo de uma nova pessoa à instância fez com que a abordagem dinâmica apresentasse um
impacto pequeno no valor de fitness e com uma baixa velocidade de convergência. Este pequeno
impacto evidencia um grande aproveitamento da solução anterior, entretanto como discutido na
 60

Figura 15 – Relação entre ARRt e stabtF,EA

Fonte – Elaborada pelo autor.

Nota – O diâmetro de cada ponto representa o seu valor de µ. O menor diâmetro representa o valor 0, enquanto
o maior representa o valor 1.

QP1, ele não traz necessariamente um valor final melhor que o valor final de uma abordagem
tradicional, entretanto vale destacar que em casos onde o tempo de execução é um fator limitante,
a abordagem dinâmica possui uma boa vantagem.
Quanto à QP3: "Dentre as abordagens dinâmicas, os valores da taxa de propagação
genética apresentam relação com as métricas de reaproveitamento de soluções?", nos casos
observados onde se faz uso da abordagem dinâmica, os valores adotados por µ apresentaram
um comportamento muito semelhante entre si. No caso do acréscimo de uma nova tarefa, o
comportamento é semelhante até mesmo se comparado a uma abordagem tradicional. Somente
no caso de acréscimo de pessoas que uma diferença maior pode ser observada. Além disso, as
métricas de recuperação absoluta e estabilidade da diferença de performance após a mudança
não apresentam uma relação linear com a taxa de propagação genética. Portanto existe uma
diferença entre abordagens (dinâmica vs tradicional), no entanto entre as abordagens dinâmicas,
a taxa de propagação genética não exerce influência sobre o quão adaptado segue sua execução.

5.3.3 Outros Cenários de Execução

Após as análises realizadas sobre a instância i_25_10, o próximo passo deste trabalho
é explorar novas possibilidades em instâncias semelhantes. Sendo assim, um novo lote de 30
simulações é realizado sobre novas instâncias de mesmo tamanho, mas em situações mais restri-
 61

tivas apresentando um maior número de precedência entre as tarefas. Para efeitos comparativos a
figura 16 apresenta a evolução média das 30 execuções sobre a instância composta de 3 pessoas
e 25 tarefas, em situações onde 10%, 25% e 50% das tarefas apresentam precedência entre si, a
taxa propagação genética µ variando entre 30%, 60% e 90% e nas já citadas situações onde uma
pessoa é acrescida ou 5 novas tarefas são adicionadas.

Figura 16 – Cenários de execução com 25 tarefas.

Fonte – Elaborada pelo autor.

Os resultados coletados sobre cenário de execução contendo 25 tarefas são apresen-

tados na figura 16 mostram que mesmo em cenários mais restritivos a evolução da solução se
comporta de forma semelhante. No caso do acréscimo de uma nova pessoa, a medida que as
restrições aumentam, o impacto após a mudança no valor da solução diminui e a velocidade de
convergência apresenta uma pequena queda. Já o acréscimo de tarefas apresenta um impacto
alto em todos os casos e apresentam uma pequena queda na velocidade de convergência.
Em ambos os casos, os valores do eixo y aumentam devido a quantidade de res-
trições não satisfeitas inicialmente. Os valores de µ apresentaram pouca relevância sobre o
comportamento geral das evoluções em todos os casos.
 62

Figura 17 – Cenários de execução com 50 tarefas.

Fonte – Elaborada pelo autor.

A figura 17 apresenta a evolução média sobre uma instância contendo 50 tarefas

sobre o mesmo cenário de execução do experimento passado. O resultado também é semelhante
ao do experimento passado, entretanto nos cenários com um maior número de precedências
pode-se observar um maior número de perturbações durante o processo. Além disso, o alto
número de restrições começa a afetar no impacto após as mudanças. Esse comportamento, em
especial, pode ser observado no cenário i_50_50_employee, onde pela primeira vez, o impacto
após a mudança se mostrou não favorável.
Por fim, a figura 18 apresenta a evolução média sobre uma instância contendo 100
tarefas sobre o mesmo cenário de execução. Observa-se que as perturbações já ocorrem de
maneira mais visível, que as observações passadas. Desta vez um impacto baixo ou não favorável
nas ocasiões de acréscimo de pessoas pode ser notado em todas as ocasiões. Já no acréscimo de
tarefas os diferentes cenários apresentaram um comportamento semelhante aos da simulação
com 50 tarefas, com uma velocidade de convergência mais baixa e com uma maior ocorrência
de perturbações.
Nos casos com maior número de tarefas e precedências, pode-se perceber que há
 63

Figura 18 – Cenários de execução com 100 tarefas.

Fonte – Elaborada pelo autor.

um número maior de perturbações. Isso se deve pelo fato de o espaço de busca a ser explorado
ser maior em instâncias maiores e um número maior de restrições reflete em punições maiores
para o valor de fitness. É possível que a convergência obtida nesses casos seja prematura, ou
seja, o tempo utilizado no experimento (30 segundos) se mostra insuficiente para atingir uma
convergência real nesta escala.
Apesar do comportamento semelhante apresentados em alguns gráficos, vale ressaltar
que a escala de valores apresentados no eixo y aumentam a medida que o tamanho da instância e
sua complexidade (precedências) crescem.
Portanto, respondendo à QP4: "O mesmo comportamento observado na abordagem
dinâmica pode ser verificado em instâncias com um maior número de variáveis e restrições?",
pode-se dizer que os diferentes valores adotados por µ no experimento mostraram um resultado
muito semelhante nas simulações com diferentes cenários de execução. Mesmo nos casos onde
o impacto não se apresentou favorável, as execuções com diferentes valores de µ apresentaram
um comportamento semelhante.
 64

5.4 AMEAÇAS À VALIDADE

Segundo o trabalho de Barros e Neto (2011), um conjunto de fatores pode ameaçar

a validade de experimentos conduzido em SBSE. Estes fatores abrangem desde o projeto até
a execução de estudos empíricos. Tais ameaças são classificadas como: Ameaças à Validade
Interna, Ameaça à Validade Externa, Ameaças à Validade de Construção e Ameaças à Validade
de Conclusões.
No que se refere à Validade Interna, pode-se ressaltar que os resultados obtidos
poderiam ser diferentes caso os parâmetros utilizados no AG fossem diferentes. Além disso
todas as instâncias e suas variações são artificiais, ou seja, foram geradas de forma aleatória.
Quanto à Validade Externa dos experimentos, destaca-se que embora este trabalho
procure explorar o comportamento de uma abordagem dinâmica com instâncias apresentando
diversas variações de tamanho e número de restrições, as modificações propostas podem não
refletir um comportamento comumente encontrado no mundo real. Um exemplo disto seria o
acréscimo constante de um bloco de 5 novas tarefas a cada modificação, ou até mesmo a ausência
de simulações com remoção pessoas ou tarefas. Além disso, outro fator limitante em relação
aos experimentos foi o tempo de duração das simulações, que por ser extenso, inviabilizou a
realização de simulações fazendo uso de diferentes parâmetros e metodologias.
Sobre a Validade de Construção, o presente trabalho apresentou um método de
estimativa de execução de tarefas elaborado, entretanto os resultados obtidos não apresentam
nenhuma base concreta em relação a sua efetividade de estimativa. Embora estas estimativas
tenham servido de base para o trabalho, a precisão das mesmas não interfere na observação sobre
os impactos das mudanças realizadas.
Por fim, quanto à Validade de Conclusão, este trabalho fez uso de um AG, que
devido ao seu caráter estocástico, produz resultados diferentes em cada execução. Por conta
deste fator, cada cenário de execução é executado 30 vezes, assim recomenda Arcuri e Briand
(2011). As constatações também fizeram uso de testes estatísticos e gráficos contendo a média
das 30 execuções.

5.5 CONCLUSÃO

Neste capítulo foi explicado como o estudo empírico realizado neste trabalho foi
conduzido. Inicialmente, foram determinadas quatro questões de pesquisa que guiaram este
estudo. A seguir elucidou-se como as instâncias utilizadas neste trabalho foram geradas, os
 65

detalhes utilizados na técnica de busca e as métricas de avaliação utilizadas.

Para a avaliação da abordagem foi utilizado um experimento com diversos cenários
de execução diferentes. Dentre os cenários, encontram-se diferentes parâmetros de taxa de
propagação genética, modificações de natureza diferente, tamanho da instância e diferentes
quantidades de precedência.
Pelos resultados coletados, pode-se constatar que a natureza da modificação causa
um impacto diferente no espaço de busca. No caso do acréscimo de pessoa, a abordagem
dinâmica consegue obter um bom aproveitamento de solução e deste modo obtém uma vantagem
inicial em relação a uma abordagem tradicional. Já o acréscimo de novas tarefas causa um
impacto grande no espaço de busca, de modo que a abordagem dinâmica não oferece vantagens
em relação a uma abordagem tradicional. Além disso, as diferentes taxas de propagação genética
utilizadas não mostraram resultados significativamente diferentes entre si.
Por fim, foram discutidos aspectos que podem ameaçar a validade dos experimentos
assim como as eventuais medidas adotadas para minimizar os potenciais prejuízos.
 66

6 CONSIDERAÇÕES FINAIS

Este trabalho teve como objetivo propor, implementar e analisar o comportamento

de uma abordagem dinâmica na resolução do Problema de Agendamento de Tarefas em Projetos
de Software. Para a realização do estudo foram criadas instâncias artificiais e planejadas várias
modificações de natureza diferente ao longo do tempo.
Através do estudo realizado, constatou-se que em situações de acréscimo de pessoas
ao problema proposto, a abordagem dinâmica possui uma clara vantagem em relação a uma
abordagem tradicional no que se diz respeito ao aproveitamento de soluções. Contudo, um maior
reaproveitamento de soluções no momento da mudança, não traz necessariamente um resultado
melhor ao fim do tempo utilizado no experimento. Já em modificações com o acréscimo de tarefas,
devido a representação da solução utilizada no processo, a abordagem dinâmica não apresentou
uma diferença significativa em relação à abordagem tradicional. Além disso as simulações foram
executadas em instâncias maiores, com um maior número de precedências entre suas tarefas. O
comportamento apresentado por essas instâncias foi semelhante ao comportamento da instância
menor, embora tenham apresentado uma maior dificuldade na convergência da solução. Ou seja,
a medida que a complexidade e tamanho do problema aumentam, mais longo torna-se o período
de convergência da solução.
Por fim, a pesquisa mostrou que dependendo da natureza da modificação realizada
na instância, o conhecimento sobre o espaço de busca adquirido pode ser reaproveitado e desta
forma aumentar a velocidade de convergência da solução.

6.1 CONTRIBUIÇÕES DO TRABALHO

Dentre as principais contribuições deste trabalho, pode-se destacar o desenvolvi-

mento de uma ferramenta que implementa as principais ideias mencionadas neste trabalho, onde
é possível acompanhar toda a evolução da solução através de recursos gráficos.
Além disso, tem-se como contribuição a proposta de uma estratégia de alocação
de tarefas dinâmicas, entregando ao responsável pelo planejamento de execução de tarefas um
planejamento eficiente de distribuição de tarefas que se mostra reativo às modificações tão
comuns em cenários reais, ao tempo em que reduz o trabalho humano de planejamento das
tarefas.
 67

6.2 LIMITAÇÕES

Como fator limitante destaca-se o método utilizado para estimar o tempo de execução
de uma tarefa, o método utilizado pode ser melhorado com o uso de técnicas de Mineração de
Dados e Aprendizado de Máquina.
Além disso, durante o processo de otimização o período estimado pode sofrer uma
alteração que se adéque a situações não planejadas, como impossibilidade da execução de uma
tarefa por motivos externos.

6.3 TRABALHOS FUTUROS

Os resultados alcançados e as conclusões obtidas demonstraram que a abordagem

proposta neste trabalho possui um bom aproveitamento de soluções em determinadas condições
de mudança. Este fato aponta a necessidade de aprofundar e evoluir a pesquisa em determinados
aspectos. Por isso, segue abaixo uma lista de trabalhos futuros que podem complementar esta
pesquisa:
a) Testar novas adaptações de solução. Fazer uso de heurísticas a fim de diminuir o
impacto pós mudança no caso de acréscimo de tarefas;
b) Considerar a passagem do tempo como um fator de mudança da instância, onde
tarefas já executadas não precisariam mais ser replanejadas;
c) Para tornar a estimativa de tempo do planejamento total mais precisa, se faz
necessário uma estimativa mais precisa para cada tarefa. Isso abre espaço para
futuros estudos com uma abordagem interatiiterativa e dinâmica ou até mesmo
fazendo uso de técnicas de Machine Learning para estimar o tempo de realização
de novas tarefas baseado no tempo estimado de tarefas já realizadas.
d) Fazer uso de outras técnicas de otimização, incluindo outras metaheurísticas,
ou até mesmo técnicas que diminuam o espaço de busca como Programação
Restritiva.
 68

REFERÊNCIAS

AKKER, M. van den; BRINKKEMPER, S.; DIEPEN, G.; VERSENDAAL, J. Flexible re-
lease planning using integer linear programming. In: Proceeding of the 11th Internatio-
nal Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ
’05). Porto, Portugal: Essener Informatik Beitrage, 2005. p. 247–262. Disponível em: <http:
//www.sse.uni-essen.de/refsq/downloads/17.pdf>. Acesso em: 01 mai. 2017.

ARCURI, A.; BRIAND, L. A practical guide for using statistical tests to assess randomized
algorithms in software engineering. In: Proceedings of the 33rd International Conference
on Software Engineering. New York, NY, USA: ACM, 2011. (ICSE ’11). Disponível em:
<http://doi.acm.org/10.1145/1985793.1985795>. Acesso em: 09 jun. 2016.

BACK, T.; FOGEL, D. B.; MICHALEWICZ, Z. (Ed.). Basic Algorithms and Operators. 1st.
ed. Bristol, UK, UK: IOP Publishing Ltd., 1999. ISBN 0750306645.

BAGNALL, A.; RAYWARD-SMITH, V.; WHITTLEY, I. The next release problem. Informa-
tion and Software Technology, v. 43, n. 14, p. 883 – 890, 2001. ISSN 0950-5849. Disponível
em: <http://www.sciencedirect.com/science/article/pii/S095058490100194X>. Acesso em: 23
set. 2016.

BARROS, M. de O.; NETO, A. C. D. Threats to Validity in Search-based Software Engine-

ering Empirical Studies. [S.l.], 2011. Disponível em: <http://www.seer.unirio.br/index.php/
monografiasppgi/article/viewFile/1479/1307>. Acesso em: 26 jul. 2016.

BOUKTIF, S.; SAHRAOUI, H.; ANTONIOL, G. Simulated annealing for improving software
quality prediction. In: Proceedings of the 8th Annual Conference on Genetic and Evolutio-
nary Computation (GECCO ’06). Seattle, Washington, USA: ACM, 2006. p. 1893–1900.

BUI, L. T.; MICHALEWICZ, Z.; PARKINSON, E.; ABELLO, M. B. Adaptation in Dyna-

mic Environments: A Case Study in Mission Planning. IEEE Transactions on Evolutionary
Computation, v. 16, n. 2, April 2012.

DORIGO, M.; BLUM, C. Ant colony optimization theory: A survey. Theor. Comput. Sci.,
Elsevier Science Publishers Ltd., Essex, UK, v. 344, n. 2-3, p. 243–278, nov. 2005. ISSN
0304-3975. Disponível em: <http://dx.doi.org/10.1016/j.tcs.2005.05.020>. Acesso em: 21 set.
2016.

DUBACH, C.; CAVAZOS, J.; FRANKE, B.; O’BOYLE, M.; FURSIN, G.; TEMAM, O. Fast
compiler optimisation evaluation using code-feature based performance prediction. In: Pro-
ceedings of the 4th International Conference on Computing frontiers. Ischia, Italy: ACM,
2007. p. 131–142.

FÁVERO, L.; BELFIORE, P. Pesquisa operacional para cursos de engenharia. [S.l.]: Elsevier
Brasil, 2012. ISBN 9788535263350.

FEO, T. A.; RESENDE, M. G. C. Greedy randomized adaptive search procedures. Journal

of Global Optimization, v. 6, n. 2, p. 109–133, Mar 1995. ISSN 1573-2916. Disponível em:
<http://dx.doi.org/10.1007/BF01096763>. Acesso em: 13 ago. 2016.

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design Patterns: Elements of
Reusable Object-oriented Software. Boston, MA, USA: Addison-Wesley Longman Publishing
Co., Inc., 1995. 326–337 p. ISBN 0-201-63361-2.
 69

GLOVER, F.; LAGUNA, M. Tabu Search. Norwell, MA, USA: Kluwer Academic Publishers,
1997. ISBN 079239965X.

HARMAN, M. The current state and future of search based software engineering. In: 2007 Fu-
ture of Software Engineering. Washington, DC, USA: IEEE Computer Society, 2007. (FOSE
’07), p. 342–357. ISBN 0-7695-2829-5. Disponível em: <http://dx.doi.org/10.1109/FOSE.2007.
29>. Acesso em: 19 set. 2016.

HARMAN, M.; CLARK, J. A. Metrics are fitness functions too. In: Proceedings of the
10th IEEE International Symposium on Software Metrics (METRICS ’04). Chicago, USA:
IEEE, 2004. p. 58–69.

HARMAN, M.; JONES, B. F. Search-based software engineering. Information and Software

Technology, v. 43, n. 14, 2001. ISSN 0950-5849. Disponível em: <http://www.sciencedirect.
com/science/article/pii/S0950584901001896>. Acesso em: 30 ago. 2016.

HLADIK, P.-E.; CAMBAZARD, H.; DÉPLANCHE, A.-M.; JUSSIEN, N. Solving a real-time

allocation problem with constraint programming. J. Syst. Softw., Elsevier Science Inc., New
York, NY, USA, v. 81, n. 1, jan. 2008. ISSN 0164-1212. Disponível em: <http://dx.doi.org/10.
1016/j.jss.2007.02.032>. Acesso em: 26 jul. 2016.

JIN, N.; YAO, X. Heuristic optimization for software project management with impacts of
team efficiency. In: Proceedings of the IEEE Congress on Evolutionary Computation, CEC
2014, Beijing, China, July 6-11, 2014. [s.n.], 2014. Disponível em: <http://dx.doi.org/10.1109/
CEC.2014.6900527>. Acesso em: 05 abr. 2017.

KOREL, B. Automated software test data generation. IEEE Transactions on Software Engi-
neering, v. 16, n. 8, p. 870–879, August 1990.

LEMARÉCHAL, C. S. boyd, l. vandenberghe, convex optimization, cambridge university press,

2004 hardback, isbn 0 521 83378 7. European Journal of Operational Research, v. 170, n. 1,
2006. Disponível em: <http://dblp.uni-trier.de/db/journals/eor/eor170.html#Lemarechal06>.
Acesso em: 09 jun. 2016.

LINDEN, R. Algoritmos Genéticos (2a edição). [S.l.]: BRASPORT, 2006. ISBN

9788574523736.

LOBO, E. L. M. Uma Solução Do Problema De Horário Escolar Via Algoritmo Genético

Paralelo. Dissertação (Mestrado) — Centro Federal de Educação Tecnológica de Minas Gerais,
2005.

LUNA, F.; GONZÁLEZ-ÁLVAREZ, D. L.; CHICANO, F.; VEGA-RODRÍGUEZ, M. A. The

software project scheduling problem: A scalability analysis of multi-objective metaheuristics.
Appl. Soft Comput., v. 15, 2014. Disponível em: <http://dx.doi.org/10.1016/j.asoc.2013.10.
015>. Acesso em: 17 jul. 2017.

MILLER, W.; SPOONER, D. L. Automatic generation of floating-point test data. IEEE Trans.
Software Eng., v. 2, n. 3, p. 223–226, 1976. Disponível em: <http://dblp.uni-trier.de/db/journals/
tse/tse2.html#MillerS76>. Acesso em: 23 set. 2016.

NAKAGAWA, S.; CUTHILL, I. C. Effect size, confidence interval and statistical significance: a
practical guide for biologists. Biological Reviews, v. 82, n. 4, 2007.
 70

NGUYEN, T. T.; YANG, S.; BRANKE, J. Evolutionary dynamic optimization: A survey

of the state of the art. Swarm and Evolutionary Computation, v. 6, 2012. Disponível em:
<http://dblp.uni-trier.de/db/journals/swevo/swevo6.html#NguyenYB12>. Acesso em: 15 set.
2016.
NGUYEN, T. T.; YAO, X. Continuous dynamic constrained optimization&#x2014;the challenges.
Trans. Evol. Comp, IEEE Press, Piscataway, NJ, USA, v. 16, n. 6, dez. 2012. ISSN 1089-778X.
Disponível em: <http://dx.doi.org/10.1109/TEVC.2011.2180533>. Acesso em: 26 jul. 2016.
POLI, R.; KENNEDY, J.; BLACKWELL, T. Particle swarm optimization. Swarm Intelligence,
v. 1, n. 1, p. 33–57, Jun 2007. ISSN 1935-3820. Disponível em: <http://dx.doi.org/10.1007/
s11721-007-0002-0>. Acesso em: 03 jul. 2016.
PRESSMAN, R. R. Software Engineering: A Practitioner’s Approach. 7th. ed. [S.l.: s.n.],
2011. ISBN 978-85-8055-044-3.
REZENDE, S. Sistemas inteligentes: fundamentos e aplicações. Manole, 2003. ISBN
9788520416839. Disponível em: <https://books.google.com.br/books?id=UsJe\_PlbnWcC>.
SEGARAN, T. Programming Collective Intelligence. First. [S.l.]: O’Reilly, 2007. ISBN
9780596529321.
SENG, O.; STAMMEL, J.; BURKHART, D. Search-based determination of refactorings for
improving the class structure of object-oriented systems. In: Proceedings of the 8th annual
Conference on Genetic and Evolutionary Computation (GECCO ’06). Seattle, Washington,
USA: ACM, 2006. p. 1909–1916.
SIMÕES, A.; COSTA, E. An immune system-based genetic algorithm to deal with dynamic
environments: Diversity and memory. In: PEARSON, D.; STEELE, N.; ALBRECHT, R. (Ed.).
Artificial Neural Nets and Genetic Algorithms, Proceedings. [S.l.: s.n.], 2003. (SPRINGER
COMPUTER SCIENCE). ISBN 3-211-00743-1. International Conference on Artificial Neural
Nets and Genetic Algorithms, ROANNE, FRANCE, APR 23-25, 2003.
SKIŚCIM, C. C.; GOLDEN, B. L. Optimization by simulated annealing: A preliminary com-
putational study for the tsp. In: Proceedings of the 15th Conference on Winter Simulation -
Volume 2. Piscataway, NJ, USA: IEEE Press, 1983. (WSC ’83), p. 523–535. Disponível em:
<http://dl.acm.org/citation.cfm?id=800044.801546>. Acesso em: 03 jul. 2016.
SOMMERVILLE, I. Software Engineering. 6th. ed. [S.l.: s.n.], 2001. ISBN 0-201-39815-X.
VARGHA, A.; VARGHA, A.; DELANEY, H. D. A critique and improvement of the cl common
language effect size statistics of mcgraw and wong. Journal of Educational and Behavioral
Statistics, v. 25, n. 2, p. 101–132, 2000.
WADA, H.; SUZUKI, J.; YAMANO, Y.; OBA, K. Evolutionary deployment optimization for
service-oriented clouds. Software: Practice and Experience, v. 41, n. 5, p. 469–493, April
2011.
WILHELMSTÖTTER, F. JENETICS Library user’s manual. 2016. <http://jenetics.io/
manual/manual-3.6.0.pdf>. Acesso em: 19 out. 2016.
WU, Z.; TANG, J.; KWONG, C. K.; CHAN, C. Y. An optimization model for reuse scenario
selection considering reliability and cost in software product line development. International
Journal of Information Technology & Decision Making, v. 10, n. 5, p. 811–841, 2011.
 71

XIAO, J.; AO, X.-T.; TANG, Y. Solving software project scheduling problems with ant colony
optimization. Computers & OR, v. 40, n. 1, 2013. Disponível em: <http://dblp.uni-trier.de/db/
journals/cor/cor40.html#XiaoAT13>. Acesso em: 19 set. 2016.

ZHANG, Y.; HARMAN, M.; MANSOURI, A. The SBSE Repository: A repository and
analysis of authors and research articles on Search Based Software Engineering. CREST
Centre, UCL, 2016. Disponível em: <http://crestweb.cs.ucl.ac.uk/resources/sbse_repository/>.
Acesso em: 28 set. 2016.