TCC Paulojunior 2009

UNIVERSIDADE FEDERAL DO PAR INSTITUTO DE CINCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAO CURSO DE BACHARELADO EM CINCIA DA COMPUTAO TRABALHO DE CONCLUSO
DE CURSO
Paulo Fernando Souza Rodrigues Jnior
UMA PROPOSTA DE APOIO SISTEMATIZADO GERNCIA DE PORTFLIO DO MPS.BR
Trabalho de Concluso de Curso para obteno do grau de Bacharel em Cincia da Computao Orientador: Prof. Dr. Sandro Ronaldo Bezerra Oliveira
Belm 2009
UNIVERSIDADE FEDERAL DO PAR INSTITUTO DE CINCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAO CURSO DE BACHARELADO EM CINCIA DA COMPUTAO TRABALHO DE CONCLUSO DE CURSO
Paulo Fernando Souza Rodrigues Jnior
UMA PROPOSTA DE APOIO SISTEMATIZADO GERNCIA DE PORTFLIO DO MPS.BR

Data da defesa: ____/____/____ Conceito: ____________ Banca Examinadora
Prof. Dr. Sandro Ronaldo Bezerra Oliveira Faculdade de Computao/UFPA Orientador
Prof. Dr. Ricardo Andr Cavalcante de Souza Faculdade de Computao/UFPA Membro
Prof. Dr. Dionne Cavalcante Monteiro Faculdade de Computao/UFPA Membro Belm 2009
AGRADECIMENTOS
minha querida me, Ana Clis, pelo carinho, incentivo e amor durante todos os momentos. Ao meu irmo, Lucas Domires, por ser paciente e compreensivo nos momentos difceis. Aos meus amigos pela ajuda e momentos de descontrao. 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 incio no sucesso deste trabalho, e dedicou-se ao mximo para dar todo o suporte necessrio aos seus orientandos do Projeto SPIDER. E, em especial, Deus, por toda a fora e apoio espiritual alcanados durante a minha vida. Paulo Rodrigues Jnior
Falta de tempo desculpa daqueles que perdem tempo por falta de mtodos. Albert Einstein
RESUMO
Com o aumento das exigncias pela qualidade das aplicaes desenvolvidas, o mercado tem buscado empresas que sigam processos de desenvolvimento de softwares bem definidos. No Brasil, o modelo MPS.Br tem alcanado grande visibilidade entre as organizaes desenvolvedoras, haja vista que o seu custo de implantao muito menor que o de modelos como o CMMI. Sendo assim, o Projeto SPIDER foi idealizado com o intuito de promover a aderncia das organizaes aos nveis de maturidade G e F do Modelo MPS.Br. Em maio de 2009, a Gerncia de Portflio de Projetos foi inserida no MPS.Br como sendo um dos processos exigidos do nvel F de maturidade. Apesar de estar sendo debatido nos ltimos anos, este um conceito novo e que poucas ferramentas implementam servios que atendem as exigncias deste processo. Como no foram identificadas aplicaes que objetivavam suprir as necessidades da Gerncia de Portflio, foram propostos ajustes no dotProject que visam implementar os servios necessrios. 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 Gerncia de Portflio do Modelo MPS.Br sero atendidos, viabilizando ento, alcanar no nvel F de maturidade.
PALAVRAS-CHAVE: Melhoria do Processo, Qualidade do Software, Modelos de Melhoria, MPS.Br, Ferramentas de Software, Gerncia de Portflio.
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 werent 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 Managements 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.
SUMRIO
Introduo ..................................................................................................................................... 12 1.1 1.2 1.3 1.4 Contexto ................................................................................................................................ 12 Justificativa ........................................................................................................................... 12 Motivao .............................................................................................................................. 13 Objetivos ............................................................................................................................... 13 Geral .............................................................................................................................. 13 Especfico ...................................................................................................................... 14
1.4.1 1.4.2 1.5 1.6 2
Metodologia .......................................................................................................................... 14 Estrutura ................................................................................................................................ 14
MPS.Br .......................................................................................................................................... 16 2.1 2.2 2.3 2.4 2.5 Histrico do MPS.Br ............................................................................................................. 16 Definio e Composio do Modelo MPS.Br ....................................................................... 17 Nveis de Maturidade do MPS.Br ......................................................................................... 19 Guias do MPS.Br................................................................................................................... 20 Consideraes Finais ............................................................................................................. 21
Processo de Gerncia de Portflio................................................................................................. 22 3.1 3.2 3.3 Gerncia de Portflio ............................................................................................................ 22 Gerncia de Portflio no MPS.Br ......................................................................................... 24 Anlise dos Resultados Esperados ........................................................................................ 26
3.3.1 GPP1 - As oportunidades de negcio, as necessidades e os investimentos so identificados, qualificados, priorizados e selecionados. ................................................................ 26 3.3.2 GPP 2 - Os recursos e oramentos para cada projeto so identificados e alocados. ..... 27
3.3.3 GPP 3 - A responsabilidade e autoridade pelo gerenciamento dos projetos so estabelecidas. ................................................................................................................................. 27 3.3.4 GPP 4 - Os conflitos sobre recursos entre projetos so tratados e resolvidos. .............. 27
3.3.5 GPP 5 - Projetos que atendem aos acordos e requisitos que levaram sua aprovao so mantidos, e os que no atendem so redirecionados ou cancelados.............................................. 28 3.4 Consideraes Finais ............................................................................................................. 29
Apoio Sistematizado Gerncia de Portflio ............................................................................... 30 4.3 4.4 O Projeto SPIDER................................................................................................................. 30 Ferramentas de Apoio ........................................................................................................... 31 dotProject ...................................................................................................................... 32 Mantis ............................................................................................................................ 32 Spider-CL ...................................................................................................................... 33
4.4.1 4.4.2 4.4.3 4.5
Mapeamento das Ferramentas com os Resultados Esperados ............................................... 33 GPP1: Parcialmente Implementado ( dotProject e Spider-CL ) .................................... 34 GPP2: No Implementado ............................................................................................. 35 GPP3: Parcialmente Implementado ( dotProject )......................................................... 36 GPP4: Totalmente Implementado ( Mantis ) ................................................................ 36 GPP5: Parcialmente Implementado ( dotProject e Spider-CL ) .................................... 36
4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 4.6
Melhorias Propostas para as Ferramentas de Apoio.............................................................. 37 GPP1 ............................................................................................................................. 37 GPP2 ............................................................................................................................. 40 GPP3 ............................................................................................................................. 41 GPP5 ............................................................................................................................. 41
4.6.1 4.6.2 4.6.3 4.6.4 4.7 5
Consideraes Finais ............................................................................................................. 43
Metodologia de Implementao .................................................................................................... 44 5.3 Instalao das Ferramentas.................................................................................................... 44 Instalao do dotProject ................................................................................................ 44 Instalao do Spider-CL ................................................................................................ 45 Instalao do Mantis...................................................................................................... 45
5.3.1 5.3.2 5.3.3 5.4
Polticas de Uso ..................................................................................................................... 46 GPP1: dotProject e Spider-CL ...................................................................................... 47 GPP2: dotProject ........................................................................................................... 49 GPP3: dotProject ........................................................................................................... 50 GPP4: Mantis ................................................................................................................ 50 GPP5: dotProject e Spider-CL ...................................................................................... 51
5.4.1 5.4.2 5.4.3 5.4.4 5.4.5
5.5 6.
Consideraes Finais ............................................................................................................. 52
Concluso ...................................................................................................................................... 54 6.3 6.4 6.5 6.6 Resumo .................................................................................................................................. 54 Resultados Obtidos................................................................................................................ 54 Trabalhos Futuros.................................................................................................................. 55 Lies Aprendidas ................................................................................................................. 55
Referncias Bibliogrficas .................................................................................................................... 56
LISTA DE FIGURAS
Figura 2.1 - Modelo de Negcio para melhoria de processo de software (MN mps) [Weber, 2004] ... 18 Figura 2.2 - Definio do Modelo de Referncia [Weber, 2004].......................................................... 19 Figura 2.3 - Nveis de Maturidade do MPS.Br [SOFTEX, 2009m] ...................................................... 20 Figura 4.1 - Tabela de mapeamento dos resultados esperados com as ferramentas.............................. 34 Figura 4.2 - Avaliao da oportunidade atravs da ferramenta Spider-CL ........................................... 38 Figura 4.3 - Prottipo para atender aos requisitos do GPP2 ................................................................. 39 Figura 4.4 - Prottipo para atender aos requisitos do GPP2 ................................................................. 39 Figura 4.5 - Prottipo para atender aos requisitos do GPP2 ................................................................. 40 Figura 4.6 - Prottipo para atender aos requisitos do GPP3 ................................................................. 41 Figura 4.7 - Prottipo para atender aos requisitos do GPP5 ................................................................. 42 Figura 4.8 - Prottipo para atender aos requisitos do GPP5 ................................................................. 42 Figura 5.1 - Criao de um novo projeto no dotProject ........................................................................ 47 Figura 5.2 - Criao de um novo projeto no dotProject ....................................................................... 48 Figura 5.3 - Criao de uma issue no Mantis ........................................................................................ 51
Lista de Tabelas
Tabela 3.1 - Processo gerencial para criao do gerenciamento de portflio, adaptada de Crawford, 2002 [RABECHINI et al, 2005]............................................................................................................ 24
12
1 INTRODUO
Neste captulo ser apresentado o contexto no qual este trabalho est inserido, a justificativa e os objetivos desta pesquisa, bem como a motivao que a originou, a metodologia utilizada e a estrutura deste trabalho.
1.1 Contexto
Com o aumento das exigncias pela qualidade das aplicaes 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 alcanado grande visibilidade entre as organizaes desenvolvedoras, haja vista que o seu custo de implantao 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 nveis de maturidade, onde as empresas definem em que nvel desejam ser avaliadas. Para atender aos requisitos exigidos em cada nvel, as organizaes se baseiam em guias elaborados para este fim, onde existem informaes detalhadas de como atender a cada um dos Resultados Esperados.
1.2 Justificativa
A crescente demanda por produtos e servios de alta qualidade para suprir o aumento da competitividade e concorrncia 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 atravs da implantao do MPS.Br. O MPS.Br se prope a ser um guia evolucionrio para o aperfeioamento e adequao de processos organizacionais orientados para a excelncia no desenvolvimento de software. Apostando num custo acessvel, especialmente para micro, pequenas e mdias empresas, e na aproximao com a realidade do mercado brasileiro, ele aderente a ISO/IEC 12207, a srie de normas ISO/IEC 15504 e ao modelo CMMI. Com metas ousadas e uma slida estrutura de pesquisa, fomentada por Universidades e pelo Ministrio da Cincia e Tecnologia, o modelo est entrando nas empresas brasileiras de maneira constante e incremental, conforme planejado.
13
O padro de qualidade MPS.Br descreve o qu deve ser feito para melhoria gradual de processos, definindo nveis de maturidade que so organizados por reas de processo, os quais possuem objetivos alcanados pelos chamados Resultado Esperados. Para tanto, faz-se necessria a utilizao de ferramentas de software para possibilitar a implantao do MPS.Br nas organizaes. Com o intuito de alavancar pesquisas na sistematizao do MPS.Br, o Projeto SPIDER foi idealizado para apresentar um levantamento de ferramentas de software livre com caractersticas adequadas para possibilitar a criao de produtos de trabalhos derivados dos Resultados Esperados, descritos nos objetivos das reas de Processo, dos nveis de maturidade G e F do modelo MPS.Br. Este trabalho tratar especificamente da rea de Processo de Gerncia de Portflio. A Gerncia de Portflio de Projetos (GPP) foi inserida recentemente, maio de 2009, nos requisitos para avaliao do Nvel F. Com isso, se faz necessrio o estudo de uma metodologia para implementao deste processo de forma eficaz. De acordo com a proposta do Projeto SPIDER, sero utilizadas ferramentas livres para dar suporte as necessidades desta metodologia, buscando alcanar os Resultados Esperados do MPS.Br em relao a Gerncia de Portflio.
1.3 Motivao
A Gerncia de Portflio uma rea pouco explorada entre os consultores de implementao do MPS.Br, haja vista que foi inserida recentemente no Nvel F, o que agrega um crescente valor ao seu estudo, alm de possibilitar ao Projeto SPIDER contemplar na totalidade os nveis G e F do MPS.Br. Soma-se a isso o interesse pessoal pela Gerncia de TI (Tecnologia da Informao), onde a experincia como pesquisador do Projeto SPIDER, mais especificamente do estudo da Metodologia de Implantao da Gerncia de Portflio, trar tal benefcio.
1.4 Objetivos
1.4.1 Geral Definir uma metodologia eficaz para a implementao da Gerncia de Portflio, alcanando todos os Resultados Esperados pelo MPS.Br em relao a este processo, bem como definir os ajustes necessrios s ferramentas escolhidas para atender os requisitos exigidos e, alm disso, elaborar um prottipo contemplando os ajustes propostos.
14
1.4.2 Especfico

Descrever a gerncia de Portflio no contexto do MPS.Br Definir uma metodologia que:

o
Identifique, qualifique, priorize e selecione as oportunidades de negcio, as necessidades e os investimentos; Identifique e organize os recursos e oramentos para cada projeto; Estabelea a responsabilidade e autoridade pelo gerenciamento dos projetos; Trate e resolva os conflitos sobre recursos entre projetos; Mantenha projetos que atendem aos acordos e requisitos que levaram sua aprovao, e redirecione ou cancele os que no atendem;
o o o o
Rastrear as caractersticas que j so suportadas por meio da implementao das ferramentas de software livres propostas nos demais sub-projetos do Projeto SPIDER; Definir os ajustes necessrios s ferramentas escolhidas de tal modo que possam oferecer todos os servios exigidos pelos Resultados Esperados do processo de GPP; Elaborar um prottipo 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 bibliogrfica de reas relacionadas, atravs de livros, artigos, Trabalhos de Concluso de Curso e revistas. Para comprovar a eficincia da proposta elaborada no decorrer deste trabalho, foi realizada uma pesquisa experimental, onde foram executadas verificaes sobre a proposta de forma que esta seja avaliada sobre os Resultados Esperados da Gerncia de Portflio de Projetos do Modelo MPS.Br. Alm disso, foi aplicado o mtodo da induo, onde foram estudados certos casos de portflio de projetos, e, partindo de suas caractersticas, foi possvel entender a estrutura necessria para ser definida uma metodologia para implementao da Gerncia de Portflio de Projeto respeitando os requisitos solicitados no MPS.Br.
1.6 Estrutura
Alm deste captulo introdutrio, a organizao desta monografia foi feita da seguinte forma.
15
O captulo 2 tem por objetivo explicar a Melhoria de Processo de Software Brasileiro, as justificativas de sua criao, sua composio e seus guias. O captulo 3 direciona suas informaes Gerncia de Portflio, conceituando-a de maneira mais ampla e contextualizando este processo dentro do Modelo MPS.Br, detalhando cada um de seus Resultados Esperados. O captulo 4 apresenta o Projeto SPIDER, no qual este trabalho de pesquisa est inserido, alm de justificar a escolha das ferramentas utilizadas para o auxlio da implementao deste processo e apresentar o mapeamento destas com os Resultados Esperados, bem como os ajustes propostos. O captulo 5 apresenta o procedimento de instalao das ferramentas escolhidas e a metodologia de uso a ser aplicada de modo que os Resultados Esperados da Gerncia de Portflio de Projetos sejam atendidos de maneira eficiente. O captulo 6 apresenta a concluso do trabalho proposto, comentando os resultados obtidos, propostas para trabalhos futuros e as lies aprendidas com esta pesquisa.
16
2 MPS.BR
Criado pela Associao Brasileira para Promoo da Exportao de Software (SOFTEX), o Modelo MPS.Br (Melhoria do Processo de Software Brasileiro) objetiva:
Definir e aprimorar um modelo de melhoria e avaliao de processo de software, visando preferencialmente as micro, pequenas e mdias empresas, de forma a atender as suas necessidades de negcio e ser reconhecido nacional e internacionalmente como um modelo aplicvel indstria de software [SOFTEX, 2009m].
2.1 Histrico do MPS.Br

Ao longo da dcada de 80, o mercado para informtica direcionou seu foco de forma intensa para a produo de hardware e desenvolvimento de microeletrnica, em detrimento a indstria de software [MCT, 2002]. Sendo assim, para buscar o equilbrio 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 Ministrio da Cincia e Tecnologia criou o que viria a se tornar um dos programas prioritrios na rea de informtica, o Programa Nacional de Software para Exportao (Programa SOFTEX 2000). Em 1996 o Governo passou a gesto do Programa SOFTEX para o setor privado, considerando e encaminhando os objetivos iniciais do programa. A Sociedade SOFTEX, uma organizao no governamental e sem fins lucrativos, atua, desde ento, como sua gestora. Em 2001, a SOFTEX contava com cerca de mil empresas associadas aos 19 Ncleos Regionais e 18 Centros SOFTEX GENESIS, espalhados por 12 estados da federao, das quais 850 so empresas maduras e 150 start-ups. O faturamento dessas empresas em 2000 foi de cerca de R$ 2 bilhes (aproximadamente um tero do faturamento total da indstria de software no Pas) e suas exportaes totalizaram cerca de US$ 100 milhes. Em parceria com o Banco Nacional do Desenvolvimento (BNDES), foi criado tambm o Prosoft, para estimular a competitividade dessa indstria em nvel internacional. Com essas aes, as empresas de software se desenvolveram e se habilitaram a desempenhar papel relevante na construo da Sociedade da Informao no Brasil [MCT, 2002].
17
Entretanto, as empresas de software no Brasil priorizavam seus esforos 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 necessrio um esforo 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 Ministrio da Cincia e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP), do Servio Brasileiro de Apoio s Micro e Pequenas Empresas (SEBRAE) e do Banco Interamericano de Desenvolvimento (BID), lanou o programa MPS.Br para soluo deste problema. Os propsitos do MPS.Br compreendem dois desafios, o primeiro seria a criao e o aprimoramento do modelo MPS e o segundo a disseminao e adoo deste modelo em todas as regies do pas a um custo razovel.
2.2 Definio e Composio do Modelo MPS.Br

A implementao e avaliao de modelos como o Capability Maturity Model Integration (CMMI) [SEI, 2006] at mesmo nos seus nveis mais baixos est fora do alcance da grande massa de micro, pequenas e mdias empresas especialmente no Brasil e pases latino-americanos devido ao seu custo elevado. Com isso, o MPS.Br baseou-se na elaborao de dois modelos: o Modelo de Referncia para melhoria de processo de software (MR-MPS) e o Modelo de Negcio para melhoria de processo de software (MN MPS). Para atingir a sua meta de atender principalmente micro, pequenas e mdias empresas, o MN MPS prev duas situaes para a implementao do MR-MPS: de forma personalizada para uma empresa (MNE Modelo de Negcio Especfico); e de forma cooperada em grupos de empresas (MNC Modelo de Negcio Cooperado), com custo mais acessvel por dividir proporcionalmente parte dos custos entre as empresas e por se buscar outras fontes de financiamento [WEBER, 2004]. Existem instituies credenciadas para a implementao do MR-MPS e a realizao de avaliaes segundo o Modelo MPS.Br. O Frum de Credenciamento e Controle (FCC) o responsvel pelo credenciamento, onde a SOFTEX assina um convnio com as instituies credenciadas tornando-as Instituies Credenciadas para Implementao (ICI ou II) ou Instituies Credenciadas para Avaliao (ICA ou IA).
18
No MNE a empresa interessada na implementao do MR-MPS busca uma das II e assina um contrato especfico. Caso deseje ser avaliada, a empresa interessada deve negociar e assinar um contrato especfico com uma das IA. A Sociedade SOFTEX toma conhecimento do contrato e dos resultados da implementao e/ou avaliao da empresa interessada atravs da II ou IA contratada. O Modelo de Negcio do MPS.Br ilustrado na Figura 2.1.
Figura 2.1 - Modelo de Negcio para melhoria de processo de software (MN mps) [Weber, 2004]
No MNC, primeiramente deve ser constitudo um grupo de empresas interessadas na implementao do MR-MPS. A coordenao do grupo dever ento negociar e assinar um contrato com uma das II do MR-MPS. Aps a implementao, ir negociar e assinar um contrato com uma das IA do MR-MPS. Nesta situao, a Sociedade SOFTEX toma conhecimento dos resultados da implementao e/ou avaliao atravs da ICI ou ICA contratada pelo grupo, e assina um convnio com a entidade organizadora do grupo, que pode ser um Agente SOFTEX. O MPS.Br no objetiva criar Normas e Modelos de Maturidade, busca ser inovador na sua estratgia de implementao, que prioriza se adequar realidade das empresas brasileiras. Sendo assim, modelos, normas e mtodos j disponveis formaram a base para a definio do Modelo de Referncia [Weber, 2004], como ilustra a Figura 2.2.
19
Figura 2.2 - Definio do Modelo de Referncia [Weber, 2004]
A definio do MR-MPS partiu da anlise da realidade das empresas brasileiras, a norma ISO/IEC 12207 [ISO/IEC, 2008], a srie 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 Referncia foi definido com sete nveis de maturidade e constitudo, tambm, por uma srie de guias para auxiliar as empresas interessadas em sua implementao, assim como as II e as IA.
2.3 Nveis de Maturidade do MPS.Br

O desempenho de uma empresa ao executar um ou mais processos pode ser previsto ao verificar o nvel de maturidade no qual se encontra esta organizao. Os sete nveis de maturidade, que so uma combinao entre processos e sua capacidade, definidos pelo MRMPS so: A (Em Otimizao), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A evoluo da empresa nos nveis de maturidade se d a partir do nvel G at o nvel A, onde a progresso da organizao atravs desses nveis representa a sua evoluo na implementao dos processos previstos em cada um deles. O nvel de maturidade obtido quando so atendidos os propsitos e todos os Resultados Esperados dos respectivos processos, bem como os Resultados Esperados dos atributos de processo estabelecidos para o respectivo nvel [SOFTEX, 2009m].
20
A Figura 2.3 ilustra os Processos e Atributos de Processo requeridos em cada nvel de maturidade.
Figura 2.3 - Nveis de Maturidade do MPS.Br [SOFTEX, 2009m]
O objetivo desta diviso considerando mais nveis de maturidade, em relao ao CMMI, para possibilitar uma implementao e avaliao adequada para as micro, pequenas e mdias empresas, possibilitando tambm 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 Aquisio, Guia de Avaliao e Guia de Implementao, explicados a seguir [SOFTEX, 2009m].
21
Guia Geral: contm a descrio geral do modelo MPS e detalha o Modelo de Referncia (MR-MPS), seus componentes e as definies comuns necessrias para seu entendimento e aplicao;
Guia de Aquisio: descreve um processo de aquisio de software e servios correlatos. descrito como forma de apoiar as instituies que queiram adquirir produtos de software e servios correlatos apoiando-se no MR-MPS [SOFTEX, 2009b];
Guia de Avaliao: descreve o processo e o mtodo de avaliao MA-MPS, os requisitos para avaliadores lderes, avaliadores adjuntos e Instituies Avaliadoras (IA) [SOFTEX, 2009a];
Guia de Implementao: srie de dez documentos que fornecem orientaes para implementar nas organizaes os nveis de maturidade descritos no Modelo de Referncia 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 Consideraes Finais

Este captulo apresentou o Modelo MPS.Br, desde a motivao que levou a sua criao pela SOFTEX at a descrio do Modelo de Referncia elaborado. Um dos processos contidos no MPS.Br o Processo de Gerncia de Portflio, que ser abordado mais detalhadamente no captulo a seguir, tendo em vista que este trabalho tem por objetivo apresentar uma proposta de apoio sistematizado a este processo.
22
3 PROCESSO DE GERNCIA DE PORTFLIO

Aps o lanamento da metodologia denominada OPM3 (Organizational Project Management Maturity Model) [PMI, 2003], gerenciamento de portflio se tornou um tema bastante explorado em literaturas sobre projetos. O OPM3 possui estruturas conceituais baseadas em evolues sucessivas que contemplam alm de projetos e programas, os portflios.
3.1 Gerncia de Portflio

Para o correto entendimento da Gerncia de Portflio, primeiramente necessrio absorver a definio de projeto. Na literatura existem algumas definies clssicas para projetos: Um processo nico, consistindo de um grupo de atividades coordenadas e controladas com datas para incio e trmino, empreendido para alcance de um objetivo conforme requisitos especficos, incluindo limitaes de tempo, custo e recursos. [ISO10006, 1997]. Um empreendimento de esforo temporrio feito para criar um produto, servio ou resultado nico. [PMI, 2002].
Um projeto uma organizao de pessoas dedicadas visando atingir um propsito e objetivo especfico. Projetos geralmente envolvem gastos, aes 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 mnimo 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, servios ou resultados nicos e exclusivos, para atender um ou mais objetivos. Desta forma, os objetivos dos projetos devem ser alinhados estratgia da organizao, permitindo que ele seja utilizado como mecanismo para operacionalizao do planejamento estratgico organizacional. possvel, porm, encontrar em diversas empresas exemplos de projetos propostos que no conseguiram atingir os benefcios prometidos. Os exemplos mais comuns so de projetos
23
inadequados, no sincronizados com os objetivos da organizao, com riscos excessivos ou aprovados em decorrncia de fora poltica dos patrocinadores [SOUZA et al, 2009], sugando os recursos que poderiam ser direcionados para projetos que trariam mais benefcios organizao [YELIN, 2007]. Para contornar isto, necessria uma gerncia adequada do projeto para que o mesmo alcance todos os seus objetivos designados. A Gerncia de Projetos tem por objetivos planejar, programar e controlar uma srie de tarefas integradas de forma a atingir, com xito, os objetivos do projeto, para benefcio dos envolvidos [KERZNER, 2005]. O [PMI, 2008a] define gerncia de projetos como sendo a aplicao de conhecimentos, habilidades, ferramentas e tcnicas 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 cenrio ideal. Entretanto, a grande maioria das empresas no vive esta realidade, e a execuo de seus projetos limitada por variveis como tempo, oramento, recursos, entre outras restries, forando-as a limitar o nmero de projetos executados de maneira concorrente. Sendo assim, surge uma nova demanda para as organizaes: avaliar, priorizar e selecionar os projetos candidatos a atender determinados objetivos de forma alinhada estratgia organizacional, ligando s atividades estratgicas, tticas e operacionais [YELIN, 2007]. Com isso, as empresas deixam de empregar grandes esforos em fazer os projetos darem certo e concentram-se na seleo dos projetos certos. Para [ARCHER & GHASEMZADEH, 1999], gerenciamento de portflio uma coleo de projetos que so desenvolvidos sob a administrao de uma unidade organizacional, onde cada projeto pode se relacionar com outros ou ser independente. No entanto, devem fazer parte de objetivos estratgicos determinados e assim buscar recursos na organizao. [KENDALL & ROLLINS, 2003] enfatizam que o gerenciamento de portflio 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 portflio visto como um processo gerencial que guiado pelos passos apresentados na Tabela 3.1.
Tabela 3.1 - Processo gerencial para criao do gerenciamento de portflio, adaptada de Crawford, 2002 [RABECHINI et al, 2005].
3.2 Gerncia de Portflio no MPS.Br

Reconhecendo o valor da disciplina no suporte do sucesso da estratgia organizacional, a SOFTEX, em maio de 2009, integrou ao modelo do MPS.Br o processo de Gerncia de Portflio. Seguindo uma fundamentao terica do Padro de Gerncia de Portflio [PMI, 2008b] que foi disseminado pelo Project Management Institute PMI (reconhecida associao profissional na rea de gerenciamento de projetos), a Gerncia de Portflio de Projetos do MPS.Br foca nas atividades envolvidas no gerenciamento da carteira de projetos da organizao, e no apenas sobre um projeto individualmente. Para o modelo, a governana de um conjunto de projetos realizada de duas formas: selecionando os projetos que devem ser executados; e, uma vez em execuo, avaliando se estes projetos continuam viveis e aderentes aos critrios pelos quais foram aprovados [SOFTEX, 2009d]. Na primeira etapa, o objetivo criar uma combinao de projetos que melhor apie os objetivos da organizao, alinhada com as suas estratgias e com as restries de recursos (pessoas e oramento) [Levine apud SOFTEX, 2009d].
25
Na segunda, o objetivo garantir que, medida que os projetos vo 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 necessrio frente s mudanas no ambiente que podem ocorrer durante a sua execuo, principalmente devido a: Modificaes na composio das necessidades do negcio e da misso em relao s ofertas de produtos e servios; Tendncias da indstria; Mudanas na economia; Demandas dos clientes; Ofertas dos fornecedores; Novas tecnologias; Requisitos legais; Competitividade e/ou business intelligence. Alm disso, tambm previsto o cancelamento ou suspenso de projetos cujos riscos ou desvantagens para a organizao superem os benefcios de se continuar investindo [ISO/IEC, 2008 apud SOFTEX, 2009d]. Todas estas caractersticas so requeridas atravs dos Resultados Esperados do Processo de Gerncia de Portflio de Projetos previsto no Nvel F do MPS.Br: GPP1: As oportunidades de negcio, as necessidades e os investimentos so identificados, qualificados, priorizados e selecionados; GPP2: Os recursos e oramentos para cada projeto so identificados e alocados; GPP3: A responsabilidade e autoridade pelo gerenciamento dos projetos so estabelecidas;
26
GPP4: Os conflitos sobre recursos entre projetos so tratados e resolvidos; GPP5: Projetos que atendem aos acordos e requisitos que levaram sua aprovao so mantidos, e os que no atendem so redirecionados ou cancelados. A organizao que desejar ter uma Gerncia de Portflio aderente ao MPS.Br, deve atender a todos estes Resultados Esperados. Porm, para o MPS.Br, a Gerncia de Portflio de Projetos torna-se opcional quando a nica atividade da unidade organizacional for evoluo de produto, podendo ser considerada fora do escopo da avaliao da empresa.
3.3 Anlise dos Resultados Esperados

Uma anlise detalhada de cada GPP foi realizada a fim de identificar os requisitos necessrios para atender de forma satisfatria cada um dos Resultados Esperados. 3.3.1 GPP1 - As oportunidades de negcio, as necessidades e os investimentos so identificados, qualificados, priorizados e selecionados. O GPP1 descrito no [SOFTEX, 2009d] da seguinte forma:
[...] Inicialmente, as demandas precisam ser identificadas, ou seja, preciso registrlas para que possam ser posteriormente analisadas, com o objetivo de definir se sero iniciadas como projetos ou descartadas. Em seguida as demandas devero ser qualificadas, ou seja, devero ser identificados os atributos que a caracterizam e que sero utilizados como critrios de seleo e priorizao. [...] Selecionar os projetos significa validar sua aderncia aos objetivos organizacionais antes que sejam incorporados ao portflio. Potenciais projetos que estejam mais alinhados com os critrios estabelecidos recebero tratamento prioritrio, enquanto que os demais recebero prioridade menor ou sero at mesmo descartados do portflio. [...] importante ressaltar que este resultado no se refere apenas anlise da viabilidade de um projeto individualmente, mas sim sob a perspectiva mais global, do portflio de projetos e dos objetivos estratgicos da organizao.
Nota-se que o objetivo deste GPP o de maximizar o valor das oportunidades identificadas, atravs da avaliao detalhada para viabilizar a incluso no portflio ou excluso oportuna dos projetos que no esto de acordo com os objetivos estratgicos do portflio. Esta avaliao feita levando-se em considerao aspectos como: rentabilidade dos projetos; riscos associados aos projetos (alto/baixo); tempo de durao (curto/longo);
27
importncia dos clientes (estratgica/financeira); e alinhamento com as estratgias de negcios. Sendo assim, este resultado consiste na obteno de uma coleo de projetos que esto de acordo com os aspectos estratgicos da empresa, oferecendo ento, subsdios para a tomada de deciso baseada em informaes estratgicas e prioridades. 3.3.2 GPP 2 - Os recursos e oramentos para cada projeto so 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 oramento necessrios. [...] No entanto, deve-se, neste momento, analisar os possveis conflitos de alocao de recursos entre os projetos, especialmente aqueles que so considerados crticos. 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 necessrios de acordo com os riscos/rendimentos envolvidos, buscando um equilbrio adequado do portflio com o uso eficiente dos recursos, para evitar o desperdcio causado pela alocao ineficiente destes. 3.3.3 GPP 3 - A responsabilidade e autoridade pelo gerenciamento dos projetos so 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 responsvel pelas atividades de gerenciamento do projeto, ou seja, que exercer o papel de Gerente do Projeto [...] Como o sucesso de um projeto est, tambm, ligado a liderana e capacidade dos indivduos que esto a sua frente, este GPP busca identificar e alocar o indivduo mais capacitado para exercer a funo de Lder de Projeto. 3.3.4 GPP 4 - Os conflitos sobre recursos entre projetos so tratados e resolvidos. Este GPP est descrito da seguinte forma [SOFTEX, 2009d]:
medida que os projetos vo sendo realizados, novos conflitos de recursos podem ser identificados. Os projetos de TI raramente so executados exatamente como o
28
planejado, por diversos motivos [...]. Estes fatores podem afetar a execuo dos projetos do portflio e tambm levar a novos conflitos sobre recursos. [...] Estes conflitos, analisados sob a perspectiva organizacional dos mltiplos projetos em execuo, devem ser registrados, analisados, tratados e resolvidos.
Para uma adequada gesto da carteira de portflio, se faz necessrio um eficaz controle sobre os possveis conflitos que possam surgir entre projetos. Os projetos de TI raramente so executados como planejado, podendo ento ocasionar conflitos sobre recursos utilizados por outro projeto. Alm disso, o desempenho de um projeto pode afetar a execuo de outro projeto do portflio. Este GPP espera solues para a identificao, anlise e soluo destes possveis conflitos, de maneira que reflita as prioridades da organizao para seus investimentos e alocao de recursos. 3.3.5 GPP 5 - Projetos que atendem aos acordos e requisitos que levaram sua aprovao so mantidos, e os que no atendem so redirecionados ou cancelados. Este GPP est descrito da seguinte forma [SOFTEX, 2009d]:
medida que um projeto vai sendo executado, as atividades de monitoramento vo sendo realizadas, de maneira a coletar informaes, na forma de fotos de determinados momentos do projeto, permitindo a atuao do gerente de projetos, quando necessrio. Estas so as atividades relacionadas ao gerenciamento do projeto individualmente, conforme previsto no processo GPR. Porm, todos os projetos possuem riscos que, se confirmados, podem levar o projeto a se desviar de seu plano original, afastando-se da situao que foi levada em considerao quando se determinou a sua aprovao. Neste momento, a empresa precisa analisar se este projeto continua alinhado aos objetivos estratgicos pretendidos, se necessrio algum redirecionamento ou at mesmo se o momento de ser cancelado.
A Gerncia de Portflio do MPS.Br prev o monitoramento e controle dos projetos que esto em andamento, decidindo quais projetos devem continuar e quais projetos devem deixar o portflio. Nota-se, ento, que os projetos em execuo devem sofrer avaliaes peridicas de acordo com os objetivos estratgicos da organizao. A coleta e anlise de dados a fim de avaliar o desempenho do portflio ajudam a determinar ou no a necessidade de ajustes, de modo que recursos importantes no sejam desperdiados em projetos que deveriam ser cancelados.
29

As decises da Gerncia de Portflio devem seguir as metas e os objetivos do portflio de projetos, assim como os critrios e condies consideradas para a seleo dos projetos. Estas metas, objetivos, critrios e condies so estipulados pela alta administrao da organizao, visando sempre manter a estratgia de negcios da empresa. A Gerncia de Portflio a ligao entre estratgia corporativa e a operao organizacional, ajudando a determinar a combinao exata de projetos simultneos e o correto nvel de investimento em cada um deles. Alm disso, a gesto de portflio pode tambm oferecer um repositrio de informaes sobre projetos, permitindo o acompanhamento e a auditoria do andamento e resultados dos projetos, facilitando a captura das lies aprendidas com as decises estratgicas adotadas no passado. Sendo assim, a sistematizao da Gerncia de Portflio de Projetos, atravs do uso de ferramentas que possuam este propsito, essencial para as organizaes poderem realizar todas as etapas que uma eficiente gesto de portflio exige.
30
APOIO SISTEMATIZADO GERNCIA DE PORTFLIO

Este captulo 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 sistematizao da Gerncia de Portflio do MPS.Br. A descrio do SPIDER justifica a escolha de ferramentas livres para alcanar os resultados esperados, e nas sees seguintes esclarecida a escolha de cada ferramenta que dar tal suporte a este objetivo, alm de apresentar as melhorias necessrias para atender a todos os resultados esperados do processo GPP.
4.3 O Projeto SPIDER

O projeto de pesquisa intitulado SPIDER: Uma Proposta de Soluo Sistmica de um SUITE de Ferramentas de Software Livre de apoio implementao do modelo MPS.Br nasceu em 2008, no Instituto de Cincias Exatas e Naturais (ICEN) da Universidade Federal do Par (UFPA), em parceria com o Centro de Informtica (CIN) da Universidade Federal do Pernambuco (UFPE) e com o Departamento de Estatstica e Informtica (DEINFO) da Universidade Federal Rural de Pernambuco (UFRPE) [OLIVEIRA, 2008]. O objetivo do projeto apresentar alternativas viveis para auxiliar a implementao dos processos do MPS.Br, atravs do apoio de ferramentas livres, agilizando o processo de implementao do modelo de qualidade e reduzindo custos para as organizaes, que no necessitam fazer aquisio de ferramentas proprietrias, alm de terem a liberdade de customizarem as mesmas de acordo com suas necessidades. Estas vantagens so evidenciadas e discutidas nos relatrios de Resultados de Desempenho das organizaes que adotaram o modelo MPS [SOFTEX, 2008b] e de Lies 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 criao de produtos de trabalho (artefatos que evidenciam a implementao do programa de qualidade organizacional) derivados dos resultados esperados descritos nos objetivos das reas de processo, inicialmente, dos nveis 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 inteno de fazer uso integrado das funes/operaes disponibilizadas, realizando a implantao das reas de processo do modelo MPS.Br, em aderncia ao fluxo de dependncia proposto por este modelo de qualidade de processo [OLIVEIRA, 2008]. Dentro do Projeto SPIDER, foram definidos subprojetos referentes a: (1) levantamento de ferramentas e definio de metodologias de apoio sistematizado para atender aos resultados esperados de cada processo dos nveis de maturidade F e G do MPS.Br, e (2) propostas de integrao para os processos dos referidos nveis [SPIDER, 2009]. Este trabalho surge do subprojeto homnimo a esta monografia.
4.4 Ferramentas de Apoio

Gerncia de Portflio um conceito relativamente novo e seus requisitos so pouco disseminados entre as ferramentas disponveis no mercado. Desta forma, no existem aplicaes bem elaboradas e adequadas para atender aos resultados esperados que tenham sido desenvolvidas para este propsito e disponibilizadas de forma open source. Sendo assim, como o Projeto SPIDER se prope a utilizar apenas ferramentas livres em seu SUITE e algumas destas, j adotadas para atender a outros processos do MPS.Br, possuam caractersticas que poderiam dar este suporte Gerncia de Portflio, foram definidas melhorias e modificaes nesses softwares a fim de que as mesmas passem a dar o suporte exigido para a implantao do GPP de acordo com o modelo MPS.Br. Devido estreita relao entre a Gerncia de Projetos e a Gerncia de Portflio, o dotProject [DOTPROJECT, 2005], uma das ferramentas que do suporte ao GPR no mbito do Projeto SPIDER, foi definido para sofrer tais modificaes para atender tambm ao GPP. Alm desta aplicao, tambm identificou-se a possibilidade de utilizar ferramentas de bugtracking para atender alguns requisitos especficos de um dos resultados esperados do GPP. Este tipo de ferramenta largamente utilizado na Gerncia de Configurao, onde o Mantis [MANTIS, 2000] o software utilizado pelo Projeto SPIDER em seu SUITE. Assim sendo, o Mantis tambm agregar responsabilidades para dar o suporte necessrio ao GPP. Por fim, como a Gerncia de Portflio possui em sua principal caracterstica dar suporte as decises estratgicas de acordo com critrios objetivos, uma ferramenta de checklist torna-
32
se necessria para complementar as anteriormente citadas. Como outros processos tambm 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 centralizao dos dados de um projeto. Assim, os requisitos necessrios para implant-la so: servidor web Apache ou Microsoft IIS, linguagem de programao PHP integrada ao servidor web e uma base SQL, como o MySQL ou PostGreSQL. A verso estvel mais atual desta ferramenta a 2.1.2. Esta ferramenta destina-se ao gerenciamento e controle de projetos, ideal para situaes onde o foco a agenda de tarefas dos membros da equipe, sendo possvel informar aos usurios do sistema suas associaes com as tarefas do projeto atravs de email ou mensagens pop-ups, reforando o comprometimento da equipe. Alm disso, a ferramenta capaz de fornecer dados referentes apropriao de horas trabalhadas de cada um dos recursos humanos envolvidos nas tarefas. 4.4.2 Mantis O Mantis uma ferramenta de bugtracking, sob licena GPL, desenvolvido para auxiliar o controle de modificaes atravs do gerenciamento dos issues. Issues so relatos de problemas identificados nos produtos de trabalho, que tero sua evoluo acompanhada desde a solicitao da mudana 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 verso mais recente e estvel a verso 1.1.8, mas atualmente est sendo desenvolvida a verso 1.2.0rc2. Entre as principais funcionalidades desta ferramenta so identificados: criao de issues; gerenciamento do ciclo de vida dos issues; registro do histrico das issues; e controle de workflow da ferramenta. Outros aspectos marcantes so: a possibilidade de customizao; interface amigvel, proporcionando fcil utilizao; e a facilidade de extenso atravs de plugins.
33
4.4.3 Spider-CL uma ferramenta web, que pode ser executada atravs de servidor Tomcat, sendo acessvel de qualquer navegador web, e seu banco de dados estruturado em MySQL. Conta com servio de controle de acesso atravs de cadastro de usurios e prov a sistematizao do processo de definio e aplicao de checklists para avaliao, inspeo ou reviso atravs de critrios objetivos. A interface da Spider-CL foi desenvolvida utilizando componentes grficos convencionais como caixas de textos, tabelas, listas e botes, para permitir fcil utilizao [BARROS, 2009]. A ferramenta Spider-CL marcada pelas seguintes caractersticas: uma ferramenta gratuita; portvel, sendo desenvolvida como uma aplicao 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 fcil utilizao; Pode ser utilizada para o desenvolvimento de qualquer tipo de checklist objetivo; Possui controle de acesso e mantm registro de todas as utilizaes 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 seo anterior, trs ferramentas pertencentes ao SUITE do Projeto SPIDER foram escolhidas para buscar atender a todos os resultados esperados da Gerncia de Portflio do Modelo MPS.Br. Entretanto, estas ferramentas no foram desenvolvias para este propsito, sendo necessrias algumas modificaes para que estas de forma conjunta possam contemplar todos os requisitos necessrios 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 customizao para que a Gerncia de Portflio seja de fato contemplada no Projeto SPIDER, haja vista que apenas um Resultado Esperado est totalmente implementado, enquanto os outros no possuem todos os seus requisitos atendidos. Os detalhes do mapeamento relacionando cada GPP as suas respectivas ferramentas utilizadas esto discutidos nas sees a seguir. 4.5.1 GPP1: Parcialmente Implementado ( dotProject e Spider-CL ) Para atender este resultado esperado do ponto de vista ferramental, necessrio oferecer a funcionalidade de registrar as oportunidades de negcio previamente identificadas, alm de mecanismos de avaliao por meio de critrios objetivos. O dotProject em conjunto com a Spider-CL atendem parte destes requisitos. A Spider-CL torna-se a ferramenta responsvel por avaliar cada oportunidade de negcio. Atravs dela possvel criar os critrios objetivos que ir avaliar e gerar um resultado absoluto para fomentar um ranking das melhores oportunidades identificadas. No dotProject possvel cadastrar novos projetos e transit-lo entre diferentes status. Os status possveis para um projeto registrado so: No Definido; Proposto; Em Planejamento; Em Execuo; Em Espera; Completo; e Arquivado. Sendo No Definido a categoria estabelecida para projetos cadastrados que ainda no possuem informaes
35
suficientes ou expectativas para serem planejados. Em Proposto esto listados os projetos que sero analisados a fim de iniciar um planejamento caso seja de interesse da organizao. Para o status Planejamento, so atribudos os projetos que esto sendo planejados para entrar em produo. Em Execuo o status que engloba todos os projetos que esto sendo executados naquele momento pela organizao. A categoria Em Espera atribuda aos projetos que j foram planejados, mas esto aguardando recursos ou decises para entrar em produo. O status Completo o que lista todos os projetos anteriormente executados com sucesso. Arquivado o status definido para os projetos que por algum motivo no puderam ser concludos. Desta forma, seria possvel registrar uma nova oportunidade como um projeto e transferi-lo entre os status existentes de acordo com a aprovao ou no desta oportunidade de negcio. Porm, nesta ferramenta no existe um status especfico que possua esta finalidade, alm disso, necessrio que sejam visualizadas estas oportunidades juntamente com o resultado de sua avaliao, de forma que um ranking mostrando as melhores oportunidades seja definido. Com a inexistncia destas peculiaridades, o GPP1 foi considerado Parcialmente Implementado e se fazem necessrias modificaes nas ferramentas escolhidas de forma que atenda por completo este resultado esperado. Estas modificaes foram definidas e sero propostas na seo seguinte. 4.5.2 GPP2: No Implementado Este resultado esperado pode ser atendido atravs de uma visualizao de recursos disponveis em todos os projetos, com suas respectivas alocaes, de forma que, ao atribuir um recurso a um projeto, no haja conflitos. Nenhuma das ferramentas disponveis no SUITE prope-se a atender esta necessidade, categorizando, ento, este GPP como No Implementado. Sendo assim, no tpico mais adiante, prope-se modificaes 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 identificao e alocao dos Lderes de Projeto. O dotProject possui caractersticas que se propem a esta finalidade, haja vista que, para cada projeto, necessrio alocar um lder para o mesmo. Porm, esta ferramenta no oferece suporte para a identificao do indivduo mais adequado para assumir tal compromisso, visto que os recursos humanos cadastrados no sistema no possuem informaes sobre suas caractersticas profissionais. Sendo assim, esta ferramenta no contempla todos os requisitos necessrios para atender o resultado esperado, classificando-o como Parcialmente Implementado. Desta forma, posteriormente sero tratadas propostas para atender tais requisitos. 4.5.4 GPP4: Totalmente Implementado ( Mantis ) De acordo com a descrio deste resultado esperado, preciso uma ferramenta que auxilie no registro e acompanhamento das solues 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 atravs 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 avaliaes peridicas de todos os projetos em andamento, de forma que os resultados de tais avaliaes dem subsdios ao processo de deciso sobre o prosseguimento ou no destes projetos, de acordo com a estratgia de negcio da instituio.
37
Alm disso, todo o histrico e resultados destas avaliaes devem ser mantidos juntamente com o registro da deciso tomada aps cada avaliao executada. Assim, como para dar suporte ao GPP1, a ferramenta Spider-CL poder ser utilizada para promover o processo de avaliaes peridicas e o dotProject poder armazenar todas as informaes relevantes de cada avaliao, bem como o histrico das mesmas e as decises tomadas. Entretanto, o dotProject no est preparado para suprir tal necessidade e modificaes se fazem necessrias para utiliz-lo em tal objetivo. Sendo assim, devido as necessidades de mudanas 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 sero apresentadas a seguir.
4.6 Melhorias Propostas para as Ferramentas de Apoio

Para atender a todos os resultados esperados previstos na Gerncia de Portflio do Modelo MPS.Br, o Projeto SPIDER promoveu uma srie de customizaes das ferramentas de seu SUITE para buscar respeitar todos o requisitos exigidos. Desta forma, todas as ferramentas que no atenderam por completo ou sequer atenderam parte dos requisitos exigidos pelo respectivo resultado esperado, devem sofrer customizaes a fim de permitir que estas possam respeitar a todos os requisitos necessrios. De tal modo que, a partir da implementao adequada destes novos servios a estas ferramentas, o Projeto SPIDER possa contemplar a Gerncia de Portflio do Modelo MPS.Br. Sendo assim, o dotProject ser a ferramenta que sofrer tais modificaes, a fim de alcanar os requisitos que ainda no foram contemplados pelas ferramentas escolhidas para este objetivo. Estas propostas sero discutidas nas sees 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 atribudos aos projetos registrados. Desta forma, se faz necessria a
38
criao de um novo status denominado Negcios, onde devero ser registradas, como projetos, todas as oportunidades de negcio identificadas. Alm disso, nesta nova aba criada devem ser exibidas informaes sobre o resultado da avaliao de cada uma destas oportunidades, realizada atravs da ferramenta Spider-CL como ilustra a Figura 4.2, bem como a posio no ranking das melhores oportunidades identificadas. Estas modificaes citadas foram instanciadas e podem ser visualizadas na Figura 4.3.
Figura 4.2 - Avaliao da oportunidade atravs da ferramenta Spider-CL
39
Figura 4.3 Prottipo para atender aos requisitos do GPP1
Tambm, a deciso tomada aps a avaliao destas oportunidades deve ser realizada atravs da prpria ferramenta, onde as opes disponveis para a alta administrao so: Aprovado; Arquivado; e Em Anlise. Como mostra a Figura 4.4.
Figura 4.4 - Prottipo para atender aos requisitos do GPP1
Aprovado o status na qual a alta administrao decide por em prtica a oportunidade de negcio identificada. Caso o resultado da avaliao da oportunidade no seja satisfatrio, a alta gesto da empresa define o status da oportunidade como Arquivado, porm esta mesma oportunidade pode sofrer avaliaes futuras onde esse status pode ser mudado. Durante o perodo em que no definido se a oportunidade de negcio entra em produo ou no, o status dela permanecer Em Anlise at que a mesma seja avaliada.
40
4.6.2 GPP2 Para este resultado esperado ser atendido, se faz necessria a criao de uma visualizao de todos os recursos disponveis juntamente com a alocao dos mesmos entre os diferentes projetos, levando-se em considerao evitar conflitos no compartilhamento desses recursos. Para isto, prope-se uma tabela de Recursos x Projeto onde cada clula seria preenchida pelo nmero 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 perodo passado pelo usurio atravs do preenchimento dos campos especficos para este fim.
Vale ressaltar que a criao desta tabela em tempo de execuo possvel, haja vista que, de acordo com o perodo passado pelo usurio, possvel enviar diferentes consultas para o banco de dados, adicionando ainda, se necessrio, clculos sobre as informaes existentes atravs desta mesma consulta. Alm das informaes contidas na relao 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 clulas o total de horas que aquele recurso possui no perodo especificado. A outra denomina-se Tempo Ocioso, que deve ser apresentada como ltima coluna onde em cada clula deve constar a diferena 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 Oramento, onde o cruzamento entre Oramento 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 mudanas no dotProject devem ser implementadas. necessrio oferecer suporte identificao e alocao de Lderes para os Projetos. Haja vista que o dotProject j possui a funcionalidade de alocar um lder para o Projeto, se faz necessrio adicionar ao registro de Recursos Humanos campos destinados a Competncias e Habilidades do indivduo cadastrado como mostra a Figura 4.5.
4.6.4 GPP5 Assim como no GPP1, onde criou-se uma nova aba denominada Negcios na rea de Projetos, para atender o GPP5, prope-se a criao de uma nova aba denominada Avaliao de Execuo.
42
A partir desta aba, todos os projetos que j passaram pela etapa de execuo devem ser listados juntamente com informaes sobre o resultado da ltima avaliao e seu status atual, como pode ser visualizado na Figura 4.6. Nos detalhes do Projeto, um guia denominado Avaliao deve ser acrescentado, onde deve conter o histrico das avaliaes com as respectivas decises tomadas a partir delas, como mostra a Figura 4.7.
Nesta aba, tambm, para a alta administrao, deve possibilitar eleger a deciso que ser tomada de acordo com a ltima avaliao, onde as possibilidades sero: Manter, Parar e Cancelar.
43
O status Manter deve ser selecionado pela alta gerncia quando o feedback da avaliao for positivo e esta decidir dar prosseguimento ao projeto. Entretanto, se existirem outras prioridades de acordo com a estratgia de negcios da empresa, a alta gesto pode Parar o projeto, tendo a possibilidade de retom-lo posteriormente em um momento mais adequado. Caso a avaliao do projeto neste momento indique a inviabilidade do projeto, possvel Cancelar o projeto, sendo que esta deciso no permite retomar o mesmo futuramente. Vale ressaltar que, enquanto uma deciso no for tomada, o status permanecer Em Anlise.

O Projeto SPIDER visa atender aos nveis G e F do MPS.Br de forma eficiente e principalmente a baixo custo, o que justifica a utilizao 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 Gerncia de Portflio. Tendo em vista que no existem ferramentas destinadas a atender todos os requisitos exigidos nos resultados esperados disponveis de forma open source, utilizou-se o dotProject e o Mantis como base, alm 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 customizaes necessrias que deveriam ser implementadas. Desta forma, propostas de modificaes foram descritas resultando na criao de um prottipo apresentado no captulo a seguir juntamente com a metodologia de uso destas ferramentas para alcanar os seus objetivos.
44
METODOLOGIA DE IMPLEMENTAO
De acordo com a anlise realizada no Captulo 4, definiu-se as ferramentas que devem
ser utilizadas para atender aos Resultados Esperados do Processo de Gerncia de Portflio de Projetos. Sendo assim, as organizaes 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 instalao de cada uma destas aplicaes e as Polticas de Uso das mesmas, para que as organizaes interessadas em implementar as propostas definidas possam utilizar como base para sua implantao.
5.3 Instalao das Ferramentas

Como definido no Captulo 4, trs ferramentas foram selecionadas para atender os requisitos exigidos pelo processo de Gerncia de Portflio de Projetos do Modelo MPS.Br. Cada uma destas ferramentas instalada de forma independente, onde o guia de instalao abaixo pode ser seguido para o sucesso deste procedimento. 5.3.1 Instalao do dotProject Esta uma ferramenta web, que depende de outros servios para a sua execuo. Dentre os requisitos mnimos para a utilizao desta ferramenta se encontram um servidor web, Apache ou Microsoft IIS, com suporte a Linguagem de programao PHP e um banco de dados MySQL ou PostGreSQL ativo. Todas as propostas do Captulo 4 apresentadas, foram definidas levando-se em considerao a verso 2.1.2 do dotProject. Desta forma, a instalao desta ferramenta segue o as recomendaes de instalao desta verso. Inicialmente, deve-se extrair os arquivos do dotProject dentro do diretrio virtual raiz do servidor web, que definido na instalao do servidor. Feito isso, atravs do browser deve-se acessar a pgina install do dotProject a partir do nome do domnio local, geralmente http://localhost/dotproject/install. Em seguida, deve-se preencher a pgina que aparecer com as informaes pertinentes instalao 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 boto upgrade db & write cfg para finalizar a instalao. Por ltimo, deve-se acessar a pgina principal da ferramenta, geralmente em http://localhost/dotproject, e realizar login no dotproject (por padro, o login admin e a senha passwd). 5.3.2 Instalao do Spider-CL Assim como o dotProject, o Spider-CL depende de alguns servios para ser executado corretamente. Para a utilizao desta ferramenta, por ser desenvolvida em Java, necessrio um servidor web com suporte a esta tecnologia, como o Tomcat (recomenda-se a utilizao do Tomcat 6.0 ou superior). Alm do Tomcat, requerido tambm a instalao de uma base de dados do MySQL 5.1. Inicialmente deve-se configurar o banco de dados existente com os requisitos da aplicao. Desta forma, necessrio a execuo de duas instrues sql para o MySQL. Onde a primeira responsvel por criar uma base de dados denominada spider_cl. E a segunda cria um usurio spider_cl identificado pela senha spider_cl, alm de atribuir todos os privilgios necessrios para este usurio, que ser utilizado pela aplicao para efetuar as modificaes 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 configuraes realizadas, deve-se publicar o arquivo WAR da ferramenta Spider-CL atravs do Tomcat. Feito isto, a ferramenta encontra-se disponvel para acesso com o usurio padro admin e a senha vazia. 5.3.3 Instalao do Mantis Seguindo o modelo das duas ferramentas anteriores, esta tambm uma ferramenta web, e possui requisitos semelhantes para o seu correto funcionamento. necessrio um servidor web disponvel, Apache ou Microsoft IIS, com suporte a Linguagem de programao PHP e um banco de dados MySQL ou PostGreSQL ativo.
46
A verso utilizada pela metodologia de uso sugerida a 1.1.8 por ser a verso estvel mais atual. Desta forma, o guia de instalao a seguir est relacionado a esta verso. Primeiramente necessrio descompactar o diretrio do Mantis dentro do local destinado publicao de pginas web do servidor web. Em seguida, acessar a pgina de configurao da base de dados, atravs do link http://localhost/mantisbt/admin/install.php, onde localhost pode ser substitudo pelo endereo IP (Internet Protocol) do servidor web que abriga a aplicao. Est uma pgina de criao das tabelas que sero utilizadas pela ferramenta, deve-se preencher os campos exigidos e clicar no boto referente a iniciar o processo de criao. Feito isto, se faz necessrio criar um arquivo denominado config_inc.php com as informaes de acesso ao banco de dados e variveis referente aos e-mails utilizados pela aplicao. Abaixo segue um exemplo de como estas informaes devem estar dispostas:
$g_hostname = 'localhost'; $g_db_type = 'mysql'; $g_database_name = 'bugtracker'; $g_db_username = 'mantisadm'; $g_db_password = 'senha'; # --- variveis de e-mail ------------$g_administrator_email = 'adminmantis@provedor.com.br'; $g_webmaster_email = 'webmaster@provedor.com.br'; # Campo "De" do e-mail $g_from_email = 'adminmantis@provedor.com.br''; # Endereo de retorno do e-mail $g_return_path_email = 'adminmantis@provedor.com.br'';
Com todas as configuraes necessrias realizadas, pode-se acessar a aplicao atravs do link http://localhost/mantisbt e utilizar o login administrator e senha root.
5.4 Polticas de Uso

Este tpico destina-se a descrever a metodologia de uso de cada ferramenta relacionada ao processo de GPP na qual esta busca atender. Sendo assim, a descrio do uso detalhado de todas as funcionalidades de tais ferramentas encontra-se disponvel 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 poltica de uso da ferramenta, de forma que atenda aos requisitos necessrios do Resultado Esperado em questo. Vale ressaltar, que estas polticas esto relacionadas ao uso das funcionalidades propostas no Captulo 4, onde apresentado um prottipo que visa suprir as necessidades que estas ferramentas no atendem. 5.4.1 GPP1: dotProject e Spider-CL Para atender este resultado esperado se faz necessrio a utilizao de duas ferramentas, o dotProject e o Spider-CL. Inicialmente preciso registrar as oportunidades de negcio identificadas no dotProject, para isso deve-se acessar a seo Projetos e clicar no boto novo projeto como mostra o local em destaque na Figura 5.1.
Figura 5.1 - Criao de um novo projeto no dotProject
Ser apresentado um formulrio onde se deve preencher os dados referentes oportunidade de negcio em questo. Dois campos so muito importantes para esta etapa, o status do projeto, que deve ser definido como Negcios, e a Metodologia de Avaliao, que deve ser preenchida com o link referente ao arquivo que contm a metodologia para avaliar a oportunidade de negcio. Ambos os campos esto destacados na Figura 5.2 identificados como os itens 1 e 2.
48
Figura 5.2 - Criao de um novo projeto no dotProject
Esta metodologia de avaliao um artefato organizacional, no do escopo desta pesquisa a elaborao e definio de um modelo para tal metodologia. Entretanto, esta metodologia deve seguir apenas critrios objetivos e oferecer como resultado um valor absoluto entre 0 e 100. Feito o cadastro da oportunidade, esta deve ser avaliada utilizando a ferramenta SpiderCL seguindo a metodologia de avaliao estabelecida. Para isto, deve-se criar um novo checklist que estar associado aos critrios objetivos estabelecidos na metodologia de avaliao. Aps a criao deste checklist, criam-se cada um dos critrios necessrios e os associam ao checklist inicialmente criado. Com o modelo de avaliao definido, se faz uso do mesmo atravs da ferramenta e aps este processo, utiliza-se a metodologia de avaliao para obter o resultado absoluto oriundo da avaliao em questo. Todos os passos citados nesta etapa do procedimento esto descritos detalhadamente no manual da ferramenta que se encontra disponvel em [SPIDER, 2009]. De posse do valor absoluto, se faz necessrio editar as informaes da oportunidade de negcios registrada, adicionando o valor referente ao resultado da avaliao realizada. Para isto, deve-se entrar nos detalhes do projeto e acessar editar projeto e, em seguida, preencher
49
o campo Resultado da Avaliao 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 formulrio de edio equivalente. Neste instante, o registro da oportunidade de negcio encontra-se realizado. Todas as oportunidades registrada e avaliadas podem ser visualizadas no guia Negcios do menu Projeto, que lista de maneira ordenada as oportunidades, como possvel visualizar na Figura 4.2. Nesta lista tambm consta a deciso tomada pela alta gerncia da organizao sobre cada oportunidade, onde as oportunidades ainda no analisadas possuem o status de Em Anlise. Para a alta administrao definir uma atitude em relao a uma oportunidade de negcio avaliada, deve-se entrar nos detalhes do projeto e no guia denominado Avaliao constar o resultado da avaliao realizada e as opes de anlises disponveis. possvel Aprovar ou Arquivar uma oportunidade, marcando um dos combobox equivalentes e clicar no boto de Confirmar Anlise. A Figura 4.3 ilustra esta etapa do procedimento. De acordo com a atitude tomada, o status ser modificado automaticamente e a data desta anlise ser registrada. Vale ressaltar que estas opes de tomada de deciso estaro desabilitadas para os usurios que no pertencerem ao grupo de usurios que possuem este privilgio. 5.4.2 GPP2: dotProject Como destacado no Captulo 4, este resultado esperado no atendido por nenhuma das ferramentas estudadas. Entretanto, elaborou-se um prottipo a ser implementado sobre a ferramenta dotProject que torne a ferramenta aderente aos requisitos deste Resultado Esperado. Sendo assim, os recursos cadastrados possuem informaes de horas disponveis para alocao de tarefas por dia, alm de informaes do custo de sua utilizao por hora e se esto disponveis para uso de maneira concorrente entre projetos. A partir destas informaes, no guia Recursos da seo de Projetos apresentado uma tabela contendo a relao Recursos x Projeto, alm do Tempo Total e o Tempo Ocioso que cada recurso dispe. Ainda na mesma tabela, acrescentada uma linha contendo
50
os custos totais de cada Projeto que conseguido atravs da soma dos custos por hora de cada recurso alocado ao Projeto respectivo. Todas estas informaes servem de subsdio para a identificao dos recursos alocados para cada Projeto, bem como os seus oramentos. Esta tabela criada dinamicamente utilizando o perodo passado pelo usurio, de forma que o resultado apresentado se refere somente a este perodo, sendo possvel aplicar filtros sobre recursos onde ser apresentado somente o recurso selecionado. A Figura 4.4 ilustra a utilizao 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 informaes para a alta gerncia da organizao sobre cada um dos funcionrios existentes capazes de exercer a funo de Lder do Projeto. Informaes estas que devem ser preenchidas no ato de registrar um novo recurso humano, nos campos Habilidades e Competncias que so apresentados na Figura 4.5. Desta forma, ao visualizar os detalhes de um usurio especfico, ser possvel identificar se este possui os requisitos necessrios para assumir a responsabilidade de Lder do Projeto. Aps a identificao do responsvel pelo projeto, deve-se editar as informaes do mesmo incluindo no campo Responsvel pelo Projeto o usurio em questo. estabelecendo e comunicando a autoridade pelo Projeto. 5.4.4 GPP4: Mantis Para a ferramenta Mantis atender ao resultado esperado GPP4 no se faz necessrias modificaes 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 resoluo de problemas ou conflitos. Sendo assim, os conflitos entre recursos, que podem ser identificados no resultado da aplicao da metodologia de uso definido ao resultado esperado GPP2, devem ser registrados na ferramenta Mantis, como ilustra a Figura 5.3, onde os responsveis por tais Projetos envolvidos no conflito sero notificados e estes devem buscar a soluo mais adequada para a organizao para a resoluo do problema. Com isto,
51
Figura 5.33 - Criao de uma issue no Mantis
Deste modo, deve-se criar um Projeto destinado resoluo de problemas do processo de GPP no Mantis denominado Gerncia de Portflio e em seguida um subprojeto deste denominado Recursos. Os Lderes de Projetos estaro associados ao subprojeto Recurso, onde todo novo relato de caso entre conflito de recursos, que deve ser realizado pelo Gerente de Negcios da organizao, os Lderes dos Projetos envolvidos devem ser notificados e a busca da soluo do problema ser acompanhada pela ferramenta. Os procedimentos de criao de projetos e subprojetos, bem como a criao de novos casos, notificao de usurios e acompanhamento da resoluo do problema, podem ser visualizados na manual da ferramenta disponvel em [MANTIS, 2000]. 5.4.5 GPP5: dotProject e Spider-CL Para atender a este resultado esperado, novamente se faz necessrio 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 revises de marcos do Projeto, devem ser aplicadas as avaliaes de execues de projetos. A lista contendo os projetos em execuo e suas respectivas avaliaes
52
mais recentes pode ser visualizada atravs do menu Projetos no guia Avaliao de Execuo, como apresentado na Figura 4.6. Estas avaliaes devem seguir a Metodologia de Avaliao disponvel nos detalhes do Projeto. Utiliza-se a ferramenta Spider-CL para aplicar a avaliao objetiva do projeto, assim como descrito para o resultado esperado GPP1. Aps a aplicao do checklist, utiliza-se da metodologia de avaliao disponvel para obter o resultado absoluto da avaliao e registrar tal resultado na ferramenta dotProject. Estas avaliaes devem ser registradas no guia Avaliao que pode ser visualizado atravs dos detalhes do projeto, como ilustra a Figura 4.7. Neste local, estar disponvel o histrico de avaliaes realizadas, e as respectivas decises tomadas pela alta gerncia valendo-se destes resultados. A cada avaliao, a alta gesto tem a possibilidade de tomar decises sobre o andamento do Projeto, onde as opes disponveis so: Manter, Parar e Cancelar. De acordo com a deciso tomada, o status deste projeto pode sofrer alteraes para Em Espera ou Arquivado se a deciso for Parar ou Cancelar, ou permanecer o mesmo caso o projeto seja mantido. Vale ressaltar que estas opes esto habilitadas somente para os usurios que possuem privilgios suficientes para tomar as referidas decises.

As ferramentas dotProject, Mantis e Spider-CL foram selecionadas de acordo com suas caractersticas para atender a todos os Resultados Esperados da Gerncia de Portflio do Modelo MPS.Br. Com isto, a instalao e configurao destas se faz necessria para obter os resultados exigidos por este processo. Alm disso, uma eficaz metodologia de uso sobre as ferramentas deve ser aplicada, tendo em vista que somente com uma utilizao adequada ser possvel extrair das ferramentas o potencial exigido por cada resultado esperado do processo de GPP para respeitar os requisitos requeridos. Entretanto, as polticas de uso esto vinculadas s funcionalidades apresentadas como prottipos no Captulo 4, haja vista que estas ferramentas s podem atender aos requisitos exigidos com a implementao das propostas elaboradas.
53
Sendo assim, a implementao das funcionalidades propostas anteriormente de suma importncia para que estas ferramentas open source sejam capazes de desempenhar os servios citados na metodologia de uso, e o seu manuseio adequado ir satisfazer a todos os Resultados Esperados da Gerncia de Portflio de Projetos no mbito do MPS.Br.
54
6. CONCLUSO
Este captulo apresentar um resumo de todo o trabalho desenvolvido, seguido dos resultados obtidos, trabalhos futuros e as lies aprendidas.
6.3 Resumo
Para uma sistematizao do Processo de Gerncia de Portflio de Projetos do MPS.Br, necessrio o auxlio de ferramentas que, com uma metodologia de uso adequada, facilite a execuo deste processo. Sendo assim, analisaram-se no mercado as opes de aplicaes disponveis com o cdigo aberto que pudessem oferecer tal auxlio, haja vista que uma das premissas do Projeto SPIDER utilizar somente ferramentas open source. Deste modo, constatou-se que no existem atualmente no mercado ferramentas de cdigo aberto que objetivam suprir as necessidades de uma Gerncia de Portflio. Sendo assim, foram escolhidas trs ferramentas que mais se adequavam aos requisitos necessrios e, posteriormente, propostos ajustes nas mesmas, de forma que pudessem implementar os servios necessrios 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 Gerncia de Portflio de Projetos do Modelo MPS.Br sero atendidos, viabilizando, ento, alcanar o nvel F de maturidade, no que diz respeito Gerncia de Portflio.
6.4 Resultados Obtidos

O trabalho desenvolvido atendeu a sua finalidade e os resultados desejados foram alcanados de forma satisfatria. Entre os resultados obtidos encontram-se: Anlise de cada resultado esperado do processo de GPP, de forma que foram identificadas as caractersticas necessrias para uma ferramenta atender a cada um destes Resultados Esperados; Uma anlise das ferramentas escolhidas e a justificativa destas serem as mais adequadas para o que se prope;
55
Um mapeamento entre as caractersticas das ferramentas escolhidas e os requisitos dos Resultados Esperados da Gerncia de Portflio de Projetos do MPS.Br;
Propostas de ajustes na ferramenta dotProject, de forma que atenda as necessidades que no esto contempladas nas ferramentas escolhidas;
Elaborao de uma metodologia de uso sobre as ferramentas dotProject, Mantis e SPIDER-CL, que em conjunto contemplam todas as necessidades para uma Gerncia de Portflio de Projetos aderente ao MPS.Br.
6.5 Trabalhos Futuros

Com base no desenvolvimento deste trabalho, destacam-se pontos que sero estudados e desenvolvidos posteriormente: Implementao dos ajustes propostos na ferramenta dotProject; Elaborao de uma Metodologia de Avaliao de oportunidades de negcio, que gere um resultado absoluto; Aplicao da metodologia proposta em uma organizao, a fim de promover um estudo de caso que ir viabilizar uma anlise dos resultados gerados.
6.6 Lies 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 opo para as micro, pequenas e mdias empresas que desejam estar concorrendo as melhores oportunidades de negcio nacional e internacionalmente. O estudo da Gerncia de Portflio de Projetos possibilitou visualizar, de forma abrangente, que a estratgia de negcios de uma empresa deve estar bem definida, para que os seus projetos estejam sempre de acordo com o desejado. Alm disso, que os projetos no podem ser executados de forma independente, sempre deve haver avaliaes para valorizar os projetos prioritrios, os que esto mais prximos da estratgia da empresa.
56
Referncias Bibliogrficas
[ABNT, 1994] ABNT (Associao Brasileira de Normas Tcnicas), NBR ISSO 8402/1994 Gesto da Qualidade e Garantia da Qualidade, Terminologia, Brasil, 1994. [ABNT, 2001] ABNT ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. NBR ISO 9000:2000 Sistemas de gesto da qualidade e garantia da qualidade Fundamentos e Vocabulrio. 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 Usurio SPIDER CL Verso 1.2, 2009. [CRAWFORD, 2002] [DOTPROJECT, 2005] CRAWFORD, J. K. The Strategic Project Office: a guide to Homepage da ferramenta dotProject, <www.dotproject.net>. improving organizational performance, 2002. 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] [KERZNER, 2005] KENDALL, G. I.; ROLLINS, S. C. Advanced Project Portfolio Management and PMO Multiplying ROI, 2003. KERZNER, H. Strategic Planning for a Project Office, 2005. em: 23/11/09. [MCT, 2002] [MIT, 2003] Ministrio da Cincia e Tecnologia - MCT. Relatrio MCT 2001, 2002. Massachussets Institute of Technology - MIT. Slicing the KnowledgeBased 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 Implementao do MPS.Br, Projeto Submetido e Aprovado pelo Instituto de Cincias Exatas e Naturais da UFPA, Belm-PA, 2008. [PMI, 2008a] Project Management Institute - PMI. A Guide to the Project Management Body of Knowledge - PMBOK. Syba: PMI Publishing Division, 2008. Disponvel em: <www.pmi.org>. [PMI, 2008b] Project Management Institute. The Standard for Portfolio Management. Syba: PMI Publishing Division, 2008. Disponvel (para associados) em: <www.pmi.org>. [PMI, 2002] Project Management Institute - PMI. Project manager competence development (PMCD) framework. Syba: PMI Publishing Division, 2002. Disponvel em: <www.pmi.org>. [MANTIS, 2000] Homepage da ferramenta Mantis, <www.mantisbt.org>. ltimo acesso
58
[PMI, 2003]
Project Management Institute - PMI. A Guide to the Organizational Project Management Maturity Model (OPM3 Guide). Syba: PMI Publishing Division, 2003. Disponvel em: <www.pmi.org>.
[RABECHINI et al, 2005]
RABECHINI, R. J.; MAXIMIANO, A. C. A.; MARTINS, V. A.
A adoo de gerenciamento de portflio como uma alternativa gerencial: o caso de uma empresa prestadora de servio de interconexo eletrnica, 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 Promoo da Excelncia do Software Brasileiro, MPS.BR: Lies Aprendidas, organizadores: Ana Regina Cavalcanti da Rocha e Kival Chaves Webes, Campinas-SP, 2008. [SOFTEX, 2008b] Softex - Sociedade para Promoo da Excelncia do Software Brasileiro, MPS: Resultados de Desempenho de organizaes que adotaram o modelo MPS, organizadores: Guilherme Horta Travassos e Marcos Kalinowski, Campinas-SP, 2008. [SOFTEX, 2009a] Associao Para Promoo Da Excelncia Do Software Brasileiro SOFTEX. MPS.BR Guia de Avaliao:2009, maio 2009. Disponvel em: www.softex.br. [SOFTEX, 2009b] Associao Para Promoo Da Excelncia Do Software Brasileiro SOFTEX. MPS.BR Guia de Aquisio:2009, maio 2009. Disponvel em: www.softex.br. [SOFTEX, 2009c] Associao Para Promoo Da Excelncia Do Software Brasileiro SOFTEX. MPS.BR Guia de Implementao Parte 1: Fundamentao para Implementao do Nvel G do MR-MPS:2009, maio 2009. Disponvel em: www.softex.br. [SOFTEX, 2009d] Associao Para Promoo Da Excelncia Do Software Brasileiro SOFTEX. MPS.BR Guia de Implementao Parte 2: Fundamentao para Implementao do Nvel F do MR-MPS:2009, maio 2009. Disponvel em: www.softex.br. [SOFTEX, 2009e] Associao Para Promoo Da Excelncia Do Software Brasileiro SOFTEX. MPS.BR Guia de Implementao Parte 3: Fundamentao
59
para Implementao do Nvel E do MR-MPS:2009, maio 2009. Disponvel em: www.softex.br. [SOFTEX, 2009f] Associao Para Promoo Da Excelncia Do Software Brasileiro SOFTEX. MPS.BR Guia de Implementao Parte 4: Fundamentao para Implementao do Nvel D do MR-MPS:2009, maio 2009. Disponvel em: www.softex.br. [SOFTEX, 2009g] Associao Para Promoo Da Excelncia Do Software Brasileiro SOFTEX. MPS.BR Guia de Implementao Parte 5: Fundamentao para Implementao do Nvel C do MR-MPS:2009, maio 2009. Disponvel em: www.softex.br. [SOFTEX, 2009h] Associao Para Promoo Da Excelncia Do Software Brasileiro SOFTEX. MPS.BR Guia de Implementao Parte 6: Fundamentao para Implementao do Nvel B do MR-MPS:2009, maio 2009. Disponvel em: www.softex.br. [SOFTEX, 2009i] Associao Para Promoo Da Excelncia Do Software Brasileiro SOFTEX. MPS.BR Guia de Implementao Parte 7: Fundamentao para Implementao do Nvel A do MR-MPS:2009, maio 2009. Disponvel em: www.softex.br. [SOFTEX, 2009j] Associao Para Promoo Da Excelncia Do Software Brasileiro SOFTEX. MPS.BR Guia de Implementao Parte 8: Implementao do MR-MPS:2009 em organizaes que adquirem software, verso em elaborao. [SOFTEX, 2009k] Associao Para Promoo Da Excelncia Do Software Brasileiro SOFTEX. MPS.BR Guia de Implementao Parte 9: Implementao do MR-MPS:2009 v 2.0 em organizaes do tipo Fbrica de Software, em elaborao. [SOFTEX, 2009l] Associao Para Promoo Da Excelncia Do Software Brasileiro SOFTEX. MPS.BR Guia de Implementao Parte 10: Implementao do MR-MPS:2009 em organizaes do tipo Fbrica de Teste, em elaborao. [SOFTEX, 2009m] Associao Para Promoo Da Excelncia Do Software Brasileiro SOFTEX. MPS.BR Guia Geral:2009, maio 2009. Disponvel 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 Gerncia Estratgica de Portflio com Foco na Seleo de Projetos, 2009. [TUMAN, 1983] [WEBER, 1994] TUMAN, G. J. Development and Implementation of Effective Project Management Information and Control Systems, 1983. WEBER, Kival C. et al, Modelo de Referncia para Melhoria de Processo de Software: uma abordagem brasileira, Conferncia Latinoamericana de Informtica CLEI, Arequipa-Peru, 2004. [YELIN, 2007] YELIN, K.C. Linking strategy and Project Portfolio Management, 2007.

TCC Paulojunior 2009

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC Paulojunior 2009

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DO PAR INSTITUTO DE CINCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAO CURSO DE BACHARELADO EM CINCIA DA COMPUTAO TRABALHO DE CONCLUSO

Paulo Fernando Souza Rodrigues Jnior

UMA PROPOSTA DE APOIO SISTEMATIZADO GERNCIA DE PORTFLIO DO MPS.BR

Paulo Fernando Souza Rodrigues Jnior

UMA PROPOSTA DE APOIO SISTEMATIZADO GERNCIA DE PORTFLIO DO MPS.BR

Prof. Dr. Sandro Ronaldo Bezerra Oliveira Faculdade de Computao/UFPA Orientador

Prof. Dr. Ricardo Andr Cavalcante de Souza Faculdade de Computao/UFPA Membro

1.4.1 1.4.2 1.5 1.6 2

Metodologia .......................................................................................................................... 14 Estrutura ................................................................................................................................ 14

4.4.1 4.4.2 4.4.3 4.5

4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 4.6

4.6.1 4.6.2 4.6.3 4.6.4 4.7 5

Consideraes Finais ............................................................................................................. 43

5.3.1 5.3.2 5.3.3 5.4

5.4.1 5.4.2 5.4.3 5.4.4 5.4.5

Consideraes Finais ............................................................................................................. 52

Referncias Bibliogrficas .................................................................................................................... 56

Descrever a gerncia de Portflio no contexto do MPS.Br Definir uma metodologia que:

2.1 Histrico do MPS.Br

2.2 Definio e Composio do Modelo MPS.Br

Figura 2.2 - Definio do Modelo de Referncia [Weber, 2004]

2.3 Nveis de Maturidade do MPS.Br

Figura 2.3 - Nveis de Maturidade do MPS.Br [SOFTEX, 2009m]

2.4 Guias do MPS.Br

2.5 Consideraes Finais

3 PROCESSO DE GERNCIA DE PORTFLIO

3.1 Gerncia de Portflio

3.2 Gerncia de Portflio no MPS.Br

3.3 Anlise dos Resultados Esperados

3.4 Consideraes Finais

APOIO SISTEMATIZADO GERNCIA DE PORTFLIO

4.3 O Projeto SPIDER

4.4 Ferramentas de Apoio

4.5 Mapeamento das Ferramentas com os Resultados Esperados

Figura 4.1 - Tabela de mapeamento dos resultados esperados com as ferramentas

4.6 Melhorias Propostas para as Ferramentas de Apoio

Figura 4.2 - Avaliao da oportunidade atravs da ferramenta Spider-CL

Figura 4.3 Prottipo para atender aos requisitos do GPP1

Figura 4.4 - Prottipo para atender aos requisitos do GPP1

Figura 4.5 - Prottipo para atender aos requisitos do GPP2

Figura 4.6 - Prottipo para atender aos requisitos do GPP3

Figura 4.7 - Prottipo para atender aos requisitos do GPP5

Figura 4.8 - Prottipo para atender aos requisitos do GPP5

4.7 Consideraes Finais

5.3 Instalao das Ferramentas

5.4 Polticas de Uso

Figura 5.1 - Criao de um novo projeto no dotProject

Figura 5.2 - Criao de um novo projeto no dotProject

Figura 5.33 - Criao de uma issue no Mantis

5.5 Consideraes Finais

6.4 Resultados Obtidos

6.5 Trabalhos Futuros

6.6 Lies Aprendidas

[RABECHINI et al, 2005]

RABECHINI, R. J.; MAXIMIANO, A. C. A.; MARTINS, V. A.

Homepage do projeto de pesquisa SPIDER, <www.ufpa.br/spider>. ltimo acesso em: 23/11/09.

Você também pode gostar