Embed Size (px)
Citation preview
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
ALOCAÇÃO DE RECURSOS HUMANOS APLICADA A
SOLICITAÇÕES DE MUDANÇA DE SOFTWARE
RICARDO VOIGT
BLUMENAU
2012
2012/1-25
RICARDO VOIGT
ALOCAÇÃO DE RECURSOS HUMANOS APLICADA A
SOLICITAÇÕES DE MUDANÇA DE SOFTWARE
Trabalho de Conclusão de Curso submetido à
Universidade Regional de Blumenau para a
obtenção dos créditos na disciplina Trabalho
de Conclusão de Curso II do curso de Ciência
da Computação — Bacharelado.
Prof. Everaldo Artur Grahl, Mestre - Orientador
BLUMENAU
2012
2012/1-25
ALOCAÇÃO DE RECURSOS HUMANOS APLICADA A
SOLICITAÇÕES DE MUDANÇA DE SOFTWARE
Por
RICARDO VOIGT
Trabalho aprovado para obtenção dos créditos
na disciplina de Trabalho de Conclusão de
Curso II, pela banca examinadora formada
por:
______________________________________________________
Presidente: Prof. Everaldo Artur Grahl, Mestre – Orientador, FURB
______________________________________________________
Membro: Prof. Marcel Hugo, Mestre – FURB
______________________________________________________
Membro: Prof. Alexander Roberto Valdameri, Mestre – FURB
Blumenau, 11 de julho de 2012
Dedico este trabalho a minha família, amigos e
especialmente a todos que de alguma forma
me contribuíram durante a sua realização.
AGRADECIMENTOS
À minha família, que sempre esteve presente em minha vida.
Aos meus amigos, pela compreensão de minha ausência em função do tempo dedicado
ao trabalho e por sempre me apoiarem em momentos difíceis.
À minha namorada Vanessa, pela motivação, compreensão e carinho.
Ao meu orientador, Everaldo Artur Grahl, por ter acreditado na conclusão deste
trabalho.
Ao colega Charles Ristow, por ter me apoiado na interpretação do algoritmo utilizado
neste trabalho.
Tenho certeza que este é apenas mais um dos inúmeros passos que darei em minha
vida, mas é o início de um novo fim.
Cada sonho que você deixa pra trás, é um
pedaço do seu futuro que deixa de existir.
Steve Jobs
RESUMO
Este trabalho apresenta a especificação e implementação de uma ferramenta que automatiza o
processo de alocação de recursos humanos aplicado a solicitação de mudança de software. A
automatização do processo ocorre através do algoritmo genético multiobjetivo NSGA-II que
implementa o conceito de dominância. Além da alocação automática, a ferramenta suporta
também a alocação manual para a composição de um calendário de recursos que representa
visualmente a alocação. Para sua implementação foram utilizadas as tecnologias ASP.NET
MVC Framework e Entity Framework.
Palavras-chave: Alocação de recursos humanos. Solicitação de mudança de software.
Algoritmo genético. NSGA-II.
ABSTRACT
This paper presents the specification and implementation of a tool that automates the process
of allocation of resources applied to software change request. The automation of the process
occurs through the multiobjective genetic algorithm NSGA-II, which implements the concept
of dominance. In addition to the automatic allocation, the tool also supports the allocation
manual for the composition of a resource calendar that visually represents the allocation. For
its implementation technologies were used ASP.NET MVC Framework and Entity
Framework.
Key-words: Allocation of human resources. Request for change of software. Genetic
algorithm. NSGA-II.
LISTA DE ILUSTRAÇÕES
Figura 1 - Processos de identificação de mudanças de software .............................................. 16
Figura 2 - Operações de (a) ordenação, (b) cálculo da distância de povoamento e (c) seleção
por comparação de povoamento ............................................................................ 19
Figura 3 - NSGA-II .................................................................................................................. 20
Figura 4 - Processos fornecidos na norma NBR ISO/IEC 12207............................................. 21
Figura 5 - Fluxo de solicitação do padrão MVC ...................................................................... 23
Figura 6 - Tela de visualização de alocações ........................................................................... 25
Figura 7 - Tela do Resource Management com tabela de alocação de recursos ...................... 26
Figura 8 - Diagrama de casos de uso da ferramenta ................................................................. 29
Figura 9 - Diagrama de classes da camada de modelo da ferramenta ...................................... 31
Figura 10 – Estrutura de classes de controle ............................................................................ 33
Figura 11 - Diagrama da classe AlocacaoController .................................................... 33
Figura 12 – Estrutura de views da ferramenta .......................................................................... 34
Figura 13 - Diagrama de sequência para alocação automática de recursos .............................. 35
Figura 14 - Diagrama de atividades do processo de alocação .................................................. 36
Figura 15 - Diagrama entidade relacionamento ....................................................................... 40
Quadro 1 - Método Index, exemplo de utilização da tecnologia LINQ na ferramenta ......... 42
Quadro 2 – Cálculo pontuação recursos ................................................................................... 43
Quadro 3 – Comparação da pontuação dos recursos ................................................................ 45
Quadro 4 - Método CrowdingDistance componente do NSGA-II ................................... 46
Quadro 5 - Método CalculaDiasInicio .......................................................................... 46
Quadro 6 – Método OrdenaCrowd ....................................................................................... 47
Quadro 7 – Método CalculaRank ....................................................................................... 47
Quadro 8 – Método DiaUtil ................................................................................................. 48
Quadro 9 – Método Feriado ................................................................................................. 49
Quadro 10 – Método Restricao .......................................................................................... 49
Figura 16 - Classe AlocacaoRecurso ................................................................................ 50
Quadro 11 – Método GravarAlocacao .............................................................................. 52
Quadro 12 – Requisição AJAX para carregamento das alocações para o calendário .............. 52
Figura 17 - Tela de visualização do calendário de alocações ................................................... 53
Figura 18 - Barra de menus do calendário de recursos............................................................. 54
Figura 19 - Fluxo de funcionamento da ferramenta ................................................................. 54
Figura 20 - Tela principal da ferramenta .................................................................................. 55
Figura 21 - Tela de prioridades contendo as informações principais ....................................... 55
Figura 22 - Menu principal da ferramenta ................................................................................ 56
Figura 23 - Menu parâmetros e subitens .................................................................................. 56
Figura 24 - Menu cadastros básicos e subitens ........................................................................ 57
Figura 25 - Menu recursos e subitens ....................................................................................... 57
Figura 26 - Cadastro de funções ............................................................................................... 58
Figura 27 - Cadastro de habilidades ......................................................................................... 58
Figura 28 – Tela de habilidades ................................................................................................ 59
Figura 29 - Cadastro de recursos .............................................................................................. 59
Figura 30 - Tela de recursos com destaque para ícones de associação .................................... 60
Figura 31 - Associação de atitudes ........................................................................................... 60
Figura 32 - Associação de conhecimento ao recurso ............................................................... 61
Figura 33 - Associação de habilidade ao recurso ..................................................................... 61
Figura 34 - Criação de restrição ao recurso .............................................................................. 62
Figura 35 - Cadastro de solicitação de mudança ...................................................................... 63
Figura 36 - Menu de alocação da ferramenta ........................................................................... 64
Figura 37 – Calendário de recursos e alocações ....................................................................... 65
Figura 38 - Legenda de restrição de folga no calendário de recursos e alocações ................... 65
Figura 39 - Legenda de feriado no calendário de recursos e alocações ................................... 65
Figura 41 - Alocação manual de solicitação de mudança e recurso ......................................... 66
Figura 42 - Atalho para alocação manual de solicitação de mudança ...................................... 67
Quadro 13 – Comparação das ferramentas ............................................................................... 69
Figura 43 - Resultado da alocação gerada nos testes................................................................ 69
LISTA DE SIGLAS
AJAX - Asynchronous Javascript And XML
API - Application Programming Interface
DER – Diagrama Entidade Relacionamento
EA – Enterprise Architect
HTTP – Hypertext Transfer Protocol
LINQ – Language Integrated Query
MVC – Model View Controller
RF - Requisito Funcional
RNF - Requisito Não Funcional
SQL - Structured Query Language
UML – Unified Modeling Language
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 13
1.1 OBJETIVOS DO TRABALHO ........................................................................................ 14
1.2 ESTRUTURA DO TRABALHO ...................................................................................... 14
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 15
2.1 GESTÃO DE MUDANÇAS ............................................................................................. 15
2.2 RECURSOS HUMANOS ................................................................................................. 17
2.3 ALGORITMO GENÉTICO MULTIOBJETIVO NSGA-II ............................................. 18
2.4 NORMA ISO/IEC 12207 .................................................................................................. 20
2.4.1 Processo de resolução de problemas de software ........................................................... 21
2.5 ASP.NET MVC ................................................................................................................. 22
2.6 TRABALHOS CORRELATOS ........................................................................................ 24
2.6.1 Planejamento de alocação de recursos humanos em projetos ......................................... 24
2.6.2 Resource Management .................................................................................................... 25
3 DESENVOLVIMENTO .................................................................................................... 27
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ....................... 27
3.2 ESPECIFICAÇÃO ............................................................................................................ 28
3.2.1 Diagrama de Casos de Uso ............................................................................................. 28
3.2.2 Diagrama de classes ........................................................................................................ 30
3.2.3 Diagrama de sequência ................................................................................................... 34
3.2.4 Diagrama de atividades ................................................................................................... 35
3.2.4.1 Seleção das solicitações de mudanças e ordenação por ordem de prioridade .............. 37
3.2.4.2 Seleção dos recursos ..................................................................................................... 37
3.2.4.3 Cálculo da pontuação de cada recurso para cada solicitação ....................................... 37
3.2.4.4 Comparação dos recursos entre si para determinar se é dominante, dominado ou
gerador .......................................................................................................................... 37
3.2.4.5 Ordenação das listas geradas ........................................................................................ 38
3.2.4.6 Cálculo de crowding distance e ordenação .................................................................. 38
3.2.4.7 Cálculo de rank ............................................................................................................. 38
3.2.4.8 Gravar a alocação do recurso ........................................................................................ 39
3.2.4.9 Apresentação dos resultados ......................................................................................... 39
3.2.5 Diagrama de entidade relacionamento ............................................................................ 39
3.3 IMPLEMENTAÇÃO ........................................................................................................ 40
3.3.1 Técnicas e ferramentas utilizadas.................................................................................... 40
3.3.2 Desenvolvimento da ferramenta ..................................................................................... 42
3.3.2.1 Cálculo da pontuação de recursos ................................................................................. 42
3.3.2.2 Comparação dos recursos ............................................................................................. 44
3.3.2.3 Crowding distance e ordenação .................................................................................... 46
3.3.2.4 Cálculo de rank ............................................................................................................. 47
3.3.2.5 Gravar a alocação do recurso ........................................................................................ 47
3.3.2.6 Apresentação dos resultados ......................................................................................... 52
3.3.3 Operacionalidade da implementação .............................................................................. 54
3.3.3.1 Cadastros ....................................................................................................................... 56
3.3.3.2 Alocação automática ..................................................................................................... 63
3.3.3.3 Visualização da alocação .............................................................................................. 64
3.3.3.4 Alocação manual .......................................................................................................... 66
3.4 RESULTADOS E DISCUSSÃO ...................................................................................... 67
4 CONCLUSÕES .................................................................................................................. 71
4.1 EXTENSÕES .................................................................................................................... 72
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 73
APÊNDICE A – Descrições dos Casos de Uso ..................................................................... 76
13
1 INTRODUÇÃO
Os projetos de desenvolvimento de software têm atendido a necessidades cada vez
mais complexas, aumentando o número de projetos, que em sua conclusão, extrapolam o
prazo e custo estimados, bem como o não preenchimento dos requisitos de qualidade
definidos pelo cliente (CORREA, 2011). O gerenciamento inadequado de pessoas é uma das
mais significativas contribuições para o fracasso de projetos (SOMMERVILLE, 2003, p.
418).
Segundo Pressman (2002, p. 786), cerca de 70% dos investimentos da área de
desenvolvimento de software são realizados com o objetivo de manter produtos desenvolvidos
anteriormente. A manutenção de software pode ser responsável por mais de 60% de todo o
esforço despendido por uma organização de desenvolvimento e a porcentagem continua a
crescer à medida que mais softwares são produzidos.
Segundo Sommerville (2003, p. 515), é impossível produzir sistemas de qualquer
tamanho que não necessitem de modificações. Assim que o software é colocado em uso,
novos requisitos emergem e os requisitos existentes são modificados à medida que a empresa
que executa este software passa por modificações. Na maioria das empresas as manutenções
são mal estruturadas e feitas de maneira desorganizada e individualizada, quase que
intuitivamente, sem cumprimento de métodos ou padrões específicos (HOPPE, 1999, p. 15).
Preocupados com as constantes mudanças nos sistemas, muitas empresas optam por processos
que contribuam no gerenciamento destas mudanças.
Segundo Brasil Filho et al. (2006), a alocação de recursos humanos é uma atividade
importante e complexa na execução de projetos. Normalmente não é um processo
automatizado, uma vez que tipicamente se baseia em experiência pessoal sem o uso de
modelos. Os gerentes de projeto têm de solucionar problemas técnicos e não técnicos,
utilizando a capacidade das pessoas de sua equipe da maneira mais eficaz possível. Esta
atividade não é simples e algoritmos de busca heurística e algoritmos genéticos são utilizados
para resolução deste problema. Nem todas as alocações possibilitam que o maior número de
tarefas sejam alocadas para um profissional, geralmente há uma série de diferentes
combinações de alocações possíveis.
A norma ISO/IEC 12207:2009, que têm processos de software sólidos, trata das
questões relacionadas à resolução de problemas de software que podem ser usadas nas
solicitações de mudança de software (ASSOCIAÇÃO BRASILEIRA DE NORMAS
14
TÉCNICAS, 2009).
Diante do exposto, propõe-se desenvolver uma ferramenta para alocação dinâmica de
recursos humanos aplicada a solicitação de mudança de software. Para isso devem ser
utilizados algoritmos de busca auxiliando assim empresas e gerentes de projetos na alocação
de recursos e definição de prazos.
1.1 OBJETIVOS DO TRABALHO
Este trabalho tem como objetivo desenvolver uma ferramenta de apoio à alocação de
recursos humanos aplicados a solicitações de mudança de software.
Os objetivos específicos do trabalho são:
a) aplicar algoritmo de busca para seleção do melhor recurso humano para a
solicitação;
b) avaliar a aderência da ferramenta ao processo de resolução de problemas de
software da norma ISO/IEC 12207.
1.2 ESTRUTURA DO TRABALHO
Este trabalho está organizado em quatro capítulos: introdução, fundamentação teórica,
desenvolvimento e conclusão.
O segundo capítulo apresenta os aspectos teóricos estudados para o desenvolvimento
do trabalho. São relatados temas como gestão de mudanças, recursos humanos, NSGA-II,
norma ISO/IEC 12207 e tecnologias aplicadas no trabalho. Também são relacionados alguns
trabalhos correlatos.
No terceiro capítulo é abordado o desenvolvimento do trabalho, detalhando os
requisitos, a especificação e a implementação.
Por fim, no quarto capítulo apresentam-se as conclusões deste trabalho, bem como as
sugestões para possíveis extensões.
15
2 FUNDAMENTAÇÃO TEÓRICA
Na seção 2.1 apresenta-se o conceito de gestão de mudanças. Na seção 2.2 e 2.3
apresentam-se respectivamente recursos humanos aplicados a software e o algoritmo genético
multiobjetivo NSGA-II. Na seção 2.4 apresenta-se a norma ISO/IEC 12207 que abrange o
processo de ciclo de vida de software. A seção 2.5 mostra o framework ASP.NET MVC
utilizado para desenvolvimento da ferramenta. Na seção 2.6 são descritos trabalhos correlatos
à ferramenta proposta.
2.1 GESTÃO DE MUDANÇAS
Em todo o desenvolvimento de software, segundo Hirama (2011, p. 131) ocorrem
mudanças. Uma das razões é a mudança de requisitos solicitada pelo cliente ou a mudança em
soluções solicitadas pelos desenvolvedores. Na primeira, o cliente solicita uma mudança por
inclusão de novos requisitos, alteração ou retirada de requisitos já acordados. Normalmente
essas mudanças ocorrem por alterações nos negócios. Na segunda, decisões inadequadas de
projeto ou defeitos detectados levam à necessidade de mudanças. Todas essas mudanças
precisam ser gerenciadas pela simples razão da necessidade de manter a rastreabilidade das
mudanças de versões de produtos e não chegar ao descontrole do desenvolvimento de
software.
O processo de solicitação de mudança é explicado por Sommerville (2003, p. 521) ao
se iniciar um conjunto de pedidos de mudança por parte dos usuários, gerentes ou clientes.
Custo e impacto devem ser analisados para se verificar quanto do sistema será afetado pela
alteração e quanto poderá custar para desenvolver esta mudança.
O gerenciamento de mudanças, segundo Sommerville (2003, p. 554), deve entrar em
ação quando o software ou a documentação associada estiver sob o controle da equipe de
gerenciamento de configuração. As tarefas sugeridas são semelhantes às tarefas da atividade
de controle de modificação definida por Pressman (2002, p. 228), ou seja, inicia-se com o
preenchimento de um Formulário de Solicitação de Mudança (FSM) e o registro do mesmo
num banco de dados de configuração. Em seguida a solicitação é analisada. Caso seja válida,
avalia-se o impacto da mudança, o seu custo e o de outros componentes afetados. A avaliação
16
então é submetida a um comitê de controle de mudança que, se aprovar, encaminha o software
para a equipe de desenvolvimento ou manutenção para que as modificações sejam realizadas.
Por fim, realiza-se uma reavaliação das mudanças implementadas antes que uma nova versão
ou release seja construída.
Os problemas relativos à alteração de um sistema contribuem para o alto custo da
manutenção do software, afirma Pfleerger (2004, p. 391). Na década de 80 a manutenção
representava 40 a 60 por cento do custo total do ciclo de vida de um sistema. No ano de 2000,
os custos de manutenção aumentaram em até 80 por cento do custo referente ao tempo de vida
de um sistema.
Em todas as organizações, as propostas de mudança no sistema são os acionadores
para a evolução, afirma Sommerville (2007, p. 166). As propostas de mudanças podem vir de
requisitos já existentes que não tenham sido implementados no release do sistema,
solicitações de novos requisitos, relatórios de bugs do sistema apontados pelos stakeholders e
novas ideias para melhoria do software vindas da equipe de desenvolvimento. Os processos
de identificação de mudanças e de evolução de sistema são cíclicos e continuam durante toda
a vida de um sistema (Figura 1).
Fonte: Sommerville (2011, p. 166).
Figura 1 - Processos de identificação de mudanças de software
Segundo Sommerville (2007, p. 167) em muitas ocasiões, as solicitações de mudança
são relacionadas a problemas de sistema, que devem ser resolvidos com urgência. Essas
mudanças podem surgir por três motivos:
Processo de identificação de mudanças
Processo de evolução de software
Novo sistema Propostas de mudança
17
a) na ocorrência de um problema grave no sistema, precisa ser corrigido para permitir
a continuidade do funcionamento normal;
b) as alterações no ambiente operacional dos sistemas tiverem efeitos inesperados que
interrompam o funcionamento normal;
c) na existência de mudanças inesperadas no funcionamento do negocio que executa
o sistema, como o surgimento de novos concorrentes ou a introdução de nova
legislação que afete o sistema.
2.2 RECURSOS HUMANOS
Para Vargas (2003, p. 101), o gerenciamento dos recursos humanos tem como objetivo
central fazer o melhor uso dos indivíduos envolvidos no projeto. Todos os resultados do
projeto podem ser vistos como fruto das relações humanas e das habilidades interpessoais dos
envolvidos. O processo de gestão de recursos humanos garante o fornecimento de uma equipe
com experiência, capacitada e qualificada para a realização de processos de ciclo de vida de
modo a alcançar os objetivos da organização, do projeto e dos clientes (ASSOCIAÇÃO
BRASILEIRA DE NORMAS TÉCNICAS, 2009).
As pessoas que trabalham em uma organização de software são seu maior patrimônio.
Elas representam o capital intelectual e é responsabilidade dos gerentes de software garantir
que a organização obtenha o melhor retorno de seu investimento em pessoas
(SOMMERVILLE, 2003, p. 418).
Ser competente está relacionado com um bom desempenho numa determinada tarefa, o
que não garante que este desempenho será bom sempre. Ter competência para a realização de
uma tarefa significa ter conhecimentos, habilidades e atitudes compatíveis com o desempenho
dela e ser capaz de colocar este potencial em prática sempre que for necessário. Então se pode
definir competência como um conjunto de conhecimentos, habilidades, atitudes e
comportamentos, que permitem ao indivíduo desempenhar com eficácia determinadas tarefas,
em qualquer situação (RABAGLIO, 2004, p. 3).
Rabaglio (2004) define significados para estas competências, assim como segue:
a) conhecimento - saber (conhecimentos adquiridos no decorrer da vida, nas escolas,
universidades, cursos);
b) habilidade - saber fazer (capacidade de realizar determinada tarefa, física ou
18
mental);
c) atitude - querer fazer (comportamentos que se tem diante de situações do nosso
cotidiano e das tarefas que desenvolvemos no nosso dia-a-dia).
2.3 ALGORITMO GENÉTICO MULTIOBJETIVO NSGA-II
A fim de auxiliar na alocação de recursos humanos em solicitações de mudanças de
software optou-se por utilizar algoritmo genético. Holland (1975) propôs, nos anos 60, a
construção de um algoritmo matemático para otimização em sistemas complexos, sendo
denominado de Algoritmo Genético. Este algoritmo pretendia simular matematicamente todo
o mecanismo da evolução biológica, com todas as características e vantagens desse processo
(FILHO; POPPI, 1998).
A partir dos anos oitenta, o algoritmo genético recebeu um grande impulso em diversas
áreas de aplicação científica, devido principalmente à versatilidade e excelentes resultados
apresentados. A popularização dos computadores e o aparecimento de sistemas cada vez mais
rápidos e potentes, também auxiliaram muito o seu desenvolvimento. A partir daí o algoritmo
genético foi utilizado em diversas áreas sempre com o objetivo de solucionar um problema
buscando a melhor solução em um menor espaço de tempo.
Devido à complexidade da área, a grande maioria dos autores prefere abordar os
problemas de engenharia de software utilizando metaheurísticas. Entre as metaheurísticas
mais tradicionais estão inclusas a busca local, a busca tabu e o algoritmo genético.
Hartmann e Kolisch (1998) avaliaram o desempenho entre as metaheurísticas
tradicionais, e para os problemas de sequenciamento/programação de atividades de projeto
com precedência de tarefas e restrições de capacidade resultou na constatação de um melhor
desempenho para os trabalhos que continham simulated annealing e algoritmo genético.
Algoritmos Genéticos (AG), baseados na teoria evolucionista de Darwin, representam
cada indivíduo de uma população como sendo um conjunto de caracteres ou bits e associam a
ele uma aptidão ou adequação (fitness). Com o uso das ideias das operações genéticas de
crossing over e mutação, novas gerações ou populações descendentes são criadas a partir de
uma população inicial, sendo que as características apresentadas pelos indivíduos mais
adaptados têm maiores chances de serem transmitidas às gerações posteriores (RIBEIRO,
2009, p. 21).
19
Non-dominated Sorting Genetic Algorithm II (NSGA II), um algoritmo multiobjetivo é
baseado em Algoritmos Genéticos (AG) e que implementa o conceito de dominância, ou seja,
classificar a população total em fronts de acordo com o grau de dominância. NSGA-II foi
proposto por Deb et al. (2000, p. 3), com operadores específicos de cruzamento, mutação e
correção.
O algoritmo genético multiobjetivo NSGA-II é o mais difundido no meio cientifico.
Estudos demonstraram que o método é no mínimo tão bom quanto, ou melhor, que outras
técnicas multiobjetivo de segunda geração (Coello et al. 2002; Deb et al., 2000).
A distância de povoamento é detalhada na Figura 2, por Spolaôr (2010, p. 24), o qual
considera os indivíduos imediatamente adjacentes a um determinado individuo p. Quanto
maior for o espaçamento, mais diversificada será a solução p. Ainda é possível exemplificar o
operador de seleção por comparação de povoamento. As fronteiras F1 e F2 são diretamente
mantidas para a população da próxima geração. Como a fronteira F3 não pode ser alocada
integralmente seleciona-se para a futura população apenas as soluções mais diversificadas de
acordo com distância de povoamento.
Fonte: Miki (2007 apud SPOLAÔR, 2010, p. 24).
Figura 2 - Operações de (a) ordenação, (b) cálculo da distância de povoamento e (c) seleção por
comparação de povoamento
Após estas operações define-se o laço principal do NSGA-II, ilustrado na Figura 3.
Entre as linhas 1 e 5 é feita a inicialização das populações P e Q, cada uma das quais com N
soluções. A população Q corresponde aos descendentes de indivíduos p P selecionados por
torneio binário para alteração. A população R(t) garante o elitismo ao considerar todos os
indivíduos de P e Q em cada geração.
20
Fonte: Spolaôr (2010, p. 25).
Figura 3 - NSGA-II
O laço interno iniciado na linha 11, ilustrado na Figura 3, adiciona a P todos os
indivíduos de cada uma das fronteiras construídas com o procedimento de ordenação partindo
da fronteira F1. Encerra-se este laço quando a fronteira Fi não puder ser acomodada
completamente em P sem que o limite de N indivíduos desta população seja superado. Neste
momento o operador de comparação é aplicado para ordenar Fi, possibilitando na linha 17
completar P com os melhores indivíduos desta fronteira.
O NSGA-II retorna na linha 21 a fronteira F1 como o melhor conjunto de soluções não
dominadas identificado pelo algoritmo.
2.4 NORMA ISO/IEC 12207
A norma NBR ISO/IEC 12207 tem como objetivo fornecer um conjunto definido de
processos para facilitar a comunicação entre os adquirentes, fornecedores e stakeholders do
ciclo de vida de um produto de software (ASSOCIAÇÃO BRASILEIRA DE NORMAS
TÉCNICAS, 2009, p. 1). A Figura 4 mostra os processos fornecidos na norma.
21
Fonte: Associação Brasileira de Normas Técnicas (2009, p. 14).
Figura 4 - Processos fornecidos na norma NBR ISO/IEC 12207
O objetivo da norma ISO/IEC 12207 é estabelecer uma estrutura comum para os
processos de ciclo de vida de software, com uma terminologia bem definida, que pode ser
referenciada pela indústria de software. A norma abrange todo o ciclo de vida de software,
desde sua concepção até a descontinuidade do projeto de software, e por todos os envolvidos
com produção, manutenção e operação do software. Ela pode ser aplicada para toda a
organização, mas existem casos de aplicação em projetos específicos por imposição contratual
ou nas fases iniciais de implantação (ARRUDA, 2007). Entre vários processos da norma está
o processo de resolução de problemas.
2.4.1 Processo de resolução de problemas de software
O propósito do processo de resolução de problemas de software é garantir que todos os
problemas serão identificados, analisados, gerenciados e controlados até a resolução. Este
22
processo pode ser adaptado facilmente para gerenciar, rastrear e controlar solicitações de
mudança de software, foco deste trabalho.
Segundo a Associação Brasileira de Normas Técnicas (2009), como resultado da
implementação bem-sucedida do processo de resolução de problemas de software da norma
ISO/IEC 12207, tem-se:
a) é desenvolvida uma estratégia de gestão de problemas;
b) os problemas são documentados, identificados e classificados;
c) problemas são analisados e avaliados para identificar soluções aceitáveis;
d) é implementada a resolução de problemas;
e) problemas são rastreados até o seu fechamento;
f) o estado de cada um dos problemas relatados é conhecido.
Estes resultados serão usados para a avaliação de aderência da ferramenta
desenvolvida.
2.5 ASP.NET MVC
O ASP.NET MVC é uma implementação da arquitetura MVC para o ASP .NET em
um framework com o objetivo de criar aplicações web no padrão MVC e fornecer uma
alternativa ao modelo WebForm do ASP .NET disponível até então (MACORATTI, 2008).
A principal tecnologia a ser utilizada na ferramenta é o ASP.NET, e o padrão MVC,
onde o modelo é composto pelo objeto representando o domínio manipulado. A representação
da tela é feita pela visão e controle, onde a visão tem o papel de exibição e captura das ações
do usuário, e o controle é responsável pelo tratamento destas ações (FOWLER, 2006).
Segundo Microsoft Corporation (2011a) o padrão Model-View-Controller (MVC) é
um princípio de design arquitetônico que separa os componentes de um aplicativo da Web.
Esta separação permite mais controle sobre as partes individuais da aplicação, que permite
desenvolver mais facilmente, modificar, e testá-los.
O padrão especifica onde cada tipo de lógica deve ser colocado na aplicação. A
lógica da interface do usuário pertence à View. Entrada lógica pertence ao
Controller. A lógica do negócio pertence ao Model. Esta separação ajuda a gerenciar
a complexidade quando você constrói uma aplicação, pois permite você se
concentrar em um aspecto da aplicação de cada vez. Por exemplo, você pode se
concentrar na visão, sem depender de lógica de negócios. (MICROSOFT
CORPORATION, 2011b).
23
Para Microsoft Corporation (2011b) o padrão MVC permite criar aplicativos que
separam os diferentes aspectos da aplicação e da lógica (entrada, lógica de negócio e lógica
do usuário), enquanto fornece um acoplamento entre esses elementos:
a) model: encapsula alguns dados juntamente com a sua lógica de processamento, e é
isolado da lógica de manipulação, que é encapsulado no controller. Ele pode
definir algumas operações que manipulam esses dados encapsulados. Ele não sabe
absolutamente nada sobre a interface gráfica do usuário e não exibe dados ou
responde às ações que ocorrem na interface;
b) view: é uma referência para o model. Ele usa os métodos apenas de leitura do
modelo para consultar e recuperar dados. Que podem ser exibidos nas mais
variadas formas, HTML, XML, Windows Forms, etc;
c) controller: o objetivo do controller é interagir com o model e com o view. Ele sabe
que o model prevê ações a serem executada sobre os dados, e sabe também que a
interface vai enviar alguns eventos que podem exigir que estas operações sejam
chamadas.
A Figura 5 mostra o fluxo de uma solicitação Hypertext Transfer Protocol (HTTP), em
um contexto web, utilizando o padrão MVC.
Fonte: Lemos (2009).
Figura 5 - Fluxo de solicitação do padrão MVC
24
Lemos (2009) explica o fluxo de solicitação do padrão MVC:
a) o usuário realiza uma requisição de uma View (página web) ao Controller (1).
b) o Controller recupera todas as informações da View e solicita uma ação para o
Model. O Model processa a ação (grava em banco de dados) e devolve o resultado
deste processamento para o Controller (2).
c) o Controller processa o resultado e devolve para View o que ela deve exibir (3).
d) a View recebe o que foi processado pelo Controller e exibe o resultado para o
usuário (4).
O ASP.NET MVC é desenvolvido e mantido pela Microsoft e distribuído sobre a
licença Microsoft Public Licence (MS-PL). Foi inspirado por outros web frameworks como
Rails, Django, e Monorail, baseando-se em muitas das principais estratégias que essas outras
plataformas MVC utilizam, além de oferecer os benefícios do código compilados e
gerenciado e também explorar os novos recursos de linguagem do VB.NET e C# (CONERY
et al., 2009, p. 188).
2.6 TRABALHOS CORRELATOS
A seguir apresentam-se trabalhos que possuem pontos em comum a este, sendo eles:
“Planejamento de alocação de recursos humanos em projetos” (BASTOS, 2009) e “Resource
Management” (QUICKARROW, 2010).
2.6.1 Planejamento de alocação de recursos humanos em projetos
A ferramenta proposta por Bastos (2009) tem como objetivo a alocação de recursos
humanos em projetos de software, propondo que se tenha uma alocação eficaz, baseada nos
estudos do Project Management Body of Knowledge (PMBOK) e com apoio de gerentes de
projetos da área. O sistema permite a alocação de profissionais em projetos e utiliza-se de
algoritmo de busca tabu, o qual se mostrou satisfatório para a ferramenta desenvolvida.
Na Figura 6 é exibida a tela principal de alocação da ferramenta. A direita fica a
listagem dos projetos selecionados pelo usuário, ao centro é mostrado, de acordo com a aba
selecionada, o calendário de recursos para a data selecionada na listagem da esquerda, a qual
25
contém os meses alocados (BASTOS, 2009, p. 54).
Fonte: Bastos (2009, p. 54).
Figura 6 - Tela de visualização de alocações
A linguagem de programação utilizada foi C# e banco de dados SQL Server, que se
mostrou eficiente, atendendo as necessidades encontradas, segundo Bastos (2009, p. 70).
A ferramenta possui algumas limitações que o autor sugere como melhoria, como
tornar sequencial e dependente as atividades do projeto, tornando assim possível iniciar uma
atividade após a outra e também sugere permitir alocações por hora, possibilitando um
recurso possuir duas atividades de dois projetos diferentes no mesmo dia.
2.6.2 Resource Management
O software Resource Management foi especificado, desenvolvido e distribuído pela
empresa QuickArrow, sob licença proprietária. A abordagem principal é gestão de recursos a
qual proporciona aos gestores de projeto pesquisar e atribuir recursos adequados aos projetos
com base em certificações, disponibilidade, habilidades, localização e trabalho
(QUICKARROW, 2010).
Os benefícios informados pela proprietária são maximizar a utilização de recursos, ver
horários e disponibilidade de recursos em tempo real, economizar recursos atribuindo tempo a
projetos, aumentar a precisão do planejamento de recursos e previsão e criar mais eficazes e
rentáveis projetos com recursos apropriados.
O principal recurso é o planejamento de alocação. Na Figura 7 é mostrado o calendário
de recursos, exibindo graficamente as alocações por data e informações de valores e
26
quantidades de horas de cada recurso.
Fonte: QuickArrow (2010). Figura 7 - Tela do Resource Management com tabela de alocação de recursos
O software é desenvolvido em Java e é comercializado na forma de Software as a
Service (SaaS).
27
3 DESENVOLVIMENTO
Este capítulo detalha as etapas do desenvolvimento da ferramenta. São apresentados os
requisitos, a especificação e a implementação do mesmo, mencionando as técnicas e
ferramentas utilizadas. Também é apresentada a operacionalidade do software e os resultados
obtidos.
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO
A partir do estudo dos trabalhos correlatos, podem-se definir os requisitos da
ferramenta, que deve possuir um módulo de cadastros, o qual reunirá as informações
necessárias para a alocação e um módulo de operação, onde o usuário poderá visualizar a
alocação. A seguir são apresentados os Requisitos Funcionais (RF) e Requisitos Não
Funcionais (RNF):
a) permitir o cadastro de usuários (RF);
b) permitir o cadastro do tipo de solicitação de mudança (RF);
c) permitir o cadastro de sistemas (RF);
d) permitir o cadastro de módulos (RF);
e) permitir o cadastro de habilidades (RF);
f) permitir o cadastro de atitudes (RF);
g) permitir o cadastro de conhecimentos (RF);
h) permitir o cadastro de recursos (RF);
i) permitir o cadastro de prioridades (RF);
j) permitir o cadastro das solicitações de mudanças (RF);
k) permitir alocação dinâmica das solicitações de mudanças aos recursos através do
algoritmo de busca NSGA-II (RF);
l) permitir emissão de relatório com visão semanal e/ou mensal da alocação das
solicitações de mudança (RF);
m) ser implementado em C# com framework .Net, utilizando o ambiente de
desenvolvimento Microsoft Visual Studio 2010 (RNF);
n) utilizar banco de dados SQL Server para armazenamento de dados (RNF);
28
o) ser compatível com três navegadores: Internet Explorer, Firefox, Google Chrome
(RNF);
p) atender as diretrizes do processo de resolução de problemas da norma ISO/IEC
12207 (RNF).
3.2 ESPECIFICAÇÃO
Nesta seção é apresentada a especificação da ferramenta. Foi utilizada a ferramenta
Microsoft SQL Server Management Studio para criação do Diagrama Entidade
Relacionamento (DER). Os demais diagramas foram concebidos utilizando a ferramenta
Entreprise Architect (EA). Foi utilizada a Unified Modeling Language (UML) para a criação
dos diagramas de casos de uso, classe, sequência e de atividades.
3.2.1 Diagrama de Casos de Uso
Os casos de uso da ferramenta estão divididos em dois grupos: Cadastros, onde o ator
informa as informações e configurações necessárias para a execução da ferramenta e
Alocação que é o processo de distribuição de solicitações de mudanças ou restrições dos
recursos.
O diagrama de casos de uso da ferramenta pode ser observado na Figura 8 e as
descrições dos principais casos de uso podem ser encontradas no Apêndice A.
29
uc 3.1 Diagrama de Casos de Uso
Cadastros
Alocação
UC01 - Cadastrar
usuário
Gerente
(from Diagrama de casos de uso)
UC02 - Cadastrar
sistema
UC03 - Cadastrar
modulo
UC05 - Cadastrar
habilidade
UC06 - Cadastrar
atitude
UC07 - Cadastrar
conhecimento
UC09 - Cadastrar
prioridade
UC08 - Cadastrar
recurso
UC10 - Cadastrar
solicitação de
mudança
UC11 - Cadastrar tipo
de solicitaçãoUC12 - Cadastrar
restrição
UC14 - Alocar
automaticamente
recurso
UC15 - Visualizar
alocação
UC13 - Alocar
manualmente recurso
UC04 - Cadastrar
requisito
Figura 8 - Diagrama de casos de uso da ferramenta
Os casos de uso são:
a) UC01 – cadastrar usuário: permite incluir, alterar, consultar e excluir um usuário;
b) UC02 - cadastrar sistema: permite incluir, alterar, consultar e excluir sistemas
utilizados no cadastro de solicitações de mudanças;
c) UC03 – cadastrar módulo: permite incluir, alterar, consultar e excluir módulos de
um sistema utilizados no cadastro de solicitações de mudanças;
d) UC04 – cadastrar requisito: permite incluir, alterar, consultar e excluir requisitos
de um módulo de um sistema utilizados no cadastro de solicitações de mudanças;
e) UC05 – cadastrar habilidade: permite incluir, alterar, consultar e excluir
habilidades, relacionando com recursos e com módulos do sistema;
f) UC06 – cadastrar atitude: permite incluir, alterar, consultar e excluir atitudes,
relacionando com recursos e com módulos do sistema;
g) UC07 – cadastrar conhecimento: permite incluir, alterar, consultar e excluir
conhecimentos, relacionando com recursos e com módulos do sistema;
h) UC08 – cadastrar recurso: permite incluir, alterar, consultar e excluir recursos
30
humanos, informando o nome, função e quantidade de horas de trabalho por dia;
i) UC09 – cadastrar prioridade: permite incluir, alterar, consultar e excluir
prioridades utilizadas no cadastro de solicitações de mudanças;
j) UC10 – cadastrar solicitação de mudança: permite incluir, alterar, consultar e
excluir solicitações de mudanças;
k) UC11 – cadastrar tipo de solicitação: permite incluir, alterar, consultar e excluir
tipos de solicitação de mudanças utilizadas no cadastro de solicitações de
mudanças;
l) UC12 – cadastrar restrição: permite incluir, alterar, consultar e excluir tipos de
restrições que podem ser usadas em recursos;
m) UC13 – alocar manualmente recurso: permite ao ator criar a alocação do recurso
para determinada solicitação de mudança não alocada, apresentando o recurso e
solicitação de mudança. A alocação é gerada a partir da próxima data disponível
do recurso selecionado;
n) UC14 – alocar automaticamente recurso: permite a alocação automática dos
recursos em solicitações de mudanças com algoritmo NSGA-II;
o) UC15 – visualizar alocação: permite ao ator visualizar os dados da alocação dos
recursos nas solicitações de mudança;
3.2.2 Diagrama de classes
O diagrama de classes auxilia na visualização de como as classes estão estruturadas e
quais suas relações. Na Figura 9 é apresentado o diagrama de classe da camada de modelo que
mostra como está estruturada a implementação da ferramenta.
31
class 4.1 Modelo de classes
Sistema
- Codigo: int
- Descricao: string
Modulo
- Codigo: int
- Descricao: string
Requisito
- Codigo: int
- Descricao: string
Usuario
- Codigo: int
- Descricao: string
Recurso
- Codigo: int
- Descricao: string
- HorasDia: int
- Funcao: Funcao
Funcao
- Codigo: int
- Descricao: stringHabilidade
- Codigo: int
- Descricao: string
Competencia
- Codigo: int
- Descricao: string
Conhecimento
- Codigo: int
- Percentual: double
Prioridade
- Codigo: int
- Descricao: string
- Ordem: int
Tipo Solicitacao
- Codigo: int
- Descricao: string
SolicitacaoMudanca
- Codigo: int
- Numero: int
- Solicitacao: String
- Descricao: string
- DataSolicitacao: datetime
- PrazoCliente: datetime
- PrazoEntrega: datetime
Feriado
- Codigo: int
- Descricao: string
- DataInicio: datetime
- DataFim: datetime
Restricao
- Codigo: int
- DataInicio: datetime
- Descricao: string
- DataFim: datetime
AlocacaoRecurso
- Codigo: int
- DataInicio: datetime
- DataFim: datetime
TipoRestricao
- Codigo: int
- Descricao: string
Projeto
- Codigo: int
- Descricao: string
Status
- Codigo: int
- Descricao: string
Solicitante
- Codigo: int
- Nome: string
- Email: string
Cliente
- Codigo: int
- Descricao: string
RecursoHabilidade
- percentual: int
0..*
1
0..*
1
0..*
1
1
0..*
0..*
1
0..*1
0..*
1
0..*
1
0..*
1
1..*
1
1..*
1..*
0..*1
1
1..*
0..*1
1..*
1..*
1..*
1..*
1..* 1
1
0..*
1
0..*
0..*1
Figura 9 - Diagrama de classes da camada de modelo da ferramenta
As classes da ferramenta apresentadas na Figura 9 são:
a) Sistema: classe que contém os sistemas cadastrados;
b) Modulo: classe que contém os módulos cadastrados de um sistema;
c) Requisito: classe que contém os requisitos cadastrados para um módulo de um
32
sistema;
d) Prioridade: classe que contém os atributos de prioridade para uma solicitação de
mudança;
e) Projeto: classe que contém os projetos cadastrados;
f) Status: classe que contém os status de solicitações de mudança;
g) TipoSolicitacao: classe que define o tipo de uma solicitação de mudança;
h) SolicitacaoMudanca: classe que contém os atributos necessários a uma
solicitação de mudança. Os atributos válidos para a ferramenta são os aderidos
pela norma ISO/IEC 12207;
i) Solicitante: classe que contém os solicitantes cadastrados a um cliente;
j) Cliente: classe que contém os clientes cadastrados;
k) Feriado: classe que contém os feriados cadastrados que são utilizados na
alocação de recursos;
l) Usuario: classe que contém os usuários cadastrados no sistema. Estes usuários
terão permissão de acesso ao sistema;
m) Funcao: classe que define a função de um recurso cadastrado;
n) AlocacaoRecurso: classe que contém as alocações das solicitações de mudança
geradas pelo sistema através do algoritmo de alocação ou alocadas manualmente;
o) Conhecimento: classe que contém os conhecimentos cadastrados para o cálculo
de afinidade dos recursos;
p) Habilidade: classe que contém as habilidades cadastradas para o cálculo de
afinidade dos recursos;
q) Atitude: classe que contém as atitudes cadastradas para o cálculo de afinidade
dos recursos;
r) Recurso: classe que contém os atributos necessários a criação de recursos da
ferramenta;
s) Restricao: classe que possui os atributos ao cadastro de restrições a recursos. As
restrições definem como uma quebra na alocação de solicitações a recursos.
t) TipoRestricao: classe que contém o tipo de restrição de uma determinada
restrição cadastrada a um recurso.
Para cada entidade do modelo, há uma classe de controle, conforme prevê o framework
MVC, que é nomeada como <nomedaentidadeController>. Na Figura 10 é mostrada a
estrutura de classes no visual studio.
33
Figura 10 – Estrutura de classes de controle
A classe AlocacaoController recebe as requisições do navegador, e processa parte
dos dados.
A Figura 11 apresenta a classe AlocacaoController com seus métodos que fazem
parte da execução da alocação e da gravação do registro alocado. O item 3.3.2 mostra detalhes
da implementação. class Modelo de classes
«controller»
AlocacaoController
+ AlocacaoManual(int) : ActionResult
+ Executar() : ActionResult
+ GravarAlocacao(int, int) : void
+ getAlocacao() : JsonResult
- CalculaRank(List<Recurso>) : void
- CrowdingDistance(List<Recurso>, SolicitacaoMudanca) : void
- CalculaDiasInicio(Recurso, DateTime) : void
- OrdenaCrowd(List<Recurso>) : void
- ConvertToTimestamp(DateTime) : string
- DiaUtil(DateTime, Recurso) : DateTime
- Restricao(DateTime, Recurso) : bool
- Feriado(DateTime) : bool
Figura 11 - Diagrama da classe AlocacaoController
Para cada controller são implementadas as quatro operações básicas, criação, consulta,
34
atualização e destruição de dados, utilizadas em bancos de dados relacionais ou em interface.
Em cada operação é gerada uma view. Na Figura 12 é apresentada a estrutura de views da
ferramenta.
Figura 12 – Estrutura de views da ferramenta
3.2.3 Diagrama de sequência
Nessa sessão é apresentado o diagrama de sequência que representa o conjunto de
ações que a ferramenta executa para realizar a alocação automática de recursos.
A Figura 13 mostra o diagrama, que equivale ao caso de uso UC14 – Alocar
automaticamente recurso. Através dele podem-se observar os passos e mensagens trocadas
demonstrando o processo de geração das alocações.
O usuário escolhe no menu da ferramenta para executar a alocação, que envia uma
35
requisição ao servidor de aplicação. Esta requisição é atendida pelo controller
AlocacaoController. O processo de alocação é executado então pela classe do model que
ao final do processamento retorna ao controller os resultados. sd Diagrama de Sequencia
Gerente
«view»
Alocacao
«controller»
AlocacaoController
«Model»
AlocacaoRecurso
«Model»
SolicitacaoMudanca
«Model»
Recurso
ExecutarAlocacao()
Executar()
GeraListaSolicitacoes()
GeraListaRecursos()
CrowdingDistance()
CalculaDiasInicio()
OrdenaCrowd()
CalculaRank()
GravarAlocacao()
Create()
Figura 13 - Diagrama de sequência para alocação automática de recursos
3.2.4 Diagrama de atividades
O processo de alocação automática dos recursos é dividido em etapas que estão
detalhadas em subseções a seguir. A Figura 14 foi construída na ferramenta Enterprise
Architect e apresenta o diagrama de atividades do processo automático de alocação com uma
visão geral.
36
act Diagrama de Ativ idades
SistemaGerenteInicio
Seleciona Alocação
Automática
Seleciona todas as
Solicitações de
Mudanças pendentes
Ordena por
ordem de
prioridade
Seleciona os recursos
com funçao de
programador
Itera a lista de solicitações
de mudanças
Itera na lista
de recursos
Calcula a pontucao conforme
competencia, habilidade e
conhecimento
Acabou lista de
recursos?Itera na lista
de recursos
Adiciona na lista de
Dominantes,
Dominados e Geração
conforme a pontuação
Acabou lista de
recursos?
Ordena a lista de recursos
dominantes pela pontuação
Ordena a lista de recursos
geração pela pontuação
Crowding Distance
Dominantes
OrdenaCrowd
CalculaRank
Ordena Recursos pela
pontução
Seleciona o primeiro recurso
Grav a alocação do recurso para a
solicitaçao de mudança
Acabou lista de
solicitaçao de
mudança?
Fim
Gera v isualização da
alocação
[Não]
[Não]
[Sim]
[Não]
[Sim]
[Sim]
Figura 14 - Diagrama de atividades do processo de alocação
37
3.2.4.1 Seleção das solicitações de mudanças e ordenação por ordem de prioridade
Esse processo é responsável por buscar todas as solicitações de mudanças que estão
pendentes, ou seja, que ainda não foram alocadas para nenhum recurso. As solicitações
pendentes são as que estão com o status “determinar programador”.
Em seguida, é realizada a ordenação da lista de solicitações pendentes de acordo com a
ordem decrescente das prioridades cadastradas.
3.2.4.2 Seleção dos recursos
Optou-se por limitar a ferramenta para a alocação apenas de solicitações de mudanças
para desenvolvimento, neste caso, a seleção de recursos humanos é efetuada filtrando os que
possuem função de programador cadastrada.
3.2.4.3 Cálculo da pontuação de cada recurso para cada solicitação
Este processo é responsável por calcular a pontuação de todos os recursos, associando
os conhecimentos, habilidades e atitudes, associados ao recurso e que são aderentes ao
sistema/modulo da solicitação de mudança que se está iterando na lista. Desta forma, é
realizado o cálculo para determinar a pontuação do recurso. Quanto maior a pontuação, mais
indicado este recurso será para ser alocado para executar a solicitação. A determinação de
como é realizado o cálculo é mostrada no item 3.3.2.1 deste capítulo.
3.2.4.4 Comparação dos recursos entre si para determinar se é dominante, dominado ou
gerador
Este processo é responsável pela geração de três listas de recursos. As listas são:
a) dominante: lista de recursos que possuem maior pontuação sobre o recurso em
comparação;
38
b) dominado: lista de recursos que possuem menor pontuação em relação ao recurso
que se está comparando;
c) geração: lista de recursos que possuem a mesma pontuação ao recurso que se está
comparando.
Na seção 3.3 são mostrados detalhes da comparação e associação dos recursos as listas
determinadas nesta etapa.
3.2.4.5 Ordenação das listas geradas
Nesta etapa é realizada a ordenação das listas de dominantes e de geração. A
ordenação é realizada com base na pontuação dos recursos de forma decrescente, ou seja, o
recurso que possuir a maior pontuação estará no topo da lista.
3.2.4.6 Cálculo de crowding distance e ordenação
Cada recurso poderá possuir alocações de solicitações de mudança e/ou de restrições
em sua fila. O cálculo de crowding distance retorna a quantidade de dias para o recurso poder
iniciar a solicitação de mudança com base na data da última alocação do recurso.
Em seguida é reordenada a lista de recursos dominantes de forma ascendente de acordo
com a quantidade de dias para iniciar a solicitação.
3.2.4.7 Cálculo de rank
O cálculo do rank cria uma nova pontuação, e em seguida atribui a pontuação dos
atributos do recurso, gerando ao final, uma pontuação totalizada. É definido um número
aleatório e somado com a multiplicação da quantidade de dias obtida através do crowding
distance por um valor negativo. Desta forma, quanto maior for a quantidade de dias para
poder iniciar a execução da solicitação, menor será a pontuação total do recurso.
Detalhes da implementação e execução são apresentados no item 3.3.
39
3.2.4.8 Gravar a alocação do recurso
Nesta etapa, o melhor recurso já esta selecionado e se tem a solicitação de mudança.
Este processo tem como objetivo realizar a alocação física do recurso ao calendário de
alocações. A solicitação de mudança é dividida em dias e em horas, em seguida busca-se o
próximo horário livre de alocação do recurso, e então é realizada a persistência gerando
registros de alocação para período disponível para o recurso. O processo também identifica
feriados, restrições, e fins de semana, e adiciona a alocação somente em períodos livres na
alocação do recurso.
3.2.4.9 Apresentação dos resultados
Após todo o processo de alocação ser realizado é necessário mostrar ao usuário os
resultados. Essa etapa é responsável por mostrar a alocação de forma amigável ao usuário,
isso se dá em forma de calendário de recursos, onde são listados os recursos e as respectivas
solicitações de mudança alocadas.
Informações sobre início e fim de intervalos de alocação ou restrição são agrupadas de
forma a tornar possível o seu entendimento. No item 3.3 deste capítulo é apresentado o
processo e também algumas telas, onde se pode observar o resultado final do processo de
alocação de recursos.
3.2.5 Diagrama de entidade relacionamento
Para representar os objetos do banco de dados, foi utilizada a ferramenta Microsoft
SQL Server Management Studio. A ferramenta permite que as alterações realizadas no
diagrama reflitam diretamente nas entidades na base de dados. Assim não é necessária a
criação e/ou execução de scripts para manutenção dos artefatos.
A Figura 15 mostra o diagrama de entidade relacionamento físico, onde se pode
observar as ligações entre as entidades. A chave ao lado do campo indica que o mesmo é ou
faz parte da chave primária da tabela. Já a chave que aparece nas ligações indica que o campo
está sendo levado para outra tabela como chave estrangeira.
40
AlocacaoRecurso
Codigo
CodigoRecurso
CodigoSolicitacaoMudanca
DataInicio
DataFim
Cliente
Codigo
Descricao
Feriado
Codigo
Descricao
DataInicio
DataFim
Funcao
Codigo
Descricao
Habilidade
Codigo
Descricao
Modulo
Codigo
Descricao
CodigoSistema
Complexidade
ModuloHabilidade
Codigo
CodigoModulo
CodigoHabilidade
Prioridade
Codigo
Descricao
Ordem
Projeto
Codigo
Descricao
Recurso
Codigo
Descricao
HorasDia
CodigoFuncao
PontuacaoP1
PontuacaoP2
Pontuacao
Dias
RecursoConhecimento
Codigo
CodigoRecurso
CodigoModulo
Percentual
RecursoHabilidade
Codigo
CodigoRecurso
CodigoHabilidade
Percentual
Requisito
Codigo
Descricao
CodigoModulo
Restricao
Codigo
Descricao
DataInicio
DataFim
CodigoTipoRestricao
CodigoRecurso
Sistema
Codigo
Descricao
SolicitacaoMudanca
Codigo
Numero
Solicitacao
Descricao
DataSolicitacao
PrazoCliente
PrazoEntrega
CodigoSolicitante
CodigoPrioridade
CodigoRequisito
CodigoProjeto
CodigoStatus
CodigoTipoSolicitacao
HoraAnaliseSistema
HoraAnaliseNegocio
HoraProgramacao
HoraTeste
HoraDocumentacao
Solicitante
Codigo
CodigoCliente
Descricao
Status
Codigo
Descricao
TipoRestricao
Codigo
Descricao
TipoSolicitacao
Codigo
Descricao
Atitude
Codigo
Descricao
ModuloAtitude
Codigo
CodigoModulo
CodigoAtitude
RecursoAtitude
Codigo
CodigoRecurso
CodigoAtitude
Figura 15 - Diagrama entidade relacionamento
3.3 IMPLEMENTAÇÃO
A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da
implementação. São apresentados blocos de códigos fontes e algumas telas da interface do
usuário.
3.3.1 Técnicas e ferramentas utilizadas
A ferramenta foi desenvolvida na linguagem C# / ASP.NET sobre a plataforma
41
Microsoft .NET (versão 3.5). Para codificação foi utilizado o ambiente Microsoft Visual
Studio 2010, também foram utilizados dois frameworks a fim de agilizar o desenvolvimento e
obter um melhor resultado. A seguir estão listados esses frameworks bem como um resumo de
suas funcionalidades, os quais são:
a) ASP.NET MVC Framework: é a implementação da Microsoft para o modelo de
arquitetura model, view e controller para a plataforma ASP.NET. Mais
informações sobre esse framework foram mostradas no item 2.5 na fundamentação
teórica;
b) Microsoft Entity Framework: é uma tecnologia de acesso a dados que ajuda
diminuir o espaço semântico entre o mundo orientado a objetos e o relacional. O
Entity Framework é uma biblioteca de alto nível que permite aumentar a abstração
no acesso aos dados, dando a flexibilidade para que o modelo de dados faça
sentido para a aplicação e para o desenvolvedor. O Entity Framework faz a leitura
das entidades da base de dados e gera as classes para a aplicação. O código gerado
não deve ser alterado pelo programador, pois a cada alteração na base dados esse
código será re-gerado substituindo qualquer alteração manual. Permite também
através da criação de diagrama a geração das classes para a aplicação. Nesse caso
o desenvolvedor deverá fazer manualmente o relacionamento entre classes e
entidades.
Uma tecnologia amplamente utilizada em projetos MVC é a Language Integrated
Query (LINQ). Segundo Microsoft Corporation (2009c) é uma extensão do .NET Framework
3.5 que engloba consulta, atribuição e operações de transformação de dados em praticamente
qualquer fonte de dados. Através de uma sintaxe semelhante ao SQL é possível realizar
pesquisas em bloco de informações, filtrar dados (vertical ou horizontalmente), quando
necessário através da associação de operadores.
Na ferramenta, a tecnologia LINQ foi utilizada para manipulação das informações no
banco de dados e coleções em memória. O Quadro 1 mostra o método Index responsável por
retornar uma lista de solicitações de mudança para a view. É feita a associação com as
entidades relacionadas à solicitação de mudança e ordenado pelo número.
// GET: /SolicitacaoMudanca/ public ActionResult Index() { var solicitacaomudanca = db.SolicitacaoMudanca.Include("Prioridade") .Include("Projeto").Include("Requisito").Include("Solicitante") .Include("Status").Include("TipoSolicitacao").OrderBy(p => p.Numero);
42
return View(solicitacaomudanca.ToList()); }
Quadro 1 - Método Index, exemplo de utilização da tecnologia LINQ na ferramenta
3.3.2 Desenvolvimento da ferramenta
A seguir são apresentados detalhes da implementação com as rotinas que compõe a
solução do problema.
3.3.2.1 Cálculo da pontuação de recursos
Como já apresentado no item 3.2.7, esta etapa é responsável por calcular a pontuação
de todos os recursos, associando os conhecimentos, habilidades e atitudes, associados ao
recurso e que são aderentes ao sistema/modulo da solicitação de mudança que se está iterando
na lista. Quanto maior a pontuação, mais indicado este recurso será para ser alocado para
atender a solicitação.
Para determinar a pontuação são feitos cálculos sobre conhecimentos, habilidades e
atitudes, conforme descrito a seguir:
a) conhecimentos: (1000 * percentual) pontos para cada conhecimento que o recurso
possui e que o módulo do sistema da solicitação de mudança requer;
b) habilidades: (100 * percentual) pontos para cada habilidade que o recurso possui e
que o módulo do sistema da solicitação de mudança requer;
c) atitudes: 10 pontos para cada atitude que o recurso possui e que o módulo do
sistema da solicitação de mudança requer.
Os valores para a base do cálculo foram determinados após uma série de testes. Foi
utilizado um cenário de sistemas comerciais que possuem muitas regras de negócio. Neste
caso o conhecimento das regras do sistema e do que as mudanças podem afetar outras partes
são a principal regra para selecionar um recurso para uma solicitação de mudança. Com um
peso menor aparecem as habilidades necessárias e mais como um critério de desempate
aparecem as atitudes do recurso.
Ao final, deste processo, o recurso possuirá uma pontuação consolidada. Esta
pontuação é realizada como base nos próximos processos do algoritmo. O Quadro 2 mostra a
43
implementação do cálculo, que é executado para cada conhecimento/habilidade/atitude que o
recurso possuir. Caso o recurso não possua os requisitos (conhecimentos, habilidades e
atitude), sua pontuação é zerada.
/* * Calculo da pontuacao do recurso * (1000 * percentual) pontos para cada conhecimento, * (100 * percentual) pontos para cada habilidade, * 10 pontos para cada atitude */ foreach (Recurso recurso in recursos) { //Zero-se as pontuacoes para fins de controle. recurso.Dias = 0; recurso.PontuacaoP1 = 0; recurso.PontuacaoP2 = 0; recurso.Pontuacao = 0; List<RecursoConhecimento> co = recurso.RecursoConhecimento.ToList(); foreach (RecursoConhecimento conhecimento in co) { if (conhecimento.CodigoModulo == sm.Requisito.CodigoModulo) { recurso.PontuacaoP1 += (Convert.ToDouble(conhecimento.Percentual) / 100) * 1000; } } List<RecursoHabilidade> ha = recurso.RecursoHabilidade.ToList(); foreach (RecursoHabilidade habilidade in ha) { foreach (ModuloHabilidade smHab in sm.Requisito.Modulo.ModuloHabilidade.ToList()) { if (smHab.Habilidade == habilidade.Habilidade) { recurso.PontuacaoP1 += (Convert.ToDouble(habilidade.Percentual) / 100) * 100; } } } List<RecursoAtitude> comp = recurso.RecursoAtitude.ToList(); foreach (RecursoAtitude atitude in comp) { foreach (ModuloAtitude smComp in sm.Requisito.Modulo.ModuloAtitude.ToList()) { if (smComp.Atitude == atitude.Atitude) { recurso.PontuacaoP1 += 10; } } } }
Quadro 2 – Cálculo pontuação recursos
44
3.3.2.2 Comparação dos recursos
Este processo é responsável pela geração de três listas de recursos: dominante,
dominado e geração conforme abordado no item 3.2.8 deste capitulo.
É realizada a iteração sobre a lista de recursos. O recurso R é adicionado na lista de
recursosVisitados, para que não seja novamente comparado com outros recursos. Então se
faz uma nova iteração sobre a lista de recursos, o qual este recurso Q será comparado com o
primeiro recurso R. Verifica-se se o recurso já está contido na lista de visitados, e caso sim vai
para a próxima iteração. Se o recurso possuir pontuação zerada – ele pode não ter sido
configurado ainda pelo gerente – este é ignorado na comparação.
Após isto são feitas as comparações para adicionar o recurso em uma das três listas.
Caso a pontuação do recurso Q for maior que a do recurso R, então Q é dominante e
adicionado na lista A. Caso a pontuação do recurso Q for menor que a do recurso R, então Q é
dominado e adicionado na lista B. Ou se a pontuação do recurso Q for igual ao recurso R, este
é adicionado na lista de geração G. A rotina do de comparação da pontuação dos recursos e
associação as listas pode ser visto no Quadro 3.
No fim da primeira iteração que seleciona o recurso R, é feita uma validação para
verificar se houve algum recurso adicionado na lista de dominantes, dominados ou de
geração. Se não tiver, o recurso R é adicionado na lista de geração – G.
45
foreach (Recurso R in recursos) { recursosVisitados.Add(R); //Itera sobre a lista de recursos, desconsiderando o recurso atual do foreach acima foreach (Recurso Q in recursos) { //Ignora os recursos ja visitados. if (recursosVisitados.Contains(Q)) { continue; } //Ignora se o recurso tiver pontuacao zerada if (Q.PontuacaoP1 == 0) { continue; } /* * Para cada recurso Q, deve gerar uma lista de dominantes e dominados * Se a pontuacao do recurso Q > R, recurso é dominante, entao insere na lista A; * Se a pontuacao do recurso Q < R, recurso é dominado, então insere na lista B; * Se a pontuacao do recurso for igual, adiciona R na lista de geracao G. */ if (Q.PontuacaoP1 > R.PontuacaoP1) { if (!A.Contains(Q)) A.Add(Q); } else if (Q.PontuacaoP1 < R.PontuacaoP1) { if (!B.Contains(Q)) B.Add(Q); } else { if (!G.Contains(Q)) G.Add(Q); } } //Se não tiver nenhum recurso para comparação que tenha pontuação, //O primeiro recurso deve ser adicionado na lista de geração. if (A.Count == 0 && B.Count == 0 && G.Count == 0 && R.PontuacaoP1 > 0) { G.Add(R); } }
Quadro 3 – Comparação da pontuação dos recursos
46
3.3.2.3 Crowding distance e ordenação
O cálculo de crowding distance, que faz parte do algoritmo NSGA-II, calcula a
quantidade de dias para o recurso poder iniciar a solicitação de mudança com base na data da
ultima alocação do mesmo. O método CrowdingDistance pode ser observado no Quadro 4.
private void CrowdingDistance(List<Recurso> A, SolicitacaoMudanca sm) { foreach (Recurso r in A) { CalculaDiasInicio(r, sm.PrazoCliente); } }
Quadro 4 - Método CrowdingDistance componente do NSGA-II
É realizada a iteração sobre a lista de recursos da lista A (Dominantes). Para cada
recurso, é chamado o método CalculaDiasInicio, que foi detalhado no Quadro 5.
O método CalculaDiasInicio atribui ao recurso a quantidade de dias para a próxima
alocação possível, buscando a última data de alocação e subtraindo da data atual.
private void CalculaDiasInicio(Recurso r, DateTime? prazoCliente) { int dias = 0; DateTime? dataUltimaAlocacao = null; try { dataUltimaAlocacao = r.AlocacaoRecurso.OrderByDescending(p => p.DataFim).FirstOrDefault().DataFim; } catch { dataUltimaAlocacao = null; } if (dataUltimaAlocacao.HasValue) { TimeSpan diffResult = dataUltimaAlocacao.Value.Date.Subtract(DateTime.Today.Date); if (diffResult.Days > 0) dias = diffResult.Days; } r.Dias = dias; }
Quadro 5 - Método CalculaDiasInicio
O método OrdenaCrowd, detalhado no Quadro 6, faz a ordenação da lista de
dominantes de forma ascendente pelo atributo dias da entidade Recurso, o qual foi
alimentado pelo método CalculaDiasInicio invocado por CrowdingDistance.
47
private void OrdenaCrowd(List<Recurso> A) { A = A.OrderBy(p => p.Dias).ToList(); }
Quadro 6 – Método OrdenaCrowd
3.3.2.4 Cálculo de rank
O processo de cálculo de rank cria uma nova pontuação, e em seguida atribui a
pontuação dos atributos do recurso, gerando ao final, uma pontuação totalizada. É definido
um numero aleatório entre 500 e 800. Este valor é atribuído e somado com a multiplicação da
quantidade de dias obtida através do método crowding distance por -100. Atribui-se este
valor por considerar-se um valor que afetará a pontuação do recurso de forma positiva para a
seleção do melhor recurso. Desta forma, quanto maior for a quantidade de dias para poder
iniciar a próxima solicitação, menor será a pontuação total do recurso. Quanto maior a fila de
alocação do recurso, menor será sua pontuação, o que o fará não ser o melhor recurso para
assumir a solicitação de mudança. O Quadro 7 mostra o código do método CalculaRank.
private void CalculaRank(List<Recurso> A) { Random rnd = new Random(); foreach (Recurso r in A) { //definido um numero aleatorio de pontuacao r.PontuacaoP2 = rnd.Next(500, 800); //calculo do rank r.PontuacaoP2 = r.PontuacaoP2 + (r.Dias * (-100)); //pontuacao final do recurso r.Pontuacao = r.PontuacaoP1 + r.PontuacaoP2; } }
Quadro 7 – Método CalculaRank
3.3.2.5 Gravar a alocação do recurso
Este processo tem como objetivo realizar a alocação física do recurso ao calendário de
alocações. A solicitação de mudança é dividida em dias e em horas, em seguida busca-se o
próximo horário livre de alocação do recurso, e então é realizada a persistência gerando
registros de alocação para período disponível para o recurso.
48
Para a persistência da alocação do recurso no banco de dados, foram criados três
métodos auxiliares ao método GravarAlocacao, os quais são:
a) DiaUtil: retorna o próximo dia útil livre e disponível do recurso. O método recebe
como parâmetro uma data a ser validada, e o recurso. Faz-se a verificação se a data
é sábado, ou domingo, e adicionam-se dias a data. Este método é utilizado de
forma recursiva. Também é feita a validação se a data não é um feriado, e também
é validado se não possui nenhuma restrição para o recurso. Para estes dois últimos
itens, foram criados os métodos Feriado e Restricao respectivamente;
b) Feriado: método auxiliar que retorna um booleano se data informada é um
feriado cadastrado na ferramenta;
c) Restricao: método auxiliar que retorna um valor booleano se o recurso possui
uma restrição na data informada.
O Quadro 8, Quadro 9 e Quadro 10 apresentam respectivamente os métodos DiaUtil,
Feriado e Restricao.
public DateTime DiaUtil(DateTime dt, Recurso r) { if (dt.DayOfWeek == DayOfWeek.Saturday) { dt = dt.AddDays(2); return DiaUtil(dt, r); } else if (dt.DayOfWeek == DayOfWeek.Sunday) { dt = dt.AddDays(1); return DiaUtil(dt, r); } else if (Feriado(dt) == true) { dt = dt.AddDays(1); return DiaUtil(dt, r); } else if (Restricao(dt, r) == true) { dt = dt.AddDays(1); return DiaUtil(dt, r); } else { return dt; } }
Quadro 8 – Método DiaUtil
49
public bool Feriado(DateTime dt) { List<Feriado> feriados = db.Feriado.ToList(); foreach (Feriado feriado in feriados) { if (feriado.DataFim.Date == dt.Date) { return true; } } return false; }
Quadro 9 – Método Feriado
private bool Restricao(DateTime dt, Recurso r) { List<Restricao> restricoes = db.Restricao.Where(p => p.CodigoRecurso == r.Codigo).ToList(); foreach (Restricao restricao in restricoes) { if (dt >= restricao.DataInicio && dt <= restricao.DataFim) { return true; } } return false; }
Quadro 10 – Método Restricao
O Quadro 11 mostra o método GravarAlocacao, que faz todas as validações
necessárias e divide a solicitação de mudança em dias e horas. Para cada quebra gerada, é
criada uma alocação, persistindo a alocação na entidade AlocacaoRecurso. Na figura 16 é
exibida a entidade que contém o recurso, a solicitação de mudança, a data de início e a data de
término. Os campos de data são do tipo datetime, o que permite saber o horário de término
previsto de uma alocação. No método GravarAlocacao foi implementada a regra de negócio
que possibilita para a ferramenta a alocação de mais de uma solicitação de mudança no
mesmo dia, quando há horário disponível do recurso/alocação.
Após o processamento de alocação da solicitação de mudança, é alterado o status da
mesma para “Aguardando Programação”.
50
Figura 16 - Classe AlocacaoRecurso
public void GravarAlocacao(int codigoSolicitacaoMudanca, int codigoRecurso) { AlocacaoRecurso alocacao = db.AlocacaoRecurso .Where(p => p.CodigoRecurso == codigoRecurso) .OrderByDescending(p => p.DataFim) .FirstOrDefault(); SolicitacaoMudanca solicitacao = db.SolicitacaoMudanca.Single(c => c.Codigo == codigoSolicitacaoMudanca); Recurso recurso = db.Recurso.Single(c => c.Codigo == codigoRecurso); AlocacaoRecurso aloca = new AlocacaoRecurso(); DateTime data = new DateTime(); if (alocacao == null) { data = DiaUtil(DateTime.Today.AddHours(8), recurso); } else { //aloca no proximo dia util - trocar por data fim!! data = alocacao.DataFim; if (data.Hour == 18) { //se a hora é igual a 18, entao é final do dia, adiciona um dia util. data = DiaUtil(data.AddDays(1), recurso); data = new DateTime(data.Year, data.Month, data.Day, 8, 0, 0); } else { data = DiaUtil(data, recurso); } } decimal dias = (Convert.ToDecimal(solicitacao.HoraProgramacao.Value) / (Convert.ToDecimal(recurso.HorasDia) +
51
Convert.ToDecimal(0.5))); decimal hora = 0; for (int i = 1; i <= decimal.Truncate(dias); i++) { //a cada iteracao valida se é dia util. data = DiaUtil(data, recurso); if (data.Hour == 18) { //se a hora é igual a 18, entao é final do dia, adiciona um dia util. data = DiaUtil(data.AddDays(1), recurso); data = new DateTime(data.Year, data.Month, data.Day, 8, 0, 0); } if (data.Hour == 8) { //codigo suprimido #region alocacaoNormal } else { //senao, faz o calculo para alocacao no periodo correto. if (data.Hour > 12) { //codigo suprimido #region manha } else { //codigo suprimido #region manhaetarde } } } if (dias % 1 > 0) { hora += solicitacao.HoraProgramacao.Value - ((recurso.HorasDia + Convert.ToDecimal(0.5)) * decimal.Truncate(dias)); if (data.Hour == 18) { //se a hora é igual a 18, entao é final do dia, adiciona um dia util. data = DiaUtil(data.AddDays(1), recurso); data = new DateTime(data.Year, data.Month, data.Day, 8, 0, 0); } //verifica a hora da data e adiciona horas if (data.Hour > 12) hora += 4 + (Convert.ToDecimal(4.5) - (18 - data.Hour)); else hora += data.Hour - 8; if (data.Hour == 8) { //codigo suprimido #region alocacaoComecodoDia } else { //codigo suprimido
52
#region alocacaoporhora } } //Apos alocar, define a Solicitação de Mudança como Aguardando Programação. solicitacao.CodigoStatus = db.Status.Single(c => c.Descricao.Equals("Aguardando Programação")).Codigo; db.SolicitacaoMudanca.ApplyCurrentValues(solicitacao); db.ObjectStateManager.ChangeObjectState(solicitacao, EntityState.Modified); db.SaveChanges(); }
Quadro 11 – Método GravarAlocacao
3.3.2.6 Apresentação dos resultados
Após o término de busca do melhor recurso a ser alocado utilizando as técnicas do
NSGA-II, as alocações ficam persistidas no banco de dados na entidade AlocacaoRecurso.
Ao usuário selecionar a opção no menu para visualizar o calendário é realizada uma
requisição AJAX. O Quadro 12 mostra o código JavaScript para o carregamento das
alocações para o calendário de alocações e recursos.
jQuery(function () { var dataPath = location.href.substring(0, location.href.lastIndexOf('/') + 1); $(".gantt").gantt({ source: '@Url.Action("getAlocacao", "Alocacao")', months: [ "Janeiro", "Fevereiro", "Março", "Abril", "Maio", "Junho", "Julho", "Agosto", "Setembro", "Outubro", "Novembro", "Dezembro" ], dow: [ "D", "S", "T", "Q", "Q", "S", "S"], navigate: 'scroll', scale: 'days', maxScale: 'days', minScale: 'hours', waitText: 'Carregando Alocações', itemsPerPage: 50 }); });
Quadro 12 – Requisição AJAX para carregamento das alocações para o calendário
As requisições AJAX são enviadas diretamente as classes controllers que executam a
53
requisição, através de consultas, utilizando a tecnologia LINQ, sobre os resultados na
memoria e retornam os dados no formato JSON, que é interpretado pela view.
Os resultados das alocações são mostrados em forma de calendário de recursos, onde
se pode observar a lista de recursos com suas respectivas alocações. O método de visualização
de alocação utiliza três cores para diferenciar alocação de solicitação de mudança, de restrição
e feriado, tornando assim fácil a visualização no calendário.
A figura 17 mostra o calendário de alocação. À esquerda ficam os recursos cadastrados,
ao centro é mostrado o calendário dos recursos. Na parte inferior da tela encontra-se uma
barra de menus do calendário.
Figura 17 - Tela de visualização do calendário de alocações
Na figura 18 está ilustrado a barra de menus do calendário. Os botões deste menu
respectivamente são:
a) anterior: navegaçao do calendário, para retroceder na lista de recursos;
b) próxima: avança para os próximos recursos;
54
c) data atual: posiciona o calendário a partir da data atual;
d) para tras: move o calendario entre os meses para tras;
e) cursor: faz a movimentão para frente e para tras nos meses do calendario, assume a
função dos dois botões ao seu redor;
f) para frente: move o calendario entre os meses para frente;
g) mais: aumenta o zoom do calendário;
h) menos: diminui o zoom do calendário.
Figura 18 - Barra de menus do calendário de recursos
3.3.3 Operacionalidade da implementação
Esta seção apresenta a funcionalidade e operacionalidade da ferramenta, mostrando
suas principais características através de um estudo de caso, onde será mostrado todo o
processo de alocação de solicitação de mudança, dos cadastros e visualizar alocações.
A figura 19 mostra o fluxo de funcionamento da ferramenta, o qual é iniciado pelo
cadastramento das informações essenciais para o funcionamento da ferramenta. Este processo
está dividido em parâmetros, cadastros básicos e recursos.
Após o usuário tem a opção de executar o processo de alocação automática, onde a
ferramenta apresenta as melhores alocações encontradas, ou manualmente onde o usuário cria
as alocações. Então o usuário pode visualizar os resultados. Nas sessões seguintes são
apresentados todos os passos do processo. act Fluxo
Cadastros
Alocação
Automática
Alocação
Manual
Visualização da
Alocação
FimInicio
Figura 19 - Fluxo de funcionamento da ferramenta
Na figura 20 é mostrada a tela principal da ferramenta desenvolvida.
55
Figura 20 - Tela principal da ferramenta
A estrutura das telas da ferramenta é formada por um topo, contendo a logo da FURB e
o menu principal, e na parte central, é exibido as informações referente ao item selecionado no
menu. Com exceção do menu de alocação quem possui um comportamento diferente, cada
opção possui uma tabela que lista os registros, contendo uma coluna de ações, que
representam as opções de editar e excluir o registro, e em seguida as informações mais
relevantes da entidade selecionada (figura 21). Acima desta tabela, contém o nome da
entidade selecionada, e um botão para adicionar novos registros.
Figura 21 - Tela de prioridades contendo as informações principais
56
3.3.3.1 Cadastros
Através do menu superior (figura 22) é possível acessar as funções de cadastros. Os
cadastros estão subdivididos em quatros itens principais para facilitar a navegabilidade na
ferramenta, os quais são:
a) parâmetros: através deste menu, é possível realizar o cadastro ou manutenção das
funções, feriados, prioridades, status, tipos de restrições e tipos de solicitação
(figura 23);
b) cadastros básicos: no item de cadastro básico é possível realizar o cadastro ou
manutenção de clientes, sistemas, módulos, requisitos, habilidades, atitudes,
projetos e solicitantes (figura 24);
c) recursos: neste menu é possível realizar o cadastro ou manutenção de recursos,
realizar o processo de associação de atitude, conhecimentos, habilidades e
adicionar restrições aos recursos (figura 25);
d) solicitação de mudança: através deste menu, é possível realizar o cadastro ou
manutenção das solicitações de mudanças.
Figura 22 - Menu principal da ferramenta
Figura 23 - Menu parâmetros e subitens
57
Figura 24 - Menu cadastros básicos e subitens
Figura 25 - Menu recursos e subitens
Funções, feriados, prioridades, status, tipos de restrições, tipos de solicitações, cliente,
sistemas, módulos, requisitos, habilidades, atitudes, projetos e solicitantes são utilizados nos
cadastros de recursos e de solicitações de mudanças. Assim, o usuário deve respeitar essa
sequência para conseguir efetuar o cadastramento. A figura 26 mostra o cadastramento da
função “Programador” na ferramenta.
58
Figura 26 - Cadastro de funções
Para o cadastro de módulos, é necessário vincular as habilidades necessárias para
poder trabalhar no mesmo. A figura 27 demonstra o processo de vinculo de habilidades para o
módulo.
Figura 27 - Cadastro de habilidades
Este vínculo é necessário para realizar o cruzamento dos recursos que possuem
conhecimento no sistema e módulo com estas habilidades e atribuir pontuação para o mesmo.
Após realizado o cadastro, a ferramenta retorna para a tela principal do item
selecionado no menu. É apresentada uma tabela contendo as principais informações da
entidade. A Figura 28 exibe a lista de habilidades cadastradas.
59
Figura 28 – Tela de habilidades
No cadastro do recurso deve ser informado nome, quantidade de horas de trabalho
deste recurso por dia e função. Após clicar em “Gravar” o recurso é criado, porém ainda não
possui nenhuma atitude, conhecimento e habilidade associado a ele. A figura 29 mostra o
cadastramento do recurso “Christian Grosh” já utilizando a função “Programador” cadastrado
anteriormente.
Figura 29 - Cadastro de recursos
A figura 30 mostra a tela de recursos e os ícones destacados na figura, que são
utilizados para a associação dos atributos. Cada ícone representa respectivamente, atitudes,
conhecimentos e habilidades. Ao clicar sobre o ícone, o usuário é direcionado para a
associação do respectivo item ao recurso.
60
Figura 30 - Tela de recursos com destaque para ícones de associação
Para a associação de atitudes, é feita a associação do recurso com a atitude cadastrada
(figura 31). O processo deve ser repetido para cada atitude que se deseja vincular ao recurso.
Figura 31 - Associação de atitudes
Na associação de conhecimentos, é selecionado o recurso, sistema, módulo, e o
percentual de conhecimento do recurso para este módulo (figura 32). Este percentual de
conhecimento é utilizado para o cálculo da pontuação dos recursos.
61
Figura 32 - Associação de conhecimento ao recurso
Para a associação de habilidades ao recurso, é informado o recurso, a habilidade e o
percentual de conhecimento do recurso sobre a habilidade (figura 33).
Figura 33 - Associação de habilidade ao recurso
Para a criação de restrições para um recurso o usuário escolhe a opção “Restrição” no
menu “Recursos”. É informado o recurso, o tipo de restrição (já cadastrada anteriormente) a
data de início e a data de fim, ao clicar em “Gravar” a ferramenta cria a restrição (figura 34).
62
Figura 34 - Criação de restrição ao recurso
Como mostra a figura 35, o cadastro de solicitação de mudança contém as informações
como número da solicitação, solicitação, descrição da solicitação, data da solicitação, prazo
do cliente, cliente, solicitante, prioridade, sistema, módulo, requisito, projeto, status da
solicitação, tipo de solicitação, e a quantidade de horas necessárias para executar a solicitação,
que está dividida em análise de negócios, análise de sistemas, programação, testes e
documentação.
63
Figura 35 - Cadastro de solicitação de mudança
3.3.3.2 Alocação automática
Após os cadastros realizados o usuário pode optar por realizar a alocação automática.
Essa opção está disponível no menu superior no item alocação e subitem “Executar Alocação”
(figura 36). O usuário tem acesso também à opção de “Alocação Manual”, que é detalhada na
seção seguinte.
64
Figura 36 - Menu de alocação da ferramenta
Ao escolher a opção “Executar Alocação” é enviada a requisição ao controller que
irá executar o processo de busca das solicitações de mudanças pendentes (as solicitações que
estão com o status de determinar programador) e irá buscar o melhor recurso através do
algoritmo NSGA-II. Após isso a ferramenta gera a alocação conforme as pontuações e
restrições dos recursos, apresentada no item 3.3.2, que pode demorar alguns segundos de
acordo com a quantidade de solicitações pendentes de alocação. Após o término do
processamento é exibida a mensagem “Alocação realizada!” e sugere ao usuário visualizar a
alocação realizada. Após a alocação automática não é possível alterar a alocação gerada. O
processo de alocação manual é apresentado no item 3.3.3.4
3.3.3.3 Visualização da alocação
Os resultados das alocações são apresentados em forma de calendário de recursos, que
está dividido em meses, de acordo com o intervalo entre a menor e a maior das alocações de
solicitação de mudanças e de restrições.
A figura 37 mostra o calendário de recursos do mês de junho de 2012. Pode-se navegar
entre os dias/meses através da barra inferior do calendário. Ao navegador não é feita
novamente requisição no servidor de aplicação. Basta clicar sobre os itens da barra que a ação
é executada instantaneamente, pois nesse instante não ocorre uma nova requisição ao
servidor.
65
Figura 37 – Calendário de recursos e alocações
O calendário utiliza as cores laranja, vermelho e verde para representar
respectivamente uma restrição, um feriado ou uma alocação de solicitação de mudança. As
letras, “R”, “F”, “S” nos quadrados coloridos sobre os dias, representam respectivamente,
restrição, feriado e solicitação de mudança. Isso torna a compreensão do calendário mais fácil
e rápida. Ao parar o ponteiro do mouse sobre qualquer um dos itens do calendário são
exibidas as informações sobre a restrição (figura 38), feriado (figura 39) ou alocação (figura
40).
Figura 38 - Legenda de restrição de folga no calendário de recursos e alocações
Figura 39 - Legenda de feriado no calendário de recursos e alocações
66
Figura 40 - Legenda de solicitação de mudança no calendário de recursos e alocações
3.3.3.4 Alocação manual
Para criar uma alocação manualmente o usuário escolhe a opção “Alocação Manual”
no menu superior. O sistema irá exibir uma tela para seleção de uma das solicitações de
mudanças que estão pendentes de alocação. Em seguida, o usuário seleciona o recurso e clica
em alocar (figura 41).
Figura 41 - Alocação manual de solicitação de mudança e recurso
No grid de solicitações de mudanças (figura 42), há um ícone que pode estar visível ou
não. Caso esteja visível, é a identificação de que a solicitação de mudança não foi alocada
para nenhum recurso, e ao clicar no ícone, o usuário é direcionado para a alocação manual. O
combobox com a solicitação virá preenchido e o usuário deverá selecionar o recurso e clicar
em alocar, como descrito anteriormente.
67
Figura 42 - Atalho para alocação manual de solicitação de mudança
A ferramenta irá alocar a solicitação de mudança selecionada a partir do próximo dia
disponível do recurso. A ferramenta considera as restrições cadastradas para o recurso,
portanto não será feita nenhuma alocação em dias que o recurso tenha férias por exemplo.
O processo de alocação manual não considera as atitude, conhecimentos e habilidades
do recurso, ficando a critério do usuário a alocação criada.
3.4 RESULTADOS E DISCUSSÃO
O presente trabalho apresentou o desenvolvimento de uma ferramenta para a alocação
de recursos humanos aplicada a solicitações de mudança de software. Nele, a alocação dos
recursos se deu através do estudo e implementação do algoritmo NSGA-II.
Um dos problemas encontrados foi a correta interpretação da aplicação do algoritmo,
uma vez que na literatura existem várias formas que o mesmo é utilizado, o que causou
dúvidas, quanto à continuidade do mesmo neste trabalho. Após este estudo, foi aplicado o
algoritmo ao problema proposto, para a seleção automática de recursos gerando uma
pontuação para cada recurso cadastrado. Esta pontuação é determinante para a alocação, uma
vez que são analisados os atributos (atitude, conhecimento e habilidades) além de analisar a
quantidade de restrições e diminuir a pontuação do recurso que estiver mais alocado,
possibilitando uma distribuição das solicitações de mudança.
O estudo realizado sobre o processo da norma ISO/IEC 12207 e trabalhos correlatos
significaram muito para a realização do presente trabalho. A partir deste estudo foi possível
realizar uma análise e verificar os pontos positivos e negativos de cada caso em particular
68
para obter o maior aproveitamento possível.
O processo de resolução de problemas de software da norma ISO/IEC 12207 (adaptado
para este trabalho para atender solicitação de mudança de software) prevê resultados, que
foram comparados com a ferramenta desenvolvida, os quais são:
a) é desenvolvida uma estratégia de solicitação de mudança de software: a ferramenta
desenvolvida adota diretrizes para o cálculo de pontuação e alocação das
solicitações de mudança de software de forma manual e automática (atende bem);
b) as solicitações de mudança de software são documentadas, identificadas e
classificadas: a ferramenta é aderente com a inserção das solicitações de mudança,
informando a descrição, numeração, sistema, módulo, requisito e são classificados
conforme os tipos de solicitação previamente cadastrados na ferramenta (atende
bem);
c) as solicitações de mudança de software são avaliadas para identificar soluções
aceitáveis: a ferramenta permite que as solicitações sejam alocadas aos recursos
apropriados, porém uma análise prévia é feita anteriormente (atende parcialmente);
d) é implementada a solicitação de mudança de software: a ferramenta permite que as
solicitações sejam identificadas, classificadas e estimadas. Essas solicitações são
alocadas aos recursos e devidamente implementadas (atende bem);
e) as solicitações de mudança de software são rastreadas até seu fechamento: as
solicitações de mudança são alocadas aos recursos, porém não há o controle até o
fechamento da solicitação de mudança (atende parcialmente);
f) o estado de cada uma das solicitações de mudança de software é conhecido: cada
solicitação de mudança possui o registro do status na ferramenta (atende bem).
Com relação aos trabalhos correlatos, este trabalho buscou aprimorar e aprofundar os
trabalhos apresentados. O Quadro 13 apresenta uma análise geral das funcionalidades
disponibilizadas pela ferramenta desenvolvida, em comparação com os trabalhos correlatos
pesquisados.
Funcionalidade Voigt Bastos QuickArrow
Plataforma Web Web Web
Idioma Português Português Inglês
Geração automática de alocações Sim Sim Não
Visualização das alocações através de
calendário de recursos
Sim Sim Sim
Cadastro de recursos e atributos Sim Sim Sim
Controle de custos Não Não Sim
Integração com outros sistemas Não Não Sim
69
Alocação múltipla por dia Sim Não Não Quadro 13 – Comparação das ferramentas
Outra forma de análise dos resultados obtidos foi à aplicação da ferramenta na empresa
Benner Sistemas S/A. Utilizou-se um cenário atual, a qual foi possível gerar alocação de
recursos humanos em solicitações de mudanças para o setor de logística, que envolvem três
sistemas, que são SLG, TMS e WMS, e também uma simulação com solicitações de mudança
do sistema de RH.
Os recursos foram cadastrados com suas atitudes, conhecimentos, habilidades e
restrições (folgas e férias). O tempo de parametrização de todo o cenário foi em torno de oito
horas. A alocação automática foi gerada em alguns segundos. De acordo com líderes de
processo da Benner, a alocação de uma quantidade significativa de solicitações de mudança
manualmente é lenta, pois é necessário verificar a fila de todos os recursos, comparar com as
restrições que não estão visualmente dispostas e então alocar a solicitação. O tempo
despendido para a utilização da ferramenta, desde a parametrização e inserção das solicitações
de mudança é relativamente menor do que uma alocação manual por um líder da área.
A figura 43 mostra o resultado da alocação gerada a partir do dia 16 de junho de 2012,
que comprova a funcionalidade da ferramenta.
Figura 43 - Resultado da alocação gerada nos testes
70
A alocação gerada está correta, pois devido à correta parametrização dos requisitos,
(conhecimentos, atitudes e habilidades) tanto dos recursos como dos sistemas e módulos, foi
possível gerar uma alocação concisa e que se mostrou eficiente.
A alocação gerada pela ferramenta foi validada por três diferentes líderes de processos,
com base em seus controles manuais. Identificaram-se, inclusive, alocações corretas que
normalmente não seriam alocadas em um processo manual, confirmando a dificuldade de
alocações manuais devido à falta de conhecimento ou até lembrança de todos os requisitos por
parte dos líderes.
O algoritmo desenvolvido resolve o melhor recurso para cada solicitação, sem
considerar o conjunto de solicitações. Os recursos são determinados a cada solicitação e estas
são ordenadas de acordo com sua prioridade e data. Assim os melhores recursos serão
selecionados, mas nem sempre o menor tempo de desenvolvimento será atingido.
71
4 CONCLUSÕES
De forma geral, pode-se considerar que os objetivos foram alcançados. O uso da
ferramenta permite que gestores de área de desenvolvimento e manutenção de software,
tenham maior agilidade no processo na alocação de recursos humanos para as solicitações de
mudança de software. Anteriormente ao case de uso da ferramenta, tomava-se muito tempo
dos líderes em processos manuais de consulta e alocação. Com a utilização da ferramenta este
processo foi automatizado, sendo necessária a manutenção das informações dos recursos, no
que diz respeito a atitudes, conhecimentos, habilidades, restrições e a correta inserção das
solicitações de mudança para uma alocação adequada. A alocação foi validada com a
utilização da ferramenta num cenário real da empresa Benner Sistemas S/A.
A ferramenta pode ser utilizada para facilitar a rotina diária de um profissional que
precisa alocar recursos, gerando uma alocação mais otimizada. A utilização do algoritmo
NSGA-II para encontrar os melhores recursos para cada solicitação de mudança, se mostrou
eficiente. Pode-se constatar que a ferramenta apresenta um ganho significativo de tempo em
relação a alocações manuais realizadas por líderes de processo.
Através do estudo do processo de resolução de problemas da norma ISO/IEC
12207:2009 devidamente adaptada para solicitações de mudança de software, foi possível
construir o processo de alocação de recursos humanos. A ferramenta desenvolvida se mostrou
bem aderente aos resultados previstos pela norma, pois dos seis resultados previstos, quatro
foram bem atendidos e dois parcialmente atendidos.
Há uma restrição para alocar a mesma solicitação de mudança de software por fases,
considerando as horas previstas na mesma, o que atualmente precisa ser feito em solicitações
separadas.
A ferramenta foi desenvolvida na linguagem de programação C# (ASP.NET) e banco
de dados SQL Server. Foram utilizadas técnicas e tecnologias atuais, como Entity Famework,
ASP.NET MVC Framework e LINQ, que mostraram-se eficientes, atendendo todas as
necessidades que sugiram.
A divisão em camadas do modelo MVC facilitou o desenvolvimento do projeto. Já a
especificação, através do uso da UML, auxiliou na definição do escopo e na codificação da
ferramenta.
72
4.1 EXTENSÕES
Como sugestões para continuação deste trabalho e melhoria da ferramenta, pode-se
citar:
a) permitir exportar os resultados para outras ferramentas de cronograma de projetos,
como por exemplo, o MS Project;
b) criar uma API para integração de solicitações de mudança de software de outros
sistemas, facilitando assim a entrada de dados na ferramenta;
c) incorporar funções para alcançar um nível maior de aderência à norma ISO/IEC
12207;
d) permitir a ferramenta realizar o controle da alocação prevista, possibilitando
comparar com o realizado, criando métricas de controle da produtividade;
e) permitir múltiplos objetivos de alocação de recursos, possibilitando que o usuário
selecione o recurso para cada solicitação após a execução do algoritmo.
73
REFERÊNCIAS BIBLIOGRÁFICAS
ARRUDA, Saulo. ISO/IEC 12207 processos fundamentais. [S.1.], [2007]. Disponível em:
<http://www.plugmasters.com.br/sys/materias/539/1/ISO%7B47%7DIEC-12207-Processos-
Fundamentais>. Acesso em: 02 set. 2011.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 12207:2009:
sistemas e engenharia de software – processos de ciclo de vida do software. Rio de Janeiro,
2009.
BASTOS, Jean R. Planejamento de alocação de recursos humanos em projetos. 2009. 83
f. Trabalho de Conclusão de Curso (Graduação em Ciências da Computação) - Centro de
Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
BRASIL FILHO, Amaury T. et al. Otimização da alocação de profissionais em projetos de
tecnologia da informação. SIMPÓSIO BRASILEIRO DE PESQUISA OPERACIONAL, 38.,
2006, Goiana. Anais... João Pessoa: UFPB, 2006. p. 2292-2302.
COELLO, Carlos A. C.; LAMONT, Gary B.; VELDHUISEN, David A. V. Evolutionary
algorithms for solving multi-objective problems. Norwell: Kluwer acad, 2002.
CONERY, Rob et al. Professional ASP.NET MVC 1.0. Indianapolis: Wiley Publishing,
2009.
CORREA, Eduardo A. Gestão de pessoas nos projetos de software. [S.1.], [2011].
Disponível em: <http://www.eduacorrea.blogspot.com/2011/02/gestao-de-pessoas-nos-
projetos-de.html>. Acesso em: 02 set. 2011.
DEB, Kalyanmoy et al. A fast elitist non-dominated sorting genetic algorithm for multi-
objective optimization: NSGA-II. Indian Institute of Technology Kanpur, India, n. 8, p. 2-
9, 2000.
FILHO, Paulo A. C.; POPPI, Rosinei J. Algoritmo genético em química. São Paulo:
Universidade Estadual de Campinas, 1998.
FOWLER, Martin. GUI architectures. [S.l.], 2006. Disponível em:
<http://martinfowler.com/eaaDev/uiArchs.html>. Acesso em: 21 abr. 2012.
HARTMANN, Sonke; KOLISCH, Rainer. Experimental evaluation of state-of-the-art
heuristics for the resource-constrained project scheduling problem. Darmstadt: Elsevier,
1998.
HIRAMA, Kechi. Engenharia de software: qualidade e produtividade com tecnologia. Rio
de Janeiro: Elsevier, 2011.
74
HOLLAND, John H. Adaptation in natural and artificial systems. Ann Arbor: University
of Michigan Press, 1975.
HOPPE, Charles. Software de apoio a manutenção de sistemas baseado em normas de
qualidade. 1999. 109 f. Trabalho de Conclusão de Curso (Graduação em Ciências da
Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau,
Blumenau.
LEMOS, Tiago. O que é o MVC. [S.l.], 2009. Disponível em:
<http://www.tiagolemos.com.br/2009/07/10/o-que-e-o-mvc-model-view-controller>. Acesso
em: 21 abr. 2012.
MACORATTI, José C. ASP .NET – MVC: introdução. [S.l.], [2008?]. Disponível em:
<http://www.macoratti.net/08/06/asp_mvc1.htm>. Acesso em: 21 abr. 2012.
MICROSOFT CORPORATION. ASP.NET Model View Controler (MVC). [S.l.], [2011?]a.
Disponível em: <http://msdn.microsoft.com/en-us/library/dd394709.aspx>. Acesso em: 21
abr. 2012.
______. ASP.NET MVC overview: the official Microsoft ASP.NET site. [S.l.], [2011?]b.
Disponível em: <http://www.asp.net/mvc/overview>. Acesso em: 21 abr. 2012.
PFLEEGER, Shari L. Engenharia de software: teoria e prática. Tradução Dino Franklin. São
Paulo: Prentice Hall, 2004.
PRESSMAN, Roger S. Engenharia de software. Tradução Mônica Maria G. Travieso. Rio
de Janeiro: McGraw-Hill, 2002.
QUICKARROW. Resource management, utilization, scheduling and planning software
tools. Austin, 2010. Disponível em:
<http://www.quickarrow.com/news_events/serviceline_news/Svcs_Visibility.asp>. Acesso
em: 03 set. 2011.
RABAGLIO, Maria O. Seleção por competências. 4. ed. São Paulo: Educator, 2004.
RIBEIRO, Rodrigo L. F. Projeto e construção de um sistema de programação genética.
2009. 97 f. Monografia (Sistemas de Informação) - Instituto de Informática, Pontifícia
Universidade Católica de Minas Gerais, Minas Gerais.
SPOLAÔR, Newton. Aplicação de algoritmos genéticos multiobjetivo ao problema de
seleção de atributos. 2010. 134 f. Dissertação (Mestrado em Engenharia da Informação) -
Curso de Mestrado em Engenharia Elétrica, Universidade Federal do ABC, Santo André.
SOMMERVILLE, Ian. Engenharia de software. 6. ed. Tradução André Maurício de
Andrade Ribeiro. São Paulo: Addison Wesley, 2003.
75
SOMMERVILLE, Ian. Engenharia de software. 8. ed. São Paulo: Pearson, Prentice Hall,
2007. xiv, 552 p, il.
VARGAS, Ricardo V. Gerenciamento de projetos: estabelecendo diferenciais competitivos.
5. ed. Rio de Janeiro: Brasport, 2003.
VIEIRA, Marconi F. Gerenciamento de projetos de tecnologia de informação. Rio de
Janeiro: Campus, 2003.
76
APÊNDICE A – Descrições dos Casos de Uso
Nos Quadro 14, Quadro 15 e Quadro 16 são apresentados às descrições dos casos de
uso da ferramenta. Optou-se por descrever de forma detalhada apenas os casos de uso mais
críticos da aplicação.
UC13 – Alocar manualmente recurso
Descrição Permite a alocação manual de solicitação de mudança para um recurso.
Atores Gerente
Cenário principal 1. O gerente seleciona a opção “Alocação Manual” no menu superior
“Alocação” da tela principal;
2. O sistema apresenta a lista de solicitações de mudança que não possuem
alocação e o ator seleciona uma solicitação;
3. O gerente seleciona o recurso;
4. O gerente escolhe a opção “Alocar”;
5. O sistema verifica a próxima data livre do recurso selecionado;
6. O sistema gera a alocação;
7. O sistema fecha a janela de seleção, retornando a tela de visualização de
alocação;
8. O sistema apresenta em forma de calendário as alocações dos recursos.
Exceções No passo 4: Erro no na geração da alocação.
O sistema não encontrou nenhuma solicitação sem alocação.
O sistema termina a operação.
Pré-condições Recursos e solicitações de mudança de software previamente cadastrado. A
solicitação de mudança não pode possuir alocação.
Pós-condições Recurso alocado.
Quadro 14 - Descrição do caso de uso UC13 – Alocar manualmente recurso
UC14 – Alocar automaticamente recurso
Descrição Permite ao ator criar a alocação dos profissionais.
Atores Gerente
Cenário principal 1. O gerente seleciona a opção “Executar Alocação” no menu superior
“Alocação” da tela principal;
2. O sistema inicia a alocação automática;
3. O sistema identifica as solicitações de mudanças não alocadas;
4. O sistema executa os cálculos e encontra o melhor recurso para ser
alocado;
5. O sistema apresenta a mensagem “Alocação realizada!”.
Exceções No passo 3 e 4: Erro no na geração da alocação.
O sistema não encontrou nenhuma solicitação ou não há recursos aptos a
executar a solicitação.
O sistema termina a operação.
Pré-condições Atitudes, conhecimentos, habilidades, restrições, solicitações de mudança e
recursos previamente cadastrados.
Pós-condições Recursos alocados.
Quadro 15 - Descrição do caso de uso UC14 – Alocar automaticamente recurso
77
UC15 – Visualizar alocação
Descrição Permite ao ator visualizar a alocação dos recursos para as solicitações de
mudanças e restrições. Apresenta na forma de calendário a relação de
recursos e alocações. Essa relação permite ao usuário saber quanto tempo
cada recurso ficará alocado e quais as datas de inicio e fim de cada alocação.
Cenário principal 1. O gerente seleciona a opção “Ver Alocação” no menu superior
“Alocação” da tela principal;
2. O sistema exibe o calendário com as alocações contendo os feriados,
restrições e solicitações de mudança de software.
Atores Gerente
Pré-condições Alocação automática ou manual previamente realizada.
Pós-condições Visualização do calendário.
Quadro 16 - Descrição do caso de uso UC15 – Visualizar alocação
![Acadêmico: Fabiano Bendercampeche.inf.furb.br/tccs/2012-II/TCC2012-2-10-AP-FabianoBender.p… · if self .var_flag : self .variavel[self .var_id] = [t. value , None ] return t #Método](https://img.document.onl/doc/110x75/600087fa6805c722ae654af2/acadmico-fabiano-if-self-varflag-self-variavelself-varid-t-value.jpg)
