Gerenciamento de projetos de software combinando PMBOK e RUP

2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
2… Contecsi — Congresso Internacional de Gest o da Tecnolo
Internacional Conference on Information Systems and Technolog
01-03 de Junho de 2005 S o Paulo/SP Brasil
Gerenciamento de projetos de software combinando PMBOK e RUP
Jefferson Leandro Anselmo (Mestrando em Administra o pela FEA/USP e Analista de Sistemas
da Promon Tecnologia) - [email protected]
Mauro Sergio Mantovano (Aluno MBA em gest o de projetos pela FGV e Analista de Sistemas
da Promon Tecnologia) - [email protected]
Antonio Cesar Amaru Maximiano (Mestre e Doutor em Administra o de Empresas e Professor
da FEA/USP) - [email protected]
O aprimoramento da qualidade dos projetos de engenharia de software e dos produtos resultantes
tem sido objeto de preocupa o constante nos ltimos anos. O Project Management Body of
Knowledge (PMBOK) e o Rational Unified Process (RUP) s o metodologias desenvolvidas com
essa finalidade. Este artigo baseia-se em experi ncias da Engenharia de Software da Promon
Tecnologia Ltda., com projetos que procuraram conciliar estas duas metodologias. Os objetivos
deste trabalho s o (1) relatar a experi ncia e (2) fornecer proposi es sobre como conduzir o
trabalho de concilia o em novos projetos. A experi ncia aqui relatada sugere que a integra o
das duas metodologias oferece um conjunto completo e robusto de processos para a condu o de
projetos de Engenharia de Software. Este trabalho tem por base conceitual (1) o PMBOK, um
guia cujo objetivo descrever e consolidar o conjunto de conhecimentos e pr ticas relativos ao
gerenciamento de projetos e (2) o RUP, que procura definir um framework completo e
customiz vel para o desenvolvimento de projetos de engenharia de software (Jacobson, Booch &
Rumbaugh, 1999). O trabalho compreende os seguintes t picos: Introdu o, Descri o sucinta do
Project Management Body of Knowledge (PMBOK), Descri o sucinta do Rational Unified
Process (RUP), Relato da experi ncia — o caso Promon e Considera es finais
Palavras-chave: gerenciamento de projetos; engenharia de software, projetos.
GERENCIAMENTO DE PROJETOS DE SOFTWARE COMBINANDO PMBOK E RUP
INTRODU O
Em meados da d cada de 90 foram realizadas importantes an lises sobre o estado da ind stria de
software. Essas an lises chegaram conclus o de que o percentual de sucesso dos projetos era
muito baixo e somente 10% eram entregues como os custos e os prazos haviam sido estimados.
Desde ent o, apesar dos esfor os de aprimoramento dos modelos de desenvolvimento e ger ncia,
ainda se observam altos ndices de falhas (Rad & Raghavan, 2000). Segundo Crawford (2000),
grande parte dos problemas ocorre devido falta de processos adequados e padronizados. Jones
(1996) enfatiza que os fatores associados aos desastres est o diretamente relacionados falta de
dom nio das t cnicas de gerenciamento ou s o conseq ncia de pr ticas err neas.
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
Nesse contexto, como resultado de um processo de consolida o de v rias metodologias
existentes, surge o Rational Unified Process (RUP), propondo um processo robusto de
desenvolvimento de software com o objetivo de uniformizar e melhorar a qualidade dos projetos
e dos produtos resultantes. A metodologia pode ser considerada, mais que um simples processo,
um framework gen rico que pode ser especializado para v rias classes de sistemas em reas
distintas, para n veis diferentes de complexidade e para qualquer tamanho de projeto. O RUP n o
define em detalhes, por m, alguns t picos referentes ao gerenciamento do projeto, como
planejamento de custos, planejamento de suprimentos, planejamento de recursos e mitiga o de
riscos.
Por outro lado, o Project Management Institute (PMI), criado para melhorar a qualidade da
gest o de projetos, publicou, em 1996, a primeira edi o do A Guide to the Project Management
Body of Knowledge (PMBOK), cujo objetivo descrever e consolidar o conjunto de
conhecimentos e pr ticas relativos gest o de projetos. O conjunto de processos descritos pelo
PMBOK pretende aplicar-se a todo tipo de projeto, inclusive engenharia de software. No entanto,
assim como no RUP h falta de princ pios de gerenciamento, no PMBOK n o se encontram
diretrizes para classes muito espec ficas de projetos, como o pr prio caso da engenharia de
software.
Apesar disso, os processos definidos pelo RUP e pelo PMBOK s o largamente utilizados e
considerados quase como padr es em suas reas de compet ncia. Assim, natural supor que em
um projeto de engenharia de software, o produto seja gerado baseado de acordo com os processos
do RUP e o empreendimento gerenciado seguindo os pressupostos do PMBOK.Para que ambas
as metodologias sejam simultaneamente utilizadas com efic cia, necess rio definir como a
din mica e as fases e ciclos de vida de ambas podem ser sincronizados e como suas atividades e
produtos podem ser compatibilizados. Em resumo, necess rio um esfor o de fundir essas duas
proposi es conceituais.
Este trabalho prop e-se a apresentar como os dois frameworks podem ser utilizados em conjunto,
de forma a se obter processos adequados condu o de projetos de engenharia de software.
Primeiramente, ser o descritas as caracter sticas b sicas do PMBOK e do RUP, de maneira a
fornecer a base necess ria para a an lise da combina o de ambos. Ao final, ser o explicitadas as
conclus es obtidas durante a execu o desse trabalho e as considera es finais.
Tendo-se por base a experi ncia com a gest o de projetos de Engenharia de Software na Promon
Tecnologia Ltda, a partir de 2000. O produto resultante, a unifica o dos dois frameworks, foi
colocado disposi o das demais equipes e passou a ser utilizado pela empresa na condu o de
seus projetos.
DESCRI O SUCINTA DO PROJECT MANAGEMENT BODY OF KNOWLEDGE
(PMBOK)
Objetivando identificar e descrever as pr ticas de gerenciamento de projetos geralmente aceitas,
aplicadas e tidas como v lidas, o Project Management Institute (PMI), a maior organiza o
mundial de profissionais de gerenciamento de projetos, vem atuando em v rias frentes desde
1981. A primeira delas tinha como principal objetivo o desenvolvimento dos procedimentos e
conceitos necess rios para dar o embasamento te rico e forma profiss o de gerenciamento de
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
projetos. Seus resultados foram publicados no Project Management Journal de agosto de 1983,
incluindo um c digo de tica, uma proposta de padroniza o de processos de trabalho e guias
para certifica o de profissionais e qualifica o de institui es de ensino em gerenciamento de
projetos.
Essa publica o deu origem a grandes debates sobre os padr es propostos. Em 1984, o PMI
iniciou um segundo projeto visando adequar esses padr es s pr ticas e conhecimentos de
gerenciamento de projetos da poca. Como resultado, um novo documento, denominado The
Project Management Body of Knowledge, foi editado, expandindo o documento original e
incorporando diversas sugest es e pr ticas. Ap s a publica o do novo documento, os debates
continuaram. Em 1991, o PMI iniciou novo projeto para an lise e incorpora o dos diversos
coment rios recebidos. A publica o do A Guide to the Project Management Body of Knowledge
(PMBOK Guide), em 1996, foi resultado desse projeto. O PMBOK Guide considerado pelo
PMI como um documento em constante evolu o. A edi o do ano de 2000 foi reconhecida
como padr o pela American National Standard (ANSI/PMI 99-001-2000) em 27 de mar o de
2001.
O PMBOK Guide consiste de um subconjunto dos conhecimentos sobre o gerenciamento de
projetos. Esse subconjunto agrupa e consolida os conhecimentos e pr ticas da gest o de projetos
que s o geralmente aceitos, aplicados e tidos como v lidos. Geralmente aceitos , nesse
contexto, significa que os conhecimentos e pr ticas descritas s o aplic veis grande maioria dos
projetos e que h um grande consenso da comunidade de gest o de projetos a respeito da
utilidade e valor desses conhecimentos e pr ticas. N o significa, no entanto, que esses
conhecimentos e pr ticas descritas s o ou devem ser aplicados uniformemente em todos os
projetos: os gestores do projeto sempre s o respons veis por determinar o que apropriado ou
n o. Al m disso, o PMBOK Guide tamb m se prop e a fornecer um vocabul rio comum para os
interessados na disciplina de gest o de projetos, aumentando a efici ncia da comunica o dentro
da comunidade.
O PMBOK focaliza a descri o dos processos relativos gest o de um projeto gen rico
(processos de gerenciamento) e n o nos aspectos espec ficos ou t cnicos dos projetos (processos
de produ o). Os processos descritos no PMBOK Guide s o agrupados em cinco grupos (Figura
1): inicia o, planejamento, execu o, controle e fechamento.
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
Figura 1: Fluxo dos grupos de processos. Fonte: Adaptado do PMBOK 2000
Os processos de inicia o definem restri es, pr -requisitos e outras informa es para o inicio
dos processos de planejamento e execu o. Durante os processos de inicia o, todas as
informa es relevantes para o planejamento devem ser levantadas, analisadas e relacionadas. Os
processos de planejamento definem e refinam os objetivos do processo principal e produzem o
plano de trabalho para alcan ar esses objetivos. Utilizam como base as informa es coletadas e
compiladas pelos processos de inicia o, trabalhando-as de maneira a planejar o trabalho a ser
executado durante os processos de execu o. Os processos de execu o coordenam pessoas e
outros recursos para encaminhar a realiza o do projeto. Esses processos seguem o plano
produzido pelos processos de planejamento e t m como resultado o pr prio resultado do projeto
ou parte desse resultado. Os processos de controle asseguram que os objetivos do projeto sejam
alcan ados e que o plano do projeto seja seguido ou ent o atualizado. Al m disso, os processos
de controle tamb m mensuram os processos de execu o. Finalmente, os processos de
fechamento formalizam o t rmino do projeto ou processo principal.
Esse fluxo aplic vel tanto ao projeto como um todo quanto a partes do projeto, de maneira
iterativa. Dessa forma, cada fase do projeto pode ter seus processos enquadrados nos cinco
grupos e o relacionamento entre eles ser o mesmo do relacionamento ilustrado pela Figura 1.
Al m disso, esse fluxo repetido em cada uma das fases do projeto. A Figura 2 ilustra essa
repeti o.
Figura 2: Rela o entre os grupos de processos entre as fases distintas. Fonte: PMBOK
2000
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
O fluxo descrito acompanha o projeto ao longo das fases do ciclo de vida, sendo que cada grupo
de processos apresenta intensidade de utiliza o diferente ao longo de cada fase do ciclo. A
Figura 3, tamb m adaptada do PMI (2001,p.31) ilustra esse comportamento.
Figura 3: Distribui o do n vel de atividade dos processos durante as fases do projeto.
Fonte: PMBOK 2000
No in cio de cada fase, os processos de inicia o consomem a maioria dos recursos. Com o
decorrer do tempo, os processos de planejamento come am a consumir mais recursos seguidos
dos processos de execu o e, finalmente, dos processos de fechamento. Os processos de controle
t m uma atua o mais uniforme durante todo o ciclo de vida do projeto. Esse ciclo repetido em
cada uma das fases do projeto.
Esses processos agrupam as atividades de nove reas de conhecimento (Figura 4): integra o,
escopo, prazo, custos, qualidade, recursos humanos, comunica o, risco e suprimentos:
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
Figura 4: rea de conhecimento do PMBOK
• Gerenciamento da Integra o: agrupa os processos necess rios para que os v rios elementos
do projeto estejam coordenados. Esses processos consistem no desenvolvimento do plano do
projeto, execu o desse plano e controle integrado de mudan as.
• Gerenciamento de Prazo: consiste nos processos de defini o, estimativa de dura o e
sequenciamento, em um cronograma, das atividades necess rias para que o projeto seja
completado no prazo necess rio, bem como pelos processos de controle da execu o desse
cronograma.
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
• Gerenciamento de Escopo: consiste do conjunto de atividades necess rias para assegurar que
o projeto inclua todo e somente o trabalho necess rio para que o mesmo seja completado com
sucesso. Essas atividades incluem a inicia o do projeto, o planejamento, o detalhamento, a
verifica o e o controle de altera es de escopo.
• Gerenciamento de Custos: consiste nos processos de planejamento de recursos e estimativa,
or amento e controle de custos, necess rios para que o projeto seja executado de acordo com
o or amento aprovado.
• Gerenciamento de Recursos Humanos: agrupa os processos de planejamento organizacional,
recrutamento e desenvolvimento da equipe, respons veis pelo uso eficiente das pessoas
envolvidas no projeto.
• Gerenciamento de Suprimentos: consiste nos processos respons veis pela aquisi o de bens e
servi os de fontes externas organiza o que est realizando o projeto e que s o necess rios
para a condu o do projeto. Inclui os processos de planejamento dos suprimentos,
planejamento das solicita es, solicita o, sele o de fornecedores, administra o e
fechamento de contratos.
• Gerenciamento da Comunica o : consiste nos processos necess rios para assegurar a correta
gera o, coleta, dissemina o, armazenamento e descarte das informa es a respeito do
projeto. Incluem os processos de planejamento da comunica o, distribui o da informa o,
elabora o de relat rios de performance e fechamento administrativo do projeto.
• Gerenciamento de Riscos: agrupa os processos de planejamento do gerenciamento,
identifica o e an lise qualitativa e quantitativa dos riscos, plano de conting ncia e
monitoramento e controle dos riscos do projeto.
• Gerenciamento da Qualidade: agrupa os processos respons veis por garantir que o projeto ir
satisfazer as necessidades que deram origem ao mesmo. Consiste do planejamento,
verifica o e controle da qualidade.
DESCRI O SUCINTA DO
RATIONAL UNIFIED PROCESS (RUP)
O RUP define um framework completo e customiz vel para o desenvolvimento de projetos de
engenharia de software (Jacobson, Booch & Rumbaugh, 1999). Diferentemente do PMBOK, que
se concentra unicamente em processos de gest o do projeto, o RUP descreve tanto os processos
de produ o (relativos s especificidades e elementos t cnicos) quanto os processos de
gerenciamento destes projetos. Esses processos de gerenciamento, por m, s o muito ligados aos
aspectos t cnicos e n o incluem diversos processos que n o integram a engenharia de software,
mas que s o necess rios para a boa condu o do projeto, como, por exemplo, a gest o de
recursos humanos.
O RUP organizado em 4 etapas: inicia o, elabora o, constru o e transi o. Essas etapas
representam a seq ncia temporal de eventos que ocorrem durante o ciclo de vida de projetos de
desenvolvimento de software, cobrindo desde o inicio do processo de defini o do software, at
sua implanta o no ambiente final de produ o. Os processos descritos pelo framework s o
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
agrupados em nove disciplinas que correspondem aos principais grupos de atividades de um
projeto de engenharia de software.
Figura 5: Marcos entre fases do ciclo de desenvolvimento. Fonte RUP
Al m disso, o processo segue um modelo iterativo de desenvolvimento, no qual todas as
disciplinas s o executadas v rias vezes durante o ciclo de desenvolvimento, seguindo um modelo
incremental, onde a cada itera o efetuada, amplia-se o conte do dos produtos desenvolvidos em
cada uma das atividades. A Figura 6 ilustra essa iteratividade.
Figura 6: Iteratividade dos processos no RUP. Fonte: RUP
O RUP parte do pressuposto de que, num projeto de software, existe uma grande intersec o
entre os produtos gerados no processo de engenharia de software e os produtos do gerenciamento
do projeto. Para lidar com esta interse o, o RUP incorpora como uma de suas disciplinas o
gerenciamento de projeto. Essa disciplina dividida em seis grupos de atividades distintos: inicio
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
do projeto, planejamento de desenvolvimento, outros planos, inicio-fim da itera o e
gerenciamento de rotina. Al m disso, a disciplina engloba as atividades relativas ao
gerenciamento do desenvolvimento do software, incluindo o planejamento e execu o de cada
uma das itera es que ser o efetuadas no projeto e a elabora o do Plano de Desenvolvimento de
Software, que cont m todas as informa es necess rias para o controle t cnico do projeto.
Enfocando a liga o entre os produtos t cnicos e os produtos de gerenciamento dos projetos de
software, o RUP deixa de considerar diversos outros aspectos necess rios ao bom gerenciamento
do projeto.
Apesar de insuficiente para o gerenciamento do projeto, essa abordagem v lida e correta j que
essa liga o efetivamente um fator necess rio em projetos de software. Tomemos como
exemplo as atividades de an lise de riscos: o PMBOK prop e m todos formais de documenta o
e mitiga o de riscos. N o existem, por m, m todos para avalia o de riscos causados pela
depend ncia ou acoplamento entre um item e outro do escopo, ou de liga o entre os riscos e os
itens de requisitos do software. Dessa forma, para projetos de engenharia de software, faz-se
necess rio analisar criteriosamente a depend ncia entre esses produtos e os itens de requisitos,
para que seja poss vel a rastreabilidade de escopo proposta pelo RUP.
Percebe-se que ambos os conjuntos de processos s o complementares no dom nio dos projetos de
Engenharia de Software. Assim, para que esses projetos possam ser conduzidos de forma a
produzir produtos de qualidade no escopo, prazo e esfor o desejados e planejados, necess ria a
consolida o de ambos, incorporando as suas melhores pr ticas e pontos fortes.
RELATO DA EXPERI NCIA — O CASO PROMON
A partir de meados no ano 2000 foi iniciado o processo de implanta o de metodologia pr pria
na rec m criada Promon*IP, bra o de tecnologia da informa o do grupo Promon. Essa
implanta o tinha por objetivos definir o framework das atividades a serem desenvolvidas e
padronizar a cultura da nova empresa, que estava fragmentada por ter sido formada pela
aquisi o de diversas empresas (como Webra, 2PG, Intex).
O primeiro passo foi definir quais processos de mercado seriam utilizados como base na nova
metodologia. Dentre os processos dispon veis estavam o processo de gerenciamento j utilizado
pela corpora o (baseado no PMBoK) e o Unified Process, amplamente difundido como
framework de engenharia de software. Faltava, portanto, um processo de mercado que unisse as
duas metodologias.
Dada a inexist ncia dessa metodologia nica, que combinasse gerenciamento de projetos e
engenharia de software de forma ampla, chegou-se defini o de que a nova metodologia
deveria ser composta pela uni o dessas duas, al m de um conjunto de processos internos para
outro aspecto do neg cio: a arquitetura de informa o:
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
Gerenciamento de projetos: Processos PMBOK.
Engenharia de software: Processos RUP.
Arquitetura de informa o : Defini o interna a partir das defini es das equipes de
arquitetura de informa o (Usabilidade e Conte do) e webdesign (designers para sistema webbased).
Essa nova metodologia foi chamada de M todo*IP e tinha por objetivo ser uma metodologia
completa para sistema complexos sobre Internet, a ser aplicada por toda Promon*IP. O
desenvolvimento e implanta o da metodologia em sua primeira vers o teve um prazo de 6
meses aproximadamente. Em seguida, iniciou-se o processo de treinamento das equipes. Em
paralelo ao treinamento das equipes, utilizou-se um projeto piloto como base para as defini es
finais da metodologia e solu es de poss veis problemas.
Ap s a execu o do piloto e dos treinamentos, j se dispunha de uma base de problemas
encontrados na implanta o da metodologia e organizados em 2 reas: (1) cultural e (2) intera o
de reas de dom nio.
•
Problemas de natureza cultural: rejei o de processos formais por equipes com cultura
orientada principalmente para atividades criativas, como de webdesign.
•
Problemas de intera o de reas de dom nio : problemas principais e mais intensos que
foram identificados durante o processo de implanta o da metodologia, relacionados com a
intera o de atividades de dom nio diferentes. Por exemplo: intera o de atividades de
engenharia de software com atividades de arquitetura de informa o e intera o de
atividades de engenharia de software com atividades de gerenciamento de projetos.
Plano de a o para resolu o de problemas
A ocorr ncia dos problemas revelou a necessidade da consolida o de uma nova vers o da
metodologia, que permitisse maior intera o entre os processos, principalmente entre engenharia
de software e gerenciamento de projetos. Nesse novo modelo, as atividades de engenharia de
software deveriam fornecer informa es nos momentos corretos para a equipe de gest o e as
atividades de gerenciamento deveriam abranger a principal caracter stica do RUP, que o
processo iterativo e incremental.
Esse segundo ciclo de discuss es, para consolida o da nova vers o da metodologia, passou a
utilizar uma abordagem diferente da primeira, que era focada em um grande n mero de pessoas
envolvidas e adotava uma abordagem de projeto (escopo, prazo e custo). Na nova linha de
racioc nio, decidiu-se que seria necess rio, primeiro, uma consolida o da base de conhecimento
das equipes e, a partir da , utilizar-se inser es pontuais durante os projetos. Essa solu o
mostrou-se ineficaz, pois a metodologia ficava relegada a segundo plano nos projetos, devido a
quest es de prioridades e prazos.
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
A terceira abordagem da implanta o do processo utilizou uma combina o das abordagem
anteriores. A unifica o de processos passou a ser tratada como priorit ria dentro da empresa,
mas sem a utiliza o de uma equipe grande, como na abordagem inicial. Definiu-se que um
conjunto de 4 a 5 pessoas seriam encarregadas inicialmente de difundir que a primeira
metodologia (M todo*IP) estava extinta e que n o haveria mais um processo pr prio da empresa.
O PMBoK seria aplicado em sua totalidade e o RUP seria implantado para definir as atividades
operacionais pertinentes aos projetos.Esta abordagem, no entanto, n o resolveu o problema
inicial, que era a intera o entre atividades das reas. Para esse problema foi definido que a
equipe proporia uma solu o, que passou a ser discutida n o a partir das atividades realizadas
internamente mas sim das defini es oficiais constantes tanto no PMBoK como no RUP,
determinando como os dois conjuntos de processos poderiam ser utilizados em conjunto e
aplicando essas defini es em projetos-piloto. Essa delimita o ser descrita em seguida neste
trabalho.
Combinando RUP com PMBOK
Apesar de seus objetivos serem diferentes, o RUP e o PMBOK t m interse o relativamente
ampla e que pode ser trabalhada de forma a possibilitar o uso integrado dos recursos dessas duas
metodologias. Essa intersec o acontece principalmente pelo fato de o RUP incluir v rias
atividades relacionadas ao gerenciamento do projeto, que a nfase do PMBOK. No entanto,
essas atividades propostas pelo RUP s o muitas vezes insuficientes para que o gerenciamento do
projeto ocorra de maneira eficaz. O framework n o cobre, por exemplo, a gest o de pessoas, a
gest o do or amento, o controle de custos e a gest o de suprimentos. Essa insufici ncia indica
que a metodologia proposta pelo PMBOK pode ser enxertada no RUP, para fornecer um
ferramental mais completo de gest o de projetos de TI.
Mas, como realizar essa integra o? Para de responder a essa pergunta, conv m recapitular
alguns conceitos:
• Tanto os processos propostos pelo RUP como os propostos pelo PMBOK s o iterativos, ou
seja, podem acontecer v rias vezes durante o ciclo de vida do projeto. Assim, para conseguir
integrar efetivamente as duas metodologias, suas itera es precisam ser compatibilizadas.
• O RUP um framework completo para o desenvolvimento de projetos de software e inclui,
portanto, tanto aspectos de engenharia de software como de gest o de projetos (de forma, no
entanto, insuficiente). O PMBOK prop e um conjunto de processos para gerenciamento
gen rico de projetos, n o incluindo, portanto, especificidades de tipos particulares de projetos.
A integra o entre as duas metodologias deve ser restrita
rea de intersec o: o
gerenciamento do projeto. Em linhas gerais, o RUP deve atender aos aspectos espec ficos
relacionados engenharia de software enquanto o PMBOK deve ocupar-se do gerenciamento
do projeto. Dessa forma, extrai-se o melhor de cada metodologia.
• Tanto o RUP quanto o PMBOK podem e devem ser customizados para atender a necessidades
espec ficas de seus usu rios. Para integrar e aplicar as duas metodologias a situa es
espec ficas, necess rio adequar uma a outra e customiz -las em conjunto. Como a intersec o
entre ambas ocorre nos processos de gerenciamento de projetos, esta a rea que mais requer
aten o durante a customiza o.
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
Para realizar a tarefa da integra o, a estrat gia da Promon foi partir do gen rico para o
especializado, ou seja, dos processos do PMBOK para os do RUP, sincronizando ambos. Os
grupos de processos do PMBOK s o realizados a cada fase do projeto, que termina com a entrega
de um ou mais produtos importantes. Em um projeto de software estruturado segundo o RUP,
cada fase (conforme definida pelo PMBOK) corresponde a uma itera o (conforme definida pelo
RUP). Assim, o ciclo dos cinco grupos de processos descritos pelo PMBOK realizado em cada
itera o do RUP. A Figura 7 ilustra esse relacionamento.
Figura 7: Compatibiliza o das itera es do RUP e do PMBOK
Os processos de inicia o preparam o in cio tanto do projeto como de cada uma das itera es do
RUP. Na mesma linha, os processos de planejamento preparam a execu o da itera o, os de
execu o tratam da produ o dos resultados esperados e os de controle tratam da avalia o da
execu o e realimenta o do planejamento da itera o. Essa primeira rela o foi denominada
relacionamento interno entre RUP e PMBOK.
Embora os grupos de atividades de gerenciamento do RUP tenham nomes semelhantes aos
grupos de processo do PMBOK, n o se pode confundi-los, pois os mesmos apresentam
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
caracter sticas distintas. As atividades de um nico grupo do RUP s o realizadas em mais de um
grupo de processos do PMBOK. Por exemplo: as atividades do grupo In cio-Fim da Itera o do
RUP s o divididas entre os grupos de Inicia o e de Fechamento do PMBOK.
Al m disso, as atividades propostas tanto pelo RUP quanto pelo PMBOK s o iterativas e
incrementais, ou seja, alguns produtos s o gerados ap s v rias itera es, sendo complementados
a cada itera o. Por exemplo, o Plano de Itera es, proposto pelo RUP seria criado no grupo de
processos de Planejamento da primeira itera o e ent o revisado nas itera es posteriores at o
final do projeto. A Figura 8 ilustra a rela o entre fluxo incremental do RUP e os grupos de
processos do PMBOK
Figura 8: Rela o entre o fluxo incremental do RUP e os grupos de processos do PMBOK
Parte do planejamento inicial do RUP ocorre concomitantemente com os processos de inicia o
do PMBOK. O restante do planejamento inicial, juntamente com o fluxo de planejamento, ocorre
junto com os processos de planejamento do PMBOK. Os fluxos de modelagem de neg cios,
requisitos, an lise e design, implementa o, testes, avalia o e implanta o ocorrem
concomitantemente com os processos de execu o. Os processos de fechamento do PMBOK n o
t m paralelo no RUP, sendo representados apenas por marcos ou estados. Os fluxos de
gerenciamento de configura o e mudan a e os de ambiente ocorrem concomitantemente com os
processos de controle.
A Figura 9 mostra a rela o temporal entre o fluxo de trabalho da disciplina de gerenciamento de
projetos do RUP com os grupos de processos do PMBOK, ou seja, em que momento, conforme
definido pelo PMBOK, cada grupo de atividades do RUP executado.
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
Figura 9: Compatibiliza o das itera es do RUP e do PMBOK
Pode-se perceber que o grupo de processos de fechamento do PMBOK apresenta apenas estados
do RUP associados e n o atividades. Esse fato explica porque o fechamento fica fora da espiral
que mostra a iteratividade do RUP associado ao PMBOK.
Al m da rela o descrita at o momento, o relacionamento interno , existe tamb m um
relacionamento externo. Como o RUP n o inclui aspectos importantes do gerenciamento de
projetos, como a gest o de suprimentos e custos, pode-se afirmar que o PMBOK mais
abrangente que o RUP na gest o do projeto. Assim, h atividades que s o executadas durante um
projeto de engenharia de software e que n o se enquadram dentro dos processos descritos no
mbito do relacionamento interno entre RUP e PMBOK. Essas atividades tamb m acontecem
dentro dos mesmos grupos de processos propostos pelo PMBOK e constituem o relacionamento
externo, ou de complementa o, entre os frameworks. A Figura 10 ilustra essa rela o, mostrando
que existe um fluxo de processos PMBOK fora do RUP e que engloba este.
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
Figura 10: Compatibiliza o das itera es do RUP e do PMBOK
Explicada a liga o entre o RUP e o PMBOK, tanto em termos de din mica interna como externa
ou de complementa o, a proposta de integra o dos dois frameworks ser definida. Essa
integra o, que poss vel porque as duas metodologias s o customiz veis, deve ocorrer somente
na disciplina de Gerenciamento de Projetos do RUP e obedecer as seguintes diretrizes:
• Os processos definidos pelo PMBOK, por serem mais completos e gen ricos, devem ser
usados como base para a defini o dos processos customizados de ger ncia de projetos da
metodologia integrada.
• Sempre que poss vel, deve-se manter a liga o entre os produtos gerados pelo gerente do
projeto e os produtos t cnicos, conforme proposto pelo RUP. Para isso, sugere-se procurar
relacionar os artifacts gerados pela disciplina de Gerenciamento do RUP com os documentos
resultados dos processos do PMBOK, bem como as atividades propostas pelo PMBOK com as
atividades propostas pela RUP para produzir os respectivos documentos ou artifacts. Essa
liga o muito importante para a manuten o da rastreabilidade entre os diversos aspectos do
projeto.
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
• Todas as atividades ou produtos da disciplina de Gerenciamento de Projetos do RUP a serem
utilizados devem ser mapeados ou customizados para ajustar-se s atividades ou documentos
propostos pelos processos do PMBOK.
• As atividades ou documentos propostos pelo PMBOK que n o t m paralelo no RUP devem
apenas ser customizados de acordo com a necessidade.
O conjunto de processos resultantes do trabalho de integra o ser constitu do dos processos
propostos pelo PMBOK, j adaptados de forma a incluir as atividades e produtos definidos pela
disciplina de Gerenciamento de Projeto do RUP. A metodologia integrada ser obtida a partir da
soma desses processos gerenciais com os demais processos espec ficos de engenharia de software
propostos pelo RUP.
Com esta integra o, consegue-se obter o melhor de cada um dos frameworks: utiliza-se o
PMBOK no gerenciamento do projeto, adaptando-se o necess rio para incluir as atividades e
produtos propostos pelo RUP e utiliza-se o RUP para todos os demais aspectos t cnicos do
projeto.
CONSIDERA ˝ES FINAIS
Neste trabalho, os autores procuraram descrever os pontos relevantes no processo de concilia o
e integra o entre a metodologia do PMBOK para o gerenciamento de projetos e do RUP para
engenharia de software, de forma a obter um conjunto de processos mais completos e adequados
ao gerenciamento de projetos de engenharia de software. Foram descritas tamb m as
caracter sticas b sicas do PMBOK e do RUP, de maneira a fornecer a base necess ria para a
concilia o dos frameworks, bem como o processo e as diretrizes a serem seguidas para que essa
tarefa seja poss vel. Essa combina o de ferramentas gerenciais tem por base experi ncias
pr ticas realizadas no mbito da Engenharia de Software da Promon Tecnologia Ltda, que o
trabalho tamb m procurou descrever. Apesar das limita es da base emp rica, essa experi ncia
tem potencial de aplica o em outras situa es. De fato, h registros de experi ncias semelhantes
(por exemplo, Medeiros e outros, 2004 e Charbonneau, 2004).
O processo e as diretrizes descritas para que a integra o entre o PMBOK e o RUP ocorra de
forma a possibilitar a obten o do melhor de cada um dos frameworks, apesar de conceitualmente
simples, pode encontrar dificuldades e problemas de implementa o, devido s peculiaridades de
cada situa o e aos fatores humanos. importante recomendar que a repeti o da experi ncia
aqui descrita em outras empresas deve ser precedida por um criterioso estudo da bibliografia e de
outros poss veis casos similares.
CR DITOS
Promon Tecnologia Ltda. (www.promon.com.br)
PMBOK e PMBOK Guide s o marcas registradas do Project Management Institute.
RUP e Rational Unified Process s o marcas registradas da IBM.
2º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação
REFER NCIAS BIBLIOGR FICAS
CHARBONNEAU, Serge, Software Project Management - A Mapping between RUP and the
PMBOK, http://www-106.ibm.com/developerworks/rational/library/4721.html
CRAWFORD, J. K. Making a Place for Success, Project Management Best Practices Report,
Junho, 2000.
JACOBSON, I.; BOOCH,G.; RUMBAUGH,J. .The Unified Software Development Process.
Addison Wesley, 1999
JONES, C. Patterns of Software Systems Failures and Success; International Thomson Computer
Press , Boston Massachusetts, 1996
MEDEIROS, Vivianne da N brega, ANDRADE, Carlos Andreazza Rego, ALMEIDA, Eduardo
Santana de, ALBUQUERQUE, Jones, MEIRA, S lvio, Construindo uma F brica de
Software: da Concep o s Li es Aprendidas. Anais da XXX Confer ncia LatinoAmericana de Inform tica, Arequipa, Peru, 27-9 a 1-10 de 2004.
PMI STANDARDS COMMITTEE. A Guide to the Project Management Body of Knowledge
2000ed. Newtown Square, PA. PMI Management Institute, 2001.
RAD, P. F.; RAGHAVAN, A. Establishing an Organizational Project Office. AACE
International Transactions, 2000