A Integração Entre RUP e PMBOK Para Projetos de Software A INTEGRAÇÃO ENTRE RUP E PMBOK PARA PROJETOS DE SOFTWARE - PDF
A Integração Entre RUP e PMBOK Para Projetos de Software A INTEGRAÇÃO ENTRE RUP E PMBOK PARA PROJETOS DE SOFTWARE
Download "A Integração Entre RUP e PMBOK Para Projetos de Software A INTEGRAÇÃO ENTRE RUP E PMBOK PARA PROJETOS DE SOFTWARE"
Isaque de Almada Caldeira
1 A INTEGRAÇÃO ENTRE RUP E PMBOK PARA PROJETOS DE SOFTWARE Jailton Benedito Marques 1 Márcio Aurélio Ribeiro Moreira 2 Resumo: A proposta do trabalho era saber se o RUP e o PMBOK podem ser utilizados de forma integrada. Para responder esta pergunta foi feito um estudo exploratório do RUP, do PMBOK e do relacionamento entre eles. O trabalho mostra que o uso combinado destas metodologias é possível, viável e em muitos casos recomendável, uma vez que a gestão de projetos do RUP foi escrita com base no PMBOK. O RUP cobre bem integração, escopo, tempo e qualidade; cobre parcialmente recursos humanos, comunicações e riscos; e cobre muito pouco custos, aquisições e partes interessadas. O trabalho também mostra que existem alguns equívocos na literatura sobre a utilização conjunta do RUP com o PMBOK. Palavras-chave: RUP, PMBOK, Gestão de Projetos e TI. Abstract: The purpose of this paper was whether RUP and PMBOK can used in an integrated manner. To answer this question we did an exploratory study of RUP, PMBOK and the relationship between them. The study shows that the combined use of these methods is possible, feasible and advisable in many cases, once the RUP project management discipline was written based on the PMBOK. RUP covers well integration, scope, time and quality; covers partially human resources, communications and risks; and has very little covers of costs, acquisitions and stakeholders. The work also shows that there are some misconceptions in the literature about the joint use of RUP with the PMBOK. Keywords: RUP, PMBOK, Project Management and IT. 1 Graduado em Comunicação Empresarial na Uniminas. Trabalha na empresa Algar Tecnologia. Pósgraduando em Gestão da Tecnologia da Informação. 2 Professor Orientador, Bacharel em Ciência da Computação pela UFU. Especialista em Segurança da Informação pela Uniminas/Pitágoras. Atua como executivo, consultor em TI e especialista em projetos em várias empresas no mercado. Jailton Marques & Márcio Moreira Página: 1
2 1. Introdução Segundo a Brasscom (2013, p. 7), Associação Brasileira das Empresas de Tecnologia da Informação e Comunicação, o Brasil pode chegar ao terceiro lugar no mercado mundial da Tecnologia da Informação (TI) até 2022, onde hoje ocupa a 4ª posição. Mas para que isso aconteça, as empresas de software precisam estar atentas à forma como seus projetos são conduzidos e, consequentemente, como se dá o desenvolvimento de suas aplicações. De acordo com Pressman (2010, p ), para a construção de um software, não basta apenas uma linguagem de modelagem de processos, com diagramas e fluxos, é preciso uma metodologia de desenvolvimento. Contudo, muitas empresas ainda desenvolvem software sem planejamento, padrões de nomenclatura, documentação, testes e homologações, tornando o trabalho de suas equipes ineficiente e majorando insatisfações com seus clientes. Além disso, para Guimarães e Moreira (2014, p. 2) não aliar esse processo a uma metodologia de gerenciamento de projetos, dificulta o atingimento dos requisitos e promove desvantagens como o não cumprimento de prazo, custo e qualidade previstos. Muitas empresas tentam adequar seus próprios métodos, ou adotam melhores práticas conhecidas do mercado, porém sem o entendimento de seus processos e a aplicabilidade destas práticas. Por conseguinte, para Temmenco (2008, p. 23), existe no mercado metodologias e guias capazes de minimizar os riscos dessa falta de planejamento, e as duas principais e tradicionalmente utilizadas na fabricação de software são o RUP (Rational Unified Process ou Processo Unificado da Rational), para o processo produtivo de desenvolvimento de software e o PMBOK (Project Management Body of Knowledge Guide ou Guia do Conhecimento de Gerenciamento de Projetos) como um modelo para o gerenciamento do projeto. Sendo assim, este estudo se propõe a responder a seguinte questão: É possível utilizar as melhores práticas do RUP e PMBOK de forma integrada? Além da busca por esta resposta, a motivação deste trabalho foi o fato de termos no mercado de TI duas metodologias (RUP e PMBOK) que parecem importantes para sucesso de projetos de desenvolvimento de software, e que geralmente são tratadas como distintas, mutuamente excludentes ou concorrentes. Para responder à questão central, este trabalho propõe fazer um estudo exploratório sobre a integração do RUP e do PMBOK, identificando similaridades, diferenças e finalmente comparando as duas metodologias. Jailton Marques & Márcio Moreira Página: 2
3 2. Referencial Teórico Segundo o PMI (2013, p. 3), um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. A sua natureza temporária indica um início e um término definidos. O término é alcançado quando os objetivos tiverem sido atingidos ou quando se concluir que esses objetivos não serão ou não poderão ser atingidos e o projeto for encerrado, ou quando o mesmo não for mais necessário. Conforme Guimarães e Moreira (2014, p. 3), o mercado de software tem estado cada vez mais interessado em contemplar o gerenciamento de projetos e o desenvolvimento de suas aplicações em seus negócios. Isso se deve ao fato de que, com a concorrência acirrada e o perfil globalizado dos clientes, tornou-se necessária a reestruturação das organizações a fim de garantir a entrega de produtos e serviços tecnológicos que atendam às expectativas das partes interessadas, com maior agilidade, qualidade e menor custo. Diante desta necessidade, sabe-se que os projetos são aplicados aos mais diferentes ramos de atividade, mas a Tecnologia da Informação (TI) é um dos setores que apresenta maior maturidade no gerenciamento de projetos, segundo pesquisa da consultoria Prado & Oliveira (2013, p. 14). Além disso, pela mesma pesquisa PMSURVEY.ORG (2013, p. 44), detectou-se que em 62,4% das empresas entrevistadas, a área de TI possui um e escritório de projetos estruturado. Segundo pesquisa da PwC (Price Waterhouse & Coopers), organizada por André Marinho (2012, p. 22), feita em âmbito mundial e mostrada na Figura 1, 41% das empresas entrevistadas utilizam o PMBOK como metodologia de gestão de projetos, 26% das empresas declararam não utilizar nenhuma metodologia e os 33% restantes são divididos entre várias metodologias, dentre elas: Prince2, SCRUM, entre outras. Por esta razão, este trabalho focará no PMBOK no que tange à gestão de projetos. Figura 1: Metodologias de gestão de projetos mais utilizadas pelas organizações (PWC, 2012, p. 22). Jailton Marques & Márcio Moreira Página: 3
4 Nos últimos anos, diversas metodologias surgiram para fornecer um padrão de desenvolvimento de software, tais como: OPEN, MSF, XP e RUP. De acordo com ZUSER (2005, p. 2), o RUP é o processo de software mais comum na indústria de software. Como mostrado na Figura 2, dentre as empresas que não utilizam processos ágeis, o processo iterativo é o mais utilizado, seguido pelo RUP (que também é iterativo e incremental), segundo pesquisa da Forrester, organizada por Dave West e Jeffrey S. Hammond (2010, p. 3), feita com profissionais de TI. Por isso este trabalho focará no RUP para o desenvolvimento de software. Figura 2: Metodologias mais utilizadas pelas organizações (Adaptado de FORRESTER, 2010, p. 3) Visão do PMBOK Segundo Morris (2013, p. 8), o PMBOK é um guia publicado pelo PMI (Project Management Institute ou Instituto de Gestão de Projetos), que descreve as melhores práticas para a gestão de projetos, de qualquer natureza. O objetivo deste guia é fornecer uma descrição dos conhecimentos de gestão de projetos e padronizar uma nomenclatura comum nesta área. A primeira versão do PMBOK foi publicada em 1987, a 5ª versão é a última edição e foi publicada em outubro de Como mostra a Figura 3, na 5a edição do PMBOK existem 47 processos distribuídos em 5 grupos de processos (iniciação, planejamento, execução, monitoramento & controle, encerramento) e 10 áreas do conhecimento (integração, Jailton Marques & Márcio Moreira Página: 4
5 escopo, tempo, custos, qualidade, recursos humanos, comunicações, riscos, aquisições e partes interessadas). Na figura está destacado o processo de Controlar os Custos que pertence à disciplina de Custos e ao grupo de processos de Monitoramento & Controle. (PMI, 2013, p. 61) Figura 3: Disciplinas e Grupos de Processos do PMBOK (Adaptado de PMI, 2013, p. 61). Ainda segundo o PMI (2013, p. 49), o propósito dos grupos de processos são: iniciação: reconhecer, definir o gerente de projetos e autorizar o início de um projeto ou fase; planejamento: definir e organizar os objetivos, planejar o trabalho para alcançar os objetivos do projeto; execução: coordenar os recursos para a realização do que foi planejado; monitoramento & controle: acompanhar e gerenciar o progresso do projeto; encerramento: obter o aceite formal das entregas do projeto e encerrar o projeto ou a fase. Analogamente seguem as principais responsabilidades das disciplinas (PMI, 2013, p ): 1) Integração: processos necessários para garantir que os processos e atividades das áreas do projeto aconteçam de forma integrada, além de coordenar as mudanças que possam ocorrer durante do projeto. 2) Escopo: descreve os processos que definem o escopo, a forma de aceita-lo, formaliza e aprova as entregas do projeto e suas possíveis mudanças. 3) Tempo: detalha as atividades do projeto, estabelece as dependências entre elas, estima os recursos e as durações das atividades, define e controla o cronograma do projeto. Jailton Marques & Márcio Moreira Página: 5
6 4) Custos: engloba os processos que asseguram a conclusão do projeto dentro do orçamento estabelecido. 5) Qualidade: define os critérios de qualidade de um projeto e como alcança-los, cuida para que as entregas sejam feitas com os critérios combinados e gerencia as questões decorrentes da avaliação destes critérios. 6) Recursos humanos: define papéis, responsabilidades e a organização destes papéis no projeto, gerencia e controla os recursos durante a realização do trabalho do projeto. 7) Comunicação: determina as informações necessárias para as partes interessadas, mantendo a transparência das ações, o desempenho e os resultados obtidos ao decorrer do projeto. 8) Riscos: identifica, analisa e responde aos riscos, iminentes ou não, que podem afetar o projeto. Prioriza os riscos utilizando a probabilidade de ocorrência, o impacto e o valor monetário esperado para fazer face aos planos de ações e de contingência dos riscos. 9) Aquisições: determina o que precisa ser contratado ou comprado, seleciona e contrata os fornecedores do projeto, gerencia o relacionamento com estes e seus contratos. 10) Partes interessadas: identifica, planeja e gerencia o engajamento das partes interessadas no projeto. Por ser composto de processos, o PMBOK descreve ainda quais são os insumos, a parte tangível do projeto, que são utilizados (entradas) e gerados (saídas). Como exemplo veja a Figura 4, que mostra as entradas, ferramentas e técnicas, bem como as saídas do processo Definir o Escopo. Este processo para ser realizado demanda o Plano de Gestão do Projeto, o Termo de Abertura do Projeto, os Documentos de Requisitos e os Ativos de Processos Organizacionais. Durante o processo são utilizadas as seguintes ferramentas e técnicas: opinião especializada (consultoria), análise de produto, identificação de alternativas e oficinas (workshops). Este processo gera a Declaração de Escopo do Projeto, e também pode atualizar alguns documentos do projeto, tais como: Registro de Partes Interessadas, Documento de Requisitos e a Matriz de Rastreabilidade. (PMI, 2013, p. 120). Jailton Marques & Márcio Moreira Página: 6
7 Figura 4: Descrição do processo Definir o Escopo (Adaptado de PMI, 2013, p. 120) Visão do RUP De acordo com a Rational (2001, p. 1), o RUP é um processo de engenharia de software de propriedade privada da Rational Software Corporation (empresa adquirida pela IBM em fevereiro de 2003) e que tem como foco principal garantir a produção de sistemas com qualidade de maneira padronizada. Ele sugere uma metodologia a ser utilizada pelos desenvolvedores de software com o objetivo de aumentar a produtividade com ganho de eficiência operacional. Como mostra a Figura 5, o RUP é dividido em 4 fases sequenciais (iniciação também chamada de concepção, elaboração, construção e transição) e 9 disciplinas (modelagem de negócios, requisitos, análise e design - projeto, implementação também chamada de distribuição, testes, implantação, gerenciamento de configurações e mudanças, gerenciamento de projetos e ambiente). Cada fase é composta de uma ou mais iterações. Cada disciplina tem um fluxo de trabalho (conjunto de atividades) a serem executadas conforme a iteração (fase do projeto). Cada atividade é composta de uma ou mais tarefas, que são executadas por um papel. O fluxo de trabalho é portanto um processo. (RATIONAL, 2001, p. 3). Figura 5: Fases, disciplinas e iterações do RUP (RATIONAL, 2008, Equipe, Bem Vindo). Jailton Marques & Márcio Moreira Página: 7
8 Segundo a Rational (2001, p. 4-7), as fases do RUP têm o seguinte propósito: iniciação: delimita o escopo do projeto e estabelece o caso de negócio (análise de custo x benefícios) para o sistema; elaboração: define uma arquitetura estável que seja capaz de suportar os requisitos mais significativos; construção: desenvolve o restante do sistema e; transição: garante que o software estará disponível e estável para seus usuários finais, lançando o produto. Em outras palavras a iniciação responde a pergunta se o projeto é viável, a elaboração responde a pergunta se ele é factível, a construção gera a versão beta para os testes de usuários e a transição conclui e entrega o software. Já o propósito das disciplinas é (Rational, 2001, p ): 1) Modelagem de negócios: documenta as necessidades de negócio, os processos de negócio utilizando casos de uso, garantindo o entendimento das partes interessadas e o alinhamento do negócio da organização com o sistema. 2) Requisitos: descreve o que o sistema deve fazer e decide quais dos requisitos do sistema serão automatizados pelo software. Isto permite que os clientes e os desenvolvedores fechem um acordo sobre as funcionalidades do software. 3) Análise e projeto: transforma os requisitos do software em modelos de projeto (conjunto de diagramas que descrevem o que o software faz e como) e produz as especificações técnicas para cada caso de uso do software. 4) Implementação: codifica (programa) os modelos lógicos e físicos em códigofonte, que é convertido em código-executável e testa os componentes desenvolvidos unitariamente (testa se eles funcionam de forma isolada). 5) Testes: verifica se todos os requisitos foram corretamente implementados, a interação entre os objetos e a integração adequada de todos os componentes do software documentando e corrigindo os defeitos encontrados. 6) Implantação: Busca a aceitação formal do software construído e cuida da colocação dele em produção, garantindo a entrega da versão final do software aos usuários. 7) Gerenciamento de configurações e mudanças: gerencia as mudanças e controla os inúmeros artefatos (documentos, diagramas, códigos fonte e executável, etc.) produzidos pela equipe do projeto gerando versões estáveis do software. Jailton Marques & Márcio Moreira Página: 8
9 8) Gerenciamento de projetos: está focada na gerência de projetos de software, fornece orientação prática para planejar e formar a equipe do projeto, gerenciar os riscos do projeto, e também para executar e monitorar o projeto em si. 9) Ambiente: configura o processo de desenvolvimento para o projeto em questão, seleciona, instala e suporta as ferramentas a serem utilizadas e os vários ambientes (individual, desenvolvimento, testes, produção, etc.). 3. Visões de Relacionamento entre o PMBOK e o RUP Esta seção explora as visões existentes sobre o relacionamento entre o RUP e o PMBOK. Nela será feita uma análise crítica dos relacionamentos encontrados na literatura científica. Para começar como mostrado por Charbonneau (2004, p. 54), destacado na Figura 6, o RUP é focado exclusivamente em projetos de software, enquanto o PMBOK pode ser utilizado para qualquer tipo de projetos. Além disto, o PMBOK cobre todos os aspectos da gestão de projetos, enquanto o RUP tem alguns focos específicos. Conforme Rational (2008, disciplina de Gestão de Projetos, p. 1) alguns dos pontos que o RUP não cobre são: gestão de pessoas (contratação, treinamento e instrução), gestão de custos (definição, alocação, etc.), gestão de compras (contratos com fornecedores e clientes). PMBOK RUP Qualquer tipo de projeto Somente práticas de gestão de projetos Cobre todos os aspectos da gestão de projetos Abordagem descritiva Específico para projetos de software Práticas para gestão de projetos de desenvolvimento de software Cobre alguns aspectos da gestão de projetos Abordagem prescritiva As fases são dependentes do domínio da As fases e as iterações são especificas para o aplicação desenvolvimento de software Figura 6: Características do RUP e do PMBOK (Adaptado de CHARBONNEAU, 2004, p. 54). Muitas pessoas confundem os grupos de processos do PMBOK com fases. Os grupos de processos (iniciação, planejamento, execução, monitoramento & controle, encerramento) são agrupamentos funcionais dos processos do PMBOK. Na figura mostrada na página 42 do PMBOK (2013, p. 42), projeto com múltiplas fases, fica claro que todos os grupos de processos são aplicados a cada fase do ciclo de vida do projeto. Jailton Marques & Márcio Moreira Página: 9
10 Ainda segundo Charbonneau (2004, p. 52), como mostrado na Figura 7, o PMBOK não sugere um faseamento específico para os projetos, ele deixa a cargo da engenharia aplicada ao projeto a escolha do ciclo de vida a ser utilizado, geralmente os projetos têm 4 ou 5 fases, chegando até 9 ou mais. O RUP, por ser específico para a fabricação de software, tem 4 fases bem características: iniciação (concepção), elaboração, construção e transição. Elemento PMBOK RUP Dividido em 4 ou 5 fases, Dividido em 4 fases: Iniciação, algumas vezes em até 9 ou Elaboração, Construção e Transição. Ciclo de Vida do mais. Cada fase é marcada pela Cada fase é dividida em uma ou Projeto entrega de um ou mais múltiplas iterações em todas as entregáveis. disciplinas através das atividades. Figura 7: Ciclo de vida do RUP e do PMBOK (Adaptado de CHARBONNEAU, 2004, p. 54). Um exemplo de leitura apressada com conclusões inadequadas pode ser visto em Hermont (2011, p. 1), mostrada na Figura 8, note que o autor afirma que o grupo de processos de Iniciação do PMBOK é equivalente à fase de Iniciação do RUP, e continua afirmando que o grupo de processos de Planejamento do PMBOK é equivalente à fase de Elaboração do RUP. Como mostrado na Figura 5, cada fase do RUP é uma fase de um projeto, logo, como visto no parágrafo anterior, tem todos os grupos de processos do PMBOK: iniciação, planejamento, execução, monitoramento & controle e encerramento. Isto pode ser facilmente comprovado os grupos de processos do PMBOK, das atividades das fases do RUP. Por exemplo, como mostrado na Figura 9, na fase de Iniciação do RUP, encontramos atividades dos grupos de processos do PMBOK: iniciação (I), planejamento (P), execução (E), monitoramento e controle (M) e encerramento (como a atividade Planejar a Próxima Iteração, não mostrada na figura, mas que deve ser feita no final de cada iteração). PMBOK Grupos RUP Fases Iniciação Iniciação Planejamento Elaboração Execução Controle e Monitoramento Construção Encerramento Transição Figura 8: Equívoco de equivalência do PMBOK e do RUP (HERMONT, 2011, p. 1). Jailton Marques & Márcio Moreira Página: 10
11 Figura 9: Grupos de processos do PMBOK da fase de Iniciação do RUP (Rational, 2008, Iniciação) Além da confusão citada acima, existem ainda várias outras confusões que podem ser vistas no trabalho de Temnenco (2008, p ), tais como: o RUP é uma alternativa ao PMBOK (o RUP não trata todas as disciplinas da gestão de projetos, vide 2º parágrafo desta seção), o RUP desvia a atenção da gestão de projetos (se fosse assim o RUP não teria uma disciplina específica para a gestão de projetos), o RUP não deixa trilha de auditoria (o RUP é fortemente embasado em artefatos, que são documentos auditáveis) e o RUP pode ser mapeado no PMBOK. O mapeamento do RUP no PMBOK na verdade não é necessário, como visto, os dois podem trabalhar juntos. Logo, o melhor seria remover as atividades de gestão de projetos do RUP e acrescentar os processos do PMBOK no RUP, ou alternativamente, completar a visão do RUP com os processos necessários do PMBOK. De forma resumida, como mostrado na Figura 10, o RUP tem uma boa cobertura das disciplinas de integração, escopo, tempo e qualidade do PMBOK; tem cobertura parcial das disciplinas de recursos humanos, comunicação e riscos; e tem baixa cobertura das disciplinas de custos, aquisições e partes interessadas. A gestão de configurações e mudanças do RUP é muito mais adequada a projetos de software do que o processo de controle integrado de mudanças do PMBOK. O RUP tem planejamento de recursos, mas não entra no mérito da estrutura da equipe do projeto, assim como não trata mobilização Jailton Marques & Márcio Moreira Página: 11
12 e nem desenvolvimento da equipe do projeto. O PMBOK trata as comunicações de forma mais completa e planejada do que o RUP. A gestão de riscos do RUP só não entra na análise quantitativa e análises de reservas dos riscos, como faz o PMBOK. O RUP prevê somente a identificação das partes interessadas, mas não entra no planejamento e nem na gestão do engajamento delas como prevê o PMBOK. Figura 10: Avaliação da gestão de projetos do RUP com base no PMBOK. A proposta de Temnenco (2008, p. 26) é a de substituição de quase todas as atividades de gestão de projeto do RUP pelos processos do PMBOK, exceto a gestão de configuração e mudanças. Esta proposta considera o fato que a disciplina de gestão de projetos do RUP foi escrita com base no PMBOK, conforme pode ser visto no material do RUP: A abordagem de gerenciamento de projeto descrita aqui foi influenciada pelo Project Management Institute's Project Management Body of Knowledge (PMBOK ) (RATIONAL, 2008, disciplina de Gestão de Projetos, p. 1). Como mostrado na Figura 11, a gestão de projetos do PMBOK pode guiar todo o projeto de desenvolvimento de software conduzido pelo RUP, desde a iniciação até o encerramento do projeto. Jailton Marques & Márcio Moreira Página: 12
13 Figura 11: Disciplinas do RUP trocando a gestão de projetos pelo PMBOK (TEMNENCO, 2008, p. 26). A proposta de combinação do RUP com o PMBOK já foi testada, como mostra o trabalho de Tetila (2007, p. 98) que os dois métodos podem ser utilizados de forma combinada, o que resultou numa redução de 4,3% na margem de erros de estimativas de projeto. Contreras & Janzen (2006, p. 19) também concluíram que a integração do PMBOK com o RUP é perfeitamente possível e viável, além disto eles sugerem também o uso do CMMI (Capability Maturity Model Integration) como outra fonte de boas práticas para esta integração. Outro texto interessante é o de Bainey (2004, p ), que dedica o capítulo 7 a mostrar como alinhar o PMBOK com RUP, o autor descreve como fazer esta integração tomando como base as fases do RUP, alinhando atividades (como), responsabilidades (quem) e artefatos (o que), terminando por concluir que este alinhamento não só é viável como também recomendável dependendo do tipo de projeto. Neste ponto cabe mais uma ressalva, o uso do CMMI como guia de uma boa prática de integração, conforme citado por Contreras & Janzen (2006, p. 19), é bem adequado, pois o CMMI é um modelo de avaliação da maturidade. Entretanto, o CMMI não deve ser visto como uma metodologia ou processo para desenvolvimento de software, como citado na pesquisa da Forrester, organizada por Dave West e Jeffrey S. Hammond (2010, p. 3) e mostrada na Figura 2. Um modelo de avaliação de maturidade, no máximo é um bom guia de boas práticas. Entretanto, não deve ser utilizado como metodologia, pois foi feito para avaliação da maturidade no uso de uma metodologia. Jailton Marques & Márcio Moreira Página: 13
14 4. Conclusões De acordo com o que foi exposto neste trabalho, a utilização do PMBOK com o RUP é possível, viável e em muitos casos recomendável. Uma das razões que torna isto possível é o fato da disciplina de gestão de projetos do RUP ter sido escrita com base no PMBOK (RATIONAL, 2008, disciplina de Gestão de Projetos, p. 1). O trabalho também mostra, que o uso conjunto do PMBOK e do RUP já foi testada com sucesso em vários projetos (TETILA, 2007, p. 98). O RUP tem uma boa cobertura das disciplinas de integração, escopo, tempo e qualidade do PMBOK; tem cobertura parcial das disciplinas de recursos humanos, comunicação e riscos; e tem baixa cobertura das disciplinas de custos, aquisições e partes interessadas. Como visto neste trabalho existem alguns equívocos na literatura sobre a utilização conjunta do RUP com o PMBOK. Como exemplo, Hermont (2011, p. 1) afirma que os grupos de processos do PMBOK são equivalentes às fases do RUP, quando na verdade as fases do RUP são compostas por iterações, que são pequenos projetos, e portanto, têm todos os grupos do PMBOK (iniciação, planejamento, execução, monitoramento & controle, encerramento). Como trabalho futuro pode ser feito uma proposta mais completa de substituições, exclusões e/ou inserções de atividades do RUP por processos do PMBOK. 5. Referências BAINEY, Kenneth. Integrated IT Project Management: A Model-centric Approach. Norwood: Artech House, Disponível em < >. Acesso em 22 mai BRASSCOM. Brasil TI BOP Book 2013/2014. Brasil, Relatório. Disponível em: <http://www.brasscom.org.br/>. Acesso em: 20 out CHARBONNEAU, S. Software Project Management -- A Mapping between RUP and the PMBOK. The Rational Edge, IBM, p , Disponível em: < >. Acesso em 16 mai Jailton Marques & Márcio Moreira Página: 14
15 CONTRERAS, César. JANZEN, Henrik. Managing Small Software Projects An Integrated Guide Based on PMBOK, RUP and CMMI. South Westphalia University of Applied Scriences, Campus Soest Disponível em < >. Acesso em 22 mai COTTRELL, W. Standards, compliance, and Rational Unified Process, Part I: Integrating RUP and the PMBOK. The Rational Edge, IBM, p , FORRESTER. The Forrester Wave: Agile Development Management Tools, Q Development-Management-Tools-Forrester-Q >. Acesso em: 13 mai GUIMARÃES, N. MOREIRA, M. Avaliação de Metodologias de Desenvolvimento de Sofware e Estudo da Aplicação do Scrum em uma Pequena Empresa. Pitágoras, Disponível em: < _esof_2_nataliaguimaraes_aplicacaodoscrum.pdf >, Acesso em: 08 mai HERMONT, B. C. Como o RUP e o PMBOK se complementam na gestão de projetos de software. Belo Horizonte: Disponível em: < >. Acesso em: 01 out KRUCHTEN, P. The Rational Unified Process: an introduction. Boston: Pearson Education, Inc, MILOSEVIC, D.; PATANAKUL, P. Standardized project management may increase development project success. International Journal of Project Management, Elsevier, p , Forrester Disponível em: < MORRIS, P. Reconstructing Project Management Reprised: A Knowledge Perspective. Project Management Journal, Vol. 44, No. 5, PMI, Disponível em: < Morris.ashx >. Acesso em: 14 mai Jailton Marques & Márcio Moreira Página: 15
16 PRESSMAN, R. S. Engenharia de Software - Uma Abordagem Profissional. Nova York: Editora McGraw-Hill, PRADO, D.; MANUEL, C. Maturidade em gerenciamento de projetos Relatório Mudanças Organizacionais 2012 Versão Resumida. Archibald & Prado Disponível em: < PesquisaMaturidade-2012_RelatorioGeral_V3.pdf >. Acesso em: 10 mai PRICE WATERHOUSE & COOPERS, PWC. Idéias e tendências: práticas atuais de gestão de projetos, portfólios e programas Terceira pesquisa global sobre a gestão de projetos Price Waterhouse & Coopers Disponível em: < >. Acesso em: 12 mai PROJECT MANAGEMENT INSTITUTE, PMI. PMSURVEY.ORG A global initiative of PMI Chapters - Relatório Nacional Project Management Institute Disponível em: < >. Acesso em: 11 mai PMI (PROJECT MANAGEMENT INSTITUTE). A Guide to the Project Management Body of Knowledge (PMBOK Guide). Fifth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, RATIONAL SOFTWARE. Rational Unified Process: best pratices for software development teams. Rev. 11/01. Cupertino, Califórnia, USA: Rational Software, Disponível em: < https://www.ibm.com/developerworks/rational/library/content/03july/1000/1251/1251_ bestpractices_tp026b.pdf >. Acesso em 15 mai RATIONAL SOFTWARE. Rational Unified Process 7.5 For Large and Small Projects. IBM Rational RODRIGUEZ-REPISO, L.; SETCHI, R. & SALMERON, J.L. Modelling IT projects success: emerging methodologies reviewed. Technovation, Elsevier, p , Jailton Marques & Márcio Moreira Página: 16
17 SOMMERVILLE, I. Software Engineering. 6. ed. Pearson Education Limited, TEMNENCO, V. A Project Manager's RUP in review. The Rational Edge, IBM, p , Disponível em: < >. Acesso em: 08 mai TETILA, Everton. Processo de Estimativa de Software com a Métrica Use Case Points, PMBOK e RUP. Universidade Paulista Disponível em < vertoncastelaotetila.swf >. Acesso em 22 mai VARGAS, R. V. Gerenciamento de projetos: estabelecendo diferenciais competitivos. 6. ed. Rio de Janeiro: Editora Brasport, ZUZER, W.; HEIL, S.; GRECHENIG, T. Software quality development and assurance in RUP, MSF and XP A comparative study. ACM Press, Disponível em: < >. Acesso em: 13 mai Jailton Marques & Márcio Moreira Página: 17