Ps-Graduao em Cincia da Computao

Definio de um mtodo que estabelece critrios

para priorizao de novos projetos e aplicao
em um processo de desenvolvimento de
software



AURENIA BARBOSA DE SANTANA DINIZ FERRAZ


DISSERTAO DE MESTRADO PROFISSIONAL




Universidade Federal de Pernambuco
posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao



RECIFE, DEZEMBRO/2013

UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMTICA
PS-GRADUAO EM CINCIA DA COMPUTAO



AURENIA BARBOSA DE SANTANA DINIZ FERRAZ


Definio de um mtodo que estabelece critrios para priorizao de
novos projetos e aplicao em um processo de desenvolvimento de
software





Este trabalho foi apresentado Ps-Graduao em
Cincia da Computao do Centro de Informtica da
Universidade Federal de Pernambuco como
requisito parcial para obteno do grau de Mestre
Profissional em Cincia da Computao.



Orientador: Prof. Vincius Cardoso Garcia, PhD




RECIFE, DEZEMBRO/2013
Dissertao de Mestrado Profissional apresentada por Aurenia Barbosa de
Santana Diniz Ferraz Ps-Graduao em Cincia da Computao do Centro
de Informtica da Universidade Federal de Pernambuco, sob o ttulo,
Definio de um mtodo que estabelece critrios para priorizao de
novos projetos e aplicao em um processo de desenvolvimento de
software, orientada pelo Professor Vincius Cardoso Garcia e aprovada pela
Banca Examinadora formada pelos professores:


_______________________________________________
Prof. Hermano Perrelli de Moura
Centro de Informtica / UFPE


______________________________________________
Prof. Maria da Conceio Moraes Batista
Universidade Federal Rural de Pernambuco


_______________________________________________
Prof. Vincius Cardoso Garcia
Centro de Informtica / UFPE



Visto e permitida a impresso.
Recife, 10 de dezembro de 2013.

___________________________________________________
Prof. EDNA NATIVIDADE DA SILVA BARROS
Coordenadora da Ps-Graduao em Cincia da Computao do
Centro de Informtica da Universidade Federal de Pernambuco.


























Aos meus pais, esposo e filha.




Agradecimentos
Agradeo a Deus pelas oportunidades que me tem dado e por ter
encaminhado toda a minha vida at aqui.
Ao meu esposo pelo companheirismo, estando sempre ao meu lado
dando foras e cuidando da nossa filha em minhas ausncias.
A minha filha que me traz muita alegria e fora para alcanar os meus
objetivos. Stella mame te ama muito.
Aos meus pais, sou muito grata pela criao e apoio que sempre tive.
Aos meus irmos e toda minha famlia pelos momentos de
descontrao.
Ao meu orientador, Professor Vincius por suas orientaes e
recomendaes, mesmo com sua agenda cheia de compromissos, sempre
encontrava um tempo para me receber e sua sala.
Lenita, Prof. Zeque, Prof. Hermano, Prof. Cea e a todos os colegas
do NTI e amigos que me ajudaram diretamente ou indiretamente para concluir
esse trabalho.




































Melhor terminar do que comear.
Eclesiastes 7:9
At aqui me ajudou o Senhor.
I Samuel 7:12


Resumo
Os projetos fazem parte do dia-a-dia das organizaes e bastante
comum o nmero de demandas ser superior capacidade da equipe
disponvel. Por isso, a importncia de ser ter processos definidos para ajudar
selecionar e priorizar aqueles projetos que so mais relevantes para a
instituio.
O presente trabalho apresenta uma proposta de soluo para ajudar no
gerenciamento das demandas recebidas pela organizao, desde a solicitao,
at a implantao no ambiente do cliente, com os seguintes objetivos:
(1) Construir um mtodo para definio de critrios para priorizao de
projetos. O mtodo deve indicar os projetos que podem trazer mais benefcios
para a organizao e menor custo para a equipe de desenvolvimento, baseado
em critrios definidos a partir de termos comuns utilizados no dia-a-dia da
organizao.
(2) Propor um processo de desenvolvimento de software baseado no
Framework Scrum, fazendo uso do mtodo de priorizao de projetos proposto.
A avaliao do mtodo de priorizao se deu comparando os resultados
obtidos com o do Mtodo TOPSIS (Technique for Order of Preference by
Similarity to Ideal Solution) e opinio de um especialista, revelando que pode
ser uma ferramenta til para o rgo, pois permite identificar previamente quais
os projetos traro mais benefcios para a organizao e consequentemente
devem ter mais prioridade no desenvolvimento, minimizando os riscos e
fracassos nos projetos e melhor otimizao da equipe de desenvolvimento.


Palavras-chave: Engenharia de software, Desenvolvimento gil de software,
Priorizao de projetos, Scrum.


Abstract
The projects are part of day-to-day of the organizations and it is quite
common that the number of demands exceeds the capacity of the team
available. For this reason, the importance of taking into account defined
processes to help select and prioritize those projects that are most relevant to
the institution.
The current work presents a proposal of solution to help manage the
demands received by the organization, from the request to the deployment in
the customer environment, with the following objectives:
(1) Elaborate a method to define criteria for prioritizing projects. The
method should indicate the projects that can bring more benefits to the
organization and lower cost for the development team, based on criteria from
common terms used daily in the organization.
(2) Propose a software development process based on Scrum
Framework, using the proposed method of prioritizing projects.
The evaluation of the prioritization method occurred comparing the
results obtained with the TOPSIS method (Technique for Order Preference by
Similarity to of Ideal Solution) and an expert opinion, revealing that can be a
useful tool for the institution, because it allows identify previously which projects
will bring more benefits to the organization, and therefore should have more
priority in the development phase, minimizing risks and failures in projects and
better optimization of the development team.

Key Workds: Software engineering, Agile software development, Prioritizing
projects, Scrum.





Lista de Imagens
Figura 1.1 Composio das equipes ............................................................. 14
Figura 1.2 Processo de solicitao e execuo de um novo projeto ............. 16
Figura 1.3 Processo de solicitao e atendimento de uma nova demanda
para manuteno de uma funcionalidade ........................................................ 17
Figura 2.1 Framework Scrum. Fonte: (Larman, et al., 2008) ......................... 25
Figura 2.2 Modelo de pontuao. Fonte (Cooper, et al., 2001) ..................... 40
Figura 3.1 - Entidades principais do Planejamento Estratgico Institucional.
Fonte: PEI-UFPE .............................................................................................. 47
Figura 3.2 - Tela principal da ferramenta. Fonte. Software Readmine ............. 49
Figura 3.3 - Tela com filtro da tela de consulta dos projetos. Fonte. Software
Redmine. .......................................................................................................... 51
Figura 3.4 - Quantidade de atividades por tipo de atividade ............................ 53
Figura 4.1 - Estrutura do ciclo de vida do processo ......................................... 60
Figura 4.2 - Funcionamento da Fase de Iniciao ........................................... 62
Figura 4.3 - Exemplo de uma instncia de execuo do processo .................. 64
Figura 4.4 - Fase de Construo para um projeto especfico ........................... 65
Figura 4.5 - Papel: Gestor ................................................................................ 67
Figura 4.6 - Papel: Scrum Master ..................................................................... 67
Figura 4.7 - Papel: Analista de Negcio ........................................................... 68
Figura 4.8 - Papel: Analista de Sistemas ......................................................... 68
Figura 4.9 - Papel: Desenvolvedor ................................................................... 69
Figura 4.10 - Papel: Analista de Teste ............................................................. 69
Figura 4.11 - Papel: Testador ........................................................................... 69
Figura 4.12 - Fases X Atividade X Papis X Artefatos ..................................... 78
Figura 4.13 - Passo-passo para aplicar mtodo de pontuao ........................ 79
Figura 4.14 - Estrutura de um critrio ............................................................... 81
Figura 5.1 - Ranking dos projetos .................................................................... 93
Figura 5.2 - Resultado do Passo 7 Classificao dos projetos pelo Modelo
TOPSIS ............................................................................................................ 99
Figura 5.3 - Comparao entre os mtodos ..................................................... 99



Lista de Tabelas
Tabela 3.1 - Eixos temticos do PAI 2013 X Entidades estratgicas X Objetivos
do PEI .............................................................................................................. 48
Tabela 3.2 - Lista dos projetos em execuo ................................................... 52
Tabela 3.3 - Mapeamento entre os projetos e a estratgia da organizao ..... 54
Tabela 3.4 - Resultado do Questionrio ........................................................... 56
Tabela 4.1 - Atividade Priorizar Projetos .......................................................... 70
Tabela 4.2 - Atividade Configurar Processo ..................................................... 71
Tabela 4.3 - Atividade Definir Viso ................................................................. 72
Tabela 4.4 - Atividade Modelar Processo ......................................................... 72
Tabela 4.5 - Atividade Detalhar Requisitos ...................................................... 73
Tabela 4.6 - Atividade Projetar sistema ............................................................ 73
Tabela 4.7 - Atividade Implementar soluo ................................................. 74
Tabela 4.8 - Atividade Implantar Sistema ......................................................... 74
Tabela 4.9 - Atividade Testar ........................................................................... 74
Tabela 4.10 - Atividade Testar ......................................................................... 75
Tabela 4.11 - Atividade Concluir projeto .......................................................... 75
Tabela 4.12 - Atividade Receber Solicitao .................................................... 76
Tabela 4.13 - Atividade Comunicar Resultados ............................................... 76
Tabela 4.14 - Atividade Acompanhar Atividades .............................................. 77
Tabela 4.15 - Termos lingusticos e Critrios previstos na literatura ................ 82
Tabela 4.16 - Escala de quantificao das alternativas ................................... 83
Tabela 4.17 - Variveis do critrio Alinhamento com Estratgia ...................... 84
Tabela 4.18 - Variveis do critrio Processos Internos .................................... 84
Tabela 4.19 - Variveis do critrio Resistncia dos Usurios........................... 85
Tabela 4.20 - Variveis do critrio Complexidade ............................................ 86
Tabela 4.21 - Variveis do critrio Dependncia dos Recursos ....................... 86
Tabela 5.1 - Resultado da avaliao dos projetos ............................................ 91
Tabela 5.2 - Tabela de projetos aps os pesos ................................................ 92
Tabela 5.3 - ndice de ganho dos projetos ....................................................... 92
Tabela 5.4 - Resultado da avaliao dos projetos ............................................ 95
Tabela 5.5 - Resultado do Passo 1 Normalizao dos dados ....................... 96
Tabela 5.6 - Resultado do Passo 2 Clculo dos pesos ................................. 96
Tabela 5.7 - Resultado do Passo 3 Aplicao dos pesos ............................. 97
Tabela 5.8 - Resultado do Passo 4 Soluo fuzzy ideal positiva e a soluo
fuzzy ideal negativa .......................................................................................... 97
Tabela 5.9 - Resultado do Passo 5 Clculo das distncias positivas e
negativas .......................................................................................................... 97
Tabela 5.10 - Resultado do Passo 6 Coeficiente de aproximao ................ 98



Sumrio
Agradecimentos ............................................................................................... 4
Resumo ............................................................................................................. 6
Abstract ............................................................................................................. 7
Lista de Imagens .............................................................................................. 8
Lista de Tabelas ............................................................................................... 9
Sumrio ........................................................................................................... 10
1. Introduo ................................................................................................ 12
1.1 Contexto .............................................................................................. 12
1.2 O Ncleo de Tecnologia da Informao (NTI) ..................................... 13
1.2.1 Organizao das equipes da rea de novos projetos ....................... 14
1.2.2 Solicitao de um novo projeto ......................................................... 15
1.2.3 Solicitao de manuteno de funcionalidade j em uso pelos clientes
................................................................................................................... 15
1.3 Tema e Objetivos ................................................................................ 18
1.4 Justificativa do Tema e dos Objetivos ................................................. 18
1.5 Estrutura do Documento ..................................................................... 19
1.6 Metodologia ......................................................................................... 20
2. Fundamentao Terica .......................................................................... 22
2.1 Mtodos geis .................................................................................... 22
2.1.1 Manifesto gil .................................................................................... 22
2.1.2 Scrum ............................................................................................... 24
2.1.3 Prticas geis ................................................................................... 27
2.1.4 Consideraes Finais ....................................................................... 34
2.2. Gerenciamento de Portflios .................................................................. 35
2.2.1 Conceitos .......................................................................................... 35
2.2.2 Mtodos Priorizao de Projetos ...................................................... 37
2.3 Consideraes Finais .............................................................................. 45
3. Coleta e Anlise dos Dados .................................................................... 46
3.1 Pesquisa qualitativa para identificar as metas estratgicas da
organizao .................................................................................................. 46
3.2 Pesquisa qualitativa para identificar os projetos em execuo e
desenvolvidos nos ltimos 24 meses ............................................................ 49
3.2.1 Resumo da Coleta 3.1.2 ................................................................... 55
3.3 Identificao dos pontos positivos e negativos dos projetos em execuo
e desenvolvidos nos ltimos 24 meses ......................................................... 56
3.4 Consideraes Finais .............................................................................. 57


4. Proposta do Processo ............................................................................. 59
4.1 Ciclo de Vida do Processo .................................................................. 60
4.2 Descrio do Processo ....................................................................... 66
4.2.1. Papis .............................................................................................. 66
4.2.2. Atividades e tarefas ......................................................................... 70
4.2.2. Artefatos .......................................................................................... 77
4.3. Mtodo que Estabelece Critrios para Priorizao de Projetos ............. 78
4.3.1 Selecionar Modelo ............................................................................ 79
4.3.2 Definir os critrios ............................................................................. 80
4.3.3 Calcular o Ganho dos Projetos ......................................................... 88
4.3.4 Aplicar os recursos ........................................................................... 90
4.3.5 Consideraes Gerais ...................................................................... 90
5. Aplicao do Mtodo ............................................................................... 91
5.1. Resultado pelo Mtodo Proposto ........................................................... 93
5.2. Validao pelo Modelo Fuzzy TOPSIS .................................................. 94
5.2.1. Comparao dos Resultados ........................................................... 99
6. Concluses e Trabalhos Futuros ......................................................... 100
6.1 Concluses ....................................................................................... 100
6.2 Limitaes ......................................................................................... 100
6.3 Trabalhos Futuros ............................................................................. 101
Referncias ................................................................................................... 102
Apndice I: Questionrio para avaliao dos projetos em andamento ... 105
Apndice II: Questionrio para definir pontuao das alternativas dos
critrios. ........................................................................................................ 106
Apndice III: Questionrio para definir os pesos dos critrios ................ 109
Apndice IV: Planilha para aplicao da pontuao dos projetos. ......... 110




12
1. Introduo
Neste captulo ser apresentado o contexto do trabalho, o problema que
o motivou, as questes de pesquisa, os objetivos, a metodologia de pesquisa
adotada e a organizao do trabalho.

1.1 Contexto
As organizaes esto mais dependentes de sistemas automatizados e
isso tem gerado um aumento na demanda de desenvolvimento de novos
produtos de software. Paralelo a isso, as organizaes enfrentam no seu
cotidiano restries de tempo, de recursos humanos, tecnolgicos e
financeiros. Esse cenrio exige que as empresas passem a se preocupar em
selecionar corretamente quais projetos devem ser desenvolvidos e quais tero
maior prioridade.
O processo de gerenciamento de portflio (PMIa, 2006), (Archer, et al.,
1999) surgiu para ajudar as organizaes nessa difcil deciso de quais
projetos devem ser desenvolvidos, quando eles devem ser parados,
cancelados ou acelerados. Tudo isso alinhado com os objetivos estratgicos da
organizao.
Para selecionar e priorizar os melhores projetos para a organizao,
vrios mtodos esto descritos na literatura (Dutra, 2012). Cada um deles tem
seus pontos positivos e negativos, alguns so complexos, outros exigem
muitas informaes de entrada (Dutra, 2012), inviabilizando o seu uso em
situaes reais.
Os mtodos de seleo e priorizao necessitam que sejam definidos
critrios comuns para avaliar os projetos. Esses critrios possibilitam
tratamento igualitrio para todas as demandas dos clientes, alm de tornar
transparentes e racionais as decises dos gestores (De Boer, et al., 2001). H
uma variedade de critrios listados na literatura (Hamilton, 2002), (Jolly, 2003),
(Martino, 1995), (Cooper, et al., 2001), (PMIa, 2006), (Vargas, 2010), (Dutra,


13
2012) e compartilhados pelos diversos mtodos de seleo e priorizao de
projetos.
Apesar dessa variedade de mtodos e critrios, no existem solues
prontas para ser utilizada por todas as empresas. A seleo do mtodo e dos
critrios deve ser feitos de acordo com o contexto e realidade de cada
organizao (Dutra, 2012).
Desta forma, este trabalho tem como objetivo construir um mtodo
simples que estabelece critrios relevantes para ser utilizado na priorizao
dos projetos. Alm de propor um processo de desenvolvimento de software
baseado no Framework Scrum que far uso desse mtodo para priorizar os
projetos que sero desenvolvidos em um rgo pblico.
A seguir ser descrito o ambiente utilizado como referncia para esse
trabalho.

1.2 O Ncleo de Tecnologia da Informao (NTI)
O Ncleo de Tecnologia da Informao (NTI) um rgo da
Universidade Federal de Pernambuco (UFPE), foi criado em 1967 com o
objetivo de fazer o gerenciamento dos ativos computacionais da universidade.
Da dcada de 60 at o final da dcada de 90, as aes do NTI eram
voltadas especialmente para a capacitao na rea da informtica e
disponibilizao de infraestrutura tecnolgica. A partir do ano de 2002, o rgo
ampliou a sua rea de atuao, passando tambm a desenvolver software,
com o lanamento do Sistema de Informaes e Gesto Acadmica SIG@.
O SIG@ utilizado por cinco instituies de ensino superior de
Pernambuco e composto por nove mdulos: ensino (graduao e ps-
graduao), pesquisa, pessoal, processos administrativos, planejamento
institucional, gesto patrimonial, processo de eleio e gesto do restaurante
universitrio. Ele o principal produto de software desenvolvido pelo NTI.


14
O NTI possui um corpo tcnico formado por desenvolvedores e analistas
que tem a responsabilidade de realizar as melhorias e evolues no SIG@.
Atualmente, o rgo mantm duas equipes que atendem as demandas desse
sistema, uma responsvel por desenvolver novos projetos, outra equipe para
manter as funcionalidades j em uso pelos clientes.
Na prxima seo ser descrito, em linhas gerais, a forma de
composio das equipes, o funcionamento atual do setor referente ao processo
de novas solicitaes, tanto para a rea de manuteno, quanto para a rea de
novos projetos. Essas informaes tm como ms de referncia Agosto/2013.

1.2.1 Organizao das equipes da rea de novos projetos
A rea de desenvolvimento composta por pequenas equipes que so
responsveis por um ou mais projetos. Cada equipe possui um lder que tem as
atribuies de guiar o trabalho da equipe e negociar os prazos e as entregas do
projeto, tudo isso com a coordenao do gerente da rea de novos projetos.
Na Figura 1.1 uma representao da composio das equipes.

Figura 1.1 Composio das equipes



15
A seguir ser detalhado o procedimento, comum, utilizado para solicitar
um novo projeto e a manuteno de uma funcionalidade j em uso no
ambiente.

1.2.2 Solicitao de um novo projeto
A solicitao de um novo projeto feita diretamente Diretoria do NTI
ou Gerncia da rea de Projetos, em seguida, a gerncia define o lder do
projeto, que a partir desse ponto, responsvel por definir o ciclo de vida do
projeto, podendo usar uma abordagem gil ou sequencial, pois no h um
processo padro no setor. Aps cada entrega do projeto o cliente pode fazer
novas solicitaes, mesmo fora do escopo inicial do projeto, ficando a cargo do
responsvel pelo projeto negociar o prazo das prximas entregas, de acordo
com a disponibilidade de sua equipe. Na Figura 1.2 uma viso geral do
processo de solicitao de um novo projeto at a sua entrega.

1.2.3 Solicitao de manuteno de funcionalidade j em uso pelos clientes
As tarefas executadas pela equipe de manuteno de funcionalidades j
implantadas so solicitadas pelos prprios clientes e seguem o seguinte
procedimento:
PASSO 1: Os clientes acessam a ferramenta de gerenciamento
de projetos Redmine
1
, que utilizada pelo rgo para fazer o
controle e acompanhamento dos projetos do setor;
PASSO 2: O cliente abre uma nova tarefa para o sistema que
precisa de ajustes. Nesse chamado preciso conter as seguintes
informaes: tipo da solicitao, que pode ser uma nova funo,
correo de algum problema ou uma adaptao do sistema; um
ttulo e a descrio da solicitao.

1
Redmine, http://www.redmine.org ambiente open-source e colaborativo para gerenciamento
de projetos, customizado para as necessidades do NTI.


16

Figura 1.2 Processo de solicitao e execuo de um novo projeto

PASSO 3: Responsvel pelo projeto analisa a solicitao feita
pelo cliente, define quando ser atendido e qual componente da
equipe ir executar a tarefa;
PASSO 4: Quando a tarefa estiver concluda, o responsvel pelo
projeto faz a validao e envia para rea responsvel para
publicar a nova verso do SIG@.
A seguir, na Figura 1.3 uma viso geral de todo o processo, desde a
solicitao de uma nova demanda para manuteno de um sistema j em uso
pelo cliente, at a sua implantao.



17

Figura 1.3 Processo de solicitao e atendimento de uma nova demanda para manuteno de
uma funcionalidade

Conforme demonstrado na Figura 1.2 e Figura 1.4 no h uma definio
de quais critrios devem ser levados em considerao para avaliar uma nova
solicitao e qual a sua prioridade em relao s demais demandas do setor.
Cada lder de equipe realiza a priorizao e seleo das tarefas de acordo com
a convenincia e disponibilidade de sua equipe.



18
1.3 Tema e Objetivos
O tema desta pesquisa compreende as reas de Gesto de Portflio,
especificamente as fases de seleo e priorizao de projetos, e a de Gesto
de Projetos.
O objetivo geral deste trabalho construir um mtodo para definio de
critrios para priorizao de projetos. O mtodo deve indicar os projetos que
podem trazer mais benefcios para a organizao e menor custo para a equipe
de desenvolvimento, baseado nos critrios definidos a partir de termos comuns
utilizados no dia-a-dia da organizao. Alm disso, propor um processo de
desenvolvimento de software baseado no Framework Scrum, fazendo uso do
mtodo definido.
Para que seja possvel alcanar o objetivo geral deste trabalho, preciso
atingir 5 objetivos especficos:
1) Identificar e selecionar os termos comuns utilizados no dia-a-dia da
organizao e que podem ser utilizados como alternativas dos
critrios para priorizao dos projetos.
2) Construir um mtodo para definio de critrios para priorizao
dos projetos.
3) Propor um processo de desenvolvimento de software integrado com
o mtodo de definio de critrios de priorizao.
4) Aplicar o mtodo nos projetos em execuo no ambiente;
5) Validar o mtodo utilizando a tcnica fuzzy TOPSIS e a opinio do
especialista da rea.

1.4 Justificativa do Tema e dos Objetivos
Os projetos fazem parte do dia-a-dia das organizaes, pois (Ouellette,
et al., 2007) empresas sem projetos no sobrevivem. de grande importncia
a seleo correta dos projetos que devem ser desenvolvidos, pois em caso de
falhas, (Rotondaro, 2006) a imagem da equipe de projeto ser comprometida,
mesmo que a execuo do projeto seja realizada com eficincia.


19
Muitos modelos existem na literatura para gerenciar projetos e portflio.
No entanto, h poucas referncias no uso integrado dessas duas reas. Os
modelos existentes so especializados no Gerenciamento de Projetos, ou no
Gerenciamento de Portflios de Projetos, apesar de alguns (Archer, et al.,
1999) e (Correia, 2005) demonstrarem que existem interdependncia entre
esses dois tipos de gerenciamento, mesmo assim no se aprofundam nos dois
temas simultaneamente, alm de no incorporar as caractersticas dos
mtodos geis em seus modelos.
Em relao ao objetivo principal desta dissertao que propor um
mtodo para definir critrios para priorizao de projetos, integrado a um
processo de desenvolvimento, salientamos a necessidade deste tipo de
contribuio, principalmente para o ambiente profissional, pois pode
proporcionar uma opo simples e fcil de utilizar, indicando os projetos mais
prioritrios, com maior ganho para a organizao e menor custo para a equipe
de desenvolvimento do projeto, alm de ser integrado com o processo de
desenvolvimento de software, facilitando o gerenciamento das demandas
recebidas pelo rgo, desde a solicitao, at a implantao no ambiente do
cliente.

1.5 Estrutura do Documento
Alm desse captulo introdutrio, este trabalho contm mais cinco
captulos. No segundo captulo so descritos a fundamentao terica, no
terceiro, o processo de coleta de dados, a identificao dos critrios para
selecionar e priorizar projetos e uma anlise do ambiente estudado, no quarto
captulo ser detalhado a proposta do processo, no quinto, a proposta ser
aplicada e validada pelo especialista da rea e pelo mtodo fuzzy TOPSIS, o
captulo seis contm as concluses da pesquisa e os trabalhos futuros.



20
1.6 Metodologia
O estudo foi realizado na UFPE/NTI e foi desenvolvido seguindo as
seguintes etapas:
Etapa 1: Reviso bibliogrfica sobre os temas: modelos e mtodos de
gerenciamento de portflio de projetos; critrios de seleo e priorizao de
projetos e sobre as metodologias geis.
Etapa 2: Pesquisa qualitativa atravs da coleta de dados e anlise nos
documentos que trata sobre o planejamento estratgico da organizao
disponveis na pgina http://www.ufpe.br.
Etapa 3: Pesquisa qualitativa dos projetos desenvolvidos pelo NTI, rea
de novos projetos, nos ltimos 24 meses. A coleta dos dados foi realizada na
ferramenta www.chamadosnti.ufpe.br que utilizada pelas equipes para
registrar as atividades dos projetos desenvolvidos e teve como objetivo
identificar datas de incio e fim de cada projeto, abordagens de
desenvolvimento, quantidade de componentes que participaram do
desenvolvimento do projeto, periodicidade de releases e principais dificuldades
e sucessos dos projetos. Esses dados depois de extrados foram validados
pela gerncia da rea de novos projetos.
Etapa 4: identificao dos principais problemas e vantagens dos
projetos que esto sendo executados no ambiente, atravs do questionrio
respondido pela gerncia da rea de desenvolvimento (Anexo I).
Etapa 5: Identificao de critrios de seleo e priorizao de projetos,
tomando como base o resultado das Etapas 2 e 3.
Etapa 6: Definio da pontuao das alternativas dos critrios (Anexo II)
e dos pesos (Anexo III).
Etapa 6: Aplicao dos critrios e suas respectivas pontuaes nos
projetos em execuo (Anexo IV).


21
Etapa 7: Definio da proposta de um processo gil que inclui: um
mtodo para selecionar e priorizar os projetos e atividades de gerenciamento e
acompanhamento dos projetos.






22
2. Fundamentao Terica
Nesse captulo sero introduzidos os princpios gerais que serviram
como fundamentao terica para desenvolver a proposta explicitada no
Captulo 4 deste trabalho. Inicialmente ser dada uma viso geral sobre os
Princpios que regem os Mtodos geis, em seguida ser detalhado o
funcionamento do Framework Scrum, que o mtodo gil mais popular
atualmente, logo aps as prticas geis consideradas mais efetivas e utilizadas
por diversos mtodos geis; e finalmente, conceitos sobre Gerenciamento de
Portflio.

2.1 Mtodos geis
Esta seo descreve os princpios que so a base para o
desenvolvimento gil de software, os valores, o Framework Scrum e as prticas
geis mais utilizadas na engenharia dos projetos.
Inicialmente ser abordado o manifesto gil, em seguida, o framework
Scrum que serviu como base para definir o processo proposto neste trabalho e
por fim apresentado um mapeamento das prticas geis utilizadas pelos
mtodos geis, demonstrando quelas que so mais efetivas, de acordo com a
literatura.

2.1.1 Manifesto gil
Em 2001 uma equipe de 17 profissionais, referncias na rea de
desenvolvimento de software, e representantes de vrias abordagens geis se
reuniram em uma conferncia nos EUA e formalizaram o Manifesto gil (Agile
Alliance, 2001). Esse manifesto definiu quatro valores, apoiados por doze
princpios trazendo um grande impacto (Ambler, et al., 2012) na forma como os
profissionais de TI pensavam sobre desenvolvimento de software.



23
O Manifesto gil
Interao de indivduos mais do que processos e ferramentas.
Produto funcionando mais do que documentao extensa.
Colaborao com o cliente mais do que contratos.
Respostas s mudanas mais do que cumprimento de planos.

Para (Ambler, et al., 2012) cada um dos quatro valores, descritos acima,
esto em forma de declaraes no formato X sobre Y, eles afirmam que o
manifesto define as preferncias, no as alternativas, estimula o foco em
determinadas reas, mas no elimina as outras.
A seguir os princpios que sustentam o manifesto (Agile Alliance, 2001):
[1] A prioridade mais alta deve ser atender o cliente por meio de
entrega contnua de software com valor para o negcio.
[2] As mudanas nos requisitos, mesmo em fases avanadas do
desenvolvimento, devem ser aceitas.
[3] Realizar entregas de software funcionando de forma frequente.
[4] O pessoal de negcio e os desenvolvedores devem trabalhar juntos
diariamente durante todo o projeto.
[5] Projetos devem ser construdos em torno de pessoas motivadas. D
a eles o ambiente e o apoio que necessitam e confie que eles vo fazer
o trabalho.
[6] A conversa face a face o meio mais eficaz para transmitir
informaes.
[7] Software funcionando a principal medida de progresso.
[8] Processos geis promovem desenvolvimento sustentvel.
[9] O Foco na excelncia tcnica e no bom projeto aumenta a
agilidade;
[10] Simplicidade essencial.
[11] As melhores arquiteturas, requisitos e projetos surgem de equipes
auto organizadas.
[12] Em intervalos regulares, a equipe deve refletir em como se tornar
mais eficaz, depois, refina e ajusta o seu comportamento
adequadamente.


24

Vrios mtodos geis tm surgidos baseados no Manifesto gil, alguns
deles so: Scrum (Schwaber, 2004), XP (Beck, 2004), FDD (Palmer, et al.,
2002), entre outros, e utilizados pelas organizaes (VersionOne, 2013). Neste
trabalho, na Seo 2.1.2, ser descrito o Framework Scrum, pois o mtodo
gil mais popular, utilizado em 54% (VersionOne, 2013) das organizaes,
alm de ser mais voltado para o gerenciamento dos projetos. Em seguida, na
Seo 2.1.3 ser realizado um mapeamento das principais prticas geis
consideradas mais efetivas no desenvolvimento de projetos de software.

2.1.2 Scrum
O Scrum foi idealizado por Ken Schwaber e Jeff Sutherland em 1990 e
definido como um framework para desenvolver e manter produtos complexos.
Para (Schwaber, 2004) o Scrum no um processo para construir
produtos, mas um framework onde os utilizadores podem empregar vrios
processos e tcnicas de acordo com a necessidade do ambiente. Utiliza uma
abordagem emprica para gerenciar projetos, por considerar ser mais
apropriado para controlar processos complexos e imprevisveis, como o de
Desenvolvimento de Software (Schwaber, 2004). Por esse motivo, os requisitos
no so precocemente detalhados e o projeto planejado progressivamente,
medida que o trabalho vai evoluindo. Para melhorar a previsibilidade e controlar
os riscos, a construo do projeto feita de forma iterativa e em pequenos
incrementos, se fundamentando em trs pilares: transparncia, inspeo e
adaptao.
Transparncia todas as informaes relevantes que influenciam o
resultado do projeto precisam est visveis aos interessados e devem
refletir ao que de fato aconteceu, ou seja, devem ser verdadeiras.
Inspeo os artefatos e o progresso das atividades devem sempre
ser inspecionados para identificar desvios.
Adaptao se na inspeo for identificado que houve desvios, alm
do aceitvel, o artefato ou processo deve ser ajustado.


25
Todo trabalho realizado no Scrum funciona dentro de uma Sprint. Uma
Sprint um intervalo de tempo pr-definido, com objetivo claro e durao entre
uma semana a um ms. Todas as atividades que precisam ser construdas e o
incremento do software que dever ser entregue no final de cada Sprint so
definidas no incio do intervalo, ou seja, uma Sprint tem uma meta a ser
alcanada. O incio da Sprint precedido por uma Reunio de Planejamento
em que so definidas e estimadas as tarefas que sero realizadas no perodo.
Reunies dirias so realizadas com a equipe do projeto, durante toda a Sprint,
para alinhar o trabalho que est sendo feito. Reunies de reviso e
retrospectiva so realizadas no final de cada Sprint, para apresentar o que foi
realizado na Sprint, avaliar o progresso e identificar pontos de melhorias no
processo. Na Figura 2.1 temos uma demonstrao do funcionamento do
Scrum.

Figura 2.1 Framework Scrum. Fonte: (Larman, et al., 2008)

O Time Scrum formado pelo Product Owner, o Time de
Desenvolvimento e o Scrum Master.
Product Owner (Schwaber, 2004) o responsvel pelo gerenciamento
do Backlog do Produto e isso inclui: explicitar e tornar claro os itens de
Backlog do Produto, ordenar os itens de acordo com o valor que tem
para o negcio. Essas atividades podem ser delegadas para os demais
componentes do time, mas o responsvel continua sendo o Product
Owner.


26
Time de Desenvolvimento (Schwaber, 2004) tem a funo de entregar
os incrementos do projeto. O Scrum no reconhece ttulos,
independente do trabalho que o componente da equipe execute,
podendo haver especialistas em alguma rea ou atividade especfica,
porm no aceita que haja subequipes dedicados a domnios
especficos, como por exemplo, de teste ou anlise. O tamanho da
equipe recomendado pelo framework (Schwaber, 2004) entre trs a
nove componentes. A justificativa dos autores que uma equipe com
menos de trs componentes prejudica a produtividade e com mais de
nove pessoas requer muita coordenao.
O Scrum Master (Schwaber, 2004) tem as seguintes atribuies:
garantir que o Scrum seja entendido e aplicado; facilitar os eventos do
Scrum; treinar o time de desenvolvimento para ser auto-gerenciveis e
interdisciplinares; planejar implementaes do Scrum dentro da
organizao; ajudar o Product Owner no gerenciamento do backlog do
Produto, ajudar o Product Owner em explicitar a viso e os objetivos dos
itens de backlog; compreender e praticar a agilidade.

O Scrum determina quatro eventos obrigatrios (Schwaber, 2004) que
devem acontecer durante a Sprint: reunio de planejamento da sprint, reunio
diria, reunio de reviso da sprint e retrospectiva da sprint.
O Scrum determina dois artefatos: o backlog do Produto e o backlog da
Sprint. O backlog do Produto uma lista ordenada de todos os requisitos, que
sero necessrias para que o produto fique pronto, isso inclui tarefas de testes,
configuraes de servidores, aplicativos, etc. e representa o escopo do projeto.
No entanto, a varivel escopo flexvel, podendo sofrer alteraes durante o
projeto (Highsmith, et al., 2001), ou seja, itens desejados no incio do projeto
podem no ser desenvolvidos, pois podero no ser considerados mais
prioritrios durante o desenvolvimento do projeto. O backlog deve conter uma
descrio da atividade, a prioridade de desenvolvimento, a estimativa e o valor
de negcio de cada item (Schwaber, 2004). medida que o projeto for
evoluindo, o backlog do projeto poder sofrer modificaes, sendo de


27
responsabilidade do Product Owner a incluso e remoo de itens, a alterao
de prioridade, bem como o seu detalhamento.
Embora a manuteno do backlog do produto seja de responsabilidade
do Product Owner, a (Schwaber, 2004) estimativa de cada atividade definida
pelo time de desenvolvimento.
J o Backlog da Sprint o conjunto de itens extrados do backlog do
produto e representa o trabalho que a equipe de desenvolvimento se
comprometeu a construir na Sprint. Esses itens so detalhados e quebrados
em atividades menores, correspondendo a todas as atividades necessrias
para que o incremento do software seja entregue e esteja pronto. O (Schwaber,
2004) backlog da Sprint pode ser mudado durante o desenvolvimento da
Sprint, itens podem ser acrescentados ou removidos. de responsabilidade do
time de desenvolvimento a manuteno do Backlog da Sprint.
Nesta seo foi demonstrado o funcionamento geral do Framework
Scrum, esse mtodo ser utilizado como base para o processo proposto neste
trabalho, devendo guiar todo o ciclo de vida do processo, utilizando os
princpios de: planejamento de iteraes, iteraes curtas, ciclos de feedback e
objetivos claros a ser alcanados no final de cada ciclo.
Na seo seguinte ser descrito as prticas mais utilizadas e quelas
consideradas mais efetivas, de acordo com estudos j existentes na literatura.
As prticas geis listadas no so especficas de um mtodo, mas um
mapeamento das principais prticas previstas nas diversas metodologias
atualmente em uso: Scrum (Schwaber, 2004), XP (Beck, 2004), FDD (Palmer,
et al., 2002), entre outras.

2.1.3 Prticas geis
H uma grande diversidade de prticas geis sendo utilizadas. Na
pesquisa realizada por (Ambler, 2007) o autor identificou um total de 58
prticas que so usadas nas empresas. Mas elas no devem ser utilizadas de
maneira indiscriminada, pois conforme estudos (Schoepping, 2012), a


28
combinao de prticas, de diversos mtodos geis, no mesmo processo, no
garante que o processo continue gil.
Diante dessas afirmaes, importante identificar quais as prticas mais
utilizadas pelas organizaes, quais as mais efetivas e como elas podem ser
agrupadas nos processos de desenvolvimento de software de acordo com o
ambiente.
Na literatura, h duas pesquisas recentes realizadas pelos
pesquisadores (Parsons, et al., 2007) e (Abbas, et al., 2010). Esses estudos
tiveram como objetivo, examinar qual a melhor forma de se fazer uso das
prticas geis recomendadas pelos mtodos geis.
O estudo de (Parsons, et al., 2007) foi baseada em uma pesquisa online
com um total de 4.235 respostas. Os autores realizaram uma anlise estatstica
nos dados brutos da pesquisa e identificaram as seguintes informaes: mais
de 16% dos entrevistados utilizam mais de um mtodo gil; nem sempre h um
padro entre o mtodo utilizado pelas equipes e as suas respectivas prticas; a
adoo de pelo menos um mtodo gil melhora os resultados de qualidade,
satisfao e produtividade, sem aumento significativo de custos; a utilizao de
mais de um mtodo gil simultneo aumenta a eficcia da equipe, sendo
Scrum e XP a combinao mais vantajosa.
J o segundo estudo, (Abbas, et al., 2010) foi baseado em 781
respostas e teve como o objetivo, explorar como as 58 prticas identificadas na
pesquisa de (Ambler, 2007) podem ser agrupadas e qual a relao delas com o
sucesso dos projetos. O resultado foi a identificao de 15 fatores, cada um
associado a um conjunto de prticas.
A seguir, sero listados os 15 fatores e a distribuio das 58 prticas
com esses fatores.
1 FATOR Modelagem da Arquitetura: incluem as prticas de
modelagem gil inicial da arquitetura, modelagem inicial dos requisitos, design
evolucionrio e definio da arquitetura j nas fases iniciais do projeto.


29
2 FATOR Prticas tradicionais de anlise: inclui a utilizao de
ferramentas case de modelagens, especificao detalhada da arquitetura,
especificao detalhada dos requisitos, planejamento detalhado do projeto
atravs de grficos de Gantt
2
detalhados e de alto-nvel.
3 FATOR Prticas de governana corporativa: incluem grficos de
burn down, jogo do planejamento, reunies dirias em p, backlog da iterao,
medio da velocidade da equipe, relatrios de status, relatrio de tendncias
de defeitos.
4 FATOR Prticas de banco de dados: integrao contnua de base
de dados, testes de banco de dados, refatorao da base de dados,
convenes de nomes.
5 FATOR Comunicao dentro da equipe (prticas de quadro branco):
esboos em quadro branco, modelagem em quadro branco.
6 FATOR Garantia da qualidade gil: integrao contnua de cdigo,
desenvolvimento guiado por testes, refatorao de cdigo, desenvolvimento de
testes, arquitetura flexvel, design evolucionrio, design simples, cdigo
coletivo.
7 FATOR Comunicao com equipe: modelagem em papel,
programao em pares.
8 FATOR Inspeo e anlise do cdigo: anlise esttica do cdigo e
inspeo do cdigo.
9 FATOR Testes leves e reviso: testes de aceitao, modelos de
reviso de documentos, testes exploratrios.
10 FATOR Arquitetura e configurao: especificao simples da
arquitetura, gerenciamento de configurao e arquitetura detalhada da
arquitetura.
11 FATOR Garantia da qualidade tradicional: planejamento de teste,
relatrios de erros, relatrios de status.

2
http://www.ganttchart.com/History.html



30
12 FATOR Padres de prtica codificao: padres de cdigo e
convenes de nomenclaturas.
13 FATOR Requisitos leves: especificaes leves de requisitos, casos
de usos leves.
14 FATOR Desenvolvimento iterativo e incremental: entrega
incremental, releases curtos, desenvolvimento incremental, ritmo sustentvel,
participao ativa dos interessados, software funcionando a cada iterao.
15 FATOR Comunicao com os clientes: toda equipe junta,
participao ativa dos interessados.
Para os autores, (Abbas, et al., 2010), esse agrupamento de prticas
muito til, pois pode servir como uma lista de verificao caso a organizao
queira se focar em um aspecto do processo de desenvolvimento de software.
Alm do agrupamento das prticas em fatores, o trabalho (Abbas, et al.,
2010) calculou, atravs de tcnicas estatsticas, a correlao entre essas
prticas, chegando aos seguintes resultados:
A taxa de sucesso dos projetos tem uma relao positiva com os
seguintes fatores:
6 FATOR: Garantia de qualidade gil.
14 FATOR: Desenvolvimento iterativo e incremental
A taxa de sucesso dos projetos tem uma relao negativa com os
seguintes fatores:
2 FATOR: Prticas tradicionais de anlise.
5 FATOR: Comunicao dentro da equipe (prticas de quadro branco)
12 FATOR: Padres de codificao
Prticas de governana corporativa (3 FATOR) tm uma relao
positiva com os seguintes fatores:
1 FATOR: Modelagem da arquitetura.


31
6 FATOR: Garantia de qualidade gil.
14 FATOR: Desenvolvimento iterativo e incremental
7 FATOR: A comunicao com a equipe
Prticas de governana corporativa (3 FATOR) tm uma relao
negativa com os seguintes fatores:
11 FATOR: Garantia de qualidade tradicional
15 FATOR: Comunicao com os clientes
Garantia de qualidade gil (6 FATOR) tem uma relao positiva com os
seguintes outros fatores:
1 FATOR: Modelagem da arquitetura.
14 FATOR: Desenvolvimento iterativo e incremental
7 FATOR: A comunicao com a equipe
Garantia de qualidade gil (6 FATOR) tem uma relao negativa com
os seguintes outros fatores:
15 FATOR: Comunicao com os clientes
5 FATOR: Comunicao dentro da equipe (prticas de quadro branco)
14 FATOR: Desenvolvimento iterativo e incremental tem uma relao
positiva com o 1 FATOR - Modelagem de arquitetura.
14 FATOR: Desenvolvimento iterativo e incremental tem uma relao
negativa com o 15 FATOR - Comunicao com os clientes
15 FATOR: Comunicao com os clientes tem uma relao positiva
com o fator 5 FATOR - comunicao dentro da equipe (prticas de quadro
branco).
A partir da anlise estatstica dos dados, os autores (Abbas, et al., 2010)
fizeram as seguintes recomendaes:


32
A fim de melhorar a taxa de sucesso dos projetos, a equipe pode usar os
fatores correlacionados positivamente e suas prticas associadas. Estes
fatores so: 6 FATOR: as prticas de garantia de qualidade geis, que est
associado com a integrao contnua de cdigo, desenvolvimento orientado a
testes, refatorao de cdigo, testes de desenvolvimento, arquitetura flexvel,
design evolucionrio, design simples e propriedade coletiva do cdigo e o 14
FATOR: Desenvolvimento iterativo e incremental, que est relacionado com
entrega incremental, pequenos lanamentos de cdigos, desenvolvimento
iterativo, o ritmo sustentvel e a participao ativa das partes interessadas.
A equipe pode considerar evitar fatores que esto correlacionados
negativamente com sucesso, incluindo o 2 FATOR - Prticas tradicionais de
anlise que se refere a prticas de anlise tradicional, como Diagramas de
Gantt
3
, ferramentas de modelagem, especificao de arquitetura detalhada e
especificao de requisitos detalhadas. Alm disso, com o 5 FATOR
Comunicao dentro da equipe (prticas de quadro branco) que incluemo
esboos do quadro branco e esboo de modelagem em quadro branco. O
ltimo fator que est negativamente correlacionada com o sucesso do projeto
o 12 FATOR (padres de codificao).
Com base neste estudo, os fatores Prticas geis de garantia de
qualidade e Desenvolvimento iterativo e incremental so prticas consideradas
como obrigatrias na proposta do processo, na fase de construo, descrita
neste trabalho, por ter uma relao positiva com o sucesso dos projetos.
O 6 FATOR - Garantia de Qualidade gil composto pelas seguintes
prticas:
Integrao contnua do cdigo - uma prtica originada do XP (Beck,
2004). Os membros da equipe integram seu trabalho frequentemente, pelo
menos uma vez ao dia, em cada integrao, um build automatizado verifica se
os testes passaram ou se houve algum problema de integrao. Com isso,
sempre existe uma verso funcional do projeto para ser demonstrado e
utilizado por toda equipe.

3
http://www.ganttchart.com/History.html



33
Teste driven development (TDD) - uma prtica originada do XP (Beck,
2004) e consiste em desenvolver o teste automatizado antes da funcionalidade.
Design simples - uma prtica originada do XP (Beck, 2004) e tem
como objetivo projetar a soluo mais simples possvel e que tenha a inteno
de resolver apenas os problemas atuais, complexidade e cdigo extras devem
ser evitados.
Propriedade coletiva do cdigo uma prtica originada do XP (Beck,
2004), com essa prtica, todo desenvolvedor da equipe tem a liberdade para
fazer qualquer alterao no cdigo, quando for necessrio, mesmo no sendo
o criador do cdigo. Isso permite a disseminao do conhecimento dentro da
equipe, alm de evitar possveis gargalos futuros.
Refatorao de cdigo uma prtica originada do XP (Beck, 2004).
Essa prtica tem como objetivo realizar melhorias no cdigo j existente,
tornando-o a cada nova alterao, mais legvel e mais fcil de ser utilizado,
sem alterar o seu funcionamento externo.
Testes de desenvolvimento uma prtica originada do XP (Beck,
2004). Toda funcionalidade precisa ter um cdigo automatizado.
Arquitetura flexvel est relacionado com a prtica de refatorao de
cdigo.
Design evolucionrio est relacionado com a prtica de refatorao de
cdigo.
O 14 FATOR - desenvolvimento iterativo e incremental composto
pelas seguintes prticas:
Ritmo sustentvel uma prtica originada do XP (Beck, 2004). Essa
prtica aconselha que a equipe no deva trabalhar alm de sua carga-horria
padro, pois para os idealizadores elas podem trazer benefcios em curto
prazo, mas em longo prazo a produtividade e a qualidade so prejudicadas.


34
Pequenos lanamentos prtica utilizada pelo Scrum (Schwaber, 2004)
e XP (Beck, 2004). Essa prtica recomenda pequenos lanamentos de forma
contnua e essas entregas devem ter valor de negcio para o cliente.
Desenvolvimento iterativo no Scrum (Schwaber, 2004) cada Sprint
uma iterao.
Entrega incremental no Scrum (Schwaber, 2004) a cada fim de Sprint
deve ter uma entrega que tenha valor de negcio para o cliente.
Participao ativa das partes interessadas Prtica recomendada pelo
Scrum (Schwaber, 2004) e XP (Beck, 2004).
Software executvel em cada incremento no Scrum (Schwaber, 2004)
recomendado que a cada fim de Sprint uma parte do software seja entregue.

2.1.4 Consideraes Finais
Os mtodos geis tm se tornado o padro para desenvolvimento de
software. Conforme estudos recentes (VersionOne, 2013), 84% das
organizaes utilizam algum mtodo gil em seus projetos, sendo o Scrum o
mais popular, representando 54% das respostas. As prticas geis,
principalmente as relacionadas qualidade gil de projetos e o
desenvolvimento iterativo e incremental tem sido considerado como fatores
positivos para o sucesso dos projetos.
Diante disso, o processo proposto neste trabalho utilizar o Scrum tanto
para gerenciar o processo como todo, desde a solicitao do cliente at sua
implantao, como individualmente, em cada um dos projetos. As prticas
geis de garantia de qualidade e desenvolvimento iterativo e incremental
tambm sero utilizadas na execuo de cada projeto de desenvolvimento de
software.
Na prxima seo ser apresentado o gerenciamento do portflio,
concedendo a base para o mtodo de seleo e priorizao de projetos
utilizados na proposta desta dissertao.


35
2.2. Gerenciamento de Portflios
Na seo anterior, foi tratado sobre os mtodos geis utilizados no
gerenciamento de projetos e as principais prticas geis consideradas
essenciais em um processo gil de desenvolvimento, nesta seo, ser
discutido, sobre o gerenciamento de portflio, especialmente sobre as
atividades de Seleo e Priorizao de Projetos.
Inicialmente ser descrito alguns conceitos essenciais para o
entendimento desta seo.

2.2.1 Conceitos
H vrias conceituaes na literatura sobre projetos. Para (Archer, et al.,
1999) um projeto um esforo complexo, formado por diversas atividades
inter-relacionadas e que foram planejadas, com um objetivo especfico e um
oramento definido. O (PMIb, 2008) considera projeto, um esforo temporrio
com a finalidade de criar um produto ou resultado exclusivo.
As organizaes, em geral, possuem um conjunto de projetos sendo
executados simultaneamente, alguns podem est relacionados com outros
projetos, ou serem executados independentemente. Portflio de projetos a
denominao dada pela literatura a essa coleo de projetos. O (PMIb, 2008)
considera um portflio de projetos como a composio de projetos, de
programas, ou trabalhos relacionados, que esto agrupados e gerenciados de
forma coordenada com a finalidade de atingir os objetivos estratgicos da
organizao.
Visando a gesto correta do portflio de projetos da organizao, foi
criado o conceito de gerenciamento de portflio, que segundo o (PMIa, 2006)
a administrao centralizada de um ou mais portflios e envolve a identificao,
priorizao, autorizao, gerncia e controle dos projetos, programas e
trabalhos relacionados com o objetivo de alcanar os objetivos estratgicos do
negcio. Para (Cooper, et al., 2002) gerenciamento de portflio um processo
de deciso em constante modificao, pois a lista de projetos a qualquer


36
momento pode ser atualizada e avaliada, acarretando incluso de novos
projetos, ou projetos em execuo serem adiantados, ou paralisados.
Vrias abordagens tm surgido para descrever o processo de
gerenciamento de portflio: (Cooper, et al., 2002), (PMIa, 2006), (Archer, et al.,
1999), (Rosenau, 2000), (Correia, 2005), entre outras.
O (PMIa, 2006) descrito na literatura como processo padro para
gerenciamento de portflio de projetos. Para que a organizao possa adot-lo
necessrio ter o seu planejamento estratgico definido, pois ele servir como
entrada para definio do portflio. Um ponto positivo identificado no padro
PMI quanto previso de reavaliar o portflio em um perodo de tempo pr-
definido pela organizao, mas como ponto negativo considerar o processo
de gerenciamento de projetos independente do processo de portflio de
projetos.
Outro processo considerado como referncia nesta rea o proposto
por (Archer, et al., 1999). Esse processo tem como objetivo integrar todas as
etapas do gerenciamento de portflio em um nico processo, pois conforme o
autor h muitas tcnicas existentes para auxiliar o processo de gerenciamento
de portflio, mas no existe um processo integrado para a sua execuo. O
processo estruturado em vrias fases, e cada uma delas com objetivos
especficos. Um dos cuidados do autor na formulao do processo foi constru-
lo de forma flexvel, como consequncia disso, o usurio pode selecionar
qualquer tcnica em cada fase do processo, ou at mesmo modificar ou
desconsiderar uma fase, dependendo da escolha e contexto do usurio.
Um dos pontos positivos do framework proposto por (Archer, et al.,
1999) que ele demonstra os prximos passos depois da etapa ps-seleo
dos projetos do portflio, que a fase de execuo dos projetos selecionados
do portflio, servindo como entrada para a nova seleo de projetos do
portflio. Um ponto negativo desse modelo quanto a sua natureza sequencial,
os projetos selecionados so executados e s aps o seu encerramento, os
projetos desenvolvidos so avaliados e um novo ciclo de seleo de projetos
do portflio iniciado.


37
Em todos os modelos analisados de gerenciamento de portflios os
processos de seleo e priorizao esto presentes. O processo de Seleo
tem como objetivo reduzir o nmero de projetos que sero considerados para
priorizao. Nesta fase pode ocorrer anlise da capacidade de recursos
humanos, anlise da capacidade financeira ou considerar a opinio
especializada para validar os projetos que devero passar pelo processo de
priorizao. J o processo de Priorizao tem como objetivo ajudar a
organizao escolher os projetos que tero a mais alta prioridade no
desenvolvimento. As propostas de projetos sero comparadas com os critrios
e pesos pr-definidos. O resultado final deste processo uma lista contendo a
prioridade de todos os projetos.
Na prxima seo sero analisados os principais mtodos descritos na
literatura, utilizados na Priorizao de Projetos.

2.2.2 Mtodos Priorizao de Projetos
Os mtodos utilizados para priorizar projetos so tcnicas importantes,
pois ajudam as organizaes nas situaes de incertezas (Wang, 2010), alm
de tornar transparentes e racionais as decises dos gestores (De Boer, et al.,
2001).
Em um recente estudo realizado por (Dutra, 2012), o pesquisador
identificou 20 mtodos distintos para priorizar os projetos. Esses mtodos
foram distribudos nas categorias qualitativos, quantitativos e hbridos.
Apesar dessa variedade, no h um consenso entre os pesquisadores
quais mtodos devem ser utilizados, pois cada um deles tem seus pontos
fortes e fracos. O trabalho de (Cooper, et al., 2001) identificou que os mtodos
mais utilizados pelas empresas so os mtodos de origem financeira,
representando 77% do total de pesquisados. Nesse mesmo estudo o autor
constatou que o mtodo financeiro apresentou os piores resultados, produzindo
um portflio desequilibrado e de menor valor para a organizao, por esse
motivo, o autor recomenda a sua utilizao em conjunto com outros mtodos a
fim de aumentar a sua eficincia. J os mtodos de pontuao, estratgico e


38
de bolhas, segundo o autor (Cooper, et al., 2001), conseguem produzir um
portflio estrategicamente mais alinhado com as prioridades do negcio. Foi
observado tambm no estudo, que as empresas, de modo geral fazem a
combinao de mais de um mtodo para gerenciar o seu portflio.
No trabalho de (Dutra, 2012), o autor identificou que o Mtodo de
Pontuao o mais utilizado dentre os mtodos qualitativos. No grupo dos
mtodos hbridos os mais utilizados so Processo de Anlise de Rede (ANP) e
Processo Analtico Hierrquico (AHP), j o mtodo quantitativo mais utilizado
foi a Programao Inteira.
No trabalho de (Dutra, 2012) foi listado seis mtodos qualitativos:
Pontuao, Balanced Scorecard (BSC), Grfico de Bolhas, Mtodo Delphi,
Desdobramento da Funo Qulaidade (QFD) e Roadmap tecnolgico. Os dois
ltimos mtodos citados so recomendados para projetos de pesquisa e
desenvolvimento tecnolgico (P&D); o mtodo BSC requer muitos dados de
entrada; o Grfico de Bolhas, apesar de simples, pode levar os avaliadores a
ignorar variveis importantes, j que exibe os dados em apenas duas
dimenses; o Mtodo Delphi realiza as avaliaes baseados em informaes
subjetivas; o Mtodo de Pontuao considerado fcil, sendo utilizado na
priorizao de projetos com mltiplos critrios, um ponto fraco desse mtodo
em relao atribuio de pesos dos critrios, em algumas situaes pode ser
difcil de avaliar. Apesar disso, os autores (Archer, et al., 1999) sugeriram a
escolha do mtodo de pontuao quando se tem muitos projetos.
Os mtodos quantitativos descritos por (Dutra, 2012) so: Programao
inteira, Lgica Fuzzy, Mtodos Probabilsticos, Programao Linear, Mtodos
Econmicos e Financeiros e Mtodos de Teoria da Utilidade so considerados
complexos, alguns necessitam de software especfico para sua utilizao.
J os mtodos hbridos identificados na reviso sistemtica da literatura
de (Dutra, 2012) so: Processo de Anlise de Rede (ANP) que considerado
simples e intuitivo, mas tem como ponto fraco a atribuio subjetiva dos pesos;
Processo Analtico Hierrquico (AHP) realiza diversas comparaes, que
dependendo da quantidade de projetos pode impossibilitar o seu uso; Mtodo
Multicriterial Promethee um dos pontos fracos que trata apenas informaes


39
quantitativas, apesar de ser considerado o mtodo multicritrio mais intuitivo; O
mtodo rvore de Deciso considerado confuso e demorado; j os mtodos
baseados em Redes Neurais tm como pontos fracos, necessitar de software
especfico, alm de em algumas situaes fazer concluses equivocadas,
necessitando de um especialista para avaliar os resultados.
A seguir sero detalhados os mtodos de Pontuao e TOPSIS. Esses
mtodos foram selecionados por lidarem com caractersticas qualitativas, e
permitirem a utilizao de mltiplos critrios, sendo que cada um deles utiliza
uma abordagem diferente. O mtodo de pontuao utiliza uma avaliao
subjetiva para priorizar os projetos, j o segundo, permite tratar de forma
objetiva um problema de tomada de deciso.

2.2.2.1. Mtodos de Pontuao
O mtodo de pontuao foi idealizado por (Hall, et al., 1990) e consiste
na definio de um conjunto de critrios em que atribudo notas para ser
utilizado na avaliao dos projetos.
O mtodo de pontuao funciona da seguinte forma: (1) definir conjunto
de critrios; (2) indicar para cada critrio uma escala de valores, exemplo: 5
representa muito alto, 4 alto, 3 mdio, 2 baixo e 1 muito baixo; (3) avaliar os
projetos em cada um dos critrios definidos; (4) somar os pontos obtidos por
cada projeto; (5) selecionar os melhores avaliados e (6) aplicar os recursos
disponveis, at o limite disponvel.
No mtodo de pontuao possvel definir pesos aos critrios. Esses
pesos representam a importncia de um critrio em comparao com os
demais. Os pesos podem ser obtidos atravs da opinio dos especialistas,
utilizando o modelo AHP para gerar os pesos, ou qualquer outra tcnica.
Na figura 2.2 demonstrado um exemplo de utilizao do modelo de
pontuao, utilizando os critrios sugeridos por (Cooper, et al., 2001), na
amostra, foi includo a informao sobre a quantidade de pessoas necessrias
para executar cada projeto. Para todos os projetos foi calculada a mdia para
se chegar ao ndice de atratividade dos projetos, os recursos foram sendo


40
adicionados aos projetos mais bem classificados, at chegar ao ponto de no
haver mais disponibilidade de recursos. Os projetos sem recursos foram
colocados na fila de espera.

Figura 2.2 Modelo de pontuao. Fonte (Cooper, et al., 2001)

2.2.2.2. Mtodo TOPSIS
O mtodo TOPSIS (Technique for Order Performance by Similarity to
Ideal Solution) foi idealizado por (Hwang, et al., 1981) e tem como objetivo
avaliar o desempenho das alternativas por meio da sua proximidade com a
soluo ideal e do seu distanciamento com a pior soluo.
Na implementao clssica do TOPSIS (Hwang, et al., 1981) a avaliao
dos critrios e de suas respectivas alternativas feito atravs de valores
absolutos, ou seja, um critrio atende ou no a um critrio. Mas essa restrio
pode tornar o mtodo invivel em situaes em que preciso lidar com
incertezas, por exemplo, em casos em que um projeto pode atender apenas
em parte a um critrio.
Por esse motivo o mtodo TOPSIS foi expandido por (Chen, 2000) para
tratar incertezas por meio da integrao com a Teoria dos Conjuntos Fuzzy
(Zadeh, 1965).
A Teoria dos Conjuntos Fuzzy (Fuzzy Set Theory FST) foi idealizada
por (Zadeh, 1965), com o objetivo de dar tratamento matemtico para vrios
conceitos subjetivos que esto presentes no cotidiano das pessoas e
organizaes. Pois nem sempre possvel resolver uma questo com


41
respostas do tipo sim ou no, pode est presentes conceitos do tipo s
vezes, parcialmente, muito mais, muito menos, entre outros. Esses
conceitos so expressos atravs de Variveis Lingusticas Fuzzy.
As Variveis Lingusticas Fuzzy podem conter palavras ou sentenas
em linguagem natural ou artificial (Zadeh, 1965), qualificadas atravs de faixas
de valores. Por exemplo, o valor da varivel Complexidade da Soluo pode
ser medido com os termos lingusticos: baixa, mdia, alta ou muito alta,
por exemplo.
Os princpios do Mtodo Fuzzy TOPSIS definidos por (Chen, 2000) para
tomada de deciso so:
a) A alternativa escolhida deve est o mais prximo possvel da
melhor soluo e mais distante da pior situao.
b) A soluo ideal positiva formada pelos melhores valores obtidos
na avaliao de cada um dos critrios, j a soluo ideal negativa
formada pelos piores valores dos critrios.
c) O algoritmo original foi mantido, mas adaptado para atender
nmeros fuzzy.
Este mtodo traz diversas vantagens, pois permite tratar de forma
objetiva um problema de tomada de deciso, alm disso, consegue demonstrar
qual a melhor e a pior alternativa em um determinado cenrio.
A seguir sero descritos os passos necessrios para utilizar o mtodo:
Passo 1: Normalizar os dados, satisfazendo a equao 1.

(1)
Onde, j=1, ...n e indica o mximo valor de xi para cada critrio.




42
Passo 2: Calcular os pesos, satisfazendo a equao 2.
No clculo dos pesos de cada critrio o mtodo TOPSIS utiliza a tcnica
probabilstica baseado na entropia da informao, e traz como resultado a
importncia de cada critrio para o modelo.

(2)

Onde, dj = 1 ej e o ej a entropia do critrio, satisfazendo a equao 3.

(3)
Passo 3: Calcular os dados normalizados com os pesos

(4)

Passo 4: Identificar a soluo fuzzy ideal positiva e a soluo fuzzy ideal
negativa, satisfazendo a equao 5.

(5)
Onde, J1 e J2 indicam os benefcios e os custos, respectivamente.


43
Passo 5: Calcular as distncias euclidianas para cada projeto,
satisfazendo a equao 6 e 7.

(6)


(7)

Passo 6: Calcular o coeficiente de aproximao, satisfazendo a equao 8.

(8)

Passo 7: Classificar os projetos
O valor do coeficiente de aproximao definido entre 0 e 1. Quanto
mais prximo de 1, melhor o desempenho do projeto.
Os projetos devem ser ordenados em ordem decrescente do coeficiente
de aproximao.
A seguir sero descritos os critrios de avaliao mais comuns,
utilizados pelos mtodos de seleo e priorizao de projetos.






44
2.2.3 Critrios para avaliar os projetos individualmente
Os mtodos de seleo e priorizao citados na Seo 2.2.3, financeiro,
estratgicos, pontuao e de bolhas, utilizam critrios para avaliar cada projeto
individualmente.
H vrias publicaes sobre esse tema: (Hamilton, 2002), (Jolly, 2003),
(Martino, 1995), (Cooper, et al., 2001), (PMIa, 2006), (Vargas, 2010), (Dutra,
2012), neste trabalho, utilizamos as descritas por (Cooper, et al., 2001) e a do
(PMIa, 2006).
No trabalho de (Cooper, et al., 2001) os autores descrevem alguns
critrios comuns utilizados para avaliar os projetos, que so:
- Alinhamento estratgico: esse critrio tem como objetivo avaliar os
projetos quanto a sua ligao com a estratgia do negcio. Para os autores
(Cooper, et al., 2001) os projetos selecionados para participar do portflio
devem ser a materializao da estratgia da organizao.
- Vantagem competitiva: esse critrio avalia os benefcios exclusivos que
o projeto vai ofertar para os clientes e como as necessidades dos clientes
sero atendidas.
- Viabilidade Tcnica: tem como objetivo avaliar a complexidade para
desenvolver o projeto, o grau de incerteza tcnica envolvida, o grau de
aprendizado necessrio para executar o projeto.
- Financeiro: avalia a relao entre o risco envolvido e o retorno
esperado com o projeto, para isso so calculados valores como retorno sobre o
investimento, perodo de tempo para obter a rentabilidade esperada e custos
envolvidos.
O guia (PMIa, 2006) tambm sugeriu uma lista de critrios, diferente de
(Cooper, et al., 2001) ele definiu os seguintes agrupamentos de critrios. Para
a categoria de negcio, foram includos os critrios de alinhamento estratgico,
produtividade, melhoria de processos, impacto da no realizao; para o tipo
financeiro, os critrios de reduo de custos e crescimento da receita; para a
categoria de riscos, tecnolgico, de gerenciamento de projetos, risco de


45
implementao; j para a categoria de critrios tcnicos, foram includos
probabilidade de sucesso do projeto.
Alm desses critrios, (Vargas, 2010) identificou o critrio Resistncia
dos usurios, que tem como objetivo calcular o grau de resistncia dos
usurios ao projeto, para o autor esse critrio uma possvel interpretao
qualitativa para a varivel de custo. Em seu trabalho, (Martino, 1995) tambm
elencou o critrio recursos requeridos que representa os recursos necessrios
para executar o projeto.

2.3 Consideraes Finais
Nesta seo foram apresentados os fundamentos da gesto do portflio
e detalhados dois processo que realizam esse gerenciamento, o (PMIa, 2006)
e o (Archer, et al., 1999). O ponto positivo do (PMIa, 2006) que ele possui
uma etapa onde possvel avaliar se houve mudana na estratgia da
organizao, a fim de realizar uma nova priorizao. O ponto negativo que
considera o gerenciamento de projetos um processo independente, no faz
nenhuma meno sobre ele. O processo proposto por (Archer, et al., 1999) tem
como ponto positivo, possuir uma etapa explcita onde so executados os
projetos selecionados, podendo aps a sua concluso gerar novas demandas
que sero selecionadas e priorizadas, o ponto negativo desse processo para o
ambiente em estudo que essa avaliao dos projetos s ocorre aps a
concluso dos projetos.
Foram tambm descritos vrios critrios para avaliar os projetos
individualmente, os que possuem melhor compatibilidade com o ambiente so:
os critrios de alinhamento estratgico, melhoria de processos, complexidade,
recursos requeridos e resistncia dos usurios.




46
3. Coleta e Anlise dos Dados
Neste captulo ser demonstrado o resultado de trs pesquisas
qualitativas realizadas no ambiente em estudo. A primeira coleta foi efetuada
em dados constantes no site da UFPE, com o objetivo de identificar a
estratgia e tambm para entender como feita a distribuio do oramento da
organizao; a segunda, no sistema utilizado pela equipe de desenvolvimento
empregado para registrar o andamento dos projetos desenvolvidos pelo NTI,
com a finalidade de extrair informaes sobre os projetos desenvolvidos e em
desenvolvimento nos ltimos dois anos; por ltimo, foi preparado um
questionrio para ser respondido pelo Gerente de Desenvolvimento da rea
acerca dos projetos em desenvolvimento no setor.
Complementando as pesquisas qualitativas, o mtodo Observao
Participante foi utilizado, dado que a autora deste trabalho servidora da
UFPE-NTI h dois anos, na diviso de desenvolvimento de novos projetos,
tendo liderado, ao longo desse perodo, quatro projetos no setor. Essa
experincia serviu para complementar as anlises documentais, possibilitando
tambm uma melhor percepo das dificuldades do ambiente.
Nas sees 3.1.1, 3.1.2 e 3.1.3 sero descritos o processo de coleta das
pesquisas qualitativas.

3.1 Pesquisa qualitativa para identificar as metas estratgicas da
organizao
Esta pesquisa teve como objetivo identificar as metas estratgicas da
organizao e como a UFPE realiza a distribuio oramentria, para que a
partir dessa informao, sejam definidos critrios estratgicos para ser utilizado
na seleo e priorizao dos novos projetos da rea.
No ms de setembro/2013 foi realizada uma pesquisa qualitativa atravs
da coleta de dados e anlise nos documentos que tratam sobre o planejamento
estratgico da organizao. Esta pesquisa foi realizada na pgina


47
http://www.ufpe.br, utilizando o seguinte filtro: "PLANEJAMENTO
ESTRATGICO" OR "PLANO" SITE:ufpe.br/proplan/ filetype:pdf.
A pesquisa retornou 84 documentos, sendo descartados 82 itens do
resultado, por estarem desatualizados, duplicados ou por tratar de assuntos
no relacionados ao planejamento estratgico da UFPE.
Os documentos considerados teis para o objetivo deste trabalho foram:
a) Plano Estratgico Institucional (PEI) representa o planejamento
estratgico da UFPE, dos anos de 2003 at 2013. O PEI tem como
objetivo identificar a viso e a misso da UFPE, propor objetivos e
tpicos estratgicos alinhados com a sua misso.

Os objetivos estratgicos da UFPE esto explicitados no PEI atravs das
atividades principais, reas de cooperao e alicerces (Figura 3.1). As
Atividades principais so as atividades fins da instituio, ensino, pesquisa e
extenso. As reas de cooperao so as reas de atuao estratgicas e
prioritrias da organizao e as de Alicerces so as reas que apoiam s
atividades principais da instituio. A Figura 3.1 representa as entidades
principais do PEI.

Figura 3.1 - Entidades principais do Planejamento Estratgico Institucional. Fonte: PEI-UFPE





48
b) Plano de Ao Institucional (PAI) baseado no PEI e representa o
planejamento de curto prazo, preparado pelos gestores da UFPE. O
PAI organizado em eixos temticos, esses eixos representam um
conjunto de aes referentes a um mesmo assunto.

O PAI j vem sendo utilizado h mais de cinco anos, com envolvimento
de todos os gestores da UFPE. O processo de formulao desse plano j est
consolidado e acontece no transcorrer de todo o ano atravs de reunies de
planejamento, monitoramento e avaliaes.
Vale salientar que, apesar de vrias aes planejadas anualmente no
PAI, no se referirem diretamente ao desenvolvimento de novos projetos,
grande parte delas, para ser operacionalizadas depende do desenvolvimento
de novos projetos, ou implantao de sistemas j existentes, ou
disponibilizao de infraestrutura tecnolgica. Por esse motivo, a importncia
do PAI neste trabalho.
Atravs da descrio dos eixos temticos do PAI, foi realizado um
mapeamento entre esses eixos temticos e as entidades estratgicas do PEI e
os Objetivos Estratgicos, conforme Tabela 3.1.
Tabela 3.1 - Eixos temticos do PAI 2013 X Entidades estratgicas X Objetivos do PEI
Eixos temticos
Entidades
estratgicas
Objetivos Estratgicos
Formao acadmica Atividade principal Ensino
Pesquisa, inovao e extenso. Atividade principal Pesquisa
Pessoas e qualidade de vida Alicerces Gesto
Vida estudantil Atividade principal Ensino
Internacionalizao Cooperao Nacional e Internacional
Interiorizao Cooperao Interiorizao
Sade Alicerces Gesto
Informao e comunicao Alicerces Informao
Governana e fluxo de trabalho Alicerces Gesto
Infraestrutura e Segurana Alicerces Infraestrutura


49
Meio ambiente, acessibilidade e
sustentabilidade. Alicerces
Infraestrutura e
Informao
Operacional Alicerces
Especial Alicerces


3.2 Pesquisa qualitativa para identificar os projetos em execuo e
desenvolvidos nos ltimos 24 meses
Para analisar as informaes sobre os projetos, foi realizada no ms de
Agosto/2013 uma pesquisa qualitativa, na ferramenta de gerenciamento de
projetos Redmine
4
, que utilizada pelo rgo para fazer o controle e
acompanhamento dos projetos do setor. Esta ferramenta de acesso restrito
aos servidores do rgo e aos donos dos projetos.
Todas as atividades realizadas ou previstas em cada projeto so
registradas nesse software. Na Figura 3.2 a tela principal da ferramenta
utilizada para registrar as atividades dos projetos, para um usurio autenticado.

Figura 3.2 - Tela principal da ferramenta. Fonte. Software Readmine

4
Redmine, http://www.redmine.org ambiente open-source e colaborativo para gerenciamento
de projetos, customizado para as necessidades do NTI.


50
Quando uma funcionalidade precisa ser desenvolvida, a equipe define
um conjunto de tarefas que precisam ser realizadas e registra nessa
ferramenta. Da mesma forma, o cliente, dono do projeto, tambm pode
registrar alguma atividade para ser executada pela equipe do projeto. Esse
processo foi detalhado na Seo 1.2 - Figura 1.2 e Figura 1.3.
A seguir, ser detalhado o passo-passo seguido para consultar os
projetos desenvolvidos pela rea:
1. Os seguintes filtros foram utilizados para realizar a consulta:
Situao: Fechada;
Projeto: selecionamos a lista dos projetos desenvolvidos pela
rea de novos projetos.
Fechado: O perodo informado de Julho/2011 at Julho/2013.
Foi utilizado este perodo por ter havido mudanas no software
para gerenciar os projetos, e nos chamados mais antigos, em
sua grande maioria, no tem a indicao de data de incio das
atividades, pois na poca esse dado no era obrigatrio.
Exportamos os 1021 registros retornados pela consulta para o
formato CSV;
Importamos esses dados para o Oracle
5
11g para facilitar a
manipulao dos dados;
Foram realizadas as seguintes consultas: quantidade de
chamados por tipo; quantidade por ms e ano; quantidade por
projetos; e quantidade de componentes na equipe para
identificar o perfil dos projetos em andamento.

Na Figura 3.3 apresentado um recorte da tela do sistema de controle
de chamados, com o filtro utilizado para realizar a consulta.

5
http://www.oracle.com/technetwork/database/database-technologies/express-
edition/overview/index.html


51

Figura 3.3 - Tela com filtro da tela de consulta dos projetos. Fonte. Software Redmine.

A consulta retornou 12 projetos em desenvolvimento pela rea,
conforme Tabela 3.2. A seguir uma explicao sobre cada coluna da tabela:
(a) ID do projeto: identificador do projeto (esse nome fictcio, porque
os originais foram omitidos);
(b) Tamanho da equipe.
(c) Incio: data de incio do projeto
(d) Durao: tempo de durao do projeto. Como todos os projetos
continuam na rea de desenvolvimento de novos projetos, os que
esto com o estgio Em desenvolvimento foi considerado at a
data atual; j os cancelados, a durao corresponde at a data do
cancelamento.
(e) 1 release: a data de lanamento da 1 verso. Os projetos que
esto como ND, esto em produo, mas no h registro no
sistema da data do 1 lanamento; os que constam nenhum so
porque no houve nenhum lanamento.
(f) Estgio do projeto: indica se est em desenvolvimento, se foi
cancelado ou se j foi implantado.






52
Tabela 3.2 - Lista dos projetos em execuo
ID do
Projeto
Tamanho
da
Equipe
Incio
Durao
(meses)
1
release
Estgio do projeto
P1 01 Mar/10 45
ND Implantado (Melhorias
pontuais)
P2 02 Set/10 39
ND Implantado (Melhorias
pontuais)
P3 02 Out/12 14
Fev/13 Implantado (Melhorias
pontuais)
P4 02 Mar/13 09 Mai/13 Em desenvolvimento
P5 02 Dez/12 12 Out/13 Em desenvolvimento
P6 02 Fev/12 22 Jun/13 Em desenvolvimento
P7 01 Mar/10 45
ND Implantado (Melhorias
pontuais)
P8 02 Jan/10 47
ND Implantado (Melhorias
pontuais)
P9 02 Set/11 23 Nenhum Cancelado (Ago/2013)
P10 02 Mar/10 33 Nenhum Cancelado (Jan/2013)
P11 02 Out/11 26
Fev/12 Implantado (Melhorias
pontuais)
P12 02 Jun/12 18 Ago/12 Em desenvolvimento

Para melhor mapear o perfil do tipo de atividade executada pela rea, foi
gerada uma consulta com o percentual de cada atividade executada nos 12
projetos, demonstrado no Figura 3.4.



53

Figura 3.4 - Quantidade de atividades por tipo de atividade

As descries dos tipos de atividades citadas no Grfico 3.4 esto
informadas a seguir:
Adaptativa: atividade executada para que uma funcionalidade, j
implantada, se adeque a uma mudana no ambiente do cliente;
Correo de violaes: executada para atender a alguma
recomendao da equipe de qualidade;
Corretiva: corrigir problema identificado no ambiente de produo;
Estudo: refere-se com estudos relacionados a novas tecnologias.
Nova funo e novo mdulo: so atividades relacionadas com o
desenvolvimento de novas funcionalidades para o sistema.
Perfectiva: melhorias em funcionalidades j implantadas.
Preventiva: so tarefas executadas com o objetivo de prevenir
possveis problemas que podem ocorrer no ambiente do cliente.
Requisito funcional: so tarefas relacionadas com a
documentao do sistema.
Servio: so atividades relacionadas publicao do sistema no
ambiente de produo, solicitao de clientes no relacionadas com
desenvolvimento de software.
Servio BD: so atividades relacionadas criao da estrutura de
banco de dados e da manipulao dos dados.
0%
5%
10%
15%
20%
25%
30%


54
Foi realizada uma anlise nos chamados do tipo Requisito Funcional,
pois chamados desse tipo contm informaes relativos documentao do
sistema, para identificar a natureza de cada projeto e assim realizar um
mapeamento dos projetos com a estratgia da organizao. Essa informao
foi validada e complementada com a gerncia da rea de desenvolvimento. O
resultado consta na Tabela 3.3.

Tabela 3.3 - Mapeamento entre os projetos e a estratgia da organizao
ID do
Projeto
Categoria
estratgica
Objetivos
Estratgicos
Eixo
Temtico
Ao 2013
P1 Alicerces Gesto - No identificado
P2 Atividade Principal Ensino
Vida
estudantil
Ao: 04. - PROAES. 03:
Benefcios permanncia
estudantil para a concluso do
ensino superior
P3 Atividade Principal Ensino
Vida
estudantil
Ao: 04. - PROAES. 03:
Benefcios permanncia
estudantil para a concluso do
ensino superior
P4 Atividade Principal Ensino
Vida
estudantil
Ao: 04. PROAES. 03: Benefcios
permanncia estudantil para a
concluso do ensino superior
P5 Atividade Principal Ensino - No identificado
P6 Atividade Principal Pesquisa - No identificado
P7 Alicerces Gesto - No identificado
P8 Alicerces Gesto - No identificado
P9 Alicerces Gesto - No identificado
P10 Alicerces Gesto - No identificado
P11 Alicerces Gesto - No identificado
P12 Alicerces Gesto
Informao e
comunicao
Ao: 08. SEGIC. 07: Programa de
comunicao institucional da
UFPE





55
3.2.1 Resumo da Coleta 3.1.2
12 projetos em desenvolvimento;
Mdia do tempo de um projeto na diviso de novos projetos: 28
meses.
As equipes de desenvolvimento dos projetos so formadas, em
mdia, por dois componentes, sendo que alguns componentes
acumulam mais de um projeto, gerando com isso, uma mdia de 1,17
pessoas por projeto. A equipe possui 10 servidores com carga-
horria de 8 horas/dia, sendo que 8 deles so da UFPE e 2 da
UFRPE e 4 estagirios com carga-horria de 4h/dia.
42% dos projetos so destinados s atividades principais (ensino,
pesquisa e extenso) da organizao; 58% para a rea alicerce e
nenhum projeto para rea de cooperao. Todos os projetos tem
uma ligao com os objetivos do eixo temtico do PAI e para 50%
dos projetos, no foi identificada correspondncia.
Total de atividades existentes para os 12 projetos: 1021, sendo 18%
relacionadas ao desenvolvimento de novas funcionalidades; 21%
para melhorias nas funcionalidades j em uso; 28% para correo de
problemas; 5% com documentao; e 28% para outras atividades.
42% dos projetos iniciaram em 2010; 17% em 2011; 33% em 2012 e
8% em 2013.
Mdia de tempo para 1 release 6 meses. Foram considerados
apenas os projetos P3, P4, P5, P6, P11 e P12, para os demais
projetos no h o registro do 1 lanamento do produto.
83% dos projetos esto sendo utilizado pelos clientes, exceto dois P9
e P10 que foram cancelados e no houve lanamento de nenhuma
verso.

Conclui-se com esta coleta de dados que apesar da rea ser
responsvel pelo desenvolvimento de novos projetos, 83% dos projetos
desenvolvidos nos ltimos dois anos j esto implantados, mas existem
demandas pontuais a cada nova entrega, impedindo que o projeto seja


56
considerado concludo e encaminhado para a rea de manuteno de sistema,
os outros 17% foram cancelados no ano de 2013.
Outra informao importante que 42% dos projetos iniciaram em 2010;
17% em 2011; 33% em 2012 e 8% em 2013, isso indica que mais de 50% dos
projetos esto no setor de novos projetos h mais de dois anos.

3.3 Identificao dos pontos positivos e negativos dos projetos em
execuo e desenvolvidos nos ltimos 24 meses
Foi formulado um questionrio com duas perguntas: (1) pontos negativos
e (2) pontos positivos, para ser respondido pelo Gerente da rea de
Desenvolvimento de Novos Projetos para cada um dos 12 projetos em
execuo no ambiente, conforme modelo Anexo I.
O objetivo desse questionrio relacionar as respostas obtidas, com o
resultado da coleta 3.1.2, a fim de se extrair critrios para ser utilizado na
priorizao dos futuros projetos.
Na Tabela 3.4 resultado do questionrio do Anexo I, respondido e
validado pelo Gerente da rea de Desenvolvimento.
Tabela 3.4 - Resultado do Questionrio
Identificao
do Projeto
Principais problemas Principais Vantagens
P1 Novas demandas aps cada entrega. Automao de um processo manual
P2 Novas demandas aps cada entrega. Donos do projeto e principais envolvidos aprovam
o projeto; automao de um processo manual.
P3 Novas demandas aps cada entrega. Donos do projeto e principais envolvidos aprovam
o projeto; automao de um processo manual.
P4 Novas demandas aps cada entrega.
Servidores de Arquivos no
disponveis para desenvolver
algumas funcionalidades do projeto.
Precisou utilizar uma soluo de
contorno, mas com algumas
restries.
Donos do projeto e principais envolvidos aprovam
o projeto; automao de um processo manual.


57
P5 Novas demandas aps cada entrega.
Complexo
Donos do projeto e principais envolvidos aprovam
o projeto; melhoria em sistema j existente.
Processo j estabelecido.
P6 Novas demandas aps cada entrega.
Complexo
Donos do projeto e principais envolvidos aprovam
o projeto; Processo j estabelecido. Melhoria em
sistema j existente.

P7

Resistncia alta a mudanas.
Complexo

Processo j estabelecido. Melhoria em sistema j
existente.
P8 Novas demandas aps cada entrega;
principal responsvel pela rea no
aprova produto.
Automao de um processo manual.
P9 Resistncia alta a mudanas. Processo j estabelecido. Melhoria em sistema j
existente.
P10 Projeto sem cliente responsvel;
muito complexo.
Melhoria em sistema j existente.
P11 Dono do projeto e principais
envolvidos tm vises diferentes
sobre a utilidade do sistema. Dono
do projeto apoia a equipe, mas
usurios finais so bastante
resistentes.
Alta administrao apoia o projeto; automatizar
um processo manual; usurio chave, designado
para acompanhar o projeto, no tem poder de
deciso.
P12 No existe processo definido,
sistema servir para cumprir
legislao; por esse motivo houve
muita demora em implantar o
sistema. Dono do projeto apoia o
sistema.
Alta administrao apoia o projeto. Baixa
complexidade.

3.4 Consideraes Finais
Este captulo apresentou o resultado das coletas realizadas no ambiente
estudado. Com base no referencial terico, nos dados coletados e nas
observaes do pesquisador, possvel chegar seguinte concluso:
(1) No existe uma definio de quais critrios devero ser utilizados
para selecionar e priorizar os projetos. A deciso tomada
individualmente por cada lder de projeto, de acordo com a
disponibilidade da equipe.
(2) No h uma definio de tempo limite para cada projeto ser
desenvolvido ou reavaliado, isso impede que novos projetos sejam
desenvolvidos: Os projetos em sua maioria so desenvolvidos de


58
forma iterativa e incremental, e com escopo flexvel, a cada nova
entrega surge novas demandas e novos problemas e como esses
projetos no so avaliados em perodos pr-determinados, para
verificar se as novas demandas so as mais prioritrias para a
organizao eles se estendem por muito tempo, impedindo que as
novas solicitaes sejam atendidas. o que constatamos na tabela
3.2, apenas 8% dos projetos em desenvolvimento na rea de novos
projetos so de fato novos, os demais so de melhorias; tambm
constamos isso no Grfico 3.1, apenas 18% das atividades
realizadas nos ltimos dois anos so de novas funes.
(3) Muitos projetos em andamento simultaneamente: No estudo
realizado por (Cooper, et al., 2001) um dos efeitos causados pela
falta de um processo de gerenciamento de portflio ter muitos
projetos em andamento simultaneamente, com os recursos diludos
entre os projetos. A consequncia disso um aumento no tempo
de entrada dos projetos em produo. No framework Scrum
tambm h uma proposta quanto ao tamanho das equipes. O
recomendado pelo Scrum (Schwaber, 2004), ter no mnimo trs
componentes e no mximo nove em uma equipe, pois uma
quantidade menor do que esta ir gerar problemas na produtividade
da equipe.

Diante desses problemas, este trabalho prope um Processo de
Desenvolvimento de Software, que no seu ciclo de vida contenha fases
especficas para seleo, priorizao e gerenciamento dos projetos, com um
time-box pr-definido e como objetivos a ser alcanados a cada fim de ciclo.
Com o fim do tempo estabelecido, todos os projetos que esto sendo
desenvolvidos e os que esto na fila de espera sero avaliados e priorizados,
podendo ou no entrar no prximo ciclo do processo. Para priorizar os projetos
recomendado um mtodo que leve em considerao os ganhos e esforos
necessrios para desenvolver os projetos.




59
4. Proposta do Processo
Neste captulo ser proposto um processo inspirado no Scrum, projetado
para ambientes que precisam gerenciar mltiplos projetos simultaneamente. A
proposta pretende ser simples e capaz de gerenciar as demandas recebidas
pelo rgo, desde a sua solicitao, at a implantao no ambiente do cliente.
Aps anlise dos modelos descritos no Captulo 2 foi identificado que os
modelos existentes so especializados no Gerenciamento de Projetos, ou no
Gerenciamento de Portflios de Projetos, apesar de alguns (Archer, et al.,
1999) e (Correia, 2005) demonstrarem que existem interdependncia entre
esses dois tipos de gerenciamento, mesmo assim no se aprofundam nos dois
temas simultaneamente, alm de no incorporar caractersticas dos mtodos
geis em seus modelos. Por essa razo, a proposta tem como finalidade
unificar, em um nico processo, as principais atividades dos modelos de
gerenciamento de portflio e de gerenciamento de projetos, alm de incluir as
principais caractersticas do Framework Scrum.
O Processo ir herdar caractersticas de modelos j existentes e
descritos no Captulo 2, como segue:
Gerenciamento de portflio sero utilizados os processos de
avaliao, seleo e priorizao dos projetos (PMIa, 2006) e
(Archer, et al., 1999), citados na Seo 2.2.
Gerenciamento de projetos sero utilizados os princpios do
Scrum, para definir a estrutura geral do processo, definio de
time-box com marcos bem delimitado, objetivo conhecido desde
o incio do ciclo de vida e entregas frequentes. Ser incorporado
na estrutura do processo fases de pr-projeto e ps-projeto,
previstos inicialmente por (Archer, et al., 1999) e citados na
Seo 2.1.3 deste trabalho.
Prticas de Engenharia de Software para execuo dos projetos
as prticas sugeridas para desenvolver cada projeto no sero
especficas de um nico mtodo, mas baseadas nas prticas


60
mais efetivas utilizadas pelas metodologias geis como um todo.
Essas prticas foram citadas na Seo 2.1.4 deste trabalho.

4.1 Ciclo de Vida do Processo
O processo proposto composto por quatro fases com objetivos e
durao pr-definida, que so: Iniciao, Construo, Encerramento e
Controle. Em cada uma dessas fases sero executadas atividades originadas
dos modelos de Gerenciamento de Portflio, do Gerenciamento de Projetos e
Prticas de Engenharia de Software descritas no Captulo 2.
A Figura 4.1 uma representao do ciclo de vida do processo.

Figura 4.1 - Estrutura do ciclo de vida do processo

Um dos problemas identificados, no ambiente em estudo, foi em relao
dificuldade em controlar o escopo do projeto, bem como manter o prazo de
desenvolvimento do projeto que foi acordado inicialmente. Novas demandas
surgem a cada nova entrega e os prazos so redefinidos, fazendo com que os
projetos demorem muito tempo para chegar ao estgio de pronto, conforme
dados coletados, Tabela 3.2. Alm disso, as novas demandas no passam por
uma reavaliao formal por parte da gerncia, a definio das novas
solicitaes acordada entre a equipe do projeto e o cliente, no passando por
nenhuma avaliao de prioridade em relao s novas demandas que esto na


61
fila de espera, conforme exposto na Seo 1.2.2, Figura 1.2 e Figura 1.3. Com
isso, os componentes das equipes continuam alocados ao projeto, impedindo
que as demandas que esto na fila de espera sejam atendidas. Outro problema
percebido na Coleta de Dados, Captulo 3, que, cada responsvel por projeto
escolhe a abordagem de desenvolvimento que lhe mais conveniente:
sequencial ou iterativa, com isso, alguns projetos passam muito tempo na fase
de anlise, demorando muito tempo para iniciar a sua construo, e com isso,
oferecer algum retorno para o cliente mais rapidamente.
Para evitar esses trs problemas identificados no ambiente falhas no
controle de escopo, falhas no controle do cronograma do projeto e fase muito
grande de anlise ser utilizado os princpios do Framework Scrum, descrito
no Captulo 3, para definir a estrutura geral do processo.
O ciclo de vida do processo proposto pretende fornecer alta direo,
as equipes do projeto e aos demais envolvidos, maior agilidade, transparncia,
pois ir possibilitar que em momentos especficos, os projetos em
desenvolvimento e as novas demandas sejam reavaliados pela alta gerncia e
decises de continuar ou parar seja realizado. Isso ir evitar que os projetos
se estendam por muito tempo, liberando as equipes para participar de projetos
mais prioritrios para a organizao, alm de adicionar um senso de urgncia
tanto para as equipes, quanto para os clientes, porque ficar bem claro que em
perodos pr-determinados os projetos sero reavaliados e trabalhos no
concludos dentro do prazo, podero no ser includos no prximo ciclo do
processo, ficando na fila de espera de projetos para serem executados em
momento posterior.
A seguir ser detalhado cada uma das fases, seus objetivos e durao.
Fase de Iniciao o principal objetivo desta fase definir quais os
projetos sero executados em determinado perodo; reavaliar os projetos em
desenvolvimento (se eles devem ser continuados ou pausados); analisar os
projetos que esto na fila de espera; definir os projetos que sero
desenvolvidos na fase de construo e realizar uma breve anlise de cada
projeto pr-selecionado. Alm disso, nessa fase ser definido o tempo de


62
durao de cada fase, quantas Sprints, cada fase ser composta e qual a
durao em dias de cada Sprint.
A proposta sugere que a fase de Iniciao tenha durao de 1 ou 2
Sprints, com a finalidade de evitar que seja demandado muito tempo na fase
de anlise e estudo de viabilidade.
Sintetizando, o objetivo dessa fase definir o foco da rea de
desenvolvimento para os prximos meses.
A Figura 4.2 uma representao do funcionamento da Fase de
Iniciao.

Figura 4.2 - Funcionamento da Fase de Iniciao

A seguir ser detalhada cada uma das atividades participantes dessa
fase.
A Fase de Iniciao comea com a Atividade Priorizar Projetos. Nessa
atividade, as demandas recebidas e os projetos em andamento so analisados,
avaliados e definidos uma ordem de priorizao, seguindo a configurao do


63
Modelo de Pontuao descrito na Seo 4.2. Participam desta atividade os
Gestores do rgo. Com a definio dos projetos que precisam ser
executados, passa-se para a Atividade de Configurar Processo, que consiste
em: selecionar o Scrum Master de cada projeto priorizado, definir o nmero de
semanas de cada Sprint, e a quantidade de Sprints necessrias para a fase de
Iniciao.
Aps essas definies iniciada a 1 Sprint da Fase de Inicializao,
que composta por cada Scrum Master designado para os projetos
selecionados e pela Equipe de Negcios.
O objetivo da 1 Sprint da fase de inicializao executar a atividade
Definir Viso que consiste em realizar um estudo preliminar sobre os novos
projetos selecionados.
Ao final da Fase de Iniciao, as seguintes perguntas para cada projeto
selecionado, precisam est respondidas:
a) J existem solues prontas que tragam o resultado mais
rapidamente para o cliente?
b) vivel desenvolver o projeto internamente?
c) Quais os principais problemas que devem ser resolvidos pelo
projeto?
d) Qual o esforo necessrio?
e) Definio da deciso de continuar ou parar o projeto.
f) Deciso de desenvolver internamente ou externamente.

No final da Fase de Iniciao devem acontecer as reunies de Reviso
da Sprint e Retrospectiva, em que sero decididos em definitivo os projetos que
sero executados na Fase de Construo, formando com isso o Backlog do
Ciclo de Vida do Processo, bem como o nmero de Sprint das Fases de
Construo e Encerramento e a durao das Sprints.
Aqueles projetos que no precisam passar por estudo de viabilidade,
podem ter a fase de construo antecipada, como por exemplo: os projetos no
concludos no ciclo anterior do processo e repriorizados para o ciclo atual.


64
Fase Construo - Nesta fase sero construdos todos os projetos
priorizados na fase de Iniciao. Cada um dos projetos selecionados ter uma
fase de construo distinta. Internamente ser utilizado o ciclo de vida do
Scrum para gerenciar os trabalhos de cada um dos projetos. Esta fase ter
uma durao de n Sprints, definido na atividade Configurar Processo, da
Fase de Iniciao, e cada um dos projetos internamente ter uma durao
menor ou igual ao tempo da fase de construo.
A Figura 4.3 uma representao de uma instncia de execuo do
processo composto por 10 Sprint, cada Sprint com durao de 3 semanas e
com cinco projetos sendo executados simultaneamente.

Figura 4.3 - Exemplo de uma instncia de execuo do processo

Todos os projetos executados pelo rgo devero ser executados na
Fase de Construo, isso inclui: os projetos desenvolvidos internamente e as
solues de terceiros que precisam ser testadas e implantadas. As atividades
sugeridas no processo so genricas e podem ser adaptadas para as duas
situaes.
Cada projeto executado na fase de construo seguir o fluxo padro do
Scrum. A Figura 4.4 uma representao do funcionamento da Fase de
Construo para um projeto especfico.


65

Figura 4.4 - Fase de Construo para um projeto especfico

Fase Encerramento - Tem como objetivo formalizar a concluso dos
projetos que foram acordados para ser desenvolvidos na fase de construo.
Os trabalhos no concludos sero pausados e reavaliados na fase de
inicializao do prximo ciclo do processo, juntamente com os demais projetos
que esto na fila de espera. Para os projetos que foram concludos antes do
encerramento do ciclo, a equipe j estar alocada em outro projeto, essa fase
apenas para formalizar a concluso de todos os projetos definidos na fase de
iniciao, dando transparncia e feedback para a organizao, dos trabalhos
que foram desenvolvidos pelo setor.
Fase de Controle - Essa fase executada continuamente durante todo
o ciclo de vida do processo e tem como funo realizar o acompanhamento do
andamento dos projetos e manter as solicitaes dos clientes atualizadas.



66
4.2 Descrio do Processo
O processo composto por tarefas, papis, artefatos e fases. Papis
representa o conjunto de responsabilidades atribudas a um grupo de pessoas.
Artefatos so os produtos dos trabalhos gerados ou alterados pelos papis.
Tarefas so as aes realizadas pelos papis em uma ou mais fases, cada
fase acontece em uma ou mais Sprint.

4.2.1. Papis
Os papis tm como funo executar as tarefas definidas pelo processo
em uma ou mais fases do ciclo de vida. Esses papis j existem no ambiente e
foram adaptados para o modelo em questo.
Alguns papis podem no ser necessrios em todos os tipos de projetos
em execuo no ambiente. Outro ponto importante para ser citado que um
componente da equipe pode assumir mais de um papel simultaneamente,
dependendo do tamanho do projeto.
Os sete papis sugeridos pelo processo so:
Gestor
Scrum master
Analista de negcio
Analista de Sistema
Analista de Testes
Desenvolvedor
Testador

(1) Gestor
O papel Gestor (Figura 4.5) representa a alta direo do rgo (diretores
e gerentes de rea) e tem como principal funo definir as metas do rgo para
um determinado perodo.


67

Figura 4.5 - Papel: Gestor

(2) Scrum Master
O Scrum Master (Figura 4.6) est envolvido em todas as tarefas de um
projeto especfico, desde a sua concepo at o seu encerramento. Este papel
deve garantir que o Scrum seja entendido e aplicado; ser um facilitador nos
eventos do Scrum, manter o foco dos membros da equipe nos objetivos da
Sprint, obter a aprovao dos envolvidos nas decises do projeto, manter os
interessados informados sobre os resultados do projeto, planejar as Sprints.

Figura 4.6 - Papel: Scrum Master

(3) Analista de Negcio
O papel Analista de Negcio tem como principal funo, manter contato
direto com o cliente, servindo de interface entre a equipe tcnica do projeto e
os clientes. Tem a responsabilidade de identificar as (Figura 4.7) necessidades
dos clientes e do negcio, sugerir melhorias no processo atual, priorizar as
funcionalidades que precisam ser desenvolvidas, identificar as restries legais
e culturais; identificar as solues similares j existentes, realizar treinamentos,
entre outras atividades relacionadas.


68


Figura 4.7 - Papel: Analista de Negcio

(4) Analistas de Sistemas
O papel Analista de Sistema tem como principal funo, projetar,
documentar, implantar sistemas desenvolvidos internamente ou soluo de
terceiros e publicar novas verses do sistema (Figura 4.8).

Figura 4.8 - Papel: Analista de Sistemas

(5) Desenvolvedor
O papel Desenvolvedor tem como principal funo, codificar a soluo
(Figura 4.9) e os testes automatizados do sistema em desenvolvimento. Este
papel exige boa habilidade tcnica na linguagem/tecnologia que ser utilizada
para desenvolver o projeto.



69

Figura 4.9 - Papel: Desenvolvedor

(6) Analista de Teste
O papel do Analista de teste tem como principal funo planejar os
testes (Figura 4.10) do sistema em desenvolvimento.

Figura 4.10 - Papel: Analista de Teste

(7) Testador
O papel de Testador tem como principal funo (Figura 4.11) executar
os testes manuais do sistema em desenvolvimento.

Figura 4.11 - Papel: Testador




70
4.2.2. Atividades e tarefas
As atividades so compostas por um conjunto de tarefas, possuem
objetivos especficos, entradas e sadas pr-definidas e so realizadas por um
ou mais papis.
A seguir sero descritos as atividades e tarefas realizadas em cada fase
do processo.

Fase de Iniciao
Esta fase composta por trs atividades, priorizar projetos, planejar ciclo
de vida e definir viso dos projetos. Os papis de Gestor, Analista de Negcio e
Scrum Master esto envolvidos diretamente com essas atividades.
A atividade Priorizar Projetos (Tabela 4.1) utiliza o mtodo proposto na
Seo 4.3. O responsvel por essa atividade o papel Gestor. Essa atividade
recebe como entrada um conjunto de demandas e gera de sada uma lista de
projetos priorizados que devero ser desenvolvidos no ciclo de vida do
processo.
Tabela 4.1 - Atividade Priorizar Projetos
Priorizar Projetos
Descrio Tem como objetivo priorizar os projetos que devero ser
desenvolvidos durante o ciclo de vida do processo.
Entrada Lista de demandas
Papis Gestor
Tarefas Categorizar
Avaliar
Selecionar
Priorizar
Sada Lista dos projetos priorizados
Quando
acontece
Na Reunio de Planejamento da 1 Sprint da Fase de Iniciao.

A atividade Configurar Processo (Tabela 4.2) tem como objetivo definir
as diretrizes a ser seguidas durante a execuo do processo e envolve os


71
seguintes passos: definio da durao do ciclo do processo em meses (06
meses, por exemplo); durao das Sprints (1 a 3 semanas, por exemplo);
nmero de Sprints das fases de Construo e Encerramento; definir o Scrum
Master de cada projeto. Essa tarefa de responsabilidade do papel Gestor e
gera como sada o Backlog do processo, contendo a lista dos projetos que
devem ser desenvolvidos no perodo pr-definido.
Tabela 4.2 - Atividade Configurar Processo
Configurar Processo
Descrio Tem como objetivo definir as diretrizes a ser seguidas durante a
execuo do ciclo de vida do processo.
Entrada Lista dos projetos selecionados
Papis Gestor
Tarefas Definir durao das Sprints (1 a 4 semanas)
Definir o Scrum Master de cada projeto
Definir nmero de Sprints das fases de Construo e
Encerramento
Sada Backlog do processo com a lista dos projetos a serem desenvolvidos
no ciclo
Quando
acontece
Na Reunio de Planejamento da 1 Sprint da Fase de Iniciao.

A atividade Definir Viso (Tabela 4.3) tem como objetivo identificar
quais os principais problemas que devem ser resolvidos de cada projeto
priorizado, qual o esforo necessrio para desenvolver a soluo, a lista de
requisitos, se j existem solues prontas que tragam o resultado mais
rapidamente para o cliente e se vivel desenvolver o projeto internamente.
Essa tarefa de responsabilidade do papel Analista de Negcio e deve
ser executada para cada projeto priorizado. Ela recebe como entrada o projeto
que ser executado e gera como sada um documento de viso do projeto,
contendo as restries, a definio da forma de execuo do projeto, se pela
equipe interna ou externa e os principais requisitos a serem atendidos.





72
Tabela 4.3 - Atividade Definir Viso
Definir Viso
Descrio Tem como objetivo criar uma viso de cada projeto selecionado, lista
de requisitos, esforo necessrio, como ser executado (se
internamente ou por solues de terceiros).
Entrada Projeto selecionado
Papis Analista de Negcio
Tarefas Identificar o problema
Listar os requisitos
Identificar o esforo para solucionar o problema
Identificar solues existentes
Definir se vivel construir internamente ou escolher uma
soluo de terceiros
Sada Documento de viso do projeto
Quando
acontece
Durante a Fase de Iniciao, podendo ser executado em uma ou mais
Sprints.


Fase de Construo
Esta fase composta por sete atividades, modelar processo, detalhar
requisitos, projetar sistema, implementar a soluo, testar, implantar sistema e
acompanhar os resultados das Sprints. Os papis de Analista de Sistema,
Analista de Negcio, Scrum Master, Desenvolvedores e Testadores esto
envolvidos diretamente com essas atividades.
A atividade Modelar Processo (Tabela 4.4) tem como objetivo entender
o funcionamento atual do processo de negcio do cliente, identificar pontos de
melhorias e desenhar junto com o cliente o novo modelo de negcio para o
ambiente.
Tabela 4.4 - Atividade Modelar Processo
Modelar Processo
Descrio Tem como objetivo principal desenhar junto com o cliente o novo
modelo de negcio para o ambiente.
Entrada Projeto selecionado
Papis Analista de Negcio
Tarefas Entender processo atual


73
Identificar pontos de melhorias
Desenhar o novo modelo de negcio para o ambiente
Validar o novo modelo com o cliente
Sada Modelo do processo de negcio
Quando
acontece
Durante a Fase de Construo, medida que os projetos vo sendo
desenvolvidos.

A atividade Detalhar Requisitos (Tabela 4.5) tem como objetivo
identificar, detalhar, analisar e documentar os requisitos que sero
desenvolvidos.
Tabela 4.5 - Atividade Detalhar Requisitos
Detalhar Requisitos
Descrio Tem como objetivo identificar, analisar e documentar os requisitos
que sero desenvolvidos.
Entrada Projeto selecionado
Papis Analista de Sistema
Tarefas Identificar os requisitos.
Criar prottipos em papel.
Documentar.
Sada Documento de Requisitos
Quando
acontece
Durante a Fase de Construo, medida que os projetos vo sendo
desenvolvidos.

A atividade Projetar sistema (Tabela 4.6) tem como objetivo definir as
estruturas lgica e fsica do sistema em desenvolvimento.
Tabela 4.6 - Atividade Projetar sistema
Projetar sistema
Descrio Tem como objetivo definir a estrutura lgica e fsica da soluo.
Entrada Projeto selecionado
Papis Analista de Sistema
Tarefas Definir a estrutura lgica do sistema
Definir a estrutura de banco de dados para o sistema
Documentar.
Sada Documento de Arquitetura
Quando
acontece
Durante a Fase de Construo, medida que os projetos vo sendo
desenvolvidos.


74
A atividade Implementar soluo (Tabela 4.7) tem como objetivo
codificar o sistema proposto.
Tabela 4.7 - Atividade Implementar soluo
Implementar soluo
Descrio Tem como objetivo codificar o sistema proposto.
Entrada Projeto selecionado
Papis Desenvolvedor
Tarefas Codificar
Criar testes automatizados
Executar os testes automatizados
Sada Cdigo fonte
Quando
acontece
Durante a Fase de Construo, medida que os projetos vo sendo
desenvolvidos.

A atividade Implantar sistema (Tabela 4.8) tem como objetivo implantar
o sistema no ambiente do cliente.
Tabela 4.8 - Atividade Implantar Sistema
Implantar Sistema
Descrio Tem como objetivo implantar o sistema no ambiente do cliente.
Entrada Projeto selecionado
Papis Analistas de Sistema e de Negcio
Tarefas Treinar os usurios
Criar manuais de utilizao do sistema
Sada Manuais de utilizao do sistema.
Quando
acontece
No final das Sprints da Fase de Construo.

A atividade Testar (Tabela 4.9) tem como objetivo criar os scripts de
testes, os planos de teste e executar os testes manuais.
Tabela 4.9 - Atividade Testar
Testar
Descrio Tem como objetivo criar os scripts de testes e executar os testes
manuais.
Entrada Projeto selecionado
Papis Testador
Tarefas Criar script de teste


75
Executar os testes manuais
Sada Scripts de testes.
Quando
acontece
Durante a Fase de Construo, medida que os projetos vo sendo
desenvolvidos.

A atividade Planejar os testes (Tabela 4.10) tem como objetivo planejar
os testes.
Tabela 4.10 - Atividade Testar
Testar
Descrio Tem como objetivo criar planejar os testes.
Entrada Projeto selecionado
Papis Analista de testes
Tarefas Criar plano de teste
Sada Plano de testes
Quando
acontece
Durante a Fase de Construo, medida que os projetos vo sendo
desenvolvidos.


Fase de Encerramento
Esta fase composta por uma atividade, concluir projeto. Os papis de
Analista de Sistema e Scrum Master esto envolvidos diretamente nessa
atividade.
A atividade Concluir projeto (Tabela 4.11) tem como objetivo fazer o
encerramento formal do projeto e identificar demandas desejadas pelo cliente
no concludas no ciclo.
Tabela 4.11 - Atividade Concluir projeto
Concluir projeto
Descrio Tem como objetivo fazer o encerramento formal do projeto e
identificar demandas desejadas pelo cliente no concludas no ciclo.
Entrada Projeto selecionado
Papis Scrum Master
Tarefas Revisar documentao
Liberar a equipe do projeto
Identificar novas demandas desejadas pelo cliente


76
Sada Documentao do sistema atualizada e revisada
Quando
acontece
Na fase de encerramento.

Fase de Controle
Esta fase composta por quatro atividades, receber solicitao, avaliar
propostas, acompanhar os resultados e comunicar aos envolvidos. Os papis
de Analista de Negcio e Scrum Master esto envolvidos diretamente nessas
atividades.
A atividade Receber Solicitao (Tabela 4.12) tem como objetivo
registrar as solicitaes dos clientes e fazer uma avaliao inicial das propostas
de projetos recebidas e categoriz-los com os critrios estabelecidos na Seo
4.2 deste documento.
Tabela 4.12 - Atividade Receber Solicitao
Receber Solicitao
Descrio Tem como objetivo registrar e categorizar as solicitaes dos clientes.
Entrada Nova solicitao
Papis Analista de negcio
Tarefas Registrar
Avaliar
Categorizar
Sada Atualizar lista de espera dos projetos
Quando
acontece
A qualquer momento.

A atividade Comunicar resultados (Tabela 4.13) tem como objetivo
manter todos os envolvidos atualizados sobre as decises e status do projeto.
Tabela 4.13 - Atividade Comunicar Resultados
Comunicar resultados
Descrio Tem como objetivo manter todos os envolvidos atualizados sobre as
decises e status dos projetos.
Entrada Todo evento relevante no projeto
Papis Scrum Master
Tarefas Enviar status do projeto aos envolvidos
Sada Mensagem de notificao


77
Quando
acontece
Durante todo o processo ciclo do processo.

A atividade Acompanhar atividades (Tabela 4.14) tem como objetivo
acompanhar a execuo das atividades dos projetos.
Tabela 4.14 - Atividade Acompanhar Atividades
Acompanhar atividades
Descrio Tem como objetivo acompanhar a execuo das atividades dos
projetos.
Entrada -
Papis Scrum Master
Tarefas Dirigir as Reunies dirias, de Planejamento, de Reviso de
Sprint e de Retrospectivas.
Sada Documento de acompanhamento dos projetos atualizado.
Quando
acontece
Durante todo o processo.


4.2.2. Artefatos
Os artefatos sugeridos para o processo so gerados ou alterados pelos
papis durante o ciclo de vida do processo e so:
Backlog do processo: lista com todos os projetos que sero
desenvolvidos no ciclo de vida do processo.
Backlog de cada projeto: lista com as atividades de cada
projeto;
Backlog da Sprint: lista com as atividades que sero
executadas na Sprint.
Documento de Viso do Projeto: deve conter uma breve
descrio sobre o projeto, os problemas e necessidades que o
projeto pretende resolver, demais informaes consideradas
relevantes.
Documentao do projeto: cdigo fonte, scripts de teste,
manuais dos usurios, documento de requisitos, documentao
da arquitetura e outras informaes relevantes sobre o projeto.


78
Documento de acompanhamento dos projetos: documento
contendo o status atualizado de cada projeto e suas respectivas
mtricas.

Na Figura 4.12 esto sintetizados as atividades, os papis e os artefatos
gerados em cada fase do processo.

Figura 4.12 - Fases X Atividade X Papis X Artefatos

4.3. Mtodo que Estabelece Critrios para Priorizao de Projetos
Durante a coleta de dados descrita no Captulo 3, os seguintes
problemas foram identificados no ambiente: alta demanda de projetos, no
sendo possvel atender a todos simultaneamente, precisando que seja
realizada alguma priorizao; no existe no ambiente um processo que defina
os critrios mnimos para serem utilizadas para priorizao dos projetos. As
decises sobre quais funcionalidades devem ser desenvolvidas so tomadas,
individualmente, por cada responsvel de projeto, de acordo com a
disponibilidade e convenincia da sua equipe, Seo 1.2.2, Figura 1.2 e Figura
1.3.


79
A falta de uma priorizao de projetos centralizada no rgo pode gerar
falta de transparncia e tratamento diferenciado para o mesmo tipo de
solicitao, alm de subutilizao dos recursos disponveis do rgo, porque
mesmo que cada equipe esteja otimizada, o processo como um todo pode est
subotimizado (Poppendieck, et al., 2011).
A definio do mtodo foi realizada em quatro etapas: (1) selecionar o
modelo; (2) definir os critrios; (3) calcular ganho dos projetos e (4) aplicar os
recursos.
Na Figura 4.13 esto listadas as etapas necessrias para selecionar e
priorizar os projetos:

Figura 4.13 - Passo-passo para aplicar mtodo de pontuao

4.3.1 Selecionar Modelo
H vrios modelos descritos na literatura (Cooper, et al., 2002), (Dutra,
2012) para ser utilizados na priorizao de projetos. Todos tm seus pontos
fortes e fracos. Por isso, cada organizao precisa selecionar aquele que
melhor se ajusta s caractersticas do seu ambiente (Dutra, 2012).
Foi utilizado reviso sistemtica realizada por (Dutra, 2012) para
selecionar o modelo aplicado neste trabalho. O pesquisador localizou 20
mtodos distintos na literatura, classificados em quantitativos, qualitativos e


80
quali/quantitativos, alm de identificar os pontos fortes e fracos de cada um
deles.
A partir da anlise dos modelos existentes na literatura, foram definidas
as seguintes restries para seleo do modelo:
1) Precisa ser fcil de usar.
2) Facilidade de extenso, de acordo com as mudanas do
ambiente;
3) Ser qualitativo.

A 3 restrio, Ser Qualitativo, se justifica porque nem sempre os
custos envolvidos no desenvolvimento de um projeto so fceis de serem
contabilizados. Para alguns custos, o clculo feito diretamente, como: salrio
da equipe envolvida, equipamentos utilizados para desenvolvimento. No
entanto, outros custos no so to simples de mensurar financeiramente, e
mesmo sendo possvel, o esforo necessrio para obter os resultados, pode
no compensar, exemplos: calcular o custo de desenvolver um sistema com
alta resistncia dos usurios; medir as melhorias nos processos internos dos
clientes; medir quanto organizao teria ganhado se tivesse investido tempo
e esforo em projetos com menos resistncia, entre outras situaes. Alm
disso, no ambiente objeto deste estudo, no existe a cultura de medir
quantitativamente os custos e os benefcios proporcionados por um projeto.
Aps anlise dos modelos, o modelo de Pontuao foi selecionado, pois
atendeu as 3 restries pr-definidas, alm de ser o mais utilizado dos mtodos
qualitativos (Dutra, 2012).

4.3.2 Definir os critrios
Cada critrio ser composto de quatro alternativas, e cada uma delas
ter uma relao direta com termos utilizados pela organizao, possibilitando
que os projetos sejam avaliados objetivamente em relao a determinado
critrio.


81
Alm das quatro alternativas, um critrio composto por um nome, um
peso e uma categoria, conforme Figura 4.14.

Figura 4.14 - Estrutura de um critrio

Os critrios adotados para priorizao dos projetos foram utilizados por
j estarem previstos na literatura (Cooper, et al., 2001), (PMIa, 2006), (Vargas,
2010) e pela alta correspondncia com importantes termos utilizados no dia-a-
dia da organizao.
A definio dos critrios foi realizada em 5 passos: (1) identificar termos
com significado para a organizao; (2) definir forma de pontuao; (3) pontuar
os critrios; (4) categorizar os critrios; (5) definir pesos dos critrios.
Passo 1: Identificar termos com significado para a organizao.
Aps anlise dos dados coletados no Captulo 3, foram identificados que
vrios termos comuns utilizados no dia-a-dia da organizao,
coincidentemente, tm alguma ligao com critrios j previstos na literatura.
A partir dessa constatao, foi realizado um mapeamento dos termos
comuns utilizados no ambiente, com os critrios j previstos na literatura. O
objetivo desse mapeamento facilitar o trabalho dos avaliadores na atividade
de priorizao dos projetos e ao mesmo tempo minimizar a subjetividade na
pontuao de cada critrio.
A Tabela 4.15 contm os termos, mapeados como alternativas dos
critrios previstos na literatura.


82
Tabela 4.15 - Termos lingusticos e Critrios previstos na literatura
Critrios previstos
na literatura
acadmica
Termos / Alternativas Descrio
Alinhamento
Estratgico
Aes definidas no PAI Identificar os projetos que tem como
objetivo operacionalizar alguma ao
prevista no PAI. As aes do PAI
representam os objetivos de curto prazo
da organizao. Termo identificado na
Coleta descrita na Seo 3.1.1.

Atividades principais
da organizao
Identificar os projetos ligados
atividade principal da organizao
(Ensino, pesquisa e extenso). Termo
identificado na Coleta descrita na Seo
3.1.1.

Atividades de
Cooperao e
Alicerces
Identificar os projetos ligados s
atividades que apoiam a atividade
principal. Termo identificado na Coleta
descrita na Seo 3.1.1.
Projetos priorizados
pela alta direo
Identificar os projetos que receberam
uma pr-seleo. De acordo com
observao do pesquisador, alguns
projetos passam por uma avaliao
prvia da Alta Direo da instituio.

Processos
Automao de
processos manuais
Identificar os projetos que tem como
objetivo automatizar um processo
manual da organizao. Termo
identificado na Coleta descrita na Seo
3.1.3. Tabela 3.4
Melhorias em
sistemas j existentes
Identificar os projetos que tem como
objetivo realizar melhorias em projetos
j existentes. Termo identificado na
Coleta descrita na Seo 3.1.3. Tabela
3.4
Atender uma
legislao
Identificar os projetos que tem como
objetivo cumprir uma legislao. Termo
identificado na Coleta descrita na Seo
3.1.3. Tabela 3.4
Complexidade
Tcnica
Complexidade Identificar o grau de dificuldade do
projeto. Termo identificado na Coleta
descrita na Seo 3.1.3. Tabela 3.4
Dependncia de
Recursos
Dependncia de
Recursos
Identificar o grau de dependncia de
recursos. Termo identificado na Coleta


83
descrita na Seo 3.1.3. Tabela 3.4
Resistncia dos
usurios
Resistncia dos
usurios
Identificar possvel resistncia dos
usurios ao projeto. Termo identificado
na Coleta descrita na Seo 3.1.3.
Tabela 3.4

Passo 2: Definir forma de pontuao
No mtodo de pontuao, para cada critrio deve ser definida uma
escala de valores para realizar sua quantificao.
No modelo atual, foi definida uma escala, com valores de 1 a 4 para
quantificar um critrio, como mostrado na Tabela 4.16.
Tabela 4.16 - Escala de quantificao das alternativas
Quantificao Valor
Muito alto 4
Alto 3
Mdio 2
Baixo 1

Passo 3: Pontuar os critrios.
Cada alternativa dos critrios foi quantificada utilizando a padronizao
definida na Tabela 4.16. Essa atividade foi realizada pelo pesquisador
juntamente com o especialista da rea, atravs do questionrio constante no
Anexo II.
A seguir a lista com todos os critrios identificados, descrio dos
objetivos de cada um deles e suas respectivas alternativas.
C1 - Alinhamento com a estratgia esse critrio tem como
objetivo identificar o grau de alinhamento do projeto com os objetivos
da organizao. A seguir um detalhamento das variveis que fazem
parte do critrio Alinhamento com a Estratgia, o peso de cada uma
delas e a justificativa da escolha.






84
Tabela 4.17 - Variveis do critrio Alinhamento com Estratgia
Pontuao Avaliao Variveis Justificativa da
pontuao
4 Muito
Alto
Projetos priorizados pela alta
direo
So projetos que j
foram priorizados por um
comit formado pela alta
administrao da
instituio.
3 Alto Aes definidas no PAI So projetos que tem
como objetivo
operacionalizar uma ao
do planejamento anual
da instituio. Essas
aes so aprovadas pela
alta administrao da
instituio e j houve
alocao de recursos
financeiros para elas.
2 Mdio Atividades principais da
organizao
So projetos que tem
como objetivo atender as
atividades fins da
organizao (ensino,
pesquisa e extenso).
1 Baixo Atividades de Cooperao e
Alicerces
Vrias atividades
executadas nesse grupo
so comuns a todas as
organizaes. Exemplos:
controle de patrimnio,
financeiro, entre outras.

C2 - Processos internos esse critrio tem como objetivo identificar
as possveis melhorias nos processos internos que o projeto vai
proporcionar. A seguir um detalhamento das variveis que fazem
parte do critrio Processos Internos, o peso de cada uma delas e a
justificativa da escolha.

Tabela 4.18 - Variveis do critrio Processos Internos
Pontuao Avaliao Variveis Justificativa da
pontuao
4 Muito
Alto
Automao de processos
manuais
A automao de
processos manuais tende
a trazer diversos
benefcios para a


85
organizao, como:
diminuio de custos,
trabalhos padronizados,
melhorias na qualidade
do trabalho.
3 Alto Melhorias em sistemas j
existentes
Os projetos que se
enquadram nessa
categoria tm como
objetivo melhorar ou
adaptar sistemas j em
uso.
2 Mdio Atender uma legislao Enquadram-se nessa
categoria os projetos que
so executados para
atender uma legislao,
mas que ainda no tem
um processo definido na
organizao.
1 Baixo Outras melhorias Situaes no previstas.

C3 - Resistncia dos usurios: esse critrio tem como objetivo
quantificar o nvel de resistncia da comunidade em relao ao
projeto. A seguir um detalhamento das variveis que fazem parte do
critrio Resistncia dos Usurios, o peso de cada uma delas e a
justificativa da escolha.

Tabela 4.19 - Variveis do critrio Resistncia dos Usurios
Pontuao Avaliao/Variveis Justificativa da Pontuao
4 Muito Alto Projeto no tem dono ou cliente responsvel.
3 Alto Gestor, dono do processo, no aprova o
projeto.
2 Mdio Gestor aprova, mas usurios finais resistem ao
sistema.
1 Baixo Gestor e usurios finais aprovam o sistema,
tendo pouca ou nenhuma resistncia dos
envolvidos.

C4 - Complexidade: ir representar quo complexo ser para a
equipe desenvolver o projeto. A seguir um detalhamento das
variveis que fazem parte do critrio Complexidade, o peso de cada
uma delas e a justificativa da escolha.


86
Tabela 4.20 - Variveis do critrio Complexidade
Pontuao Avaliao/Variveis Justificativa da Pontuao
4 Muito Alto Representa uma complexidade muito alta ao
sistema. Exemplos: Utilizar novas tecnologias,
ainda no testadas em outros mdulos do
SIG@.
3 Alta Representa uma complexidade alta ao sistema.
Exemplo: Acessar dados externos ao SIG@ e
realizar integrao com dados j existentes no
SIG@; possuir regras de negcio complexas.
2 Mdio Representa uma complexidade mdia ao
sistema. Exemplo: Cadastrar, alterar, excluir,
consultar e listar, alm de realizar consultas e
relatrios com maior complexidade, como por
exemplo, que realize clculos, gere grficos,
agrupamentos.
1 Baixa Representa uma complexidade baixa ao
sistema. Exemplo, funcionalidades do tipo:
Cadastrar, alterar, excluir, consultar e listar.

C5 - Dependncia de Recursos: ser avaliado se necessrio
recursos tecnolgicos adicionais, como servidores especficos,
softwares especficos ou habilidades tcnicas especficas; se os
recursos esto disponveis, mas foi exigida alguma adequao; ou
todos os recursos necessrios esto disponveis. A seguir um
detalhamento das variveis que fazem parte do critrio Dependncia
de Recursos, o peso de cada uma delas e a justificativa da escolha.

Tabela 4.21 - Variveis do critrio Dependncia dos Recursos
Pontuao Avaliao/Variveis Justificativa da Pontuao
4 Muito Alto Recursos humanos ou tecnolgicos no
disponveis, impedindo o incio do projeto.
3 Alta Recursos necessrios no disponveis,
impedindo a implantao do sistema.
2 Mdio Recursos necessrios no disponveis. Pode ser
utilizada uma soluo de contorno, mas vai
trazer alguma restrio para o projeto.
1 Baixa Recursos disponveis.





87
Passo 4: Categorizar os critrios
Para atender os objetivos deste trabalho, Seo 1.3, os projetos
selecionados precisam atender a duas restries bsicas:
1) Precisa est alinhado com a estratgia da organizao.
2) Precisa ser vantajoso para o rgo, ou seja, ter menor custo de
desenvolvimento.

Por essa razo, os critrios sero agrupados em dois grandes grupos:
benefcios e custo.
Um critrio benefcio significa que quanto maior o seu valor, melhor o
projeto ser para a organizao. Enquanto o critrio custo, quanto maior seu
valor, mais dificuldades ou riscos do projeto so adicionados, ou seja, mais
custoso ser para a equipe desenvolver o projeto.
Em resumo, os critrios do tipo benefcios devem ser visto pela tica da
instituio, j os custos, pela perspectiva da equipe de desenvolvimento.
Desse modo, os critrios foram assim distribudos:
a) Benefcios: alinhamento estratgico e melhoria em processos;
b) Custos: resistncia, complexidade e dependncia de recursos.

Passo 5: Definir os pesos dos critrios
No Mtodo de Pontuao, um peso atribudo a um critrio para indicar
a sua importncia ou prioridade em relao aos demais.
O clculo dos pesos respeitou a seguinte definio:
wt = c1w + c2w + c3w + c4w + c5w = 1
Onde, wt representa a soma do peso(w) de todos os critrios, c1w
(critrio alinhamento estratgico), c2w (processos), c3w (resistncia); c4w
(complexidade) e c5w (recursos).


88
Foi definida uma proporcionalidade na definio dos pesos dos critrios.
Os critrios da categoria benefcios representam 50% do total dos pesos, e os
50% restante, os critrios custos.
A razo dessa proporo para atender aos objetivos deste trabalho,
Seo 1.4: os projetos selecionados precisam est alinhado com a estratgia
da organizao e ser vantajoso para a equipe do projeto, ou seja, ter menor
custo de desenvolvimento.
Seguindo essa recomendao, o especialista responsvel pela rea,
definiu os pesos dos critrios, conforme Questionrio do Anexo III, da seguinte
forma:
Benefcios
o Alinhamento estratgico: 30%
o Processos: 20%
Custos
o Resistncia dos usurios: 20%
o Complexidade: 10%
o Dependncia de recursos: 20%

Resultado da frmula:
wt = c1w + c2w + c3w + c4w + c5w
wt = 0,3 + 0,2 + 0,2 + 0,1 + 0,2

4.3.3 Calcular o Ganho dos Projetos
O rgo fornece servios para clientes internos da prpria organizao e
no remunerado diretamente pelo desenvolvimento desses projetos. Mas
isso no significa que no existam custos e isso precisa ser levado em
considerao no momento de selecionar as atividades mais vantajosas para a
equipe de desenvolvimento do projeto, semelhante ao que as empresas
(MacGibbon, et al., 2005) fazem diariamente a fim de se manter competitivas
no mercado.


89
Mas nem sempre os custos envolvidos, no desenvolvimento de um
projeto, so fceis de serem contabilizados. Para alguns tipos de custos, o
clculo feito diretamente, como: salrio da equipe envolvida, equipamentos
utilizados para desenvolvimento. Por outro lado, calcular o custo de
desenvolver um sistema com alta resistncia dos usurios; ou medir as
melhorias nos processos internos dos clientes; ou quanto organizao deixou
de ganhar, se tivesse investido tempo e esforo em projetos com maior
aceitao no ambiente. Essas questes no so to simples de mensurar
financeiramente, e mesmo sendo possvel, o esforo necessrio para obter os
resultados pode no compensar.
Por essas razes, ser realizado um clculo simples que indica o ndice
de ganho de cada projeto. Esse clculo baseado no total de pontos dos
Benefcios do projeto, comparado com o seu custo de desenvolvimento.
O ganho de cada projeto ser calculado usando a frmula:
iG = ganhos esforos ou

(( ) ( ) ( ))
(( ) ( ) ( ))

Onde,
iG igual ao somatrio dos ganhos dividido pelo somatrio dos
esforos.
g1: a pontuao do 1 critrio de ganho multiplicado pelo seu
peso;
g2: a pontuao do 2 critrio de ganho multiplicado pelo seu
peso;
gn: repetir o mesmo procedimento de g1 e g2, enquanto houver
critrios de ganhos.
e1: a pontuao do 1 critrio de esforo multiplicado pelo seu
peso;
e2: a pontuao do 1 critrio de esforo multiplicado pelo seu
peso;
en: repetir o mesmo procedimento de e1 e e2, enquanto houver
critrios de esforos.


90
4.3.4 Aplicar os recursos
Esse passo tem por objetivo alocar os recursos humanos disponveis
aos projetos.
Os projetos mais bem classificados tero prioridade na alocao dos
recursos. Os projetos sem equipe disponvel devem aguardar o novo ciclo de
priorizao.

4.3.5 Consideraes Gerais
O presente captulo apresentou a proposta de soluo para o problema
da dissertao, que consiste na definio de um mtodo para definir critrios
para priorizar projetos, embutido em um processo de desenvolvimento de
software.
Conforme exposto neste captulo, o processo baseado nos princpios
dos Mtodos geis, em especial o Scrum e composto pelos seguintes
elementos estruturais: Tarefas, Papis e Artefatos. O mtodo para definir a
ordem de prioridade dos projetos baseado em critrios categorizados em
benefcios e custos, contendo cada um deles um conjunto de variveis que
representam termos comuns que so utilizados no ambiente.



91
5. Aplicao do Mtodo
Nesta seo sero apresentados os resultados da aplicao do mtodo
para estabelecer os critrios para priorizao de projetos.
A aplicao foi realizada em 3 passos: (1) avaliar os projetos; (2) aplicar
os pesos dos critrios; (3) calcular o ganho dos projetos.

Passo 1: Avaliar os projetos
Os critrios foram aplicados aos projetos em andamento pelo
especialista responsvel pela rea, Anexo IV. O resultado apresentado na
Tabela 5.1.
Tabela 5.1 - Resultado da avaliao dos projetos


Passo 2: Aplicar os pesos dos critrios
Os pesos definidos na Seo 4.3.2 para cada critrio foram aplicados na
Tabela 5.1 gerando o resultado exibido na Tabela 5.2.
Os seguintes pesos foram utilizados:
Alinhamento estratgico 0,3;
Processos 0,2;
Resistncia dos usurios 0,2;
Complexidade 0,1 e


92
Dependncia de recursos 0,2

Tabela 5.2 - Tabela de projetos aps os pesos


Passo 3: Calcular o ganho do projeto
Foi calculado o ndice de ganho de cada projeto a partir do resultado da
Tabela 5.2 gerando o resultado exibido na Tabela 5.3.
Tabela 5.3 - ndice de ganho dos projetos

De acordo com o modelo, os projetos P3, P2, P4 e P12 so os mais
prioritrios. Enquanto, o P10, P8, P7 e P9 so os menos prioritrios. Na Figura
5.1 a demonstrao da classificao dos projetos aps a aplicao do mtodo.


93

Figura 5.1 - Ranking dos projetos

5.1. Resultado pelo Mtodo Proposto
O resultado foi avaliado pelo especialista da rea, demonstrando
compatibilidade com a realidade do ambiente. A seguir um resumo da
avaliao realizada pelo especialista:
Os trs projetos melhores avaliados so sistemas que
apresentam poucos problemas quanto a sua utilizao, alm de
ter uma boa parceria entre a equipe tcnica e o cliente.
O projeto P12, apesar de ser o quarto colocado, de est
alinhado com os objetivos da organizao, de ser apoiado pelo
dono do projeto, mesmo assim, apresentou problemas na
implantao. Essa resistncia, conforme o especialista
causado pelo objetivo do projeto ser atender uma legislao e a
atividade que se prope a fazer no ser anteriormente
executada no ambiente. Com isso, no h papis bem
estabelecidos para executar a funo e h resistncia dos
usurios finais do sistema.
Dos quatro projetos que tiverem ndices mais baixos: os projetos
P9 e P10 foram cancelados, e o P7 e P8 esto passveis de
serem substitudos por uma soluo externa ao SIG@.


94
O P10 no tinha um dono do projeto, a tecnologia utilizada era
nova e pioneira no sistema. No havia clientes para validar o
sistema.
O projeto P7 e P9 tem uma resistncia por parte de alguns
envolvidos quanto mudana para o novo sistema, pois j
existe um sistema em funcionamento atual na rea.

Baseados nesse resultado, conclumos que projetos mais bem alinhados
com a estratgia da organizao e que trazem melhorias visveis para os
processos da organizao e com baixa resistncia devem ser priorizados pela
organizao.
O mtodo, apesar de simples, mostrou ser consistente, indicando os
melhores projetos e os mais problemticos executados no ambiente.

5.2. Validao pelo Modelo Fuzzy TOPSIS
Um dos pontos fracos do modelo de pontuao utilizado na proposta
desse trabalho quanto a subjetividades em relao a atribuio dos pesos
critrios selecionados, conforme explicitado na Seo 2.2.2, por esse motivo,
para validar os pesos atribudos para cada um dos critrios escolhidos no
modelo (Seo 4.3), foi utilizado o modelo matemtico Fuzzy TOPSIS, descrito
na Seo 2.2.3.2, pois permite tratar de forma objetiva um problema de tomada
de deciso, alm disso, consegue demonstrar qual a melhor e a pior alternativa
em um determinado cenrio.
Para isso foi realizado o seguinte procedimento:
1. Na planilha respondida pelo responsvel da rea de
desenvolvimento, Anexo IV, foram aplicados os critrios de
priorizao definidos no mtodo proposto por este trabalho,
conforme Tabela 5.4.





95
Tabela 5.4 - Resultado da avaliao dos projetos


2. Foi aplicado o Modelo Fuzzy TOPSIS, seguindo o passo-passo
detalhado na Seo 2.2.2.2.
Passo 1: Normalizar os dados Tabela 5.5;
Passo 2: Calcular os pesos Tabela 5.6;
Passo 3: Calcular os dados normalizados com os pesos
Tabela 5.7;
Passo 4: Identificar a soluo fuzzy ideal positiva e a soluo
fuzzy ideal negativa Tabela 5.8;
Passo 5: Calcular as distncias euclidianas para cada projeto
Tabela 5.9;
Passo 6: Calcular o coeficiente de aproximao Tabela 5.10;
Passo 7: Classificar os projetos Figura 5.2.








96
Tabela 5.5 - Resultado do Passo 1 Normalizao dos dados


Tabela 5.6 - Resultado do Passo 2 Clculo dos pesos






97
Tabela 5.7 - Resultado do Passo 3 Aplicao dos pesos


Tabela 5.8 - Resultado do Passo 4 Soluo fuzzy ideal positiva e a soluo fuzzy ideal
negativa



Tabela 5.9 - Resultado do Passo 5 Clculo das distncias positivas e negativas


98


Tabela 5.10 - Resultado do Passo 6 Coeficiente de aproximao




99

Figura 5.2 - Resultado do Passo 7 Classificao dos projetos pelo Modelo TOPSIS

5.2.1. Comparao dos Resultados
A comparao entre os dois mtodos indicou uma correspondncia nos
projetos que ocupam as primeiras e as ltimas posies, havendo divergncia
nas posies 3 e 4 e na 8 e 9. Porm pela avaliao do especialista, a proposta
deste trabalhou realizou a classificao dos projetos de forma mais realista,
pois tanto o projeto P11, quanto o P4 so mais relevante para o negcio do que
o P9 (projeto foi cancelado) e P12 (projeto considerado de baixa
representatividade).


Figura 5.3 - Comparao entre os mtodos


100
6. Concluses e Trabalhos Futuros
Este captulo apresenta as concluses, as principais contribuies deste
trabalho, suas limitaes e os trabalhos futuros que podero ser realizados
dentro desta linha de pesquisa.

6.1 Concluses
Este trabalho teve como objetivo principal construir um mtodo para
definio de critrios para priorizao de projetos, integrado em um processo
de desenvolvimento de software. O mtodo procurou atravs de critrios
qualitativos, calcular os benefcios e custos envolvidos nos projetos e indicar
quais projetos so mais relevantes tanto para a organizao, quanto para
equipe de desenvolvimento.
O mtodo foi validado pela tcnica Fuzzy TOPSIS e pelo especialista da
rea. Os resultados da proposta com o modelo Fuzzy TOPSIS revelou
correspondncia em 67% dos projetos. Mas conforme avaliao do especialista
da rea a proposta deste trabalho mostrou maior compatibilidade com a
realidade do ambiente.
Outro ponto positivo do mtodo que apesar de utilizar uma abordagem
subjetiva, modelo de pontuao, as alternativas de cada um dos critrios so
baseadas em valores objetivos, ligados realidade do dia-a-dia da
organizao, sendo possvel a adio de novos critrios de acordo com a
dinmica do negcio.

6.2 Limitaes
No foi possvel executar, integralmente, o processo no ambiente de
estudo, o mtodo foi avaliado com os projetos j em andamento, onde j eram
conhecidos os principais problemas, apesar de isso ter sido tambm uma


101
vantagem, porque a partir dos erros, foi possvel sugerir melhorias e definir os
critrios mais importantes para o ambiente.
Outro ponto negativo em relao ao processo de desenvolvimento de
software. No foi avaliado integralmente no ambiente, apesar de algumas
atividades e prticas previstas na fase de iniciao e construo ter sido usado
no projeto P4, gerando resultados satisfatrios.

6.3 Trabalhos Futuros
Como trabalhos futuros sugere-se avaliar o mtodo proposto antes dos
projetos serem iniciados e reavaliar quando forem concludos para identificar a
coerncia e importncia do mtodo, bem como aplicar o processo em todo o
setor para verificar os possveis ganhos e dificuldades encontrados.



102
Referncias

Abbas, Noura, Gravell, Andrew M. e Wills., Gary B. 2010. Using Factor
Analysis to Generate Clusters of Agile (A Guide for Agile Process
Improvement). Agile Conference (AGILE) : IEEE, 2010.
Agile Alliance. 2001. http://www.agilealliance.org. Acessado em: 10/10/2013.
2001.
Ambler, Scott. 2007. [Online] 1 de 3 de 2007. [Citado em: 14 de 10 de 2013.]
http://www.ambysoft.com/surveys/agileMarch2007.html.
Ambler, Scott e Lines, Mark. 2012. Disciplined Agile Delivery. s.l. : IBM Press,
2012.
Archer, NP e Ghasemzadeh, F. 1999. An integrated framework for project
portfolio selection. International Journal of Project Management 17.4 (1999):
207-216. 1999.
Beck, Kent. 2004. Programao Extrema (XP) Explicada. 2004.
Chen, C. T. 2000. Extensions of the TOPSIS for group decision-making under
fuzzy enviroment. Fuzzy Sets and Systems, v. 114, p. 1-9 . 2000.
Cooper, Robert G., J. Edgett, Scott e J. Kleinschmidt, Elko. 2001. Portfolio
Management for New Product Development: Results of an Industry Practices
Study. R&D Management (Industrial Research Institute, Inc.) Volume 31,
number 4. 2001.
Cooper, Robert G., J. Edgett, Scott e J. Kleinschmidt, Elko. 2002. Portfolio
Management: Fundamental for New Product Success. The PDMA ToolBook for
New Product Development, Wiley & Sons. 2002.
Correia, B. C. S. 2005. Portfolius: Um Modelo de Gesto de Portflio de
Projetos de Software. s.l. : Dissertao de Mestrado - Universidade Federal de
Pernambuco (UFPE), 2005.
De Boer, L., Labro, E e Morlacchi, P. 2001. A review of methods supporting
supplier selection. European Journal of Purchasing & Supply Management, v.7,
p.75-89. 2001.
Dutra, Camila Costa. 2012. Modelo econmico-probabilstico para seleo e
priorizao de projetos. Porto Alegre : s.n., 2012.
Hall, D e Naudia, A. 1990. An interactive approach for selecting IR&D projects.
IEEE Transactions on Engineering Management, v. 37, n. 2, p. 126-133. 1990.
Hamilton, Albert. 2002. Considering value during early project development: a
product case study. International Journal of Project Management, v. 20, n. 2, p.
131-136. 2002.


103
Highsmith, Jim e Cockburn, Alistair. 2001. Agile software development: the
business of innovation. s.l. : IEEE Computer p.120-122, November., 2001.
Hwang, C. L. e Yoon, K. 1981. Multiple Attribute Decision Making: Methods
and Application. Springer-Verlang: Belin (Alemanha). 1981.
Jolly, D. 2003. The issue of weightings in technology portfolio management.
Technovation, v. 23, n. 5, p. 383-391. 2003.
Larman, C. e Vodde, B. 2008. Scaling lean & agile development: thinking and
organizational tools for large-scale Scrum. s.l. : Pearson Education., 2008.
MacGibbon, Simon P., Schumacher, Jeffrey R. e Tinaikar, Ranjit S. . 2005.
When IT's customers are external. s.l. : McKinsey IT, 2005.
Martino, Joseph P. 1995. Research and Development Project Selection. s.l. :
Wiley, 1995.
Ouellette, Beth e Edington, Barbara. 2007. Gerenciamento de Portflio de
Projetos: O Monte Everest dos Projetos. Mundo PM, n. 13, pp.8-19, mar 2007.
2007.
Palmer, S. R. e Felsing, J. M. 2002. A Practical Guide to Feature-Driven
Development. s.l. : Prentice-Hall, New Jersey, USA., 2002.
Parsons, David, Ryu, Hokyoung e Lal, Ramesh. 2007. The impact of
methods and techniques on outcomes from agile software development
projects. s.l. : Springer, 2007. Vols. Pginas 235-249.
PMIa. 2006. Standard for Portfolio Management. s.l. : Project Management
Institute, Inc, 2006. 3a.
PMIb. 2008. PMBOK - Um guia do conhecimento em Gerenciamento de
Projetos. s.l. : Project Management Institute, Inc, 2008. 4a.
Rosenau, Milton D. . 2000. Successful product development: speeding from
concept to profit. s.l. : John Wiley & Sons, 2000.
Rotondaro, Fernando Jos Barbin Laurindo e Roberto Gilioli. 2006. Gesto
Integrada de Processos e da Tecnologia da Informao. s.l. : 1a, 2006.
Schoepping, Guilherme. 2012. Um estudo exploratrio a partir de um
framework para seleo de prticas geis. s.l. : Universidade Federal de Santa
Catarina - UFSC, 2012.
Schwaber, Ken. 2004. Agile Project Management with Scrum. s.l. : Microsoft
Press , 2004.
Vargas, Ricardo Viana . 2010. Utilizando a programao multicritrio (Analytic
Hierarchy Process - AHP) para selecionar e priorizar projetos na gesto de
portflio. PMI Global Congress 2010 North America. 2010.
VersionOne. 2013. 7th annual survey: The state of agile development. [Online]
2013. http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-
Survey.pdf.


104
Wang, W. 2010. A fuzzy linguistic computing apprach to supplier evalution.
Applied Mathematical Modelling. v34, p. 3130-3141. 2010.
Zadeh, L. A. 1965. Fuzzy Sets. Information and Control, v.8, p.338-353. 1965.







105
Apndice I: Questionrio para avaliao dos projetos em
andamento
Identificao
do Projeto
Principais problemas Principais Vantagens





















106
Apndice II: Questionrio para definir pontuao das alternativas
dos critrios.
Indique de 1 a 4 qual a relevncia de cada alternativa no desenvolvimento dos
projetos.
Benefcios: Quanto maior o valor atribudo para as alternativas,
mais relevante para a organizao.
CR1 Estratgia
Alternativa 1 Projeto desenvolvido para operacionalizar uma
ao do PAI
o Ponto: (___)
o Justificar a pontuao:
Alternativa 2 Projetos priorizados pela alta direo da
organizao.
o Ponto: (___)
o Justificar a pontuao:
Alternativa 3 Projetos ligados s atividades principais da
organizao: Ensino, Pesquisa e Extenso.
o Ponto: (___)
o Justificar a pontuao:
Alternativa 4 Projetos ligados s atividades de cooperao e
alicerces.
o Ponto: (___)
o Justificar a pontuao:

CR2 Processos
Alternativa 1 Automao de processos manuais
o Ponto: (___)
o Justificar a pontuao:
Alternativa 2 Melhorias em sistemas j existentes.
o Ponto: (___)
o Justificar a pontuao:
Alternativa 3 Atender uma legislao.
o Ponto: (___)


107
o Justificar a pontuao:
Alternativa 4 Outras situaes
o Ponto: (___)
o Justificar a pontuao:

Custos: Quanto menor o valor atribudo para as alternativas,
melhor para equipe desenvolver o projeto.
CR3 Resistncia
Alternativa 1 Gestor, dono do processo, no aprova o
projeto.
o Ponto: (___)
o Justificar a pontuao:
Alternativa 2 Gestor, dono do processo, aprova o projeto,
mas os usurios finais so muito resistentes ao sistema.
o Ponto: (___)
o Justificar a pontuao:
Alternativa 3 Projeto no tem dono definido.
o Ponto: (___)
o Justificar a pontuao:
Alternativa 4 Gestor e usurios aprovam o sistema ou
resistncia muito baixa de parte de usurios.
o Ponto: (___)
o Justificar a pontuao:

CR4 Complexidade
Alternativa 1 Acessar dados externos ao SIG@ e realizar
integrao com dados j existentes no SIG@; Possuir regras de
negcio complexas.
o Ponto: (___)
o Justificar a pontuao:
Alternativa 2 Utilizar novas tecnologias, ainda no testadas em
outros mdulos do SIG@.
o Ponto: (___)


108
o Justificar a pontuao:
Alternativa 3 Cadastrar, alterar, excluir, consultar e listar.
o Ponto: (___)
o Justificar a pontuao:
Alternativa 4 Cadastrar, alterar, excluir, consultar e listar, alm
de realizar consultas e relatrios com maior complexidade, como
por exemplo, que realize clculos, gere grficos, agrupamentos.
o Ponto: (___)
o Justificar a pontuao:

CR5 Recursos Necessrios
Alternativa 1 Recursos tecnolgicos no disponveis,
impedindo o incio do projeto.
o Ponto: (___)
o Justificar a pontuao:
Alternativa 2 Recursos tecnolgicos necessrios no
disponveis, impedindo que o projeto seja implantado, caso no
seja resolvido dentro do perodo de execuo do projeto.
o Ponto: (___)
o Justificar a pontuao:
Alternativa 3 Recursos tecnolgicos necessrios no
disponveis, mas pode ser utilizada uma soluo de contorno,
apesar de trazer alguma restrio para o projeto.
o Ponto: (___)
o Justificar a pontuao:
Alternativa 4 Recursos necessrios j disponveis.
o Ponto: (___)
o Justificar a pontuao:







109
Apndice III: Questionrio para definir os pesos dos critrios
Orientao: Quanto maior o valor mais relevante o critrio. O total de
pesos dos critrios benefcios deve ser igual a 50 e dos custos 50%.
Benefcios (mximo 50%):
CR1 Estratgia (___)
CR2 Processos (___)

Custos (mximo 50%):
CR3 Resistncia (___)
CR4 Complexidade (___)
CR5 Recursos Necessrios (___)




















110
Apndice IV: Planilha para aplicao da pontuao dos projetos.