UMA PROPOSTA DE APOIO SISTEMATIZADO À GERÊNCIA DE PORTFÓLIO DO MPS.BR

Transcrição

1 UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO Paulo Fernando Souza Rodrigues Júnior UMA PROPOSTA DE APOIO SISTEMATIZADO À GERÊNCIA DE PORTFÓLIO DO MPS.BR Trabalho de Conclusão de Curso para obtenção do grau de Bacharel em Ciência da Computação Orientador: Prof. Dr. Sandro Ronaldo Bezerra Oliveira Belém 2009

2 UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE CIÊNCIAS EXATAS E NATURAIS FACULDADE DE COMPUTAÇÃO CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO TRABALHO DE CONCLUSÃO DE CURSO Paulo Fernando Souza Rodrigues Júnior UMA PROPOSTA DE APOIO SISTEMATIZADO À GERÊNCIA DE PORTFÓLIO DO MPS.BR Data da defesa: / / Conceito: Banca Examinadora Prof. Dr. Sandro Ronaldo Bezerra Oliveira Faculdade de Computação/UFPA Orientador Prof. Dr. Ricardo André Cavalcante de Souza Faculdade de Computação/UFPA Membro Prof. Dr. Dionne Cavalcante Monteiro Faculdade de Computação/UFPA Membro Belém 2009

3 AGRADECIMENTOS À minha querida mãe, Ana Célis, pelo carinho, incentivo e amor durante todos os momentos. Ao meu irmão, Lucas Domires, por ser paciente e compreensivo nos momentos difíceis. Aos meus amigos pela ajuda e momentos de descontração. Aos demais integrantes do Projeto SPIDER, pelo companheirismo durante as nossas pesquisas. Ao meu orientador Prof. Dr. Sandro Ronaldo Bezerra Oliveira, que confiou desde o início no sucesso deste trabalho, e dedicou-se ao máximo para dar todo o suporte necessário aos seus orientandos do Projeto SPIDER. E, em especial, à Deus, por toda a força e apoio espiritual alcançados durante a minha vida. Paulo Rodrigues Júnior

4 Falta de tempo é desculpa daqueles que perdem tempo por falta de métodos. Albert Einstein

5 RESUMO Com o aumento das exigências pela qualidade das aplicações desenvolvidas, o mercado tem buscado empresas que sigam processos de desenvolvimento de softwares bem definidos. No Brasil, o modelo MPS.Br tem alcançado grande visibilidade entre as organizações desenvolvedoras, haja vista que o seu custo de implantação é muito menor que o de modelos como o CMMI. Sendo assim, o Projeto SPIDER foi idealizado com o intuito de promover a aderência das organizações aos níveis de maturidade G e F do Modelo MPS.Br. Em maio de 2009, a Gerência de Portfólio de Projetos foi inserida no MPS.Br como sendo um dos processos exigidos do nível F de maturidade. Apesar de estar sendo debatido nos últimos anos, este é um conceito novo e que poucas ferramentas implementam serviços que atendem as exigências deste processo. Como não foram identificadas aplicações que objetivavam suprir as necessidades da Gerência de Portfólio, foram propostos ajustes no dotproject que visam implementar os serviços necessários. Juntamente com os ajustes, definiu-se uma metodologia de uso sobre as ferramentas dotproject, Mantis e Spider-CL, onde, seguindo esta metodologia, todos os cinco Resultados Esperados exigidos pela Gerência de Portfólio do Modelo MPS.Br serão atendidos, viabilizando então, alcançar no nível F de maturidade. PALAVRAS-CHAVE: Melhoria do Processo, Qualidade do Software, Modelos de Melhoria, MPS.Br, Ferramentas de Software, Gerência de Portfólio.

6 ABSTRACT With the increasing demands for software quality, the market is seeking for companies that follow well-defined development software processes. In Brazil, the MPS.Br model is reaching great visibility among development organizations, once its deployment cost is much lower than models like CMMI. In this scenario, SPIDER Project was idealized to promote organizations adherence to G and F maturity levels of MPS.Br. In May 2009, the Portfolio Management was inserted in the MPS.Br as one of the process required to F maturity level. Despite the last years it debates, this is a new concept and few tools implement services that attend this process demands. Once there weren t applications that aim to attend Portfolio Management needs, adjustments were proposed in the dotproject to implement the needed services. Together with those adjustments a use methodology of the dotproject, Mantis and Spider-CL tools was defined, that all Portfolio Management s expected results of MPS.Br will be attended, enabling to achieve F maturity level, following this methodology. KEYWORDS: Process Improvement, Software Quality, Improvement Models, MPS.Br, Software Tools, Portfolio Management.

7 SUMÁRIO 1 Introdução Contexto Justificativa Motivação Objetivos Geral Específico Metodologia Estrutura MPS.Br Histórico do MPS.Br Definição e Composição do Modelo MPS.Br Níveis de Maturidade do MPS.Br Guias do MPS.Br Considerações Finais Processo de Gerência de Portfólio Gerência de Portfólio Gerência de Portfólio no MPS.Br Análise dos Resultados Esperados GPP1 - As oportunidades de negócio, as necessidades e os investimentos são identificados, qualificados, priorizados e selecionados GPP 2 - Os recursos e orçamentos para cada projeto são identificados e alocados GPP 3 - A responsabilidade e autoridade pelo gerenciamento dos projetos são estabelecidas GPP 4 - Os conflitos sobre recursos entre projetos são tratados e resolvidos GPP 5 - Projetos que atendem aos acordos e requisitos que levaram à sua aprovação são mantidos, e os que não atendem são redirecionados ou cancelados Considerações Finais... 29

8 4 Apoio Sistematizado à Gerência de Portfólio O Projeto SPIDER Ferramentas de Apoio dotproject Mantis Spider-CL Mapeamento das Ferramentas com os Resultados Esperados GPP1: Parcialmente Implementado ( dotproject e Spider-CL ) GPP2: Não Implementado GPP3: Parcialmente Implementado ( dotproject ) GPP4: Totalmente Implementado ( Mantis ) GPP5: Parcialmente Implementado ( dotproject e Spider-CL ) Melhorias Propostas para as Ferramentas de Apoio GPP GPP GPP GPP Considerações Finais Metodologia de Implementação Instalação das Ferramentas Instalação do dotproject Instalação do Spider-CL Instalação do Mantis Políticas de Uso GPP1: dotproject e Spider-CL GPP2: dotproject GPP3: dotproject GPP4: Mantis GPP5: dotproject e Spider-CL... 51

9 5.5 Considerações Finais Conclusão Resumo Resultados Obtidos Trabalhos Futuros Lições Aprendidas Referências Bibliográficas... 56

10 LISTA DE FIGURAS Figura Modelo de Negócio para melhoria de processo de software (MN mps) [Weber, 2004] Figura Definição do Modelo de Referência [Weber, 2004] Figura Níveis de Maturidade do MPS.Br [SOFTEX, 2009m] Figura Tabela de mapeamento dos resultados esperados com as ferramentas Figura Avaliação da oportunidade através da ferramenta Spider-CL Figura Protótipo para atender aos requisitos do GPP Figura Protótipo para atender aos requisitos do GPP Figura Protótipo para atender aos requisitos do GPP Figura Protótipo para atender aos requisitos do GPP Figura Protótipo para atender aos requisitos do GPP Figura Protótipo para atender aos requisitos do GPP Figura Criação de um novo projeto no dotproject Figura Criação de um novo projeto no dotproject Figura Criação de uma issue no Mantis... 51

11 Lista de Tabelas Tabela Processo gerencial para criação do gerenciamento de portfólio, adaptada de Crawford, 2002 [RABECHINI et al, 2005]

12 12 1 INTRODUÇÃO Neste capítulo será apresentado o contexto no qual este trabalho está inserido, a justificativa e os objetivos desta pesquisa, bem como a motivação que a originou, a metodologia utilizada e a estrutura deste trabalho. 1.1 Contexto Com o aumento das exigências pela qualidade das aplicações desenvolvidas, o mercado tem buscado empresas que sigam processos de desenvolvimento de softwares bem definidos. No Brasil, o Modelo de Processo de Software Brasileiro tem alcançado grande visibilidade entre as organizações desenvolvedoras, haja vista que o seu custo de implantação é muito menor que o de modelos como o CMMI (Capability Maturity Model Integration). Criado a partir de normas e modelos internacionais, o MPS.Br é dividido em sete níveis de maturidade, onde as empresas definem em que nível desejam ser avaliadas. Para atender aos requisitos exigidos em cada nível, as organizações se baseiam em guias elaborados para este fim, onde existem informações detalhadas de como atender a cada um dos Resultados Esperados. 1.2 Justificativa A crescente demanda por produtos e serviços de alta qualidade para suprir o aumento da competitividade e concorrência internacional, tem exigido das empresas brasileiras oferecerem garantias de que possuem maturidade suficiente para desenvolver seus projetos. No âmbito nacional, esta garantia vem sendo obtida através da implantação do MPS.Br. O MPS.Br se propõe a ser um guia evolucionário para o aperfeiçoamento e adequação de processos organizacionais orientados para a excelência no desenvolvimento de software. Apostando num custo acessível, especialmente para micro, pequenas e médias empresas, e na aproximação com a realidade do mercado brasileiro, ele é aderente a ISO/IEC 12207, a série de normas ISO/IEC e ao modelo CMMI. Com metas ousadas e uma sólida estrutura de pesquisa, fomentada por Universidades e pelo Ministério da Ciência e Tecnologia, o modelo está entrando nas empresas brasileiras de maneira constante e incremental, conforme planejado.

13 13 O padrão de qualidade MPS.Br descreve o quê deve ser feito para melhoria gradual de processos, definindo níveis de maturidade que são organizados por áreas de processo, os quais possuem objetivos alcançados pelos chamados Resultado Esperados. Para tanto, faz-se necessária a utilização de ferramentas de software para possibilitar a implantação do MPS.Br nas organizações. Com o intuito de alavancar pesquisas na sistematização do MPS.Br, o Projeto SPIDER foi idealizado para apresentar um levantamento de ferramentas de software livre com características adequadas para possibilitar a criação de produtos de trabalhos derivados dos Resultados Esperados, descritos nos objetivos das Áreas de Processo, dos níveis de maturidade G e F do modelo MPS.Br. Este trabalho tratará especificamente da Área de Processo de Gerência de Portfólio. A Gerência de Portfólio de Projetos (GPP) foi inserida recentemente, maio de 2009, nos requisitos para avaliação do Nível F. Com isso, se faz necessário o estudo de uma metodologia para implementação deste processo de forma eficaz. De acordo com a proposta do Projeto SPIDER, serão utilizadas ferramentas livres para dar suporte as necessidades desta metodologia, buscando alcançar os Resultados Esperados do MPS.Br em relação a Gerência de Portfólio. 1.3 Motivação A Gerência de Portfólio é uma área pouco explorada entre os consultores de implementação do MPS.Br, haja vista que foi inserida recentemente no Nível F, o que agrega um crescente valor ao seu estudo, além de possibilitar ao Projeto SPIDER contemplar na totalidade os níveis G e F do MPS.Br. Soma-se a isso o interesse pessoal pela Gerência de TI (Tecnologia da Informação), onde a experiência como pesquisador do Projeto SPIDER, mais especificamente do estudo da Metodologia de Implantação da Gerência de Portfólio, trará tal benefício. 1.4 Objetivos Geral Definir uma metodologia eficaz para a implementação da Gerência de Portfólio, alcançando todos os Resultados Esperados pelo MPS.Br em relação a este processo, bem como definir os ajustes necessários às ferramentas escolhidas para atender os requisitos exigidos e, além disso, elaborar um protótipo contemplando os ajustes propostos.

14 Específico Descrever a gerência de Portfólio no contexto do MPS.Br Definir uma metodologia que: o Identifique, qualifique, priorize e selecione as oportunidades de negócio, as necessidades e os investimentos; o Identifique e organize os recursos e orçamentos para cada projeto; o Estabeleça a responsabilidade e autoridade pelo gerenciamento dos projetos; o Trate e resolva os conflitos sobre recursos entre projetos; o Mantenha projetos que atendem aos acordos e requisitos que levaram à sua aprovação, e redirecione ou cancele os que não atendem; Rastrear as características que já são suportadas por meio da implementação das ferramentas de software livres propostas nos demais sub-projetos do Projeto SPIDER; Definir os ajustes necessários às ferramentas escolhidas de tal modo que possam oferecer todos os serviços exigidos pelos Resultados Esperados do processo de GPP; Elaborar um protótipo para cada funcionalidade que deve ser adicionada às ferramentas de acordo com os ajustes propostos. 1.5 Metodologia A metodologia aplicada neste trabalho sustenta-se na pesquisa bibliográfica de áreas relacionadas, através de livros, artigos, Trabalhos de Conclusão de Curso e revistas. Para comprovar a eficiência da proposta elaborada no decorrer deste trabalho, foi realizada uma pesquisa experimental, onde foram executadas verificações sobre a proposta de forma que esta seja avaliada sobre os Resultados Esperados da Gerência de Portfólio de Projetos do Modelo MPS.Br. Além disso, foi aplicado o método da indução, onde foram estudados certos casos de portfólio de projetos, e, partindo de suas características, foi possível entender a estrutura necessária para ser definida uma metodologia para implementação da Gerência de Portfólio de Projeto respeitando os requisitos solicitados no MPS.Br. 1.6 Estrutura Além deste capítulo introdutório, a organização desta monografia foi feita da seguinte forma.

15 15 O capítulo 2 tem por objetivo explicar a Melhoria de Processo de Software Brasileiro, as justificativas de sua criação, sua composição e seus guias. O capítulo 3 direciona suas informações à Gerência de Portfólio, conceituando-a de maneira mais ampla e contextualizando este processo dentro do Modelo MPS.Br, detalhando cada um de seus Resultados Esperados. O capítulo 4 apresenta o Projeto SPIDER, no qual este trabalho de pesquisa está inserido, além de justificar a escolha das ferramentas utilizadas para o auxílio da implementação deste processo e apresentar o mapeamento destas com os Resultados Esperados, bem como os ajustes propostos. O capítulo 5 apresenta o procedimento de instalação das ferramentas escolhidas e a metodologia de uso a ser aplicada de modo que os Resultados Esperados da Gerência de Portfólio de Projetos sejam atendidos de maneira eficiente. O capítulo 6 apresenta a conclusão do trabalho proposto, comentando os resultados obtidos, propostas para trabalhos futuros e as lições aprendidas com esta pesquisa.

16 16 2 MPS.BR Criado pela Associação Brasileira para Promoção da Exportação de Software (SOFTEX), o Modelo MPS.Br (Melhoria do Processo de Software Brasileiro) objetiva: Definir e aprimorar um modelo de melhoria e avaliação de processo de software, visando preferencialmente as micro, pequenas e médias empresas, de forma a atender as suas necessidades de negócio e ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software [SOFTEX, 2009m]. 2.1 Histórico do MPS.Br Ao longo da década de 80, o mercado para informática direcionou seu foco de forma intensa para a produção de hardware e desenvolvimento de microeletrônica, em detrimento a indústria de software [MCT, 2002]. Sendo assim, para buscar o equilíbrio entre as áreas de hardware e software, o MCT criou o programa SOFTEX, cujo objetivo inicial era o de implantar infra-estrutura de uso geral, para incubar empresas produtoras e exportadoras de software [MCT, 2002]. Em 1993, o Ministério da Ciência e Tecnologia criou o que viria a se tornar um dos programas prioritários na área de informática, o Programa Nacional de Software para Exportação (Programa SOFTEX 2000). Em 1996 o Governo passou a gestão do Programa SOFTEX para o setor privado, considerando e encaminhando os objetivos iniciais do programa. A Sociedade SOFTEX, uma organização não governamental e sem fins lucrativos, atua, desde então, como sua gestora. Em 2001, a SOFTEX contava com cerca de mil empresas associadas aos 19 Núcleos Regionais e 18 Centros SOFTEX GENESIS, espalhados por 12 estados da federação, das quais 850 são empresas maduras e 150 start-ups. O faturamento dessas empresas em 2000 foi de cerca de R$ 2 bilhões (aproximadamente um terço do faturamento total da indústria de software no País) e suas exportações totalizaram cerca de US$ 100 milhões. Em parceria com o Banco Nacional do Desenvolvimento (BNDES), foi criado também o Prosoft, para estimular a competitividade dessa indústria em nível internacional. Com essas ações, as empresas de software se desenvolveram e se habilitaram a desempenhar papel relevante na construção da Sociedade da Informação no Brasil [MCT, 2002].

17 17 Entretanto, as empresas de software no Brasil priorizavam seus esforços a atender a ISO 9000 [ABNT, 2001], sem favorecer outras normas e modelos especificamente voltadas para a melhoria de processo de software [MIT 2003], sendo necessário um esforço significativo para melhorar a maturidade do processo de softwares nessas empresas [MCT, 2002]. Assim sendo, em 11 de dezembro de 2003, a SOFTEX, com o apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP), do Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e do Banco Interamericano de Desenvolvimento (BID), lançou o programa MPS.Br para solução deste problema. Os propósitos do MPS.Br compreendem dois desafios, o primeiro seria a criação e o aprimoramento do modelo MPS e o segundo a disseminação e adoção deste modelo em todas as regiões do país a um custo razoável. 2.2 Definição e Composição do Modelo MPS.Br A implementação e avaliação de modelos como o Capability Maturity Model Integration (CMMI) [SEI, 2006] até mesmo nos seus níveis mais baixos está fora do alcance da grande massa de micro, pequenas e médias empresas especialmente no Brasil e países latino-americanos devido ao seu custo elevado. Com isso, o MPS.Br baseou-se na elaboração de dois modelos: o Modelo de Referência para melhoria de processo de software (MR-MPS) e o Modelo de Negócio para melhoria de processo de software (MN MPS). Para atingir a sua meta de atender principalmente micro, pequenas e médias empresas, o MN MPS prevê duas situações para a implementação do MR-MPS: de forma personalizada para uma empresa (MNE Modelo de Negócio Específico); e de forma cooperada em grupos de empresas (MNC Modelo de Negócio Cooperado), com custo mais acessível por dividir proporcionalmente parte dos custos entre as empresas e por se buscar outras fontes de financiamento [WEBER, 2004]. Existem instituições credenciadas para a implementação do MR-MPS e a realização de avaliações segundo o Modelo MPS.Br. O Fórum de Credenciamento e Controle (FCC) é o responsável pelo credenciamento, onde a SOFTEX assina um convênio com as instituições credenciadas tornando-as Instituições Credenciadas para Implementação (ICI ou II) ou Instituições Credenciadas para Avaliação (ICA ou IA).

18 18 No MNE a empresa interessada na implementação do MR-MPS busca uma das II e assina um contrato específico. Caso deseje ser avaliada, a empresa interessada deve negociar e assinar um contrato específico com uma das IA. A Sociedade SOFTEX toma conhecimento do contrato e dos resultados da implementação e/ou avaliação da empresa interessada através da II ou IA contratada. O Modelo de Negócio do MPS.Br é ilustrado na Figura 2.1. Figura Modelo de Negócio para melhoria de processo de software (MN mps) [Weber, 2004] No MNC, primeiramente deve ser constituído um grupo de empresas interessadas na implementação do MR-MPS. A coordenação do grupo deverá então negociar e assinar um contrato com uma das II do MR-MPS. Após a implementação, irá negociar e assinar um contrato com uma das IA do MR-MPS. Nesta situação, a Sociedade SOFTEX toma conhecimento dos resultados da implementação e/ou avaliação através da ICI ou ICA contratada pelo grupo, e assina um convênio com a entidade organizadora do grupo, que pode ser um Agente SOFTEX. O MPS.Br não objetiva criar Normas e Modelos de Maturidade, busca ser inovador na sua estratégia de implementação, que prioriza se adequar à realidade das empresas brasileiras. Sendo assim, modelos, normas e métodos já disponíveis formaram a base para a definição do Modelo de Referência [Weber, 2004], como ilustra a Figura 2.2.

19 19 Figura Definição do Modelo de Referência [Weber, 2004] A definição do MR-MPS partiu da análise da realidade das empresas brasileiras, a norma ISO/IEC [ISO/IEC, 2008], a série de normas ISO/IEC [ISSO/IEC, 2003] [ISSO/IEC, 2004a] [ISSO/IEC, 2004b] [ISSO/IEC, 2004c] [ISSO/IEC, 2006] e o modelo CMMI. Com isso, o Modelo de Referência foi definido com sete níveis de maturidade e é constituído, também, por uma série de guias para auxiliar as empresas interessadas em sua implementação, assim como as II e as IA. 2.3 Níveis de Maturidade do MPS.Br O desempenho de uma empresa ao executar um ou mais processos pode ser previsto ao verificar o nível de maturidade no qual se encontra esta organização. Os sete níveis de maturidade, que são uma combinação entre processos e sua capacidade, definidos pelo MR- MPS são: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A evolução da empresa nos níveis de maturidade se dá a partir do nível G até o nível A, onde a progressão da organização através desses níveis representa a sua evolução na implementação dos processos previstos em cada um deles. O nível de maturidade é obtido quando são atendidos os propósitos e todos os Resultados Esperados dos respectivos processos, bem como os Resultados Esperados dos atributos de processo estabelecidos para o respectivo nível [SOFTEX, 2009m].

20 20 maturidade. A Figura 2.3 ilustra os Processos e Atributos de Processo requeridos em cada nível de Figura Níveis de Maturidade do MPS.Br [SOFTEX, 2009m] O objetivo desta divisão considerando mais níveis de maturidade, em relação ao CMMI, é para possibilitar uma implementação e avaliação adequada para as micro, pequenas e médias empresas, possibilitando também visualizar os resultados de melhoria de processos em prazos mais curtos. 2.4 Guias do MPS.Br O modelo MPS.Br está descrito em formato de guias. Sendo estes divididos em Guia Geral, Guia de Aquisição, Guia de Avaliação e Guia de Implementação, explicados a seguir [SOFTEX, 2009m].

21 21 Guia Geral: contém a descrição geral do modelo MPS e detalha o Modelo de Referência (MR-MPS), seus componentes e as definições comuns necessárias para seu entendimento e aplicação; Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. É descrito como forma de apoiar as instituições que queiram adquirir produtos de software e serviços correlatos apoiando-se no MR-MPS [SOFTEX, 2009b]; Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA) [SOFTEX, 2009a]; Guia de Implementação: série de dez documentos que fornecem orientações para implementar nas organizações os níveis de maturidade descritos no Modelo de Referência MR-MPS [SOFTEX, 2009c], [SOFTEX, 2009d], [SOFTEX, 2009e], [SOFTEX, 2009f], [SOFTEX, 2009g], [SOFTEX, 2009h], [SOFTEX, 2009i], [SOFTEX, 2009j], [SOFTEX, 2009k] e [SOFTEX, 2009l]. 2.5 Considerações Finais Este capítulo apresentou o Modelo MPS.Br, desde a motivação que levou a sua criação pela SOFTEX até a descrição do Modelo de Referência elaborado. Um dos processos contidos no MPS.Br é o Processo de Gerência de Portfólio, que será abordado mais detalhadamente no capítulo a seguir, tendo em vista que este trabalho tem por objetivo apresentar uma proposta de apoio sistematizado a este processo.

22 22 3 PROCESSO DE GERÊNCIA DE PORTFÓLIO Após o lançamento da metodologia denominada OPM3 (Organizational Project Management Maturity Model) [PMI, 2003], gerenciamento de portfólio se tornou um tema bastante explorado em literaturas sobre projetos. O OPM3 possui estruturas conceituais baseadas em evoluções sucessivas que contemplam além de projetos e programas, os portfólios. 3.1 Gerência de Portfólio Para o correto entendimento da Gerência de Portfólio, primeiramente é necessário absorver a definição de projeto. Na literatura existem algumas definições clássicas para projetos: Um processo único, consistindo de um grupo de atividades coordenadas e controladas com datas para início e término, empreendido para alcance de um objetivo conforme requisitos específicos, incluindo limitações de tempo, custo e recursos. [ISO10006, 1997]. Um empreendimento de esforço temporário feito para criar um produto, serviço ou resultado único. [PMI, 2002]. Um projeto é uma organização de pessoas dedicadas visando atingir um propósito e objetivo específico. Projetos geralmente envolvem gastos, ações únicas ou empreendimentos de altos riscos o qual tem que ser completado numa certa data por um montante de dinheiro, dentro de alguma expectativa de desempenho. No mínimo todos projetos necessitam de terem seus objetivos bem definidos e recursos suficientes para poderem desenvolver as tarefas requeridas. [TUMAN, 1983]. Um projeto visa gerar produtos, serviços ou resultados únicos e exclusivos, para atender um ou mais objetivos. Desta forma, os objetivos dos projetos devem ser alinhados à estratégia da organização, permitindo que ele seja utilizado como mecanismo para operacionalização do planejamento estratégico organizacional. É possível, porém, encontrar em diversas empresas exemplos de projetos propostos que não conseguiram atingir os benefícios prometidos. Os exemplos mais comuns são de projetos

23 23 inadequados, não sincronizados com os objetivos da organização, com riscos excessivos ou aprovados em decorrência de força política dos patrocinadores [SOUZA et al, 2009], sugando os recursos que poderiam ser direcionados para projetos que trariam mais benefícios à organização [YELIN, 2007]. Para contornar isto, é necessária uma gerência adequada do projeto para que o mesmo alcance todos os seus objetivos designados. A Gerência de Projetos tem por objetivos planejar, programar e controlar uma série de tarefas integradas de forma a atingir, com êxito, os objetivos do projeto, para benefício dos envolvidos [KERZNER, 2005]. O [PMI, 2008a] define gerência de projetos como sendo a aplicação de conhecimentos, habilidades, ferramentas e técnicas nas atividades do projeto, com o objetivo de atender às suas necessidades. Uma empresa que tenha recursos para executar todos os projetos candidatos, atendendo um determinado conjunto de metas e objetivos, seria um cenário ideal. Entretanto, a grande maioria das empresas não vive esta realidade, e a execução de seus projetos é limitada por variáveis como tempo, orçamento, recursos, entre outras restrições, forçando-as a limitar o número de projetos executados de maneira concorrente. Sendo assim, surge uma nova demanda para as organizações: avaliar, priorizar e selecionar os projetos candidatos a atender determinados objetivos de forma alinhada à estratégia organizacional, ligando às atividades estratégicas, táticas e operacionais [YELIN, 2007]. Com isso, as empresas deixam de empregar grandes esforços em fazer os projetos darem certo e concentram-se na seleção dos projetos certos. Para [ARCHER & GHASEMZADEH, 1999], gerenciamento de portfólio é uma coleção de projetos que são desenvolvidos sob a administração de uma unidade organizacional, onde cada projeto pode se relacionar com outros ou ser independente. No entanto, devem fazer parte de objetivos estratégicos determinados e assim buscar recursos na organização. [KENDALL & ROLLINS, 2003] enfatizam que o gerenciamento de portfólio serve para garantir que o conjunto de projetos escolhido e mantido na carteira deve atender os objetivos organizacionais.

24 24 [CRAWFORD, 2002] apresenta o gerenciamento de portfólio visto como um processo gerencial que é guiado pelos passos apresentados na Tabela 3.1. Tabela Processo gerencial para criação do gerenciamento de portfólio, adaptada de Crawford, 2002 [RABECHINI et al, 2005]. 3.2 Gerência de Portfólio no MPS.Br Reconhecendo o valor da disciplina no suporte do sucesso da estratégia organizacional, a SOFTEX, em maio de 2009, integrou ao modelo do MPS.Br o processo de Gerência de Portfólio. Seguindo uma fundamentação teórica do Padrão de Gerência de Portfólio [PMI, 2008b] que foi disseminado pelo Project Management Institute PMI (reconhecida associação profissional na área de gerenciamento de projetos), a Gerência de Portfólio de Projetos do MPS.Br foca nas atividades envolvidas no gerenciamento da carteira de projetos da organização, e não apenas sobre um projeto individualmente. Para o modelo, a governança de um conjunto de projetos é realizada de duas formas: selecionando os projetos que devem ser executados; e, uma vez em execução, avaliando se estes projetos continuam viáveis e aderentes aos critérios pelos quais foram aprovados [SOFTEX, 2009d]. Na primeira etapa, o objetivo é criar uma combinação de projetos que melhor apóie os objetivos da organização, alinhada com as suas estratégias e com as restrições de recursos (pessoas e orçamento) [Levine apud SOFTEX, 2009d].

25 25 Na segunda, o objetivo é garantir que, à medida que os projetos vão sendo executados, continuem aderentes e satisfazendo os objetivos pelos quais foram iniciados. Segundo Maizlish e Handler [apud SOFTEX, 2009d] visa, ainda, avaliar se o projeto continua sendo necessário frente às mudanças no ambiente que podem ocorrer durante a sua execução, principalmente devido a: Modificações na composição das necessidades do negócio e da missão em relação às ofertas de produtos e serviços; Tendências da indústria; Mudanças na economia; Demandas dos clientes; Ofertas dos fornecedores; Novas tecnologias; Requisitos legais; Competitividade e/ou business intelligence. Além disso, também é previsto o cancelamento ou suspensão de projetos cujos riscos ou desvantagens para a organização superem os benefícios de se continuar investindo [ISO/IEC, 2008 apud SOFTEX, 2009d]. Todas estas características são requeridas através dos Resultados Esperados do Processo de Gerência de Portfólio de Projetos previsto no Nível F do MPS.Br: GPP1: As oportunidades de negócio, as necessidades e os investimentos são identificados, qualificados, priorizados e selecionados; GPP2: Os recursos e orçamentos para cada projeto são identificados e alocados; GPP3: A responsabilidade e autoridade pelo gerenciamento dos projetos são estabelecidas;

26 26 GPP4: Os conflitos sobre recursos entre projetos são tratados e resolvidos; GPP5: Projetos que atendem aos acordos e requisitos que levaram à sua aprovação são mantidos, e os que não atendem são redirecionados ou cancelados. A organização que desejar ter uma Gerência de Portfólio aderente ao MPS.Br, deve atender a todos estes Resultados Esperados. Porém, para o MPS.Br, a Gerência de Portfólio de Projetos torna-se opcional quando a única atividade da unidade organizacional for evolução de produto, podendo ser considerada fora do escopo da avaliação da empresa. 3.3 Análise dos Resultados Esperados Uma análise detalhada de cada GPP foi realizada a fim de identificar os requisitos necessários para atender de forma satisfatória cada um dos Resultados Esperados GPP1 - As oportunidades de negócio, as necessidades e os investimentos são identificados, qualificados, priorizados e selecionados. O GPP1 é descrito no [SOFTEX, 2009d] da seguinte forma: [...] Inicialmente, as demandas precisam ser identificadas, ou seja, é preciso registrálas para que possam ser posteriormente analisadas, com o objetivo de definir se serão iniciadas como projetos ou descartadas. Em seguida as demandas deverão ser qualificadas, ou seja, deverão ser identificados os atributos que a caracterizam e que serão utilizados como critérios de seleção e priorização. [...] Selecionar os projetos significa validar sua aderência aos objetivos organizacionais antes que sejam incorporados ao portfólio. Potenciais projetos que estejam mais alinhados com os critérios estabelecidos receberão tratamento prioritário, enquanto que os demais receberão prioridade menor ou serão até mesmo descartados do portfólio. [...] É importante ressaltar que este resultado não se refere apenas à análise da viabilidade de um projeto individualmente, mas sim sob a perspectiva mais global, do portfólio de projetos e dos objetivos estratégicos da organização. Nota-se que o objetivo deste GPP é o de maximizar o valor das oportunidades identificadas, através da avaliação detalhada para viabilizar a inclusão no portfólio ou exclusão oportuna dos projetos que não estão de acordo com os objetivos estratégicos do portfólio. Esta avaliação é feita levando-se em consideração aspectos como: rentabilidade dos projetos; riscos associados aos projetos (alto/baixo); tempo de duração (curto/longo);

27 27 importância dos clientes (estratégica/financeira); e alinhamento com as estratégias de negócios. Sendo assim, este resultado consiste na obtenção de uma coleção de projetos que estão de acordo com os aspectos estratégicos da empresa, oferecendo então, subsídios para a tomada de decisão baseada em informações estratégicas e prioridades GPP 2 - Os recursos e orçamentos para cada projeto são identificados e alocados. Este GPP está descrito da seguinte forma [SOFTEX, 2009d]: Para cada um dos projetos que tenham sido selecionados e priorizados devem ser provisionados e disponibilizados os recursos e o orçamento necessários. [...] No entanto, deve-se, neste momento, analisar os possíveis conflitos de alocação de recursos entre os projetos, especialmente aqueles que são considerados críticos. Esta é uma perspectiva mais organizacional do que simplesmente individual de cada projeto. Nota-se que este GPP objetiva atribuir à carteira de projetos da empresa, os recursos e suporte necessários de acordo com os riscos/rendimentos envolvidos, buscando um equilíbrio adequado do portfólio com o uso eficiente dos recursos, para evitar o desperdício causado pela alocação ineficiente destes GPP 3 - A responsabilidade e autoridade pelo gerenciamento dos projetos são estabelecidas. Este GPP está descrito da seguinte forma [SOFTEX, 2009d]: Para cada um dos projetos que tenha sido selecionado e priorizado, deve ser identificado o profissional que será responsável pelas atividades de gerenciamento do projeto, ou seja, que exercerá o papel de Gerente do Projeto [...] Como o sucesso de um projeto está, também, ligado a liderança e capacidade dos indivíduos que estão a sua frente, este GPP busca identificar e alocar o indivíduo mais capacitado para exercer a função de Líder de Projeto GPP 4 - Os conflitos sobre recursos entre projetos são tratados e resolvidos. Este GPP está descrito da seguinte forma [SOFTEX, 2009d]: À medida que os projetos vão sendo realizados, novos conflitos de recursos podem ser identificados. Os projetos de TI raramente são executados exatamente como o

28 28 planejado, por diversos motivos [...]. Estes fatores podem afetar a execução dos projetos do portfólio e também levar a novos conflitos sobre recursos. [...] Estes conflitos, analisados sob a perspectiva organizacional dos múltiplos projetos em execução, devem ser registrados, analisados, tratados e resolvidos. Para uma adequada gestão da carteira de portfólio, se faz necessário um eficaz controle sobre os possíveis conflitos que possam surgir entre projetos. Os projetos de TI raramente são executados como planejado, podendo então ocasionar conflitos sobre recursos utilizados por outro projeto. Além disso, o desempenho de um projeto pode afetar a execução de outro projeto do portfólio. Este GPP espera soluções para a identificação, análise e solução destes possíveis conflitos, de maneira que reflita as prioridades da organização para seus investimentos e alocação de recursos GPP 5 - Projetos que atendem aos acordos e requisitos que levaram à sua aprovação são mantidos, e os que não atendem são redirecionados ou cancelados. Este GPP está descrito da seguinte forma [SOFTEX, 2009d]: À medida que um projeto vai sendo executado, as atividades de monitoramento vão sendo realizadas, de maneira a coletar informações, na forma de fotos de determinados momentos do projeto, permitindo a atuação do gerente de projetos, quando necessário. Estas são as atividades relacionadas ao gerenciamento do projeto individualmente, conforme previsto no processo GPR. Porém, todos os projetos possuem riscos que, se confirmados, podem levar o projeto a se desviar de seu plano original, afastando-se da situação que foi levada em consideração quando se determinou a sua aprovação. Neste momento, a empresa precisa analisar se este projeto continua alinhado aos objetivos estratégicos pretendidos, se é necessário algum redirecionamento ou até mesmo se é o momento de ser cancelado. A Gerência de Portfólio do MPS.Br prevê o monitoramento e controle dos projetos que estão em andamento, decidindo quais projetos devem continuar e quais projetos devem deixar o portfólio. Nota-se, então, que os projetos em execução devem sofrer avaliações periódicas de acordo com os objetivos estratégicos da organização. A coleta e análise de dados a fim de avaliar o desempenho do portfólio ajudam a determinar ou não a necessidade de ajustes, de modo que recursos importantes não sejam desperdiçados em projetos que deveriam ser cancelados.

29 Considerações Finais As decisões da Gerência de Portfólio devem seguir as metas e os objetivos do portfólio de projetos, assim como os critérios e condições consideradas para a seleção dos projetos. Estas metas, objetivos, critérios e condições são estipulados pela alta administração da organização, visando sempre manter a estratégia de negócios da empresa. A Gerência de Portfólio é a ligação entre estratégia corporativa e a operação organizacional, ajudando a determinar a combinação exata de projetos simultâneos e o correto nível de investimento em cada um deles. Além disso, a gestão de portfólio pode também oferecer um repositório de informações sobre projetos, permitindo o acompanhamento e a auditoria do andamento e resultados dos projetos, facilitando a captura das lições aprendidas com as decisões estratégicas adotadas no passado. Sendo assim, a sistematização da Gerência de Portfólio de Projetos, através do uso de ferramentas que possuam este propósito, é essencial para as organizações poderem realizar todas as etapas que uma eficiente gestão de portfólio exige.

30 30 4 APOIO SISTEMATIZADO À GERÊNCIA DE PORTFÓLIO Este capítulo descreve a proposta deste trabalho, que visa inicialmente apresentar o Projeto SPIDER, que deu origem a este objeto de pesquisa, e em seguida a proposta de sistematização da Gerência de Portfólio do MPS.Br. A descrição do SPIDER justifica a escolha de ferramentas livres para alcançar os resultados esperados, e nas seções seguintes é esclarecida a escolha de cada ferramenta que dará tal suporte a este objetivo, além de apresentar as melhorias necessárias para atender a todos os resultados esperados do processo GPP. 4.3 O Projeto SPIDER O projeto de pesquisa intitulado SPIDER: Uma Proposta de Solução Sistêmica de um SUITE de Ferramentas de Software Livre de apoio à implementação do modelo MPS.Br nasceu em 2008, no Instituto de Ciências Exatas e Naturais (ICEN) da Universidade Federal do Pará (UFPA), em parceria com o Centro de Informática (CIN) da Universidade Federal do Pernambuco (UFPE) e com o Departamento de Estatística e Informática (DEINFO) da Universidade Federal Rural de Pernambuco (UFRPE) [OLIVEIRA, 2008]. O objetivo do projeto é apresentar alternativas viáveis para auxiliar a implementação dos processos do MPS.Br, através do apoio de ferramentas livres, agilizando o processo de implementação do modelo de qualidade e reduzindo custos para as organizações, que não necessitam fazer aquisição de ferramentas proprietárias, além de terem a liberdade de customizarem as mesmas de acordo com suas necessidades. Estas vantagens são evidenciadas e discutidas nos relatórios de Resultados de Desempenho das organizações que adotaram o modelo MPS [SOFTEX, 2008b] e de Lições Aprendidas do MPS.Br [SOFTEX, 2008a]. Neste contexto, o projeto SPIDER tem, como uma das principais metas, realizar um levantamento de ferramentas de software livre que possibilitem a criação de produtos de trabalho (artefatos que evidenciam a implementação do programa de qualidade organizacional) derivados dos resultados esperados descritos nos objetivos das áreas de processo, inicialmente, dos níveis de maturidade G (parcialmente gerenciado) e F (gerenciado) do MPS.Br [OLIVEIRA, 2008].

31 31 A partir deste levantamento, pretende-se definir um SUITE de ferramentas, com a intenção de fazer uso integrado das funções/operações disponibilizadas, realizando a implantação das áreas de processo do modelo MPS.Br, em aderência ao fluxo de dependência proposto por este modelo de qualidade de processo [OLIVEIRA, 2008]. Dentro do Projeto SPIDER, foram definidos subprojetos referentes a: (1) levantamento de ferramentas e definição de metodologias de apoio sistematizado para atender aos resultados esperados de cada processo dos níveis de maturidade F e G do MPS.Br, e (2) propostas de integração para os processos dos referidos níveis [SPIDER, 2009]. Este trabalho surge do subprojeto homônimo a esta monografia. 4.4 Ferramentas de Apoio Gerência de Portfólio é um conceito relativamente novo e seus requisitos são pouco disseminados entre as ferramentas disponíveis no mercado. Desta forma, não existem aplicações bem elaboradas e adequadas para atender aos resultados esperados que tenham sido desenvolvidas para este propósito e disponibilizadas de forma open source. Sendo assim, como o Projeto SPIDER se propõe a utilizar apenas ferramentas livres em seu SUITE e algumas destas, já adotadas para atender a outros processos do MPS.Br, possuíam características que poderiam dar este suporte à Gerência de Portfólio, foram definidas melhorias e modificações nesses softwares a fim de que as mesmas passem a dar o suporte exigido para a implantação do GPP de acordo com o modelo MPS.Br. Devido à estreita relação entre a Gerência de Projetos e a Gerência de Portfólio, o dotproject [DOTPROJECT, 2005], uma das ferramentas que dão suporte ao GPR no âmbito do Projeto SPIDER, foi definido para sofrer tais modificações para atender também ao GPP. Além desta aplicação, também identificou-se a possibilidade de utilizar ferramentas de bugtracking para atender alguns requisitos específicos de um dos resultados esperados do GPP. Este tipo de ferramenta é largamente utilizado na Gerência de Configuração, onde o Mantis [MANTIS, 2000] é o software utilizado pelo Projeto SPIDER em seu SUITE. Assim sendo, o Mantis também agregará responsabilidades para dar o suporte necessário ao GPP. Por fim, como a Gerência de Portfólio possui em sua principal característica dar suporte as decisões estratégicas de acordo com critérios objetivos, uma ferramenta de checklist torna-

32 32 se necessária para complementar as anteriormente citadas. Como outros processos também se beneficiam do uso de uma ferramenta de checklist, desenvolveu-se a Spider-CL [SPIDER, 2009] para atender as demandas do Projeto SPIDER dotproject O dotproject trata-se de uma ferramenta baseada na web, que permite a centralização dos dados de um projeto. Assim, os requisitos necessários para implantá-la são: servidor web Apache ou Microsoft IIS, linguagem de programação PHP integrada ao servidor web e uma base SQL, como o MySQL ou PostGreSQL. A versão estável mais atual desta ferramenta é a Esta ferramenta destina-se ao gerenciamento e controle de projetos, ideal para situações onde o foco é a agenda de tarefas dos membros da equipe, sendo possível informar aos usuários do sistema suas associações com as tarefas do projeto através de ou mensagens pop-ups, reforçando o comprometimento da equipe. Além disso, a ferramenta é capaz de fornecer dados referentes à apropriação de horas trabalhadas de cada um dos recursos humanos envolvidos nas tarefas Mantis O Mantis é uma ferramenta de bugtracking, sob licença GPL, desenvolvido para auxiliar o controle de modificações através do gerenciamento dos issues. Issues são relatos de problemas identificados nos produtos de trabalho, que terão sua evolução acompanhada desde a solicitação da mudança até seu desfecho. Por ser um software executado em browser, ele independe de sistema operacional e sua base de dados pode ser estruturada em MySQL, MS SQL e PostgreSQL. A sua versão mais recente e estável é a versão 1.1.8, mas atualmente está sendo desenvolvida a versão 1.2.0rc2. Entre as principais funcionalidades desta ferramenta são identificados: criação de issues; gerenciamento do ciclo de vida dos issues; registro do histórico das issues; e controle de workflow da ferramenta. Outros aspectos marcantes são: a possibilidade de customização; interface amigável, proporcionando fácil utilização; e a facilidade de extensão através de plugins.

33 Spider-CL É uma ferramenta web, que pode ser executada através de servidor Tomcat, sendo acessível de qualquer navegador web, e seu banco de dados é estruturado em MySQL. Conta com serviço de controle de acesso através de cadastro de usuários e provê a sistematização do processo de definição e aplicação de checklists para avaliação, inspeção ou revisão através de critérios objetivos. A interface da Spider-CL foi desenvolvida utilizando componentes gráficos convencionais como caixas de textos, tabelas, listas e botões, para permitir fácil utilização [BARROS, 2009]. A ferramenta Spider-CL é marcada pelas seguintes características: É uma ferramenta gratuita; É portável, sendo desenvolvida como uma aplicação para o servidor Tomcat. A ferramenta pode ser executada em qualquer servidor capaz de executar o Tomcat 6.0 e o MySQL 5.1; Possui uma interface de fácil utilização; Pode ser utilizada para o desenvolvimento de qualquer tipo de checklist objetivo; Possui controle de acesso e mantém registro de todas as utilizações de cada checklist; Exporta os checklists preenchidos e seus resultados para o formato PDF. 4.5 Mapeamento das Ferramentas com os Resultados Esperados Como exposto na seção anterior, três ferramentas pertencentes ao SUITE do Projeto SPIDER foram escolhidas para buscar atender a todos os resultados esperados da Gerência de Portfólio do Modelo MPS.Br. Entretanto, estas ferramentas não foram desenvolvias para este propósito, sendo necessárias algumas modificações para que estas de forma conjunta possam contemplar todos os requisitos necessários para dar suporte aos resultados esperados do processo GPP.

34 34 A Figura 4.1 ilustra o mapeamento das ferramentas relacionando aos respectivos resultados esperados que estas atendem. Figura Tabela de mapeamento dos resultados esperados com as ferramentas De posse do resultado deste mapeamento, fica evidente a necessidade de customização para que a Gerência de Portfólio seja de fato contemplada no Projeto SPIDER, haja vista que apenas um Resultado Esperado está totalmente implementado, enquanto os outros não possuem todos os seus requisitos atendidos. Os detalhes do mapeamento relacionando cada GPP as suas respectivas ferramentas utilizadas estão discutidos nas seções a seguir GPP1: Parcialmente Implementado ( dotproject e Spider-CL ) Para atender este resultado esperado do ponto de vista ferramental, é necessário oferecer a funcionalidade de registrar as oportunidades de negócio previamente identificadas, além de mecanismos de avaliação por meio de critérios objetivos. O dotproject em conjunto com a Spider-CL atendem parte destes requisitos. A Spider-CL torna-se a ferramenta responsável por avaliar cada oportunidade de negócio. Através dela é possível criar os critérios objetivos que irá avaliar e gerar um resultado absoluto para fomentar um ranking das melhores oportunidades identificadas. No dotproject é possível cadastrar novos projetos e transitá-lo entre diferentes status. Os status possíveis para um projeto registrado são: Não Definido; Proposto; Em Planejamento; Em Execução; Em Espera; Completo; e Arquivado. Sendo Não Definido a categoria estabelecida para projetos cadastrados que ainda não possuem informações