PONTIFCIA UNIVERSIDADE CATLICA DO RIO GRANDE DO SUL FACULDADE DE INFORMTICA PROGRAMA DE PS-GRADUAO EM CINCIA DA COMPUTAO

PROPOSTA DE INTEGRAO RUP + PMBOK NA GERNCIA DE ESCOPO NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ANDR LUS SANSON GOMES

Dissertao apresentada como requisito para obteno do grau de Mestre, pelo Programa de Ps-Graduao da Faculdade de Informtica da Pontifcia Universidade Catlica do Rio Grande do Sul.

ORIENTADOR: PROF. DR. JORGE LUIS NICOLAS AUDY

PORTO ALEGRE 2009

G633p

Gomes, Andr Sanson Proposta de integrao RUP + PMBOK na gerncia de escopo no processo de desenvolvimento de software / Andr Lus Sanson Gomes. Porto Alegre, 2009. 137 f. Diss. (Mestrado) Fac. de Informtica, PUCRS. Orientador: Prof. Dr. Jorge Luis Nicolas Audy. 1. Informtica. 2. Engenharia de Software.

Ficha Catalogrfica elaborada pelo I. Audy, Jorge 3. Administrao de Projetos Computao. Luis Nicolas. II. Ttulo. Setor de Processamento Tcnico da BC-PUCRS

CDD 005.1

Ficha Catalogrfica elaborada pelo Setor de Tratamento da Informao da BC-PUCRS

DEDICATRIA

minha Soninha, por tudo que passamos neste perodo e pelo fortalecimento que tivemos em nosso relacionamento.

AGRADECIMENTOS Aos meus pais Avelino e Selma, de quem eu sinto tantas saudades, o mestrado serviu para nos encontrarmos mais vezes, j que estou desgarrado do RS h 10 anos, volta e meia, dei um pulo em Cachoeira do Sul para matar a saudade. Aos meus diletos amigos Prof. Geovane B. Girelli, Prof. Adavilso Parpinelli e Prof. Charles Berta, sempre nos reunamos para um bate papo e algumas vezes tiveram que discutir comigo sobre: Nmero de Frodo, Nmeros Montanhosos e Generais Bizantinos e como me ajudaram com a soluo. Ao meu orientador, professor Dr. Jorge Luis Nicolas Audy, pelas contribuies e observaes sempre pontuais sobre o trabalho, por ter entendido minhas vrias dificuldades encontradas e minha correria para cumprir os prazos, mas sempre me apoiando. Alm das frases que ficavam martelando: tempo no se recupera!, dissertao boa a dissertao entregue. Valeu Professor!!! Ao professor avaliador Dr. Marcelo Blois Ribeiro, que em momentos especficos do mestrado, PEP e Seminrio de Andamento, auxiliou no direcionamento e aperfeioamento deste trabalho. Mais do que isso, foi professor de duas disciplinas do Minter e logo fora escolhido por todos ns como uma referncia profissional. Alm ainda, claro, da frase: t errado!!!. Que antecedia a uma boa discusso acadmica a respeito da matria. Agradeo aos professores do PPGCC/PUCRS os quais tive a satisfao de assistir s suas aulas e que assim como ns tambm enfrentaram as viagens entre o RS e MT. Ao Governo do Estado de Mato Grosso que, atravs da UNEMAT e FAPEMAT, oportunizaram este desenvolvimento ao nosso estado, mesmo sendo do grupo externo ao de professores da UNEMAT, sei o quanto isto ir representar para esta instituio. Ao diretor e colegas da empresa Oeste Veculos LTDA, que primeiramente entenderam que esta era uma oportunidade nica para minha vida, e ainda, o mais importante, se desdobraram em suas atividades nas vrias vezes que me ausentei. Aos colegas de mestrado, turma MINTER PUCRS/UNEMAT, conhecidos como minterianos, que j no primeiro instante tivemos problemas e quase que o programa no comeara. Demonstrou-se ali a unio de pessoas totalmente desconhecidas mas que desejavam o melhor para as suas vidas, as suas carreiras e principalmente para o desenvolvimento do Estado de Mato Grosso. Que dura foi a conquista de cada um. Parabns!

PROPOSTA DE INTEGRAO RUP + PMBOK NA GERNCIA DE ESCOPO NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

RESUMO As organizaes de desenvolvimento de software esto sempre buscando aumentar a qualidade dos produtos de software, para isto necessrio que os processos sejam bem definidos e possam ser controlados. Entretanto, algumas dificuldades so encontradas como: processos voltados totalmente para a atividade produtiva e com pouco ou nenhuma atividade gerencial, m gerncia de projetos ou ausncia de gerncia, no atendimento a expectativa dos envolvidos. Estes processos devem permitir uma metodologia de gerncia de projetos, que descreva as atividades importantes para garantir a qualidade do projeto com um todo, incluindo o produto e o processo. Neste contexto, esta pesquisa prope um processo integrado utilizando uma metodologia de gerncia de projetos e um processo de desenvolvimento de software na rea de gerenciamento de escopo. Contribuindo para que atividades gerenciais e produtivas sejam executadas de forma integrada e utilizando a rea de gerenciamento de escopo para determinar corretamente como estas atividades devem ser desenvolvidas no projeto de modo a se produzir as entregas previstas. Assim, apresenta-se o processo e um exemplo de uso, para que possa auxiliar os gestores na tomada de deciso e planejamento, execuo e controle dos projetos. Palavra-Chave: Gerncia de Projetos. Processo de Desenvolvimento de Software. Processo Integrado.

PROPOSTA DE INTEGRAO RUP + PMBOK NA GERNCIA DE ESCOPO NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

ABSTRACT Software organizations of development are always searching to increase the product quality of software, for that is necessary that the processes well are defined and can be controlled. However, some difficulties are found as: processes directed total toward the productive activity and with little or no management activity, bad the management of projects or absence of management, not attendance the expectation of the involved ones. These processes must allow a methodology of management of projects that describes the activities important to all to assure the quality of the project with one, including the product and the process. In this context, this research considers an integrated process using a methodology of management of projects and a process of development of software in the area of target management. Contributing so that management and productive activities are executed of integrated form and using the area of target management to determine correctly as these activities they must be developed in the project in order to produce the foreseen deliveries. Like this, the process is presented and a use example, so that it can assist the managers in the taking of decision and planning, execution and control of the projects. Keywords: Project Management. Software Development Process. Integrated Process.

LISTA DE FIGURAS

Figura 1 - Relatrio de CHAOS publicado pelo The Standish Group International [IKE06]. .................................................................................................................................... 26 Figura 2 - Sequncia tpica de fases no ciclo de vida de um projeto [Pmi04]. ................... 30 Figura 3 - Grupos de Processos PMBOK [Pmi04]. ............................................................ 31 Figura 4 - Interao de grupos de processos em um projeto [Pmi04]. .............................. 32 Figura 5 - reas de Conhecimento no Gerenciamento de Projetos................................... 32 Figura 6 - Grupo de Processos e seus Processos [Sot07a]. ............................................. 34 Figura 7 - Viso geral da arquitetura do RUP [RAT08]. ..................................................... 37 Figura 8- Aspectos considerados mais importantes no gerenciamento de projetos [INT07]. .................................................................................................................................... 42 Figura 9 - Problemas que ocorrem com mais freqncia nos projetos das organizaes [INT07]. ....................................................................................................................... 43 Figura 10 - Processos, Entradas e Sadas do Gerenciamento de Escopo. Adaptado de [Sot07]. ....................................................................................................................... 46 Figura 11 - Exemplo de Modelo para criar EAP. Adaptado de [Sot07]. ............................. 49 Figura 12 Exemplo EAP para uma verso de um software [Bar06]. ............................... 50 Figura 13 - A estrutura do PMBOK executada dentro de cada iterao [COT04]........... 56 Figura 14 - As disciplinas do RUP expandidas com o PMBOK [TEM08]. .......................... 58 Figura 15 Desenho da pesquisa ..................................................................................... 62 Figura 16 - Abordagens do RUP e PMBOK. ...................................................................... 66 Figura 17 - Grupo de Processos PMBOK e Atividades RUP - Gerncia de Escopo. ........ 69 Figura 18 - RMC e a separao de contedo do mtodo dos processos no RUP [RMC08]. .................................................................................................................................... 73 Figura 19 - Principais Elementos do RMC e sua relao: contedo de mtodo e processo [RMC08]. .................................................................................................................... 73 Figura 20 - Tela com a configurao de mtodo da integrao RUP e PMBOK. .............. 75 Figura 21 - Opo de escolha de novo elemento do mtodo. ........................................... 76 Figura 22 - Tela de um elemento de mtodo do tipo tarefa e seu contedo. ..................... 77 Figura 23 - Conjunto de Funes: Analista e Funes Gerais........................................... 83 Figura 24 - Conjunto de Funes: Gerenciadores ............................................................. 83 Figura 25 - Diferena de Nomenclatura entre as Atividades.............................................. 85 Figura 26 - Diferena de Nomenclatura entre os Artefatos ................................................ 86 Figura 27 - Adaptao dos elementos de mtodo ao processo. ........................................ 88 Figura 28 - Adaptao do contedo dos elementos de mtodo ao processo (Atividade). . 90

Figura 29 - Tela inicial do processo RUP + PMBOK.......................................................... 92 Figura 30 - Integrao RUP + PMBOK - Funo Coordenador de Projeto ........................ 93 Figura 31 - Integrao RUP + PMBOK - Funo Analista de Sistemas............................. 93 Figura 32 - Integrao RUP + PMBOK - Atividade: AGP- Desenvolver a EAP ................. 94 Figura 33 - Integrao RUP + PMBOK - Atividade: AGP- Captar Glossrio ...................... 95 Figura 34 - Integrao RUP + PMBOK - Produto de Trabalho: PM-EAP........................... 96 Figura 35 - Integrao RUP + PMBOK - Produto de Trabalho: Declarao Preliminar do Escopo do Projeto ...................................................................................................... 97 Figura 36 - Fluxo PDS - PMBOK + RUP Fase Iniciao Pgina 1.................................. 99 Figura 37 - Fluxo PDS - PMBOK + RUP Fase Iniciao Pgina 2................................ 100 Figura 38 - Fluxo PDS - PMBOK + RUP Fase Elaborao Pgina 3............................ 101 Figura 39 Fluxo PDS - PMBOK + RUP Fase Elaborao Pgina 4 .............................. 101 Figura 40 - Fluxo PDS - PMBOK + RUP Fase Construo Pgina 5 ........................... 102 Figura 41 - Fluxo PDS - PMBOK + RUP Fase Construo Pgina 6 ........................... 102 Figura 42 - Fluxo PDS - PMBOK + RUP Fase Transio Pgina 7 .............................. 103 Figura 43 - Fluxo PDS - PMBOK + RUP Fase Transio Pgina 8 .............................. 104 Figura 44 - Integrao RUP + PMBOK - Funo Coordenador de Projeto ...................... 118 Figura 45 - Integrao RUP + PMBOK - Funo Analista de Sistemas........................... 118 Figura 46 - Integrao RUP + PMBOK - Funo Gerenciador de Configurao ............. 119 Figura 47 - Integrao RUP + PMBOK - Funo Gerenciador de Controle de Mudanas .................................................................................................................................. 119 Figura 48 - Integrao RUP + PMBOK - Funo Especificador de Requisitos ................ 119 Figura 49 - Integrao RUP + PMBOK - Funo Coordenador de Reviso .................... 119 Figura 50 - Integrao RUP + PMBOK - Funo Revisor de Gerenciamento ................. 120 Figura 51 - Integrao RUP + PMBOK - Funo Todas as Funes............................... 120 Figura 52 - Integrao RUP + PMBOK - Atividade: AGI - Desenvolver Declarao Preliminar do Escopo do Projeto .............................................................................. 121 Figura 53 - Integrao RUP + PMBOK - Atividade: AGI Desenvolver Termo de Abertura do Projeto ................................................................................................................. 122 Figura 54 - Integrao RUP + PMBOK - Atividade: AGI - Iniciar Plano de Gerenciamento do Projeto ................................................................................................................. 123 Figura 55 - Integrao RUP + PMBOK - Atividade: AGP- Desenvolver a EAP ............... 124 Figura 56 - Integrao RUP + PMBOK - Atividade: AGP- Captar Glossrio .................... 125 Figura 57 - Integrao RUP + PMBOK - Atividade: AGP- Escrever Plano de Gerenciamento e Configurao CM ......................................................................... 126 Figura 58 - Integrao RUP + PMBOK - Atividade: AGP- Desenvolver Plano do Gerenciamento do Escopo do Projeto ...................................................................... 127 Figura 59 - Integrao RUP + PMBOK - Produto de Trabalho: PM - EAP....................... 128

Figura 60 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Declarao Preliminar do Escopo do Projeto ............................................................................................... 129 Figura 61 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Dicionrio da EAP . 130 Figura 62 - Integrao RUP + PMBOK - Produto de Trabalho: PM Linha de Base do Escopo...................................................................................................................... 131 Figura 63 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Mudanas Solicitadas .................................................................................................................................. 131 Figura 64 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Plano de Gerenciamento do Projeto ........................................................................................ 132 Figura 65 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Termo de Abertura do Projeto ...................................................................................................................... 133 Figura 66 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Plano de Gerenciamento de Escopo do Projeto ...................................................................... 134 Figura 67 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Requisitos do Gerenciamento de Configurao e Controle ............................................................ 135 Figura 68 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Declarao do Escopo do Projeto ................................................................................................................. 136

LISTA DE TABELAS

Tabela 1 - Comparao PMBOK e RUP: Principais Caractersticas. Adaptado de [CHA04]. .................................................................................................................................... 64 Tabela 2 - Metamodelo PMBOK e RUP. Adaptado de [CHA04]. ....................................... 65 Tabela 3 - Mapeamento PMBOK e RUP em relao: reas de Conhecimento e Disciplinas. Adaptado de [CHA04]. ............................................................................. 67 Tabela 4 - Relao entre processos PMBOK e atividades RUP. Adaptado de [CHA04]. .. 68 Tabela 5 - Descrio das Disciplinas envolvidas na integrao [RAT08]. ......................... 82 Tabela 6 - Relao do Conjunto de Funes e seus Papis e suas respectivas atribuies [RAT08]. ..................................................................................................................... 83 Tabela 7 - Descrio das Nomenclaturas das atividades criadas...................................... 85 Tabela 8 - Nveis de Adaptao disponveis no RUP [RAT08], [RMC08]. ......................... 86

LISTA DE SIGLAS

ANSI EAP MSF OPEN PDSP PMBOK PMI PRINCE2 RMC RUP SPIM UML XP

American National Standards Institute Estrutura Analtica do Projeto Microsoft Solutions Framework Object-oriented Process, Environment and Notation Processo de Desenvolvimento de Software do Projeto Project Management Body of Knowledge Project Management Institute Projects In Controlled Environments Rational Method Composer Rational Unified Process Software Planning Integrated Model Unified Model Language Extremming Programming

SUMRIO

INTRODUO ........................................................................................................... 16 1.1 1.2 Motivao ............................................................................................................ 17 Questo de Pesquisa ................................................................................... 19 Objetivo Geral .............................................................................................. 19 Objetivos Especficos ................................................................................... 20 Objetivos ............................................................................................................. 19 1.1.1 1.2.1 1.2.2 1.3

Estrutura do Trabalho .......................................................................................... 20 Gerncia de Projetos ........................................................................................... 22 Surgimento Projetos ..................................................................................... 22 Projeto .......................................................................................................... 23 Gesto de Projetos ....................................................................................... 25 Problemas relacionados com a falta de gesto de projetos ......................... 26

FUNDAMENTAO TERICA ................................................................................. 22 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.2 2.3

Processo de desenvolvimento de software ......................................................... 27 Modelo de gesto de projetos e de processo de desenvolvimento de software .. 28 PMBOK Project Management Body of Knowledge .................................... 28 Ciclo de Vida e Organizao do Projeto................................................ 29 Grupos de Processos ............................................................................ 30 reas de Conhecimento da Gerncia do Projeto .................................. 32 Princpios e Melhores Prticas .............................................................. 35 Dimenso Esttica ................................................................................ 37 Dimenso Dinmica .............................................................................. 39 2.3.1.1 2.3.1.2 2.3.1.3

2.3.1

2.3.2

RUP Rational Unified Process................................................................... 34

2.3.2.1 2.3.2.2 2.3.2.3 2.4 2.4.1

Gerenciamento de Escopo .................................................................................. 41 Definio ...................................................................................................... 41

2.4.2 Falhas no Gerenciamento de Projetos e a relao com a Gerncia de Escopo 43 2.4.3 Escopo do Produto e Escopo do Projeto ...................................................... 44 Escopo do Produto ................................................................................ 44 Escopo do Projeto ................................................................................. 45 Planejamento do Escopo ...................................................................... 46 2.4.3.1 2.4.3.2 2.4.4 2.4.4.1

Detalhamento dos Processos Especficos do Gerenciamento de Escopo ... 45

2.4.4.2 2.4.4.3 2.4.4.4 2.4.4.5 2.5 3

Definio do Escopo ............................................................................. 47 Criao da EAP ..................................................................................... 48 Verificao do Escopo........................................................................... 50 Controle do Escopo ............................................................................... 51

Consideraes sobre o captulo .......................................................................... 53

TRABALHOS RELACIONADOS ............................................................................... 54 3.1 Gerenciamento de Projetos de Software Um mapeamento entre RUP e o PMBOK [CHA04] ........................................................................................................... 54 3.2 Padres, Tendncias, e o Rational Unified Process, Parte I: Integrando-se RUP e o PMBOK [COT04] ......................................................................................................... 55 3.3 O gerenciamento de projetos com RUP em reviso [TEM08] ............................. 57 3.4 Um modelo de integrao entre a gerncia de projetos e o processo de desenvolvimento de software [ROS08] .......................................................................... 58 3.5 Consideraes sobre o captulo .......................................................................... 60 Tipo de Pesquisa ................................................................................................. 61 Desenho da Pesquisa ......................................................................................... 61 Consideraes sobre o captulo .......................................................................... 63 Comparaes e Anlises de compatibilidade RUP/PMBOK ............................... 64 Mapeamentos RUP/PMBOK ............................................................................... 66 Consideraes sobre o captulo .......................................................................... 69 Descrio principal do Rational Method Composer ............................................. 71 Viso da configurao de mtodo da integrao................................................. 74 Viso da autoria de contedo do mtodo ............................................................ 76 Consideraes sobre o captulo .......................................................................... 79 Premissas para a integrao ............................................................................... 80 Elementos dos esforos direcionados ................................................................. 81 Disciplinas Envolvidas .................................................................................. 82 Papis envolvidos ........................................................................................ 82 Atividades envolvidas ................................................................................... 84 Artefatos envolvidos ..................................................................................... 85

metodologia de pesquisa ......................................................................................... 61 4.1 4.2 4.3

Mapeamento entre PROCESSO RUP E O MODELO PMBOK ................................ 64 5.1 5.2 5.3

Ferramenta para publicao e personalizao de processos - RMC ................... 71 6.1 6.2 6.3 6.4

Processso rup + pmbok de gerncia de escopo .................................................. 80 7.1 7.2

7.2.1 7.2.2 7.2.3 7.2.4 7.3 7.4

Nveis de adaptao ............................................................................................ 86 Adaptar o processo ............................................................................................. 87 Desenvolver os elementos de mtodo ......................................................... 87

7.4.1

7.4.2 7.4.3 7.5 7.5.1 7.5.2 7.5.3 7.6 8 8.1 8.2 9 9.1 9.2

Configurar o contedo dos elementos do mtodo ........................................ 88 Tornar o processo disponvel ....................................................................... 91 Interface Funes Integrao RUP + PMBOK .......................................... 92 Interface Atividade Integrao RUP + PMBOK ......................................... 94 Interface Produto de Trabalho Integrao RUP + PMBOK ....................... 95

Visualizao da publicao do processo integrado RUP + PMBOK ................... 91

Consideraes sobre o captulo .......................................................................... 97 Fluxo de processo de desenvolvimento de software ........................................... 99 Consideraes sobre o captulo ........................................................................ 104 Resultados da pesquisa .................................................................................... 106 Contribuies..................................................................................................... 107 Terica ....................................................................................................... 107 Prtica ........................................................................................................ 107

Exemplo de uso ........................................................................................................ 99

Consideraes finais.............................................................................................. 105

9.2.1 9.2.2 9.3 9.4

Limitaes da pesquisa ..................................................................................... 108 Estudos futuros.................................................................................................. 108

APNDICE A Demonstrao da Integrao dos Modelos ....................................... 114 APNDICE B publicao completa da integrao ................................................... 118 ANEXO A Solicitao de alterao de escopo ........................................................ 137

16

INTRODUO

A globalizao, as tecnologias emergentes, a reestruturao das organizaes e a busca pela eficincia na gesto empresarial tornam o gerenciamento de projetos assunto fundamental para a continuidade e sobrevivncia das organizaes [Sot07]. Normalmente o projeto executado por pessoas que vo consumir horas, esto limitadas por prazo, custo e escopo. Como em qualquer empreendimento, as atividades precisam ser planejadas, programadas e, durante a execuo, precisam ser controladas [Mar02]. Um projeto bem-sucedido quando atende (ou excede) s expectativas dos stackholders, que so aquelas pessoas que investiram e participam do projeto. So as pessoas que tem algo a ganhar ou a perder, como consequncia do projeto [Hel03]. O incremento no volume de projetos, aliado necessidade de resultados mais rpidos, com maior qualidade e menor custo, somente reforam a importncia do bom gerenciamento do escopo em projetos, como forma de garantir que todo o trabalho necessrio para a concluso bem-sucedida de um projeto esteja descrito e aprovado para que possa ser controlado e as necessidades dos clientes atendidas [Sot07]. Atualmente, os projetos so aplicados nas mais diversas reas como: construo, engenharia, indstria, setor automotivo, finanas, militar, marketing e tecnologia da informao. Segundo relatrio benchmarking da Integrao Nacional [INT07] relativo ao gerenciamento de projetos no Brasil em 2007, a tecnologia da informao a rea que mais est utilizando metodologias de gerenciamento de projetos no cenrio nacional representando uma fatia de 28% do total dos setores pesquisados. Grande parte destas organizaes de tecnologia da informao tem como atuao o desenvolvimento de software definindo modelos para o gerenciamento de projetos. Algumas das caractersticas mais desejadas destes modelos incluem a habilidade de capturar as melhores prticas de desenvolvimento de software, um bom nvel de flexibilidade (a fim de lidar com diferentes tipos de projetos), bem como um bom apoio gesto . A falta de metodologias especficas para a gerncia de projetos de software, o aumento da complexidade e do nmero de projetos nas organizaes contribuem para o aumento dos problemas relacionados a gesto de projetos [Pre01], [Ker06].

17

Na maioria das vezes o processo de desenvolvimento est baseado em modelos e guias voltados para a gerncia de projetos como o Project Management Body of Knowledge Guide (PMBOK) [Pmi04] ou Projects IN Controlled Environments (PRINCE2) [Ogc05], [HAR05] e [SIE04], que no tratam especificamente de processos de desenvolvimento de software. H casos em que a produo utilizando processos de desenvolvimento de software, atende parcialmente as prticas relacionadas gerncia de projetos como o Rational Unified Process (RUP) [Kru03] ou Object-oriented Process, Environment and Notation (OPEN) [Gra97]. O desenvolvimento de produtos de software requer o planejamento e a execuo de atividades definidas de acordo com o escopo do projeto, onde necessrio lidar tanto com assuntos gerenciais quanto tcnicos. Entretanto, a maioria dos modelos ou guias voltados para a gerncia de projetos no se dirigem especificamente a processos de desenvolvimento de software. Alm disso, os processos de desenvolvimento de software, por sua vez, geralmente fornecem apenas um conjunto de prticas que atendem a determinadas atividades e fluxos relacionados gerncia de projetos . Nesta pesquisa apresentamos uma proposta de integrao entre a gerncia de projeto e o processo de desenvolvimento de software na rea de gerenciamento de escopo. Utilizamos o PMBOK como um modelo que apresenta uma viso gerencial no desenvolvimento de projetos e o RUP que oferece uma perspectiva de produo no processo de desenvolvimento de software. Para a integrao dos mesmos desenvolveuse estudos de mapeamento e compatibilidade em ambos, a fim de que as atividades gerenciais pudessem ser aplicadas ao processo de desenvolvimento de software sem interferir nas suas principais caractersticas tcnicas. Para verificar a viabilidade da proposta utilizamos a ferramenta Rational Method Composer (RMC), permitindo acesso a biblioteca do RUP que possui todo plugin de mtodo e processo, no qual pode-se incorporar as melhores prticas de gerenciamento de projetos do modelo PMBOK na rea de gerenciamento de escopo ao processo de desenvolvimento de software.

1.1

Motivao Em percebe-se que o gerenciamento de projetos em geral e especificamente

na rea de software, apresenta um alto ndice de falhas, ou seja, os projetos no so concludos ou tem seus prazos e custos extrapolados. O desenvolvimento de produtos de

18

software requer o planejamento e a execuo de atividades definidas de acordo com o escopo do projeto, onde necessrio lidar tanto com assuntos gerenciais quanto tcnicos. E complementa ainda que, a fim de se obter um processo mais detalhado para o gerenciamento de projetos de software, necessrio aplicar os conhecimentos de gesto de projetos aos processos de desenvolvimento do software. No entanto o que se v cada vez mais surgir no mercado empresas de desenvolvimento de software, de todos os tamanhos e com sua especificidade delimitada, muitas utilizam seus processos individuais durante o desenvolvimento [SIL07]. Muitas empresas no investem na padronizao de suas atividades, o que acaba deixando cada integrante da equipe de desenvolvimento livre para implantar o seu prprio mtodo de desenvolvimento. A no utilizao de uma padronizao, tanto em cdigo quanto em processo e documentao, acaba por transformar um sistema num conjunto de mdulos, sendo que cada mdulo s entendido pelo seu prprio autor. Alm disso, a no padronizao no processo de desenvolvimento de software compromete aspectos relacionados qualidade e confiabilidade do projeto [PRI03]. Desta forma, muitos pesquisadores trabalham na investigao dos fatores de sucesso dos projetos, tais como a definio de produto, qualidade de execuo e tcnicas de gerncia de projetos [PIN87]. Mesmo existindo diversos artigos na literatura que enfatizam a importncia do uso de processos de softwares bem definidos nas organizaes, parece no haver estudos suficientes para suprir a carncia no quesito de gerncia de projetos destes processos . As empresas na rea de tecnologia percebem a necessidade de implantar projetos que consigam alcanar os resultados esperados, dentro do prazo, custo e escopo ao qual foram planejados respeitando assim as restries do projeto e trabalhando para diminuir o ndice de fracasso dos mesmos, consequentemente de metodologias de gerenciamento de aumentando o ndice de satisfao dos clientes. Entre as medidas tomadas por estas organizaes, a principal foi a utilizao projetos como [Pmi04], [Ker06], [HAR05] e [SIE04]. Percebe-se que o uso das boas prticas contribuiu de forma satisfatria para melhorar os ndices de sucesso de projetos [IKE06], [STA94] e [STA04], mas ainda h muito a se aperfeioar nesta rea.

19

Diante disto, destaca-se a iniciativa de vrias metodologias em incluir disciplinas, responsabilidades, mtodos e atividades relacionadas ao gerenciamento de projetos na rea de software. Entre elas citamos o RUP, bem sucedido na criao e manuteno de sistemas de software [Kru03]. Com estas iniciativas surgiu a necessidade de mapear e integrar os padres existentes, entre eles o RUP e o PMBOK [CHA04], [COT04] , [TEM08], [CAL07] e . Dessa forma, com estes esforos para criao de processos de gerenciamento sucesso dos projetos nas organizaes. Vrias pesquisas esto sendo realizadas quanto a unificao de padres de gerenciamento de projetos e processos de desenvolvimento de software [CHA04], [COT04] , [TEM08], [CAL07] e . Com o objetivo final de se aplicar estes processos em qualquer tipo de organizao de desenvolvimento de software. Faz-se necessrio ainda especificar um processo que fornea a integrao dos conhecimentos de gesto de projetos na rea de gerenciamento de escopo aos processos de desenvolvimento do software, servindo de apoio ao gerente de projetos em suas atividades. de projetos de software, h uma contribuio para a probabilidade de um aumento no

1.1.1 Questo de Pesquisa A questo de pesquisa abordada neste estudo foi a seguinte: Como gerenciar escopo de projetos de software utilizando os padres RUP e PMBOK em um mesmo processo de forma integrada?

1.2

Objetivos Definida a questo de pesquisa, definiu-se o objetivo geral e os objetivos

especficos deste trabalho, os quais a seguir so apresentados.

1.2.1 Objetivo Geral O estudo realizado neste trabalho tem como objetivo geral propor um processo de gerenciamento de escopo baseado no RUP para projetos de softwares, inserindo contribuies da rea de conhecimento do PMBOK de gerncia de escopo ao contedo das disciplinas do RUP. Contribuindo para a integrao das melhores prticas de gesto

20

ao processo de produo e auxiliando os gerentes de projetos durante o planejamento de projetos de software.

1.2.2 Objetivos Especficos Como objetivos especficos tm-se: Aprofundar o estudo terico entre a gerncia de projetos e os processos de desenvolvimento de software e o gerenciamento de escopo de projetos. Identificar caractersticas e compatibilidades entre o modelo de gerncia de escopo PMBOK e o processo de desenvolvimento de software RUP, mapeando estas caractersticas entre modelo e processo. Integrar o modelo de gerncia de escopo PMBOK na rea de gerenciamento de escopo nas disciplinas do processo de desenvolvimento de software RUP; Publicar a proposta de processo integrado utilizando o RMC; Apresentar um exemplo de uso com a proposta integrada.

1.3

Estrutura do Trabalho Este trabalho est dividido em trs partes: fundamentao terica, proposta de

integrao do processo RUP + PMBPOK na gerncia de escopo no desenvolvimento de software e um exemplo de uso do processo. O captulo 2 apresenta a fundamentao terica necessria para um bom entendimento do trabalho, onde so esclarecidos aspectos de gerncia de projetos, processos de desenvolvimento de software, gerenciamento de escopo em projetos, alm das caractersticas principais e fundamentais do modelo de gerenciamento de projetos PMBOK e o processo de desenvolvimento de software RUP. No captulo 3 esto apresentados alguns trabalhos encontrados na literatura que relacionam-se anlise da gesto de projetos nos processos de desenvolvimento de software, bem como a integrao destes, que de alguma forma contribuiram para esta proposta. J no captulo 4 ilustramos a metodologia de pesquisa adotada para a elaborao deste trabalho. No captulo 5 demonstramos o mapeamento entre o PMBOK e o RUP realizado atravs de um estudo de suas caractersticas e um anlise de suas compatibilidades. A

21

ferramenta de publicao e personalizao de processos utilizada para configurao e desenvolvimento do processo apresentada no captulo 6. Para ento no captulo 7 mostrarmos a integrao do processo, quais atividades e papis envolvidos, ilustrarmos como a integrao foi publicada utilizando o RMC. No captulo 8 demonstramos um exemplo de uso com a integrao proposta por este trabalho. E finalmente no captulo 9 so apresentadas as concluses, contribuies e os trabalhos futuros.

22

FUNDAMENTAO TERICA

Para se ter um bom entendimento da proposta de integrao que este trabalho apresenta necessria a compreenso dos fundamentos tericos e das metodologias bsicas nos quais a proposta esta embasada. Assim na seo sobre 2.1 apresentamos e gerncia conceitos de e caractersticas gerais projetos projetos.

Demonstramos uma pesquisa relacionada a problemas na gerncia de projetos, na seo 2.2 o conceito sobre processo de desenvolvimento de software, na seo 2.3 apresentamos o RUP e o PMBOK e finalmente na seo 2.4 gerenciamento de escopo de projetos.

2.1

Gerncia de Projetos Antes de estudar os conceitos de gerncia de projeto importante compreender o

conceito e o surgimento dos projetos.

2.1.1 Surgimento Projetos Muitos afirmam que os primeiros projetos podem ser considerados a construo das Pirmides do Egito, a Muralha da China, a Torre de Babel, entre outras grandes construes que so to conhecidas. Para o gerenciamento de projeto moderno, considera-se o incio de tudo com o projeto Manhattan1, com isto podemos afirmar que nos primeiros dias o gerenciamento de projetos foi utilizado para projetos grandes, de complexa pesquisa e desenvolvimento. Depois disto a construo de refinarias, represas e grandes complexos, foram o palco para o gerenciamento de projetos. Com esta divulgao companhias do setor privado de construo perceberam que alm de grandes construes o gerenciamento de projeto poderia ser utilizado por exemplo em centros menores, como condomnios residenciais.

1 foi um esforo durante a Segunda Guerra Mundial para desenvolver as primeiras armas nucleares pelos Estados Unidos da Amrica com o apoio do Reino Unido e do Canad.

23

Alm disto, com o uso de gerenciamento de projetos vrias organizaes tambm encontraram uma oportunidade de negcio para seus empreendimentos, utilizando ento este modelo para o planejamento e execuo de sapatos a turbinas de avio. Passados alguns anos notou-se o crescimento e utilizao de gerenciamento de projetos por parte de empresas prestadoras de servios de uma forma rpida, hoje encontramos as tcnicas de gerenciamento de projetos para uma festa de casamento ou uma cerimnia de colao de grau na universidade. Importante ressaltar o uso frequente de gerenciamento de projetos para o desenvolvimento de softwares e conjunto de aplicaes das mais diversas reas da tecnologia atual.

2.1.2 Projeto O ponto de partida para compreenso de gerncia de projetos o entendimento do conceito de projeto. Conforme [Sch02], um projeto um empreendimento temporrio com o objetivo de produzir um nico produto ou servio. Geralmente direcionado a alcanar um resultado especfico e envolve a execuo coordenada de atividades inter-relacionadas. De acordo com a definio de [Din05], um projeto um esforo temporrio realizado para criar um produto ou servio nico, diferente de alguma maneira, de todos os outros produtos e servios, com incio e fim definidos, que utiliza recursos, dirigido por pessoas e obedece a parmetros de custo, tempo e qualidade. Projeto um empreendimento no repetitivo, caracterizado por uma sequncia clara e lgica de eventos, com incio, meio e fim, que se destina a atingir um objetivo claro e definido. Por usa vez, sendo conduzido por pessoas dentro de parmetros predefinidos de tempo, custo, recursos envolvidos e qualidade, como afirma [VAR02]. Um projeto pode ser definido como um empreendimento nico, com incio e fim determinados, que utiliza recursos e conduzido por pessoas, visando atingir objetivos predefinidos [Pmi04]. Desta forma o [Pmi04] define o projeto com as seguintes caractersticas: - Temporrio: Significa que todos os projetos possuem um incio e um final definidos. O final alcanado quando os objetivos do projeto tiverem sido atingidos.

24

Quando se tornar claro que os objetivos do projeto no sero ou no podero ser atingidos, ou quando no existir mais a necessidade do projeto e ele for encerrado. Temporrio no significa necessariamente de curta durao sendo assim muitos projetos duram vrios anos. Em todos os casos, no entanto, a durao de um projeto finita. Projetos no so esforos contnuos. Alm disso, geralmente o termo temporrio no se aplica ao produto, servio ou resultado criado pelo projeto. A maioria dos projetos realizado, para criar um resultado duradouro. Por exemplo, um projeto para erguer um monumento nacional criar um resultado que deve durar sculos. Os projetos tambm podem com freqncia ter impactos sociais, econmicos e ambientais, intencionais ou no, com durao muito mais longa que a dos prprios projetos. A natureza temporria dos projetos pode tambm ser aplicada a outros aspectos do esforo: A oportunidade ou janela do mercado geralmente temporria: alguns projetos tm um prazo limitado durante o qual seu produto ou servio deve ser gerado; A equipe do projeto, como uma unidade de trabalho, raramente sobrevive ao projeto: uma equipe criada com o nico objetivo de realizar o projeto realizar esse projeto e, em seguida, ser desfeita e seus membros sero realocados quando o projeto for concludo. - Produtos, servios ou resultados exclusivos: Um projeto cria entregas exclusivas, que so produtos, servios ou resultados. Os projetos podem criar: Um produto ou objeto produzido, quantificvel e que pode ser um item final ou um item componente; Uma capacidade de realizar um servio, como funes de negcios que do suporte produo ou distribuio; Um resultado, como resultados finais ou documentos. Por exemplo, um projeto de pesquisa desenvolve um conhecimento que pode ser usado para determinar se uma tendncia est presente ou no, se um novo processo ir beneficiar a sociedade. A singularidade uma caracterstica importante das entregas do projeto. Por exemplo, muitos milhares de prdios de escritrios foram construdos, mas cada prdio em particular nico, pois tem proprietrio diferente, projeto diferente, local diferente,

25

construtora diferente, etc. A presena de elementos repetitivos no muda a singularidade fundamental do trabalho do projeto. - Elaborao progressiva: uma caracterstica de projetos que integra os conceitos de temporrio e exclusivo. Elaborao progressiva significa desenvolver em etapas e continuar por incrementos. Por exemplo, o escopo do projeto ser descrito de maneira geral no incio do projeto e se tornar mais explcito e detalhado conforme a equipe do projeto desenvolver um entendimento mais completo dos objetivos e das entregas. A elaborao progressiva no deve ser confundida com aumento do escopo. A elaborao progressiva das especificaes de um projeto deve ser

cuidadosamente coordenada com a definio adequada do escopo do projeto, particularmente se o projeto for realizado sob contrato. Quando adequadamente definido, o escopo do projeto o trabalho a ser feito deve ser controlado conforme as especificaes do projeto e do produto so progressivamente elaboradas.

2.1.3 Gesto de Projetos A gerncia de projetos responsvel pelo controle da realizao dos objetivos do projeto atravs da aplicao de um conjunto de tcnicas e ferramentas [Sch02]. Conforme o [Pmi04], o gerenciamento de projetos a aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos realizado atravs da aplicao e da integrao dos seguintes processos de gerenciamento de projetos: iniciao, planejamento, execuo, monitoramento e controle, e encerramento. O gerente de projetos a pessoa responsvel pela realizao dos objetivos do projeto. Gerenciar um projeto inclui: Identificao das necessidades; Estabelecimento de objetivos claros e alcanveis; Balanceamento das demandas conflitantes de qualidade, escopo, tempo e custo; Adaptao das especificaes, dos planos e da abordagem s diferentes preocupaes e expectativas das diversas partes interessadas.

26

Os gerentes de projetos frequentemente falam da restrio tripla, escopo, tempo e custo do projeto, no gerenciamento de necessidades conflitantes do projeto. A qualidade do projeto afetada pelo balanceamento desses trs fatores. Projetos de alta qualidade entregam o produto, servio ou resultado solicitado dentro do escopo, no prazo e dentro do oramento. A relao entre esses fatores ocorre de tal forma que se algum dos trs fatores mudar, pelo menos um outro, provavelmente ser afetado. Os gerentes de projetos tambm gerenciam projetos em resposta a incertezas. Um risco do projeto um evento ou condio incerta que, se ocorrer ter um efeito positivo ou negativo em pelo menos um dos objetivos do projeto.

2.1.4 Problemas relacionados com a falta de gesto de projetos Conforme , citando [Pre01], os principais problemas da gerncia de projetos esto relacionados falta de processos adequados e padronizados de gesto. Sendo que os principais motivos do insucesso nos projetos esto relacionados falta de procedimentos, metodologias e padres de gesto. Em [IKE06], feito um comparativo utilizando-se como base os relatrios de Chaos, [STA94] e [STA04], que uma pesquisa significativa, possuindo estatsticas que traduzem um perodo de 10 anos (entre 1994 e 2004) no gerenciamento de projetos aplicados na rea da Tecnologia da Informao, perodo em que houve uma ascenso e consolidao da gesto de projetos como uma disciplina formal. Observamos na Figura 1 [IKE06], que o percentual das taxas de projetos executados com sucesso praticamente dobraram, passando de 16,2% em 1994 para 29% em 2004, e o nmero de projetos que falharam ou no foram completados diminuram de 31,1% em 1994 para 18% em 2004. Os projetos considerados arriscados (projetos que geralmente ultrapassam a estimativa de custo, prazo e escopo, causando enorme prejuzos aos clientes e organizaes envolvidas) permanece na taxa em torno de 53%.

Figura 1 - Relatrio de CHAOS publicado pelo The Standish Group International [IKE06].

27

Verifica-se que utilizar processos para gerenciamento de projetos pode, seguramente, ser ponto fundamental para o sucesso do projeto, mas ainda est longe de ser a soluo de todos os problemas. As principais razes para ainda termos um nmero expressivo de projetos com oramento, tempo e escopo excedidos, podem ser elencados como: A mudana ou especificao incompleta de requisitos; A falta de recursos humanos ou financeiros; As expectativas irrealistas dos stakeholders; A falta de comunicao dos membros da equipe, que os leva a trabalhar de forma no integrada; Ausncia de processos bem definidos na organizao. As organizaes devem continuar investindo em metodologias de gerenciamento de projetos e em modalidades de qualidade de processo para que o nmero de projetos bem sucedidos seja aceitvel, para que futuramente possamos alcanar um nvel de excelncia. Segundo [Sot07a], para que a evoluo dos modelos possa reduzir a quantidade de falhas no desenvolvimento de software importante o investimento em mtodos de gerenciamento mais amplos e na profissionalizao das organizaes. Os problemas que afetam o desenvolvimento de software podem ser

caracterizados a partir de uma srie de perspectivas diferentes. Entre os principais problemas, pode-se citar a especificao de requisitos, capacitao de pessoal, qualidade e teste de software, planejamento e gerncia de projeto, cumprimento dos prazos, trabalho em equipe, e muitos outros, conforme [GIR05]. 2.2 Processo de desenvolvimento de software De acordo com [Som04], um processo de desenvolvimento de software pode ser denido como um conjunto de atividades, mtodos, prticas e transformaes que as pessoas empregam para desenvolver e manter o software e os produtos associados (por exemplo, planos de projeto, documentos de projeto, design, cdigo, casos de teste, manual do usurio). O processo de desenvolvimento de software, segundo [Pre01], o conjunto de atividades parcialmente ordenadas que um projeto deve seguir para desempenhar alguma

28

tarefa. Esta tarefa deve ter como objetivo atingir uma determinada meta e geralmente est associada ao desenvolvimento de um ou mais produtos. Projetos de software podem envolver um pequeno grupo ou centenas de pessoas. Sua durao pode variar de algumas semanas a vrios anos. Podem envolver um nico setor da organizao, toda a organizao, ou at ultrapassar os limites da organizao, abrangendo todas as entidades externas que participam nos processos a serem automatizados e contemplados no sistema. Por estes motivos os processos de desenvolvimento de software podem apresentar grande complexidade, e desta forma, possibilitar diversas alternativas de execuo de suas atividades, e por isso esto ganhando importncia e fazendo parte das atividades estratgicas das organizaes. A importncia da utilizao de um processo de desenvolvimento de software padro deve-se ao fato de que este atua como um guia para a execuo de todos os projetos dentro de uma organizao. Assim, muitos processos ou guias tais como RUP, SCRUM, Extreme Programming (XP), Microsoft Solutions Framework (MSF) e OPEN esto sendo utilizados como base no desenvolvimento de processos de desenvolvimento de software padro nas organizaes. Mesmo assim, os processos de desenvolvimento de software identificando o importncia das atividades relacionadas gesto, no tratam de forma adequada os aspectos relacionados gerncia de projeto.

2.3

Modelo de gesto de projetos e de processo de desenvolvimento de software Nesta seo apresenta-se uma viso geral do PMBOK e do processo de

desenvolvimento de software RUP. Destacando caractersticas e conceitos inerentes a cada um, j que ambos so os objetos de estudo para a proposta de integrao que este documento prope. 2.3.1 PMBOK Project Management Body of Knowledge O PMBOK conjunto de conhecimentos em gerenciamento de projetos , publicado pelo Project Management Institute (PMI), tem-se consolidado como a principal referncia para a gesto de projetos em nvel mundial. Nos Estados Unidos reconhecido pelo American National Standards Institute (ANSI) como padro para gesto de projetos desde 1999.

29

O objetivo principal do PMBOK identificar e descrever os conhecimentos e prticas normalmente aceitos sobre a gesto de projetos, bem como estabelecer um vocabulrio comum para essa rea. Normalmente aceitos, significa que h consenso sobre o valor e a utilidade das prticas e dos conhecimentos descritos. Conforme o [Pmi04], o principal objetivo do PMBOK identificar um subconjunto dos conhecimentos sobre gerncia de projetos que seja reconhecido, genericamente, como sendo uma coleo de boas prticas. O PMBOK, porm, no um processo em seu sentido estrito, pois no determina quais so as aes e nem indica como estas devem ser executadas para o correto desenvolvimento de um projeto. 2.3.1.1 Ciclo de Vida e Organizao do Projeto A organizao ou os gerentes de projetos podem dividir projetos em fases para oferecer melhor controle gerencial com ligaes adequadas com as operaes em andamento da organizao executora. Coletivamente, essas fases so conhecidas como o ciclo de vida do projeto. Muitas organizaes identificam um conjunto especfico de ciclos de vida para serem usados em todos os seus projetos. O ciclo de vida do projeto define as fases que conectam o incio de um projeto ao seu final. A transio de uma fase para a outra dentro do ciclo de vida de um projeto em geral envolve e normalmente definida por alguma forma de transferncia tcnica ou entrega. As entregas de uma fase geralmente so revisadas, para garantir que estejam completas e exatas, e aprovadas antes que o trabalho seja iniciado na prxima fase. Os ciclos de vida do projeto geralmente definem: Que trabalho tcnico deve ser realizado em cada fase; Quando as entregas devem ser geradas em cada fase e como cada entrega revisada, verificada e validada; Quem est envolvido em cada fase; Como controlar e aprovar cada fase. Embora muitos ciclos de vida do projeto possuam nomes de fases semelhantes com entregas semelhantes, poucos ciclos de vida so idnticos. Alguns podem ter quatro ou cinco fases, mas outros podem ter nove ou mais. O trmino e a aprovao de um ou mais produtos caracteriza uma fase do projeto. Chamamos genericamente de produto o resultado mensurvel e verificvel do trabalho, como uma especificao, um relatrio de estudo de viabilidade, um documento de projeto

30

detalhado ou um prottipo. Alguns produtos podem corresponder ao processo de gerenciamento de projetos, enquanto outros so os produtos finais ou componentes dos produtos finais para os quais o projeto foi concebido. Os produtos e, portanto, as fases fazem parte de um processo geralmente sequencial criado para garantir o controle adequado do projeto e conseguir o produto ou servio desejado, que o objetivo do projeto, conforme a Figura 2. Uma fase do projeto em geral concluda com uma reviso do trabalho realizado e dos produtos para definir a aceitao, se ainda necessrio algum trabalho adicional ou se a fase deve ser considerada encerrada.

Figura 2 - Sequncia tpica de fases no ciclo de vida de um projeto [Pmi04].

2.3.1.2 Grupos de Processos O gerenciamento de projetos a aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim de atender a seus requisitos. O gerenciamento de projetos realizado atravs de processos, usando conhecimento, habilidades, ferramentas e tcnicas do gerenciamento de projetos que recebem entradas e geram sadas [Pmi04]. Esta seo identifica e descreve os cinco grupos de processos de gerenciamento de projetos necessrios para qualquer projeto. Esses cinco grupos de processos possuem dependncias claras e so executados na mesma sequncia em todos os projetos, conforme Figura 3. Os cinco grupos de processos so: Grupo de processos de iniciao: Define e autoriza o projeto ou uma fase do projeto.

31

Grupo de processos de planejamento: Define e refina os objetivos e planeja a ao necessria para alcanar os objetivos e o escopo para os quais o projeto foi realizado. Grupo de processos de execuo: Integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto para o projeto. Grupo de processos de monitoramento e controle: Mede e monitora regularmente o progresso para identificar variaes em relao ao plano de gerenciamento do projeto, de forma que possam ser tomadas aes corretivas quando necessrio para atender aos objetivos do projeto. Grupo de processos de encerramento: Formaliza a aceitao do produto, servio ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado.

Figura 3 - Grupos de Processos PMBOK [Pmi04].

Os grupos de processos de gerenciamento de projetos esto ligados pelos objetivos que produzem. Em geral, as sadas de um processo se tornam entradas para outro processo ou so entregas do projeto. Alm disso, os grupos de processos raramente so eventos distintos ou nicos. Eles so atividades sobrepostas que ocorrem em diversos nveis de intensidade durante todo o projeto. A Figura 4 ilustra como os grupos de processos interagem e o nvel de sobreposio em momentos diferentes dentro de um projeto. Se o projeto estiver dividido em fases, os grupos de processos iro interagir dentro de uma fase do projeto e tambm podero atravessar vrias fases dele.

32

Figura 4 - Interao de grupos de processos em um projeto [Pmi04]. 2.3.1.3 reas de Conhecimento da Gerncia do Projeto As reas de conhecimento em gerenciamento de projetos podem ser encontradas na Figura 5, totalizando um nmero de 9 diferentes reas de conhecimento, logo abaixo podemos identificar estas reas seguidas de uma breve descrio das atividades que a compem.

Figura 5 - reas de Conhecimento no Gerenciamento de Projetos.

33

Gerenciamento de integrao do projeto: Descreve os processos e as atividades que integram os diversos elementos do gerenciamento de projetos, que so identificados, definidos, combinados, unificados e coordenados dentro dos grupos de processos de gerenciamento de projetos. Gerenciamento do escopo do projeto: Descreve os processos envolvidos na verificao de que o projeto inclui todo o trabalho necessrio, e apenas o trabalho necessrio, para que seja concludo com sucesso. Gerenciamento de tempo do projeto: Descreve os processos relativos ao trmino do projeto no prazo correto. Gerenciamento de custos do projeto: Descreve os processos envolvidos em planejamento, estimativa, oramentao e controle de custos, de modo que o projeto termine dentro do oramento aprovado. Gerenciamento da qualidade do projeto: Descreve os processos envolvidos na garantia de que o projeto ir satisfazer os objetivos para os quais foi realizado. Gerenciamento de recursos humanos do projeto: Descreve os processos que organizam e gerenciam a equipe do projeto. Gerenciamento das comunicaes do projeto: Descreve os processos relativos gerao, coleta, disseminao, armazenamento e destinao final das informaes do projeto de forma oportuna e adequada. Gerenciamento de riscos do projeto: Descreve os processos relativos realizao do gerenciamento de riscos em um projeto. Gerenciamento de aquisies do projeto: Descreve os processos que compram ou adquirem produtos, servios ou resultados, alm dos processos de gerenciamento de contratos. Conforme [Pmi04], as principais competncias que os gerentes de projeto devem desenvolver para a execuo dos processos gerenciais so descritas nas reas de conhecimento do PMBOK. Estas 9 reas de conhecimento conforme a Figura 6 organizam os 44 processos de gerenciamento de projetos dentro dos grupos de processos que so: iniciao, planejamento, execuo, monitoramento e controle e encerramento.

34

Entre os grupos de processos e seus processos, as sadas dos processos esto relacionadas e possuem um impacto nos outros grupos de processos. Quando um projeto dividido em fases, os grupos de processos so normalmente repetidos dentro de cada fase, durante toda a vida do projeto, para conduzir o projeto de modo eficaz [Pmi04].

Figura 6 - Grupo de Processos e seus Processos [Sot07a].

2.3.2 RUP Rational Unified Process O Rational Unified Process (RUP) um processo de engenharia de software. Ele fornece uma abordagem disciplinada para assumir tarefas e responsabilidades dentro de uma organizao de desenvolvimento. Seu objetivo assegurar a produo de software de alta qualidade que satisfaa as necessidades de seus usurios finais dentro do prazo e oramento previsveis [Kru03].

35

2.3.2.1 Princpios e Melhores Prticas O RUP, por si s, um produto de software. desenvolvido e mantido pela IBM Rational Software, sendo modular e automatizado, e toda a sua metodologia apoiada por diversas ferramentas de desenvolvimento de software integradas. tambm uma estrutura de processo que pode ser adaptada e estendida para compor as necessidades de uma organizao que o esteja adotando. Capturando muitas das melhores prticas no desenvolvimento moderno de software de forma satisfatria para uma grande faixa de projetos e organizaes. Em particular, cobre as seis prticas descritas abaixo: Desenvolver software iterativamente: Dado o tempo gasto para desenvolver um software grande e sofisticado, no possvel definir o problema e construir o software em um nico passo. Os requerimentos iro frequentemente mudar no decorrer do desenvolvimento do projeto, devido a restries de arquitetura, necessidades do usurio ou a uma maior compreenso do problema original. Alteraes permitem ao projeto ser constantemente refinado, alm de assinalarem itens de alto risco do projeto como as tarefas de maior prioridade. De forma ideal, ao trmino de cada iterao haver uma verso executvel, o que ajuda a reduzir o risco de configurao do projeto, permitindo maior retorno do usurio e ajudando ao desenvolvedor manter-se focado. Gerenciar requisitos: O Gerenciamento de requisitos no RUP est concentrado em encontrar as necessidades do usurio final pela identificao e especificao do que ele necessita e identificando aquilo que deve ser mudado. Isto traz como benefcios: A correo dos requisitos gera a correo do produto, as necessidades dos usurios so encontradas; As caractersticas necessrias sero includas, reduzindo o custo de desenvolvimentos posteriores. Usar arquiteturas baseadas em componente: Arquitetura baseada em componentes cria um sistema que facilmente extensvel, intuitivo e de fcil compreenso e promove a reusabilidade de software. Um componente freqentemente se relaciona com um conjunto de objetos na programao orientada ao objeto. Arquitetura de software aumenta de importncia quando um sistema se torna maior e mais complexo. O RUP foca na produo da

36

arquitetura bsica nas primeiras iteraes. Esta arquitetura ento se torna um prottipo nos ciclos iniciais de desenvolvimento. A arquitetura desenvolve-se em cada iterao para se tornar a arquitetura final do sistema. O RUP tambm prope regras de projeto e restries para capturar regras de arquitetura. Pelo desenvolvimento iterativo possvel identificar gradualmente componentes os quais podem ento ser desenvolvidos, comprados ou reusados. Modelar visualmente o software: Abstraindo sua programao do seu cdigo e representando-a usando blocos de construo grfica constitui-se de uma forma efetiva de obter uma viso geral de uma soluo. Usando esta representao, recursos tcnicos podem determinar a melhor forma para implementar a dado conjunto de interdependncias lgicas. Isto tambm constri uma camada intermediria entre o processo de negcio e o cdigo necessrio atravs da tecnologia da informao. Um modelo neste contexto uma visualizao e ao mesmo tempo uma simplificao de um projeto complexo. O RUP especifica quais modelos so necessrios e porque. A Linguagem modelagem unificada (UML) pode ser usada para modelagem de casos de uso, diagrama de classes e outros objetos. O RUP tambm discute outras formas para construir estes modelos. Verificar continuamente a qualidade do software: O RUP ajuda no planejamento do controle da qualidade e cuida da sua construo em todo processo, envolvendo todos os membros da equipe. Nenhuma tarefa especificamente direcionada para a qualidade; o RUP assume que cada membro da equipe responsvel pela qualidade durante todo o processo. O processo foca na descoberta do nvel de qualidade esperado e prov testes nos processos para medir este nvel. Controlar mudanas no software: Em todos os projetos de software, mudanas so inevitveis. O RUP define mtodos para controlar, rastrear e monitorar estas mudanas. O RUP tambm define espaos de trabalho seguros (secure workspaces), garantindo que um sistema de engenharia de software no ser afetado por mudanas em outros sistemas. Este conceito bem aderente com arquiteturas de software baseados em componentes. Conforme a Figura 7, o RUP contm elementos em duas dimenses distintas: esttica e dinmica.

37

A primeira dimenso representa o aspecto esttico do processo: sua descrio em termos de componentes de processo, atividades, fluxos, artefatos e papis, so agrupados em workflows. A segunda dimenso representa o aspecto dinmico do processo como ordenado, e expresso em termos de ciclos, fases, iteraes e marcos.

Figura 7 - Viso geral da arquitetura do RUP [RAT08].

2.3.2.2 Dimenso Esttica Um processo descreve quem est fazendo o qu, como e quando. O RUP representado usando quatro elementos primrios de modelagem: papis (quem), atividades (como), artefatos (o qu) e fluxos (quando) [Kru03]. Papis: Um papel define o comportamento e as responsabilidades de um indivduo ou grupo de indivduos que trabalham juntos como uma equipe [Jac99] [Kru03]. O comportamento expresso em termos de atividades que o papel desempenha, e cada papel associado a um conjunto de atividades coesas. Neste sentido, coesas significa as atividades melhor executadas por uma pessoa. Normalmente so expressas as

38

responsabilidades de cada papel em relao a certos artefatos que o papel cria, modifica ou controla. Um papel desempenha um ou mais papis e dono de um conjunto de artefatos [Kru03]. Importante salientar que os papis no so indivduos; ao contrrio, eles descrevem como os indivduos deveriam se comportar no negcio e as responsabilidades de cada um. Atividades: Uma atividade uma unidade de trabalho que um indivduo naquele papel pode ser pedido a desempenhar, e isso produz um resultado significante no contexto do projeto [Kru03]. Toda atividade deve ser atribuda a um papel. A atividade tem um propsito claro, normalmente expresso em termos de criar ou modificar artefatos [RAT01]. A granulao de uma atividade geralmente de algumas horas a alguns dias. Normalmente envolve um papel e afeta um ou s um nmero pequeno de artefatos. Uma atividade deveria ser utilizvel como elemento de planejamento e progresso; se for muito pequeno, ser negligenciado, se for muito grande, o progresso ter que ser expresso em termos das partes da atividade [Kru03]. As atividades podem ser repetidas vrias vezes no mesmo artefato, especialmente de uma iterao para a outra, quando o sistema refinado ou expandido. Atividades repetidas podem ser desempenhadas pelo mesmo papel, mas no necessariamente pelo mesmo indivduo. Artefatos: Um artefato um pedao de informao que produzida, modificada ou usada por um processo [RAT01] [Kru03]. Os artefatos so os produtos tangveis do projeto: as coisas que o projeto produz ou usa enquanto trabalha para o produto final. Os artefatos so usados como entrada por papis para desempenhar uma atividade e so o resultado ou a sada de tais atividades. Os artefatos possuem diferentes formas de apresentao, tais como modelos (modelo de caso de uso ou modelo de projeto), elementos do modelo (classe, caso de uso), documentos (caso de uso do negcio ou documento de arquitetura de software), cdigos-fonte e executveis. Os artefatos tambm podem ser compostos de outros artefatos.

39

Fluxos: Um fluxo uma sequncia de atividades que produz um resultado de valor observvel [RAT01] [Kru03]. Em termos de UML, um fluxo pode ser expresso como um diagrama de sequncia, de colaborao ou de atividade. No RUP podemos dividir os fluxos em dois grupos principais: fluxos centrais (core workflows), que so as disciplinas do processo, e os detalhes de fluxo (workflow detail), que so os fluxos internos de cada disciplina. importante ressaltar que um fluxo no pode ser interpretado literalmente como sendo um conjunto de passos no qual um indivduo ir executar de forma automtica e mecnica . H nove fluxos centrais no processo RUP, e eles representam uma partio de todos os papis e atividades em grupos lgicos: reas de interesse e disciplinas. Os fluxos centrais (disciplinas) so divididos em seis na engenharia e trs no suporte [Kru03]. Sendo as disciplinas de engenharia: - Modelagem de Negcios; - Requisitos; - Anlise e Design; - Implementao; - Teste; - Implantao. Sendo as disciplinas de suporte: - Gerenciamento de Configuraes e Mudanas; - Gerenciamento de Projetos; - Ambiente.

2.3.2.3 Dimenso Dinmica Um projeto baseado no RUP passa por quatro fases: Iniciao, Elaborao, Construo e Transio. Cada fase contm uma ou mais iteraes [RAT02]. Atravs desta caracterstica iterativa, cada fase realizada com base no resultado da fase anterior, de maneira a refinar o sistema at o momento em que o produto final esteja completo [Jac99].

40

E [Jac99] ainda destaca, cada fase no processo RUP atravessar diversas iteraes. Uma iterao um lao completo do desenvolvimento tendo por resultado uma liberao (interna ou externa) de um produto executvel, um subconjunto do produto final sob o desenvolvimento, que cresce de forma incremental de iterao em iterao at se transformar no sistema final. Fase Iniciao: A Iniciao significativa para novos esforos de desenvolvimento, onde necessrio tratar de riscos de negcios e de requisitos importantes, antes da continuao do projeto. Para projetos que visam melhorias em um sistema existente, a fase de Iniciao mais rpida, mas ainda se concentra em assegurar que o projeto seja compensatrio e que seja possvel faz-lo. Durante a Iniciao, criado o caso de negcios para construo do software. A Viso um artefato chave produzido durante a Iniciao. uma descrio de alto nvel do sistema. Ela informa a todos qual o sistema e tambm pode informar que o utilizar, por que ele ser utilizado, quais recursos devem ser apresentados e quais restries existem. Muitas vezes, a Viso contm os recursos crticos fornecidos pelo software para o cliente [RAT02]. Fase Elaborao: A meta da fase de Elaborao criar a linha de base2 para a arquitetura do sistema, a fim de fornecer uma base estvel para a parte principal do esforo de design e de implementao da fase de Construo. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que tm grande impacto na arquitetura do sistema) e de uma avaliao de risco. A estabilidade da arquitetura avaliada atravs de um ou mais prottipos de arquitetura [RAT02]. Fase Construo: A meta da Construo concluir o desenvolvimento do sistema. A fase de Construo , de certa forma, um processo de manufatura, em que a nfase est no gerenciamento de recursos e controle de operaes para otimizar custos, programaes e qualidade. Nesse sentido, a inteno do gerenciamento passa por uma transio do desenvolvimento de propriedade intelectual durante a Iniciao e Elaborao, para o desenvolvimento de produtos implantveis durante a Construo e a Transio [RAT02].

Uma situao inicial de referncia de planejamento normalmente utilizada para comparao do planejado com o real. Largamente utilizada na literatura de projetos.

41

Fase Transio: O foco da Transio assegurar que o software esteja disponvel para seus usurios finais. A fase de Transio inclui testar o produto em preparao para release e ajustes pequenos com base no feedback do usurio. Nesse momento no ciclo de vida, o feedback do usurio precisa principalmente ser focalizado no ajuste do produto, na configurao, na instalao e nos problemas de utilidade [RAT02]. 2.4 Gerenciamento de Escopo 2.4.1 Definio Como enfatiza [Sot07], a rea de conhecimento do gerenciamento do escopo aquela que trata, principalmente, da definio e controle do que est e do que no est includo no projeto, ou seja, a fundamentao do planejamento do projeto. Serve para a criao de sua linha de base, onde esto contidos os processos de gerenciamento de projeto necessrios para que possamos nos assegurar de que o projeto inclui a descrio de todo o trabalho necessrio para uma concluso bem-sucedida. Assim, o trabalho no descrito no plano de gerenciamento do escopo do projeto no faz parte do projeto. A declarao de escopo fundamental, j que o gerente precisa ter uma viso muito clara do produto ou servio a ser desenvolvido, incluindo suas caractersticas, premissas assumidas, restries, etc. O que no faz parte do escopo tambm precisa estar bem claro na declarao, para facilitar o entendimento do projeto e viabilizar um diagrama de rede coerente com a realidade do produto a ser desenvolvido [Bar07]. Na definio formal do [Pmi04], o gerenciamento do escopo do projeto inclui os processos necessrios para garantir que o projeto inclua todo o trabalho necessrio, e somente ele, para terminar o projeto com sucesso. O gerenciamento do escopo do projeto trata principalmente da definio e controle do que est e do que no est includo no projeto. Fica muito difcil a definio de atividades sem o conhecimento total do escopo pretendido. No impossvel, porque isso pode variar de projeto para projeto, mas fica visivelmente dificultada, dado que logicamente preciso saber antes o que se deseja obter para depois se planejar como conseguir [Bar07]. Comparado a 2006, prazo, escopo e custo continuam sendo em 2007, [INT07] as principais reas consideradas nas metodologias de gerenciamento de projetos, assim

42

como integrao e aquisies continuam sendo as reas menos consideradas. Conforme a Figura 8 demonstra esta situao. Isto demonstra uma preocupao das organizaes com o escopo e com o tempo no gerenciamento de projetos, so reas que merecem uma ateno especial por influenciarem diretamente no sucesso do projeto, bem como no custo. A falha em definir exatamente o que ser feito provavelmente ir impactar o custo (e talvez o lucro) de um projeto, ou pior, resultar em um projeto que produz entregas que o cliente se recusa a aceitar [SIL07]. Conforme [Bar07], no somente o gerenciamento do tempo, mas todas as reas do gerenciamento de projetos tm no escopo do projeto a base para seu planejamento. Mas no caso especfico do gerenciamento do tempo, e principalmente no momento da definio das atividades, essa influncia determinante.

Figura 8- Aspectos considerados mais importantes no gerenciamento de projetos [INT07].

43

2.4.2 Falhas no Gerenciamento de Projetos e a relao com a Gerncia de Escopo Um dos aspectos de maior relevncia num projeto o tempo dedicado ao planejamento do mesmo e, em particular, caracterizao do escopo. Neste ponto, atividades aparentemente simples so menosprezadas ou desconsideradas. a etapa na qual busca-se garantir que todos os envolvidos, desde o contratante at cada um dos projetistas, tenham um conhecimento comum e preciso daquilo que dever ser feito para gerar o produto desejado e nada mais do que o produto desejado. Em outras palavras, um conhecimento das necessidades e expectativas do cliente [Sot07]. Ainda conforme [SIL07], espera-se que os projetos tenham um objetivo claro e entendido por todas as partes interessadas. A realidade, no entanto, pode ser bem diferente. Muitos projetos iniciam com uma ideia vaga do resultado final ou com apenas uma definio superficial. Assim, muitos projetos falham devido m definio do escopo.

Figura 9 - Problemas que ocorrem com mais freqncia nos projetos das organizaes [INT07].

44

De acordo com a pesquisa de [INT07], a Figura 9 demonstra os problemas que ocorrem com mais frequncia nos projetos das organizaes, observa-se que o no cumprimento de prazos (66%), problemas de comunicao (64%) e mudanas constantes de escopo (62%) so os principais problemas relatados pelas organizaes. Atravs deste estudo da [INT07], possvel verificar a importncia do planejamento e da definio de escopo para sucesso nos projetos. Com estes resultados referentes aos problemas teremos tambm, atrasos no cronograma, mudanas de requisitos e especificaes, falta de recursos humanos, custos acima do esperado, produtos e/ou servios que no satisfazem o cliente, muitas vezes pode levar ao cancelamento do projeto.

2.4.3 Escopo do Produto e Escopo do Projeto O escopo do produto no deve ser confundido com o escopo do projeto. Com uma certa frequncia esta diferena ignorada. O trmino do escopo do projeto medido em relao ao plano de gerenciamento do projeto, declarao do escopo do projeto, e Estrutura Analtica do Projeto (EAP) e ao dicionrio da EAP associados a ele, mas o trmino do escopo do produto medido em relao aos requisitos do produto. O gerenciamento do escopo do projeto precisa estar bem integrado aos outros processos da rea de conhecimento, de forma que o resultado do trabalho do projeto seja a entrega do escopo do produto especificado [Pmi04].

2.4.3.1 Escopo do Produto O escopo do produto composto pela especificao tcnica que descreve o conjunto de funcionalidades e o desempenho desejado para o produto, e deve ser elaborado antes do escopo do projeto [Mar02]. J conforme [Sot07], o escopo do produto est relacionado ao conjunto de caractersticas e funes que descrevem um produto, servio ou resultado, seja ele parcial ou final. Est intimamente relacionado aos requisitos e especificaes fornecidos pelo cliente, os quais podem ser mais ou menos detalhados. Muitas vezes ele desenvolvido pela equipe do projeto junto ao prprio cliente.

45

2.4.3.2 Escopo do Projeto Na definio de [Mar02], o escopo do projeto descreve as principais atividades a serem executadas, a base para elaborao do cronograma e do oramento. Algumas vezes necessrio especificar o que o projeto no vai produzir, particularmente quando existe algo que as pessoas possam presumir como sendo parte do projeto. Por exemplo, no desenvolvimento de um sistema, pode ou no fazer parte do escopo do projeto o treinamento dos usurios, a gerao de manuais e a instalao dos sistemas nos computadores dos usurios. O escopo do projeto refere-se ao trabalho que deve ser realizado para entregar um produto, servio ou resultado com as caractersticas e funes especificadas. Para [Sot07], em geral, o resultado de um projeto um nico produto, que pode incluir componentes auxiliares, cada um deles com seu prprio escopo do produto separado, mas interdependente. Por exemplo, se voc for contratado para desenvolver um avio, umas das entregas o prprio avio, porm existem outras entregas que so necessrias para o sucesso do empreendimento, como um hangar para fabricar o avio, simulador, treinamento, dados etc.

2.4.4 Detalhamento dos Processos Especficos do Gerenciamento de Escopo Os processos de gerenciamento do escopo do projeto, e suas ferramentas e tcnicas associadas, variam por rea de aplicao, so normalmente definidos como parte do ciclo de vida do projeto e so documentados no plano de gerenciamento do escopo do projeto. A declarao do escopo detalhada do projeto aprovada, a EAP e o dicionrio da EAP associados a ela, constituem a linha de base do escopo do projeto [Pmi04]. O gerenciamento do escopo envolve processos necessrios para garantir que os vrios elementos do projeto estejam apropriadamente coordenados. Desenvolver estes processos envolve decidir entre objetivos e alternativas que competem entre si de modo a atender ou exceder as necessidades e expectativas das partes interessadas [Sot07]. Gerenciar o escopo envolve desenvolver os seguintes processos que sero detalhados nas prximas sees deste documento: Planejamento do escopo; Definio do escopo;

46

Criao da estrutura analtica do projeto; Verificao do escopo; Controle do escopo. Estes processos do gerenciamento do escopo interagem entre si e tambm com processos de outras reas de conhecimento. Cada processo pode envolver o esforo de uma ou mais pessoas ou grupos de pessoas, com base nas necessidades do projeto, ocorre pelo menos uma vez em todos os projetos e tambm em uma ou mais fases do projeto, se ele estiver dividido em fases. Embora os processos estejam apresentados aqui como componentes distintos com interfaces bem definidas, na prtica eles podem se sobrepor e interagir de maneiras no detalhadas aqui [Pmi04]. A Figura 10 apresenta uma viso geral destes elementos:

Figura 10 - Processos, Entradas e Sadas do Gerenciamento de Escopo. Adaptado de [Sot07]. 2.4.4.1 Planejamento do Escopo A definio e o gerenciamento do escopo do projeto influenciam o sucesso total do projeto. Cada projeto exige um balanceamento cuidadoso de ferramentas, fontes de

47

dados, metodologias, processos e procedimentos, e de outros fatores, para garantir que o esforo gasto nas atividades de determinao do escopo esteja de acordo com o tamanho, complexidade e importncia do projeto [Pmi04]. O plano de gerenciamento do escopo do projeto uma ferramenta de planejamento que descreve como a equipe ir definir o escopo do projeto, e desenvolver a declarao do escopo detalhada do projeto, definir e desenvolver a estrutura analtica do projeto, verificar o escopo do projeto e controlar o escopo do projeto [Pmi04]. A determinao de planejar disciplinadamente o escopo constantemente desafiada pelo contexto de negcios das organizaes. Esse ambiente, pleno de oportunidades e desafios estratgicos, operacionais e tcnicos, ao mesmo tempo que restringe, passa a exigir tempo dedicado aplicao efetiva das boas prticas em gerenciamento de projetos, como um mecanismo eficaz de gerao de solues no escopo estabelecido, dentro do prazo e do oramento contratados e de acordo com os nveis de qualidade acordados [Sot07]. O objetivo fundamental do esforo de planejamento deve ser o de prover uma orientao consistente e realista a respeito do que deve ser gerado pelo projeto e de como isso deve ser executado e controlado.

2.4.4.2 Definio do Escopo A preparao de uma declarao do escopo detalhada do projeto essencial para o sucesso do projeto e desenvolvida a partir das principais entregas, premissas e restries, que so documentadas durante a iniciao do projeto, na declarao do escopo preliminar do projeto. Durante o planejamento, o escopo do projeto definido e descrito mais especificamente porque se conhecem mais informaes sobre o projeto. Necessidades, desejos e expectativas das partes interessadas so analisados e convertidos em requisitos. As premissas e restries so analisadas para garantir que estejam completas, adicionando-se mais premissas e restries conforme necessrio. A equipe do projeto e outras partes interessadas, que possuem uma viso mais clara da declarao do escopo preliminar do projeto, podem realizar e preparar as anlises [Pmi04]. Conforme [Sot07], antes de simplesmente sair fazendo, o objetivo central do gerente e da equipe na definio do escopo do projeto deve ser: A partir das definies preliminares sobre o projeto, registradas no termo de abertura, prover esclarecimento

48

paulatino, no menor tempo possvel, sobre o que fazer, de que forma entreg-lo e como medir os resultados do escopo do projeto. Em um equilbrio satisfatrio entre as restries-chave do empreendimento e o nvel de incerteza com o qual os envolvidos sentem-se confortveis para tomar decises. O documento que consolida essas informaes a declarao de escopo. Segundo [Mar02], na definio do escopo deve estar claro a estratgia e as tticas que sero utilizadas. A estratgia est associada abordagem que ser utilizada para realizar o projeto, como por exemplo, utilizar anlise essencial ou UML para especificao de um sistema. A ttica indica que passos sero dados para implementar a estratgia ou abordagem: elaborar o modelo de dados, documentao de casos de uso e outras atividades associadas ao desenvolvimento.

2.4.4.3 Criao da EAP A EAP uma decomposio hierrquica orientada entrega do trabalho a ser executado pela equipe do projeto, para atingir os objetivos do projeto e criar as entregas necessrias. A EAP organiza e define o escopo total do projeto. A EAP subdivide o trabalho do projeto em partes menores e mais facilmente gerenciveis, em que cada nvel descendente da EAP representa uma definio cada vez mais detalhada do trabalho do projeto. possvel agendar, estimar custos, monitorar e controlar o trabalho planejado contido nos componentes de nvel mais baixo da EAP, denominados pacotes de trabalho [Pmi04]. A organizao das entregas por meio de uma EAP vem sendo fortemente utilizadas nos projetos de sucesso em todo o mundo, j que permite o esclarecimento equipe do projeto, fornecedores, clientes, patrocinadores e demais interessados sobre o que se espera em termos de resultados do projeto e, consequentemente, do que ser monitorado e controlado. O gerenciamento do conhecimento aplicado a um projeto deve coletar, armazenar e disponibilizar as informaes histricas e as lies aprendidas em outros projetos, viabilizando o aprendizado com o passado. Assim, uma EAP de um projeto especfico poder ser utilizada parcialmente em outro projeto semelhante [Sot07]. Os passos seguintes so a representao de uma estratgia para criao de uma EAP, no indicando ser uma abordagem obrigatria e nica:

49

Escrever o nome do projeto no primeiro nvel (nvel 0) da EAP; Iniciar o segundo nvel com uma entrega denominada gerenciamento do projeto; Acrescentar as fases do ciclo de vida ou maiores entregas no segundo nvel; Acrescentar no segundo nvel, ao final, uma entrega denominada fechamento do projeto; Acrescentar as entregas (produtos) e subprodutos (entregas parciais) que as compem; Decompor as entregas parciais at um nvel de detalhe que viabilize o planejamento e controle em termos de tempo, custo, qualidade, risco, atribuio de responsabilidade e contratao, se for o caso; Revisar continuamente a EAP, refinando-a quando necessrio, at que a mesma esteja apta a ser aprovada; importante salientar, que possvel escolher uma estratgia onde o projeto seja decomposto por rea geogrfica ou partes componentes e no por fases de ciclo de vida. Abaixo apresentamos na Figura 11 um exemplo com os passos para a criao de uma EAP e os seus respectivos nveis.

Figura 11 - Exemplo de Modelo para criar EAP. Adaptado de [Sot07]. No existe uma regra que defina em quantos nveis o gerente de projetos dever decompor sua EAP. O importante que o nvel adotado seja suficiente para especificar o

50

que ser gerado no projeto, de forma que as partes interessadas possam compreender e participar ativamente em suas atribuies. Na Figura 12, apresentamos um exemplo de como poderia ser organizada a EAP para o desenvolvimento de uma verso de um software. importante lembrar do documento complementar da EAP, que o dicionrio da EAP, fundamental para especificar cada pacote de trabalho definido na EAP. Apresentando uma breve especificao do pacote de trabalho e seu critrio de aceitao.

Figura 12 Exemplo EAP para uma verso de um software [Bar06]. 2.4.4.4 Verificao do Escopo Aes de monitoramento e verificao do escopo so aquelas que exigem o acompanhamento e certificao das condies e dos resultados que so obtidos durante a execuo do projeto, bem como a sua comparao com o que foi, anteriormente, planejado. O enfoque dado a essas aes sobre o resultado obtido durante a implementao do projeto. Esse resultado desejado nos projetos, representado pela linha de base, a referncia, estabelecida aps os ajustes durante o esforo de planejamento. As atividades do grupo de processos de controle e monitoramento, nas quais encontramos o desenvolvimento das aes de verificao do escopo, ocorrem concomitantemente s atividades de execuo do plano do projeto [Sot07]. A verificao do escopo o processo de obteno da aceitao formal pelas partes interessadas do escopo do projeto terminado e das entregas associadas. A verificao do escopo do projeto inclui a reviso das entregas para garantir que cada uma delas foi

51

terminada de forma satisfatria. Se o projeto foi finalizado antes do trmino (abortado), o processo de verificao do escopo do projeto deve determinar e documentar o nvel e a extenso do trmino. A verificao do escopo difere do controle da qualidade porque a verificao do escopo trata principalmente da aceitao das entregas, enquanto o controle da qualidade trata principalmente do atendimento aos requisitos de qualidade especificados para as entregas. Em geral, o controle da qualidade realizado antes da verificao do escopo, mas esses dois processos podem ser realizados em paralelo [Pmi04]. As entregas estabelecidas no plano do projeto e no contrato uma regra que deve ser respeitada pelo gerente do projeto. Um dos mecanismos para que isso possa ser mais bem conduzido est no estabelecimento, ainda na fase de planejamento do projeto, das entregas do projeto. Elas devem ser claramente definidas para que a sua aferio possa ser feita de maneira indubitvel. Uma forma prtica para a identificao das entregas por meio da EAP, que orientada a resultados. Assim, os pacotes de trabalho devem permitir ao gerente do projeto identificar com clareza uma entrega. Alm da entrega, um dos grandes desafios do gerente de projetos garantir que o cliente ir avaliar e aceitar os resultados parciais ou finais do projeto. Antes de qualquer entrega o gerente deve se certificar de que ela est completa e respeita as especificaes ajustadas. Isto feito, ele deve se preparar e agendar a reunio formal para o encaminhamento dos resultados ao cliente. Alm do produto e da documentao tcnica, deve ser providenciado um termo de recebimento para que o cliente possa assinar e atestar a aprovao do que est sendo entregue.

2.4.4.5 Controle do Escopo O controle do escopo do projeto trata de influenciar os fatores que criam mudanas no escopo do projeto e de controlar o impacto dessas mudanas. O controle do escopo garante que todas as mudanas solicitadas e aes corretivas recomendadas sejam processadas por meio do processo de controle integrado de mudanas do projeto. O controle do escopo do projeto tambm usado para gerenciar as mudanas no momento em que efetivamente ocorrem e integrado a outros processos de controle. As mudanas no controladas so frequentemente chamadas de aumento do escopo do projeto. A mudana inevitvel e, portanto, exige algum tipo de processo de controle de mudanas [Pmi04].

52

As solicitaes de mudana de escopo devem ser formalizadas como parte do sistema de controle de mudanas do escopo do projeto. Ele iniciado com uma solicitao formal, depois com a anlise dos seus possveis impactos e, por ltimo deve receber a aprovao dos rgos e/ou profissionais competentes e o aceite das mudanas por parte do cliente. Essa solicitao, aprovada e aceita, autorizar a implementao das mudanas no projeto. Trabalhar com controle do escopo quase sempre lidar com o controle das mudanas do escopo. Fazer um controle das mudanas de escopo deve significar, para a organizao do projeto um atributo de autoproteo. O escopo , sem sombra de dvida, um dos elementos mais suscetveis mudanas ao longo do desenvolvimento de um projeto. Assim, gerir as mudanas de escopo envolve a criao de mecanismos que sirvam como obstculos s tentativas de mudana no escopo do projeto. atribuio do gerente do projeto evitar ou minimizar as mudanas de escopo que tantos impactos desagradveis tragam ao projeto, principalmente no que se refere qualidade, aos recursos, prazos, riscos, custos e oramentos. O gerente do projeto deve ter em mente a necessidade de criar mecanismos que funcionem ao longo do ciclo de vida do projeto para registro das solicitaes de mudana; as anlises necessrias dessas solicitaes; garantir o fluxo de informaes relativo s mudanas; suportar o processo de tomada de deciso sobre mudanas. No Anexo A apresentamos um exemplo de formulrio para solicitao de mudanas no escopo. Acompanhadas as mudanas de escopo, ser importante atualizar a documentao do projeto. A declarao de escopo deve compreender os novos produtos ou solues solicitadas e que foram aceitas pela equipe do projeto e/ou cliente. J a estrutura analtica do projeto, seus respectivos pacotes de trabalho e detalhamento, por meio do seu dicionrio, tambm precisam ser atualizados caso alguma alterao de escopo tenha sido implementada. Isso provocar uma alterao na referncia, na linha de base do escopo que dever ser registrado para o gerenciamento do escopo como parte importante do projeto. Enfim vrios processos podem sofrer ajustes com as mudanas oriundas de alteraes de escopo. Mas algumas alteraes no devem gerar alteraes na documentao do projeto. Uma mudana pode representar muito para um projeto, desde um mero e pequeno atraso at uma grande alterao no projeto. O importante aplicar

53

aes de controle do escopo para manter as variaes de produtos e servios devidamente administrados. 2.5 Consideraes sobre o captulo As sees anteriores apresentam conceitos bsicos utilizados na construo do processo de integrao proposto. Inicialmente, as definies apresentadas de gerncia de projetos, processos de desenvolvimento de software e principais problemas relacionados gesto de projetos, ilustram as caractersticas essenciais a estes conceitos, auxiliando na criao do processo de integrao. Logo aps, foi apresentado o PMBOK, documento redigido e mantido pelo PMI onde esto registradas as melhores prticas de gerncia de projetos defendidas pela organizao. Tambm apresentou-se uma viso geral do processo de desenvolvimento RUP ressaltando a importncia deste processo nos projetos de software. Por fim, demonstrou-se o detalhamento da gerncia de escopo em projetos, contextualizando o planejamento, definio, criao da estrutura analtica do projeto e verificao e controle do escopo, bem como a relao entre as falhas nos projetos com a gerncia de escopo. Constatou-se que a gerncia de projetos, como o PMBOK, no especificamente voltado processos de desenvolvimento de software e que o RUP tem carncias no tocante gerncia de projetos e elencamos ainda, as principais falhas com a gerncia de escopo. Estudamos abordagens para realizar a integrao destes modelos a fim de proporcionar solues estas carncias. A seguir sero apresentados os trabalhos relacionados que foram selecionados e que de alguma forma contriburam para a elaborao desta proposta.

54

TRABALHOS RELACIONADOS

Este captulo tem como principal objetivo apresentar os principais trabalhos relacionados gesto de projetos nos processos de desenvolvimento de software, especificamente utilizando-se do RUP e o PMBOK em uma forma integrada.

Na literatura foram encontradas propostas, ilustrando que o desenvolvimento de software requer o planejamento e que a execuo de atividades seja definida de acordo com o escopo do projeto, havendo a necessidade de se lidar tanto com aspectos tcnicos como gerenciais do projeto. Vrios modelos e guias de gerenciamento de projetos no se dirigem especificamente processos de desenvolvimento de software. Com a finalidade de se obter um processo mais detalhado para o gerenciamento de projetos de software, necessrio aplicar os conhecimentos de gesto de projetos aos processos de desenvolvimento de software. Entre as propostas encontradas na literatura destacamos [CHA04] e [COT04] que sugestionam uma forma de integrao e mapeamento entre o PMBOK e o RUP. Em [TEM08] discutido a forma na qual o PMBOK se relaciona com o RUP e maneiras de evitar-se ambiguidades, por fim em apresentado um modelo de integrao entre o PMBOK e o RUP, OPEN.

3.1

Gerenciamento de Projetos de Software Um mapeamento entre RUP e o

PMBOK [CHA04] Em [CHA04], dois importantes processos de gesto de projetos so comparados, proporcionando um mapeamento entre as melhores prticas na gesto de projetos das disciplinas RUP e as melhores prticas do PMBOK. Muitas organizaes pretendem padronizar suas prticas em engenharia de software, bem como suas prticas quanto gesto de projetos, e os dois conhecidos processos esto disponveis para ajudar ambas reas. O RUP que oferece uma abordagem prescritiva para a padronizao das melhores prticas em engenharia de

55

software e o PMBOK que oferece uma abordagem descritiva para a padronizao das melhores prticas em gesto de projetos. Com duas abordagens a disposio das organizaes, a questo torna-se: Eles so compatveis? A resposta simples Sim. Ao longo do artigo (mapeamento) possvel visualizar que existem semelhanas e diferenas entre os processos. Essencialmente, que o RUP est inserido nas melhores prticas para o gerenciamento de projetos de software especificamente, enquanto as melhores prticas do PMBOK so aplicveis a gesto de projetos genricos, ou seja, no domnio de qualquer aplicao. O RUP auxilia na execuo das melhores prticas para o desenvolvimento de software, mas algumas reas de gesto de projetos esto fora do mbito de suas disciplinas, e so cobertas pelas melhores prticas do PMBOK: Gesto de Pessoas: contratao e treinamento; Gesto de Oramento: definio e atribuio; Gesto de Contratos: com fornecedores e clientes. Portanto trs das nove reas do PMBOK no tem equivalentes no RUP, (gerncia de recursos humanos, gerncia de custos e gerncia de aquisies). No referido artigo o autor apresenta diversos mapeamentos entre o RUP e o PMBOK entre eles (principais caractersticas, metamodelos, reas de conhecimento e disciplinas, processos e atividades, processos de sada e artefatos). O autor conclui o estudo enfatizando que com base na comparao entre o RUP e o PMBOK no existe nenhuma incompatibilidade fundamental entre os dois padres. E que so utilizados termos diferentes para descrever semanticamente conceitos idnticos ou semelhantes, sendo que as boas prticas do RUP no contradizem o PMBOK, nem as boas prticas do PMBOK contrariam o RUP.

3.2

Padres, Tendncias, e o Rational Unified Process, Parte I: Integrando-se

RUP e o PMBOK [COT04] Em [COT04], o autor explica o relacionamento entre os processos RUP e PMBOK, e durante a descrio deste relacionamento indica a necessidade de se estudar formas de integrar os padres, para que o RUP possa incorporar caractersticas do padro da gesto de projetos da indstria institudos no PMBOK.

56

As organizaes de desenvolvimento de software ao integrar estes padres podem se tornar mais competitivas, alcanar metas comerciais, resolver problemas no processo de negcio, melhorar a comunicao da equipe e conseqentemente ter melhores resultados financeiros. Traando inicialmente uma comparao entre os padres para ajudar-nos a ter um entendimento de como estes padres se relacionam vejamos: PMBOK descreve orientaes baseada em melhores prticas da indstria. O RUP ajuda os desenvolvedores de software a implementar software utilizandose das melhores prticas. PMBOK descreve o ciclo de vida de projetos genricos. O RUP prescreve um ciclo de vida genrico para desenvolvimento de software dentro de um ciclo de vida do projeto. PMBOK descreve padres para projetos de qualquer tamanho. O RUP pode ser adaptado para a implementao de projetos de software de qualquer tamanho. Sobre as comparaes acima o autor relata que o PMBOK descreve as melhores prticas de gesto de projetos e o RUP prescreve as melhores prticas no desenvolvimento de software.

Figura 13 - A estrutura do PMBOK executada dentro de cada iterao [COT04].

57

A Figura 13, ilustra a forma como o PMBOK implementado durante cada iterao dentro de um projeto RUP. Um projeto com RUP utiliza as melhores prticas do PMBOK em cada iterao e em todas as quatro fases (Criao, Elaborao, Construo e Transio) como podemos observar na disciplina gerenciamento de projeto na ilustrao. Isso significa que temos de adequar o RUP aos elementos-chave do PMBOK. Assim, ns vamos considerar o PMBOK como um processo existente e incorporar as suas melhores prticas ao RUP. Para fazer isto primeiramente tem-se que saber o que deve-se adequar. E depois como demonstar esta integrao e comunicar as mudanas, sendo sempre realizada a documentao destas alteraes pela equipe do projeto. O autor conclui o artigo com sugestes de integrao dos padres com base no que foi apresentado, e alertando sobre o nvel de subjetividade que aplicado para a integrao dos padres que pode estar intimamente ligado a organizao ou ambiente em que o autor est inserido.

3.3

O gerenciamento de projetos com RUP em reviso [TEM08] Em [TEM08] discutida a forma com que o PMBOK se relaciona com o RUP e

explica maneiras de reduzir ou eliminar ambiguidades imperceptveis que existem quando relacionamos estes dois processos. retratado a importncia do gerente de projetos, principalmente no comando de equipes, pois os projetos de software dependem, e muito, de habilidades profissionais e intelectuais de vrios indivduos, por exemplo, indivduos que compem a equipe de desenvolvimento. O RUP no um modelo de gesto de projetos com caractersticas voltadas para a gesto de pessoas, mas sim voltado especificamente s melhores prticas de desenvolvimento de software. J o gerenciamento de projetos utilizando os padres do PMBOK podem ajudar os gerentes de projetos que esto utilizando o processo RUP para a gerncia de seus projetos. Conforme a Figura 14, observamos que incluida uma disciplina extra chamada PMBOK junto as conhecidas disciplinas do RUP e substituindo a disciplina de gerenciamento de projetos do RUP, esta disciplina integra todo um ciclo de vida do processo a cada iterao de cada fase do RUP.

58

Figura 14 - As disciplinas do RUP expandidas com o PMBOK [TEM08]. Podemos notar que a disciplina comea antes mesmo de qualquer outra disciplina do RUP ter iniciado ou antes mesmo de oficialmente o RUP ter iniciado o processo. Com uma certa prudncia, alguns cuidados e consideraes pode-se utilizar o PMBOK como uma disciplina de apoio para as configuraes iniciais das iteraes do RUP, afirma Temnenco.

3.4

Um modelo de integrao entre a gerncia de projetos e o processo de

desenvolvimento de software [ROS08] Em , apresenta um modelo de integrao entre a gerncia de projetos (PMBOK) e os processos de desenvolvimento de software (RUP) e Object-oriented Process, Environment and Notation (OPEN). O modelo foi denominado Software Planning Integrated Model (SPIM). Este modelo inclui um conjunto de regras para o planejamento integrado de atividades gerenciais e produtivas no contexto de desenvolvimento de software. Enquanto o PMBOK fornece uma perspectiva gerencial da soluo, a viso sobre a produo obtida a partir do RUP. Assim, ao aplicar o conhecimento de gerncia de projetos em conjunto com um processo de desenvolvimento de software apropriado ser possvel obter um fluxo mais completo e integrado de atividades e suas dependncias. A integrao dos modelos tambm permitiu que um conjunto de regras e restries

59

pudessem ser derivadas, essas caractersticas, em sua maioria, visam apoiar a consistncia do modelo proposto. Para realizar o trabalho que originou o modelo SPIM o autor realizou um estudo detalhado dos metamodelos do PMBOK e RUP representados por estruturas compatveis, j que a inteno era comparar dois modelos e depois promover a integrao dos mesmos. Atravs da integrao entre a gerncia de projetos e os processos de desenvolvimento de software foi possvel identificar as principais caractersticas e discrepncias entre os elementos de tais modelos. No critrio de integrao entre os modelos seguiu-se um conjunto de regras que devem ser observadas ao realizar uma integrao entre dois modelos, e as seguintes situaes podem ocorrer: - Uma sobreposio de conceitos (duas classes com o mesmo conceito em cada modelo): neste caso, pode-se transformar e unir estas duas classes em um nico conceito dentro de um pacote comum; - Relao entre conceitos (uma classe de um dos modelos se relaciona com alguma outra classe de outro modelo, mas estas classes no representam exatamente o mesmo conceito): deve-se manter as classes em seus modelos originais e criar uma associao entre elas; - Conceitos independentes (classes com conceitos independentes e distintos): deve-se deixar cada classe em seu prprio pacote. O autor conclui sua pesquisa relatando como o estudo da integrao do PMBOK com dois processos distintos de desenvolvimento de software (RUP e OPEN) permitiu elaborar uma viso mais ampla de como a gerncia de projetos pode positivamente contribuir no desenvolvimento de um produto de software. Nos trabalhos futuros o autor refora a existncia na literatura sobre diferentes integraes da gerncia de projetos com os processos de desenvolvimento de software, entretanto, parece no haver estudos suficientes para suprir a carncia no quesito de gerncia de projetos destes processos. Indicando que novas pesquisas e a continuidade do estudo iniciado levem novas contribuies para a engenharia de software, melhorando nossa compreenso dos relacionamentos da gerncia de projetos com os processos de desenvolvimento de software.

60

3.5

Consideraes sobre o captulo Com as abordagens apresentadas pode-se deduzir que o processo de

desenvolvimento de software RUP tem carncias quanto conceitos de gesto de projetos e sugestiona que estas lacunas podem ser cobertas pelo modelo de gerenciamento de projetos PMBOK. Estas propostas utilizadas como trabalhos relacionados identificam possveis diretrizes para a integrao do modelo de gerenciamento de projetos (PMBOK) com o processo de desenvolvimento de software (RUP) onde discutida a compatibilidade entre as duas abordagens, cada qual com suas contribuies e limitaes. A seguir, apresenta-se a metodologia de pesquisa adotada neste trabalho.

61

METODOLOGIA DE PESQUISA

Neste captulo caracterizou-se o tipo de pesquisa realizada, buscou-se apresentar e descrever o desenho da pesquisa com suas respectivas fases, detalhando-se o mtodo usado para exemplo de uso.

4.1

Tipo de Pesquisa Apesar de os temas uso de gerncia de projetos e processos de desenvolvimento

de software possuirem vrios estudos em desenvolvimento e pesquisas j realizadas, a integrao proposta neste trabalho com os modelos referenciados possuem poucas publicaes a respeito. Por isso, optou-se por realizar uma pesquisa exploratria com uma estratgia qualitativa que particularmente adequada para o desenvolvimento de novas teorias em reas ou abordagens ainda no consolidadas. Segundo [Yin05] e [San00], a pesquisa exploratria normalmente utilizada nos casos em que o tema em questo foi pouco pesquisado ou ento quando a reviso da literatura mostrar que existem apenas fragmentos tericos com vaga relao ao tema pesquisado. Alm de exploratrio, o mtodo de pesquisa definido caracteriza-se por seguir uma estratgia qualitativa. Esta de carter subjetivo, ou seja, a interpretao dos dados no realizada em termos de quantidade, intensidade ou frequncia estatstica, mas sim de acordo com a interpretao do pesquisador.

4.2

Desenho da Pesquisa O desenho de pesquisa se refere ao plano concebido para responder ao problema

de pesquisa, onde aparecem os mtodos a serem utilizados e a identificao das etapas do processo de pesquisa. O trabalho apresentado neste estudo foi realizado por meio de 4 etapas, as quais esto representadas pela Figura 15 e so descritas a seguir.

62

Figura 15 Desenho da pesquisa

Etapa 1: nesta etapa efetuou-se o levantamento bibliogrfico e o estudo do referencial terico que permitiu aprofundar os conhecimentos sobre gerncia de projetos e processos de desenvolvimento de software; com enfse no gerenciamento de escopo. Etapa 2: aps o desenvolvimento da etapa 1, utilizou-se o PMBOK como modelo de gerenciamento de projetos e o RUP como processo de desenvolvimento de software, comparando-os e identificando compatibilidades e relacionamentos comuns, traando um mapeamento das caractersticas do processo e do modelo. Etapa 3: nesta etapa foi apresentada uma proposta de integrao entre a gerncia de projetos e o processo de desenvolvimento de software, na rea de gerenciamento de escopo. Esta proposta visa auxiliar o planejamento integrado das atividades do PMBOK e RUP e reduzir problemas na gerncia de escopo no processo de desenvolvimento de software.

63

Etapa 4: nesta etapa escolhemos a ferramenta que permite publicar a integrao proposta na etapa anterior. O RMC foi escolhido porque uma plataforma de ferramentas que permite que engenheiros e gerentes de processo implementem, desenvolvam e faam a manuteno em projetos ou processos para organizaes. No captulo 8 desenvolveu-se um exemplo de uso, com a criao de um fluxo de um processo de desenvolvimento de software, ou seja, o fluxo demonstra processos da rea de conhecimento de gerenciamento de escopo e gerenciamento de integrao do PMBOK, sendo executados de forma integrada com as fases do processo RUP e com o processo de desenvolvimento de software do projeto (PDSP), fornecendo a base para o planejamento, desempenho e aperfeioamento das atividades gerenciais e tcnicas que as tarefas do projeto executam.

4.3

Consideraes sobre o captulo Nesta seo demonstrou-se que o tipo de pesquisa que caracteriza o trabalho do

tipo exploratria seguindo uma estratgia qualitativa, que de carter subjetiva dando nfase ento a interpretao do autor. Mostrou-se o desenho de pesquisa onde podemos identificar todas as etapas de pesquisa do planejamento concebido para resolver ao problema de pesquisa.

64

MAPEAMENTO ENTRE PROCESSO RUP E O MODELO PMBOK

Com o intuito de atingir o objetivo deste trabalho necessrio que se faa uma comparao e anlise de compatibilidade entre os modelos, para que tenhamos instrumentos de avaliao entre os modelos PMBOK e RUP. Fazendo o mapeamento do PMBOK (reas de conhecimento, grupos de processos) com o RUP (disciplinas, atividades) poderemos identificar os relacionamentos e tambm possveis adequaes que devem ser efetuadas para a integrao proposta.

Neste trabalho proposto um processo integrado utilizando o RUP associado s melhores prticas do PMBOK para gerenciamento de escopo em projetos de software. Nesta seo demonstrou-se os mapeamentos bsicos e essenciais entre o RUP e o PMBOK, para que se alcance o objetivo deste trabalho, destacando: principais caractersticas, reas de conhecimento e disciplinas, processos e atividades.

5.1

Comparaes e Anlises de compatibilidade RUP/PMBOK

Tabela 1 - Comparao PMBOK e RUP: Principais Caractersticas. Adaptado de [CHA04].

PMBOK Qualquer tipo de projeto Somente projetos prticas de gesto

RUP Especfico para projetos de software de Prticas para gesto de projetos de desenvolvimento de software

Cobre todos os aspectos da gesto de Cobre alguns aspectos da gesto de projetos Abordagem descritiva projetos Abordagem prescritiva

As fases so dependentes do domnio As fases e as iteraes so especificas da aplicao para o desenvolvimento de software

65

A Tabela 1 apresenta uma comparao entre o PMBOK e o RUP em relao as suas principais caractersticas. Tanto o PMBOK como o RUP tem em suas atividades grupos estruturais e grupos temporais, estas e outras caractersticas podem ser observadas na Tabela 2 que nos mostra uma comparao do metamodelo PMBOK e RUP. Tabela 2 - Metamodelo PMBOK e RUP. Adaptado de [CHA04]. Elemento Tipo do projeto PMBOK Qualquer tipo de projeto Especfico software Dividido em 4 fases: Iniciao, Elaborao, Construo e Transio. Casa fase dividida em uma ou mltiplas iteraes em todas as disiciplinas atravs das atividades. Marcos principais Artefato sadas, Artefato de entrada, artefato de sada, padres, ferramentas Artefato de entrada Artefato de Sada RUP para projetos de

Dividido Ciclo Projeto de Vida do

em 4

Fases. ou 5

Tipicamente

podendo chegar a 9. Em cada fase realizada uma ou mais entregas.

Fim da Fase Fim da Fase Artefato Atividade Artefato de entrada Artefado de sada

Marcos Entrega Entradas,

ferramentas e tcnicas Entrada Sada

Reviso do fim da Fim de fase, estgios e Reviso do ciclo de vida entre fase Grupo de Atividades Estruturais Grupo de Atividades Temporais marcas reas de Conhecimento marcos Disciplinas

Grupo de Processos

Atividades

66

A comparao feita do processo RUP em relao as prticas de gerenciamento de projetos propostas pelo PMBOK, de modo a analisarmos qual o grau de atendimento da engenharia de software em relao s prticas executadas e consagradas como melhores prticas pelos profissionais em gerenciamento de projetos. Mesmo que em alguns processos exista sobreposio, as abordagens do RUP e PMBOK so essencialmente complementares e compatveis, conforme a Figura 16. Principalmente porque o RUP trata da perspectiva tcnica focado na engenharia do produto e o PMBOK em uma perspectiva mais gerencial de um sentido mais amplo do projeto.

Figura 16 - Abordagens do RUP e PMBOK. (1) O RUP fornece processos e ferramentas para a definio de papis e

responsabilidades, e o PMBOK de como organizar e gerenciar a equipe. (2) O RUP fornece processos e ferramentas para gerenciar repositrios de projetos e para desempenho de relatrios, e o PMBOK tambm abrange atividades de comunicao em geral do projeto. 5.2 Mapeamentos RUP/PMBOK Na Tabela 3, comparamos o RUP com suas disciplinas e o PMBOK em relao as reas de gerenciamento de projetos.

67

O PMBOK, por ser mais genrico, cobre processos no cobertos pelo modelo RUP (gerenciamento de pessoal, oramento e contratos). O RUP tm includo prticas gerenciais no processo de desenvolvimento de software, porm, apesar de diversas pesquisas evidenciarem que o problema gerencial e no tcnico isso no est sendo representado devidamente no modelo.

Tabela 3 - Mapeamento PMBOK e RUP em relao: reas de Conhecimento e Disciplinas. Adaptado de [CHA04]. PMBOK Ares de Conhecimento RUP Disciplinas Gerenciamento de projeto Integrao Requisitos Instalao Configurao mudanas Escopo Requisitos Configurao mudanas Tempo Custo Aquisio Recursos Humanos Comunicao Risco Garantia de Qualidade e gerenciamento de e gerenciamento de

Gerenciamento de projeto

Gerenciamento de projeto Sem mapeamento Sem mapeamento Sem mapeamento completo, embora

defina a organizao do projeto Gerenciamento de Projeto Gerenciamento de Projeto Gerenciamento de Projeto Gerenciamento de Mudanas

Diante do mapeamento da Tabela 3, destacamos em negrito a rea que o foco deste estudo, as disciplinas do RUP (requisitos, gerenciamento de projeto e configurao gerenciamento de mudanas) que esto relacionadas com a rea de conhecimento

68

gerencial de escopo do PMBOK, e utilizando contribuies da rea de gerenciamento de integrao do projeto, que a rea do modelo PMBOK que faz a integrao de todas as outras reas de conhecimento. A partir desse mapeamento podemos efetuar um detalhamento onde demonstramos os processos do PMBOK na rea de conhecimento gerenciamento de escopo com as atividades correlatas do processo RUP, conforme Tabela 4. Tabela 4 - Relao entre processos PMBOK e atividades RUP. Adaptado de [CHA04]. Processos PMBOK
Planejamento do escopo

Atividades no RUP
Gerenciamento de projetos o Iniciar projeto o Iniciar iterao o Desenvolver caso de negcio Gerenciamento de requisitos o Desenvolver a viso Gerenciamento de projetos o Desenvolver plano de resoluo do problema Gerenciamento de requisitos o Desenvolver plano de gerenciamento de requisitos o Desenvolver a viso o Localizar atores e casos de uso o Detalhar um caso de uso o Detalhar os requisitos de software o Captar um vocabulrio comum Gerenciamento de projetos o Desenvolver plano de iteraes o Planejar fases e iteraes Gerenciamento de requisitos o Desenvolver a viso o Localizar atores e casos de uso o Detalhar um caso de uso o Detalhar os requisitos de software o Captar um vocabulrio comum Gerenciamento de projetos o Reviso de marco de ciclo de vida Gerenciamento de requisitos o Revisar requisitos Gerenciamento de projetos o Relatar status o Avaliar iterao o Desenvolver plano de iteraes o Planejar fases e iteraes Gerenciamento de requisitos o Desenvolver a viso o Localizar atores e casos de uso o Detalhar um caso de uso o Detalhar os requisitos de software o Captar um vocabulrio comum Gerenciamento de configurao e

Definio do escopo

Criar a EAP

Verificao do escopo

Controle do escopo

69

solicitaes de mudana o Enviar controle de mudanas o Atualizar controle de mudanas

Com base no mapeamento entre o RUP e o PMBOK no existe nenhuma incompatibilidade fundamental entre os dois padres. E que so utilizados termos diferentes para descrever semanticamente conceitos idnticos ou semelhantes, sendo que as boas prticas do RUP no contradizem o PMBOK, nem as boas prticas do PMBOK contrariam o RUP [CHA04]. Utilizando a relao entre processos PMBOK e disciplinas RUP conforme demonstrado na Tabela 4, podemos identificar as disciplinas do RUP relacionadas com os grupos de processos dos processos da rea de gerenciamento do escopo de projetos, de acordo com a Figura 17.

Figura 17 - Grupo de Processos PMBOK e Atividades RUP - Gerncia de Escopo.

5.3

Consideraes sobre o captulo Como apresentado nas sees anteriores, realizou-se um estudo detalhado de

compatibilidade entre o RUP e PMBOK, o que concluiu-se que de uma forma geral o

70

PMBOK cobre algumas reas no cobertas pelo RUP, como gerenciamento de aquisies e custos, e que em alguns casos encontramos conceitos semelhantes representados com termos semanticamente diferentes, como gerenciamento de integrao e gerenciamento de projeto. O Mapeamento das reas de conhecimento do PMBOK com as disciplinas do RUP requer uma ateno especial, pois em vrias situaes este mapeamento pode estar cruzado entre estes conceitos, ou seja, poderamos ter uma ou vrias reas de conhecimento se relacionando com uma ou mais disciplinas. Como neste trabalho se prev a integrao a nvel de gerenciamento de escopo, tratamos especificamente dessa rea de conhecimento do PMBOK, e utilizamos atividades da rea de gerenciamento de integrao que por sua vez faz a interao entre todas s areas de conhecimento do PMBOK. O desenvolvimento deste mapeamento o primeiro passo para a criao da integrao proposta, aqui demonstrou-se o relacionamento entre o RUP e o PMBOK quanto as suas principais caractersticas e mais detalhadamente na rea de gerenciamento de escopo. Esta seo foi fundamental para a criao do Apndice A Demonstrao da Integrao dos Modelos, que por sua vez serviu de base para o processo integrado proposto que apresentado no captulo 7. No prximo captulo apresentamos o ferramenta RMC.

71

FERRAMENTA PARA PUBLICAO E PERSONALIZAO DE

PROCESSOS - RMC

Neste Captulo apresenta-se a ferramenta Rational Method Composer utilizada para estender a estrutura do mtodo existente com o novo contedo de mtodo, o RMC a ferramenta utilizada para a publicao e personalizao do processo proposto.

6.1

Descrio principal do Rational Method Composer O aplicativo RMC (IBM Rational Method Composer) uma uma ferramenta de

publicao e personalizao de processos que permite aos engenheiros de processo acelerar a distribuio de processos de desenvolvimento de software personalizados, modelar processos visualmente utilizando a Linguagem de Modelagem Unificada e promover o uso de boas prticas capturadas no RUP. O RMC ajuda a personalizar RUP para os requisitos precisos da sua organizao, melhorando sua prpria experincia, prticas e conhecimento interno [RAT08]. Construdo na plataforma Eclipse - o Rational Method Composer especificamente projetado para o gerenciamento de contedo do mtodo com funes como autoria com base em formulrio, navegao de contedo, pesquisa de contedo e importao e exportao de contedo do mtodo. O RMC suporta configurao durante a publicao bem refinada do contedo para atender a diferentes necessidades de projetos e usurios finais. O poderoso recurso Plugin de Contedo do RMC permite que o contedo existente seja estendido e modificado por meio de plug-ins, simplificando o gerenciamento e a manuteno do contedo de mtodo [RAT08]. O Rational Method Composer tem dois objetivos principais [RMC08]: Fornecer uma base de conhecimento de capital intelectual que voc possa procurar, gerenciar e implementar. Este contedo pode incluir contedo desenvolvido externamente e, o mais importante, pode incluir seu prprio contedo, que pode ser white papers, diretrizes, gabaritos, princpios, boas prticas, procedimentos e regulamentaes internos, material de treinamento e qualquer outra descrio geral de seus mtodos. Essa base de conhecimento pode ser utilizada para referncia e educao. Ela tambm compe a base para

72

processos de desenvolvimento (o segundo objetivo). O Rational Method Composer foi projetado para ser um sistema de gerenciamento de contedo que fornece uma estrutura comum de gerenciamento e aparncia e comportamento para todo o seu contedo, em vez de ser um sistema de gerenciamento de documento em que voc armazena e acessa documentos herdados de difcil manuteno, tudo em suas prprias formas e formatos. Todo o contedo gerenciado no Rational Method Composer pode ser publicado em HTML e implementado em servidores da Web para uso distribudo. Fornecer recursos de engenharia do processo, dando suporte a engenheiros do processo e coordenadores de projeto na seleo, personalizao e rpida montagem de processos para os projetos de desenvolvimento concretos correspondentes. O Rational Method Composer fornece catlogos de processos predefinidos para situaes tpicas de projetos que podem ser adaptadas s necessidades individuais. Ele tambm fornece blocos de construo de processo, chamados padres de recursos, que representam as boas prticas de desenvolvimento para disciplinas, tecnologias ou estilos de gerenciamento especficos. Esses blocos de construo compem um toolkit para rpida montagem de processos baseados nas necessidades especficas do projeto. O Rational Method Composer tambm permite configurar suas prprias bibliotecas com padro de recurso especficas da organizao. Finalmente, os processos criados com o Rational Method Composer podem ser publicados e implementados como Web sites. Eles tambm podem ser implementados como modelos de plano de projeto para o Rational Portfolio Manager. O princpio mais fundamental no Rational Method Composer a separao de contedo de mtodo principal reutilizvel de seu aplicativo em processos. Quase todos os conceitos do Rational Method Composer esto categorizados com essa separao. O contedo de mtodo descreve o que deve ser produzido, as habilidades necessrias exibidas e as explicaes de ponta a ponta, que descrevem como metas de desenvolvimento especficas so atingidas. Essas descries de contedo de mtodo so independentes de um ciclo de vida de desenvolvimento. Os processos descrevem o ciclo de vida de desenvolvimento. Os processos obtm os elementos do contedo de mtodo e os relatam para seqncias semi-ordenadas que so personalizadas para tipos especficos de projetos [RMC08]. Podemos visualizar na Figura 18, como essa separao foi relatada no Processo Unificado do Rational.

73

Figura 18 - RMC e a separao de contedo do mtodo dos processos no RUP [RMC08]. A Figura 19 abaixo fornece um resumo dos principais elementos utilizados no Rational Method Composer e como esto relacionados ao contedo ou ao processo do mtodo. O contedo de mtodo expresso principalmente utilizando produtos de trabalho, funes, tarefas e orientao. A orientao, como listas de verificao, exemplos ou roteiros, tambm pode ser definida para fornecer acompanhamentos exemplares de um processo.

Figura 19 - Principais Elementos do RMC e sua relao: contedo de mtodo e processo [RMC08].

74

No lado direito do diagrama, podemos observar os elementos utilizados para representar os processos do Rational Method Composer. O elemento principal a atividade que pode ser aninhada para definir estruturas de diviso, bem como relacionada uma com a outra para definir um fluxo de trabalho. As atividades tambm contm descritores que fazem referncia ao contedo de mtodo. As atividades so utilizadas para definir os processos suportados pelo Rational Method Composer em dois tipos principais: processos de entrega e padres de recurso. Os processos de entrega representam um gabarito de processo completo e integrado para executar um tipo especfico de projeto. Eles descrevem um ciclo de vida completo e de ponta a ponta do projeto e so utilizados como uma referncia para executar projetos com caractersticas similares. Os padres de recursos so processos que expressam e comunicam o conhecimento do processo para uma rea principal de interesse, como uma disciplina ou uma boa prtica. Eles tambm so utilizados como blocos de construo para montar processos de entrega ou grandes padres de recursos. Isso garante a tima reutilizao e a aplicao das melhores prticas nas atividades de autoria de processo no Rational Method Composer. Na integrao proposta neste trabalho utilizado o RMC em sua verso IBM Rational Method Composer 7.5.0 que acessa a verso do Rational Unified Process Base Plug-in 7.0.1, sendo que utilizamos o RUP em sua configurao clssica para grandes projetos.

6.2

Viso da configurao de mtodo da integrao O Rational Method Composer oferece uma biblioteca que contm uma grande

quantidade de contedo reutilizvel. Ele inclui a estrutura de mtodo do RUP e diversos plug-ins que estendem o RUP com incluses especficas do domnio. possvel criar e especificar uma configurao utilizando o editor de configuraes descrito na Figura 20. Pode-se comear criando uma prpria configurao de mtodo, copiando uma das configuraes includas com o Rational Method Composer e modificla para que se adapte s necessidades especficas. Ou ainda incluir ou remover os plugins de mtodo por completo, bem como fazer a seleo com cada plugin, marcando ou desmarcando pacotes.

75

Figura 20 - Tela com a configurao de mtodo da integrao RUP e PMBOK.

Na Figura 22 podemos observar algumas das configuraes que foram realizadas para a criao da integrao e posteriormente a publicao da mesma: - Configurao do RUP clssico para grandes projetos: - Perspectiva no modo de autoria : - Criao de um plugin de mtodo, utilizando toda a base do RUP:

Com

estes

procedimentos

realizados

nesta

tela

de

configurao temos toda a biblioteca de mtodos do RUP criado em sua configurao clssica para grandes projetos, podemos ento comear a adaptao nesta fase de elementos do mtodo e contedo do mtodo.

76

6.3

Viso da autoria de contedo do mtodo No modo de perspectiva do tipo autoria, podemos comear a fazer as alteraes e

incluses necessrias para a integrao do processo de acordo com os mapeamentos estabelecidos. possvel criar vrios tipos diferentes de elementos do mtodo de acordo com suas caractersticas e objetivos, a Figura 21 mostra as possibilidades de novos elementos do mtodo.

Figura 21 - Opo de escolha de novo elemento do mtodo. interessante atentar-se que o elemento de mtodo criado dentro do pacote de contedo que o usurio estiver acessando no momento. Como a biblioteca muito extensa e apresenta nomes de elementos semelhantes, importante ter a exata noo de referncia da criao dos elementos, pois evita a criao de um elemento em um pacote de contedo errado e por consequncia no momento da visualizao o contedo do mtodo vai estar com informaes inconsistentes e com uma viso errnea quanto produtos, papis, atividades, etc. Para evitar este tipo de problema aconselha-se a utilizao da disposio em navegao em rvore para visualizao, o que pode facilitar a localizao e a organizao das vises que as alteraes podem influenciar. A Figura 22 a seguir, ilustra a tela de um elemento de mtodo que foi criado na viso da autoria de contedo do mtodo, sendo que o contedo de mtodo descreve as funes, e as tarefas que as funes podem executar, os produtos de trabalho que so

77

utilizados e produzidos por essas tarefas e a orientao de suporte, nesta figura podemos observar a autoria de uma tarefa Atividade Gerencial de Planejamento: AGP Desenvolver Declarao do Escopo do Projeto.

Figura 22 - Tela de um elemento de mtodo do tipo tarefa e seu contedo. Nesta Figura 22, podemos observar ainda que o elemento de mtodo que foi criado pode ter seu contedo configurado atravs das abas que ficam localizadas na parte inferior da tela. Cada elemento de mtodo possui um conjunto de abas diferenciado. Demonstraremos as abas dos elementos que so mais comuns e tambm que foram criados nesta integrao (Tarefa, Produtos de Trabalho).

Elemento Tarefa: Descrio: pode-se fornecer uma multiplicidade de informaes sobre o elemento que foi criado, como informaes gerais, informaes detalhadas, objetivos, palavras chaves, verso, informa o relacionamento com outro elemento de mesmo tipo, configurao de cone do elemento;

78

Etapas: Cria e especifica as etapas necessrias para desempenhar o elemento de mtodo criado; Funes: Designa as funes que podem desempenhar o elemento do mtodo, mostrando os executores primrios e executores adicionais e uma breve descrio destes executores; Produtos de Trabalho: Especifica os produtos de trabalho de entrada e sada para este elemento de mtodo, suas entradas opcionais e uma breve descrio dos elementos selecionados; Orientao: Fornece links adicionais na forma de orientao (frum de discusses, listas de verificao); Categorias: Gerencia as categorias s quais este elemento de mtodo pertence (disciplinas); Estimativa: Fornece uma estimativa padro para este elemento de mtodo (em horas) e pode-se selecionar os fatores de estimativa; Visualizar: Visualiza a publicao apenas do elemento de mtodo em questo, onde possvel verificar a situao de todas as alteraes feitas neste elemento na forma de pgina web.

Elemento Funo: Descrio: semelhante ao elemento de mtodo tarefa, mais a opo de definio sobre equipe; Produtos de Trabalho: especifica os produtos de trabalho que este elemento de mtodo responsvel e os produtos de trabalho que so sadas de tarefas que este elemento de mtodo desempenha; Orientao: semelhante ao elemento de mtodo tarefa; Categorias: Gerencia os domnios os quais este elemento de mtodo pertence e define o tipo deste elemento; Visualizar: semelhante ao elemento de mtodo tarefa.

79

Elemento Produto de Trabalho: Descrio: semelhante ao elemento de mtodo tarefa; Orientao: semelhante ao elemento de mtodo tarefa; Categorias: Gerencia os domnios os quais este elemento de mtodo pertence e define o tipo deste elemento; Visualizar: semelhante ao elemento de mtodo tarefa.

6.4

Consideraes sobre o captulo Mostrou-se uma breve descrio da ferramente RMC que serve para configurar e

adaptar o processo de uma maneira conveniente aos usurios do processo, salientando ainda, os objetivos propostos por esta ferramenta. Posteriormente observou-se as configuraes dos elementos de mtodo, onde mostrou-se o procedimento para proceder com a criaco e personalizao destes elementos que esto diretamente ligados a integrao do processo proposto. No prximo captulo apresentamos a integrao proposta nestre trabalho e desenvolvida com o uso da ferramenta RMC.

80

PROCESSSO RUP + PMBOK DE GERNCIA DE ESCOPO

Sendo que foram analisados no captulo 5 os mapeamentos e compatibilidades entre os modelos e no captulo 6 demonstrou-se a ferramenta que possibilita desenvolver a proposta de integrao, o processo RUP + PMBOK de gerncia de escopo apresentado nesta seo. Primeiramente mostramos o planejamento adotado para a integrao dos modelos e suas atividades, assim como os papis envolvidos no processo, posteriormente mostramos a publicao do processo na forma de Web Site utilizando o RMC.

necessrio que seja apresentado um planejamento integrado de atividades pertencentes ao projeto de desenvolvimento de software e aos fluxos de trabalho da organizao referentes ao gerenciamento de escopo do projeto. Conforme , o gerente de projetos pode no possuir todas as informaes relevantes para o projeto e podero ocorrer interaes com outros departamentos da organizao durante o planejamento de um projeto de software. Assim, o fluxo de atividades de um projeto de software pode interagir com os demais fluxos de atividades da organizao. Devemos conceber um processo que possa lidar com uma significativa parte dos aspectos produtivos e gerenciais do desenvolvimento de um produto de software, contribuindo com o aumento da qualidade global do trabalho resultante. A partir dos estudos de mapeamentos e compatibilidades realizados no Captulo 5, possvel darmos incio a integrao do RUP com o PMBOK, permitindo assim que as organizaes e os prprios gerentes de projetos apliquem os conhecimentos gerencias em conjunto com aspectos tcnicos.

7.1

Premissas para a integrao Segundo o [RAT08], para que o processo possa ser adaptado necessrio seguir

as seguintes orientaes: Elemento dos esforos direcionados. Identificar o contedo do mtodo a ser acrescentado ou refinado no RUP. Identificar os ativos do mtodo existente que

81

podem

ser

includos.

Por

exemplo,

orientaes

especficas

organizao/projeto, gabaritos, exemplos, entre outros. outros, que deseja adaptar.

Selecionar os

processos, funes, tarefas, produtos de trabalho, orientao, processos, entre Nveis de Adaptao. H diferentes nveis de adaptao no qual o RUP pode ser adaptado, cada um com um "custo" e "benefcio" associado. Adaptar o processo. Adaptar as partes identificadas do RUP utilizando o nvel de adaptao selecionado. No importa qual o nvel de adaptao que foi escolhido, a adaptao do RUP geralmente envolve quatro etapas principais (embora algumas etapas sejam opcionais, dependendo do nvel de adaptao): Desenvolvimento dos elementos do mtodo. Essa etapa inclui o desenvolvimento de novo contedo e/ou redefinio do contedo existente. Configurar o contedo do mtodo. Inclui decidir qual contedo incluir e qual contedo excluir, bem como fornecer vises apropriadas sobre esse contedo (por exemplo, vises baseadas em funo ou domnios especficos). Configurar o contedo do mtodo uma questo de dimensionamento exato do processo de modo que corresponda s necessidades de uma organizao especfica ou projeto individual. Desenvolver o processo para a configurao. Inclui selecionar um tipo de ciclo de vida de desenvolvimento (por exemplo, em cascata ou repetitivo) e definir um processo que esteja bem afinado para atender s necessidades exatas da organizao ou do projeto. O processo resultante servir como uma entrada direta ao planejamento do projeto. Tornar o processo disponvel. Inclui publicar a configurao (e seu processo) como um Web site do processo, e/ou exportar o processo para uma ferramenta de planejamento do projeto.

7.2

Elementos dos esforos direcionados Nesta seo identificamos o contedo do mtodo a ser excludo, acrescentado ou

refinado no RUP. No caso de nossa integrao nenhum contedo de mtodo dever ser excludo j que a base do processo o RUP e que a ele ser integrado as prticas do PMBOK na rea de gerenciamento de escopo, interessante ainda afirmar que no conveniente que

82

as

caractersticas

principais

do

RUP

sejam

afetadas:

iterativo

incremental

(principalmente). Mas novos elementos de mtodo foram includos para compor o processo de forma integrada e devem ser informados, bem como os elementos de mtodo existentes que foram envolvidos diretamente com a integrao, sendo:

7.2.1 Disciplinas Envolvidas Conforme j exposto no Captulo 5 as disciplinas mapeadas para a integrao entre os modelos RUP e PMBOK so: Gerenciamento de Projetos, Requisitos e Gerenciamento de Configurao e Mudanas. Na Tabela 5 apresentamos uma breve descrio da funo principal da disciplina. Tabela 5 - Descrio das Disciplinas envolvidas na integrao [RAT08]. Disciplina Gerenciamento de Projetos Descrio Esta disciplina enfoca o planejamento do projeto, gerenciamento de riscos, monitoramento do progresso e mtricas. Esta disciplina explica como elucidar os requisitos dos investidores e transform-los em um conjunto de requisitos de Produtos de Trabalho, no escopo do sistema a ser construdo e fornece requisitos detalhados sobre o que faz o sistema. Esta disciplina explica como controlar e sincronizar a evoluo do conjunto de Produtos de Trabalho que compem o sistema de software.

Requisitos

Gerenciamento de Configurao e Mudanas

7.2.2 Papis envolvidos Nesta etapa da pesquisa foram selecionados os papis (funes) do RUP que esto envolvidos diretamente com a gerncia de escopo, sendo resultado dos mapeamentos efetuados entre os modelos RUP e PMBOK. Estes papis so: Coordenador de Projeto, Revisor de Gerenciamento, Gerenciador de Configurao, Analista de Sistemas, Especificador de Requisitos, Revisor Tcnico e Todas as Funes.

83

Figura 23 - Conjunto de Funes: Analista e Funes Gerais

Figura 24 - Conjunto de Funes: Gerenciadores Apresentados os papis envolvidos na Figura 23 e Figura 24, podemos observar que 3 papis compem o conjunto de funes (generalizados): Analista, Funes Gerais e Gerenciadores, os quais possuem atribuies diferenciadas, sendo ento especializados em outros 7 papis j citados anteriormente. Na Tabela 6 apresentamos uma breve descrio das atribuies dos papis envolvidos na integrao do processo RUP e PMBOK. Tabela 6 - Relao do Conjunto de Funes e seus Papis e suas respectivas atribuies [RAT08].

Conjunto de Funes

Papel

Atribuio do Papel
Essa funo planeja, gerencia e aloca recursos, ajusta as prioridades, coordena interaes com clientes e usurios e mantm a equipe do projeto concentrada. O Coordenador de Projetos tambm estabelece um conjunto de prticas que asseguram a integridade e a qualidade dos produtos de trabalho do projeto.

Gerenciadores

Coordenador de Projeto

84

Revisor de Gerenciamento

Gerenciador de Configurao

Analista de Sistemas Analistas Especificador de Requisitos

Revisor Tcnico Funes Gerais Todas as Funes

Essa funo avalia os produtos de trabalho de planejamento e avaliao do projeto, nos principais pontos de reviso do ciclo de vida do projeto. Esta funo gerencia a infraestrutura e o ambiente do Gerenciamento de Configurao (CM) geral para a equipe de desenvolvimento de produto. Essa funo lidera e coordena a obteno de requisitos, delimitando o sistema e definindo sua funcionalidade. Essa funo especifica e mantm os requisitos detalhados do sistema. Essa funo contribui com feedback tcnico sobre produtos de trabalho do projeto. Esse feedback deve ser oportuno e apropriado. Essa funo caracteriza as tarefas que qualquer membro da equipe pode executar.

7.2.3 Atividades envolvidas As atividades envolvidas diretamente com a integrao foram todas criadas com base nas atividades j existentes no RUP, sendo ento diferenciadas visualmente, da seguinte forma: Primeiramente pela cor, sendo a imagem original que representa a atividade na cor amarela e as atividades criadas para a integrao so representadas na cor azul. Posteriormente pelo nome, mais especificamente pela sigla anterior a identificao da atividade, por exemplo, a Figura 25: Para a atividade original Avaliar Iterao tem-se uma atividade criada que chamada AGMC Avaliar Iterao, onde AGMC quer dizer, Atividade Gerencial de Monitoramento e Controle. Definindo ento ao usurio do processo que esta uma Atividade Gerencial (PMBOK), e que do Grupo de Processos de Monitoramento e Controle.

85

Figura 25 - Diferena de Nomenclatura entre as Atividades Importante notar que a identificao da atividade no mudou o que facilita o usurio do processo a identificar pelo nome uma determinada atividade, j que muito provavelmente este usurio deve estar familiarizado com os nomes das atividades no processo RUP original. Todas as atividades criadas para a integrao possuem uma nomenclatura que identifica que uma atividade gerencial e a que grupo de processos de gerenciamento de projetos pertence, conforme a Tabela 7. Tabela 7 - Descrio das Nomenclaturas das atividades criadas Nomenclatura AGI AGP AGEX AGMC AGE Descrio da Nomenclatura Atividade Gerencial de Iniciao Atividade Gerencial de Planejamento Atividade Gerencial de Execuo Atividade Gerencial de Monitoramento e Controle Atividade Gerencial de Encerramento

7.2.4 Artefatos envolvidos Os artefatos envolvidos diretamente com a integrao foram todos criados com base nas sadas das atividades gerenciais geradas para a integrao do RUP + PMBOK. Sendo ento diferenciadas visualmente, da seguinte forma: Primeiramente pela cor, sendo a imagem original que representa o artefato na cor vermelha e os artefatos criados para a integrao so representadas na cor verde. Posteriormente pelo nome, mais especificamente pela sigla anterior a identificao da atividade, por exemplo, a Figura 26: Para o artefato original Plano de Iterao tem-se um artefato criado que chamado PM Estrutura Analtica do Projeto, onde PM quer dizer, que o artefato um artefato PMBOK.

86

Figura 26 - Diferena de Nomenclatura entre os Artefatos Todos os artefatos criados para a integrao possuem uma nomenclatura que identifica que um artefato PMBOK e o mesmo sada/entrada de uma Atividade Gerencial. 7.3 Nveis de adaptao No RUP existem 6 nveis de adaptao disponveis atualmente, relacionados a partir do mais fcil at o mais complexo, nos quais cada nvel inclui o nvel precedente. A seguir na Tabela 8 relacionamos estes nveis com uma breve descrio de cada um. Tabela 8 - Nveis de Adaptao disponveis no RUP [RAT08], [RMC08]. Nveis Nvel 1 Nvel 2 Nvel 3 Nvel 4 Nvel 5 Descrio Documentar o processo adaptado em um documento externo que refere-se a um processo subjacente, assim como qualquer ativo de mtodo personalizado. Personalizar um processo existente de Web site utilizando My RUP e documentos externos. Configurar um processo de Web site a partir de um contedo de mtodo existente utilizando Rational Method Composer. Incluir Orientao na estrutura do mtodo existente utilizando Rational Method Composer. Desenvolver um novo Processo de Entrega (idealmente baseado em Padro de Capacidade disponvel) utilizando Rational Method Composer . Estender a estrutura do mtodo existente com novo contedo de mtodo (ex., Tarefas, Produto de Trabalhos, Funos) utilizando Rational Method Composer. Este nvel , s vezes, conhecido como desenvolvimento de plugin "estrutural". Um plug-in estrutural um plug-in que estende o RUP incluindo/refinando Funes, Tarefas, e/ou Produtos de Trabalho.

Nvel 6

Na integrao proposta por este trabalho necessariamente obrigatrio a criao de novos contedos de mtodo, estendendo assim a estrutura do mtodo. Dessa forma, automaticamente exclui-se a possibilidade de utilizao dos nveis de adaptao de 1 a 5, sendo necessrio o uso do nvel de adaptao de nmero 6.

87

7.4

Adaptar o processo 7.4.1 Desenvolver os elementos de mtodo Parte desta primeira etapa de adaptao j foi apresentada na seo 7.2, no que

refere-se as caractersticas visuais e na nomenclatura utilizada para identificar os elementos de mtodo criados para este processo. Abaixo apresentamos a listagens dos elementos de mtodo, atividade e artefatos (produtos de trabalho) includos no processo.

Atividades AGI Desenvolver Declarao Preliminar do Escopo do Projeto; AGI Desenvolver Termo de Abertura do Projeto; AGI Iniciar Plano de Gerenciamento do Projeto; AGP Desenvolver Declarao do Escopo do Projeto; AGP Atualizar Declarao do Escopo do Projeto; AGP Capturar Glossrio; AGP Atualizar Plano Gerenciamento do Projeto; AGP Planejar Estrutura Analtica do Projeto; AGP Desenvolver Estrutura Analtica do Projeto; AGP Desenvolver Plano Gerenciamento do Escopo; AGP Desenvolver Plano de Resolues dos Problemas; AGP Escrever Plano de Gerenciamento e Configurao (CM); AGMC Desenvolver a Declarao do Escopo do Projeto; AGMC Atualizar Declarao do Escopo do Projeto; AGMC Capturar Glossrio; AGMC Controlar Mudanas; AGMC Avaliar Iteraes; AGMC Planejar Estrutura Analtica do Projeto; AGMC Desenvolver Estrutura Analtica do Projeto; AGMC Relatar Status. Artefatos PM Declarao Preliminar do Escopo do Projeto; PM Declarao do Escopo do Projeto; PM Plano de Gerenciamento do Escopo do Projeto; PM Termo de Abertura do Projeto;

88

PM Plano de Gerenciamento do Projeto; PM Estrutura Analtica do Projeto; PM Dicionrio da Estrutura Analtica do Projeto; PM Linha de Base do Escopo; PM Mudanas Solicitadas; PM Entregas Aceitas; PM Requisitos do Gerenciamento de Configurao e Controle.

7.4.2 Configurar o contedo dos elementos do mtodo Nesta seo apresentaremos especificamente como adaptar os elementos de mtodo e suas caractersticas ao contedo do mtodo, e tambm fornecer as vises apropriadas a este novo elemento de mtodo. Na Figura 27 apresentamos uma situao para deciso de incluso de elementos de mtodos, e definimos a viso destes elementos de mtodo baseados na funo especfica. Neste caso, a funo coordenador de projeto.

Figura 27 - Adaptao dos elementos de mtodo ao processo.

89

Baseando-se nos mapeamentos apresentados no Captulo 5 deste trabalho, determinamos que para a funo Coordenador de Projeto, que desempenha uma atividade descrita como Desenvolver Plano de Iterao e que esta atividade gera um artefato de sada Plano de Iterao, necessrio esta funo uma integrao que permita a incluso de nova atividade, definida como AGP Desenvolver Estrutura Analtica do Projeto e que esta atividade gere um artefato de sada denominado PM Estrutura Analtica. Neste caso descrito na Figura 27, a viso est baseada na funo, ou seja, a funo Coordenador de Projeto agora desempenha uma atividade descrita como AGP Desenvolver Estrutura Analtica do Projeto. Atividade que gera um artefato de sada PM Estrutura Analtica do Projeto. A integrao deste e outros elementos de mtodo podem ser visualizados na seo 6.8 deste captulo de maneira integral na seo visualizao da publicao do processo integrado RUP e PMBOK. Ainda nesta fase necessrio desenvolver/configurar o contedo destes elementos de mtodo, definindo caractersticas e relacionamentos deste elemento dentro do processo. Na Figura 28, podemos observar como devem aparecer as configuraes dos contedos de elementos de mtodo, para facilitar a descrio desta atividade enumeramos as principais caractersticas de configurao, em uma tarefa ainda no adaptada. 1 Informar uma breve descrio do elemento de mtodo, logo depois em nvel de viso de domnio informa a qual disciplina pertence o elemento, na visualizao da integrao (seo 6.8 deste captulo) podemos verificar que foram acrescidos a esta primeira caracterstica a nomenclatura PMBOK seguida do grupo de processos que pertence o elemento de mtodo; 2 Definir qual o objetivo do elemento de mtodo; 3 Definir quais as relaes do elemento de mtodo quanto as funes, se o elemento de mtodo uma tarefa, necessrio definir suas entradas e sadas quanto aos artefatos. Se o elemento de mtodo um artefato necessrio ainda definir suas entradas e sadas quanto as tarefas, definido tambm o uso do elemento de mtodo no processo; 4 Apresentar uma descrio principal do elemento de mtodo;

90

5 Detalhar as etapas do elemento de mtodo a serem desempenhadas para o cumprimento do objetivo; podem ser definidas etapas opcionais;

Figura 28 - Adaptao do contedo dos elementos de mtodo ao processo (Atividade). Alm destas principais caractersticas dependendo do tipo de elemento de mtodo, este pode apresentar alguma caracterstica adicional, como uma categoria contendo exemplos de desenvolvimento do elemento de mtodo. A integrao com a configurao deste e outros contedos de elementos de mtodo podem ser visualizados de maneira integral na seo 6.8 (visualizao da publicao do processo integrado RUP e PMBOK) deste captulo.

91

7.4.3 Tornar o processo disponvel Esta etapa inclui publicar a configurao (e seu processo) como um Web Site do processo, e/ou exportar o processo para uma ferramenta de planejamento do projeto. Para um melhor entendimento desta etapa destinamos a seo 7.5 onde apresentamos de forma detalhada a Publicao da Integrao.

7.5

Visualizao da publicao do processo integrado RUP + PMBOK No Apndice A apresentamos um exemplo da Integrao dos Modelos, onde

exemplificamos as integraes que foram realizadas neste trabalho em forma de uma tabela com todos os elementos, nesta forma de demonstrao temos uma visualizao geral de todos os elementos envolvidos de forma rpida e simples. Nesta seo ilustramos o processo integrado RUP + PMBOK para gerncia de escopo em projetos de desenvolvimento de software, com algumas telas da interface e uma descrio do tipo de integrao. Como so diversas as telas da integrao do processo e as descries das atividades e produtos de trabalho, bem como as vises apresentadas nestes elementos, foi disponibilizado todas as telas no Apndice B. Veremos que o RUP + PMBOK entregue aos profissionais como um Web site interativo utilizando a tecnologia de navegador padro de mercado. Um Web site do RUP + PMBOK uma apresentao do processo publicado do Rational Method Composer, configurada para seu projeto e ajustada para suas necessidades especficas. O Web site criado utilizando pginas HTML geradas dinamicamente, as quais o RMC permite que sejam publicadas na forma de vrios Web sites do RUP + PMBOK, cada um representando uma definio de processo configurada e ajustada. A Figura 29 apresenta a tela inicial do processo RUP que foi estendido com o PMBOK na rea de gerenciamento de escopo. Sendo que para esta tela foi acrescentado uma nomenclatura para designar a integrao [RUP + PMBOK], no restante a tela igual a interface inicial do processo RUP padro.

92

Figura 29 - Tela inicial do processo RUP + PMBOK.

7.5.1 Interface Funes Integrao RUP + PMBOK Na Figura 30 possvel visualizar a funo Coordenador de Projeto e seus

relacionamentos, como as atividades que desempenha e os produtos de trabalho pelos quais responsvel. Observamos que nesta funo que uma das principais nesta integrao, foram adicionados vrias atividades novas relacionadas a gerencia de escopo do PMBOK todas representadas pela nomenclatura AG (Atividade Gerencial) + nomenclatura do grupo de processos + nome da atividade, ainda podemos diferenciar estas das outras atividades por estarem na cor azul. Quase que necessariamente estas atividades produzem produtos de trabalho, os artefatos adicionados esto aqui representados pela nomenclatura PM (PMBOK) + nome do produto de trabalho e ainda podemos diferencia-los dos outros produtos de trabalho por estarem na cor verde.

93

Figura 30 - Integrao RUP + PMBOK - Funo Coordenador de Projeto Na Figura 31, semelhante a figura anterior, apresentamos uma outra funo Analista de Sistemas, e tambm podemos visualizar as atividades que so desempenhadas por esta funo e os produtos de trabalhos que esta funo responsvel, a nomeclatura utilizada para o processo a padronizada j explicada anteriormente, na figura podemos visualizar vrias atividades incorporadas a esta funo e os seus artefados.

Figura 31 - Integrao RUP + PMBOK - Funo Analista de Sistemas Todas as interfaces do conjunto de funes que esto diretamente ligados a integrao podem ser encontrados no Apndice B.

94

7.5.2 Interface Atividade Integrao RUP + PMBOK Na Figura 32, apresentado a tela de uma atividade desempenhada pelo Coordenador do Projeto, atividade chamada AGP (Atividade Gerencial + Planejamento) Desenvolver Estrutura Analtica do Projeto.

Figura 32 - Integrao RUP + PMBOK - Atividade: AGP- Desenvolver a EAP Podemos observar nesta atividade que ela possui a descrio de seu nome e a que grupo de disciplinas pertence, possui ainda a descrio do seu objetivo a informao

95

de sua descrio principal e quais as etapas necessrias para desenvolver esta atividade, possu uma opo para a insero de exemplos, neste caso foram utilizados arquivos externos no formato PDF. Possui a informao de todos os seus relacionamentos, como: quem o seu executor primrio e quem so seus executores adicionais, quais os produtos de trabalho so obrigatrios para esta atividade e quais os produtos de trabalhos que so opcionais, informa tambm quais so os produtos de trabalho que so sadas desta atividade.

Figura 33 - Integrao RUP + PMBOK - Atividade: AGP- Captar Glossrio A Figura 33 semelhante a figura anterior, nela demonstrado a tela de uma atividade desempenhada pelo Analista de Sistemas, atividade chamada AGP (Atividade Gerencial + Planejamento) Captar Glossrio. Todas as interfaces das atividades que esto diretamente ligados a integrao podem ser encontrados no Apndice B.

7.5.3 Interface Produto de Trabalho Integrao RUP + PMBOK Na Figura 34, apresentado a tela de um produto de trabalho que sada de uma atividade desempenhada pelo Coordenador do Projeto, produto de trabalho chamado PM

96

(PMBOK) Estrutura Analtica do Projeto. Semelhante aos outros elementos de mtodo apresentados a figura apresenta as caractersticas especficas deste produto de trabalho, como: definio, a que domnio pertence, tipo do produto de trabalho, objetivo e descrio principal.

Figura 34 - Integrao RUP + PMBOK - Produto de Trabalho: PM-EAP Ainda podemos visualizar as informaes de relacionamentos deste produto de trabalho com os elementos do mtodo, como: quem responsvel pelo produto de trabalho, quem pode modific-lo, para quais tarefas este produto de trabalho entrada e de quais tarefas este produto de trabalho sada. A Figura 35, semelhante a figura anterior, nela apresentado a tela de um produto de trabalho que sada de uma atividade desenvolvida pelo Analista de Sistema, produto de trabalho chamado PM (PMBOK) Projeto. Declarao Preliminar do Escopo do

97

Figura 35 - Integrao RUP + PMBOK - Produto de Trabalho: Declarao Preliminar do Escopo do Projeto Todas as interfaces dos produtos de trabalho que esto diretamente ligados a integrao podem ser encontrados no Apndice B.

7.6

Consideraes sobre o captulo Neste Captulo foi apresentado o processo proposto para a integrao dos

modelos, suas atividades e as premissas necessrias para a adaptao. Verificou-se ainda os elementos que so diretamente afetados pela integrao, como as disciplinas, papis envolvidos, atividades e artefatos. Dentro deste planejamento foi definido o nvel de adaptao que o processo deveria ter e qual o motivo da utilizao deste nvel de adaptao. Por fim, mostra-se a publicao da integrao RUP + PMBOK para gerenciamento do escopo de projetos de desenvolvimento de software, elementos de mtodos criados e

98

devidamente configurados foram apresentados j integrados ao processo RUP, demonstrando de forma simples como a integrao favorece o gerenciamento por parte do gerente de projetos. Como so vrias as telas da integrao convencionou-se demonstrar a integrao completa no Apndice B. E no prximo captulo veremos o fluxo para o desenvolvimento de projetos de software criado integrando o RUP + PMBOK que pode ser seguido utilizando o processo que foi gerado neste trabalho.

99

EXEMPLO DE USO

Neste Captulo demonstramos um exemplo de uso do processo de desenvolvimento de software, criando um fluxo entre o RUP, Processo de Desenvolvimento de Software do Projeto (PDSP) e o PMBOK especificamente na rea de gerenciamento de escopo e integrao.

8.1

Fluxo de processo de desenvolvimento de software Para ilustrar o uso processo integrado RUP + PMBOK criou-se um fluxo de

processo de desenvolvimento de software, onde atravs desse podemos identificar as fases do RUP, sendo que dentro de cada fase apresentado o detalhamento dos processos do PMBOK na rea de gerenciamento de escopo e integrao.

Figura 36 - Fluxo PDS - PMBOK + RUP Fase Iniciao Pgina 1

100

Figura 37 - Fluxo PDS - PMBOK + RUP Fase Iniciao Pgina 2 Dentro do detalhamento de cada item dos processos do PMBOK temos o processo de desenvolvimento de software do projeto, este fluxo fornece a base para o planejamento, desempenho e aperfeioamento das atividades gerenciais e tcnicas que as tarefas do projeto executam. Nas Figura 37 e 37 temos o fluxo das atividades da fase iniciao do RUP. Dentro desta fase temos vrios processos do PMBOK especificamente da rea de gerenciamento de escopo e integrao sendo executados em conjunto com o processo de desenvolvimento de software do projeto. Nas Figuras abaixo de nmero 38 e 39 temos o fluxo das atividades da fase elaborao do RUP. Dentro desta fase temos vrios processos do PMBOK especificamente da rea de gerenciamento de escopo e integrao sendo executados em conjunto com o processo de desenvolvimento de software do projeto.

101

Figura 38 - Fluxo PDS - PMBOK + RUP Fase Elaborao Pgina 3

Figura 39 Fluxo PDS - PMBOK + RUP Fase Elaborao Pgina 4

102

Figura 40 - Fluxo PDS - PMBOK + RUP Fase Construo Pgina 5

Figura 41 - Fluxo PDS - PMBOK + RUP Fase Construo Pgina 6

103

Nas Figura 40 temos o fluxo das atividades da fase construo do RUP. Dentro desta fase temos vrios processos do PMBOK especificamente da rea de gerenciamento de escopo e integrao sendo executados em conjunto com o processo de desenvolvimento de software do projeto.

Figura 42 - Fluxo PDS - PMBOK + RUP Fase Transio Pgina 7 Nas Figura 42 temos o fluxo das atividades da fase transio do RUP. Dentro desta fase temos vrios processos do PMBOK especificamente da rea de gerenciamento de escopo e integrao sendo executados em conjunto com o processo de desenvolvimento de software do projeto. Em todas as fases do projeto de desenvolvimento de software notamos processos de controle que aparecem no fluxo que asseguram ao mximo a qualidade das atividades que esto sendo desenvolvidas na fase. A numerao dos itens que aparecem nos processos PMBOK do fluxo fazem referncia ao nmero do processo em: Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos 3 Edio Guia PMBOK. A publicao do processo RUP + PMBOK (Web Site) est adaptado a fim de servir como base ao gerente de projetos e sua equipe utilizar tanto as prticas de atividade gerencial como as atividades tcnicas no gerenciamento de escopo para projetos de

104

desenvolvimento de software. O processo constante no fluxo deste exemplo de uso pode ser consultado no processo RUP + PMBOK para que sejam seguidas as diretrizes propostas pela adaptao.

Figura 43 - Fluxo PDS - PMBOK + RUP Fase Transio Pgina 8 8.2 Consideraes sobre o captulo O fluxo para desenvolvimento de projetos de software criado neste captulo, demonstra os processos referentes as reas de gerenciamento de escopo e integrao do PMBOK sendo executados dentro das fases de desenvolvimento do RUP de uma forma integrada. Tanto as atividades gerenciais e tcnicas que aparecem no fluxo ao serem desenvolvidas precisam seguir um processo tambm integrado, sendo recomendado o processo RUP + PMBOK para gerenciamento de escopo. Os processos nos fluxos referem-se apenas as reas de conhecimento de gerncia de escopo e integrao do PMBOK, mas para um fluxo completo tem-se que integrar todos processos PMBOK ao processo de desenvolvimento de software, o que de extrema relevncia, no entanto, este no o objetivo deste trabalho.

105

CONSIDERAES FINAIS

Este captulo apresenta as consideraes finais deste trabalho destaca ainda, as contribuies, limitaes do estudo e os rumos para futuras pesquisas na rea.

Segundo [Sch02], as organizaes da rea de tecnologia, entendendo as dificuldades da rea em realizar projetos bem sucedidos, isto , projetos que respeitem as restries e objetivos impostos durante o seu planejamento, buscaram, nos ltimos anos, subsdios para diminuir os ndices de fracasso. Vrias aes foram tomadas, sendo a principal delas a utilizao de metodologias de gerenciamento de projetos como o PMBOK Guide [Pmi04] ou o PRINCE2 [Ogc05], [HAR05] e [SIE04]. O sucesso de um projeto est intimamente ligado a assegurar que o projeto vai satisfazer as necessidades para as quais foi criado, ou seja, gerenciar a qualidade. Isso envolve levantar em detalhes e especificar formalmente as necessidades explcitas e implcitas dos clientes, usurios e outras partes importantes interessadas, valid-los com essas partes e comprometer-se a entregar o que foi especificado (nada mais) [Sot07]. A crescente preocupao relativa ao desenvolvimento de software pode ser observada devido adoo de prticas de engenharia de software pelas empresas. O desenvolvimento de produtos de software requer o planejamento e a execuo de atividades, definidas de acordo com o escopo do projeto, onde necessrio lidar tanto com assuntos gerenciais quanto tcnicos. Em qualquer contexto deve-se considerar o fato de que projetos sempre so esforos nicos e temporrios, alm de envolverem um elevado nvel de incerteza [Pre01], e [CAL07]. Assim, percebe-se que o escopo do projeto ponto crucial em seu desenvolvimento e que extremamente relevante gerenciarmos atividades relacionadas a assuntos especificamente gerenciais e atividades relacionadas a assuntos tcnicos voltadas ao desenvolvimento do produto de maneira integrada. Autores como [Pre01], [Sch02], [CHA04], [COT04], [Sot07], e [CAL07], pesquisam e trabalham neste contexto para que possamos garantir um desenvolvimento de software de maior qualidade e um aumento das taxas de sucesso dos projetos de software.

106

Ento, atravs da realizao deste trabalho pode-se refletir de que forma as organizaes de desenvolvimento de software poderiam gerenciar o escopo de projetos de software utilizando um modelo de gerenciamento de projetos e um processo de desenvolvimento de software em um mesmo processo de forma integrada. Dessa maneira chegou-se proposta de um processo integrado RUP + PMBOK para gerncia de escopo em projetos de desenvolvimento de software. Esse descrito no captulo 6 deste trabalho. As sees seguintes descrevem os resultados da pesquisa, as contribuies tericas e prtica do trabalho para a rea, as limitaes de pesquisa e, finalmente, as sugestes de trabalhos futuros.

9.1

Resultados da pesquisa Os objetivos propostos inicialmente, descritos no captulo 1, foram alcanados. O

objetivo geral do trabalho foi atendido pelo processo proposto apresentado no captulo 7, que propunha uma forma de gerenciar o escopo dos projetos de software de forma integrada com o RUP + PMBOK. Em relao aos objetivos especficos as referncias consultadas nas reas de gerncia de projetos, gerenciamento de escopo de projetos, processo de desenvolvimento de software, foram apresentadas no captulo 2, e os trabalhos relacionados que muito contriburam para esta proposta foram elencados no captulo 3, os quais proporcionaram a expanso do conhecimento para a integrao entre RUP + PMBOK e a formalizao desse entendimento no processo proposto. A integrao s foi possvel por ser antecedida de uma anlise de compatibilidade entre os modelos realizada no captulo 5, gerando um mapeamento entre os mesmos que serviu de base para todo o processo. No captulo 6 demonstrou-se a ferramenta de publicao e personalizao de processos RMC que proporcionou a customizao e integrao do processo proposto de forma satisfatria. No processo proposto, descrito no captulo 7 desse trabalho, o foco est no auxlio ao gerente de projetos para que ao executar as fases do processo de desenvolvimento de software possa utilizar das atividades gerencias do modelo de gesto de projetos, especificamente na rea de gerenciamento de escopo e integrao.

107

Finalmente foi apresentado atravs da criao de um fluxo de processo de desenvolvimento de software um exemplo de uso para a utilizao do processo proposto, apresentado no captulo 8.

9.2

Contribuies Este trabalho oportunizou pesquisar um processo de desenvolvimento de software

e um modelo de gesto para gerenciamento de projetos, apresentando uma proposta de integrao entre estes, denominada RUP + PMBOK. Em funo da integrao proposta foi desenvolvido um processo de gerenciamento de escopo para projetos de software, que permite elaborar uma viso mais ampla de como a rea de gerenciamento de escopo em projetos pode contribuir de maneira positiva com o desenvolvimento de um produto de software.

9.2.1 Terica Acredita-se que este trabalho contribua com a rea de cincia da computao, nas subreas de engenharia de software e gerenciamento de projetos de desenvolvimento de software, ampliando as publicaes acerca destas reas. Tambm acredita-se que o estudo fornece uma viso complementar de integrao de um modelo de gesto de projetos e um processo de desenvolvimento de software. Espera-se que algumas lacunas sobre o tema integrao de processos, no mnimo, sejam parcialmente cobertas pelo processo proposto, de forma que o estudo do processo fornea subsdios para o desenvolvimento de processos de software. Estes, integrados as melhores prticas de gesto de projetos, contribuindo para uma melhor produtividade das demandas nesta rea pelas organizaes de tecnologia.

9.2.2

Prtica

Tendo em vista a complexidade do processo de desenvolvimento de software que integre questes gerenciais e tcnicas, so necessrios mecanismos de apoio para guiar os gerentes no planejamento e controle desses projetos. Supe-se que o processo proposto neste estudo possa apoiar os gestores nas reas de sistemas de informao permitindo o planejamento integrado de atividades gerenciais e tcnicas.

108

A biblioteca com o processo RUP + PMBOK est disponvel para que os gestores de projetos possam utilizar-se de sua estrutura e mtodo aplicando as melhores prticas em projetos reais de desenvolvimento de software. Alm disso, a biblioteca do processo proposto est disponvel servindo de modelo para que os gestores faam a personalizao e integrao das atividades de acordo com o padro utilizado em suas organizaes.

9.3

Limitaes da pesquisa Com base no mtodo de pesquisa adotado, descrito no captulo 4, a pesquisa

qualifica-se como um estudo qualitativo, o que no nos permite a generalizao dos resultados. O mtodo de pesquisa, descrito no captulo 4, previa a demonstrao do processo atravs da realizao de um estudo de caso, j no desenvolvimento do seminrio de andamento foi detectado que no haveria possibilidade da aplicao deste mtodo pelos seguintes motivos: No existem empresas locais (Tangar da Serra MT) que utilizam o processo de desenvolvimento de software escolhido para o estudo e pesquisa deste trabalho; O tempo necessrio para a implantao primeiramente do processo de desenvolvimento de software escolhido e posteriormente o processo proposto neste estudo no era suficiente, dada limitao imposta pelo cronograma deste trabalho.

9.4

Estudos futuros Apesar dos objetivos propostos inicialmente terem sido alcanados, identificou-se

oportunidades de estudos futuros com possibilidades de avanar a pesquisa no sentido de avaliar o processo proposto, as quais so apresentadas a seguir: Realizao de mltiplos estudos de caso, e aplicao do processo proposto em diferentes organizaes, permitindo que o grau de generalizao dos resultados seja ampliado;

109

Desenvolvimento de um protocolo para a avaliao do processo proposto com empresas de software, utilizando o processo em projetos reais; Ampliao da integrao entre todas as reas de conhecimento do modelo de gesto de projetos PMBOK e o processo de desenvolvimento de software RUP; Criao de um fluxo de processo de desenvolvimento de software completo para demonstrar o uso da integrao entre todas as reas de conhecimento do modelo de gesto de projetos PMBOK e o processo de desenvolvimento de software RUP.

110

REFERNCIAS BIBLIOGRFICAS

[Bar06]

Barbosa, A. L. Anlise comparativa de metodologias para o gerenciamento de projetos de desenvolvimento de software. Dissertao de Mestrado. Faculdade de Engenharia Eltrica e de Computao, UNICAMP, 2006, 135p.

[Bar07]

Barcaui, A. B.; Borba, D. B.; Silva, I. M.; Neves, R. B. Gerenciamento do tempo em projetos. Rio de Janeiro:Editora FGV, 2007, 168p.

[CAL07]

Callegari, D.; Bastos, R. M. Project Development Processes: 8.

Management

and

Software ICSEM

Integrating RUP

and PMBOK. In:

International Conference on Systems Engineering and Modeling, 2007, pp. 1-

[CHA04]

Charbonneau, S. Software Project Management -- A Mapping between RUP and the PMBOK. The Rational Edge, IBM, 2004, pp. 45-76.

[COT04]

Cottrell, W. Standards, compliance, and Rational Unified Process, Part I: Integrating RUP and the PMBOK. The Rational Edge, IBM, 2004, pp. 77-86.

[Din05]

Dinsmore, P. C.; Neto, F. H. S. Gerenciamento de Projetos Como Gerenciar seu Projeto com Qualidade, dentro do Prazo e Custos Previstos. Rio de Janeiro:QualityMark Editora Ltda, 2005, 150 p.

[GIR05]

Giraffa, L. M. M.; Marczak, S.; Prikladnicki, R. PDS-E: Em direo a um processo para desenvolvimento de Software Educacional. In: XXV Congresso da Sociedade Brasileira de Computao, 2005, 9p.

[Gra97]

Graham, I.; Henderson-Sellers 314p.

B.; Younessi, H. The OPEN Process

Specification. New York: ACM Press/Addison-Wesley Publishing Co, 1997,

[HAR05]

Harpam, A. O que PRINCE2?. Revista Mundo Project Management, vol. 02-15, Fev 2005, pp. 20-23.

[Hel03]

Heldman, K. Gerncia de Projetos: Guia para o exame oficial do PMI. Rio de Janeiro:Campus, 2003, 580p.

[IKE06]

Ikeda, J. T. The Curse of Project Management. In: PMI Global Congress-North America, 2006, 9p.

111

[INT07]

Integrao Nacional. Estudo de Benchmarking em Gerenciamento de Projetos Brasil 2007, Project Management Institute Chapters Brasileiros. Capturado em: http://www.pmi.org.br/, Janeiro 2008.

[Jac99]

Jacobson, I.; Booch G.; Rumbaugh J. The Unified Software Development Process. Addison Wesley, 1999, 463p.

[Ker06]

Kerzner,

H.

Gesto

de

Projetos:

As

Melhores

Prticas.

Porto

Alegre:Bookman, 2006, 821p. [Kru03] Kruchten, P. Introduo ao RUP Rational Unified Process. Rio de Janeiro:Cincia Moderna, 2003, 255p. [Mar02] Martins, J. C. C. Gesto de Projetos de Desenvolvimento de Software. Rio de Janeiro:Brasport, 2002, 336 p. [Ogc05] Office Government Commerce. Managing Sucessuful Projects with

PRINCE2. London:The Stationery Office, 2005, 471p. [PIN87] Pinto, J. K.; Slevin, D. P. Critical factors in successful project

implementation. IEEE Transactions on Engineering Management. New York: IEEE Engineering Management Society, vol. 34, Feb 1987, pp. 2227. [Pre01] Pressman, R. Software Engineering: a practitioners approach.

Boston:McGraw-Hill, 2001, 888p. [PRI03] Prikladnicki, R. MuNDDoS Um Modelo de Referncia para

Desenvolvimento de Distribudo de Software. Dissertao de Mestrado, Programa de Ps-Graduao em Cincia da Computao, PUCRS, 2003, 144p. [Pmi04] PMI. PMBOK Um Guia do Conjunto de Conhecimentos em Gesto de Projetos. Pennsylvania:Project Management Institute, 2004, 405p. [RAT01] Rational Software White Paper. Rational Unified Process: Best Practices for Software Development Teams. Cupertino: Rational Software Corporation, 2001, 18p. [RAT02] Rational Software White Paper. Utilizando o Rational Unified Process para Pequenos Projetos: Expandido no eXtreme. Cupertino: Rational Software Corporation, 2002, 16p. [RAT08] Rational Process Unified. Base Plug-in. Verso 7.0.1. Capturado em: www.ibm.com/software/rational, Dezembro 2008.

112

[RMC08]

Rational Method Composer.

IBM Rational Method Composer 7.5.0.

Capturado em: www.ibm.com/software/rational, Dezembro 2008. [ROS08] Rosito, M. C. Um Modelo de Integrao entre a Gerncia de Projetos e o Processo de Desenvolvimento de Software. Dissertao de Mestrado, Programa de Ps-Graduao em Cincia da Computao, PUCRS, 2008, 142 p. [San00] Santos, Antonio R. dos. Metodologia cientfica: a construo do

conhecimento. Rio de Janeiro:DP&A editora, 2000, 190p. [Sch02] Schwalbe, K. Information Technology Project Management. Course Technology, 2002, 561p. [SIE04] Siegelaub, J. M. How PRINCE2 Can Complement PMBOK and Your PMP. In: Paper Originally published as a part of 2004 PMI Global Congress Proceeddings, 2004, 7p. [SIL07] Silva, J.; Viana, T.; Rodrigues, L.; Morais, F.; Zanata, G.; Leonardo, H.; Ageu, J.; Rangel, R.; Madruga, R.; Bezerra, S. Aderncia de um Processo Pesado (RUP) a um Modelo de Qualidade (MPS.BR). Revista Cientifica Tecnologus, vol. 2, Ago 2007, 10p. [Som04] Sommerville, I. In Software Engineering. Addison-Wesley Longman Publishing Co., 2004, 606p. [Sot07] Sotille, M. A.; Menezes, L. C. de M.; Xavier, L. F. da S.; Pereira, Mrio Luis Sampaio. Gerenciamento do Escopo em Projetos. Rio de Janeiro:Editora FGV, 2007, 152p. [Sot07a] Sotille, M. A. Gerenciamento de Projetos na Engenharia de Software. Capturado em: http://www.pmtech.com.br/artigos.html, Maro 2008. [STA94] The Standish Group International. 1994 Chaos Report. Capturado em: http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf, Maro 2008. [STA04] The Standish Group International. 2004 Chaos Report. Capturado em: http://www.standishgroup.com/sample_research/PDFpages/q3-spotlight.pdf, Maro 2008. [TEM08] Temnenco, V. A Project Manager's RUP in review. The Rational Edge, IBM, 2008, pp. 23-31.

113

[Yin05]

Yin,

R. K. Estudo

de

caso:

planejamento

mtodos. Porto

Alegre:Bookman, 2005, 212p.

114

APNDICE A DEMONSTRAO DA INTEGRAO DOS MODELOS

Disciplina RUP

Funo do RUP Afetada

Atividade do RUP Afetada

PMBOK / Ferramentas e Tcnicas

Artefato do RUP Afetado

PMBOK / Sadas

Grupo de Processos PMBOK INICIAO - Metodologia de Gerenciamento de Projetos - Sistema de Informaes do Gerenciamento de Projetos - Opinio Especializada - Metodologia de Gerenciamento de Projetos - Sistema de Informaes do Gerenciamento de Projetos - Opinio Especializada - Metodologia de Gerenciamento de Projetos - Sistema de Informaes do Gerenciamento de Projetos - Opinio Especializada

Gerenciamento de Projeto

Coordenador de Projeto

Desenvolver Caso de Negcio

Caso de Negcio

- Termo de Abertura do Projeto

Gerenciamento de Projeto

Coordenador de Projeto

Iniciar Projeto

Plano de Desenvolvimento de Software

- Plano de Gerenciamento do Projeto

Requisitos

Analista Sistemas

de

Desenvolver Plano de Gerenciamento de Requisitos

Plano Gerenciamento Requisitos

de de

- Declarao do Escopo Preliminar do Projeto

Grupo de Processos PMBOK PLANEJAMENTO Gerenciamento de Projeto Coordenador de Projeto Desenvolver Caso de Negcio Compilar Plano de Desenvolvimento de Software Desenvolver Plano de Resoluo do Problema - Opinio Especializada - Modelos, Formulrios, Normas - Metodologia de Gerenciamento de Projetos - Sistema de Informaes do Gerenciamento de Projetos - Opinio Especializada - Opinio Especializada Modelos, formulrios, normas

Caso de Negcio

- Plano de Gerenciamento do Escopo do Projeto

Gerenciamento de Projeto

Coordenador de Projeto

Plano de Desenvolvimento de Software Plano de Resoluo de Problemas

- Plano de Gerenciamento do Projeto (atualizaes)

Gerenciamento de Projeto

Coordenador de Projeto

- Plano de Gerenciamento do Escopo do Projeto (atualizaes) - Mudanas Solicitadas

115 Gerenciamento de Projeto Coordenador de Projeto Desenvolver Plano de Iterao - Modelos da Estrutura Analitica do Projeto - Decomposio - Modelos da Estrutura Analitica do Projeto - Decomposio - Analise de Produtos - Identificao de Alternativas - Analise de Produtos - Identificao de Alternativas - Analise de Produtos - Identificao de Alternativas - Analise de Produtos - Identificao de Alternativas Anlise das Partes Interessadas - Analise de Produtos - Identificao de Alternativas Anlise das Partes Interessadas - Opinio Especializada Modelos, formulrios, normas Modelos, normas formulrios, Plano de Iterao - Estrutura Analtica do Projeto - Dicionrio da EAP - Estrutura Analtica do Projeto - Dicionrio da EAP - Declarao do Escopo do Projeto (atualizaes) - Linha de Base do Escopo - Declarao do Escopo do Projeto (atualizaes)

Gerenciamento de Projeto

Coordenador de Projeto Analista Sistemas Analista Sistemas Analista Sistemas de de de

Planejar Fases e Iteraes Desenvolver Plano de Gerenciamento de Requisitos Desenvolver a Viso Localizar atores e casos de uso Detalhar um caso de uso Detalhar requisitos software os de

Plano de Desenvolvimento de Software Plano Gerenciamento Requisitos Viso Viso de de

Requisitos Requisitos Requisitos

- Declarao do Escopo do Projeto - Declarao do Escopo do Projeto

Requisitos

Especificador de Requisitos

Caso de Uso

- Declarao do Escopo do Projeto

Requisitos

Especificador de Requisitos Analista Sistemas de

Especificao Requisitos Software Glossrio Plano gerenciamento configurao

de de

- Declarao do Escopo do Projeto

Requisitos Configurao e Gerenciamento de Mudanas

Gerenciador de Configurao

Captar um vocabulrio comum Escrever Plano de Gerenciamento de Configurao (CM)

- Plano de Gerenciamento do Escopo do Projeto de de

- Requisitos do Gerenciamento de Configurao e Controle * Declarao do Escopo do Projeto

Grupo de Processos PMBOK EXECUO Gerenciamento de Projeto Coordenador de Projeto

Relatar Status

- Inspeo

Avaliao de Status

- Declarao do Escopo do Projeto (atualizaes)

Grupo de Processos PMBOK MONITORAMENTO E CONTROLE Verificar se os objetivos foram alcanados com xito

Gerenciamento de Projeto

Revisor de Gerenciamento

Reviso de Marco de Ciclo de Vida

- Inspeo

- Entregas Aceitas

116 Requisitos Gerenciamento de Projeto Revisor Tcnico Coordenador de Projeto Revisar Requisitos Relatar Status - Inspeo - Inspeo - Inspeo - Sistema de Controle Mudanas - Analise da Variao - Replanejamento - Inspeo - Sistema de Controle Mudanas - Analise da Variao - Replanejamento - Inspeo - Sistema de Controle Mudanas - Analise da Variao - Replanejamento - Inspeo - Sistema de Controle Mudanas - Analise da Variao - Replanejamento - Inspeo - Sistema de Controle Mudanas - Analise da Variao - Replanejamento - Inspeo - Sistema de Controle Mudanas - Analise da Variao - Replanejamento - Inspeo - Sistema de Controle Mudanas - Analise da Variao - Replanejamento - Inspeo - Sistema de Controle Mudanas - Analise da Variao - Replanejamento Registro de Reviso Avaliao de Status - Mudanas Solicitadas - Aes Corretivas Recomendadas - Declarao do Escopo do Projeto (atualizaes)

Gerenciamento de Projeto

Coordenador de Projeto

de

Avaliar Iterao

Avaliao Iterao

de

- Declarao do Escopo do Projeto (atualizaes) - Estrutura Analtica do Projeto (atualizaes) - Dicionrio da EAP (atualizaes)

Gerenciamento de Projeto

Coordenador de Projeto

Desenvolver Plano de Iterao

de Plano de Iterao

- Declarao do Escopo do Projeto (atualizaes) - Estrutura Analtica do Projeto (atualizaes) - Dicionrio da EAP (atualizaes)

Gerenciamento de Projeto

Coordenador de Projeto

Planejar Fases e Iteraes

de

Plano de Desenvolvimento de Software

- Declarao do Escopo do Projeto (atualizaes) - Estrutura Analtica do Projeto (atualizaes) - Dicionrio da EAP (atualizaes)

Requisitos

Analista Sistemas

de

Desenvolver Viso

de Viso

- Declarao do Escopo do Projeto (atualizaes)

Requisitos

Analista Sistemas

de

Localizar atores e casos de uso

de Viso

- Declarao do Escopo do Projeto (atualizaes)

Requisitos

Especificador de Requisitos

Detalhar um caso de uso

de Caso de Uso

- Declarao do Escopo do Projeto (atualizaes)

Requisitos

Especificador de Requisitos

Detalhar requisitos software

os de

de

Especificao Requisitos Software

de de

- Declarao do Escopo do Projeto (atualizaes)

Requisitos

Analista Sistemas

de

Captar vocabulrio comum

um

de Glossrio - Plano de Gerenciamento do Escopo do Projeto

117 Configurao e Gerenciamento de Mudanas Configurao e Gerenciamento de Mudanas Todas Funes Todas Funes as Enviar Controle de Mudanas Atualizar Controle de Mudanas - Sistema de Controle de Mudanas - Sistema de Controle de Mudanas Controle mudanas Controle mudanas de - Mudanas Solicitadas - Aes Corretivas Recomendadas - Linha de Base do Escopo (atualizaes) - Mudanas Solicitadas - Aes Corretivas Recomendadas - Linha de Base do Escopo (atualizaes)

as

de

118

APNDICE B PUBLICAO COMPLETA DA INTEGRAO

CONJUNTO DE FUNES

Figura 44 - Integrao RUP + PMBOK - Funo Coordenador de Projeto

Figura 45 - Integrao RUP + PMBOK - Funo Analista de Sistemas

119

Figura 46 - Integrao RUP + PMBOK - Funo Gerenciador de Configurao

Figura 47 - Integrao RUP + PMBOK - Funo Gerenciador de Controle de Mudanas

Figura 48 - Integrao RUP + PMBOK - Funo Especificador de Requisitos

Figura 49 - Integrao RUP + PMBOK - Funo Coordenador de Reviso

120

Figura 50 - Integrao RUP + PMBOK - Funo Revisor de Gerenciamento

Figura 51 - Integrao RUP + PMBOK - Funo Todas as Funes

121

ATIVIDADES

Figura 52 - Integrao RUP + PMBOK - Atividade: AGI - Desenvolver Declarao Preliminar do Escopo do Projeto

122

Figura 53 - Integrao RUP + PMBOK - Atividade: AGI Desenvolver Termo de Abertura do Projeto

123

Figura 54 - Integrao RUP + PMBOK - Atividade: AGI - Iniciar Plano de Gerenciamento do Projeto

124

Figura 55 - Integrao RUP + PMBOK - Atividade: AGP- Desenvolver a EAP

125

Figura 56 - Integrao RUP + PMBOK - Atividade: AGP- Captar Glossrio

126

Figura 57 - Integrao RUP + PMBOK - Atividade: AGP- Escrever Plano de Gerenciamento e Configurao CM

127

Figura 58 - Integrao RUP + PMBOK - Atividade: AGP- Desenvolver Plano do Gerenciamento do Escopo do Projeto

128

PRODUTOS DE TRABALHO

Figura 59 - Integrao RUP + PMBOK - Produto de Trabalho: PM - EAP

129

Figura 60 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Declarao Preliminar do Escopo do Projeto

130

Figura 61 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Dicionrio da EAP

131

Figura 62 - Integrao RUP + PMBOK - Produto de Trabalho: PM Linha de Base do Escopo

Figura 63 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Mudanas Solicitadas

132

Figura 64 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Plano de Gerenciamento do Projeto

133

Figura 65 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Termo de Abertura do Projeto

134

Figura 66 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Plano de Gerenciamento de Escopo do Projeto

135

Figura 67 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Requisitos do Gerenciamento de Configurao e Controle

136

Figura 68 - Integrao RUP + PMBOK - Produto de Trabalho: PM - Declarao do Escopo do Projeto

137

ANEXO A SOLICITAO DE ALTERAO DE ESCOPO

Solicitao de Mudana
Data 19/03/2009 Nome do Projeto xxxxxxxxxxxxxx Coordenador do Nome rea - empresa Projeto Num. 014 Solicitao

Detalhamento da Solicitao
Descrio da xxxxxxxxxxxxxx Mudana Motivo da xxxxxxxxxxxxxxxxxxx Mudana Abordagem da xxxxxxxxxxxxxx Mudana Importncia da Impede a continuidade do projeto Mudana Dificulta a continuidade do projeto
Aumenta as atividades do projeto

Limita a utilidade do produto final Melhora a qualidade dos produtos Amplia a relao de produtos

Anlise de Impacto da Solicitao

Espao reservado para o Coordenador do Projeto descrever a anlise de impacto da mudana requerida. vivel Sim, xxxxxxxxxxxxx. tecnicamente? Impacto de esforo nn horas, e custo de R$ nnnnn com pagamento nico em 01/01/2010. (horas) Impacto de prazo (dias) Impacto na xxxxxxxx. qualidade do projeto? Impacto na xxxxxxxxx. alocao de recursos humanos? Impacto em outros xxx. projetos? Outros impactos? xxxxxxxxxxx.

Parecer do Coordenador do Projeto

Xxxxxxxx xx xxxxxxxxxxxxxxxxxxxxxxxxxxxx x x.

Deciso sobre a solicitao

Espao reservado para o Comit do Projeto deliberar sobre fazer ou no fazer a mudana requerida. Justificativa: Aprovada sem restries xxxxxxxxxxxxxxxxxx Aprovada com restries
Negada Cancelada Suspensa temporariamente

Data da Nn/nn/nnnn Deliberao

Participantes Xxxxxxxxxxxxxxxxxxx / xxxxxxxxxxxxxxxxx / da deciso xxxxxxxxxxx