Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DO PARÁ
INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO
Paulo Fernando Souza Rodrigues Júnior
UMA PROPOSTA DE APOIO SISTEMATIZADO À GERÊNCIA DE PORTFÓLIO DO MPS.BR
Trabalho de Conclusão de Curso para obtenção do grau de Bacharel em Ciência da Computação
Orientador: Prof. Dr. Sandro Ronaldo Bezerra Oliveira
Belém 2009
UNIVERSIDADE FEDERAL DO PARÁ
INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO
Paulo Fernando Souza Rodrigues Júnior
UMA PROPOSTA DE APOIO SISTEMATIZADO À
GERÊNCIA DE PORTFÓLIO DO MPS.BR
Data da defesa: ____/____/____
Conceito: ____________
Banca Examinadora
Prof. Dr. Sandro Ronaldo Bezerra Oliveira Faculdade de Computação/UFPA – Orientador
Prof. Dr. Ricardo André Cavalcante de Souza Faculdade de Computação/UFPA – Membro
Prof. Dr. Dionne Cavalcante Monteiro Faculdade de Computação/UFPA – Membro
Belém 2009
AGRADECIMENTOS
À minha querida mãe, Ana Célis, pelo carinho, incentivo e amor durante todos
os momentos. Ao meu irmão, Lucas Domires, por ser paciente e compreensivo nos
momentos difíceis. Aos meus amigos pela ajuda e momentos de descontração. Aos
demais integrantes do Projeto SPIDER, pelo companheirismo durante as nossas
pesquisas. Ao meu orientador Prof. Dr. Sandro Ronaldo Bezerra Oliveira, que
confiou desde o início no sucesso deste trabalho, e dedicou-se ao máximo para dar
todo o suporte necessário aos seus orientandos do Projeto SPIDER. E, em especial,
à Deus, por toda a força e apoio espiritual alcançados durante a minha vida.
Paulo Rodrigues Júnior
“Falta de tempo é desculpa daqueles que perdem tempo por falta de métodos.”
Albert Einstein
RESUMO
Com o aumento das exigências pela qualidade das aplicações desenvolvidas, o
mercado tem buscado empresas que sigam processos de desenvolvimento de
softwares bem definidos. No Brasil, o modelo MPS.Br tem alcançado grande
visibilidade entre as organizações desenvolvedoras, haja vista que o seu custo de
implantação é muito menor que o de modelos como o CMMI. Sendo assim, o Projeto
SPIDER foi idealizado com o intuito de promover a aderência das organizações aos
níveis de maturidade G e F do Modelo MPS.Br. Em maio de 2009, a Gerência de
Portfólio de Projetos foi inserida no MPS.Br como sendo um dos processos exigidos
do nível F de maturidade. Apesar de estar sendo debatido nos últimos anos, este é
um conceito novo e que poucas ferramentas implementam serviços que atendem as
exigências deste processo. Como não foram identificadas aplicações que
objetivavam suprir as necessidades da Gerência de Portfólio, foram propostos
ajustes no dotProject que visam implementar os serviços necessários. Juntamente
com os ajustes, definiu-se uma metodologia de uso sobre as ferramentas dotProject,
Mantis e Spider-CL, onde, seguindo esta metodologia, todos os cinco Resultados
Esperados exigidos pela Gerência de Portfólio do Modelo MPS.Br serão atendidos,
viabilizando então, alcançar no nível F de maturidade.
PALAVRAS-CHAVE: Melhoria do Processo, Qualidade do Software, Modelos de
Melhoria, MPS.Br, Ferramentas de Software, Gerência de Portfólio.
ABSTRACT
With the increasing demands for software quality, the market is seeking for
companies that follow well-defined development software processes. In Brazil, the
MPS.Br model is reaching great visibility among development organizations, once its
deployment cost is much lower than models like CMMI. In this scenario, SPIDER
Project was idealized to promote organizations adherence to G and F maturity levels
of MPS.Br. In May 2009, the Portfolio Management was inserted in the MPS.Br as
one of the process required to F maturity level. Despite the last years it debates, this
is a new concept and few tools implement services that attend this process demands.
Once there weren’t applications that aim to attend Portfolio Management needs,
adjustments were proposed in the dotProject to implement the needed services.
Together with those adjustments a use methodology of the dotProject, Mantis and
Spider-CL tools was defined, that all Portfolio Management’s expected results of
MPS.Br will be attended, enabling to achieve F maturity level, following this
methodology.
KEYWORDS: Process Improvement, Software Quality, Improvement Models, MPS.Br, Software Tools, Portfolio Management.
SUMÁRIO
1 Introdução ..................................................................................................................................... 12
1.1 Contexto ................................................................................................................................ 12
1.2 Justificativa ........................................................................................................................... 12
1.3 Motivação .............................................................................................................................. 13
1.4 Objetivos ............................................................................................................................... 13
1.4.1 Geral .............................................................................................................................. 13
1.4.2 Específico ...................................................................................................................... 14
1.5 Metodologia .......................................................................................................................... 14
1.6 Estrutura ................................................................................................................................ 14
2 MPS.Br .......................................................................................................................................... 16
2.1 Histórico do MPS.Br ............................................................................................................. 16
2.2 Definição e Composição do Modelo MPS.Br ....................................................................... 17
2.3 Níveis de Maturidade do MPS.Br ......................................................................................... 19
2.4 Guias do MPS.Br................................................................................................................... 20
2.5 Considerações Finais ............................................................................................................. 21
3 Processo de Gerência de Portfólio................................................................................................. 22
3.1 Gerência de Portfólio ............................................................................................................ 22
3.2 Gerência de Portfólio no MPS.Br ......................................................................................... 24
3.3 Análise dos Resultados Esperados ........................................................................................ 26
3.3.1 GPP1 - As oportunidades de negócio, as necessidades e os investimentos são identificados, qualificados, priorizados e selecionados. ................................................................ 26
3.3.2 GPP 2 - Os recursos e orçamentos para cada projeto são identificados e alocados. ..... 27
3.3.3 GPP 3 - A responsabilidade e autoridade pelo gerenciamento dos projetos são estabelecidas. ................................................................................................................................. 27
3.3.4 GPP 4 - Os conflitos sobre recursos entre projetos são tratados e resolvidos. .............. 27
3.3.5 GPP 5 - Projetos que atendem aos acordos e requisitos que levaram à sua aprovação são mantidos, e os que não atendem são redirecionados ou cancelados. ............................................. 28
3.4 Considerações Finais ............................................................................................................. 29
4 Apoio Sistematizado à Gerência de Portfólio ............................................................................... 30
4.3 O Projeto SPIDER ................................................................................................................. 30
4.4 Ferramentas de Apoio ........................................................................................................... 31
4.4.1 dotProject ...................................................................................................................... 32
4.4.2 Mantis ............................................................................................................................ 32
4.4.3 Spider-CL ...................................................................................................................... 33
4.5 Mapeamento das Ferramentas com os Resultados Esperados ............................................... 33
4.5.1 GPP1: Parcialmente Implementado ( dotProject e Spider-CL ) .................................... 34
4.5.2 GPP2: Não Implementado ............................................................................................. 35
4.5.3 GPP3: Parcialmente Implementado ( dotProject )......................................................... 36
4.5.4 GPP4: Totalmente Implementado ( Mantis ) ................................................................ 36
4.5.5 GPP5: Parcialmente Implementado ( dotProject e Spider-CL ) .................................... 36
4.6 Melhorias Propostas para as Ferramentas de Apoio.............................................................. 37
4.6.1 GPP1 ............................................................................................................................. 37
4.6.2 GPP2 ............................................................................................................................. 40
4.6.3 GPP3 ............................................................................................................................. 41
4.6.4 GPP5 ............................................................................................................................. 41
4.7 Considerações Finais ............................................................................................................. 43
5 Metodologia de Implementação .................................................................................................... 44
5.3 Instalação das Ferramentas .................................................................................................... 44
5.3.1 Instalação do dotProject ................................................................................................ 44
5.3.2 Instalação do Spider-CL ................................................................................................ 45
5.3.3 Instalação do Mantis ...................................................................................................... 45
5.4 Políticas de Uso ..................................................................................................................... 46
5.4.1 GPP1: dotProject e Spider-CL ...................................................................................... 47
5.4.2 GPP2: dotProject ........................................................................................................... 49
5.4.3 GPP3: dotProject ........................................................................................................... 50
5.4.4 GPP4: Mantis ................................................................................................................ 50
5.4.5 GPP5: dotProject e Spider-CL ...................................................................................... 51
5.5 Considerações Finais ............................................................................................................. 52
6. Conclusão ...................................................................................................................................... 54
6.3 Resumo .................................................................................................................................. 54
6.4 Resultados Obtidos ................................................................................................................ 54
6.5 Trabalhos Futuros .................................................................................................................. 55
6.6 Lições Aprendidas ................................................................................................................. 55
Referências Bibliográficas .................................................................................................................... 56
LISTA DE FIGURAS
Figura 2.1 - Modelo de Negócio para melhoria de processo de software (MN mps) [Weber, 2004] ... 18
Figura 2.2 - Definição do Modelo de Referência [Weber, 2004] .......................................................... 19
Figura 2.3 - Níveis de Maturidade do MPS.Br [SOFTEX, 2009m] ...................................................... 20
Figura 4.1 - Tabela de mapeamento dos resultados esperados com as ferramentas .............................. 34
Figura 4.2 - Avaliação da oportunidade através da ferramenta Spider-CL ........................................... 38
Figura 4.3 - Protótipo para atender aos requisitos do GPP2 ................................................................. 39
Figura 4.4 - Protótipo para atender aos requisitos do GPP2 ................................................................. 39
Figura 4.5 - Protótipo para atender aos requisitos do GPP2 ................................................................. 40
Figura 4.6 - Protótipo para atender aos requisitos do GPP3 ................................................................. 41
Figura 4.7 - Protótipo para atender aos requisitos do GPP5 ................................................................. 42
Figura 4.8 - Protótipo para atender aos requisitos do GPP5 ................................................................. 42
Figura 5.1 - Criação de um novo projeto no dotProject ........................................................................ 47
Figura 5.2 - Criação de um novo projeto no dotProject ....................................................................... 48
Figura 5.3 - Criação de uma issue no Mantis ........................................................................................ 51
Lista de Tabelas
Tabela 3.1 - Processo gerencial para criação do gerenciamento de portfólio, adaptada de Crawford, 2002 [RABECHINI et al, 2005]. ........................................................................................................... 24
12
1 INTRODUÇÃO
Neste capítulo será apresentado o contexto no qual este trabalho está inserido, a
justificativa e os objetivos desta pesquisa, bem como a motivação que a originou, a
metodologia utilizada e a estrutura deste trabalho.
1.1 Contexto
Com o aumento das exigências pela qualidade das aplicações desenvolvidas, o mercado
tem buscado empresas que sigam processos de desenvolvimento de softwares bem definidos.
No Brasil, o Modelo de Processo de Software Brasileiro tem alcançado grande visibilidade
entre as organizações desenvolvedoras, haja vista que o seu custo de implantação é muito
menor que o de modelos como o CMMI (Capability Maturity Model Integration).
Criado a partir de normas e modelos internacionais, o MPS.Br é dividido em sete níveis
de maturidade, onde as empresas definem em que nível desejam ser avaliadas. Para atender
aos requisitos exigidos em cada nível, as organizações se baseiam em guias elaborados para
este fim, onde existem informações detalhadas de como atender a cada um dos Resultados
Esperados.
1.2 Justificativa
A crescente demanda por produtos e serviços de alta qualidade para suprir o aumento da
competitividade e concorrência internacional, tem exigido das empresas brasileiras
oferecerem garantias de que possuem maturidade suficiente para desenvolver seus projetos.
No âmbito nacional, esta garantia vem sendo obtida através da implantação do MPS.Br.
O MPS.Br se propõe a ser um guia evolucionário para o aperfeiçoamento e adequação
de processos organizacionais orientados para a excelência no desenvolvimento de software.
Apostando num custo acessível, especialmente para micro, pequenas e médias empresas, e na
aproximação com a realidade do mercado brasileiro, ele é aderente a ISO/IEC 12207, a série
de normas ISO/IEC 15504 e ao modelo CMMI. Com metas ousadas e uma sólida estrutura de
pesquisa, fomentada por Universidades e pelo Ministério da Ciência e Tecnologia, o modelo
está entrando nas empresas brasileiras de maneira constante e incremental, conforme
planejado.
13
O padrão de qualidade MPS.Br descreve o quê deve ser feito para melhoria gradual de
processos, definindo níveis de maturidade que são organizados por áreas de processo, os quais
possuem objetivos alcançados pelos chamados Resultado Esperados. Para tanto, faz-se
necessária a utilização de ferramentas de software para possibilitar a implantação do MPS.Br
nas organizações. Com o intuito de alavancar pesquisas na sistematização do MPS.Br, o
Projeto SPIDER foi idealizado para apresentar um levantamento de ferramentas de software
livre com características adequadas para possibilitar a criação de produtos de trabalhos
derivados dos Resultados Esperados, descritos nos objetivos das Áreas de Processo, dos
níveis de maturidade G e F do modelo MPS.Br. Este trabalho tratará especificamente da Área
de Processo de Gerência de Portfólio.
A Gerência de Portfólio de Projetos (GPP) foi inserida recentemente, maio de 2009, nos
requisitos para avaliação do Nível F. Com isso, se faz necessário o estudo de uma
metodologia para implementação deste processo de forma eficaz. De acordo com a proposta
do Projeto SPIDER, serão utilizadas ferramentas livres para dar suporte as necessidades desta
metodologia, buscando alcançar os Resultados Esperados do MPS.Br em relação a Gerência
de Portfólio.
1.3 Motivação
A Gerência de Portfólio é uma área pouco explorada entre os consultores de
implementação do MPS.Br, haja vista que foi inserida recentemente no Nível F, o que agrega
um crescente valor ao seu estudo, além de possibilitar ao Projeto SPIDER contemplar na
totalidade os níveis G e F do MPS.Br. Soma-se a isso o interesse pessoal pela Gerência de TI
(Tecnologia da Informação), onde a experiência como pesquisador do Projeto SPIDER, mais
especificamente do estudo da Metodologia de Implantação da Gerência de Portfólio, trará tal
benefício.
1.4 Objetivos
1.4.1 Geral
Definir uma metodologia eficaz para a implementação da Gerência de Portfólio,
alcançando todos os Resultados Esperados pelo MPS.Br em relação a este processo, bem
como definir os ajustes necessários às ferramentas escolhidas para atender os requisitos
exigidos e, além disso, elaborar um protótipo contemplando os ajustes propostos.
14
1.4.2 Específico
• Descrever a gerência de Portfólio no contexto do MPS.Br
• Definir uma metodologia que:
o Identifique, qualifique, priorize e selecione as oportunidades de negócio, as
necessidades e os investimentos;
o Identifique e organize os recursos e orçamentos para cada projeto;
o Estabeleça a responsabilidade e autoridade pelo gerenciamento dos projetos;
o Trate e resolva os conflitos sobre recursos entre projetos;
o Mantenha projetos que atendem aos acordos e requisitos que levaram à sua
aprovação, e redirecione ou cancele os que não atendem;
• Rastrear as características que já são suportadas por meio da implementação das
ferramentas de software livres propostas nos demais sub-projetos do Projeto SPIDER;
• Definir os ajustes necessários às ferramentas escolhidas de tal modo que possam
oferecer todos os serviços exigidos pelos Resultados Esperados do processo de GPP;
• Elaborar um protótipo para cada funcionalidade que deve ser adicionada às
ferramentas de acordo com os ajustes propostos.
1.5 Metodologia
A metodologia aplicada neste trabalho sustenta-se na pesquisa bibliográfica de áreas
relacionadas, através de livros, artigos, Trabalhos de Conclusão de Curso e revistas. Para
comprovar a eficiência da proposta elaborada no decorrer deste trabalho, foi realizada uma
pesquisa experimental, onde foram executadas verificações sobre a proposta de forma que
esta seja avaliada sobre os Resultados Esperados da Gerência de Portfólio de Projetos do
Modelo MPS.Br.
Além disso, foi aplicado o método da indução, onde foram estudados certos casos de
portfólio de projetos, e, partindo de suas características, foi possível entender a estrutura
necessária para ser definida uma metodologia para implementação da Gerência de Portfólio
de Projeto respeitando os requisitos solicitados no MPS.Br.
1.6 Estrutura
Além deste capítulo introdutório, a organização desta monografia foi feita da seguinte
forma.
15
O capítulo 2 tem por objetivo explicar a Melhoria de Processo de Software Brasileiro,
as justificativas de sua criação, sua composição e seus guias.
O capítulo 3 direciona suas informações à Gerência de Portfólio, conceituando-a de
maneira mais ampla e contextualizando este processo dentro do Modelo MPS.Br, detalhando
cada um de seus Resultados Esperados.
O capítulo 4 apresenta o Projeto SPIDER, no qual este trabalho de pesquisa está
inserido, além de justificar a escolha das ferramentas utilizadas para o auxílio da
implementação deste processo e apresentar o mapeamento destas com os Resultados
Esperados, bem como os ajustes propostos.
O capítulo 5 apresenta o procedimento de instalação das ferramentas escolhidas e a
metodologia de uso a ser aplicada de modo que os Resultados Esperados da Gerência de
Portfólio de Projetos sejam atendidos de maneira eficiente.
O capítulo 6 apresenta a conclusão do trabalho proposto, comentando os resultados
obtidos, propostas para trabalhos futuros e as lições aprendidas com esta pesquisa.
16
2 MPS.BR
Criado pela Associação Brasileira para Promoção da Exportação de Software
(SOFTEX), o Modelo MPS.Br (Melhoria do Processo de Software Brasileiro) objetiva:
Definir e aprimorar um modelo de melhoria e avaliação de processo de software,
visando preferencialmente as micro, pequenas e médias empresas, de forma a
atender as suas necessidades de negócio e ser reconhecido nacional e
internacionalmente como um modelo aplicável à indústria de software [SOFTEX,
2009m].
2.1 Histórico do MPS.Br
Ao longo da década de 80, o mercado para informática direcionou seu foco de forma
intensa para a produção de hardware e desenvolvimento de microeletrônica, em detrimento a
indústria de software [MCT, 2002]. Sendo assim, para buscar o equilíbrio entre as áreas de
hardware e software, o MCT criou o programa SOFTEX, “cujo objetivo inicial era o de
implantar infra-estrutura de uso geral, para incubar empresas produtoras e exportadoras de
software” [MCT, 2002].
Em 1993, o Ministério da Ciência e Tecnologia criou o que viria a se tornar um dos
programas prioritários na área de informática, o Programa Nacional de Software para
Exportação (Programa SOFTEX 2000). Em 1996 o Governo passou a gestão do Programa
SOFTEX para o setor privado, considerando e encaminhando os objetivos iniciais do
programa. A Sociedade SOFTEX, uma organização não governamental e sem fins lucrativos,
atua, desde então, como sua gestora.
Em 2001, a SOFTEX contava com cerca de mil empresas associadas aos 19 Núcleos
Regionais e 18 Centros SOFTEX GENESIS, espalhados por 12 estados da federação, das
quais 850 são empresas maduras e 150 start-ups. O faturamento dessas empresas em 2000 foi
de cerca de R$ 2 bilhões (aproximadamente um terço do faturamento total da indústria de
software no País) e suas exportações totalizaram cerca de US$ 100 milhões. Em parceria com
o Banco Nacional do Desenvolvimento (BNDES), foi criado também o Prosoft, para
estimular a competitividade dessa indústria em nível internacional. Com essas ações, as
empresas de software se desenvolveram e se habilitaram a desempenhar papel relevante na
construção da Sociedade da Informação no Brasil [MCT, 2002].
17
Entretanto, as empresas de software no Brasil priorizavam seus esforços a atender a ISO
9000 [ABNT, 2001], sem favorecer outras normas e modelos especificamente voltadas para a
melhoria de processo de software [MIT 2003], sendo necessário um esforço significativo para
melhorar a maturidade do processo de softwares nessas empresas [MCT, 2002].
Assim sendo, em 11 de dezembro de 2003, a SOFTEX, com o apoio do Ministério da
Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP), do Serviço
Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e do Banco Interamericano de
Desenvolvimento (BID), lançou o programa MPS.Br para solução deste problema.
Os propósitos do MPS.Br compreendem dois desafios, o primeiro seria a criação e o
aprimoramento do modelo MPS e o segundo a disseminação e adoção deste modelo em todas
as regiões do país a um custo razoável.
2.2 Definição e Composição do Modelo MPS.Br
A implementação e avaliação de modelos como o Capability Maturity Model
Integration (CMMI) [SEI, 2006] até mesmo nos seus níveis mais baixos está fora do alcance
da grande massa de micro, pequenas e médias empresas especialmente no Brasil e países
latino-americanos devido ao seu custo elevado. Com isso, o MPS.Br baseou-se na elaboração
de dois modelos: o Modelo de Referência para melhoria de processo de software (MR-MPS) e
o Modelo de Negócio para melhoria de processo de software (MN MPS).
Para atingir a sua meta de atender principalmente micro, pequenas e médias empresas, o
MN MPS prevê duas situações para a implementação do MR-MPS: de forma personalizada
para uma empresa (MNE – Modelo de Negócio Específico); e de forma cooperada em grupos
de empresas (MNC – Modelo de Negócio Cooperado), com custo mais acessível por dividir
proporcionalmente parte dos custos entre as empresas e por se buscar outras fontes de
financiamento [WEBER, 2004].
Existem instituições credenciadas para a implementação do MR-MPS e a realização de
avaliações segundo o Modelo MPS.Br. O Fórum de Credenciamento e Controle (FCC) é o
responsável pelo credenciamento, onde a SOFTEX assina um convênio com as instituições
credenciadas tornando-as Instituições Credenciadas para Implementação (ICI ou II) ou
Instituições Credenciadas para Avaliação (ICA ou IA).
18
No MNE a empresa interessada na implementação do MR-MPS busca uma das II e
assina um contrato específico. Caso deseje ser avaliada, a empresa interessada deve negociar e
assinar um contrato específico com uma das IA. A Sociedade SOFTEX toma conhecimento
do contrato e dos resultados da implementação e/ou avaliação da empresa interessada através
da II ou IA contratada. O Modelo de Negócio do MPS.Br é ilustrado na Figura 2.1.
Figura 2.1 - Modelo de Negócio para melhoria de processo de software (MN mps) [Weber, 2004]
No MNC, primeiramente deve ser constituído um grupo de empresas interessadas na
implementação do MR-MPS. A coordenação do grupo deverá então negociar e assinar um
contrato com uma das II do MR-MPS. Após a implementação, irá negociar e assinar um
contrato com uma das IA do MR-MPS. Nesta situação, a Sociedade SOFTEX toma
conhecimento dos resultados da implementação e/ou avaliação através da ICI ou ICA
contratada pelo grupo, e assina um convênio com a entidade organizadora do grupo, que pode
ser um Agente SOFTEX.
O MPS.Br não objetiva criar Normas e Modelos de Maturidade, busca ser inovador na
sua estratégia de implementação, que prioriza se adequar à realidade das empresas brasileiras.
Sendo assim, modelos, normas e métodos já disponíveis formaram a base para a definição do
Modelo de Referência [Weber, 2004], como ilustra a Figura 2.2.
19
Figura 2.2 - Definição do Modelo de Referência [Weber, 2004]
A definição do MR-MPS partiu da análise da realidade das empresas brasileiras, a
norma ISO/IEC 12207 [ISO/IEC, 2008], a série de normas ISO/IEC 15504 [ISSO/IEC, 2003]
[ISSO/IEC, 2004a] [ISSO/IEC, 2004b] [ISSO/IEC, 2004c] [ISSO/IEC, 2006] e o modelo
CMMI. Com isso, o Modelo de Referência foi definido com sete níveis de maturidade e é
constituído, também, por uma série de guias para auxiliar as empresas interessadas em sua
implementação, assim como as II e as IA.
2.3 Níveis de Maturidade do MPS.Br
O desempenho de uma empresa ao executar um ou mais processos pode ser previsto ao
verificar o nível de maturidade no qual se encontra esta organização. Os sete níveis de
maturidade, que são uma combinação entre processos e sua capacidade, definidos pelo MR-
MPS são: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D
(Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente
Gerenciado).
A evolução da empresa nos níveis de maturidade se dá a partir do nível G até o nível A,
onde a progressão da organização através desses níveis representa a sua evolução na
implementação dos processos previstos em cada um deles. O nível de maturidade é obtido
quando são atendidos os propósitos e todos os Resultados Esperados dos respectivos
processos, bem como os Resultados Esperados dos atributos de processo estabelecidos para o
respectivo nível [SOFTEX, 2009m].
20
A Figura 2.3 ilustra os Processos e Atributos de Processo requeridos em cada nível de
maturidade.
Figura 2.3 - Níveis de Maturidade do MPS.Br [SOFTEX, 2009m]
O objetivo desta divisão considerando mais níveis de maturidade, em relação ao CMMI,
é para possibilitar uma implementação e avaliação adequada para as micro, pequenas e
médias empresas, possibilitando também visualizar os resultados de melhoria de processos em
prazos mais curtos.
2.4 Guias do MPS.Br
O modelo MPS.Br está descrito em formato de guias. Sendo estes divididos em Guia
Geral, Guia de Aquisição, Guia de Avaliação e Guia de Implementação, explicados a seguir
[SOFTEX, 2009m].
21
• Guia Geral: contém a descrição geral do modelo MPS e detalha o Modelo de
Referência (MR-MPS), seus componentes e as definições comuns necessárias para
seu entendimento e aplicação;
• Guia de Aquisição: descreve um processo de aquisição de software e serviços
correlatos. É descrito como forma de apoiar as instituições que queiram adquirir
produtos de software e serviços correlatos apoiando-se no MR-MPS [SOFTEX,
2009b];
• Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os
requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras
(IA) [SOFTEX, 2009a];
• Guia de Implementação: série de dez documentos que fornecem orientações para
implementar nas organizações os níveis de maturidade descritos no Modelo de
Referência MR-MPS [SOFTEX, 2009c], [SOFTEX, 2009d], [SOFTEX, 2009e],
[SOFTEX, 2009f], [SOFTEX, 2009g], [SOFTEX, 2009h], [SOFTEX, 2009i],
[SOFTEX, 2009j], [SOFTEX, 2009k] e [SOFTEX, 2009l].
2.5 Considerações Finais
Este capítulo apresentou o Modelo MPS.Br, desde a motivação que levou a sua criação
pela SOFTEX até a descrição do Modelo de Referência elaborado.
Um dos processos contidos no MPS.Br é o Processo de Gerência de Portfólio, que será
abordado mais detalhadamente no capítulo a seguir, tendo em vista que este trabalho tem por
objetivo apresentar uma proposta de apoio sistematizado a este processo.
22
3 PROCESSO DE GERÊNCIA DE PORTFÓLIO
Após o lançamento da metodologia denominada OPM3 (Organizational Project
Management Maturity Model) [PMI, 2003], gerenciamento de portfólio se tornou um tema
bastante explorado em literaturas sobre projetos. O OPM3 possui estruturas conceituais
baseadas em evoluções sucessivas que contemplam além de projetos e programas, os
portfólios.
3.1 Gerência de Portfólio
Para o correto entendimento da Gerência de Portfólio, primeiramente é necessário
absorver a definição de projeto. Na literatura existem algumas definições clássicas para
projetos:
“Um processo único, consistindo de um grupo de atividades coordenadas e controladas
com datas para início e término, empreendido para alcance de um objetivo conforme
requisitos específicos, incluindo limitações de tempo, custo e recursos.” [ISO10006, 1997].
“Um empreendimento de esforço temporário feito para criar um produto, serviço ou
resultado único.” [PMI, 2002].
Um projeto é uma organização de pessoas dedicadas visando atingir um propósito e
objetivo específico. Projetos geralmente envolvem gastos, ações únicas ou
empreendimentos de altos riscos o qual tem que ser completado numa certa data por
um montante de dinheiro, dentro de alguma expectativa de desempenho. No mínimo
todos projetos necessitam de terem seus objetivos bem definidos e recursos
suficientes para poderem desenvolver as tarefas requeridas. [TUMAN, 1983].
Um projeto visa gerar produtos, serviços ou resultados únicos e exclusivos, para atender
um ou mais objetivos. Desta forma, os objetivos dos projetos devem ser alinhados à estratégia
da organização, permitindo que ele seja utilizado como mecanismo para operacionalização do
planejamento estratégico organizacional.
É possível, porém, encontrar em diversas empresas exemplos de projetos propostos que
não conseguiram atingir os benefícios prometidos. Os exemplos mais comuns são de projetos
23
inadequados, não sincronizados com os objetivos da organização, com riscos excessivos ou
aprovados em decorrência de força política dos patrocinadores [SOUZA et al, 2009], sugando
os recursos que poderiam ser direcionados para projetos que trariam mais benefícios à
organização [YELIN, 2007].
Para contornar isto, é necessária uma gerência adequada do projeto para que o mesmo
alcance todos os seus objetivos designados. A Gerência de Projetos tem por objetivos
planejar, programar e controlar uma série de tarefas integradas de forma a atingir, com êxito,
os objetivos do projeto, para benefício dos envolvidos [KERZNER, 2005]. O [PMI, 2008a]
define gerência de projetos como sendo a aplicação de conhecimentos, habilidades,
ferramentas e técnicas nas atividades do projeto, com o objetivo de atender às suas
necessidades.
Uma empresa que tenha recursos para executar todos os projetos candidatos, atendendo
um determinado conjunto de metas e objetivos, seria um cenário ideal. Entretanto, a grande
maioria das empresas não vive esta realidade, e a execução de seus projetos é limitada por
variáveis como tempo, orçamento, recursos, entre outras restrições, forçando-as a limitar o
número de projetos executados de maneira concorrente.
Sendo assim, surge uma nova demanda para as organizações: avaliar, priorizar e
selecionar os projetos candidatos a atender determinados objetivos de forma alinhada à
estratégia organizacional, ligando às atividades estratégicas, táticas e operacionais [YELIN,
2007]. Com isso, as empresas deixam de empregar grandes esforços em fazer os projetos
darem certo e concentram-se na seleção dos projetos certos.
Para [ARCHER & GHASEMZADEH, 1999], gerenciamento de portfólio é uma
coleção de projetos que são desenvolvidos sob a administração de uma unidade
organizacional, onde cada projeto pode se relacionar com outros ou ser independente. No
entanto, devem fazer parte de objetivos estratégicos determinados e assim buscar recursos na
organização.
[KENDALL & ROLLINS, 2003] enfatizam que o gerenciamento de portfólio serve
para garantir que o conjunto de projetos escolhido e mantido na carteira deve atender os
objetivos organizacionais.
24
[CRAWFORD, 2002] apresenta o gerenciamento de portfólio visto como um processo
gerencial que é guiado pelos passos apresentados na Tabela 3.1.
Tabela 3.1 - Processo gerencial para criação do gerenciamento de portfólio, adaptada de Crawford, 2002
[RABECHINI et al, 2005].
3.2 Gerência de Portfólio no MPS.Br
Reconhecendo o valor da disciplina no suporte do sucesso da estratégia organizacional,
a SOFTEX, em maio de 2009, integrou ao modelo do MPS.Br o processo de Gerência de
Portfólio.
Seguindo uma fundamentação teórica do Padrão de Gerência de Portfólio [PMI, 2008b]
que foi disseminado pelo Project Management Institute – PMI (reconhecida associação
profissional na área de gerenciamento de projetos), a Gerência de Portfólio de Projetos do
MPS.Br foca nas atividades envolvidas no gerenciamento da carteira de projetos da
organização, e não apenas sobre um projeto individualmente.
Para o modelo, a governança de um conjunto de projetos é realizada de duas formas:
selecionando os projetos que devem ser executados; e, uma vez em execução, avaliando se
estes projetos continuam viáveis e aderentes aos critérios pelos quais foram aprovados
[SOFTEX, 2009d].
Na primeira etapa, o objetivo é criar uma combinação de projetos que melhor apóie os
objetivos da organização, alinhada com as suas estratégias e com as restrições de recursos
(pessoas e orçamento) [Levine apud SOFTEX, 2009d].
25
Na segunda, o objetivo é garantir que, à medida que os projetos vão sendo executados,
continuem aderentes e satisfazendo os objetivos pelos quais foram iniciados. Segundo
Maizlish e Handler [apud SOFTEX, 2009d] visa, ainda, avaliar se o projeto continua sendo
necessário frente às mudanças no ambiente que podem ocorrer durante a sua execução,
principalmente devido a:
� Modificações na composição das necessidades do negócio e da missão em relação às
ofertas de produtos e serviços;
� Tendências da indústria;
� Mudanças na economia;
� Demandas dos clientes;
� Ofertas dos fornecedores;
� Novas tecnologias;
� Requisitos legais;
� Competitividade e/ou business intelligence.
Além disso, também é previsto o cancelamento ou suspensão de projetos cujos riscos ou
desvantagens para a organização superem os benefícios de se continuar investindo [ISO/IEC,
2008 apud SOFTEX, 2009d].
Todas estas características são requeridas através dos Resultados Esperados do Processo
de Gerência de Portfólio de Projetos previsto no Nível F do MPS.Br:
� GPP1: As oportunidades de negócio, as necessidades e os investimentos são
identificados, qualificados, priorizados e selecionados;
� GPP2: Os recursos e orçamentos para cada projeto são identificados e alocados;
� GPP3: A responsabilidade e autoridade pelo gerenciamento dos projetos são
estabelecidas;
26
� GPP4: Os conflitos sobre recursos entre projetos são tratados e resolvidos;
� GPP5: Projetos que atendem aos acordos e requisitos que levaram à sua aprovação
são mantidos, e os que não atendem são redirecionados ou cancelados.
A organização que desejar ter uma Gerência de Portfólio aderente ao MPS.Br, deve
atender a todos estes Resultados Esperados. Porém, para o MPS.Br, a Gerência de Portfólio
de Projetos torna-se opcional quando a única atividade da unidade organizacional for
evolução de produto, podendo ser considerada fora do escopo da avaliação da empresa.
3.3 Análise dos Resultados Esperados
Uma análise detalhada de cada GPP foi realizada a fim de identificar os requisitos
necessários para atender de forma satisfatória cada um dos Resultados Esperados.
3.3.1 GPP1 - As oportunidades de negócio, as necessidades e os investimentos são identificados, qualificados, priorizados e selecionados.
O GPP1 é descrito no [SOFTEX, 2009d] da seguinte forma:
[...] Inicialmente, as demandas precisam ser identificadas, ou seja, é preciso registrá-las para que possam ser posteriormente analisadas, com o objetivo de definir se serão iniciadas como projetos ou descartadas.
Em seguida as demandas deverão ser qualificadas, ou seja, deverão ser identificados os atributos que a caracterizam e que serão utilizados como critérios de seleção e priorização. [...] Selecionar os projetos significa validar sua aderência aos objetivos organizacionais antes que sejam incorporados ao portfólio. Potenciais projetos que estejam mais alinhados com os critérios estabelecidos receberão tratamento prioritário, enquanto que os demais receberão prioridade menor ou serão até mesmo descartados do portfólio.
[...] É importante ressaltar que este resultado não se refere apenas à análise da viabilidade de um projeto individualmente, mas sim sob a perspectiva mais global, do portfólio de projetos e dos objetivos estratégicos da organização.
Nota-se que o objetivo deste GPP é o de maximizar o valor das oportunidades
identificadas, através da avaliação detalhada para viabilizar a inclusão no portfólio ou
exclusão oportuna dos projetos que não estão de acordo com os objetivos estratégicos do
portfólio.
Esta avaliação é feita levando-se em consideração aspectos como: rentabilidade dos
projetos; riscos associados aos projetos (alto/baixo); tempo de duração (curto/longo);
27
importância dos clientes (estratégica/financeira); e alinhamento com as estratégias de
negócios.
Sendo assim, este resultado consiste na obtenção de uma coleção de projetos que estão
de acordo com os aspectos estratégicos da empresa, oferecendo então, subsídios para a
tomada de decisão baseada em informações estratégicas e prioridades.
3.3.2 GPP 2 - Os recursos e orçamentos para cada projeto são identificados e alocados.
Este GPP está descrito da seguinte forma [SOFTEX, 2009d]:
Para cada um dos projetos que tenham sido selecionados e priorizados devem ser provisionados e disponibilizados os recursos e o orçamento necessários. [...] No entanto, deve-se, neste momento, analisar os possíveis conflitos de alocação de recursos entre os projetos, especialmente aqueles que são considerados críticos. Esta é uma perspectiva mais organizacional do que simplesmente individual de cada projeto.
Nota-se que este GPP objetiva atribuir à carteira de projetos da empresa, os recursos e
suporte necessários de acordo com os riscos/rendimentos envolvidos, buscando um equilíbrio
adequado do portfólio com o uso eficiente dos recursos, para evitar o desperdício causado
pela alocação ineficiente destes.
3.3.3 GPP 3 - A responsabilidade e autoridade pelo gerenciamento dos projetos são estabelecidas.
Este GPP está descrito da seguinte forma [SOFTEX, 2009d]:
“Para cada um dos projetos que tenha sido selecionado e priorizado, deve ser identificado o profissional que será responsável pelas atividades de gerenciamento do projeto, ou seja, que exercerá o papel de Gerente do Projeto [...]”
Como o sucesso de um projeto está, também, ligado a liderança e capacidade dos
indivíduos que estão a sua frente, este GPP busca identificar e alocar o indivíduo mais
capacitado para exercer a função de Líder de Projeto.
3.3.4 GPP 4 - Os conflitos sobre recursos entre projetos são tratados e resolvidos.
Este GPP está descrito da seguinte forma [SOFTEX, 2009d]:
À medida que os projetos vão sendo realizados, novos conflitos de recursos podem ser identificados. Os projetos de TI raramente são executados exatamente como o
28
planejado, por diversos motivos [...]. Estes fatores podem afetar a execução dos projetos do portfólio e também levar a novos conflitos sobre recursos.
[...] Estes conflitos, analisados sob a perspectiva organizacional dos múltiplos projetos em execução, devem ser registrados, analisados, tratados e resolvidos.
Para uma adequada gestão da carteira de portfólio, se faz necessário um eficaz controle
sobre os possíveis conflitos que possam surgir entre projetos. Os projetos de TI raramente são
executados como planejado, podendo então ocasionar conflitos sobre recursos utilizados por
outro projeto. Além disso, o desempenho de um projeto pode afetar a execução de outro
projeto do portfólio.
Este GPP espera soluções para a identificação, análise e solução destes possíveis
conflitos, de maneira que reflita as prioridades da organização para seus investimentos e
alocação de recursos.
3.3.5 GPP 5 - Projetos que atendem aos acordos e requisitos que levaram à sua aprovação são mantidos, e os que não atendem são redirecionados ou cancelados.
Este GPP está descrito da seguinte forma [SOFTEX, 2009d]:
À medida que um projeto vai sendo executado, as atividades de monitoramento vão sendo realizadas, de maneira a coletar informações, na forma de “fotos” de determinados momentos do projeto, permitindo a atuação do gerente de projetos, quando necessário. Estas são as atividades relacionadas ao gerenciamento do projeto individualmente, conforme previsto no processo GPR.
Porém, todos os projetos possuem riscos que, se confirmados, podem levar o projeto a se desviar de seu plano original, afastando-se da situação que foi levada em consideração quando se determinou a sua aprovação. Neste momento, a empresa precisa analisar se este projeto continua alinhado aos objetivos estratégicos pretendidos, se é necessário algum redirecionamento ou até mesmo se é o momento de ser cancelado.
A Gerência de Portfólio do MPS.Br prevê o monitoramento e controle dos projetos que
estão em andamento, decidindo quais projetos devem continuar e quais projetos devem deixar
o portfólio. Nota-se, então, que os projetos em execução devem sofrer avaliações periódicas
de acordo com os objetivos estratégicos da organização.
A coleta e análise de dados a fim de avaliar o desempenho do portfólio ajudam a
determinar ou não a necessidade de ajustes, de modo que recursos importantes não sejam
desperdiçados em projetos que deveriam ser cancelados.
29
3.4 Considerações Finais
As decisões da Gerência de Portfólio devem seguir as metas e os objetivos do portfólio
de projetos, assim como os critérios e condições consideradas para a seleção dos projetos.
Estas metas, objetivos, critérios e condições são estipulados pela alta administração da
organização, visando sempre manter a estratégia de negócios da empresa.
A Gerência de Portfólio é a ligação entre estratégia corporativa e a operação
organizacional, ajudando a determinar a combinação exata de projetos simultâneos e o correto
nível de investimento em cada um deles.
Além disso, a gestão de portfólio pode também oferecer um repositório de informações
sobre projetos, permitindo o acompanhamento e a auditoria do andamento e resultados dos
projetos, facilitando a captura das lições aprendidas com as decisões estratégicas adotadas no
passado.
Sendo assim, a sistematização da Gerência de Portfólio de Projetos, através do uso de
ferramentas que possuam este propósito, é essencial para as organizações poderem realizar
todas as etapas que uma eficiente gestão de portfólio exige.
30
4 APOIO SISTEMATIZADO À GERÊNCIA DE PORTFÓLIO
Este capítulo descreve a proposta deste trabalho, que visa inicialmente apresentar o
Projeto SPIDER, que deu origem a este objeto de pesquisa, e em seguida a proposta de
sistematização da Gerência de Portfólio do MPS.Br. A descrição do SPIDER justifica a
escolha de ferramentas livres para alcançar os resultados esperados, e nas seções seguintes é
esclarecida a escolha de cada ferramenta que dará tal suporte a este objetivo, além de
apresentar as melhorias necessárias para atender a todos os resultados esperados do processo
GPP.
4.3 O Projeto SPIDER
O projeto de pesquisa intitulado “SPIDER: Uma Proposta de Solução Sistêmica de um
SUITE de Ferramentas de Software Livre de apoio à implementação do modelo MPS.Br”
nasceu em 2008, no Instituto de Ciências Exatas e Naturais (ICEN) da Universidade Federal
do Pará (UFPA), em parceria com o Centro de Informática (CIN) da Universidade Federal do
Pernambuco (UFPE) e com o Departamento de Estatística e Informática (DEINFO) da
Universidade Federal Rural de Pernambuco (UFRPE) [OLIVEIRA, 2008].
O objetivo do projeto é apresentar alternativas viáveis para auxiliar a implementação
dos processos do MPS.Br, através do apoio de ferramentas livres, agilizando o processo de
implementação do modelo de qualidade e reduzindo custos para as organizações, que não
necessitam fazer aquisição de ferramentas proprietárias, além de terem a liberdade de
customizarem as mesmas de acordo com suas necessidades. Estas vantagens são evidenciadas
e discutidas nos relatórios de “Resultados de Desempenho das organizações que adotaram o
modelo MPS” [SOFTEX, 2008b] e de “Lições Aprendidas do MPS.Br” [SOFTEX, 2008a].
Neste contexto, o projeto SPIDER tem, como uma das principais metas, realizar um
levantamento de ferramentas de software livre que possibilitem a criação de produtos de
trabalho (artefatos que evidenciam a implementação do programa de qualidade
organizacional) derivados dos resultados esperados descritos nos objetivos das áreas de
processo, inicialmente, dos níveis de maturidade G (parcialmente gerenciado) e F
(gerenciado) do MPS.Br [OLIVEIRA, 2008].
31
A partir deste levantamento, pretende-se definir um SUITE de ferramentas, com a
intenção de fazer uso integrado das funções/operações disponibilizadas, realizando a
implantação das áreas de processo do modelo MPS.Br, em aderência ao fluxo de dependência
proposto por este modelo de qualidade de processo [OLIVEIRA, 2008].
Dentro do Projeto SPIDER, foram definidos subprojetos referentes a: (1) levantamento
de ferramentas e definição de metodologias de apoio sistematizado para atender aos
resultados esperados de cada processo dos níveis de maturidade F e G do MPS.Br, e (2)
propostas de integração para os processos dos referidos níveis [SPIDER, 2009]. Este trabalho
surge do subprojeto homônimo a esta monografia.
4.4 Ferramentas de Apoio
Gerência de Portfólio é um conceito relativamente novo e seus requisitos são pouco
disseminados entre as ferramentas disponíveis no mercado. Desta forma, não existem
aplicações bem elaboradas e adequadas para atender aos resultados esperados que tenham
sido desenvolvidas para este propósito e disponibilizadas de forma open source.
Sendo assim, como o Projeto SPIDER se propõe a utilizar apenas ferramentas livres em
seu SUITE e algumas destas, já adotadas para atender a outros processos do MPS.Br,
possuíam características que poderiam dar este suporte à Gerência de Portfólio, foram
definidas melhorias e modificações nesses softwares a fim de que as mesmas passem a dar o
suporte exigido para a implantação do GPP de acordo com o modelo MPS.Br.
Devido à estreita relação entre a Gerência de Projetos e a Gerência de Portfólio, o
dotProject [DOTPROJECT, 2005], uma das ferramentas que dão suporte ao GPR no âmbito
do Projeto SPIDER, foi definido para sofrer tais modificações para atender também ao GPP.
Além desta aplicação, também identificou-se a possibilidade de utilizar ferramentas de
bugtracking para atender alguns requisitos específicos de um dos resultados esperados do
GPP. Este tipo de ferramenta é largamente utilizado na Gerência de Configuração, onde o
Mantis [MANTIS, 2000] é o software utilizado pelo Projeto SPIDER em seu SUITE. Assim
sendo, o Mantis também agregará responsabilidades para dar o suporte necessário ao GPP.
Por fim, como a Gerência de Portfólio possui em sua principal característica dar suporte
as decisões estratégicas de acordo com critérios objetivos, uma ferramenta de checklist torna-
32
se necessária para complementar as anteriormente citadas. Como outros processos também se
beneficiam do uso de uma ferramenta de checklist, desenvolveu-se a Spider-CL [SPIDER,
2009] para atender as demandas do Projeto SPIDER.
4.4.1 dotProject
O dotProject trata-se de uma ferramenta baseada na web, que permite a centralização
dos dados de um projeto. Assim, os requisitos necessários para implantá-la são: servidor web
Apache ou Microsoft IIS, linguagem de programação PHP integrada ao servidor web e uma
base SQL, como o MySQL ou PostGreSQL. A versão estável mais atual desta ferramenta é a
2.1.2.
Esta ferramenta destina-se ao gerenciamento e controle de projetos, ideal para situações
onde o foco é a agenda de tarefas dos membros da equipe, sendo possível informar aos
usuários do sistema suas associações com as tarefas do projeto através de email ou mensagens
pop-ups, reforçando o comprometimento da equipe. Além disso, a ferramenta é capaz de
fornecer dados referentes à apropriação de horas trabalhadas de cada um dos recursos
humanos envolvidos nas tarefas.
4.4.2 Mantis
O Mantis é uma ferramenta de bugtracking, sob licença GPL, desenvolvido para
auxiliar o controle de modificações através do gerenciamento dos issues. Issues são relatos de
problemas identificados nos produtos de trabalho, que terão sua evolução acompanhada desde
a solicitação da mudança até seu desfecho.
Por ser um software executado em browser, ele independe de sistema operacional e sua
base de dados pode ser estruturada em MySQL, MS SQL e PostgreSQL. A sua versão mais
recente e estável é a versão 1.1.8, mas atualmente está sendo desenvolvida a versão 1.2.0rc2.
Entre as principais funcionalidades desta ferramenta são identificados: criação de
issues; gerenciamento do ciclo de vida dos issues; registro do histórico das issues; e controle
de workflow da ferramenta. Outros aspectos marcantes são: a possibilidade de customização;
interface amigável, proporcionando fácil utilização; e a facilidade de extensão através de
plugins.
33
4.4.3 Spider-CL
É uma ferramenta web, que pode ser executada através de servidor Tomcat, sendo
acessível de qualquer navegador web, e seu banco de dados é estruturado em MySQL. Conta
com serviço de controle de acesso através de cadastro de usuários e provê a sistematização do
processo de definição e aplicação de checklists para avaliação, inspeção ou revisão através de
critérios objetivos. A interface da Spider-CL foi desenvolvida utilizando componentes
gráficos convencionais como caixas de textos, tabelas, listas e botões, para permitir fácil
utilização [BARROS, 2009].
A ferramenta Spider-CL é marcada pelas seguintes características:
• É uma ferramenta gratuita;
• É portável, sendo desenvolvida como uma aplicação para o servidor Tomcat. A
ferramenta pode ser executada em qualquer servidor capaz de executar o Tomcat
6.0 e o MySQL 5.1;
• Possui uma interface de fácil utilização;
• Pode ser utilizada para o desenvolvimento de qualquer tipo de checklist objetivo;
• Possui controle de acesso e mantém registro de todas as utilizações de cada
checklist;
• Exporta os checklists preenchidos e seus resultados para o formato PDF.
4.5 Mapeamento das Ferramentas com os Resultados Esperados
Como exposto na seção anterior, três ferramentas pertencentes ao SUITE do Projeto
SPIDER foram escolhidas para buscar atender a todos os resultados esperados da Gerência de
Portfólio do Modelo MPS.Br. Entretanto, estas ferramentas não foram desenvolvias para este
propósito, sendo necessárias algumas modificações para que estas de forma conjunta possam
contemplar todos os requisitos necessários para dar suporte aos resultados esperados do
processo GPP.
34
A Figura 4.1 ilustra o mapeamento das ferramentas relacionando aos respectivos
resultados esperados que estas atendem.
Figura 4.1 - Tabela de mapeamento dos resultados esperados com as ferramentas
De posse do resultado deste mapeamento, fica evidente a necessidade de customização
para que a Gerência de Portfólio seja de fato contemplada no Projeto SPIDER, haja vista que
apenas um Resultado Esperado está totalmente implementado, enquanto os outros não
possuem todos os seus requisitos atendidos.
Os detalhes do mapeamento relacionando cada GPP as suas respectivas ferramentas
utilizadas estão discutidos nas seções a seguir.
4.5.1 GPP1: Parcialmente Implementado ( dotProject e Spider-CL )
Para atender este resultado esperado do ponto de vista ferramental, é necessário oferecer
a funcionalidade de registrar as oportunidades de negócio previamente identificadas, além de
mecanismos de avaliação por meio de critérios objetivos. O dotProject em conjunto com a
Spider-CL atendem parte destes requisitos.
A Spider-CL torna-se a ferramenta responsável por avaliar cada oportunidade de
negócio. Através dela é possível criar os critérios objetivos que irá avaliar e gerar um
resultado absoluto para fomentar um ranking das melhores oportunidades identificadas.
No dotProject é possível cadastrar novos projetos e transitá-lo entre diferentes status.
Os status possíveis para um projeto registrado são: Não Definido; Proposto; Em
Planejamento; Em Execução; Em Espera; Completo; e Arquivado. Sendo “Não Definido” a
categoria estabelecida para projetos cadastrados que ainda não possuem informações
35
suficientes ou expectativas para serem planejados. Em “Proposto” estão listados os projetos
que serão analisados a fim de iniciar um planejamento caso seja de interesse da organização.
Para o status “Planejamento”, são atribuídos os projetos que estão sendo planejados para
entrar em produção. “Em Execução” é o status que engloba todos os projetos que estão sendo
executados naquele momento pela organização. A categoria “Em Espera” é atribuída aos
projetos que já foram planejados, mas estão aguardando recursos ou decisões para entrar em
produção. O status “Completo” é o que lista todos os projetos anteriormente executados com
sucesso. “Arquivado” é o status definido para os projetos que por algum motivo não puderam
ser concluídos.
Desta forma, seria possível registrar uma nova oportunidade como um projeto e
transferi-lo entre os status existentes de acordo com a aprovação ou não desta oportunidade de
negócio.
Porém, nesta ferramenta não existe um status específico que possua esta finalidade,
além disso, é necessário que sejam visualizadas estas oportunidades juntamente com o
resultado de sua avaliação, de forma que um ranking mostrando as melhores oportunidades
seja definido.
Com a inexistência destas peculiaridades, o GPP1 foi considerado Parcialmente
Implementado e se fazem necessárias modificações nas ferramentas escolhidas de forma que
atenda por completo este resultado esperado. Estas modificações foram definidas e serão
propostas na seção seguinte.
4.5.2 GPP2: Não Implementado
Este resultado esperado pode ser atendido através de uma visualização de recursos
disponíveis em todos os projetos, com suas respectivas alocações, de forma que, ao atribuir
um recurso a um projeto, não haja conflitos.
Nenhuma das ferramentas disponíveis no SUITE propõe-se a atender esta necessidade,
categorizando, então, este GPP como Não Implementado. Sendo assim, no tópico mais
adiante, propõe-se modificações na ferramenta dotProject para atender tais necessidades.
36
4.5.3 GPP3: Parcialmente Implementado ( dotProject )
Este resultado esperado caracteriza-se por exigir das ferramentas utilizadas suporte à
identificação e alocação dos Líderes de Projeto.
O dotProject possui características que se propõem a esta finalidade, haja vista que, para
cada projeto, é necessário alocar um líder para o mesmo. Porém, esta ferramenta não oferece
suporte para a identificação do indivíduo mais adequado para assumir tal compromisso, visto
que os recursos humanos cadastrados no sistema não possuem informações sobre suas
características profissionais.
Sendo assim, esta ferramenta não contempla todos os requisitos necessários para
atender o resultado esperado, classificando-o como Parcialmente Implementado. Desta forma,
posteriormente serão tratadas propostas para atender tais requisitos.
4.5.4 GPP4: Totalmente Implementado ( Mantis )
De acordo com a descrição deste resultado esperado, é preciso uma ferramenta que
auxilie no registro e acompanhamento das soluções de conflitos identificados entre os
recursos compartilhados entre projetos.
Sendo assim, a ferramenta mais adequada, pertencente ao SUITE, para buscar atender a
este resultado esperado, é a ferramenta de bugtracking Mantis. Como visto na Figura 4.1, que
ilustra o mapeamento entre as ferramentas e os resultados esperados, este resultado esperado é
completamente atendido através desta ferramenta.
Como para este resultado esperado a necessidade é apenas de uma adequada
metodologia de uso da ferramenta escolhida, classificou-se este resultado esperado como
Totalmente Implementado.
4.5.5 GPP5: Parcialmente Implementado ( dotProject e Spider-CL )
Este resultado esperado exige avaliações periódicas de todos os projetos em andamento,
de forma que os resultados de tais avaliações dêem subsídios ao processo de decisão sobre o
prosseguimento ou não destes projetos, de acordo com a estratégia de negócio da instituição.
37
Além disso, todo o histórico e resultados destas avaliações devem ser mantidos
juntamente com o registro da decisão tomada após cada avaliação executada.
Assim, como para dar suporte ao GPP1, a ferramenta Spider-CL poderá ser utilizada
para promover o processo de avaliações periódicas e o dotProject poderá armazenar todas as
informações relevantes de cada avaliação, bem como o histórico das mesmas e as decisões
tomadas.
Entretanto, o dotProject não está preparado para suprir tal necessidade e modificações
se fazem necessárias para utilizá-lo em tal objetivo. Sendo assim, devido as necessidades de
mudanças no sistema dotProject, classificou-se este resultado esperado como Parcialmente
Implementado ao utilizar as ferramentas escolhidas: dotProject e Spider-CL. Propostas que
tendem suprir as necessidades citadas serão apresentadas a seguir.
4.6 Melhorias Propostas para as Ferramentas de Apoio
Para atender a todos os resultados esperados previstos na Gerência de Portfólio do
Modelo MPS.Br, o Projeto SPIDER promoveu uma série de customizações das ferramentas
de seu SUITE para buscar respeitar todos o requisitos exigidos.
Desta forma, todas as ferramentas que não atenderam por completo ou sequer
atenderam parte dos requisitos exigidos pelo respectivo resultado esperado, devem sofrer
customizações a fim de permitir que estas possam respeitar a todos os requisitos necessários.
De tal modo que, a partir da implementação adequada destes novos serviços a estas
ferramentas, o Projeto SPIDER possa contemplar a Gerência de Portfólio do Modelo MPS.Br.
Sendo assim, o dotProject será a ferramenta que sofrerá tais modificações, a fim de
alcançar os requisitos que ainda não foram contemplados pelas ferramentas escolhidas para
este objetivo. Estas propostas serão discutidas nas seções a seguir de acordo com cada
resultados esperado que a mesma visa atender.
4.6.1 GPP1
Como explicitado no detalhamento do mapeamento, o dotProject possui um conjunto de
status que podem ser atribuídos aos projetos registrados. Desta forma, se faz necessária a
38
criação de um novo status denominado “Negócios”, onde deverão ser registradas, como
projetos, todas as oportunidades de negócio identificadas.
Além disso, nesta nova aba criada devem ser exibidas informações sobre o resultado da
avaliação de cada uma destas oportunidades, realizada através da ferramenta Spider-CL como
ilustra a Figura 4.2, bem como a posição no ranking das melhores oportunidades
identificadas. Estas modificações citadas foram instanciadas e podem ser visualizadas na
Figura 4.3.
Figura 4.2 - Avaliação da oportunidade através da ferramenta Spider-CL
39
Figura 4.3 – Protótipo para atender aos requisitos do GPP1
Também, a decisão tomada após a avaliação destas oportunidades deve ser realizada
através da própria ferramenta, onde as opções disponíveis para a alta administração são:
Aprovado; Arquivado; e Em Análise. Como mostra a Figura 4.4.
Figura 4.4 - Protótipo para atender aos requisitos do GPP1
“Aprovado” é o status na qual a alta administração decide por em prática a
oportunidade de negócio identificada. Caso o resultado da avaliação da oportunidade não seja
satisfatório, a alta gestão da empresa define o status da oportunidade como “Arquivado”,
porém esta mesma oportunidade pode sofrer avaliações futuras onde esse status pode ser
mudado. Durante o período em que não é definido se a oportunidade de negócio entra em
produção ou não, o status dela permanecerá “Em Análise” até que a mesma seja avaliada.
40
4.6.2 GPP2
Para este resultado esperado ser atendido, se faz necessária a criação de uma
visualização de todos os recursos disponíveis juntamente com a alocação dos mesmos entre os
diferentes projetos, levando-se em consideração evitar conflitos no compartilhamento desses
recursos.
Para isto, propõe-se uma tabela de Recursos x Projeto onde cada célula seria preenchida
pelo número de horas alocada daquele Recurso para o respectivo Projeto, como é apresentado
na Figura 4.4. Sendo que esta tabela será criada dinamicamente a partir de um período
passado pelo usuário através do preenchimento dos campos específicos para este fim.
Figura 4.5 - Protótipo para atender aos requisitos do GPP2
Vale ressaltar que a criação desta tabela em tempo de execução é possível, haja vista
que, de acordo com o período passado pelo usuário, é possível enviar diferentes consultas
para o banco de dados, adicionando ainda, se necessário, cálculos sobre as informações
existentes através desta mesma consulta.
Além das informações contidas na relação entre Recursos x Projeto, foi acrescentada a
tabela mais duas colunas e uma linha. A primeira coluna denominada “Tempo Total” deve
aparecer ao lado dos recursos identificando em suas células o total de horas que aquele
recurso possui no período especificado. A outra denomina-se “Tempo Ocioso”, que deve ser
apresentada como última coluna onde em cada célula deve constar a diferença entre o Tempo
Total e a soma das horas alocadas em cada Projeto. A linha adicional deve ser exibida no fim
41
da tabela e será denominada “Orçamento”, onde o cruzamento entre Orçamento e Projeto
deve ser preenchido com o valor total dos gastos de todos os Recursos alocados para tal
Projeto.
4.6.3 GPP3
Para completar o suporte a este resultado esperado, poucas mudanças no dotProject
devem ser implementadas. É necessário oferecer suporte à identificação e alocação de Líderes
para os Projetos.
Haja vista que o dotProject já possui a funcionalidade de alocar um líder para o Projeto,
se faz necessário adicionar ao registro de Recursos Humanos campos destinados a
“Competências” e “Habilidades” do indivíduo cadastrado como mostra a Figura 4.5.
Figura 4.6 - Protótipo para atender aos requisitos do GPP3
4.6.4 GPP5
Assim como no GPP1, onde criou-se uma nova aba denominada “Negócios” na área de
Projetos, para atender o GPP5, propõe-se a criação de uma nova aba denominada “Avaliação
de Execução”.
42
A partir desta aba, todos os projetos que já passaram pela etapa de execução devem ser
listados juntamente com informações sobre o resultado da última avaliação e seu status atual,
como pode ser visualizado na Figura 4.6. Nos detalhes do Projeto, um guia denominado
“Avaliação” deve ser acrescentado, onde deve conter o histórico das avaliações com as
respectivas decisões tomadas a partir delas, como mostra a Figura 4.7.
Figura 4.7 - Protótipo para atender aos requisitos do GPP5
Figura 4.8 - Protótipo para atender aos requisitos do GPP5
Nesta aba, também, para a alta administração, deve possibilitar eleger a decisão que será
tomada de acordo com a última avaliação, onde as possibilidades serão: Manter, Parar e
Cancelar.
43
O status “Manter” deve ser selecionado pela alta gerência quando o feedback da
avaliação for positivo e esta decidir dar prosseguimento ao projeto. Entretanto, se existirem
outras prioridades de acordo com a estratégia de negócios da empresa, a alta gestão pode
“Parar” o projeto, tendo a possibilidade de retomá-lo posteriormente em um momento mais
adequado. Caso a avaliação do projeto neste momento indique a inviabilidade do projeto, é
possível ”Cancelar” o projeto, sendo que esta decisão não permite retomar o mesmo
futuramente. Vale ressaltar que, enquanto uma decisão não for tomada, o status permanecerá
“Em Análise”.
4.7 Considerações Finais
O Projeto SPIDER visa atender aos níveis G e F do MPS.Br de forma eficiente e
principalmente a baixo custo, o que justifica a utilização de ferramentas livres em seu SUITE.
Para este trabalho foram estudadas as ferramentas que já integravam o SUITE do Projeto
SPIDER a fim de buscar alternativas para contemplar a Gerência de Portfólio.
Tendo em vista que não existem ferramentas destinadas a atender todos os requisitos
exigidos nos resultados esperados disponíveis de forma open source, utilizou-se o dotProject
e o Mantis como base, além do desenvolvimento de uma ferramenta de checklist denominada
Spider-CL, para buscar este objetivo.
Um mapeamento entre estas ferramentas e os resultados esperados foi realizado, a fim
de identificar as customizações necessárias que deveriam ser implementadas. Desta forma,
propostas de modificações foram descritas resultando na criação de um protótipo apresentado
no capítulo a seguir juntamente com a metodologia de uso destas ferramentas para alcançar os
seus objetivos.
44
5 METODOLOGIA DE IMPLEMENTAÇÃO
De acordo com a análise realizada no Capítulo 4, definiu-se as ferramentas que devem
ser utilizadas para atender aos Resultados Esperados do Processo de Gerência de Portfólio de
Projetos. Sendo assim, as organizações interessadas em aplicar a proposta deste trabalho
devem instalar tais ferramentas e fazer uso das mesmas de maneira adequada.
Desta forma, elaborou-se um guia de instalação de cada uma destas aplicações e as
Políticas de Uso das mesmas, para que as organizações interessadas em implementar as
propostas definidas possam utilizar como base para sua implantação.
5.3 Instalação das Ferramentas
Como definido no Capítulo 4, três ferramentas foram selecionadas para atender os
requisitos exigidos pelo processo de Gerência de Portfólio de Projetos do Modelo MPS.Br.
Cada uma destas ferramentas é instalada de forma independente, onde o guia de instalação
abaixo pode ser seguido para o sucesso deste procedimento.
5.3.1 Instalação do dotProject
Esta é uma ferramenta web, que depende de outros serviços para a sua execução. Dentre
os requisitos mínimos para a utilização desta ferramenta se encontram um servidor web,
Apache ou Microsoft IIS, com suporte a Linguagem de programação PHP e um banco de
dados MySQL ou PostGreSQL ativo.
Todas as propostas do Capítulo 4 apresentadas, foram definidas levando-se em
consideração a versão 2.1.2 do dotProject. Desta forma, a instalação desta ferramenta segue o
as recomendações de instalação desta versão.
Inicialmente, deve-se extrair os arquivos do dotProject dentro do diretório virtual raiz
do servidor web, que é definido na instalação do servidor. Feito isso, através do browser
deve-se acessar a página install do dotProject a partir do nome do domínio local, geralmente
“http://localhost/dotproject/install”. Em seguida, deve-se preencher a página que aparecerá
com as informações pertinentes à instalação do banco de dados selecionado, informando
dados como, tipo do SGBD – Sistema Gerenciador de Banco de Dados, login, senha e nome
45
da base de dados, clicando no botão “upgrade db & write cfg” para finalizar a instalação. Por
último, deve-se acessar a página principal da ferramenta, geralmente em
http://localhost/dotproject, e realizar login no dotproject (por padrão, o login é admin e a
senha é passwd).
5.3.2 Instalação do Spider-CL
Assim como o dotProject, o Spider-CL depende de alguns serviços para ser executado
corretamente. Para a utilização desta ferramenta, por ser desenvolvida em Java, é necessário
um servidor web com suporte a esta tecnologia, como o Tomcat (recomenda-se a utilização do
Tomcat 6.0 ou superior). Além do Tomcat, é requerido também a instalação de uma base de
dados do MySQL 5.1.
Inicialmente deve-se configurar o banco de dados existente com os requisitos da
aplicação. Desta forma, é necessário a execução de duas instruções sql para o MySQL. Onde
a primeira é responsável por criar uma base de dados denominada “spider_cl”. E a segunda
cria um usuário “spider_cl” identificado pela senha “spider_cl”, além de atribuir todos os
privilégios necessários para este usuário, que será utilizado pela aplicação para efetuar as
modificações nas tabelas utilizadas nesta base.
CREATE DATABASE spider_cl;
GRANT ALL PRIVILEGES ON spider_cl.* TO 'spider_cl'@'localhost'
IDENTIFIED BY 'spider_cl';
O banco de dados deve estar configurado para ser acessado pela porta 3306, de forma
que a url para acessá-lo seja localhost:3306/spider_cl. Com estas configurações realizadas,
deve-se publicar o arquivo WAR da ferramenta Spider-CL através do Tomcat. Feito isto, a
ferramenta encontra-se disponível para acesso com o usuário padrão “admin” e a senha vazia.
5.3.3 Instalação do Mantis
Seguindo o modelo das duas ferramentas anteriores, esta também é uma ferramenta
web, e possui requisitos semelhantes para o seu correto funcionamento. É necessário um
servidor web disponível, Apache ou Microsoft IIS, com suporte a Linguagem de programação
PHP e um banco de dados MySQL ou PostGreSQL ativo.
46
A versão utilizada pela metodologia de uso sugerida é a 1.1.8 por ser a versão estável
mais atual. Desta forma, o guia de instalação a seguir está relacionado a esta versão.
Primeiramente é necessário descompactar o diretório do Mantis dentro do local
destinado à publicação de páginas web do servidor web. Em seguida, acessar a página de
configuração da base de dados, através do link http://localhost/mantisbt/admin/install.php,
onde “localhost” pode ser substituído pelo endereço IP (Internet Protocol) do servidor web
que abriga a aplicação.
Está é uma página de criação das tabelas que serão utilizadas pela ferramenta, deve-se
preencher os campos exigidos e clicar no botão referente a iniciar o processo de criação. Feito
isto, se faz necessário criar um arquivo denominado “config_inc.php” com as informações de
acesso ao banco de dados e variáveis referente aos e-mails utilizados pela aplicação. Abaixo
segue um exemplo de como estas informações devem estar dispostas:
$g_hostname = 'localhost';
$g_db_type = 'mysql';
$g_database_name = 'bugtracker';
$g_db_username = 'mantisadm';
$g_db_password = 'senha';
# --- variáveis de e-mail -------------
$g_administrator_email = '[email protected]';
$g_webmaster_email = '[email protected]';
# Campo "De" do e-mail
$g_from_email = '[email protected]'';
# Endereço de retorno do e-mail
$g_return_path_email = '[email protected]'';
Com todas as configurações necessárias realizadas, pode-se acessar a aplicação através
do link http://localhost/mantisbt e utilizar o login “administrator” e senha “root”.
5.4 Políticas de Uso
Este tópico destina-se a descrever a metodologia de uso de cada ferramenta relacionada
ao processo de GPP na qual esta busca atender. Sendo assim, a descrição do uso detalhado de
todas as funcionalidades de tais ferramentas encontra-se disponível em seus respectivos
47
manuais disponibilizados em seus sites [DOTPROJECT, 2005], [SPIDER, 2009] e [MANTIS,
2000].
Deste modo, para cada resultado esperado do processo de GPP existe uma política de
uso da ferramenta, de forma que atenda aos requisitos necessários do Resultado Esperado em
questão. Vale ressaltar, que estas políticas estão relacionadas ao uso das funcionalidades
propostas no Capítulo 4, onde é apresentado um protótipo que visa suprir as necessidades que
estas ferramentas não atendem.
5.4.1 GPP1: dotProject e Spider-CL
Para atender este resultado esperado se faz necessário a utilização de duas ferramentas,
o dotProject e o Spider-CL. Inicialmente é preciso registrar as oportunidades de negócio
identificadas no dotProject, para isso deve-se acessar a seção “Projetos” e clicar no botão
“novo projeto” como mostra o local em destaque na Figura 5.1.
Figura 5.1 - Criação de um novo projeto no dotProject
Será apresentado um formulário onde se deve preencher os dados referentes à
oportunidade de negócio em questão. Dois campos são muito importantes para esta etapa, o
status do projeto, que deve ser definido como “Negócios”, e a Metodologia de Avaliação, que
deve ser preenchida com o link referente ao arquivo que contém a metodologia para avaliar a
oportunidade de negócio. Ambos os campos estão destacados na Figura 5.2 identificados
como os itens 1 e 2.
48
Figura 5.2 - Criação de um novo projeto no dotProject
Esta metodologia de avaliação é um artefato organizacional, não é do escopo desta
pesquisa a elaboração e definição de um modelo para tal metodologia. Entretanto, esta
metodologia deve seguir apenas critérios objetivos e oferecer como resultado um valor
absoluto entre 0 e 100.
Feito o cadastro da oportunidade, esta deve ser avaliada utilizando a ferramenta Spider-
CL seguindo a metodologia de avaliação estabelecida. Para isto, deve-se criar um novo
checklist que estará associado aos critérios objetivos estabelecidos na metodologia de
avaliação. Após a criação deste checklist, criam-se cada um dos critérios necessários e os
associam ao checklist inicialmente criado. Com o modelo de avaliação definido, se faz uso do
mesmo através da ferramenta e após este processo, utiliza-se a metodologia de avaliação para
obter o resultado absoluto oriundo da avaliação em questão.
Todos os passos citados nesta etapa do procedimento estão descritos detalhadamente no
manual da ferramenta que se encontra disponível em [SPIDER, 2009].
De posse do valor absoluto, se faz necessário editar as informações da oportunidade de
negócios registrada, adicionando o valor referente ao resultado da avaliação realizada. Para
isto, deve-se entrar nos detalhes do projeto e acessar “editar projeto” e, em seguida, preencher
49
o campo “Resultado da Avaliação” com o valor obtido. O campo a ser preenchido está
destacado na Figura 5.2 identificado como item 3, apesar desta imagem se referir ao cadastro
de um novo projeto, o formulário de edição é equivalente.
Neste instante, o registro da oportunidade de negócio encontra-se realizado. Todas as
oportunidades registrada e avaliadas podem ser visualizadas no guia “Negócios” do menu
“Projeto”, que lista de maneira ordenada as oportunidades, como é possível visualizar na
Figura 4.2. Nesta lista também consta a decisão tomada pela alta gerência da organização
sobre cada oportunidade, onde as oportunidades ainda não analisadas possuem o status de
“Em Análise”.
Para a alta administração definir uma atitude em relação a uma oportunidade de negócio
avaliada, deve-se entrar nos detalhes do projeto e no guia denominado “Avaliação” constará o
resultado da avaliação realizada e as opções de análises disponíveis. É possível “Aprovar” ou
“Arquivar” uma oportunidade, marcando um dos combobox equivalentes e clicar no botão de
“Confirmar Análise”. A Figura 4.3 ilustra esta etapa do procedimento.
De acordo com a atitude tomada, o status será modificado automaticamente e a data
desta análise será registrada. Vale ressaltar que estas opções de tomada de decisão estarão
desabilitadas para os usuários que não pertencerem ao grupo de usuários que possuem este
privilégio.
5.4.2 GPP2: dotProject
Como destacado no Capítulo 4, este resultado esperado não é atendido por nenhuma das
ferramentas estudadas. Entretanto, elaborou-se um protótipo a ser implementado sobre a
ferramenta dotProject que torne a ferramenta aderente aos requisitos deste Resultado
Esperado.
Sendo assim, os recursos cadastrados possuem informações de horas disponíveis para
alocação de tarefas por dia, além de informações do custo de sua utilização por hora e se estão
disponíveis para uso de maneira concorrente entre projetos.
A partir destas informações, no guia “Recursos” da seção de “Projetos” é apresentado
uma tabela contendo a relação Recursos x Projeto, além do “Tempo Total” e o “Tempo
Ocioso” que cada recurso dispõe. Ainda na mesma tabela, é acrescentada uma linha contendo
50
os custos totais de cada Projeto que é conseguido através da soma dos custos por hora de cada
recurso alocado ao Projeto respectivo.
Todas estas informações servem de subsídio para a identificação dos recursos alocados
para cada Projeto, bem como os seus orçamentos. Esta tabela é criada dinamicamente
utilizando o período passado pelo usuário, de forma que o resultado apresentado se refere
somente a este período, sendo possível aplicar filtros sobre recursos onde será apresentado
somente o recurso selecionado. A Figura 4.4 ilustra a utilização desta funcionalidade a ser
desenvolvida sobre a ferramenta dotProject para buscar atender ao resultado esperado GPP2.
5.4.3 GPP3: dotProject
Para atender este resultado esperado, a ferramenta deve disponibilizar informações para
a alta gerência da organização sobre cada um dos funcionários existentes capazes de exercer a
função de Líder do Projeto. Informações estas que devem ser preenchidas no ato de registrar
um novo recurso humano, nos campos “Habilidades” e “Competências” que são apresentados
na Figura 4.5.
Desta forma, ao visualizar os detalhes de um usuário específico, será possível identificar
se este possui os requisitos necessários para assumir a responsabilidade de Líder do Projeto.
Após a identificação do responsável pelo projeto, deve-se editar as informações do mesmo
incluindo no campo “Responsável pelo Projeto” o usuário em questão. Com isto,
estabelecendo e comunicando a autoridade pelo Projeto.
5.4.4 GPP4: Mantis
Para a ferramenta Mantis atender ao resultado esperado GPP4 não se faz necessárias
modificações na mesma. Sendo apenas recomendada uma adequada metodologia de uso para
que os requisitos exigidos neste Resultado Esperado sejam atendidos.
Esta ferramenta é utilizada para rastrear e acompanhar a resolução de problemas ou
conflitos. Sendo assim, os conflitos entre recursos, que podem ser identificados no resultado
da aplicação da metodologia de uso definido ao resultado esperado GPP2, devem ser
registrados na ferramenta Mantis, como ilustra a Figura 5.3, onde os responsáveis por tais
Projetos envolvidos no conflito serão notificados e estes devem buscar a solução mais
adequada para a organização para a resolução do problema.
51
Figura 5.33 - Criação de uma issue no Mantis
Deste modo, deve-se criar um Projeto destinado à resolução de problemas do processo
de GPP no Mantis denominado “Gerência de Portfólio” e em seguida um subprojeto deste
denominado “Recursos”. Os Líderes de Projetos estarão associados ao subprojeto “Recurso”,
onde todo novo relato de caso entre conflito de recursos, que deve ser realizado pelo Gerente
de Negócios da organização, os Líderes dos Projetos envolvidos devem ser notificados e a
busca da solução do problema será acompanhada pela ferramenta.
Os procedimentos de criação de projetos e subprojetos, bem como a criação de novos
casos, notificação de usuários e acompanhamento da resolução do problema, podem ser
visualizados na manual da ferramenta disponível em [MANTIS, 2000].
5.4.5 GPP5: dotProject e Spider-CL
Para atender a este resultado esperado, novamente se faz necessário o uso de duas
ferramentas: dotProject e Spider-CL. A metodologia de uso empregada sobre elas é
semelhante a já apresentada para o resultado esperado GPP1, haja vista que ambos os
Resultados Esperados possuem procedimentos equivalentes.
Juntamente com as revisões de marcos do Projeto, devem ser aplicadas as avaliações de
execuções de projetos. A lista contendo os projetos em execução e suas respectivas avaliações
52
mais recentes pode ser visualizada através do menu “Projetos” no guia “Avaliação de
Execução”, como é apresentado na Figura 4.6. Estas avaliações devem seguir a Metodologia
de Avaliação disponível nos detalhes do Projeto.
Utiliza-se a ferramenta Spider-CL para aplicar a avaliação objetiva do projeto, assim
como descrito para o resultado esperado GPP1. Após a aplicação do checklist, utiliza-se da
metodologia de avaliação disponível para obter o resultado absoluto da avaliação e registrar
tal resultado na ferramenta dotProject.
Estas avaliações devem ser registradas no guia “Avaliação” que pode ser visualizado
através dos detalhes do projeto, como ilustra a Figura 4.7. Neste local, estará disponível o
histórico de avaliações realizadas, e as respectivas decisões tomadas pela alta gerência
valendo-se destes resultados.
A cada avaliação, a alta gestão tem a possibilidade de tomar decisões sobre o
andamento do Projeto, onde as opções disponíveis são: Manter, Parar e Cancelar. De acordo
com a decisão tomada, o status deste projeto pode sofrer alterações para “Em Espera” ou
“Arquivado” se a decisão for “Parar” ou “Cancelar”, ou permanecer o mesmo caso o projeto
seja mantido. Vale ressaltar que estas opções estão habilitadas somente para os usuários que
possuem privilégios suficientes para tomar as referidas decisões.
5.5 Considerações Finais
As ferramentas dotProject, Mantis e Spider-CL foram selecionadas de acordo com suas
características para atender a todos os Resultados Esperados da Gerência de Portfólio do
Modelo MPS.Br. Com isto, a instalação e configuração destas se faz necessária para obter os
resultados exigidos por este processo.
Além disso, uma eficaz metodologia de uso sobre as ferramentas deve ser aplicada,
tendo em vista que somente com uma utilização adequada será possível extrair das
ferramentas o potencial exigido por cada resultado esperado do processo de GPP para
respeitar os requisitos requeridos.
Entretanto, as políticas de uso estão vinculadas às funcionalidades apresentadas como
protótipos no Capítulo 4, haja vista que estas ferramentas só podem atender aos requisitos
exigidos com a implementação das propostas elaboradas.
53
Sendo assim, a implementação das funcionalidades propostas anteriormente é de suma
importância para que estas ferramentas open source sejam capazes de desempenhar os
serviços citados na metodologia de uso, e o seu manuseio adequado irá satisfazer a todos os
Resultados Esperados da Gerência de Portfólio de Projetos no âmbito do MPS.Br.
54
6. CONCLUSÃO
Este capítulo apresentará um resumo de todo o trabalho desenvolvido, seguido dos
resultados obtidos, trabalhos futuros e as lições aprendidas.
6.3 Resumo
Para uma sistematização do Processo de Gerência de Portfólio de Projetos do MPS.Br, é
necessário o auxílio de ferramentas que, com uma metodologia de uso adequada, facilite a
execução deste processo. Sendo assim, analisaram-se no mercado as opções de aplicações
disponíveis com o código aberto que pudessem oferecer tal auxílio, haja vista que uma das
premissas do Projeto SPIDER é utilizar somente ferramentas open source.
Deste modo, constatou-se que não existem atualmente no mercado ferramentas de
código aberto que objetivam suprir as necessidades de uma Gerência de Portfólio. Sendo
assim, foram escolhidas três ferramentas que mais se adequavam aos requisitos necessários e,
posteriormente, propostos ajustes nas mesmas, de forma que pudessem implementar os
serviços necessários para contemplar os requisitos restantes.
Juntamente com os ajustes, definiu-se uma metodologia de uso sobre as ferramentas
escolhidas: dotProject, Mantis e Spider-CL. Seguindo esta metodologia, todos os cinco
Resultados Esperados exigidos pela Gerência de Portfólio de Projetos do Modelo MPS.Br
serão atendidos, viabilizando, então, alcançar o nível F de maturidade, no que diz respeito à
Gerência de Portfólio.
6.4 Resultados Obtidos
O trabalho desenvolvido atendeu a sua finalidade e os resultados desejados foram
alcançados de forma satisfatória. Entre os resultados obtidos encontram-se:
• Análise de cada resultado esperado do processo de GPP, de forma que foram
identificadas as características necessárias para uma ferramenta atender a cada
um destes Resultados Esperados;
• Uma análise das ferramentas escolhidas e a justificativa destas serem as mais
adequadas para o que se propõe;
55
• Um mapeamento entre as características das ferramentas escolhidas e os
requisitos dos Resultados Esperados da Gerência de Portfólio de Projetos do
MPS.Br;
• Propostas de ajustes na ferramenta dotProject, de forma que atenda as
necessidades que não estão contempladas nas ferramentas escolhidas;
• Elaboração de uma metodologia de uso sobre as ferramentas dotProject, Mantis
e SPIDER-CL, que em conjunto contemplam todas as necessidades para uma
Gerência de Portfólio de Projetos aderente ao MPS.Br.
6.5 Trabalhos Futuros
Com base no desenvolvimento deste trabalho, destacam-se pontos que serão estudados e
desenvolvidos posteriormente:
• Implementação dos ajustes propostos na ferramenta dotProject;
• Elaboração de uma Metodologia de Avaliação de oportunidades de negócio, que
gere um resultado absoluto;
• Aplicação da metodologia proposta em uma organização, a fim de promover um
estudo de caso que irá viabilizar uma análise dos resultados gerados.
6.6 Lições Aprendidas
Durante todo o processo de desenvolvimento deste trabalho, ficou evidente a enorme
vantagem de se seguir um processo de desenvolvimento de software bem definido. O MPS.Br
é a melhor opção para as micro, pequenas e médias empresas que desejam estar concorrendo
as melhores oportunidades de negócio nacional e internacionalmente.
O estudo da Gerência de Portfólio de Projetos possibilitou visualizar, de forma
abrangente, que a estratégia de negócios de uma empresa deve estar bem definida, para que os
seus projetos estejam sempre de acordo com o desejado. Além disso, que os projetos não
podem ser executados de forma independente, sempre deve haver avaliações para valorizar os
projetos prioritários, os que estão mais próximos da estratégia da empresa.
56
Referências Bibliográficas
[ABNT, 1994] ABNT (Associação Brasileira de Normas Técnicas), NBR ISSO
8402/1994 – Gestão da Qualidade e Garantia da Qualidade, Terminologia,
Brasil, 1994.
[ABNT, 2001] ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS.
NBR ISO 9000:2000 – Sistemas de gestão da qualidade e garantia da
qualidade – Fundamentos e Vocabulário. Rio de Janeiro: ABNT, 2001.
[ARCHER & GHASEMZADEH, 1999] ARCHER, N. P.; GHASEMZADEH, F. An
integrated framework for project portfolio selection, 1999.
[BARROS, 2009] BARROS, Renan S., Manual do Usuário – SPIDER CL – Versão 1.2,
2009.
[CRAWFORD, 2002] CRAWFORD, J. K. The Strategic Project Office: a guide to
improving organizational performance, 2002.
[DOTPROJECT, 2005] Homepage da ferramenta dotProject, <www.dotproject.net>.
Último acesso em: 23/11/09.
[ISO10006, 1997] International Standard Organization - ISO 10006: Quality management -
Guidelines to quality in project management, 1997.
[ISO/IEC, 2003] International Organization For Standardization/ International
Electrotechnical Comission. ISO/IEC 15504-2: Information Technology -
Process Assessment – Part 2 - Performing an Assessment, Geneve: ISO,
2003.
[ISO/IEC, 2004a] International Organization For Standardization/ International
Electrotechnical Comission. ISO/IEC 15504-1: Information Technology -
Process Assessment – Part 1 - Concepts and Vocabulary, Geneve: ISO,
2004.
[ISO/IEC, 2004b] International Organization For Standardization/ International
Electrotechnical Comission. ISO/IEC 15504-3: Information Technology -
Process Assessment - Part 3 - Guidance on Performing an Assessment,
Geneve: ISO, 2004.
[ISO/IEC, 2004c] International Organization For Standardization/ International
Electrotechnical Comission. ISO/IEC 15504-4: Information Technology -
57
Process Assessment – Part 4 - Guidance on use for Process Improvement
and Process Capability Determination, Geneve: ISO, 2004.
[ISO/IEC, 2006] International Organization For Standardization/ International
Electrotechnical Comission. ISO/IEC 15504-5: Information Technology -
Process Assessment - Part 5: An exemplar Process Assessment Model,
Geneve: ISO, 2006.
[ISO/IEC, 2008] International Organization For Standardization/ International
Electrotechnical Comission. ISO/IEC 12207 Systems and software
engineering– Software life cycle processes, Geneve: ISO, 2008.
[KENDALL & ROLLINS, 2003] KENDALL, G. I.; ROLLINS, S. C. Advanced Project
Portfolio Management and PMO Multiplying ROI, 2003.
[KERZNER, 2005] KERZNER, H. Strategic Planning for a Project Office, 2005.
[MANTIS, 2000] Homepage da ferramenta Mantis, <www.mantisbt.org>. Último acesso
em: 23/11/09.
[MCT, 2002] Ministério da Ciência e Tecnologia - MCT. Relatório MCT – 2001, 2002.
[MIT, 2003] Massachussets Institute of Technology - MIT. Slicing the Knowledge-
Based Economy in Brazil, China and India: a Tale of 3 Software
Industries, 2003.
[OLIVEIRA, 2008] Oliveira, S. R. B., SPIDER: Uma Proposta de um SUITE de
Ferramentas de Software Livre de Apoio à Implementação do MPS.Br,
Projeto Submetido e Aprovado pelo Instituto de Ciências Exatas e
Naturais da UFPA, Belém-PA, 2008.
[PMI, 2008a] Project Management Institute - PMI. A Guide to the Project Management
Body of Knowledge - PMBOK™. Syba: PMI Publishing Division, 2008.
Disponível em: <www.pmi.org>.
[PMI, 2008b] Project Management Institute. The Standard for Portfolio Management.
Syba: PMI Publishing Division, 2008. Disponível (para associados) em:
<www.pmi.org>.
[PMI, 2002] Project Management Institute - PMI. Project manager competence
development (PMCD) framework. Syba: PMI Publishing Division, 2002.
Disponível em: <www.pmi.org>.
58
[PMI, 2003] Project Management Institute - PMI. A Guide to the Organizational
Project Management Maturity Model (OPM3 Guide). Syba: PMI
Publishing Division, 2003. Disponível em: <www.pmi.org>.
[RABECHINI et al, 2005] RABECHINI, R. J.; MAXIMIANO, A. C. A.; MARTINS, V. A.
A adoção de gerenciamento de portfólio como uma alternativa gerencial: o
caso de uma empresa prestadora de serviço de interconexão eletrônica,
2005.
[SEI, 2006] Software Engineering Institute. CMMI for Development (CMMI-DEV),
Version 1.2, Technical Report CMU/SEI-2006-TR-008. Pittsburgh, PA:
Software Engineering Institute, Carnegie Mellon University, 2006.
[SOFTEX, 2008a] Softex - Sociedade para Promoção da Excelência do Software Brasileiro,
MPS.BR: Lições Aprendidas, organizadores: Ana Regina Cavalcanti da
Rocha e Kival Chaves Webes, Campinas-SP, 2008.
[SOFTEX, 2008b] Softex - Sociedade para Promoção da Excelência do Software Brasileiro,
MPS: Resultados de Desempenho de organizações que adotaram o modelo
MPS, organizadores: Guilherme Horta Travassos e Marcos Kalinowski,
Campinas-SP, 2008.
[SOFTEX, 2009a] Associação Para Promoção Da Excelência Do Software Brasileiro –
SOFTEX. MPS.BR – Guia de Avaliação:2009, maio 2009. Disponível
em: www.softex.br.
[SOFTEX, 2009b] Associação Para Promoção Da Excelência Do Software Brasileiro –
SOFTEX. MPS.BR – Guia de Aquisição:2009, maio 2009. Disponível
em: www.softex.br.
[SOFTEX, 2009c] Associação Para Promoção Da Excelência Do Software Brasileiro –
SOFTEX. MPS.BR – Guia de Implementação – Parte 1: Fundamentação
para Implementação do Nível G do MR-MPS:2009, maio 2009.
Disponível em: www.softex.br.
[SOFTEX, 2009d] Associação Para Promoção Da Excelência Do Software Brasileiro –
SOFTEX. MPS.BR – Guia de Implementação – Parte 2: Fundamentação
para Implementação do Nível F do MR-MPS:2009, maio 2009.
Disponível em: www.softex.br.
[SOFTEX, 2009e] Associação Para Promoção Da Excelência Do Software Brasileiro –
SOFTEX. MPS.BR – Guia de Implementação – Parte 3: Fundamentação
59
para Implementação do Nível E do MR-MPS:2009, maio 2009.
Disponível em: www.softex.br.
[SOFTEX, 2009f] Associação Para Promoção Da Excelência Do Software Brasileiro –
SOFTEX. MPS.BR – Guia de Implementação – Parte 4: Fundamentação
para Implementação do Nível D do MR-MPS:2009, maio 2009.
Disponível em: www.softex.br.
[SOFTEX, 2009g] Associação Para Promoção Da Excelência Do Software Brasileiro –
SOFTEX. MPS.BR – Guia de Implementação – Parte 5: Fundamentação
para Implementação do Nível C do MR-MPS:2009, maio 2009.
Disponível em: www.softex.br.
[SOFTEX, 2009h] Associação Para Promoção Da Excelência Do Software Brasileiro –
SOFTEX. MPS.BR – Guia de Implementação – Parte 6: Fundamentação
para Implementação do Nível B do MR-MPS:2009, maio 2009.
Disponível em: www.softex.br.
[SOFTEX, 2009i] Associação Para Promoção Da Excelência Do Software Brasileiro –
SOFTEX. MPS.BR – Guia de Implementação – Parte 7: Fundamentação
para Implementação do Nível A do MR-MPS:2009, maio 2009.
Disponível em: www.softex.br.
[SOFTEX, 2009j] Associação Para Promoção Da Excelência Do Software Brasileiro –
SOFTEX. MPS.BR – Guia de Implementação – Parte 8: Implementação
do MR-MPS:2009 em organizações que adquirem software, versão em
elaboração.
[SOFTEX, 2009k] Associação Para Promoção Da Excelência Do Software Brasileiro –
SOFTEX. MPS.BR – Guia de Implementação – Parte 9: Implementação
do MR-MPS:2009 v 2.0 em organizações do tipo Fábrica de Software, em
elaboração.
[SOFTEX, 2009l] Associação Para Promoção Da Excelência Do Software Brasileiro –
SOFTEX. MPS.BR – Guia de Implementação – Parte 10: Implementação
do MR-MPS:2009 em organizações do tipo Fábrica de Teste, em
elaboração.
[SOFTEX, 2009m] Associação Para Promoção Da Excelência Do Software Brasileiro –
SOFTEX. MPS.BR – Guia Geral:2009, maio 2009. Disponível em
www.softex.br.
60
[SPIDER, 2009] Homepage do projeto de pesquisa SPIDER, <www.ufpa.br/spider>.
Último acesso em: 23/11/09.
[SOUZA et al, 2009] SOUZA, A. D.; ROCHA, A. R.; SANTOS, G.; CARMO, T. V. P.;
ALEXANDRE, D. B. Uma Abordagem para Gerência Estratégica de
Portfólio com Foco na Seleção de Projetos, 2009.
[TUMAN, 1983] TUMAN, G. J. Development and Implementation of Effective Project
Management Information and Control Systems, 1983.
[WEBER, 1994] WEBER, Kival C. et al, Modelo de Referência para Melhoria de Processo
de Software: uma abordagem brasileira, Conferência Latinoamericana de
Informática – CLEI, Arequipa-Peru, 2004.
[YELIN, 2007] YELIN, K.C. Linking strategy and Project Portfolio Management, 2007.
