GESTAO EM RH 5

Prévia do material em texto

TURNO: NOTURNO VERSÃO: 2 
ANO / 
SEMESTRE: 
2011.2 No 
 
UNIVERSIDADE REGIONAL DE BLUMENAU 
CENTRO DE CIÊNCIAS EXATAS E NATURAIS 
DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO 
CURSO DE CIÊNCIA DA COMPUTAÇÃO — BACHARELADO 
COORDENAÇÃO DE TRABALHO DE CONCLUSÃO DE CURSO 
 
PROPOSTA PARA O TRABALHO DE CONCLUSÃO DE CURSO 
TÍTULO: ALOCAÇÃO DE RECURSOS HUMANOS APLICADA A SOLICITAÇÕES 
DE MUDANÇA DE SOFTWARE 
ÁREA: Engenharia de Software 
Palavras-chave: Gestão de recursos humanos. Solicitações de mudança de software. 
Algoritmo de busca. 
1 IDENTIFICAÇÃO 
1.1 ALUNO 
Nome: Ricardo Voigt Código/matrícula: 54274 
Endereço residencial: 
Rua: Frei Estanislau Schaett n°: 451 Complemento: Casa 
Bairro: Água Verde CEP: 89037-001 Cidade: Blumenau UF: SC 
Telefone fixo: 3329-0927 Celular: 9997-2546 
Endereço comercial: 
Empresa: Benner Sistemas 
Rua: Antônio da Veiga n°: 419 Bairro: Victor Konder 
CEP: 89012-500 Cidade: Blumenau UF: SC Telefone: 2111-4800 
E-Mail FURB: E-Mail alternativo: voigtt@gmail.com 
1.2 ORIENTADOR 
Nome: Everaldo Artur Grahl 
E-Mail FURB: egrahl@furb.br E-Mail alternativo: everaldo.grahl@gmail.com 
 
 
 
2 DECLARAÇÕES 
2.1 DECLARAÇÃO DO ALUNO 
Declaro que estou ciente do Regulamento do Trabalho de Conclusão de Curso de 
Ciência da Computação e que a proposta em anexo, a qual concordo, foi por mim rubricada 
em todas as páginas. Ainda me comprometo pela obtenção de quaisquer recursos necessários 
para o desenvolvimento do trabalho, caso esses recursos não sejam disponibilizados pela 
Universidade Regional de Blumenau (FURB). 
Assinatura: Local/data: 
 
2.2 DECLARAÇÃO DO ORIENTADOR 
Declaro que estou ciente do Regulamento do Trabalho de Conclusão do Curso de 
Ciência da Computação e que a proposta em anexo, a qual concordo, foi por mim rubricada 
em todas as páginas. Ainda me comprometo a orientar o aluno da melhor forma possível de 
acordo com o plano de trabalho explícito nessa proposta. 
Assinatura: Local/data: 
 
 
3 AVALIAÇÃO DA PROPOSTA 
3.1 AVALIAÇÃO DO(A) ORIENTADOR(A) 
Acadêmico(a): Ricardo Voigt 
Orientador(a): Everaldo Artur Grahl 
 
ASPECTOS AVALIADOS 
at
en
d
e 
at
en
d
e 
p
ar
ci
al
m
en
te 
n
ão
 a
te
nd
e 
A
S
P
E
C
T
O
S
 
T
É
C
N
IC
O
S
 
1. INTRODUÇÃO 
1.1. O tema de pesquisa está devidamente contextualizado/delimitado? 
 
1.2. O problema está claramente formulado? 
2. OBJETIVOS 
2.1. O objetivo geral está claramente definido e é passível de ser alcançado? 
 
2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral? 
Caso não sejam apresentados objetivos específicos, deixe esse item em branco. 
 
3. RELEVÂNCIA 
3.1. A proposta apresenta um grau de relevância em computação que justifique o 
desenvolvimento do TCC? 
 
4. METODOLOGIA 
4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC? 
 
4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a 
metodologia proposta? 
 
4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de 
maneira a permitir a execução do TCC no prazo disponível? 
 
5. REVISÃO BIBLIOGRÁFICA 
5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC? 
 
5.2. São apresentados trabalhos correlatos, bem como comentadas as principais 
características dos mesmos? 
 
6. REQUISITOS DO SISTEMA A SER DESENVOLVIDO 
6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram 
claramente descritos? 
 
7. CONSIDERAÇÕES FINAIS 
7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica 
com a realização do TCC? 
 
A
S
P
E
C
T
O
S
 
M
E
T
O
D
O
L
Ó
G
IC
O
S
 
8. REFERÊNCIAS BIBLIOGRÁFICAS 
8.1. As referências bibliográficas obedecem às normas da ABNT? 
 
8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na 
proposta (são usadas obras atualizadas e/ou as mais importantes da área)? 
 
9. CITAÇÕES 
9.1. As citações obedecem às normas da ABNT? 
 
9.2. As informações retiradas de outros autores estão devidamente citadas? 
10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada) 
10.1. O texto obedece ao formato estabelecido? 
 
10.2. A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem 
utilizada é clara)? 
 
A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se: 
• qualquer um dos itens tiver resposta NÃO ATENDE; 
• pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou 
• pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE. 
PARECER: ( ) APROVADA ( ) NECESSITA DE COMPLEMENTAÇÃO 
 
Assinatura do(a) avaliador(a): Local/data: 
 
 
 
CONSIDERAÇÕES DO(A) ORIENTADOR(A): 
Caso o(a) orientador(a) tenha assinalado em sua avaliação algum item como “atende parcialmente”, devem ser relatos os 
problemas/melhorias a serem efetuadas. 
 
Na segunda versão, caso as alterações sugeridas pelos avaliadores não sejam efetuadas, deve-se incluir uma justificativa. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Assinatura do(a) avaliador(a): Local/data: 
 
 
3.2 AVALIAÇÃO DO(A) COORDENADOR DE TCC 
Acadêmico(a): Ricardo Voigt 
Avaliador(a): José Roque Voltolini da Silva 
 
ASPECTOS AVALIADOS 
at
en
d
e 
at
en
d
e 
p
ar
ci
al
m
en
te 
n
ão
 a
te
nd
e 
A
S
P
E
C
T
O
S
 
T
É
C
N
IC
O
S
 
1. INTRODUÇÃO 
1.1. O tema de pesquisa está devidamente contextualizado/delimitado? 
 
1.2. O problema está claramente formulado? 
2. OBJETIVOS 
2.1. O objetivo geral está claramente definido e é passível de ser alcançado? 
 
2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral? 
Caso não sejam apresentados objetivos específicos, deixe esse item em branco. 
 
3. RELEVÂNCIA 
3.1. A proposta apresenta um grau de relevância em computação que justifique o 
desenvolvimento do TCC? 
 
4. METODOLOGIA 
4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC? 
 
4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a 
metodologia proposta? 
 
4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de 
maneira a permitir a execução do TCC no prazo disponível? 
 
5. REVISÃO BIBLIOGRÁFICA 
5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC? 
 
5.2. São apresentados trabalhos correlatos, bem como comentadas as principais 
características dos mesmos? 
 
6. REQUISITOS DO SISTEMA A SER DESENVOLVIDO 
6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram 
claramente descritos? 
 
7. CONSIDERAÇÕES FINAIS 
7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica 
com a realização do TCC? 
 
A
S
P
E
C
T
O
S
 
M
E
T
O
D
O
L
Ó
G
IC
O
S
 
8. REFERÊNCIAS BIBLIOGRÁFICAS 
8.1. As referências bibliográficas obedecem às normas da ABNT? 
 
8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na 
proposta (são usadas obras atualizadas e/ou as mais importantes da área)? 
 
9. CITAÇÕES 
9.1. As citações obedecem às normas da ABNT? 
 
9.2. As informações retiradas de outros autores estão devidamente citadas? 
10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada) 
10.1. O texto obedece ao formato estabelecido? 
 
10.2. A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem 
utilizada é clara)? 
 
A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se: 
• qualquer um dos itens tiver resposta NÃO ATENDE; 
• pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou 
• pelo menos 4 (quatro) itens dosASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE. 
PARECER: ( ) APROVADA ( ) NECESSITA DE COMPLEMENTAÇÃO 
OBSERVAÇÕES: 
 
 
Assinatura do(a) avaliador(a): Local/data: 
 
 
3.3 AVALIAÇÃO DO(A) PROFESSOR(A) DA DISCIPLINA DE TCCI 
Acadêmico(a): Ricardo Voigt 
Avaliador(a): Sérgio Stringari 
 
ASPECTOS AVALIADOS 
at
en
d
e 
at
en
d
e 
p
ar
ci
al
m
en
te 
n
ão
 a
te
nd
e 
A
S
P
E
C
T
O
S
 
T
É
C
N
IC
O
S
 
1. INTRODUÇÃO 
1.1. O tema de pesquisa está devidamente contextualizado/delimitado? 
 
1.2. O problema está claramente formulado? 
2. OBJETIVOS 
2.1. O objetivo geral está claramente definido e é passível de ser alcançado? 
 
2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral? 
Caso não sejam apresentados objetivos específicos, deixe esse item em branco. 
 
3. RELEVÂNCIA 
3.1. A proposta apresenta um grau de relevância em computação que justifique o 
desenvolvimento do TCC? 
 
4. METODOLOGIA 
4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC? 
 
4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a 
metodologia proposta? 
 
4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de 
maneira a permitir a execução do TCC no prazo disponível? 
 
5. REVISÃO BIBLIOGRÁFICA 
5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC? 
 
5.2. São apresentados trabalhos correlatos, bem como comentadas as principais 
características dos mesmos? 
 
6. REQUISITOS DO SISTEMA A SER DESENVOLVIDO 
6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram 
claramente descritos? 
 
7. CONSIDERAÇÕES FINAIS 
7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica 
com a realização do TCC? 
 
A
S
P
E
C
T
O
S
 
M
E
T
O
D
O
L
Ó
G
IC
O
S
 
8. REFERÊNCIAS BIBLIOGRÁFICAS 
8.1. As referências bibliográficas obedecem às normas da ABNT? 
 
8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na 
proposta (são usadas obras atualizadas e/ou as mais importantes da área)? 
 
9. CITAÇÕES 
9.1. As citações obedecem às normas da ABNT? 
 
9.2. As informações retiradas de outros autores estão devidamente citadas? 
10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada) 
10.1. O texto obedece ao formato estabelecido? 
 
10.2. A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem 
utilizada é clara)? 
 
PONTUALIDADE NA ENTREGA 
 atraso de 
_____ dias 
A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se: 
• qualquer um dos itens tiver resposta NÃO ATENDE; 
• pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou 
• pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE. 
PARECER: ( ) APROVADA ( ) NECESSITA DE COMPLEMENTAÇÃO 
OBSERVAÇÕES: 
 
 
Assinatura do(a) avaliador(a): Local/data: 
 
 
3.4 AVALIAÇÃO DO(A) PROFESSOR(A) ESPECIALISTA NA ÁREA 
Acadêmico(a): Ricardo Voigt 
Avaliador(a): 
 
ASPECTOS AVALIADOS 
at
en
d
e 
at
en
d
e 
p
ar
ci
al
m
en
te 
n
ão
 a
te
nd
e 
A
S
P
E
C
T
O
S
 
T
É
C
N
IC
O
S
 
1. INTRODUÇÃO 
1.1. O tema de pesquisa está devidamente contextualizado/delimitado? 
 
1.2. O problema está claramente formulado? 
2. OBJETIVOS 
2.1. O objetivo geral está claramente definido e é passível de ser alcançado? 
 
2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral? 
Caso não sejam apresentados objetivos específicos, deixe esse item em branco. 
 
3. RELEVÂNCIA 
3.1. A proposta apresenta um grau de relevância em computação que justifique o 
desenvolvimento do TCC? 
 
4. METODOLOGIA 
4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC? 
 
4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a 
metodologia proposta? 
 
4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de 
maneira a permitir a execução do TCC no prazo disponível? 
 
5. REVISÃO BIBLIOGRÁFICA 
5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC? 
 
5.2. São apresentados trabalhos correlatos, bem como comentadas as principais 
características dos mesmos? 
 
6. REQUISITOS DO SISTEMA A SER DESENVOLVIDO 
6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram 
claramente descritos? 
 
7. CONSIDERAÇÕES FINAIS 
7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica 
com a realização do TCC? 
 
A
S
P
E
C
T
O
S
 
M
E
T
O
D
O
L
Ó
G
IC
O
S
 
8. REFERÊNCIAS BIBLIOGRÁFICAS 
8.1. As referências bibliográficas obedecem às normas da ABNT? 
 
8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na 
proposta (são usadas obras atualizadas e/ou as mais importantes da área)? 
 
9. CITAÇÕES 
9.1. As citações obedecem às normas da ABNT? 
 
9.2. As informações retiradas de outros autores estão devidamente citadas? 
10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada) 
10.1. O texto obedece ao formato estabelecido? 
 
10.2. A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem 
utilizada é clara)? 
 
A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se: 
• qualquer um dos itens tiver resposta NÃO ATENDE; 
• pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou 
• pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE. 
PARECER: ( ) APROVADA ( ) NECESSITA DE COMPLEMENTAÇÃO 
OBSERVAÇÕES: 
 
 
Assinatura do(a) avaliador(a): Local/data: 
 
 
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 
2011 
 
 
RICARDO VOIGT 
ALOCAÇÃO DE RECURSOS HUMANOS APLICADA A 
SOLICITAÇÕES DE MUDANÇA DE SOFTWARE 
Proposta de Trabalho de Conclusão de Curso 
submetida à Universidade Regional de 
Blumenau para a obtenção dos créditos na 
disciplina Trabalho de Conclusão de Curso I 
do curso de Ciência da Computação — 
Bacharelado. 
Prof. Everaldo Artur Grahl - Orientador 
BLUMENAU 
2011 
 
 
 
2
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 software é produzido. 
Segundo Sommerville (2003, p. 515), é impossível produzir sistemas de qualquer 
tamanho que não precisem ser modificados. 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 constantesmudanç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. 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. 
Decorrente das constantes mudanças nos softwares existem hoje no mercado normas 
para análise de requisitos, desenvolvimento e gerenciamento de software. Pode-se citar, por 
exemplo, a norma ISO/IEC 12207:2009, que têm processos de software sólidos, que tratam 
das questões relacionadas à gestão de mudanças (ASSOCIAÇÃO BRASILEIRA DE 
 
 
 
3
NORMAS TÉCNICAS, 2009). 
Diante do exposto, propõe-se desenvolver uma ferramenta para alocação dinâmica de 
recursos humanos aplicada a 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) implementar funcionalidades na ferramenta que sejam aderentes ao processo de 
resolução de problema da norma ISO/IEC 12207; 
b) disponibilizar funcionalidades para visão gerencial por setores como análise, 
desenvolvimento e qualidade; 
c) aplicar algoritmo de busca para seleção do melhor recurso humano para a 
solicitação. 
1.2 RELEVÂNCIA DO TRABALHO 
Em projetos de tecnologia da informação, um dos aspectos considerados como sendo 
de maior qualidade é a entrega dentro do prazo. É importante notar que produtos gerados por 
tecnologia têm uma janela temporal pequena devido às constantes renovações tecnológicas 
(VIEIRA, 2003, p. 58). Um dos maiores desafios de gerentes de projetos é gerenciar 
efetivamente os recursos. 
Fica evidente a importância do desenvolvimento de uma ferramenta que possibilite a 
alocação dinâmica de recursos humanos aplicado à gestão de mudança de software. A 
ferramenta a ser desenvolvida terá ênfase na norma ISO/IEC 12207. Utilizará um algoritmo 
computacional de busca, mais especificamente um algoritmo genético multiobjetivo 
denominado Non-dominated Sorting Genetic Algorithm II (NSGA II), para delegar o melhor 
 
 
 
4
recurso para determinada solicitação com base nas competências. Também possibilitará 
identificar a data de conclusão da solicitação, formando um cronograma de atividades por 
recurso. Esta ferramenta contribuirá para a área de engenharia de software e para empresas de 
software, aliviando assim a carga sobre os profissionais da área de gerência de projetos da 
tecnologia da informação na alocação de solicitações, pois esta atividade será por conta do 
algoritmo de busca, sendo assim uma alocação automática dos recursos. 
1.3 METODOLOGIA 
O trabalho será desenvolvido observando as seguintes etapas: 
a) levantamento bibliográfico: realizar levantamento bibliográfico sobre a norma 
ISO/IEC 12207, gestão de mudanças de software, alocação de recursos humanos, 
algoritmo de busca NSGA-II e trabalhos correlatos; 
b) elicitação de requisitos: detalhar e reavaliar os requisitos, observando as 
necessidades levantadas durante a revisão bibliográfica; 
c) especificação da ferramenta: especificar a ferramenta com análise orientada a 
objetos utilizando a Unified Modeling Language (UML). Será utilizada a 
ferramenta Enterprise Architect (EA) 7.5 para o desenvolvimento dos diagramas 
de casos de uso, de classes e de sequência; 
d) implementação da ferramenta: implementar a ferramenta especificada na etapa 
anterior. Será utilizada a linguagem C# com framework .Net no ambiente Visual 
Studio e banco de dados SQL Server; 
e) testes: realizar testes para determinar o correto funcionamento da ferramenta 
desenvolvida; 
f) validação: validar a ferramenta aplicando um caso real de uma fábrica de software 
em solicitações de mudanças de software. 
As etapas serão realizadas nos períodos relacionados no Quadro 1. 
 
 
 
5
 2012 
 fev. mar. abr. maio jun. 
etapas / quinzenas 1 2 1 2 1 2 1 2 1 2 
levantamento bibliográfico 
elicitação dos requisitos 
especificação da ferramenta 
implementação da ferramenta 
testes 
validação 
Quadro 1 - Cronograma 
 
 
 
6
2 REVISÃO BIBLIOGRÁFICA 
Este capítulo está organizado em cinco seções: a primeira aborda a norma ISO/IEC 
12207, a segunda e a terceira apresentam, respectivamente, gestão de mudanças e recursos 
humanos, a quarta aborda o algoritmo genético multiobjetivo NSGA-II e a última seção traz 
trabalhos correlatos à ferramenta proposta. 
2.1 NORMA 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.1.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 
processo pode ser adaptado facilmente para gerenciar, rastrear e controlar solicitações de 
mudança de software. 
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; 
 
 
 
7
c) problemas são analisados e avaliados para identificar solução(ões) aceitável(is); 
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. 
2.2 GESTÃO DE MUDANÇAS 
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 
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-seuma 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. 
 
 
 
8
2.3 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 pode-se 
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). 
2.4 ALGORITMO GENÉTICO MULTIOBJETIVO NSGA-II 
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. 
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 
 
 
 
9
adaptados têm maiores chances de serem transmitidas às gerações posteriores (RIBEIRO, 
2009, p. 21). 
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. 
A distância de povoamento é detalhada na figura 1, 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 1 - 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 2. 
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. 
 
 
 
 
10
 
Fonte: Spolaôr (2010, p. 25). 
Figura 2 - NSGA-II 
O laço interno iniciado na linha 11, ilustrado na Figura 2, 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.5 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). 
 
 
 
11
2.5.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 mostrou-se satisfatório para a ferramenta desenvolvida. 
Na Figura 3 é exibido 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 
contém os meses alocados (BASTOS, 2009, p. 54). 
 
 
Fonte: Bastos (2009, p. 54). 
Figura 3 - 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). 
2.5.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 
 
 
 
12
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 4 é mostrado o calendário 
de recursos, exibindo graficamente as alocações por data e informações de valores e 
quantidades de horas de cada recurso. 
 Fonte: QuickArrow (2010). 
Figura 4 - Tela do Resource Management com tabela de alocação de recursos 
 
 
 
 
 
 
 
 
 
13
3 REQUISITOS DO SISTEMA A SER DESENVOLVIDO 
A partir do estudo dos trabalhos correlatos, pode-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 competências (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); 
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). 
 
 
 
14
4 CONSIDERAÇÕES FINAIS 
Após o término da análise da problemática que envolve a alocação de recursos 
humanos aplicados a solicitação de mudança de software, verificou-se que os processos são 
feitos de forma manual pelo gerente de projetos ou líder de desenvolvimento. Nesta 
abordagem é gasto uma fatia de tempo desta pessoa em alocação das solicitações 
manualmente para os recursos. 
Assim, o desenvolvimento da referida ferramenta será voltado para a alocação 
dinâmica de solicitações de mudança de software, auxiliando o gerente de projeto ou líder de 
desenvolvimento para que tenha facilidade na alocação com eficiência e de forma precisa, 
pois será feita sob análise de habilidade e competência dos recursos. 
A respeito dos trabalhos correlatados mencionados pode-se afirmar que este trabalho 
utilizará de uma abordagem inspirada nos mesmos. No entanto, existem diferenciais em 
relação aos trabalhos relacionados. Bastos (2009) e QuickArrow (2010) limitam-se a alocação 
de recursos em um projeto de software, sendo que este trabalho implementará a abordagem de 
solicitação de mudança de software. 
 No que diz respeito a alocação de recursos humanos será utilizado um algoritmo 
genético multiobjetivo – NSGA-II – com complexidade maior de implementação. Outro 
diferencial será que a abordagem da ferramenta está voltada para o emprego da solicitação de 
mudança de software. 
A ferramenta será aderente ao processo resolução de problema da norma ISO/IEC 
12207. A alocação ocorrerá de forma automática e possibilitará uma visão semanal e/ou 
mensal dos recursos a qual a ferramenta está aplicada. 
Por fim, a ferramenta proposta diferencia-se dos trabalhos correlatos em função da 
ênfase em problemas de softwares, algoritmo de alocação e pela norma aplicada. 
 
 
 
15
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. 
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. 
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. 
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. 
 
 
 
16
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. 
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.