Como o RUP e o PMBOK se complementam na GP de software

Como o RUP e o PMBOK se complementam na gestão de projetos de software

1) INTRODUÇÃO

Nas últimas décadas, grande parte das organizações busca a padronização das práticas de desenvolvimento e engenharia de software, bem como as práticas relacionadas a gerenciamento de projetos, com o objetivo de estruturar e formatar os processos associados às atividades que envolvem a tecnologia da informação. O RUP oferece uma perspectiva e metodologia para a resolução destas questões, enquanto o PMBoK (Project Management Body of Knowledge) oferece uma estratégia mais descritiva para a padronização das melhores práticas de gerenciamento de projetos. Desta maneira, quando se trata de um projeto como um todo, da sua fase de iniciação até o seu encerramento, as metodologias definidas no RUP ( IBM – Rational Unified Process ) não são suficientes para a execução, controle e monitoramento das atividades necessárias em um projeto de engenharia de software.

Nas organizações, tipicamente notamos que o primeiro passo é um processo de formalização dos processos adotados, o que acaba sendo realizado pela equipe técnica responsável pelos processos de concepção e desenvolvimento dos sistemas. Em um momento posterior, enxerga-se a necessidade de uma integração das metodologias e artefatos definidos pelo RUP com os controles de recursos humanos, planejamento e financeiro do projeto, o que leva a utilização do PMBoK como guia para a estruturação e padronização destes processos. Quando não se é feita uma análise da aderência das fases do RUP aos processos do PMBoK, os membros gestores do projeto podem decidir por suprimir parte do RUP na formalização dos procedimentos executados pela equipe, o que significa a utilização de processos mais genéricos do PMBoK em detrimento de processos mais direcionados à projetos de software, definidos pelo RUP. Contudo, é importante ressaltar que o PMBoK e o RUP não são antagônicos. Através da análise fornecida neste artigo será possível identificar a possibilidade de fusão destas duas metodologias, o que permite a obtenção de uma maior aderência dos procedimentos às particularidades dos projetos de software (PHILLIPS, 2003) e a abrangência das fases e processos que não são definidos pelo RUP, mas que são necessários ao gerenciamento destes projetos.

2) REVISÃO DA LITERATURA

Uma análise de compatibilidade entre o RUP e o PMBoK mostrou que o mapeamento entre os processos e fases não pode ser perfeitamente realizado (CHARBONNEAU, 2004). Contudo, se o PMBoK for realizado como base de comparação com o RUP, é possível inferir com ponto comum principal o fato de que muitos dos processos diretamente associados ao gerenciamento de projetos são iterativos, devido a necessidade de elaboração e realização incremental dos documentos e tarefas ao longo do ciclo de vida do projeto.

No processo de gerenciamento de riscos, Rocha e Belchior (2004) verificaram que os processos são compatíveis em seus aspectos essenciais, não havendo incompatibilidades fundamentais entre eles, o que possibilita comprovar a importância da gerência de riscos para projetos, especificamente os de software. Esta importância pode ser comprovada através do estudo realizado por Standish Group (2011), onde se mostra que a taxa de insucesso dos projetos aumenta drasticamente quando são introduzidas mudanças de escopo no projeto.

Alguns estudos de caso de Matsushita (2010), mostram que a integração das melhores práticas do PMBoK com o RUP pode apresentar bons resultados, onde os processos de Escopo e Qualidade do RUP predominaram, enquanto os processos do PMBoK ausentes no RUP foram utilizados com sucesso. Este caráter complementar entre as duas metodologias permite que uma forma de gestão, monitoramento e controle das atividades em um projeto de software seja realizada de modo mais efetivo, já que a maioria dos modelos ou guias voltados para a gerência de projetos, tal como o PMBoK, não se dirigem especificamente a processos de desenvolvimento de software (ROSITO ET AL, 2008).

3) DESENVOLVIMENTO

Conforme Kutsch (2006), projetos de software possuem particularidades que muitas vezes são subestimadas o que reflete a necessidade de adotarmos uma metodologia de gerenciamento de projetos que seja mais adequada às particularidades de cada setor ou área de projeto. Muitas organizações optam por utilizar processos de gerenciamento de projetos já utilizados em outras disciplinas, aplicando-os também à projetos de software. Esta decisão pode atender plenamente às necessidades de controle de custo, alocação de recursos, comunicações e aquisições, mas já para outros processos como Escopo, Prazo e Qualidade, existem técnicas específicas do RUP que permitem controle e monitoramento de maior direcionamento, granularidade e certeza, pois padroniza técnicas e procedimentos comumente adotados nos projetos de software. No que se refere às fases do RUP e aos grupos do PMBoK, nota-se que ambos são equivalentes, o que pode ser observado através ta tabela 2.

Já uma análise da segunda dimensão destas metodologias, permite perceber como o RUP complementa o PMBoK, principalmente nos processos que requerem controles específicos para projetos relacionados à tecnologia da informação.

Como é possível perceber através da análise da tabela 3, o processos de Custos, Comunicação e Aquisição não fazem parte da metodologia do RUP, por não exigirem um tratamento específico para projetos de software. Nestes casos, a utilização do PMBoK  como guia mostra-se mais adequada e abrangente. Já para as disciplinas comuns entre o PMBoK e o RUP, pode-se perceber através de uma análise mais detalhada (passos e fluxos de trabalho) que há uma maior riqueza de detalhes e procedimentos na metodologia RUP.

Foi realizada uma análise no processo de Qualidade no PMBoK, que é tratado no RUP pela disciplina de Testes. Esta análise teve como objetivo identificar itens complementares destas metodologias, e nela verificou-se que o PMBoK define a  atividade de Elaboração de Plano de Melhorias de Processo, que não é identificada no RUP. Esta atividade é útil para identificar procedimentos que aumentam o valor do processo, no caso, alguma fração do código sendo avaliado. Já o RUP define processos de identificação de ideias de teste, definição de configurações no ambiente de teste, análise de falha do teste e necessidades de avaliação e rastreabilidade, sendo este último de extrema importância para identificar a origem das falhas ocorridas em um software.

O RUP também possui um nível de detalhamento maior dentro de cada uma das atividades. Tomando como exemplo a parte de documentação de requisitos, o PMBoK define alguns componentes de documentação, dentre eles o que mais se adéqua à projetos de software: “Requisitos funcionais descrevendo processos de negócio, informações e interação com o produto de forma apropriada a ser documentada textualmente numa lista de requisitos, em modelos ou ambos” (PMBoK, 2008, p.110). Neste caso, o PMBoK serve apenas de elemento norteador da atividade a ser realizada, já que o RUP detalha de maneira procedural e profunda a identificação de atores, casos de uso, fluxos básicos, fluxos alternativos, pré-condições, pontos de extensão, dentre outros passos recomendados para confecção de um documento de especificação de um sistema.

Entretanto, é importante ressaltar que o PMBoK não objetiva detalhar os tipos de procedimentos e controles específicos para projetos de software. A partir de um trecho do PMBoK pode-se concluir “Enquanto o gerenciamento da qualidade de produtos de software utiliza abordagens e medidas diferentes de uma construção de uma usina nuclear, as abordagens de gerenciamento da qualidade do projeto se aplicam aos dois tipos.” (PMBoK, 2008, p.189).

4) CONCLUSÕES

De acordo com a análise baseada no guia PMBoK e na metodologia do RUP, foi possível extrair informações que constatam que o RUP não abrange todos os procedimentos definidos no PMBoK, o que não permite desconsiderar este último em projetos de software. Além disso, as boas práticas do PMBoK são mais adequadas para gerenciamento do software projeto como um todo, apesar do caráter menos aprofundado do mesmo. Além disso, é possível inferir através de uma análise quantitativa das atividades de ambas as metodologias analisadas, que o PMBoK possui um grande foco nas atividades de planejamento (48%), enquanto o RUP possui um número de atividades distribuída de maneira mais uniforme a detalhada (120 atividades),  de acordo com a análise realizada e exibida na tabela 4.

A partir das análises realizadas entre a metodologia RUP e o guia PMBoK, é perceptível o aspecto complementar entre eles. Enquanto o RUP foca na identificação, desenvolvimento e testes de atividades específicas de software, o PMBoK aborda estes itens de maneira abrangente a qualquer tipo de projeto. Contudo, PMBoK preocupa-se em ter uma abordagem que permita integrar o projeto no contexto da organização, através dos processos de Custos, Comunicação e Aquisição, o que não é tratado pelo RUP.

Sendo assim, foi possível constatar que o RUP complementa o PMBoK nos processos onde é necessário o uso de métodos mais práticos e específicos  para projetos de software, ou seja, nas disciplinas mais orientadas à requisitos, desenvolvimento e testes, o uso do RUP permite um maior detalhamento dos procedimentos críticos e necessários a estes tipos de projetos, aprofundando nas definições de base teórica no PMBoK.

REFERÊNCIAS

•  CHARBONNEAU, S. Software Project Management: A Mapping between RUP and the PMBoK. 2004. Disponível em . Acesso em: 12 Ago. 2012.
•  HENDERSON-SELLERS, B. et al. Third generation OO processes: a critique of RUP and OPEN from a project management perspective, ASPEC – Seventh Asia-Pacific Software Engineering Conference, 2000.
•  KUTSCH, E. The Influence of Intervening Conditions on the Over: And Underestimation of Risk. Conferência Européia de Sistemas de Informação (ECIS), 2006.
•  KRUCHTEN, P. The Rational Unified Process: An Introduction. Reading. MA: Addison-Wesley, 2000.
•  MATSUSHITA, R. O impacto da integração entre o processo RUP com padrão PMBoK. Faculdade de Tecnologia de São Caetano do Sul. Disponível em http://www.fattocs.com.br/livro-apf/citacao/RenanSTMatsushita-2010.pdf. Acesso em: 13  Ago. 2012.
• PHILLIPS, J. Gerência de Projetos de tecnologia da informação. Tradução de Ana B. T. S. P., Daniela F. L. G. 9ª Ed. Rio de Janeiro: Elsevier, 2003.
• PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em Gerenciamento de Projetos (PMBoK). 4a Ed. Pennsylvania, USA: PMI Publishing Division, 2008.
• ROCHA, P.C; BELCHIOR, A. D. Mapeamento do Gerenciamento de Riscos no PMBoK, CMMI-SW e RUP. VI Simpósio Internacional de Melhoria de Processos de Software, São Paulo, 2004.
• ROSITO, M. C. et al. Gerência de Projetos e Processos de Desenvolvimento de Software: uma proposta de integração iSys. Revista Brasileira de Sistemas de Informação – PPGI / UNIRIO, v. 1, p. 88-115, 2008.
• SCHWABER, K; SUTHERLAND, J. The Crisis in Software: The Wrong Process Produces the Wrong Results, Hoboken, NJ, p. 4-16, 2011.
• STANDISH GROUP. The Standish Group Report: Chaos. The Standish Group International Inc., v. 1, p. 2-8, 2011.

Sobre o autor: Bernardo Campos Hermont, engenheiro de Software Sênior atuante na área de TI e TI Industrial há 9 anos, participando de todo o ciclo de desenvolvimento de software, desde a concepção à implantação. Conhecimento amplo categorias de soluções MES, LIMS, PIMS, RtPM, aplicações Web para indústria e portais de visualização de dados corporativos..

E-mail de contato: bhermont@gmail.com

Se você tem comentários, sugestões ou alguma dúvida que gostaria de esclarecer, aproveite o espaço a seguir.