ESCOLA POLITÉCNICA
DCC/SEGRAC
PROPOSTA DE METODOLOGIA SIMPLIFICADA PARA
PROJETOS DE DESENVOLVIMENTO DE SOFTWARES
UTILIZANDO PMBoK E RATIONAL UNIFIED PROCESS
Gilberto Santiago Araújo
DESENVOLVIMENTO DE SOFTWARES UTILIZANDO PMBoK E RATIONAL UNIFIED PROCESS
Gilberto Santiago Araújo
M o n o g r a f i a a p r e s e n t a d a n o C u r s o d e P ó s - G r a d u a ç ã o e m G e r e n c i a m e n t o d e P r o j e t o s , d a E s c o l a P o l i t é c n i c a , d a U n i v e r s i d a d e F e d e r a l d o R i o d e J a n e i r o . Orientadores Carlos Sérgio Mota Filho José Raimundo Matos Miranda
Fortaleza Junho, 2006
ii
PROPOSTA DE METODOLOGIA SIMPLIFICADA PARA PROJETOS DE DESENVOLVIMENTO DE SOFTWARES UTILIZANDO PMBoK E RATIONAL
UNIFIED PROCESS
Gilberto Santiago Araújo
Orientadores Carlos Sérgio Mota Filho José Raimundo Matos Miranda
Monografia submetida ao Curso de Pós-graduação Gerenciamento de Projetos, da Escola Politécnica, da Universidade Federal do Rio de Janeiro – UFRJ, como parte dos requisitos necessários à obtenção do título de Especialista em Gerenciamento de Projetos.
Aprovado por:
__________________________________________ Prof. Eduardo Linhares Qualharini
__________________________________________ Prof. Carlos Sérgio Mota Filho
Orientador
__________________________________________
Prof. José Raimundo Matos Miranda Orientador
Fortaleza Junho, 2006
iii
ARAÚJO, Gilberto Santiago.
Proposta de Metodologia Simplificada para Projetos de Desenvolvimento de Softwares Utilizando PMBoK e Rational Unified Process / ARAÚJO, G. S. Rio de Janeiro: UFRJ/EP, 2006. viii, 52f. il.; 29,7cm.
Orientadores: Carlos Sérgio Mota Filho, José Raimundo Matos Miranda.
Monografia (especialização) – UFRJ/ Escola Politécnica/ Curso de Especialização em Gerenciamento de Projetos, SEGRAC, 2006.
Referências Bibliográficas: f. 51-52
1. Qualidade de Software. 2. PMBoK. 3. RUP - Monografia. I. FILHO, C. S. M., MIRANDA, J. R. M. II. Universidade Federal do Rio de Janeiro, Escola Politécnica, Pós-graduação III. Especialista.
iv
RESUMO
PROPOSTAS DE METODOLOGIA SIMPLIFICADA PARA PROJETOS DE DESENVOLVIMENTO DE SOFTWARES UTILIZANDO PMBoK E RATIONAL
UNIFIED PROCESS
Gilberto Santiago Araújo
Resumo da Monografia submetida ao corpo docente do curso de Pós-Graduação em Gerenciamento de Projetos – Universidade Federal do Rio de Janeiro – UFRJ, como parte dos requisitos necessários à obtenção do título de Especialista em Gerenciamento de Projetos.
Este trabalho propõe a combinação dos conceitos e metodologias estudados pelo Project Management Institute com o Rational Unified Process e métodos ágeis. Cada proposta é apresentada separadamente de forma condensada e, logo em seguida, as áreas de conhecimento do PMBoK são mapeadas com as disciplinas do RUP, permitindo que este estudo, devidamente embasado, possa chegar ao seu objetivo final, que é propor uma metodologia simplificada e de fácil implementação por pequenas e médias equipes de desenvolvimento de software.
Palavras-chave: Qualidade de Software, PMBoK e RUP.
Fortaleza Junho, 2006
v SUMÁRIO 1. Introdução ... 01 1.1 Objetivo ... 01 1.2 Justificativa ... 01 1.3 Metodologia ... 01
1.4 Conteúdos dos capítulos ... 02
2. Conceitos Básicos ... 03
2.1 Breve histórico da engenharia de software ... 03
2.2 Fundamentos sobre engenharia de software ... 04
2.3 Métodos ágeis ... 05
2.4 Visão geral do Rational Unified Process ou RUP ... 11
2.4.1 Primeira comparação entre RUP e PMBoK ... 16
2.4.2 Principais artefatos da disciplina de Gerenciamento de Projeto (RUP) ... 17
2.5 Visão geral do PMBoK ... 20
2.5.1 Áreas de conhecimento do PMBoK e grupos de processos ... 21
2.5.2 Ciclos de vida no PMBoK ... 23
2.5.3 Produtos do PMBoK ... 24
3. Mapeamento entre PMBoK e RUP ... 26
3.1 Características comuns... 26
3.2 Mapeando os modelos ... 27
3.3 Mapeando processos do PMBoK às atividades do RUP ... 28
3.4 Primeiras conclusões ... 29
4. Proposta de Metodologia Simplificada Unindo PMBoK e RUP ... 30
4.1 Processo de Triagem ... 31 4.2 Iniciação ... 31 4.3 Planejamento ... 32 4.4 Requisitos ... 33 4.5 Tempo ... 34 4.6 Implementação ... 34 4.7 Controle ... 35 4.8 Encerramento ... 35
4.9 Estrutura Analítica do Projeto... 36
4.10 Atividades e Descrições ... 39
4.10.1 Iniciação ... 39
4.10.2 Planejamento ... 39
4.10.3 Requisitos ... 41
vi 4.10.5 Implementação ... 43 4.10.6 Controle ... 46 4.10.7 Encerramento ... 47 5. Considerações Finais ... 49 5.1 Críticas ... 49 5.2 Sugestões ... 50 5.3 Recomendações ... 50 REFERÊNCIAS BIBLIOGRÁFICAS ... 51 REFERÊNCIAS ELETRÔNICAS ... 52
vii
LISTA DE FIGURAS
Figura 1 - Abordagem Tradicional ... 7
Figura 2 - Métodos Ágeis ... 7
Figura 3 - Fases do APM ... 10
Figura 4 - Grupos de processos do PMBoK ... 23
Figura 5 - EAP da metodologia proposta ... 36
Figura 6 - EAP e principais atividades da metodologia proposta ... 37
Figura 7 - EAP com etapas e atividades da fase de Implementação ... 37
LISTA DE GRÁFICOS Gráfico 1 - Fluxo de um projeto ágil ... 10
Gráfico 2 - Dimensões do RUP ... 14
Gráfico 3 - Ciclo de vida da metodologia proposta ... 30
LISTA DE QUADRO Quadro 1 - Princípios do APM ... 8
Quadro 2 - Visão geral do PMBoK ... 20
Quadro 3 - Principais características do PMBoK e RUP ... 26
Quadro 4 - Principais elementos do PMBoK e RUP ... 27 Quadro 5 - Mapeando as áreas de conhecimento do PMBoK às disciplinas do RUP . 28
O tema sugerido, “Proposta de Metodologia Simplificada para Projetos de Desenvolvimento de Softwares Utilizando PMBoK e Rational Unified Process”, é decorrente de necessidade de melhorias em métodos e processos para o desenvolvimento de softwares em uma universidade particular.
1.1 Objetivo
Propor uma metodologia simplificada para pequenas e médias equipes de desenvolvimento unindo as propostas do Project Management Body of Knowledge, PMBoK versão 2000, e o Rational Unified Process, RUP, método proprietário criado pela Rational Software Corporation. O objetivo maior é sugerir um método voltado para a realidade das empresas brasileiras e de fácil implementação por equipes de desenvolvimento para reduzir os riscos de insucesso em projetos de software.
1.2 Justificativa
Segundo pesquisa realizada pela Standish Group International em 2003, projetos de desenvolvimento de sistemas de Tecnologia da Informação bem sucedidos representaram apenas 34% do total no ano de 2002. Somando os projetos cancelados ou abandonados e os que obtiveram sucesso apenas parcial, obtém-se um índice bastante elevado de 66%. Estes números mostram que, ainda há um bom caminho a percorrer para que o desenvolvimento de software atinja níveis de maturidade alinhados com a disponibilidade orçamentária, prazos adequados e reais interesses das empresas de modo geral.
1.3 Metodologia
A monografia foi desenvolvida a partir de pesquisas bibliográficas envolvendo artigos científicos, revistas especializadas, teses de mestrado, livros e páginas na Internet de instituições de renome para o meio comercial e acadêmico.
O conteúdo é disposto de forma analítica de modo que os conceitos envolvidos são primeiramente detalhados em separado para, posteriormente, serem associados
dentro de um método único e de fácil implementação.
A pesquisa é causal, pois os temas e conceitos precisarão ser melhor assimilados e aprofundados antes da elaboração de uma proposta que virá a compor a parte final do trabalho. Pretende-se implementar a proposta final em uma instalação real, de modo a obter as primeiras impressões e registros do modelo proposto. Nenhum estudo de caso é apresentado neste trabalho.
1.4 Conteúdos dos capítulos
O capítulo 2, que virá logo a seguir, compila os principais conceitos que embasam este estudo. Nele são apresentados o histórico e noções básicas sobre engenharia de software e princípios e filosofia dos métodos ágeis, cujas contribuições são parte fundamental do trabalho aqui desenvolvido. O mesmo capítulo também fornece uma breve noção e uma visão geral das propostas metodológicas do Project
Management Institute, PMI, o Project Management Body of Knowledge, PMBoK, e da
IBM, o Rational Unified Process, RUP.
Na seqüência, no capítulo 3, é realizado um comparativo entre o PMBoK e o RUP, de modo a permitir a identificação de semelhanças, diferenças, omissões e, principalmente, compatibilidades. O objetivo deste capítulo é comprovar a viabilidade de mesclar as duas propostas em um modelo híbrido.
O capítulo 4 apresenta a metodologia proposta de forma detalhada. A idéia é que leitor possa assimilar seus conceitos, baseados principalmente no modelo do PMI, e compreender o sequenciamento das etapas e respectivas atividades. Os documentos a serem produzidos e/ou atualizados em cada atividade também são declarados, além de terem modelos apresentados como anexos.
Ao final, no capítulo 5, são apresentadas as considerações finais, críticas sobre trabalho desenvolvido, sugestões e recomendações de outros estudos a serem realizados em torno deste tema.
2.
Conceitos Básicos
2.1 Breve histórico da engenharia de software
Durante anos, o desenvolvimento de sistemas vem evoluindo no sentido de se tornar gerenciável. Historicamente, nas décadas de 50 e 60, os sistemas eram muito simples e desenvolvidos para necessidades específicas, mas, com o passar de algumas décadas, proporcionados com o avanço do aparato tecnológico, as necessidades passaram a ser mais complexas e com isso os sistemas tornaram-se mais robustos. Até então, o que se tinha em termo de Tecnologia da Informação para prover certa garantia de qualidade eram técnicas como fluxogramas, diagrama de módulos, programação estruturada, projeto estruturado e análise estruturada. Estas técnicas representaram um considerável avanço para a Engenharia de Software que dava seus primeiros passos e o desenvolvimento de sistemas passou a atingir níveis de produtividade cada vez maiores, atribuídos a uma forte e crescente demanda vinda do mercado. As grandes corporações perceberam então a fundamental importância dos sistemas informatizados para todo o processo de negócio, independente de sua área de atuação.
Neste contexto, metodologias para gerenciar o desenvolvimento de software foram criadas em resposta à necessidade evidente de planejar, executar e controlar o conjunto de atividades envolvendo novas perspectivas, expectativas e requisitos reunidos em sistemas cada vez menos triviais. Assim, para se obter uma maior produtividade, foram formulados novos conceitos e modelos, como a Análise Orientada a Objetos que veio atingir um bom nível de maturidade na década de 90. Quando somada com padrões de projeto, frameworks e componentes reutilizáveis, a Análise Orientada a Objetos proveu um suporte confiável, tornando o processo de desenvolvimento de software robusto o suficiente para a implementação de sistemas de alta complexidade.
Mais recentemente, a UML1
1 A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira geração. A UML não é um método de desenvolvimento, ou seja, ela não diz o que fazer primeiro ou como desenhar o software, mas auxilia a visualizar o que será produzido e a comunicação entre objetos. Fonte: WIKIPEDIA (2006).
surgiu como um padrão de fato para toda a cadeia de produção de software com o objetivo de tornar-se uma linguagem padrão de notações, diagramas e formas de representação dentre as diversas atualmente disponíveis.
A automatização e informatização de processos é crítica para a grande maioria das empresas, o que torna cada vez mais obrigatória a aproximação dos administradores das empresas dos profissionais de TI e destes com os gerentes de projetos, de modo que todos estejam alinhados com a gestão dos custos, recursos e tempo, e, obviamente, atentos em garantir a qualidade necessária para a obtenção de lucros.
O RUP, em conjunto com a UML, formalizou uma metodologia para gerir o processo de desenvolvimento de software e, com isso, surgiram novos conceitos relativos à qualidade e eficiência que vieram somar às técnicas já existentes.
Atualmente foi concebido o conceito de Gerência de Projeto de software, onde os processos de desenvolvimento passam a dar suporte a um universo maior, encadeado por metas e objetivos estratégicos das corporações. Com isso, a Tecnologia da Informação tem de estar fortemente atrelada à própria administração da empresa. Esta realidade mostra-se muito clara quando uma organização de TI voltada para o mercado ou um setor de TI que presta serviços apenas para a corporação a qual pertence realiza seu planejamento estratégico. As metas e objetivos estratégicos são perfeitamente alinhados aos dos seus clientes, sendo impossível separar os ideais e planos de um e de outro, pois devem estar em perfeita simbiose. Neste contexto, metodologias de gerência de projetos, como PMBoK, podem servir de apoio para a obtenção de índices de produtividade, sucesso e o aumento de competitividade das empresas no mercado.
2.2 Fundamentos sobre engenharia de software
A engenharia de software possui características especiais que torna seus projetos voltados ao desenvolvimento de produtos distintos das abordagens tradicionais. Projetos tradicionais geralmente são organizados com base em estruturas top-down e Product
Breakdown Structure ou PBS, onde o produto é decomposto em componentes e
artefatos (plantas baixas, maquetes, desenhos esquemáticos, etc.) e em processos em cascata com fases sequenciais, herança da indústria e da construção civil. O planejamento precisa ser desenvolvido com base na estrutura do produto que, por sua vez, precisa ser especificado no início do projeto. Este método não pode ser adotado no desenvolvimento de softwares, “uma vez que no início do projeto se sabe muito pouco sobre o sistema a ser produzido” (MARTINS, 2005, p. 229). Devido a essas peculiaridades, um projeto de desenvolvimento de software sofre modificações no
escopo diversas vezes no decorrer do seu ciclo de vida, o que praticamente inviabiliza a adoção de técnicas de gerenciamento de projeto tradicionais. Seguem alguns motivos que podem causar mudanças de requisitos:
1. Mudanças nas expectativas do cliente, principalmente em projetos longos;
2. Alterações nos processos a informatizar;
3. Evoluções tecnológicas que agreguem valor ao produto final;
4. Lançamento, pela concorrência, de produtos de qualidade superior ao do projeto;
5. Mudanças na legislação.
As mudanças, portanto, são inerentes ao processo de desenvolvimento de
software e devem ser naturalmente incorporadas e aceitas durante todo o projeto.
2.3 Métodos ágeis
O Gerenciamento de Projetos Ágeis, Agile Project Management ou APM, teve início em 2001, em um movimento iniciado pela comunidade internacional de desenvolvimento de sistemas quando da publicação do Manifesto for Agile software
Development (BECK, 2001). Esse movimento foi uma reação às crescentes pressões por
constantes inovações, à forte concorrência, a necessidade de redução e simplificação dos ciclos de desenvolvimento de novos sistemas e de adaptação a um ambiente de negócio bastante dinâmico, contexto em que o gerenciamento de projetos clássico não se mostrou plenamente efetivo. À medida que esse movimento inicial dos desenvolvedores de sistemas de Tecnologia da Informação foi percebido por segmentos mais tradicionais, tais como o das indústrias de construção civil e aeroespacial, que dispõem de premissas semelhantes relacionadas a complexidades e incertezas, o movimento ampliou sua abrangência, sendo estendido, genericamente, ao gerenciamento de projetos de qualquer segmento de negócio (DIAS, 2005, p.15).
Neste estudo a abrangência se limita ao que a metodologia APM oferece para projetos de software, foco e objeto de estudo desta monografia.
acontecem durante o processo de desenvolvimento de software. O Gerenciamento de Projetos Ágeis pode ser definido como um “conjunto de valores, princípios e práticas que auxiliam a equipe de projeto a entregar produtos ou serviços de valor em um ambiente complexo, instável e desafiador” (HIGHSMITH, 2004, p.16).
O APM defende que:
1. A ausência de estrutura ou estabilidade pode levar ao caos, enquanto estrutura em demasia gera rigidez;
2. E que agilidade é a habilidade de criar e responder a mudanças, buscando a obtenção de lucro em um ambiente de negócio turbulento (HIGHSMITH, 2004, p.16);
3. Agilidade também pode ser vista como “a capacidade de balancear flexibilidade e estabilidade” (HIGHSMITH, 2002).
A diferença básica entre a abordagem APM e a tradicional está na ênfase que é dada a atividades específicas do projeto e o nível de esforço correspondente. Processos tradicionais têm grande ênfase sobre o planejamento e controle. Já em um ambiente
agile ou ágil, o foco é transferido do planejamento para a execução, buscando sempre a
entrega de valor ao cliente e a apresentação de resultados ao longo de todo o projeto; e do controle para a adaptação, permitindo alterações substanciais de escopo a cada iteração para atender aos requisitos do negócio. Além disso, custo e prazo são estimados no início do projeto e melhor detalhados a cada ciclo ou iteração, o que repercute, após recálculos periódicos, na estimativa inicial.
O PMI-MG (MAGALHÃES, 2005, p. 3) apresenta a principal diferença de abordagem dos métodos tradicionais e ágeis de forma bastante simples e direta. O gerenciamento tradicional de projetos, mais especificamente o PMBoK, demonstra profunda preocupação com o gerenciamento do escopo, por ser este um dos três principais pilares de um projeto, além de custo e prazo. Em métodos ágeis a qualidade torna-se um dos pilares, recebendo maior atenção, enquanto o escopo pode ser manipulado com mais liberdade.
As figuras anteriores apresentam, de forma simplificada, a mudança de paradigma e o destaque que é dado ao gerenciamento do escopo em cada abordagem.
Para HIGHSMITH (2004), o APM se desfaz da postura antecipatória, fortemente calcada no planejamento prévio de ações e atividades, típico do gerenciamento de projetos tradicional, e busca o desenvolvimento da visão do futuro e da capacidade de realização através da exploração de cada etapa em andamento. O APM traz em si um novo enfoque de desenvolvimento de sistemas, baseado na agilidade, flexibilidade, habilidades de comunicação e na capacidade de oferecer novos produtos de valor ao mercado em curtos períodos de tempo.
Os valores centrais do Agile Project Management, apresentados no Manifesto for
Agile software Development (BECK, 2001) e listados a seguir, preocupam-se tanto com
a necessidade de criação e entrega de produtos ou sistemas de modo ágil e adaptável, como a necessidade de desenvolvimento de equipes de projeto com as mesmas características:
1. As respostas às mudanças são mais importantes que a perseguição de um plano previamente definido;
2. A entrega de produtos é prioritária em relação à entrega da documentação;
3. Enfatiza-se a colaboração do cliente em detrimento da negociação de contratos;
4. Os indivíduos e suas interações são mais importantes que os processos e ferramentas.
Qualidade
Prazo Custo
Escopo
Figura 1: Abordagem Tradicional
Fonte: MAGALHÃES, 2005, p. 3
Escopo
Prazo Custo
Qualidade
Figura 2: Métodos Ágeis
A clara opção pela satisfação do cliente, relações humanas e pela entrega de produtos de qualidade indicam um radical retorno às origens, lembrando aos profissionais que lidam com desenvolvimento de software o objetivo final de cada projeto.
Além dos valores básicos, o APM possui um conjunto de princípios-mestres que norteiam a sua aplicação. Embora cada princípio seja útil se aplicado isoladamente, o conjunto formado por eles cria um ambiente que encoraja e produz resultados mais efetivos (HIGHSMITH, 2004, p. 27-28):
Observando-se o quadro apresentado, fica evidente a preocupação com o aspecto humano ao destacar e valorizar o cliente, aspectos motivacionais e de autogestão.
Assim, a estrutura de processos para o APM deve ter por foco o conceito de agilidade e englobar os princípios apresentados anteriormente, além de assegurar o alcance dos objetivos de negócio. Para tanto, deve (DIAS, 2005, p. 17):
1. Favorecer a exploração e a cultura adaptativa; 2. Permitir a auto organização e a autodisciplina;
3. Promover a confiabilidade e a consistência possíveis, dado o grau de incertezas e complexidade inerente ao projeto;
4. Ser flexível e facilmente adaptável;
5. Permitir visibilidade ao longo do processo; 6. Incorporar o aprendizado;
7. Englobar as práticas específicas de cada fase;
Quadro 1: Princípios do APM
Categoria Princípio
Valor ao cliente
Entregar valor ao cliente
Gerar entregas iterativas e baseadas em funcionalidades
Buscar excelência técnica
Estilo de gerenciamento baseado na liderança e colaboração
Encorajar a exploração Construir times adaptativos
(autoorganizados e autodisciplinados) Simplificar
8. Prover pontos de verificação.
Vale ressaltar que o APM, no intuito de viabilizar a entrega rápida de produtos e valor, o aprendizado contínuo e a rápida adaptação às mudanças, é organizado em uma etapa inicial seguida de vários ciclos repetitivos ou iterações. Cada ciclo embute um novo planejamento de escopo, prazo, custo e qualidade, visando a entrega de produtos ou resultados e possibilitando o acréscimo de funcionalidades de acordo com a necessidade do negócio.
O Gerenciamento Ágil de Projetos está estruturado em fases da seguinte maneira (HIGHSMITH, 2004, p. 81):
1. Visão – corresponde à determinação da visão do produto e do escopo do projeto, a identificação da comunidade participante do projeto (clientes, gerente de projeto, equipe de projeto e outros atores) e definição de como a equipe do projeto trabalhará em conjunto;
2. Especulação – referente à identificação dos requisitos iniciais para o produto, definição das atividades, desenvolvimento de um plano de projeto (contendo entregas, marcos, várias iterações, cronograma de trabalho e alocação de recursos), incorporação de estratégias para mitigação de riscos e estimativas de custos e outras informações financeiras relevantes. Nesta etapa, é elaborado um planejamento preliminar que será seguido por planejamentos específicos, melhor detalhados a cada iteração;
3. Exploração – engloba a entrega dos produtos planejados através do gerenciamento da carga de trabalho e do emprego de práticas e estratégias de mitigação de risco apropriadas. Essas entregas são feitas sob a forma de incrementos de funcionalidades e são divididas entre os ciclos do projeto;
4. Adaptação – compreende a revisão dos resultados entregues, a análise da situação atual, a avaliação do desempenho da equipe de projeto, para eventual adaptação, se necessário. Esta revisão visa não apenas uma comparação do realizado versus o
planejado, mas principalmente do realizado versus informações e requisitos atualizados do projeto;
5. Encerramento – finalização das atividades do projeto, transferência dos aprendizados-chave e comemoração. As ilustrações a seguir permitem uma visão geral e facilitada do fluxo em projetos ágeis e as interligações entre as diferentes fases do APM.
Os pontos de controle, representados por pequenos losangos na figura anterior, indicam períodos de tempo que permitem que a equipe reveja e aprimore o planejamento realizado até aquele momento, absorva possíveis mudanças de escopo necessárias ao cliente, realize entregas e prepare a iteração seguinte.
Gráfico 1: Fluxo de um projeto ágil
Fonte: Adaptado de DIAS, 2005, p.18
Figura 3: Fases do APM
A figura 3 apresenta as fases da abordagem ágil de projetos. Ao observar o fluxo de informações, documentos e entregas, os ciclos das iterações - representadas nas fases de especulação, exploração e adaptação - ficam evidenciadas. Uma fase específica, a de adaptação, mostra a importância dada pelo método à aceitação de mudanças que são incorporadas na iteração seguinte ou, mais precisamente, dentro da próxima fase de especulação.
2.4 Visão geral do Rational Unified Process ou RUP
Os conceitos sobre o RUP aqui apresentados, baseados em Martins (2005) e Charbonneau (2004), destacam principalmente a disciplina da metodologia responsável pelo gerenciamento de projetos de software, foco deste documento, de modo a embasar a proposta final que busca integrar suas melhores práticas com as do PMBoK do PMI.
Muitas organizações buscam padronizar suas práticas de desenvolvimento de
softwares assim como também de gerenciamento de projetos e há dois processos
bastante difundidos e conhecidos que ajudam em ambos os casos. O Rational Unified
Process da IBM ou RUP, oferece uma proposta para a padronização das melhores
práticas em engenharia de software e o Guide to the Project Management Body of
Knowledge (PMBoK) do Project Management Institute (PMI), oferece uma proposta
descritiva de padronização das melhores práticas no gerenciamento de projetos. Ambas as propostas estão disponíveis para as organizações de forma geral e a questão a ser abordada neste documento é quanto a viabilidade de compatibilizá-las para se obter o máximo benefício possível dentro de uma proposta única.
Daqui em diante ambas as propostas são apresentadas de forma superficial e, na sequência, as melhores práticas das disciplinas do RUP são mapeadas para as melhores práticas do PMBoK. O mapeamento permite que sejam percebidas as similaridades e divergências de cada abordagem. Essencialmente, o RUP foca nas melhores práticas de gerenciamento de projetos no contexto de projetos de desenvolvimento e implantação de softwares enquanto as melhores práticas do PMBoK são genéricas e aplicáveis ao gerenciamento de projetos de qualquer natureza, seja na construção de navios petroleiros ou na implantação de novos processos de negócios dentro de uma companhia. Pode-se concluir, portanto, que a disciplina de Gerenciamento de Projeto do
RUP é uma instância específica das melhores e mais genéricas práticas em gerenciamento de projetos do PMBoK.
As melhores práticas em gerenciamento de projetos do RUP identificadas neste documento estão descritas mais detalhadamente na disciplina Gerência de Projetos do padrão proposto. Outras melhores práticas relacionadas mais ou menos superficialmente ao gerenciamento de projetos estão descritas em outras disciplinas da metodologia tais como Modelagem de Negócio, Requisitos, Análise e Projeto, Implementação, Teste, Implantação, Ambiente e Gerência de Configuração e Mudança e, quando necessário, referências serão feitas a elas.
O RUP é uma metodologia para gerenciar projetos de desenvolvimento de
software que usa a Unified Modeling Language ou UML como ferramenta para
modelagem e especificação de sistemas. O RUP é composto por um conjunto de disciplinas que fornecem diretrizes para definição das tarefas e para atribuição de responsabilidades.
O autor identifica também as causas mais comuns de fracassos de projetos de desenvolvimento de softwares, conforme listadas a seguir:
1. Gerenciamento informal dos requisitos;
2. Falha no levantamento dos requisitos e, por consequência, na identificação das reais necessidades dos clientes;
3. Incapacidade de lidar com as mudanças de requisitos; 4. Complexidade crescente e excessiva;
5. Baixa qualidade1
6. Testes insuficientes.
do produto final;
Pode-se perceber a ênfase dada pelo RUP para os requisitos ou escopo do projeto, o que fez com que o padrão proposto ofereça modelos bastante completos e complexos, utilizando largamente a UML, para a especificação de requisitos de
softwares. Há um choque evidente entre a proposta do RUP e dos Métodos Ágeis, pois
o RUP, por ser voltado para grandes equipes de desenvolvimento, não demonstra
1 Segundo a norma ISO 9000:2000, qualidade é o grau em que um conjunto de características inerentes a um produto, processo ou sistema cumpre os requisitos daquele produto, processo ou sistema. Fonte: WIKIPEDIA (2006).
preocupação com a simplificação.
Segundo Charbonneau (2004) “o RUP é um processo de engenharia de software que descreve quem faz o que, quando e como em um projeto de desenvolvimento e implantação de software”. Ele tem como características focar em casos de uso, estar centrado na arquitetura, priorizar riscos e ser iterativo.
Considerando projetos conduzidos com a utilização do RUP, requisitos especificados no formato de casos de uso direcionam para aplicações executáveis. Acrescente-se a isso o fato de que o processo foca o esforço da equipe no que é mais crítico ao projeto e nos elementos estruturais da aplicação antes de centrar esforços no que é secundário. A mitigação dos maiores riscos faz com que a definição do escopo aconteça nas primeiras iterações do ciclo de vida do produto e, finalmente, a divisão do ciclo de vida de desenvolvimento de softwares dentro de iterações produz versões incrementais da aplicação executável.
Para fazer frente aos problemas citados anteriormente e garantir a criação de produtos de alta qualidade, o RUP segue as melhores práticas de desenvolvimento de
software, conforme a seguir:
1. Desenvolvimento iterativo; 2. Gerenciamento de requisitos;
3. Arquitetura baseada em componentes;
4. Organização da especificação através de modelagens do mundo real; 5. Verificação contínua da qualidade;
6. Controle de mudanças.
O RUP implementa as melhores práticas, conforme acima, dentro de um processo bidimensional. Uma dimensão descreve as “disciplinas” enquanto a outra dimensão descreve “fases” dentro do ciclo de vida do processo. A figura a seguir mostra uma representação geral do processo e apresenta as disciplinas e fases do padrão:
Observando-se a disciplina de Gerenciamento de Projeto no gráfico 2, onde são apresentados os relacionamentos no tempo entre as fases e disciplinas do RUP, percebe-se que suas ações percorrem todo o projeto de modo a permitir maior controle sobre ele. É evidenciada também a dinâmica das atividades das disciplinas que participam com maior ou menor intensidade a cada ciclo na medida em que o projeto avança no tempo. Desde o início praticamente todas as disciplinas são acionadas a cada iteração para produzir artefatos e realizar entregas ao cliente.
As disciplinas do RUP são claramente relacionadas às seis melhores práticas citadas anteriormente, mas, de forma um pouco mais detalhada, representam regras individuais para membros ou equipes menores dentro da equipe de desenvolvimento completa.
Cada disciplina do RUP é declarada em termos de regras (quem executa as tarefas), atividades (como eles devem proceder) e artefatos (o que a atividade produzirá). Uma regra define procedimentos e responsabilidades de um indivíduo ou grupo de indivíduos, responsável por atividades e artefatos. Uma atividade é uma tarefa que descreve os passos necessários para criar ou atualizar um ou mais artefatos. Um artefato é uma entrada e/ou uma saída para uma atividade. Outros elementos complementam estes três itens, tais como conceitos, relatórios, modelos, pontos de controle, linhas de trabalho, guias de apoio às ferramentas necessárias e recomendações.
Gráfico 2: Dimensões do RUP
Conforme citado anteriormente, o RUP é iterativo e dividido em quatro fases:
1. Concepção;
2. Elaboração; 3. Construção; 4. Transição.
Cada fase tem um conjunto definido de objetivos e encerra com um marco significativo. Os marcos de cada fase são:
1. O objetivo do ciclo de vida ao fim da Concepção; 2. A arquitetura do ciclo de vida ao fim da Elaboração; 3. Capacidade operacional parcial ao fim da Construção; 4. Entrega de versão do software ao fim da Transição.
O objetivo da Concepção é definir o escopo do projeto. O objetivo da Elaboração é criar uma arquitetura executável para a aplicação. O objetivo da Construção é preencher o esqueleto da arquitetura com a maior parte dos recursos necessários à aplicação. E, finalmente, o objetivo da Transição é entregar a aplicação aos clientes.
Cada fase do RUP é subdividida em iterações, sendo cada uma delas encerrada com um marco menos significativo.
O RUP define o gerenciamento de projetos de software como a arte de balancear a competição entre objetivos, gerenciamento dos riscos e superação dos obstáculos para entregar com sucesso um produto que atenda tanto às necessidades do cliente que solicitou o software quanto às daqueles que efetivamente utilizarão o produto concebido.
A disciplina de Gerenciamento de Projeto do RUP provê:
1. Um modelo para o gerenciamento de projetos voltados ao desenvolvimento de softwares;
2. Regras práticas para o planejamento, organização da equipe, execução e monitoramento de projetos;
Esta disciplina está voltada, essencialmente, para os principais aspectos de um processo de desenvolvimento iterativo:
1. Gerenciamento de riscos;
2. Planejamento de uma determinada iteração do projeto; 3. Monitoramento do progresso de uma iteração do projeto através de métricas.
2.4.1 Primeira comparação entre RUP e PMBoK
Considerando as propostas para gerenciamento de projetos do PMBoK e a disciplina de Gerência de Projetos do RUP, já é possível uma comparação, ainda inicial, entre os dois padrões. O RUP, por ser mais voltado especificamente para projetos de desenvolvimento e implantação de software, não cobre todas as áreas de gerenciamento do PMBoK.
Seguem adiante as áreas de gerenciamento, conforme as melhores práticas propostas pelo PMI, que estão fora do escopo da disciplina de Gerenciamento de Projeto do RUP:
1. Gerenciando pessoas: contratando, treinando, capacitando (aponta para a área de conhecimento de Gerenciamento dos Recursos Humanos do Projeto do PMBoK);
2. Gerenciando orçamentos: definindo e alocando, dentre outras providências (aponta para a área de conhecimento de Gerenciamento de Custos do Projeto do PMBoK);
3. Gerenciando contratos: com fornecedores e clientes (aponta para a área de conhecimento de Gerenciamento das Aquisições do Projeto do PMBoK).
As áreas de conhecimento do PMBoK são apresentadas em mais detalhes adiante. Por enquanto, já é possível perceber que três das nove áreas de conhecimento do PMBoK não possuem disciplinas equivalentes no RUP: Gerenciamento dos Recursos Humanos, Gerenciamento dos Custos e Gerenciamento das Aquisições. Porém, conforme exposto anteriormente, o processo de Planejamento Organizacional do
Gerenciamento de Recursos Humanos mapeia para as “regras” do RUP, cujo propósito é identificar, documentar e assinalar regras e responsabilidades dentro do projeto.
2.4.2 Principais artefatos da disciplina de Gerenciamento de Projeto (RUP) Vários artefatos são criados dentro da disciplina de Gerenciamento de Projeto do RUP. Os principais artefatos estão listados a seguir e a quantidade de vezes que determinado artefato é produzido dentro de um projeto típico é citado entre parênteses (CHARBONNEAU, 2004):
1. Plano de Desenvolvimento do software (um) 1. Plano de Garantia de Qualidade 2. Plano de Gerenciamento de Riscos 3. Plano de Métricas
4. Plano de Aceitação do Produto 5. Plano de Resolução de Problemas 2. Modelagem de Negócio (um)
3. Plano de Iterações (n) 4. Avaliação de Iteração (n) 5. Avaliação de Situação (n) 6. Lista de Riscos (um)
7. Sequência das Atividades (n) 8. Lista de Problemas (um)
9. Controle e Monitoramento do Projeto (n)
A seguir são detalhados quatro artefatos do RUP que servirão de base comparativa para o mapeamento com as melhores práticas do PMBoK (CHARBONNEAU, 2004):
1. O Plano de Desenvolvimento de software é: 1. Criado na fase de Concepção;
3. Preenchido conforme a seguir: 1. Visão Geral do Projeto:
1. Propósito, escopo e objetivos; 2. Restrições e premissas;
3. Produtos e serem entregues pelo
projeto. 2. Organização do Projeto: 1. Estrutura organizacional; 2. Interfaces externas; 3. Regras e responsabilidades. 3. Processo de Gerenciamento: 1. Estimativas do projeto; 2. Plano de projeto; 3. Planos de iteração; 4. Controle e monitoramento do projeto. 4. Outros planos. 2. O Plano de Iterações é:
1. Criado a cada iteração; 2. Prenchido conforme a seguir:
1. Plano;
2. Recursos; 3. Casos de uso;
4. Critérios de avaliação. 3. A Visão é:
1. Não é um artefato da disciplina de Gerenciamento de Projeto do RUP. A Visão é um artefato produzido pela
disciplina Requisitos;
2. Artefato criado na fase de Concepção; 3. Preenchido conforme a seguir:
1. Posicionamento:
1. Oportunidades de negócios; 2. Declaração de problemas;
3. Declaração de posicionamento do
produto.
2. Descrições de atores e clientes envolvidos: 1. Descrições dos atores;
2. Descrições dos clientes; 3. Necessidades dos atores. 3. Visão geral do produto;
4. Características do produto; 5. Restrições;
6. Outras informações. 4. A Modelagem do Negócio é:
1. Criada na fase de Concepção; 2. Preenchida conforme a seguir:
1. Descrição do produto; 2. Contexto do negócio; 3. Objetivos do produto; 4. Previsão financeira; 5. Restrições.
2.5 Visão geral do PMBoK
Os conceitos sobre o PMBoK aqui apresentados são baseados em Possi (2004) e Charbonneau (2004). O PMBoK descreve um conjunto bem aceito de práticas que pessoas envolvidas na coordenação de projetos podem usar para gerir qualquer tipo de projeto, incluindo aqueles voltados para o desenvolvimento e implantação de softwares. O PMBoK define um projeto como “um empreendimento temporário com o objetivo de criar um produto ou serviço único”. Já o gerenciamento de projetos é definido como “a aplicação de conhecimentos, habilidades, e técnicas para projetar atividades que visem atingir ou exceder as necessidades e expectativas das partes envolvidas, com relação ao projeto” (PMBoK, 2000).
O PMBoK apresenta as práticas de gerenciamento de projetos em agrupamentos lógicos. Uma dimensão descreve “áreas de conhecimento” enquanto outra descreve os processos de gerenciamento ordenados em cinco grupos de processos. O quadro a seguir mostra uma visão geral de todos os 39 processos do PMBoK (2000):
Quadro 2: Visão geral do PMBoK
Grupos de processos
Iniciação Planejamento Execução Controle Encerramento
Área de conhecimento 4. Gerenciamento da Integração do Projeto 4.1 Elaboração do plano do projeto 4.2 Execução do plano do projeto 4.3 Controle integrado de alterações 5. Gerenciamento do Escopo do Projeto 5.1 Iniciação 5.2 Planejamento do escopo 5.3 Definição do escopo 5.4 Verificação do escopo 5.5 Controle de alterações do escopo 6. Gerenciamento do Tempo do Projeto 6.1 Definição das atividades 6.2 Sequenciamento das atividades 6.3 Estimativa de duração das atividades 6.4 Elaboração do cronograma 6.5 Controle do cronograma 7. Gerenciamento de Custos do Projeto 7.1 Planejamento dos recursos 7.2 Estimativas de custos 7.3 Orçamento de custos 7.4 Controle de custos 8. Gerenciamento da Qualidade do Projeto 8.1 Planejamento da qualidade 8.2 Garantia de qualidade 8.3 Controle de qualidade 9. Gerenciamento de Recursos Humanos do Projeto 9.1 Planejamento organizacional 9.2 Formação da equipe 9.3 Desenvolvimento da equipe 10. Gerenciamento das Comunicações do Projeto 10.1 Planejamento das comunicações 10.2 Distribuição de informações 10.3 Relatório de desempenho 10.4 Encerramento administrativo 11. Gerenciamento de Riscos do Projeto 11.1 Planejamento do gerenciamento de riscos 11.2 Identificação de riscos 11.3 Análise qualitativa de riscos 11.4 Análise quantitativa de riscos 11.4 Planejamento de respostas a riscos 11.6 Monitoração e controle de riscos 12. Gerenciamento das Aquisições do Projeto 12.1 Planejamento das aquisições 12.2 Planejamento da solicitação 12.3 Solicitação 12.4 Seleção das fontes 12.5 Administração do
contrato
12.6 Encerramento do contrato
Observando-se o quadro anterior, percebe-se claramente a forte preocupação do PMBoK com processos de controle sobre o planejamento, execução e controle. São 36 processos que buscam garantir, principalmente, a máxima fidelidade quanto ao escopo inicialmente contratado, o tempo estimado e os custos previstos.
2.5.1 Áreas de conhecimento do PMBoK e grupos de processos As áreas de conhecimento do PMBoK são (POSSI, 2004, p. 34):
1. Gerenciamento da Integração do Projeto: Descreve os processos necessários para assegurar que diversos elementos do projeto sejam adequadamente coordenados;
2. Gerenciamento do Escopo: Descreve os processos necessários para assegurar que o projeto contemple todo o trabalho necessário, e tão somente o trabalho necessário, para completar o trabalho com sucesso;
3. Gerenciamento do Tempo: Descreve os processos necessários para assegurar que o projeto termine dentro dos prazos previstos;
4. Gerenciamento do Custo: Descreve os processos necessários para assegurar que o projeto seja completado dentro do orçamento previsto;
5. Gerenciamento da Qualidade: Descreve os processos necessários para assegurar que as necessidades que originaram o desenvolvimento do projeto serão satisfeitas;
6. Gerenciamento dos Recursos Humanos: Descreve os processos necessários para proporcionar a melhor utilização das pessoas envolvidas no projeto;
7. Gerenciamento das Comunicações: Descreve os
processos necessários para assegurar que a geração, captura, armazenamento e distribuição de informações sobre o projeto sejam feitas de forma adequada;
8. Gerenciamento de Riscos: Descreve os processos que dizem respeito à identificação, análise e resposta aos riscos do projeto;
9. Gerenciamento das Aquisições: Descreve os processos necessários para a aquisição de bens e serviços fora da organização executora do projeto.
Cada área de conhecimento do PMBoK descreve conhecimentos e práticas de gerenciamento de projetos em termos de um ou mais processos. Cada processo é descrito conforme suas entradas, saídas, ferramentas e técnicas. Entradas e saídas são documentos ou itens documentáveis. Ferramentas e técnicas são mecanismos aplicados às entradas para produzir as saídas de um processo.
Os processos de gerenciamento de projetos do PMBoK são organizados em cinco grupos, cada um deles contendo um ou mais processos que são ligados entre si pelos resultados que produzem (POSSI, 2004, p.32):
1. Processos de Iniciação: Fase inicial do projeto, quando uma determinada necessidade é identificada e traduzida em um problema. O projeto é formalmente iniciado e autorizado. Tem como características o reconhecimento que um projeto deve começar e a formalização do comprometimento da execução;
2. Processos de Planejamento: São processos de onde os objetivos do projeto são refinados e detalhados e as ações que visam atingi-los são identificadas e selecionadas. Neste grupo de processos encontra-se o detalhamento dos trabalhos a serem realizados, suas estimativas de duração e sequenciamento lógico, identificação de recursos necessários à realização do projeto, elaboração de cronograma e orçamento, além de planos de atuação para facilitação do gerenciamento do projeto. Tem como característica a criação de um plano de trabalho viável para que os objetivos de negócios sejam atingidos;
3. Processos de Execução: Processos ligados à execução dos trabalhos planejados. Têm como características a coordenação de pessoas e a utilização de recursos para a realização do plano do projeto;
4. Processos de Monitoramento e Controle: Conjunto de processos que visam assegurar que os trabalhos executados seguem o
planejamento original, identificando pontos de ações preventivas e corretivas que eliminem anormalidades percebidas através da medição e monitoramento regular das ações;
5. Processos de Encerramento: São processos que visam caracterizar o encerramento formal e organizado de um projeto através da avaliação dos trabalhos realizados, arquivo documental das atividades realizadas e análise do aprendizado adquirido.
A ilustração a seguir apresenta os cinco grupos de processos e o fluxo de informações entre eles:
Apesar do PMBoK não explicitar em sua proposta atividades iterativas em projetos, a figura anterior permite perceber que implicitamente isso é possível quando são consideradas as interações que ocorrem entre os grupos de processos de planejamento, execução e controle.
2.5.2 Ciclos de vida no PMBoK
O PMBoK não prevê ciclos de vida específicos para projetos. Ele especifica, porém, que o projeto deve ser dividido em fases. O número de fases varia de acordo com o escopo do projeto e o domínio da aplicação. Ele identifica de quatro a nove fases como uma quantidade típica para qualquer tipo de projeto.
Figura 4: Grupos de processos do PMBoK
2.5.3 Produtos do PMBoK
O PMBoK define um produto como um resultado de um trabalho, tangível e verificável, tal como um estudo de viabilidade, um desenho detalhado ou um protótipo funcional.
Seguem adiante alguns dos principais produtos do PMBoK:
1. Project Charter (com restrições e premissas);
1. Plano de Projeto;
2. Resultados do Trabalho e Solicitações de Mudanças; 3. Ações Corretivas e Lições Aprendidas;
O Plano de Projeto é:
1. Criado no processo de Elaboração do Plano do Projeto logo no início do projeto;
2. Atualizado no decorrer do andamento do projeto; 3. Preenchido conforme a seguir:
1. Project Charter;
2. Descrição da abordagem ou estratégia da gerência de projetos (um sumário dos planos de gerência individuais das outras áreas de conhecimento);
3. Declaração de escopo: 1. Objetivos do projeto; 2. Produtos do projeto.
4. Estrutura Analítica do Projeto (EAP) até o onde o controle deve ser exercido;
5. Estimativas de custos, datas programadas para início das atividades e atribuições de responsabilidade no nível adequado do EAP;
6. Métricas para medir desempenho de escopo, prazo e custo;
7. Marcos principais e datas previstas; 8. Equipe necessária;
9. Outros planos.
O Project Charter possui características específicas, conforme a seguir: 1. Autoriza formalmente um projeto;
2. É criado no processo de Iniciação, logo no início do ciclo de vida do projeto;
3. Deve ser preenchido da seguinte maneira: 1. Necessidades do negócio;
3.
Mapeamento entre PMBoK e RUP
Este capítulo, baseado em artigo de Charbonneau (2004), busca apresentar as semelhanças e diferenças entre as propostas do RUP e do PMBoK.
Deve ser observado que eventualmente os elementos do PMBoK não são perfeitamente identificados com os do RUP e vice-versa. A proposta aqui, foco deste documento, é verificar a viabilidade de aproximação entre os padrões propostos.
Para que a comparação seja possível, o PMBoK é utilizado como referência por ser o mais genérico dos dois padrões. O RUP é comparado a ele.
3.1 Características comuns
Tanto o RUP como o PMBoK reconhecem que o gerenciamento de projetos é um empreendimento iterativo. O PMBoK (2004) descreve isto da seguinte maneira:
“É importante observar que muitos processos dentro do gerenciamento de projetos são iterativos devido à existência, e necessidade, de uma elaboração progressiva em um projeto durante todo o seu ciclo de vida. Isto é, conforme uma equipe de gerenciamento de projetos aprende mais sobre um projeto, poderá gerenciar com um nível maior de detalhes.”
O quadro a seguir provê um mapeamento entre as principais características do PMBoK e RUP:
O PMBoK, por ser mais genérico, cobre todos os aspectos da gerência de projetos. O RUP, com foco em projetos de desenvolvimento de softwares, não abrange
Quadro 3: Principais características do PMBoK e RUP
PMBoK RUP
Qualquer tipo de projeto Projetos específicos de desenvolvimento de software Somente práticas de gerenciamento de
projetos
Práticas de gerenciamento de projetos e de desenvolvimento de software
Cobre todos os aspectos do gerenciamento de projetos
Cobre alguns aspectos do gerenciamento de projetos
Descritivo Prescritivo
As fases dependem da natureza do projeto
Fases e iterações são específicas para o desenvolvimento de software
todos esses aspectos, conforme exposto em capítulo anterior. Por outro lado, o RUP, por ser mais específico, prescreve detalhadamente tudo que deve ser realizado em um projeto de software.
3.2 Mapeando os modelos
Tanto o RUP quanto o PMBoK reunem atividades dentro de estruturas de grupos e grupos temporais. O RUP tem grupos de atividades chamados disciplinas e grupos temporais de atividades chamados fluxos de trabalho (workflows). O PMBoK possui grupos de processos chamados áreas de conhecimento e grupos temporais de atividades chamados grupos de processos.
Os quadros a seguir apresentam um mapeamento entre o RUP e o PMBoK:
Tomando por base o quadro anterior, percebe-se que não há diferenças significativas entre as duas propostas. As distinções estão principalmente nas
Quadro 4: Principais elementos do PMBoK e RUP
ELEMENTO PMBoK RUP
Tipo de projeto Qualquer tipo de projeto Projetos de desenvolvimento e implantação de software Ciclo de vida do
projeto
Dividido em fases. Normalmente de 4 a 5, chegando eventualmente a 9 ou mais. Cada fase é marcada pelo término de um ou mais subprodutos
Dividido em 4 fases: Iniciação, Elaboração, Construção e
Transição. Cada fase é dividida em uma ou mais iterações que inclui atividades de todas as disciplinas. Cada iteração produz uma versão executável da aplicação ou sistema a ser entregue
Fim de fase Marco Marco significativo Artefato de fim de
fase
Subproduto Artefato
Atividade Processo descrito em termos de entradas, saídas, ferramentas e técnicas
Atividade descrita em termos de artefatos de entrada, artefatos produzidos e passos a serem seguidos com guias de utilização e diretrizes
Artefato de entrada Entrada Artefato de entrada Artefato de saída Saída Artefato produzido Revisão de fim de
fase
Saídas de fase, marcos de estágio ou pontos de interrupção (kill point)
Revisão de marco do ciclo de vida
Grupos de atividades Área de conhecimento Disciplina Grupo temporal de
atividades
Grupo de processos Fluxo de trabalho (workflow)
nomenclaturas, mas os conceitos, de modo geral, são semelhantes. A principal diferença está na especificidade dos projetos a serem desenvolvidos com o apoio do RUP que devem, sem exceção, ser voltados à concepção de softwares. Merece destaque também que o RUP detalha exatamente o que, como e por quem determinadas atividades devem ser realizadas para que um projeto de software seja bem sucedido, algo que deve ser definido pela equipe de projeto que trabalha nos moldes do PMBoK.
O quadro anterior mostra que a disciplina de Gerenciamento do Projeto do RUP concentra praticamente todas as áreas de conhecimento do PMBoK. Apesar disso, o RUP deixa pontos da gerência de projetos em aberto no que refere ao gerenciamento de pessoas, orçamentos e contratos. Por serem aspectos críticos a maioria dos projetos, o PMBoK apresenta-se como uma referência mais completa e mais madura, considerando todos os aspectos que envolvem a gestão de projetos, incluindo projetos de software.
3.3 Mapeando processos do PMBoK às atividades do RUP
O anexo VIII, conforme proposto por Charbonneau (2004), apresenta uma proposta de mapeamento entre os processos do PMBoK e atividades do RUP.
Realizando uma análise mais aproximada do comparativo é possível perceber as
Quadro 5: Mapeando as áreas de conhecimento do PMBoK às disciplinas do RUP
ÁREA DE CONHECIMENTO DO PMBoK DISCIPLINA DO RUP Gerenciamento da Integração do Projeto Gerenciamento do Projeto
Requisitos Implantação
Gerência da Configuração e Mudança Gerenciamento do Escopo do Projeto Gerenciamento do Projeto
Requisitos
Gerência da Configuração e Mudança Gerenciamento de Tempo do Projeto Gerenciamento do Projeto
Gerenciamento de Custos do Projeto Gerenciamento do Projeto Gerenciamento da Qualidade do Projeto Gerenciamento do Projeto
Gerência da Configuração e Mudança Gerenciamento de Recursos Humanos do
Projeto
Gerenciamento do Projeto
Gerenciamento das Comunicações do Projeto Gerenciamento do Projeto Gerenciamento de Riscos do Projeto Gerenciamento do Projeto Gerenciamento das Aquisições do Projeto Requisitos
omissões do RUP no que se refere aos aspectos específicos das gerência de projetos. Os processos de Orçamento de Custos e Controle de Custos (Gerenciamento de Custos do Projeto) e Desenvolvimento da Equipe (Gerenciamento de Recursos Humanos do Projeto) não possuem equivalência na proposta do RUP. Além disso, os processos de Planejamento da Solicitação, Solicitação, Seleção das Fontes, Administração do Contrato e Encerramento do Contrato, todos referentes à área de conhecimento Gerenciamento das Aquisições do PMBoK também não estão cobertas pelo RUP, requerendo práticas e técnicas complementares em projetos de software de maior porte e que requeiram serviços de terceiros.
3.4 Primeiras conclusões
Charbonneau (2004) utilizou os comparativos entre o RUP e o PMBoK, conforme expostos e comentados anteriormente, para defender que não há incompatibilidades fundamentais entre os dois padrões propostos pela IBM e PMI. Conforme mostrado, termos diferentes são utilizados para descrever conceitos semelhantes, mas nada no RUP contradiz práticas defendidas pelo PMBoK, assim como nada do PMBoK contradiz as melhores práticas do RUP.
Diante disto, o capítulo a seguir propõe um modelo híbrido, tendo como base o padrão do PMBoK para gerenciamento de projetos combinada com as boas práticas do RUP voltadas ao desenvolvimento de softwares. Para que a proposta aqui defendida seja atingida no que diz respeito a sugestão de um método simplificado para projetos de pequeno e médio porte voltados ao desenvolvimento e implantação de software, os conceitos de métodos ágeis serão utilizados como referência e o padrão proposto pelo PMBoK será tomado como base para processos de gerenciamento de projetos. O RUP é integrado com suas boas práticas relacionadas a processos de desenvolvimento de
4.
Proposta de Metodologia Simplificada Unindo PMBoK e RUP
O gráfico a seguir apresenta o ciclo de vida da metodologia proposta. Completamente voltada para o desenvolvimento e implantação de softwares, o método é baseado no padrão sugerido pelo PMBoK para o gerenciamento de projetos. Para as práticas específicas de desenvolvimento de software, são utilizados somente os artefatos do RUP minimamente necessários para projetos de pequeno e médio porte de modo a simplificar e facilitar sua adoção.
O gráfico acima apresenta o ciclo de vida dos projetos conforme a metodologia proposta, onde as fases são sequenciadas e bem identificadas de modo a facilitar o entendimento e adoção do modelo.
O objetivo principal é atingir o máximo de eficiência possível em equipes de desenvolvimento de menor porte ao contemplar os seguintes aspectos:
1. Realização de entregas rápidas e cíclicas;
2. Concepção de produtos sempre alinhados ao negócio do
contratante;
3. Obtenção de índices altos de satisfação dos clientes e demais interessados;
4. Equipes motivadas ao obterem resultados contínuos e medidos.
Gráfico 3: Ciclo de vida da metodologia proposta
INICIAÇÃO PLANEJAMENTO EXECUÇÃO CONTROLE ENCERRAMENTO
Fonte: O autor, 2006 Processo Processo Requisito Tempo Implement Processo Controle
4.1 Processo de Triagem
Conforme previsto no PMBoK 2004, capítulo 3, a aprovação do projeto e a alocação de recursos financeiros estão fora dos seus limites de atuação. A metodologia proposta, portanto, não prevê esta etapa e preocupa-se apenas em viabilizar a condução de projetos cuja existência foi decidida anteriormente.
A responsabilidade por realizar a triagem, necessária para decidir quais projetos serão iniciados e suas respectivas prioridades, fica a cargo da direção da empresa patrocinadora ou do cliente. Em empresas com boa governança, esta decisão é tomada em processos de planejamento periódicos que envolvem diversos profissionais, setores estratégicos, parceiros e clientes.
Há técnicas de seleção de projetos, sugeridas pelo PMBoK, que podem ser bastante úteis em empresas que ainda não adotaram boas práticas de planejamento. O PMBoK sugere abordagens comparativas e matemáticas que podem apoiar o decisor e/ou sua equipe. Por ser mais simples e de fácil adoção, apesar de menos precisa, a abordagem comparativa apresenta-se como uma possibilidade para tomadores de decisão.
O anexo I apresenta um modelo de tabela de decisão, onde, através da definição de critérios de seleção e pesos, pontuações e técnicas de reunião, uma equipe pode classificar e priorizar projetos, além de descartar os que não atendem aos critérios de relevância estabelecidos.
4.2 Iniciação
Conforme já exposto, a metodologia pressupõe que o projeto passou por um processo de triagem e foi aceito pela organização ou equipe designada para realizar esta atividade.
Esta etapa prevê que o negócio deve ser modelado de modo a, principalmente, identificar e documentar os atores (pessoas, setores, empresas, parceiros e fornecedores) interessados no projeto e suas principais regras, processos e produtos a serem concebidos. Os primeiros requisitos são levantados após a aceitação formal do projeto.
O aceite deve ocorrer por escrito e com o aval dos principais patrocinadores do empreendimento. O documento deve estar em formato e meio sabidamente aceito por
todas as partes e deve ser arquivado para consulta sempre que necessário.
4.3 Planejamento
O Plano de Projeto deve ser elaborado e conter uma visão geral do projeto, incluindo cronograma com as principais previsões, riscos identificados e respectivas ações, recursos e investimentos necessários (análise dos custos), plano de comunicações e critérios de aceitação dos produtos (controle de qualidade):
Visão geral do projeto:
1. Objetivo;
2. Identificação do cliente;
3. Escopo resumido. Os requisitos iniciais e os casos de uso identificados (RUP), mas ainda sem detalhes, devem ser levantados e modelados. A aprovação do cliente é indispensável (esta prática se repetirá seguidamente para garantir a correção dos requisitos levantados, a aproximação da equipe do projeto com o cliente e o compromisso do contratante ou seu representante com o produto a ser concebido);
4. Produtos a serem desenvolvidos; 5. Premissas;
6. Restrições;
7. Equipe e serviços de terceiros. O perfil da equipe deve ser identificado com suas respectivas responsabilidades. As pessoas com o perfil desejado devem ser alocadas e a necessidade de terceirização deve ser indicada, se for o caso. Este item é crítico e pré-requisito para os processos relacionados ao desenvolvimento do software contratado;
8. Cronograma com os principais ciclos e datas do projeto definidos. A cada ciclo o cronograma deve ser melhor detalhado para que as responsabilidades sejam devidamente atribuídas. Deve ser aprovado junto ao cliente.
Análise de riscos e definição de ações relacionadas:
software está em falhas no levantamento, identificação de itens críticos e gerência das
mudanças relacionadas aos requisitos do software a ser desenvolvido. Nesta fase devem ser identificados os módulos essenciais ao projeto, pois são os que devem receber maior atenção. Para minimizar o risco e maximizar as chances de sucesso, os módulos críticos devem ser desenvolvidos em prioridade logo nos primeiros ciclos de entrega do projeto. A adoção desta prática possibilita que falhas nos requisitos sejam identificadas mais cedo dentro do ciclo de vida do projeto e corrigidas no decorrer das iterações seguintes. Riscos externos ao projeto, tais como falência da empresa, falência da contratante, mudanças na legislação, mudanças na equipe, dentre outros, devem ser considerados, priorizados e analisados a cada empreendimento;
Recursos e investimentos previstos:
1. Total de horas previstas e respectivos custos;
2. Aquisição de equipamentos e licenças de aplicativos (opcional);
3. Treinamentos (opcional);
4. Contratação de fábricas de software (opcional). Plano de comunicações;
Critérios para aceitação de produtos.
Um modelo de documentos para elaboração de planos de projeto encontra-se disponível no anexo II como referência.
4.4 Requisitos
Nesta etapa, com os ciclos de desenvolvimento definidos durante a concepção do plano de projeto, os requisitos referentes aos programas a serem desenvolvidos na próxima iteração devem ser cuidadosamente detalhados e validados utilizando os seguintes artefatos:
1. Casos de uso detalhados (RUP). Deve ser aprovado pelo cliente; 2. Modelo de dados;
4. Desenhos das interfaces, caso necessárias. Devem ser aprovadas pelo cliente;
5. Diagramas de implementação (RUP).
Técnicas de entrevista, condução de reuniões e de relações humanas devem ser utilizadas intensivamente para que os processos de levantamento de requisitos sejam precisos e evitem ou reduzam ao máximo, pedidos de mudança ou incorreções com conseqüentes retrabalhos e atrasos.
4.5 Tempo
Uma vez que os requisitos a serem implementados estão detalhados, o cronograma deve ser esmiuçado para o ciclo em curso, principalmente para melhor controle interno, e as atividades devem ser atribuídas aos membros da equipe pelo gerente do projeto, analista de negócios ou de sistemas responsável por sua condução.
A periodicidade com que as atividades serão controladas deve estar previsto no Plano de Projeto. A comparação entre o tempo previsto e o realizado, devidamente apropriado pelos membros da equipe, permitirá o controle sobre o ciclo em andamento e o projeto como um todo.
4.6 Implementação
A implementação requer a utilização de técnicas, ferramentas e procedimentos específicos da tecnologia adotada pela equipe de desenvolvimento, empresa contratada ou empresa contratante, caso ela assim o exija, para a codificação de software.
Em resumo, as atividades a seguir devem ser contempladas: 1. Implementação do projeto gráfico;
2. Implementação de programas com equipe própria;
3. Implementação de programas com fábricas de software
contratadas (opcional).
4. Realização de testes integrados (garantia de qualidade); 5. Aprovação junto ao cliente;
6. Implantação da versão desenvolvida (parcial ou totalmente); 7. Treinamento do cliente e/ou sua equipe;
O anexo III apresenta um modelo de cronograma onde a implementação é realizada com programas em Java/JSP e a utilização de geradores de código, ferramentas de mercado e fábricas de software.
4.7 Controle
Esta etapa é fundamental para a gestão do projeto e controles de qualidade das entregas.
As seguintes atividades devem estar cobertas:
1. Entrega formal por escrito. A entrega deve ser realizada por meio sabidamente aceito por todos os envolvidos e arquivado de tal maneira que possa ser consultado sempre que necessário;
2. Reunião de acompanhamento e controle.
A reunião de acompanhamento é uma prática necessária para o sucesso do projeto, pois permite que o gerente do projeto realize a revisão dos riscos identificados, revise contratos que eventualmente tenham sido assinados, controle custos e respectivos desembolsos e o desempenho da equipe.
Após cada reunião de fim de ciclo devem ser realizadas as devidas comunicações, conforme previsto no Plano de Projeto.
4.8 Encerramento
Os processos de encerramento devem documentar informações que servirão de matéria-prima para os próximos projetos. Uma atividade fundamental é a realização de pesquisa de satisfação junto ao cliente. O resultado da pesquisa possibilita que a equipe tenha medida mais precisa do grau de sucesso do empreendimento que está se encerrando. Os pontos não ou mal atendidos devem ser identificados e as medidas corretivas imediatamente informadas aos responsáveis para garantir a melhoria para os próximos projetos.
1. Aprovação final junto ao cliente;
2. Submissão de pesquisa qualitativa de satisfação abordando postura da equipe, qualidade do produto entregue, atendimento às expectativas e nível de satisfação geral quanto a condução do projeto; 3. Reunião final, onde ações corretivas e lições aprendidas devem ser identificadas e registradas;
4. Toda a documentação pertinente deve ser reunida e arquivada; 5. Encerramento do projeto;
6. Comemoração. A comemoração permite que a equipe se sinta valorizada e motivada e desfrute das conquistas obtidas. Em setores que convivem diariamente com rotinas estressantes, essa boa prática pode preparar o espírito de equipe e da equipe para os próximos desafios a serem superados.
4.9 Estrutura Analítica do Projeto1
A ilustração a seguir apresenta o ciclo de vida da metodologia proposta através da EAP em sua visão mais básica:
A partir da EAP foram identificadas as principais atividades apresentadas na ilustração conforme a seguir:
1 Ferramenta de decomposição do trabalho do projeto em partes manejáveis. É uma estrutura em árvore, hierárquica (do mais geral ao mais específico) de entregáveis (deliverables) e tarefas que precisam ser realizadas para completar um projeto. Fonte: WIKIPEDIA (2006).
Figura 5: EAP da metodologia proposta
Propositalmente, as atividades referentes à etapa de Implementação não foram detalhadas. Isso se deve ao fato destas atividades envolverem procedimentos específicos da tecnologia adotada pela empresa ou equipe do projeto. É apresentada logo abaixo uma sugestão de atividades prevendo a contratação opcional de terceiros e a implementação de programas pela equipe do projeto utilizando tecnologia Java/JSP para codificação do software. As atividades de entrega de cada módulo desenvolvido são obrigatórias e estão presentes em todos os projetos, independentemente da tecnologia utilizada:
A partir da Estrutura Analítica do Projeto o cronograma pode ser inferido. As atividades sequenciadas e todos os passos a serem seguidos serão detalhados item a item mais adiante.
Figura 6: EAP e principais atividades da metodologia proposta Fonte: O autor, 2006
Figura 7: EAP com etapas e atividades da fase de Implementação
