A MIGRAO DO PMBOK PARA O RUP

Antonio Roberto Albuquerque.

UNIP, Universidade Paulista.

Luciano Schiavo.
UNIP, Universidade Paulista.

ABSTRACT
Some enterprises, looking for more effectiveness and efficiency, has choose to follow and implement PMBOK. The article below will care one specific case study where one company dont get its benefits applying on software development and choose to customize with RUP. On development of the article we will analyse the structure about the models used and to identify the comum and opposite points. It is showed a set of possible solutions will be adopted and the better that adapts necessity of contracting company.

Key-words: Processo, PMBOK, RUP Tema: Engenharia Produto/Processo. RESUMO

Algumas empresas, buscando maior eficincia e eficcia, tem optado por seguir e implementar o PMBOK. O artigo abaixo tratar de um caso especfico onde uma delas no obteve exito em sua utilizao no desenvolvimento de software e resolveu customiz-lo com o RUP. No desenvolvimento do artigo analisaremos a estrutura de cada um dos modelos utilizados e, atravs de um contraste, sero identificados os pontos em comum ou divergentes. apresentado um conjunto de possveis solues que poderiam ser adotadas e selecionada a que melhor se adapta as necessidades da empresa contratante.

1. INTRODUO O Project Management Institute (PMI) possui mais de 80.000 membros espalhados pelo mundo. Ele publicou o Project Management Body of Knowledge, tambm chamado PMBOK. Por se tratar de um trabalho genrico vrias empresas o tem utilizado como metodologia para melhorar o gerenciamento e integrao de recursos. Este artigo abordar um estudo de caso prtico onde a utilizao do PMBOK no demonstrou bons resultados na aplicao de desenvolvimento de software e, a partir de ento, a empresa resolveu customiza-lo com o RUP. 2. PMBOK Project Management Body of Knowledge (PMBOK) ou Universo de conhecimento em gerncia de projetos representa o somatrio de conhecimentos dentro da profisso de gerncia de projetos, sendo identificado como guia para os profissionais da rea. Este guia de autoria do Standard Committee (Comit de Padronizao) do Project Management Institute (PMI) e procura contemplar os principais aspectos que podem ser abordados no gerenciamento de um projeto genrico. A partir de 1999 ele foi aceito como padro de gerenciamento de projetos pelo ANSI American National Standards Institute.

3. ESTRUTURA DO PMBOK As prticas no PMBOK sugerem a seguinte estrutura para o gerenciamento de processos: grupos de processos e reas de conhecimento. O detalhamento desta estrutura segue nos subitens abaixo. 3.1 Grupos de Processos Os processos de gerncia de projetos podem ser organizados em cinco grupos, cada um deles contendo um ou mais processos. 3.1.1 Processo de Iniciao O processo de iniciao refere-se a autorizao do projeto ou fase. 3.1.2 Processo de planejamento O processo de planejamento refere-se a definio e refinamento dos objetivos e seleo da melhor das alternativas de ao para alcanar os objetivos que o projeto estiver comprometido em atender. 3.1.3 Processo de execuo O processo de execuo preocupa-se em coordenar pessoas e outros recursos para realizar o plano. 3.1.4 Processo de controle O processo de controle assegura que os objetivos do projeto esto sendo atingidos, atravs da monitorao regular do seu progresso para identificar variaes do plano e, portanto, aes corretivas podem ser tomadas quando necessrias. 3.1.5 Processo de encerramento O processo de encerramento formaliza a aceitao do projeto ou fase e encerra-o de forma organizada. 3.2 reas de conhecimento da Gerncia do Projeto Os processos de gerncia de projetos se relacionam com a descrio, a organizao e a concluso dos trabalhos do projeto (pmbok, 2000). As reas de conhecimento da gerncia de projetos descreve os conhecimentos e prticas em gerncia de projetos em termos de processos que a compem. Estes processos foram organizados em nove reas de conhecimento conforme descrito abaixo (pmbok, 2000). 3.3 Gerncia de Integrao Descreve os processos necessrios para assegurar que os diversos elementos do projeto sejam adequadamente coordenados. 3.3.1 Gerncia de Escopo Descreve os processos necessrios para assegurar que o projeto contemple todo o trabalho requerido, e nada mais que o trabalho requerido, para completar o projeto com sucesso. 3.3.2 Gerncia de Tempo Descreve os processos necessrios para assegurar que o projeto termine dentro do prazo previsto.

3.3.3 Gerncia de Custo Descreve os processos necessrios para assegurar que o projeto seja completado dentro do oramento previsto. 3.3.4 Gerncia de Qualidade Descreve os processos necessrios para assegurar que as necessidades que originaram o desenvolvimento do projeto sero satisfeitas. 3.3.5 Gerncia de Recursos Humanos Descreve os processos necessrios para proporcionar a melhor utilizao das pessoas envolvidas no projeto. 3.3.6 Gerncia das Comunicaes Descreve os processos necessrios para assegurar que a gerao, captura, distribuio, armazenamento e pronta apresentao das informaes do projeto sejam feitas de forma adequada e no tempo certo. 3.3.7 Gerncia dos Riscos Descreve os processos que dizem respeito a identificao, anlise e resposta aos riscos do projeto. 3.3.8 Gerncia das Aquisies Descreve os processos necessrios para a aquisio de mercadorias e servios fora da organizao que desenvolve o projeto. 4. RATIONAL UNIFIED PROCESS (RUP) Booch, Raumbaugh e Jacobson propuseram a UML como uma notao de modelagem orientada em objetos, independente de processos de desenvolvimento. Alm disso, propuseram o Processo Unificado Rational (Rational Unified Process - RUP), que utiliza a UML como notao de uma srie de modelos que compem os principais resultados das atividades de uma metodologia. O RUP descente de mtodos anteriores propostos pelos propositores da UML (Paula, 2001). 4.1 Definio Kruchten (Kruchten, 2003) afirma que, embora o RUP sugira um processo, ele pode ser considerado como : uma abordagem de desenvolvimento de software que interativa, centrada na arquitetura e dirigida por casos de uso, ou seja, levantamento de requisitos baseados na viso do usurio. um processo de engenharia de software bem definido e bem estruturado. Ele claramente define quem o responsvel pelo que, como as coisas so feitas e quando faze-las. um produto processo que fornece um framework de processo customizvel para a engenharia de software. Essas customizaes podem ser feitas para suportar pequenas equipes e abordagens disciplinadas ou menos formal para o desenvolvimento. Esse produto fornecido pela Rational.

4.2 Rup como um Processo de Engenharia de Software O RUP foi modelado usando o Software Process Engineering Model (SPEM) que um padro para modelagem de processos baseado em UML. O processo tem duas estruturas, ou duas dimenses, a saber: Estrutura dinmica: representa a dimenso do tempo no processo. Estrutura esttica: descreve como elementos do processo so agrupados em disciplinas. Utilizando a estrutura apresentada, o RUP apresentado da seguinte maneira: Figura 1 - Estrutura esttica e dinmica do RUP
Tempo

A estrutura que representa o tempo denominada FASE. A estrutura que representa os elementos do processo so as DISCIPLINAS. 4.2.1 Fase Uma fase definida como a dimenso de tempo entre duas maiores marcas (major milestones) de processos, durante a qual um conjunto bem definido de objetivos encontrado, artefatos so completados, e a deciso tomada no sentido de ir para a prxima fase (Royce, 1998) e maiores marcas pode ser definido como eventos de grandes sistemas organizados no final de cada fase de desenvolvimento para fornecer visibilidade aos seus problemas, sincronizar o gerenciamento, perspectivas de engenharia e verificar que os objetivos de cada fase foi obtido (Royce, 1998) 4.2.1.1 Objetivos para cada Fase Iniciao Esta fase tem por objetivo, sinteticamente falando: estabelecer o escopo do projeto; selecionar os use cases crticos do negcio; buscar ao menos uma arquitetura candidata; elaborar cronograma e estimativas de custos do projeto; estimar os riscos do projeto e preparar o ambiente de apoio ao projeto. Elaborao Esta fase tem por objetivo, sinteticamente falando: assegurar que a arquitetura, os requisitos e os planos estejam estveis para prever o resto do projeto, resolver todos os riscos de arquitetura do projeto, produzir um prottipo, demonstrar que a arquitetura suportar os requisitos e estabelecer um ambiente de apoio para o projeto.

Elementos do processo

Construo Esta fase tem por objetivo, sinteticamente falando: minimizar os custos de desenvolvimento; atingir qualidade de forma rpida e prtica, obter verses utilizveis o quanto antes, completar anlise, design e implementao, assegurar-se que o usurio est pronto para a entrega, buscar paralelismo nas atividades de desenvolvimento Transio Esta fase tem por objetivo, sinteticamente falando: realizar beta testes para validar o produto; executar teste paralelo com sistemas legados, converter base de dados existentes, treinar usurios e resolver problemas de implantao. 4.2.2 Disciplina Uma Disciplina uma coleo de atividades relacionadas que esto ligadas a maior rea de interesse dentro do processo em geral (Kruchten, 2003) 4.2.2.1 Objetivos de cada disciplina Modelagem Corporativa Esta fase tem por objetivo, sinteticamente falando: entender a estrutura e a dinmica da organizao na qual o sistema ser entregue, identificar problemas correntes na organizao e possveis aperfeioamentos; assegurar que o cliente, o usurio final e desenvolvedores possuam a mesma compreenso da empresa e produzir os requisitos de sistemas necessrios para suportar os objetivos da organizao. Requisitos Esta fase tem por objetivo, sinteticamente falando: estabelecer e manter o consentimento entre clientes e stakeholders sobre o que o sistema deve fazer; fornecer uma melhor compreenso dos requisitos aos desenvolvedores de sistemas; definir os limites do sistema; fornecer as bases para o planejamento das iteraes, estimativa de custo e tempo de desenvolvimento e definir as interfaces do sistema baseado nas necessidades e objetivos dos usurios. Anlise e Design Esta fase tem por objetivo, sinteticamente falando: transformar os requisitos dentro de um design do que ser o sistema; desenvolver uma arquitetura robusta para o sistema e adaptar o design para combinar com o ambiente de implementao, projetar para performance Implementao Esta fase tem por objetivo, sinteticamente falando: preparar a organizao do cdigo em termos de implementao de subsistemas, organizados em layers; implementar classes e objetos em termos de componentes (cdigo fonte, binrios, executveis, etc); testar os componentes desenvolvidos como unidades e integrar os resultados obtidos por implementadores individuais (ou equipes) em um sistema executvel. Teste Esta fase tem por objetivo, sinteticamente falando: verificar a interao entre os objetos; verificar a integrao de todos os componentes de software; verificar se

todos os requisitos foram implementados corretamente e verificar os defeitos e assegurar que eles foram tratados antes da entrega do software Instalao Esta fase tem por objetivo, sinteticamente falando: descrever as atividades associadas a verificao que o software est disponvel ao usurio final. Gerenciamento de Mudana e Configurao Esta fase tem por objetivo, sinteticamente falando: identificar itens de configurao; restringir alteraes para aqueles itens; auditar as alteraes feitas neles e definir e gerenciar as alteraes daqueles itens. Gerenciamento de Projeto Esta fase tem por objetivo, sinteticamente falando: fornecer uma estrutura para gerenciamento de projeto de software; fornecer um guia prtico para planejamento, recrutamento, execuo e monitoramento de projeto e fornecer uma estrutura para o gerenciamento de risco. Ambiente Esta fase tem por objetivo, sinteticamente falando: focar as atividades necessrias para configurar o processo para o projeto; descrever as atividades requeridas para desenvolver as guias mestres no suporte do projeto e fornecer, para a organizao de desenvolvimento de software, o ambiente de processos e ferramentas que suportaro a equipe de desenvolvimento. 5. SOLUES PROPOSTAS Para tentar solucionar este problema sero aprensentadas vrias propostas, conforme descrio abaixo. 5.1 Adoo do RUP A primeira alternativa seria a adoo do RUP com a otimizao da disciplina chamada gerenciamento de projeto. A disciplina gerenciamento de projeto seria otimizada com as prticas do PMBOK e possivelmente teramos uma disciplina superespecializada. Com a adoo desta opo teramos que implementar as fases do RUP na empresa em detrimento dos grupos de processos. A partir de ento todos os outros projetos seriam executados na nova abordagem, ou seja, haveria uma substituio dos processos de gerenciamento de processo pelas fases do RUP. Tal alternativa inicialmente torna-se impraticvel pois a empresa j est estruturada com as prticas propostas pelo PMBOK. 5.2 Incompatibilidade entre os modelos Uma segunda alternativa seria a de incorporar os conceitos e metodologia existentes no RUP para os j implementados pelo PMBOK. Partindo dessa premissa temos seguintes problemas estruturais, conforme demonstrado nas figuras abaixo. Figura 2 - grupos de processos PMBOK

Iniciao

Planejamento

Execuo

Controle

Encerramento

Figura 3 - fases no RUP

Iniciao Elaborao Construo Transio

No PMBOK temos uma estrutura com 5 divises e uma estrutura com 4 divises no RUP. Alm das diferenas estruturais numricas existe a necessidade de verificar se o mesmo tipo de controle implementado ao final de cada diviso. Considerando o objetivo e caractersticas de cada um dos modelos presume-se inicialmente que os controles so diferentes e uma anlise mais aprofundada seria necessria para fazer o devido diagnstico. Nos elementos de cada modelo que possuimos as maiores diferenas. Enquanto o PMBOK utiliza dos conceitos de gerncia para otimizar os recursos existentes no projeto, o RUP preocupa-se, atravs das disciplinas, em coletar e estruturar informaes para o desenvolvimento de sistemas. Figura 4 - referncia cruzada entre reas de conhecimento(PMBOK) e disciplinas(RUP)
reas de conhecimento no PMBOK Gerncia de integrao Gerncia de escopo Gerncia de tempo Gerncia de custo Gerncia de qualidade Gerncia de recursos humanos Gerncia de comunicaes Gerncia de risco Gerncia de aquisies Disciplinas no RUP Modelagem de Negcios Requisitos Anlise e Design Implementao Teste Implantao Gerenciamento de configurao e mudana Gerenciamento do Projeto Ambiente

5.3 Elaborao de um modelo tridimensional Embora haja a incompatibilidade entre os modelos poderamos considerar a adio de mais uma dimenso para a consolidao de um novo modelo. Levando em considerao que primeiro estariamos estruturando a rea de desenvolvimento de sistemas e a partir de ento nos adequarmos a todo o resto da empresa poderamos adotar o RUP e adicionar uma nova dimenso ao mesmo. Dentro desse contexto poderamos adicionar a reas de conhecimento s fases e disciplinas. Um esboo inicial desse modelo seria conforme a figura abaixo. Figura 5 - fases X disciplinas X reas de conhecimento

reas de conhecimento

Fases
di sc ip lin as

Esta adoo possui o problema de falta de sintonia com os grupos de processos j institudos pelo PMBOK, pois fatalmente um sistema s iria para a rea de desenvolvimento se houvesse a viabilidade de desenvolver esse novo projeto (o desenvolvimento de um novo sistema seria considerado como um novo projeto na fase de iniciao do PMBOK. Nesta fase seria verificada a viabilidade ou no de prosseguimento do projeto). Outro problema que a rea de conhecimento estaria sendo praticamente subutilizada pois a disciplina gerenciamento de projeto possui as caractersticas e instrumentos que seriam necessrios para o contexto de gerenciamento de projeto no desenvolvimento de um sistema. Consequentemente poderamos retirar a dimenso de reas de conhecimento e adicionar os grupos de processos onde teramos as seguintes dimenses: grupos de processos, fases e disciplinas. Veja como seria graficamente esta estrutura atravs da figura abaixo. Figura 6 - fases X disciplinas X grupos de processos

grupos de processos

fases
ip lin as

Esta pode ser uma medida alternativa intermediria para comear a estruturao da rea de desenvolvimento de sistemas da empresa com as duas metodologias. Porm o problema de integrao com toda a empresa ainda persiste; no podemos simplesmente desprezar as reas de conhecimento propostas pelo PMBOK. Embora estejam discriminados com nomes diferentes possvel identificar a evoluo do tempo em cada uma das metodologias. A dimenso do tempo estruturada no PMBOK aquela onde consta os grupos de processos, ou seja, iniciao, planejamento, execuo, controle e encerramento. A dimenso do tempo apresentada pelo RUP refere-se as fases cujos nomes so: iniciao, elaborao, construo e transio.

di

sc

Essas duas dimenses podem ser apenas uma pois o andamento do projeto ou do sistema seguem a mesma linha do tempo. Por motivo de economia e praticidade (a empresa j est estruturada para os grupos de processos) optaremos para aquele modelo definido pelo PMBOK. Graficamente teramos o seguinte modelo: Figura 7 - Representando a linha do tempo em apenas um eixo

reas de conhecimento

Esse modelo permitiria area de desenvolvimento de sistemas a adoo das disciplinas do RUP no decorrer do tempo comum a todos os projetos. O desenvolvimento de um sistema tambm ser considerado como um projeto. Para todos os outros projetos existentes no ser necessrio a utilizao das disciplinas que so vlidas apenas para a rea de desenvolvimento de sistemas. Esta abordagem a considerada como tima onde seria necessrio apenas um ajuste fino como veremos no tpico abaixo. 5.3.1 Ajuste fino entre as duas abordagens Embora h uma evoluo no refinamento das idias citadas anteriormente ainda temos outro problema que deve ser abordado. O PMBOK e o RUP abordam problemas comuns em alguns pontos. Por exemplo, que riscos considerar ? como otimizar e utilizar a equipe disponvel no projeto? Lembrem-se que ainda tenho a disciplina de gerenciamento de projetos no modelo apresentado. Dessa forma deve ser feito um trabalho que busque identificar a interseco entre os dois processos e fornecer uma linha de implementao a partir do PMBOK. Figura 8 - interseco da metodologia PMBOK e RUP

di sc ip lin as

grupos de processos

PMBOK

RUP

MIGRAO

Estre trabalho buscaria retirar as redundncias existentes em cada modelo que so representadas pela interseco do grfico. Ao final desta abordagem teramos o PMBOK/RUP enxuto baseado em um modelo tridimensional.

5.3.2 A empresa considera a rea de desenvolvimento como contratada Esta perspectiva permite a implementao de toda a filosofia RUP, dentro da rea de desenvolvimento de software, sem impactar nos processos atuais. 6. A SOLUO ADOTADA Devido ao PMBOK ter sido implementado na empresa anteriormente suas caractersticas deveriam ser preservadas. Baseado nesta caracterstica o RUP foi customizado com apenas algumas disciplinas que consideradas iniciais para o incio do desenvolvimento de sistemas orientado a objetos. A estrutura utilizada foi a considerada intermediria com as seguintes dimenses: fases, disciplinas e grupos de processos. Este tipo de adoo permitir que a empresa evolua naturalmente at a soluo considerada como tima, fazendo as medies e alteraes necessrias no processo durante seu andamento. 7. CONCLUSO O PMBOK pode ser customizado para a rea de desenvolvimento de sistemas e o RUP pode ser customizado para atender as caractersticas de desenvolvimento de uma empresa. A unio dos dois pode significar uma sinergia que refletir nos lucros e qualidade dos trabalhos. REFERNCIA BIBLIOGRFICA PAULA, W. DE PDUA FILHO, Engenharia de Software: Fundamentos, mtodos e padres, Rio de Janeiro, LTC Editora, 2001. PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK Guide): Edio 2000. KRUCHTEN, PHILIPPE, Rational Unified Process made easy: A practioners guide to the RUP, Addison-Wesley, 2003. RUP - Rational Unified Process; 2002.05.01.01. ROYCE, WALKER; Software Project Management: A Unified Framework, Addison Wesley; 1998. GRAHAN, IAN; Object Oriented Method: Principles & Practice (3th edition); AddisonWesley; 2001. JACOBSON, IVAR; Object-Oriented Software Engineering: A Use Case Driven Approach; Addison-Wesley; 1992. PETERS, JAMES F., Engenharia de Software: Teoria e Prtica, Rio de Janeiro, Editora Campus, 2001. PRESSMAN, ROGER S., Engenharia de Software- (3 edio), So Paulo, Ed. Makron Books, 1995. PRESSMAN, ROGER S., Engenharia de Software- (5 edio), So Paulo, Ed. McGrawHill, 2002 SILVA, ALBERTO MANUEL RODRIGUES DA, UML, Metodologias e Ferramentas Case, Ed. Centro Atlntico, Portugal, 2001.