FACULDADE LOURENO FILHO CINCIA DA COMPUTAO

Thiago Coelho Gomez

GERENCIAMENTO DE RISCOS UTILIZANDO O PMBOK

FORTALEZA, 2010

ii

Thiago Coelho Gomez

GERENCIAMENTO DE RISCOS UTILIZANDO O PMBOK

Monografia apresentada ao Curso de Cincia da Computao da Faculdade Loureno Filho, como requisito parcial para obteno do grau de Bacharel em Cincia da Computao. Orientador: Prof. MSc.Emanuel Ferreira Coutinho

Fortaleza, 2010

iii

Thiago Coelho Gomez

GERENCIAMENTO DE RISCOS UTILIZANDO O PMBOK

Monografia apresentada ao curso de Bacharel em Cincia da Computao, da Faculdade Loureno Filho, como parte dos requisitos para a obteno do grau de Bacharel em Cincia da Computao. Aprovada em: ____/_____2010 Conceito obtido: ______________

Composio da Banca Examinadora:

_______________________________________ Prof. MSc. Emanuel Ferreira Coutinho (Orientador)

_______________________________________ Prof. MSc. Andr Barros Pereira

_______________________________________ Profa. MSc. Joo Frederico Roldan Viana

_______________________________________ Prof. MSc. Carlos Manso Coordenador do Curso

iv

A Helena Lutescia Luna Coelho

AGRADECIMENTOS

Inicialmente, agradeo a minha esposa, Adrienne, pelo incentivo, para que eu me dedicasse ao estudo e por seu auxlio no caminho desta empreitada. Agradeo a minha me, Helena, no s pelo apoio neste trabalho, mas ao longo de toda a minha vida. Sou grato principalmente a Deus, por ter me dado a oportunidade, capacitao e portas abertas para desenvolver este trabalho.

vi

"Sem o domnio da teoria das probabilidades e de outros instrumentos de administrao de risco, os engenheiros jamais teriam projetado as grandes pontes, os lares ainda seriam aquecidos por lareiras e as viagens espaciais ainda seriam um sonho. (...) A capacidade de administrar o risco e a vontade de correr riscos e de fazer opes ousadas so elementos-chave da energia que impulsiona o sistema econmico. (BERNSTEIN 1997, p. 99)

vii

RESUMO

Este estudo busca apresentar o funcionamento e a importncia da gerncia de riscos no desenvolvimento de software com base no PMBOK. A pesquisa aborda sobre o risco, sua definio, como identific-lo, classific-lo e trat-lo no desenvolvimento de software. No que diz respeito Engenharia de Software foram descritos os modelos de ciclo de vida dos processos de desenvolvimento de software, com o objetivo de agregar a idia da gesto de riscos ao ciclo de vida dos projetos. So apresentados tambm, alguns modelos de desenvolvimento de software como o RUP e o MSF que tambm tratam da gerencia de riscos. A pesquisa tem como foco principal o tratamento de risco no PMBOK, descrevendo em detalhes a disciplina de gerncia de riscos, bem como as tcnicas utilizadas, constatando que as prticas de gesto de riscos que so utilizadas no PMBOK tambm podem ser agregadas a qualquer metodologia utilizada no desenvolvimento de software. E por fim, comenta-se como seria importante agregar estas prticas Engenharia de Software. Palavras-chave: Gerncia de Riscos, MSF, RUP e PMBOK.

viii

ABSTRACT

This study is in pursuit of a presentation, practicability and importance of risks management on a software development based on the PMBOK. This research approaches its risk, its definition, as well as its identification, classification that deals with the software development, As per as the software engineering, it was described the models of the software development life cycle processes, in the direction of adding the idea of the risk management to the project life cycles. It is presented as well some software development such as: RUP, MSP and the PMBOK. The research keeps its main focus on the PMBOK test achievement, describing in details the risk management as well as its used techniques, indicating that the risk management practicable means that are used in the PMBOK, can be added to any used software development methodology. Finally, its a common thought to say how important it would be to add these procedures to the engineering software that rarely deals with such a subject. Key words: Risk Management, MSF, RUP and PMBOK.

ix

Sumrio
Lista de Figuras.............................................................................................................xii Lista de Quadros..........................................................................................................xiii 1. INTRODUO..........................................................................................................1 1.1 Motivao.............................................................................................................1 1.2 Objetivos...............................................................................................................1 2. RISCO.........................................................................................................................2 2.1 Riscos em desenvolvimento de software..............................................................2 2.2 Categoria de Riscos..............................................................................................2 2.2.1 Riscos Organizacionais..............................................................................3 2.2.2 Riscos de Gerncia do projeto....................................................................3 2.2.3 Riscos Tcnicos, de Qualidade ou de Desempenho...................................3 2.2.4 Riscos Externos..........................................................................................3 3. GERENCIAMENTO DE RISCOS EM DESENVOLVIMENTO DE SOFTWARE.4 3.1 O Processo de Desenvolvimento de Software......................................................4 3.2 Modelos de Processos de Software......................................................................5 3.3 Gerncia de Riscos no RUP.................................................................................7 3.4 Gerncia de Riscos no CMMI............................................................................10 3.5 Gerncia de Riscos no MSF...............................................................................14 4. PMBOK.....................................................................................................................16 4.1 PMI.....................................................................................................................16 4.2 Gerncia de Projetos com PMBOK....................................................................17 4.3 Gerenciamento de Integrao.............................................................................18 4.4 Gerenciamento de Escopo..................................................................................18 4.5 Gerenciamento de Tempo...................................................................................19 4.6 Gerenciamento do Custo....................................................................................19 4.7 Gerenciamento da Qualidade..............................................................................19 4.8 Gerenciamento de Recursos Humanos...............................................................19 4.9 Gerenciamento da Comunicao........................................................................19 4.10 Gerncia de Aquisies....................................................................................20 4.11 Gerncia de Risco.............................................................................................20 5. Gerenciamento de Riscos no PMBOK......................................................................22

5.1 Processos de gerenciamento de risco..................................................................25 5.1.1 Plano de Gerenciamento do Risco............................................................26 5.1.1.1 Principais Entradas do Plano de gerenciamento de riscos.....................26 5.1.1.2 Tcnicas e Ferramentas.........................................................................30 5.1.1.3 Sadas do Plano de Gerenciamento de Riscos.......................................31 5.1.2 Identificao de Riscos.............................................................................32 5.1.2.1 Principais Entradas de Identificao de Riscos.....................................32 5.1.2.2 Tcnicas e Ferramentas.........................................................................32 5.1.2.3 Sadas da Identificao dos Riscos........................................................41 5.1.3 Anlise Qualitativa de Riscos...................................................................41 5.1.3.1 Principais Entradas da Anlise Qualitativa dos Riscos.........................42 5.1.3.2 Tcnicas e Ferramentas..........................................................................42 5.1.3.3 Sadas da Anlise Qualitativa de Riscos...............................................45 5.1.4 Anlise Quantitativa.................................................................................46 5.1.4.1 Principais Entradas da Anlise Quantitativa dos Riscos.......................47 5.1.4.2 Ferramentas e Tcnicas.........................................................................48 5.1.4.3 Sadas Anlise Qualitativa de Riscos....................................................48 5.1.5 Planejamento de Respostas a Riscos........................................................49 5.1.5.1 Entradas do Planejamento de Respostas a Riscos.................................49 5.1.5.2 Tcnicas e Ferramentas para o Planejamento de Resposta ao Risco..........................................................................................................................................49 5.1.5.3 Sadas para o Planejamento de Resposta ao Risco................................51 5.1.6 Monitoramento e Controle dos Fatores de Risco.....................................52 5.1.6.1 Entradas para o Monitoramento e Controle do Risco............................53 5.1.6.2 Tcnicas e Ferramentas para o Monitoramento e Controle do Risco..........................................................................................................................................54 5.1.6.3 Sadas do Monitoramento e Controle do Risco.....................................55

6. Gerncia de Riscos no PMBOK x Gerncia de Riscos no Desenvolvimento de Software....................................................................................................................................57 6.1 Planejamento da Gerncia de Riscos......................................................................60 6.2 Identificao dos Riscos..........................................................................................61 6.3 Anlise Qualitativa dos Riscos................................................................................62 6.4 Anlise Quantitativa dos Riscos..............................................................................64

xi

6.5 Planejamento das Respostas aos Riscos..................................................................67 6.6 Monitorao e Controle dos Riscos........................................................................69 7. Concluso..................................................................................................................71 8. Referncias Bibliogrficas........................................................................................73

xii

Lista de Figuras
Figura 1: Arquitetura geral do RUP..........................................................................................22 Figura 2: Processos da gerncia de risco no modelo MSF.......................................................29 Figura 3: A performance dos projetos que utilizam totalmente, moderadamente, pouco ou no utilizam o PMBOK.............................................................................................31 Figura 4: Viso geral das reas de conhecimento em gerenciamento de projetos e os processos de gerenciamento de projetos...................................................................................35 Figura 5: Fluxograma de Processos de Gerenciamento de riscos do Projeto............................37 Figura 6: Fluxograma do painel Delphi....................................................................................49 Figura 7: Modelo de analise de riscos SWOT Mapas Mentais..............................................52 Figura 8: Diagrama de Ichikawa ou Fishbone..........................................................................54 Figura 9: Diagrama de Influncia.............................................................................................54 Figura 10: Matriz de probabilidade e impacto em cores vermelho, amarelo e verde...............57 Figura 11: Matriz de probabilidade e impacto em tons de branco e preto................................57 Figura 12: Processo Cclico de Gerncia de Risco...................................................................66 Figura 13: Associao de probabilidades a ndices..................................................................78 Figura 14: Exemplo de prioridade utilizando ndices relacionados a probabilidades de risco.....................................................................................................................................79

xiii

Lista de Quadros

Quadro 1: Sntese das disciplinas do RUP................................................................................23 Quadro 2: Objetivos especficos e prticas no CMMI..............................................................27 Quadro 3: Processos do gerenciamento de riscos.....................................................................39 Quadro 4: Analise Swot, pontos fortes vrs pontos fracos.........................................................50 Quadro 5: Analise Swot, uso do PMBOOK em novos projetos................................................51 Quadro 6: Risco em PMBOK, CMMI-SW, RUP e MSF.........................................................72

1. INTRODUO

1.1 Motivao Na vida cotidiana sempre convivemos com riscos. Podemos por exemplo: ser assaltados, contrair doenas ou sofrer um acidente de carro. Para esses casos h solues simples como: ter o veculo segurado, vacinar-se ou andar com cinto de segurana. Dentro de um projeto de desenvolvimento de um sistema no diferente. Corre-se o risco de indesejveis surpresas. H situaes em que poder incidir um risco grave e que poder significar o fracasso do prprio projeto. A Gerncia de Riscos est presente em vrias metodologias de Gesto de Projetos. Neste trabalho ser escolhido como base o modelo de Gerenciamento de Riscos do PMBOK (Project Management Body of Knowledge) desenvolvido pelo PMI (Project Managemanent Institute). O fator de maior peso na escolha do PMBOK como o modelo a ser detalhado o fato de existir uma disciplina ou grupo de processos que se dedica ao estudo do risco. 1.2 Objetivos O gerenciamento de riscos parte fundamental da gesto de projetos, porque aumenta consideravelmente a chance de um projeto ser concludo com sucesso. O presente trabalho tem como objetivo principal descrever o gerenciamento de riscos do PMBOK. Como objetivos especficos, o trabalho mostrar como o risco tratado em algumas metodologias de gesto de software, far uma comparao e demonstrar a importncia do gerenciamento de risco dentro da gesto de desenvolvimento de software.

16

2. RISCO

Risco a probabilidade de que um fator de risco venha a assumir um valor que passa a prejudicar, total ou parcialmente as chances de sucesso de um projeto. Um fator de risco qualquer evento que possa prejudicar total ou parcialmente, as chances de sucesso do projeto, isto , as chances do projeto realizar o que foi proposto dentro do prazo e fluxo de caixa que foram estabelecidos. (ALENCAR E SCHMITZ, 2006) visto que em gerncia de projetos, o risco est ligado a estas duas palavras: possibilidade e perigo. No entanto, a viso que temos em gerncia de projetos que risco qualquer evento potencial que, se concretizado, pode afetar negativamente ou positivamente o objetivo do projeto.

2.1 Riscos em desenvolvimento de software O desenvolvimento de software uma atividade complexa envolvendo inmeros fatores que so imprevisveis e de difcil controle, como inovaes tecnolgicas e mudanas constantes nos requisitos do cliente, dentre muitos outros. Esta complexidade faz com que grande parte dos projetos de desenvolvimento de software exceda o prazo e o oramento previstos, alm de no atender s expectativas do cliente em termos de funcionalidades e qualidade. Diante deste cenrio, um gerenciamento eficaz tem-se evidenciado como de fundamental importncia para o sucesso de projetos de software. Uma vez que a incerteza inerente a este tipo de projeto, o gerenciamento de riscos vem se tornando cada vez mais relevante neste contexto. 2.2 Categoria de Riscos Os riscos podem ser identificados e organizados dentro das categorias de riscos, podendo afetar o projeto positivamente ou negativamente. Se bem definidos, devem refletir os princpios comuns do risco para determinada rea de aplicao. As categorias de riscos, conforme Project Management Institute (2004), so as seguintes: Riscos Organizacionais, Riscos de Gerncia do Projeto, Riscos Tcnicos, de Qualidade ou de Desempenho, e Riscos Externos.

17 2.2.1 Riscos Organizacionais So riscos Organizacionais aqueles que so ligados poltica e gesto da empresa como, por exemplo: Tempo e escopo internamente inconsistentes, falta de verba ou verba aplicada inadequadamente, competio de projetos gerando conflito de recursos e a falta de priorizao dos projetos. 2.2.2 Riscos de Gerncia do projeto Existem vrios motivos que podem fazer com que um bom gestor de projetos venha a falhar. Como por exemplo: presso de chefias para comear a desenvolver o projeto, no respeitando o tempo estipulado nem as fases do projeto (diminuto tempo de planejamento), qualidade inadequada do planejamento, com falhas na programao das atividades, m distribuio de tempo e de recursos. 2.2.3 Riscos Tcnicos, de Qualidade ou de Desempenho A cada dia surgem novas tecnologias substituindo ou melhorando e extinguindo outras. Corre-se o risco de confiar em novas tecnologias ainda no comprovadas ou de baixa qualidade, o que poder acarretar falta de apoio ou de informao no uso daquela ferramenta. O uso de metas e performances irrealistas ou muito complexas pode afetar o desenvolvimento do projeto e a qualidade do produto ou servio final. 2.2.4 Riscos Externos Qualquer desvio do ambiente ideal para o desenvolvimento do projeto, tais como: pedidos de demisso, questes trabalhistas, mudana nas prioridades dos scios. Riscos de fora maior tal como mudanas climticas, terremotos, enchentes, guerras civis. O gerenciamento de risco posto de lado para que as aes de recuperao entrem em campo.

18

3. GERENCIAMENTO DE RISCOS EM DESENVOLVIMENTO DE SOFTWARE

O gerenciamento de riscos trabalha justamente com a incerteza, visando identificao de problemas potenciais e de oportunidades antes que eles ocorram, com o objetivo de eliminar ou reduzir a probabilidade de ocorrncia e o impacto de eventos negativos para os objetivos do projeto, alm de potencializar os efeitos da ocorrncia de eventos positivos. O gerenciamento de riscos abordado por vrios modelos que controlam a qualidade do processo de desenvolvimento de software dentre os quais o PMBOK, o CMMI, o RUP e o MSF. O CMMI (Capability Maturity Model Integration for Software) prov um framework para a implantao e melhoria do processo de software das organizaes. O RUP (Rational Unified Process) um processo baseado em melhores prticas de Engenharia de Software. O MSF (Microsoft Solutions Framework) tem sido usado pela Microsoft como o seu mtodo para desenvolvimento de solues de software dentro da Microsoft e tambm para os milhares de clientes e parceiros da Microsoft em todo o mundo. O PMBOK (Project Management Body of Knowledgement) trata do gerenciamento de projetos de uma forma ampla, no sendo especfico para software. Este captulo apresenta um estudo do gerenciamento de riscos no RUP, no CMMI e no MSF, modelos voltados para o desenvolvimento de software semelhana do que foi feito em Rocha e Belchior (2004).

3.1 O Processo de Desenvolvimento de Software Um processo de desenvolvimento de software um conjunto de atividades e resultados associados que produz um produto de software. (SOMMERVILLE, 2003) Segundo Sommerville, existem quatro atividades fundamentais de processo, que so comuns a todos os processos de software: a. Especificao de software: clientes e engenheiros definem o software a ser produzido e as restries para a sua operao; b. Desenvolvimento de software: o software projetado e programado;

19 c. Validao de software: na qual o software verificado para garantir que o que o cliente deseja; d. Evoluo de software: o software modificado para se adaptar s mudanas dos requisitos do cliente e do mercado. Cada atividade pode ser composta de outras atividades as quais so realizadas por pessoas que possuem um determinado papel no processo como: programador, gerente, cliente e outros. Tais pessoas podem utilizar ferramentas e modelos que automatizem e facilitem os seus trabalhos, e medida que o processo flui, artefatos (cdigo, documentos, modelos, diagramas, etc...) so produzidos, atualizados e consumidos nas atividades realizadas. Sommerville diz ainda que, diferentes tipos de sistemas necessitam de diferentes processos de desenvolvimento, como exemplo: um software de tempo real de uma aeronave deve ser completamente especificado antes do incio do desenvolvimento, enquanto nos sistemas de comrcio eletrnico a especificao e o programa so, geralmente, desenvolvidos em conjunto. Consequentemente, essas atividades genricas podem ser organizadas de diferentes maneiras e descritas em nveis diferentes de detalhes, para diferentes tipos de software. Porm, o uso de um processo de software inadequado pode reduzir a qualidade ou a utilidade do produto de software a ser desenvolvido e/ou aumentar os custos de desenvolvimento. (SOMMERVILLE, 2003)

3.2 Modelos de Processos de Software A importncia da aplicao de metodologias para o desenvolvimento de software foi crescendo gradualmente, medida que a complexidade das aplicaes crescia. Atrasos e problemas com o oramento eram problemas comuns maioria dos projetos, devido falta de uma abordagem especial ao software. Assim, houve a necessidade de se repensar em como de fato desenvolver um software. Vrios modelos de desenvolvimento foram criados desde ento. Um modelo de processo de software uma representao abstrata de um processo de software. (SOMMERVILLE, 2003) Segundo Sommerville (2003), a maioria dos modelos de processo de software baseada em um dos trs modelos gerais ou paradigmas de desenvolvimento de software:

20

a. O modelo em cascata: considera as atividades apresentadas anteriormente e as representa como fases separadas de processo, como especificao de requisitos, projeto de software, implementao, teste e assim por diante. Depois que cada estgio concludo, ele aprovado e o desenvolvimento prossegue para o estgio seguinte.

b. Desenvolvimento evolucionrio: esta abordagem intercala as atividades de especificao, desenvolvimento e validao. Um sistema inicial desenvolvido rapidamente com base em especificaes muito abstratas. ento refinado com as informaes do cliente, para produzir um sistema que satisfaa as necessidades deste. O sistema pode, ento, ser entregue. Como alternativa, ele pode ser reimplementado, utilizando uma abordagem mais estruturada, para produzir um sistema mais robusto e mais fcil de ser mantido. c. Engenharia de software baseada em componentes (CBSR Component Based Software Engineering): esta tcnica supe que partes do sistema j existam. O processo de desenvolvimento concentra-se mais na integrao dessas partes que no seu desenvolvimento a partir do incio.

Esses trs modelos genricos de processo so amplamente usados na prtica atual de Engenharia de Software. Eles no so mutuamente exclusivos e freqentemente so usados em conjunto, especialmente para desenvolvimento de sistemas de grande porte. Os subsistemas contidos em um sistema maior podem ser desenvolvidos usando diferentes abordagens. A primeira proposta para incluir a gerncia de riscos em modelos de desenvolvimento de software foi feita no final dos anos 80, quando Barry Boehm props o modelo de desenvolvimento em espiral. (MACHADO, 2002) Mais tarde, em 1991, o mesmo Barry Boehm publicou um artigo especfico sobre gerncia de riscos em projetos de desenvolvimento de software. Ao longo de sua carreira, Boehm teve a chance de observar diversos gerentes de projetos em ao e com isso pde identificar caractersticas que diferenciam os mais

21 eficientes dos menos eficientes. Como resultado destas observaes, ele identificou que uma caracterstica presente em todos os gerentes de projetos eficientes que estes eram excelentes gerentes de riscos. (BOEHM, 1991) O artigo publicado por Boehm teve como objetivo tentar definir princpios e prticas baseado nesta caracterstica comum aos gerentes de projetos observados. Desde ento, a gerncia de riscos em projetos de desenvolvimento de software vem crescendo em proporo. (MACHADO, 2002) No incio da dcada de 90, as metodologias de gerncia de projetos costumavam deixar a gerncia de riscos em segundo plano, normalmente dentro de alguma outra rea de conhecimento. Hoje essas mesmas metodologias colocam a gerncia de riscos em posio de destaque, dedicando captulos exclusivos para essa rea de conhecimento. Foi o caso do PMBOK, que em 1987 deu maior visibilidade gerncia de riscos dedicando uma rea de conhecimento especfica para o assunto, e do CMMI, que ao evoluir do SW-CMM reuniu as prticas referentes gerncia de riscos, at ento inclusas dentro de outras reas chave de processo, em uma rea de processo tambm especfica para o assunto.

3.3

Gerncia de Riscos no RUP O Rational Unified Process (RUP) um framework de processo de

desenvolvimento de software definido pela Rational Software Corporation. um exemplo de modelo de processo de software moderno, inclui as melhores prticas de Engenharia de Software, utiliza a abordagem iterativa e incremental e tambm traz elementos de outros modelos genricos de processos. Foi desenvolvido para ser aplicvel a uma grande classe de projetos distintos e pode ser considerado como um framework genrico para processos de desenvolvimento. Isso significa que ele deve ser adaptado para ser usado eficientemente. A adaptao pode ser feita para empresas ou mesmo para projetos especficos. O RUP composto por quatro fases Iniciao, Elaborao, Construo e Transio cada uma destas com objetivos especficos. A fase de Iniciao deve estabelecer o escopo e a viabilidade econmica do projeto. RUP (2003)

22 O objetivo da fase de Elaborao eliminar os principais riscos e estabelecer uma arquitetura estvel a partir da qual o sistema poder evoluir. Na fase de Construo, um produto completo desenvolvido de maneira iterativa at que esteja pronto para ser passado aos usurios, o que ocorre na fase de Transio, onde uma verso beta do sistema disponibilizada. Cada fase pode comportar vrias iteraes e cada iterao, por sua vez, est organizada em disciplinas, que descrevem o que deve ser feito em termos de atividades, responsveis e artefatos. RUP (2003)

Figura 1 Arquitetura Geral do RUP. Fonte: RUP (2003)

A Figura 1 mostra a arquitetura geral do RUP da seguinte maneira: O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo medida que se desenvolve O eixo vertical representa as disciplinas, que agrupam as atividades de maneira lgica, por natureza. Na fase de iniciao o foco principal recai sobre o entendimento dos requisitos e a determinao do escopo do projeto (planejamento e levantamento de requisitos). Na fase de elaborao, o enfoque est na captura e modelagem dos requisitos (levantamento de requisitos e anlise), ainda que algum trabalho de projeto e implementao seja realizado para prototipar a arquitetura, evitando certos riscos tcnicos. Na fase de

23 construo, o enfoque concentra-se no projeto e na implementao, visando evoluir e incrementar o prottipo inicial, at obter o primeiro produto operacional. Finalmente, a fase de transio concentra-se nos testes, visando garantir que o sistema possui o nvel adequado de qualidade. Alm disso, usurios devem ser treinados, caractersticas ajustadas e elementos esquecidos adicionados.

Quadro 1 Sntese das disciplinas do RUP

DISCIPLINAS DO RUP
Modelagem de Negcios Envolve o entendimento da estrutura e dinmica da organizao cliente, garantindo que clientes, usurios e desenvolvedores tenham a mesma viso da organizao para a qual ser feito o desenvolvimento. Envolve a definio dos requisitos do sistema e de como gerenciar escopo e mudanas de requisitos. Envolve a traduo dos requisitos numa especificao que descreva como implementar o sistema. A linguagem UML utilizada para modelar o sistema. Envolve o desenvolvimento de cdigo: classes, objetos, etc., testes de unidade e integrao de subsistemas. Envolve a verificao do sistema como um todo, com testes de integrao e conformidade com os requisitos especificados. Envolve o empacotamento, distribuio, instalao e treinamento de usurios, assim como o planejamento e conduo de testes preliminares. Envolve o gerenciamento de riscos, planejamento e acompanhamento do projeto.

Requisitos

Anlise e Projeto

Implementao Testes

Disponibilizao

Gerncia de Projetos

Gerncia de Configurao e Mudanas Envolve o gerenciamento dos artefatos gerados durante o desenvolvimento. Ambiente Envolve a organizao do ambiente de trabalho para a equipe do projeto e a configurao do RUP para o projeto.

Fonte: Adaptado pelo autor a partir da RUP (2003)

O gerenciamento de riscos no RUP se prope a balancear objetivos concorrentes, gerenciar riscos e restries, para que a entrega do produto satisfaa a seus clientes e usurios. O gerenciamento de riscos est integrado ao processo de desenvolvimento, onde as iteraes so planejadas e esto baseadas nos riscos de maior prioridade. Em uma abordagem iterativa, os riscos so mitigados mais cedo, porque os elementos so integrados progressivamente.

24 Uma vez que cada iterao exercita muitos aspectos do projeto, torna-se mais fcil descobrir at que ponto os riscos percebidos esto se materializando, como tambm descobrir novos e insuspeitos riscos.

No RUP, a problemtica do risco tratada de uma maneira cooperativa nas quatro fases da seguinte maneira: Iniciao: foco no tratamento dos riscos relacionados aos casos de negcio1. Elaborao: foco principalmente nos riscos tcnicos, examinando-se os riscos de arquitetura e, se necessrio, revisando-se o escopo do projeto medida que seus requisitos tornam-se melhor compreendidos. Construo: foco nos riscos de logstica e na obteno da concluso da maior parte do trabalho Transio: foco nos riscos associados com a logstica de entrega do produto seu usurio.

O papel envolvido com o gerenciamento de riscos no RUP o do gerente do projeto, que executa as atividades Desenvolver o Plano de Gerenciamento de Riscos, Identificar e Avaliar Riscos, e Monitorar o Status do Projeto, que tm como entrada ou sada os artefatos: Viso Geral (documento de requisitos), Planos de Gerenciamento de Riscos e Lista de Riscos. (PASCALE e BELCHIOR, 2004)

3.4 Gerncia de Riscos no CMMI O CMMI (Capability Maturity Model Integration) considerado um modelo de gesto de processos que tem como objetivo prover s empresas, um conjunto de melhores prticas que possa suportar a melhoria contnua de seu desempenho, bem como ser referncia para eventuais comparaes por meio de seus nveis de maturidade e capacidade. O CMMI contm prticas (Genricas e Especficas) necessrias maturidade em disciplinas especficas (Systems Engineering (SE), Software Engineering (SE), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)).

Caso de Negcio: O caso de negcio (business case) fornece a informao necessria a partir de um ponto de vista de negcio para determinar se o projeto justifica o investimento necessrio para a sua execuo.

25 Desenvolvido pelo SEI (Software Engineering Institute) da University Carnegie Mellon, o CMMI uma evoluo do CMM
2

e procura estabelecer um modelo nico

para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas. O CMMI-SW contm duas representaes: por estgios, e contnua. A representao por estgios trata do nvel de maturidade da organizao como um todo, contendo cinco nveis de maturidade: inicial, gerenciado, definido, gerenciado quantitativamente e em otimizao.

a. A Representao Contnua: Possibilita organizao utilizar a ordem de melhoria que melhor atender os objetivos de negcio da empresa. caracterizado por Nveis de Capacidade (Capability Levels):

Nvel 0: Incompleto (Ad-hoc) Nvel 1: Executado (Definido) Nvel 2: Gerenciado / Gerido Nvel 3: Definido Nvel 4: Quantitativamente gerenciado / Gerido quantitativamente Nvel 5: Em otimizao (ou Optimizado)

b. Representao Por Estgios: Disponibiliza uma seqncia pr-determinada para melhoria baseada em estgios que no deve ser desconsiderada, pois cada estgio serve de base para o prximo. caracterizado por Nveis de Maturidade (Maturity Levels):

Nvel 1: Inicial (Ad-hoc) Nvel 2: Gerenciado / Gerido Nvel 3: Definido Nvel 4: Quantitativamente gerenciado / Gerido quantitativamente Nvel 5: Em otimizao

CMM: O CMM foi desenvolvido pela SEI (Software Engineering Institute) em 1986 com o objetivo de melhorar a desenvolvimento de aplicaes em organizaes que trabalham com tecnologia.

26 Cada nvel constitudo por um conjunto de reas de processos, compostas por objetivos especficos e objetivos genricos. Cada objetivo especfico pode ser composto por um conjunto de prticas especficas.

Um objetivo especfico (SG, Specific Practices by Goal) descreve as caractersticas que devem estar presentes para satisfazer uma rea de processo. Uma prtica especfica (SP, Specific Practices) a descrio de uma atividade que considerada importante para se alcanar o objetivo especfico a ela associado.

A problemtica do risco abordada nas reas de processo Planejamento do Projeto, Monitorao e Controle do Projeto, e Gerncia de Risco. As duas primeiras reas de processo esto no nvel 2 e a ltima est no nvel 3 do CMMI-SW. No Planejamento do Projeto, tem-se o SG Desenvolvimento do Plano do Projeto com a SP Identificar os Riscos do Projeto, que consiste na identificao e na anlise dos riscos para se determinar o impacto, a probabilidade de ocorrncia e o perodo em que podem ocorrer, para que os riscos possam ser priorizados. Na Monitorao e Controle do Projeto, tem-se o SG Monitorar o Projeto de Acordo com o Plano, onde est inserido a SP Monitorar os Riscos do Projeto. A Gerncia de Risco no CMMI tem por finalidade identificar potenciais problemas antes que ocorram, de forma que as atividades de administrao desses riscos possam ser planejadas e realizadas, de acordo com suas necessidades, ao longo do ciclo de vida do produto ou projeto, para mitigar possveis impactos adversos. (ROCHA e BELCHIOR, 2004) O quadro 2 mostra os objetivos especficos e o resumo de suas prticas.

27 Quadro 2 Objetivos especficos e prticas no CMMI.

Objetivos especficos Prticas SP 1.1: Determinar as origens e categorias dos riscos SG 1: Preparar-se para a gerncia de riscos SP 1.2: Definir os parmetros dos riscos SP 1.3: Estabelecer uma estratgia de gerncia de riscos SP 2.1: Identificar os riscos SG 2: Identificar e analisar os riscos SP 2.2: Avaliar, categorizar e priorizar os riscos SP 3.1: Desenvolver planos de mitigao de riscos SG 3: Mitigar os Riscos SP 3.2: Implementar os planos de mitigao dos riscos GP 2.1: Estabelecer uma poltica organizacional GP 3.1: Estabelecer um processo definido GP 2.2: Planejar o processo GP 2.3: Prover recursos GP 2.4: Atribuir responsabilidades GP 2.5: Treinar o pessoal GG 3: Institucionalizar um processo definido GP 2.6: Gerenciar configuraes GP 2.7: Identificar e envolver os interessados relevantes GP 2.8: Monitorar e controlar o processo GP 3.2: Coletar informaes de melhoria GP 2.9: Avaliar objetivamente a aderncia GP 2.10: Revisar a situao com a gerncia de alto nvel Fonte: ROCHA e BELCHIOR(2004)

28 3.5 Gerncia de Riscos no MSF O MSF (Microsoft Solutions Framework) uma srie flexvel e interrelacionada de conceitos, modelos e prticas recomendadas que serve como uma base para planejamento e criao de projetos tecnolgicos. Os princpios e as prticas do MSF ajudam as organizaes a prever, planejar e implementar solues tecnolgicas que atendam aos objetivos dos negcios. A Microsoft criou o MSF em 1994, baseando-se nas prticas recomendadas de desenvolvimento de produto da Microsoft e das organizaes de TI. O MSF aborda a gerncia de riscos como uma importante atividade para o sucesso do projeto, pois tomadas de deciso baseadas em riscos so fundamentais para esta metodologia. A gerncia de riscos uma das disciplinas do MSF que precisa ser integrada ao ciclo de vida do projeto. (MICROSOFT, 2002)

O MSF divide a gerncia de riscos em seis processos: Identificar: identificar os riscos do projeto e apresent-los equipe do projeto. Analisar e priorizar: estudar e ordenar os riscos. Planejar: construir um plano de aes. Monitorar: acompanhar a situao dos riscos e das aes. Controlar: integrar a gerncia de riscos s atividades cotidianas do projeto. Aprender: finalizar o processo registrando numa base de conhecimentos, os riscos, os planos de ao e contingncia e a aes adotadas para que possam ser futuramente revistas e analisadas.

29

Figura 2 Processos da gerncia de risco no Modelo MSF. Fonte: Microsoft (2002)

A Figura 2 apresenta como os seis processos que compem a gerncia de riscos no MSF interagem entre si. A disciplina considera como boas prticas a gerncia prativa de riscos, a avaliao contnua de riscos e a integrao da disciplina com as tomadas de decises ao longo do ciclo de vida do projeto. Riscos devem ser continuamente gerenciados at que sejam mitigados ou at que se tornem um problema real a ser controlado. (MICROSOFT, 2002)

30

4. PMBOK

4.1 PMI O PMI (Project Management Institute) uma organizao internacional sem fins lucrativos, fundada em 1969 por um grupo de cinco voluntrios, na Filadlfia Pensilvnia - EUA. O principal objetivo do PMI tem sido a definio e divulgao das melhores prticas em gesto de projetos. Alm de desenvolver normas, seminrios, programas educacionais e certificao profissional. Possui mais de 100.000 (cem mil) membros em todo o mundo e j certificou mais de 50.000 (cinqenta mil) PMP (Project Management Professional). O PMI estima que 10 trilhes de dlares sejam gastos anualmente no mundo em projetos, o que equivale a aproximadamente 25% do PIB mundial, e que cerca de 16,5 milhes de profissionais esto envolvidos diretamente com a Gerncia de Projetos no mundo. Este volume de projetos e mudanas constantes no cenrio competitivo mundial gera a crescente necessidade de resultados mais rpidos, com qualidade e a um custo competitivo. Fatores como a globalizao do mercado e aquisies de novas tecnologias emergentes, tornam cada vez maior a Gerncia de Projetos um assunto da mais alta importncia para as organizaes e para sua capacidade de sobrevivncia. Pesquisas realizadas pelo PMI mostram que 75% dos seus membros indicaram que, nos prximos anos, suas empresas estaro dando maior importncia para a gerncia de projetos. (PMI-SP, 2009)

31

Figura 3 A performance dos projetos que utilizam totalmente, moderadamente, pouco ou no utilizam o PMBOK. Fonte: PMI-SP (2009) A figura 3 apresenta uma estatstica dos projetos que utilizam o PMBOK. Os dados afirmam claramente que com a utilizao do PMBOK os projetos tiveram um desempenho muito melhor quanto s entregas dos prazos e ao oramento. (PMI-SP, 2009)

4.2 Gerncia de Projetos com PMBOK O desenvolvimento de software tem avanado tecnologicamente em rpidas propores, mas existem fatores que ocorrem desde o comeo desse avano, so eles: os erros de gesto e a falta de sucesso do software desenvolvido, muitas vezes no atendendo o que cliente desejava. Para o sucesso ser completo, o produto final deve ser entregue dentro do prazo, com o custo especificado, e ser realmente aquilo que o cliente necessitava. A Gerncia de Projetos uma soluo para os problemas que as equipes de desenvolvimento de Software vm enfrentando, porque distribuda em reas de conhecimento, onde cada uma delas descreve seus respectivos processos a fim de garantir que os objetivos planejados sejam atingidos. As tcnicas de gerenciamento de

32 projetos esto sendo aprimoradas constantemente, buscando sempre garantir o sucesso dos processos. O Project Management Body of Knowledge, tambm conhecido como PMBOK um conjunto de prticas em gerncia de projetos levantado pelo Project Management Institute (PMI) e constituem a base da metodologia de gerncia de projetos do PMI. Estas prticas so compiladas na forma de um guia, chamado de Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos, ou Guia PMBOK. (ALENCAR, 2006) O Gerente de projetos a pessoa responsvel pela realizao dos objetivos do projeto, identificando s necessidades, estabelecendo objetivos claros e possveis de ser alcanados e tentar equilibrar qualidade, escopo, tempo e custo, a ainda atender s expectativas das partes interessadas no projeto. Ele e sua equipe devero seguir um cdigo de tica e conduta profissional para aqueles que possuem a certificao PMP. No gerenciamento de projetos so aplicados os conhecimentos, habilidades, ferramentas e tcnicas s atividades do projeto e realizado atravs da aplicao e da integrao das seguintes reas de competncias gerncias, so elas: Gerenciamento de Integrao, Gerenciamento de Escopo, Gerenciamento de Tempo, Gerenciamento do Custo, Gerenciamento da Qualidade, Gerenciamento dos Recursos Humanos, Gerenciamento da Comunicao, Gerncia de Aquisies e Gerncia de Riscos. (PMI, 2004; DINSMORE, 2005; GURGEL, 2007) 4.3 Gerenciamento de Integrao A Gerncia de Integrao tem como objetivo fazer o controle geral das mudanas e monitorar a execuo do plano do projeto, desde seu inicio com o termo de abertura do projeto at seu final com o encerramento do projeto, realizando negociaes dos objetivos conflitantes, dando alternativas ao projeto com a finalidade de atender as necessidades e expectativas de todas as partes interessadas. 4.4 Gerenciamento de Escopo O objetivo principal dessa gerncia definir e manter o desenvolvimento do projeto dentro do escopo desenhado, controlando o que deve e o que no deve estar includo no projeto, tendo a segurana, que realmente a necessidade do cliente, e

33 qualquer mudana que venha a se realizar no escopo dever ter o consentimento do cliente.

4.5 Gerenciamento de Tempo Tem como objetivo principal controlar o tempo das atividades garantindo que o projeto cumpra seu prazo contratual.

4.6 Gerenciamento do Custo A responsabilidade da Gerncia de Custo gerenciar o caixa do projeto, desde a estimativa de custo total do projeto, bem como o controle das despesas para cada atividade dentro do projeto, garantido que o mesmo seja realizado dentro do oramento estipulado. 4.7 Gerenciamento da Qualidade O gerenciamento da qualidade responsvel por garantir a aceitao do software ao cliente, ou seja, o controle de qualidade do projeto, verificando se ele satisfaz as exigncias para o que foi desenvolvido, e se cumpre as expectativas e as necessidades do cliente. 4.8 Gerenciamento de Recursos Humanos O Gerenciamento de Recursos Humanos tem como objetivo administrar a mo de obra humana, atribuir funes e responsabilidades, relaes interpessoais e de equipe, buscando sempre o melhor aproveitamento das pessoas envolvidas no projeto.

4.9 Gerenciamento da Comunicao O Gerenciamento de Comunicaes responsvel pela conectividade de informaes do projeto a todos os stakeholders e outras gerncias. Todas as gerncias do projeto interagem entre si e com as demais reas de conhecimento. A Gerncia de

34 Comunicaes do Projeto inclui os processos que garantem a coleta, a distribuio, o armazenamento e o controle bsico das informaes do projeto, fornecendo a ligao entre pessoas, idias e informaes. Todos os envolvidos no projeto devem estar preparados para enviar e receber as informaes e os processos que envolvem essa gerncia que consiste em: planejar da forma mais conveniente a disponibilizar as informaes e comunicaes necessrias para os evolvidos no projeto, relatando as informaes de desempenho at o encerramento das fases do projeto.

4.10 Gerncia de Aquisies A Gerncia de Aquisies responsvel pela administrao de compras e contrataes de servios para o projeto.

4.11 Gerncia de Risco Gerncia de Risco o objeto de estudo da monografia e ser detalhado no prximo captulo. O objetivo principal dessa gerncia maximizar os resultados de ocorrncias positivas e minimizar as consequncias negativas ou at mesmo eliminar eventos adversos, tratando e controlando os riscos. A figura 4 apresenta as reas de conhecimento e os processos pelos quais so responsveis.

35

Figura 4 Viso Geral das reas de conhecimento em gerenciamento de projetos e os processos de gerenciamento de projetos. Fonte: PMI (2004)

36

5. GERENCIAMENTO DE RISCOS NO PMBOK

O gerenciamento de Riscos um processo sistemtico usado para identificar, analisar e responder aos riscos do projeto cujo objetivo maximizar a probabilidade dos eventos positivos e se possvel neutralizar os eventos negativos ou minimizar suas consequncias para o objetivo do projeto. O risco dentro de um projeto uma condio incerta de ocorrer, e se ocorrer ter sempre um impacto positivo ou negativo sobre pelo menos um dos objetivos do projeto, como: o tempo, o custo, o escopo ou a qualidade. O risco poder ter uma ou mais causas e um ou mais impactos. Por exemplo, uma causa pode ser: a falta de pessoal suficiente para trabalhar dentro de uma rea de conhecimento do projeto, o evento do risco pode ser a contratao inadequada de pessoal, podendo comprometer o cronograma, a qualidade e o custo do projeto. Os riscos tambm podem abranger os aspectos organizacionais como prticas deficientes de gerenciamento de impacto. Por exemplo, a falta de sistemas de gerenciamento integrados, vrios projetos simultneos, dependncia externa fora do controle do gerente do projeto, etc. (VARGAS, 2009) A figura 5 apresenta uma viso geral dos processos do gerenciamento de riscos no PMBOK. O quadro referente ao gerenciamento de riscos do projeto foi isolado para fornecer uma viso ampliada dos processos de gerenciamento de risco do projeto, conforme demonstrado no quadro 3.

37

Figura 5 Fluxograma de Processos de Gerenciamento de Riscos do Projeto. Fonte: PMI (2004)

38 5.1 Processos de gerenciamento de risco O inicio de um projeto marcado por um grande esforo. No planejamento do projeto, so realizadas reunies tendo como foco os objetivos do projeto: Escopo, Qualidade, Prazo e Custo. Neste momento j importante pensar nos riscos pois medida que os objetivos vo se consolidando, os possveis riscos vo se tornando mais provveis, podendo comprometer o andamento do projeto. Os processos do gerenciamento de riscos do projeto esto dispostos da seguinte forma: a. Plano de Gerenciamento do Risco: decide como abordar, planejar e executar as atividades de gerncia de risco para um projeto; b. Identificao dos Fatores de Risco: determina quais riscos podem afetar o projeto e documenta suas caractersticas; c. Anlise Qualitativa de Risco: realiza uma anlise qualitativa dos riscos e as condies para priorizar seus efeitos nos objetivos do projeto. d. Anlise Quantitativa de Risco: mede a probabilidade atravs de uma anlise numrica e as conseqncias dos riscos e estima suas implicaes para os objetivos do projeto. e. Planejamento de resposta ao Risco: desenvolve procedimentos e tcnicas para melhorar as oportunidades e reduzir as ameaas para os objetivos do projeto. f. Monitoramento e Controle do Risco: monitora riscos residuais identifica novos riscos, executa planos de reduo de risco e avalia sua eficcia durante todo o ciclo do projeto. Esses processos no ocorrem isoladamente, eles interagem entre si e tambm com processos de outras reas.

39

Quadro 3 Processos do Gerenciamento de Riscos. (PMI, 2004)

1. Plano de Gerncia de Risco 2. Identificao do Risco 3. Anlise Qualitativa do risco

1.1 Entradas Fatores ambientais Ativos de processos organizacionais Declarao do escopo do projeto Plano de gerenciamento do projeto

2.1 Entradas Plano de gerenciamento de riscos Declarao do escopo do projeto Fatores ambientais Ativos de processos organizacionais Plano de gerenciamento do projeto

3.1 Entradas Ativos de processos organizacionais Declarao do escopo do projeto Plano de gerenciamento de riscos Registro de riscos 3.2 Tcnicas e Ferramentas Avaliao de probabilidade impacto de riscos Matriz de probabilidade e impacto do risco Avaliao da qualidade dos dados sobre o risco Categorizao de riscos Avaliao da urgncia do risco 3.3 Sadas Registro de riscos atualizados

1.2 Tcnicas e Ferramentas Reunies de planejamento

2.2 Tcnicas e Ferramentas Reviso da documentao Tcnicas de coleta de informaes. Anlise da lista de verificao Anlise das premissas Tcnicas de diagramao

1.3 Sadas Plano de gerenciamento de riscos

2.3 Sadas Registro de riscos

4. Anlise quantitativa do risco 4.1 Entradas Ativos de processos organizacionais Declarao do escopo do projeto Plano de gerenciamento de risco Registro de Riscos identificados Plano de gerenciamento do projeto Cronograma Custos 4.2 Tcnicas e Ferramentas Tcnicas de representao e coleta de dados. Anlise quantitativa de riscos e tcnicas de modelagem

5. Plano de Resposta ao risco 5.1 Entradas Plano de gerenciamento de risco Registro de Riscos

6. Monitorando e Controlando risco 6.1 Entradas Plano de gerenciamento de risco Registro de Riscos Solicitao de mudanas aprovadas

5.2 Tcnicas e Ferramentas Estratgias para riscos negativos ou ameaas Estratgias para riscos positivos ou oportunidades Estratgias para ameaas e oportunidades Estratgia para respostas contigenciadas

Informaes sobre o desempenho do trabalho Relatrios de desempenho 6.2 Tcnicas e Ferramentas Reavaliao de riscos Auditorias de risco Anlise das tendncias e da variao Medio do desempenho tcnico Anlise das reservas

5.3 Sadas 4.3 Sadas Registro de riscos atualizados Registro de riscos atualizados Plano de gerenciamento do projeto (atualizaes) Acordos contratuais relacionados a riscos

Reunies de andamento 6.3 Sadas Registro de riscos(atualizaes) Mudanas solicitadas Aes corretivas recomendadas Ativos de processos organizacionais (atualizaes) Plano de gerenciamento do projeto (atualizaes)

Fonte:PMI

(2004)

40 5.1.1 Plano de Gerenciamento do Risco Dentro de um processo de administrao de risco, o seu plano de gerenciamento visa garantir que o tipo, o nvel e a visibilidade da Gerncia de Risco sejam compatveis com o risco e com a importncia do projeto. O Plano gerencial de riscos deve ser terminado j no incio do planejamento do projeto, por ser essencial para executar com sucesso as outras atividades de planejamento. O Plano do Gerenciamento do Risco , portanto, um documento que explica como ser desenvolvido o processo gerencial do risco, o custo estimado e investido e a nomeao de responsabilidades aos gestores e envolvidos. Os processos do Plano de Gerenciamento de Riscos no atuam isoladamente, interagem entre si e com os processos de outras reas, ocorrendo pelo menos uma vez em cada projeto (ALENCAR e SCHMITZ. 2006; GURGEL. 2007 e SOARES. 2007).

5.1.1.1 Principais Entradas do Plano de gerenciamento de riscos

As principais entradas so desenvolvidas inicialmente nas seguintes reas: Gerenciamento da Integrao e no Gerenciamento de escopo. So elas: fatores ambientais, ativos de processos organizacionais, declarao de escopo do projeto e plano de gerenciamento do projeto. PMI (2004) Fatores Ambientais: tudo deve ser considerado no projeto, inclusive os fatores ambientais da empresa, pois eles podero influenciar no sucesso do projeto. Como, por exemplo: Polticas de gerncia do risco da organizao: algumas organizaes possuem essa abordagem pr-definida para anlise de risco para cada projeto. a. Tolerncia aos riscos: pr-definir as diferentes tolerncias aos riscos, atravs de polticas ou aes; b. Bancos de dados comerciais: por exemplo: dados padronizados de estimativa de custos, informaes sobre estudos de risco do setor e banco de dados de risco. c. Sistema de informaes do gerenciamento do projeto: por exemplo, um conjunto de ferramentas automatizadas, como uma ferramenta de software

41 para elaborao de cronogramas, um sistema de gerenciamento de configurao, um sistema de coleta e distribuio de informaes ou interfaces Web para outros sistemas on-line automatizados.

Ativos de Processos organizacionais: so considerados ativos de processos organizacionais as polticas, procedimentos, planos e diretrizes formais e informais. Tambm podem ser representados pelo aprendizado e o conhecimento adquirido em projetos anteriores. Podendo agrupar-se em duas categorias:

a. Processos e procedimentos da empresa: como, por exemplo, as normas, polticas de gerenciamento de projetos, contrataes, polticas e

procedimentos de qualidade (auditoria de processos, metas de melhoria, listas de verificao e processos padronizados), procedimentos para gerenciar os problemas e defeitos de maneira que sejam identificados e controlados, procedimentos para controlar mudanas de normas e polticas (como elas sero aprovadas e validadas), procedimentos para controlar os riscos e suas categorias, impacto e definio de probabilidade e matriz de probabilidade e impacto.

b. Base de conhecimento corporativo da empresa para armazenar e recuperar informaes: por exemplo, arquivos de projeto (escopo, custo, cronograma, qualidade, desempenho, registro de riscos (aes de resposta planejada e impacto de risco definido), base de dados financeira contendo informaes como pessoal contratado, custos incorridos, oramento e estouro nos custos do projeto.

Declarao do escopo do projeto: descreve os principais objetivos do projeto, permitindo que a equipe do projeto realize um planejamento mais detalhado, servindo de orientao para a equipe do projeto durante a execuo, auxiliando a avaliar as solicitaes de mudana e verificar se estas esto dentro ou fora dos limites estabelecidos no projeto. Quanto maior for o grau e o nvel de detalhamento da declarao de escopo do projeto, melhor ser definido o trabalho que ser realizado pela

42 equipe ajudando a planejar, gerenciar e controlar sua execuo. A declarao do escopo detalhada do projeto poder incluir as seguintes informaes:

a. Objetivos do projeto: os critrios mensurveis do sucesso do projeto esto includos na declarao do escopo. Os objetivos podem ser de ordem tcnica, de negcios, custo, cronograma e qualidade. Os objetivos do projeto tambm podem incluir metas de custo, cronograma e qualidade, e estas definidas em uma determinada moeda como parmetros.

b. Descrio do escopo do produto: descreve as caractersticas do produto, servio ou resultado do por que da realizao do projeto. medida que o projeto avana as caractersticas sero mais detalhadas, elas podem variar com o tempo, contanto que forneam detalhes suficientes para dar suporte ao planejamento posterior do escopo do projeto. c. Requisitos do projeto: so as normas, especificaes ou outros documentos formalmente impostos, com descrio das condies a serem seguidas projeto para atender a um determinado contrato. As expectativas e

necessidades das partes interessadas devero ser transformadas em requisitos prioritrios.

d. Limites do projeto: identifica o que est includo dentro do projeto e descreve explicitamente o que est fora do projeto, para prevenir que a parte interessada cobre que um determinado produto, servio ou resultado especfico seja componente do projeto. e. Entregas do projeto: as entregas3 possuem os relatrios de gerenciamento de projetos e sua documentao e dependendo da declarao do escopo do projeto, as entregas podem ser descritas de forma sumarizada ou detalhada.

A entrega qualquer produto, resultado ou capacidade para realizar um servio exclusivo e verificvel identificvel ma documentao do plano de gerenciamento do projeto e que deve ser produzido e fornecido para terminar o projeto - Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK) 3 edio.

43 f. Critrios de aceitao de produtos: define o processo e os critrios para aceitar os produtos terminados.

g. Restries do projeto: lista e descreve as restries especficas do projeto associadas ao escopo do projeto que limitam as opes da equipe. As restries listadas na declarao do escopo do projeto so normalmente mais numerosas e mais detalhadas do que as listadas no termo de abertura do projeto.

h. Premissas do projeto: lista e descreve as premissas especficas do projeto associadas ao escopo do projeto e o impacto potencial dessas premissas, se no forem confirmadas. Frequentemente, as equipes de projetos identificam, documentam e validam as premissas como parte do seu processo de planejamento. As premissas listadas na declarao do escopo detalhada do projeto so normalmente mais numerosas e mais detalhadas do que as listadas no termo de abertura do projeto.

i. Organizao inicial do projeto: os membros da equipe do projeto e as partes interessadas so identificados e tambm documentada.

j. Riscos iniciais definidos: Identifica os riscos conhecidos.

k. Marcos do cronograma: Os marcos so identificados e datados. Essas datas podem ser consideradas como restries do cronograma.

l. Limitao de fundos: Descreve qualquer limitao dos recursos financeiros do projeto, uma limitao do valor total ou uma limitao imposta em prazos especificados.

m. Estimativa de custos: A estimativa de custos do projeto indica o custo total esperado do projeto e normalmente precedida de um modificador que fornece alguma indicao de exatido como, por exemplo, conceitual ou definitiva.

44

n. Requisitos do gerenciamento de configurao do projeto: Descreve o nvel de gerenciamento de configurao e controle de mudanas que ser implementado no projeto.

o.

Especificaes do projeto: Identifica os documentos de especificao com os quais o projeto deve estar de acordo.

p. Requisitos de aprovao: Identifica os requisitos de aprovao que podem ser aplicados a itens como objetivos, entregas, documentos e trabalho do projeto. Plano de Gerenciamento do Projeto: O contedo do plano de gerenciamento do Projeto est compreendido em trs partes: a. Definio de papis e responsabilidades: definir as responsabilidades e os nveis de autoridade das pessoas que iro influir no plano.

b. Estrutura analtica do Projeto (EAP): um agrupamento orientado ao subproduto dos elementos do projeto que organiza e define o escopo total do projeto. O trabalho que no est na EAP est fora do escopo do projeto.

c. Oramento da Gerncia de Risco: estabelece um oramento para a gerncia do risco para o projeto.

5.1.1.2 Tcnicas e Ferramentas De acordo com a PMI (2004), so as principais tcnicas e ferramentas do Plano Gerencial do Risco: Reunies de planejamento: o gerente do projeto, lderes de equipe do projeto organizam reunies de planejamento para elaborao do plano de gerncia do risco, podendo usar modelos de gerncia do risco ou outros inputs quando necessrios.

45 5.1.1.3 Sadas do Plano de Gerenciamento de Riscos A ltima etapa do plano de gerenciamento do risco a formalizao dos documentos de sada. Estes serviro de entrada para a prxima fase do processo de gerenciamento do risco. Plano de gerncia de riscos: descreve como identificar o risco, a anlise qualitativa e quantitativa, plano de respostas, estrutura do monitoramento e controle a ser realizado durante o ciclo de vida do projeto e o oramento do plano da Gerncia de Riscos. O plano de gerncia de risco no enderea respostas para riscos individuais este alcanado no plano de resposta ao risco. A seguir o contedo detalhado do referido plano a. Contedo do plano de gerncia de riscos: Metodologias: define as abordagens, ferramentas, e fontes de dados que podem ser usados para gerenciar o risco do projeto. Diferentes tipos de avaliaes podem ser apropriados, dependendo do estgio do projeto, quantidade de informao disponvel, e flexibilidade restante na gerncia de risco. Papis e responsabilidades: Definem a liderana, o suporte e os membros da equipe de gerncia de risco para cada ao no plano de gerncia de risco. Equipes de gerncia externa podem agir com mais independncia para analisar de forma imparcial os riscos do projeto. Oramento: estabelece um oramento para a gerncia do risco para o projeto. Momento: define com que frequncia o processo de gerncia do risco ser realizado durante o ciclo de vida do projeto. Ganho e interpretao: mtodos apropriados de interpretao e ganho para identificar o momento e o tipo de anlise de quantificao e qualificao do risco em que comea a ser realizado. Critrios. Os critrios que diro que o risco est de acordo, quem e de que maneira. O dono do projeto, cliente ou o patrocinador podem ter diferentes critrios de risco. Os formulrios com o objetivo dos critrios de aceitao pelo qual a equipe medir a eficincia da execuo do plano de resposta ao risco.

46 Formatos de relatrios: Definem como os resultados do processo de gerncia do risco sero documentados, analisados e comunicados para a equipe do projeto, partes envolvidas, patrocinador e outros. Investigao: documentos relativos s observaes das atividades de risco sero registrados para o benefcio do projeto, futuras necessidades, e lies aprendidas. Eles serviro de base para a auditoria dos processos.

5.1.2 Identificao de Riscos A identificao dos riscos visa especificar todos os riscos que podem afetar o projeto, documentando as suas caractersticas. Participam desta atividade: o gerente de projetos, membros da equipe, especialistas no assunto (externos ao projeto), clientes e usurios finais, todos devem ser incentivados a identificar os riscos e ela dever ser feita durante todo o projeto, pois os riscos so mutveis ao longo da execuo do projeto. (ALENCAR, 2006)

5.1.2.1 Principais Entradas de Identificao de Riscos

So as principais entradas de informaes para identificao dos riscos: declarao do escopo e plano de gerenciamento de riscos as sadas do planejamento definio dos riscos de acordo com as categorias e informaes histricas de projetos anteriores ou banco de dados comerciais, estudos acadmicos, benchmarking, e outros estudos publicados podem estar disponveis para pesquisa. 5.1.2.2 Tcnicas e Ferramentas So as principais tcnicas e ferramentas de identificao do risco: Reviso da documentao: consiste na reviso do escopo do projeto como um todo e detalhadamente, pesquisa em arquivos de projetos anteriores e outras informaes. Tcnicas de informaes garantidas: exemplo de tcnicas de obteno de informao usadas para identificar os riscos:

a.

Brainstorming uma das tcnicas de identificao de risco mais utilizadas. A meta obter uma lista de riscos bem abrangente que possa

47 ser dirigida mais tarde para os processos qualitativos e quantitativos da anlise de risco. (PMI, 2004; GURGEL, 2007; DINSMORE, 2005) A equipe do projeto normalmente apresenta um brainstorming, embora um conjunto de especialistas multidisciplinar possa desenvolver esta tcnica tambm. Sob a liderana de um facilitador, estas pessoas geram idias sobre o risco do projeto. Fontes de risco so identificadas num escopo amplo e anunciadas para que todos possam examinar durante a reunio. Riscos so ento categorizadas pelo tipo de risco, e se suas definies esto precisas. As quatro principais regras do brainstorming so: I. Crticas so rejeitadas: Esta provavelmente a regra mais importante. O princpio do julgamento no pode operar. A falha do grupo ao cumprir esta regra a razo mais crtica para que a sesso de brainstorming no obtenha sucesso. Esta regra aquela que primariamente diferencia um brainstorming clssico dos mtodos de conferncia tradicionais. II. Criatividade bem-vinda: Esta regra utilizada para encorajar os participantes a sugerir qualquer idia que lhes venha mente, sem preconceitos. necessrio deixar as inibies para trs enquanto as idias so geradas. Quando se segue esta regra, cria-se automaticamente um clima de brainstorming apropriado. III. Quantidade necessria: Quanto mais idias forem geradas, maior a possibilidades de encontrar uma idia valiosa. Quantidade gera qualidade. IV. Combinao e aperfeioamento so necessrios: O objetivo desta regra encorajar a gerao de idias adicionais para a construo e reconstruo sobre as idias dos outros. b. Tcnica Delphi: trata-se de um mtodo que permite descobrir opinies de especialistas em um assunto determinado como risco do projeto. Os

48 especialistas em risco do projeto so identificados, mas participam anonimamente. (PMI, 2004; GURGEL, 2007; DINSMORE, 2005).

I. Painel Delphi: um facilitador atravs da realizao de uma srie de questionrios solicita idias sobre os riscos de projeto importantes. Os resultados depois de agregados so enviados aos especialistas para reformular as proposies apresentadas e incluir comentrios adicionais. Um consenso com relao aos principais riscos do projeto pode ser alcanado em algumas etapas desse processo. A tcnica Delphi ajuda a reduzir influncias nas informaes e evita que qualquer pessoa sofra uma influncia indevida como consequncia.O nmero de rondas trabalhadas varia de acordo com o grau de consenso atingido pelos especialistas, sendo esse consenso entendido a nvel individual. Ou seja, se houver uma discrepncia muito elevada na opinio de um dado especialista nas vrias rondas, no se poder chegar a um consenso. As opinies podem, no entanto variar de ronda para ronda, uma vez que como so introduzidas novas questes em cada questionrio, o especialista pode mudar de opinio em relao s questes que considera mais relevante. Este mtodo distingue-se essencialmente por trs caractersticas bsicas, o anonimato, a integrao com feedback controlado e as respostas estatsticas do grupo. As principais caractersticas do mtodo Delphi consistem ento, na utilizao de um painel de peritos para obter conhecimento, o fato de os participantes no terem confrontao frente a frente, a garantia de anonimato das respostas dadas pelos participantes e o uso de ferramentas estatsticas simples para identificar padres de acordo. Com efeito, uma das grandes vantagens deste mtodo permitir que pessoas que no se conhecem, desenvolvam um projeto comum, e sem ter que revelar as suas opinies uns aos

49 outros, cheguem a um acordo geral sobre uma dada rea de interesse. A figura 6 apresenta um organograma que demonstra os passos da tcnica Painel Delphi.

Incio

Realizao de um questionrio/inqurito

Anlise das Respostas do questionrio

Sim

Atingiu-se consenso?

No

Tabelamento das respostas e entrega da informao ao grupo

Desenvolvimento do questionrio seguinte

Compilao dos resultados num resumo final

Fim

Figura 6 Fluxograma do Painel Delphi. Fonte: GURGEL (2007)

c. Entrevistas: uma tcnica simples, porm os riscos podem ser identificados quando entrevistamos gerentes de projeto ou especialistas no assunto, que baseados em suas experincias podem fornecer informaes teis para o entrevistador. Devem-se escolher indivduos apropriados, deixando-os a par do projeto, fornecendo o escopo e a lista de hipteses. (PMI, 2004; GURGEL, 2007 e DINSMORE, 2005)

50 d. Anlise SWOT (Foras Strengths; Fraquezas Weaknesses; Oportunidades - Opportunities e Ameaas - Threats): uma ferramenta simples utilizada para fazer a anlise do ambiente, podendo ser ampliao da base para identificao de riscos, onde as foras e fraquezas se relacionam com o ambiente interno e as oportunidades e ameaas esto relacionadas a fatores externos. O ambiente interno pode ser controlado atravs de polticas implantadas dentro da organizao, ressaltando os pontos fortes e controlando ou minimizando os pontos fracos. O ambiente externo foge do controle dos dirigentes, porm o fato de no poder controlar no significa que no se pode conhec-lo e monitor-lo com frequncia, tentando aproveitar as oportunidades e tentar se planejar para evitar as ameaas. A anlise SWOT pode servir para analisar um projeto ou parte de um projeto, dividindo as grandes reas. Realizam-se os seguintes questionamentos no quadro 4. Quadro 4 Anlise SWOT, pontos fortes x pontos fracos.
Ambiente Interno
PONTOS FORTES PONTOS FRACOS

1. 2. 3.

O que voc (empresa/equipe/pessoa) faz bem? Que recursos especiais voc possui e pode aproveitar ? O que outros (empresas/equipes/pessoas) acham que voc faz bem?

1. No que voc pode melhorar? 2. Onde voc tem menos recursos que os outros? 3. O que outros acham que so suas fraquezas?

Ambiente Externo
OPORTUNIDADES 1. Quais so as oportunidades externas que voc pode identificar? Que tendncias e novas tecnologias voc pode aproveitar em seu favor? 1. AMEAAS Que ameaas (leis, regulamentos, concorrentes) podem lhe prejudicar ? O que seu concorrente est fazendo?

2.

2.

Fonte: GURGEL (2007)

No quadro 5 demonstrado um caso de adoo da analise SWOT em uma empresa.

51

Quadro 5 Anlise de Risco SWOT Uso do PMBOOK em novos Projetos.

Fonte: GURGEL (2007) Com apenas alguns minutos de reunio, o gerente do projeto num clima de informalidade e simplicidade levanta os primeiros dados e ainda aproxima o gerente da sua equipe ou cliente. Cada sentena uma hiptese considerada como verdadeira, logo, cada premissa precisa ser levantada, validada e colocada em uma lista de riscos, levando em considerao o impacto na tomada de decises, se alguma premissa se mostrar falsa. Quanto mais informao se obtm sobre cada item identificado, maior a chance de se tomar a deciso certa. Aps a anlise do quadro 5, novos pontos vo surgindo antes de uma tomada de deciso. A expanso de um item na anlise de SWOT migra para o uso de um Mapa Mental como na figura 7.

52

Figura 7 Modelo de Analise de Riscos SWOT Mapas Mentais. Fonte: GURGEL (2007) Uma anlise SWOT pode trazer organizao que a utiliza um conjunto de informaes importantes para a tomada de decises, quando realizada atravs de Mapas Mentais, temos condies de conduzir reunies eficazes com clientes e membros da equipe levantando pontos que iro nos auxiliar em uma anlise mais completa. (PMI, 2004; GURGEL, 2007)

Para completar, os Mapas Mentais nos permitem rapidamente ampliar a viso que temos dos pontos registrados durante a reunio, de forma a identificarmos seus componentes mais importantes (como em uma estrutura analtica de projetos) e at mesmo trabalhar em uma rpida diviso de tarefas entre os participantes de uma reunio para uma efetiva tomada de deciso. e. Checklist: uma ferramenta para a identificao de risco que elaborada com base em informaes de um histrico e no conhecimento de projetos anteriores, similares ou de outras fontes de informao. Porm todo o cuidado pouco para no se limitar s categorias da lista Deve-se ter

53 ateno para explorar itens que no aparecem em um checklist padro caso eles paream importantes ao projeto especfico. O checklist deve conter os itens de todos os tipos possveis de riscos do projeto. importante conferir o checklist como um passo formal de cada procedimento de fechamento de projeto para melhorar a lista de riscos potenciais, e das descries dos riscos.

f. Anlise das hipteses ou premissas: Cada projeto concebido e desenvolvido baseado em um conjunto de hipteses, cenrios, ou dedues. Anlise de hipteses uma tcnica que explora a validade das hipteses. Ela identifica riscos ao projeto como imperfeies, inconsistncias, ou falta de hipteses. g. Diagrama de causa e efeito tambm conhecido como diagrama Ishikawa ou Espinha de Peixe (Fishbone) uma tcnica usada para identificar e arranjar as causas de um evento ou um problema ou um resultado. O diagrama de causa e efeito ilustra hierarquicamente as causas de um problema de acordo com o seu nvel de detalhe ou importncia e um resultado dado. Sua representao pode ser observada na figura 8. A utilizao do diagrama de causa e efeito tem boa aplicao na identificao de causas de riscos.(GURGEL, 2007)

54

Efeito

Figura 8 Diagrama de Ichikawa ou Fishbone. Fonte: GURGEL (2007) h. Digramas de influncia uma representao grfica do problema mostrando influncias, time ordering de eventos, e outras relaes entre variveis e conseqncias. A figura 9 apresenta um exemplo do diagrama de influncias.

Figura 9 Diagrama de Influncia. Fonte: GURGEL (2007)

55 5.1.2.3 Sadas da Identificao dos Riscos So as principais sadas no processo de identificao dos riscos: Os Registros dos riscos: so compostos pelas listas dos riscos identificados, lista de possveis respostas e atualizao da Categoria dos Riscos. Os Detonadores: algumas vezes chamados de sintomas de risco ou sinais de advertncia, so indicaes que um risco ocorreu ou est preste a ocorrer. Por exemplo: O fracasso no cumprimento dos marcos estabelecidos pode ser um sinal de advertncia de atraso no cronograma. A Entrada em outros processos: Identificao de um risco pode indicar a necessidade de uma ao futura em outra rea. Por exemplo, o escopo pode no ter detalhes suficientes que permitam a identificao adequada de riscos, ou o cronograma pode no estar completo ou inteiramente lgico.

5.1.3 Anlise Qualitativa de Riscos A anlise qualitativa o processo de avaliar o impacto e a probabilidade dos riscos identificados. Permite qualificar e classificar os riscos em funo do seu efeito potencial individual e prioriz-los em funo do seu efeito potencial para o projeto como um todo. As organizaes podem melhorar o desempenho do projeto de modo eficaz se concentrando nos riscos de alta prioridade. A anlise qualitativa de riscos avalia a prioridade dos riscos identificados usando a probabilidade de eles ocorrerem, o impacto correspondente nos objetivos do projeto se os riscos realmente ocorrerem, alm de outros fatores, como o prazo e tolerncia a risco das restries de custo, cronograma, escopo e qualidade do projeto. (PMI, 2004) A anlise qualitativa de riscos normalmente uma maneira rpida e econmica de estabelecer prioridades para o planejamento de respostas a riscos, e estabelece a base para a anlise quantitativa de riscos, se esta for necessria. A anlise qualitativa de riscos deve ser reexaminada durante o ciclo de vida do projeto para acompanhar as mudanas nos riscos do projeto. (PMI, 2004)

56 5.1.3.1 Principais Entradas da Anlise Qualitativa dos Riscos So as principais entradas de informaes para a realizao da anlise qualitativa dos riscos: Os Ativos de processos organizacionais: deve-se utilizar dos dados de lies aprendidas em projetos passados; A Declarao do escopo do projeto: atravs desse documento pode-se avaliar se o projeto de alta complexidade, recorrentes ou de baixa complexidade Portanto focar-nos mais complexos que tendem a ter mais incertezas. O Plano de gerenciamento de riscos: no plano de gerenciamento de riscos esto inclusas funes e responsabilidades para conduzir o gerenciamento de riscos, oramentos e atividades do cronograma para gerenciamento de riscos, categorias de risco, definio de probabilidade e impacto, a matriz de probabilidade e impacto e reviso das tolerncias a risco das partes. Todas essas entradas so geralmente adequadas ao projeto durante o processo, por isso devem ser revistos quando da Anlise qualitativa. O Registro de riscos: contm a lista de riscos identificados, nela so descritos os riscos identificados, incluindo suas causas-raiz e as premissas incertas do projeto.

5.1.3.2 Tcnicas e Ferramentas So as principais tcnicas e ferramentas utilizadas na anlise qualitativa do risco: A Avaliao de probabilidade e impacto de riscos: investiga a probabilidade de cada risco especfico ocorrer e o efeito potencial sobre um objetivo do projeto, como tempo, custo, escopo ou qualidade, inclusive os efeitos negativos das ameaas e os efeitos positivos das oportunidades. A coleta de dados em entrevistas ou reunies com participantes e at especialistas de fora do projeto ajudam a avaliar a probabilidade e o impacto do risco. Tudo dever estar registrado para uma futura pesquisa A Matriz de probabilidade e impacto: normalmente realizada usando uma tabela de pesquisa ou uma matriz de probabilidade e impacto. Essa matriz especifica as combinaes de probabilidade e impacto que levam classificao dos riscos como de prioridade baixa, moderada ou alta.

57 a. Metodologia: Cada organizao determina as combinaes de probabilidade e impacto e definem os riscos como ma figura 10. Risco alto (condio vermelha); Risco moderado (condio amarela) e Risco baixo (condio verde).

Probabilidade Alto Impacto Alto Mdio Baixo Alto Alto Mdio Mdio Alto Mdio Baixo Baixo Mdio Baixo Baixo

Figura 10 Matriz de probabilidade e impacto em cores vermelho, amarelo e verde. Fonte: Elaborada pelo autor.

b. Ou uma matriz em preto e branco, essas condies podem ser indicadas pelos diferentes tons de cinza de acordo com a figura 11. a rea cinza escuro (com os nmeros mais altos) representa risco alto; a rea cinza mdio (com os nmeros mais baixos) representa risco baixo; e a rea cinza claro (com nmeros intermedirios) representa risco moderado.

Probabilidade Alto Impacto Alto Mdio Baixo Alto Alto Mdio Mdio Alto Mdio Baixo Baixo Mdio Baixo Baixo

Figura 11 Matriz de probabilidade e impacto em tons de branco e preto. Fonte: Elaborada pelo autor.

58 A pontuao do risco ajuda a orientar as respostas a riscos. Por exemplo, riscos que, se ocorrerem, tero um impacto negativo nos objetivos (ameaas) e que se encontram na zona de alto risco (cinza escuro) da matriz podem exigir aes prioritrias e estratgias agressivas de resposta. As ameaas na zona de baixo risco (cinza mdio) podem no exigir nenhuma ao de gerenciamento pr-ativo, alm da sua colocao em uma lista de observao ou da sua adio a uma reserva para contingncias. Isso ocorre de forma similar para as oportunidades. Portanto, devem-se priorizar as oportunidades na zona de alto risco (cinza escuro) que podem ser obtidas mais facilmente e oferecem o maior benefcio. As oportunidades na zona de baixo risco (cinza mdio) devem ser monitoradas. A avaliao da qualidade dos dados sobre os riscos precisam ser exatos e imparciais para serem confiveis. A anlise da qualidade dos dados sobre riscos uma tcnica para avaliar o grau de utilidade dos dados sobre riscos para o gerenciamento de riscos. Ela envolve examinar at que ponto o risco entendido e tambm a exatido, qualidade, confiabilidade e integridade dos dados sobre riscos. O uso de dados sobre riscos de baixa qualidade pode levar a uma anlise qualitativa de riscos de pouca utilidade para o projeto. Se a qualidade dos dados no for aceitvel, talvez seja necessrio coletar dados de melhor qualidade. A coleta das informaes sobre riscos muitas vezes uma atividade difcil e consome mais tempo e recursos do que os originalmente planejados. a. Categorizao de riscos: Os riscos do projeto podem ser categorizados por fontes de risco (por exemplo, usando a EAR)4, pela rea do projeto afetada (por exemplo, usando a EAP) ou por outra categoria til (por exemplo, fase do projeto) para determinar as reas do projeto mais expostas aos efeitos da incerteza. O agrupamento dos riscos por causasraiz comuns pode possibilitar o desenvolvimento de respostas a riscos eficazes. b. Avaliao da urgncia do risco: A abordagem dos riscos que exigem respostas em curto prazo pode ser considerada mais urgente. Os indicadores de prioridade podem incluir o tempo para efetuar uma resposta a riscos, sintomas e sinais de alerta, e a classificao dos riscos.
4

O EAR (Estrutura Analtica dos Riscos) uma representao grfica que apresenta os grupos e subgrupos do projeto de forma hierrquica onde podem ser encontrados os possveis riscos desenvolvimento do software.

59 5.1.3.3 Sadas da Anlise Qualitativa de Riscos So as sadas no processo da anlise qualitativa dos riscos: Os Registros de riscos: so atualizados com informaes da anlise qualitativa de riscos e esse registro de riscos atualizado includo no plano de gerenciamento do projeto. As atualizaes do registro de riscos a partir da anlise qualitativa de riscos incluem: a. A lista de prioridades dos riscos do projeto de acordo com a sua importncia individual. b. Riscos agrupados por categorias, pois saber onde se concentram os riscos pode aumentar a eficcia das respostas a riscos. c. Lista de riscos que exigem resposta em curto prazo para separar em grupos diferentes os riscos que exigem uma resposta urgente e os que podem ser tratados em uma data posterior. d. Lista de riscos para anlise e resposta adicionais que so para aqueles riscos que necessitam de anlises adicionais, inclusive a anlise quantitativa de riscos, alm de ao de resposta. e. Listas de observao de riscos de baixa prioridade podem ser colocadas em uma lista de observao para serem monitorados continuamente. f. Tendncias dos resultados da anlise qualitativa: conforme a anlise repetida, uma tendncia a riscos especficos pode se tornar evidente e pode fazer com que as respostas a riscos ou a anlise adicional sejam mais ou menos urgentes/importantes. 5.1.4 Anlise Quantitativa do Risco Anlise quantitativa dos riscos tem como objetivo mensurar a probabilidade de ocorrncia dos riscos, suas conseqncias e estimar as implicaes no projeto. Os riscos que foram priorizados no processo da Anlise Qualitativa sero submetidos ao processo da Anlise Quantitativa que ir analisar o efeito desses eventos de risco e atribuir uma classificao numrica a eles. Ela tambm apresenta uma abordagem quantitativa para a tomada de decises na presena da incerteza.

60 Este processo usa tcnicas como a simulao de Monte Carlo e a anlise da rvore de deciso para: Quantificar os possveis resultados do projeto e suas probabilidades. Avaliar a probabilidade de atingir objetivos especficos do projeto. Identificar os riscos que exigem mais ateno quantificando sua contribuio relativa para o risco total do projeto. Identificar metas realistas e alcanveis de custo, cronograma ou escopo, quando fornecidos os riscos do projeto. Determinar a melhor deciso de gerenciamento de projetos quando algumas condies ou resultados forem incertos. Em geral, a anlise quantitativa de riscos segue o processo anlise qualitativa de riscos, embora gerentes de riscos experientes algumas vezes realizem essa anlise diretamente aps a identificao de riscos. Em alguns casos, a anlise quantitativa de riscos pode no ser necessria para desenvolver respostas a riscos eficazes. A disponibilidade de tempo e oramento e tambm a necessidade de declaraes qualitativas ou quantitativas sobre risco e impactos determinaro o(s) mtodo(s) que sero usados em um projeto especfico. A anlise quantitativa de riscos deve ser repetida aps o planejamento de respostas a riscos, e tambm como parte do monitoramento e controle de riscos, para determinar se o risco total do projeto diminuiu de forma satisfatria. As tendncias podem indicar uma necessidade de aumento ou diminuio das aes de gerenciamento de riscos. So entradas do processo Planejamento de respostas a riscos. 5.1.4.1 Principais Entradas da Anlise Quantitativa dos Riscos So as principais entradas no processo da Anlise Quantitativa dos Riscos: Os Ativos de processos organizacionais: As informaes sobre projetos anteriores semelhantes e terminados. A Declarao do escopo do projeto: tem a descrio dos principais objetivos do projeto, permitindo que a equipe do projeto realize um planejamento mais detalhado, servindo de orientao para a equipe do projeto durante a execuo, auxiliando a avaliar as solicitaes de mudana e verificar se estas esto dentro ou fora dos limites estabelecidos no projeto.

61 O Plano de gerenciamento de riscos: Os principais elementos do plano de gerenciamento de riscos para a anlise quantitativa de riscos incluem funes e responsabilidades para realizar gerenciamento de riscos, oramentos e atividades do cronograma para gerenciamento de riscos, categorias de risco, a EAR e reviso das tolerncias a risco das partes interessadas. O Registro de riscos: os principais itens do registro de riscos para a anlise quantitativa de riscos incluem a lista de riscos identificados, a classificao relativa ou lista de prioridades de riscos do projeto e os riscos agrupados por categorias.

O Plano de gerenciamento do projeto inclui: a. Plano de gerenciamento do cronograma do projeto. Define o formato e estabelece os critrios de desenvolvimento e controle do cronograma do projeto. b. Plano de gerenciamento de custos do projeto. Define o formato e estabelece os critrios de planejamento, estruturao, estimativa, oramentao e controle dos custos do projeto. 5.1.4.2 Ferramentas e Tcnicas So as principais tcnicas e ferramentas utilizadas na anlise quantitativa do risco.

As Entrevistas: as tcnicas de entrevistas so usadas para quantificar a probabilidade e o impacto dos riscos nos objetivos do projeto. As informaes necessrias dependem do tipo de distribuies de probabilidades que ser usado. A Opinio especializada: os especialistas no assunto, internos ou externos organizao, como especialistas em engenharia e estatstica, validam os dados e as tcnicas. A Anlise de sensibilidade: a anlise de sensibilidade ajuda a determinar quais riscos apresentam maior impacto potencial no projeto. Ela examina a extenso com que a incerteza de cada elemento do projeto afeta o objetivo que est sendo examinado quando todos os outros elementos incertos so mantidos em seus valores de linha de base. Uma representao tpica da anlise de sensibilidade o diagrama de tornado, que til para comparar a importncia relativa das variveis que possuem um alto grau de incerteza com as que so mais estveis.

62 A Modelagem e simulao: uma simulao do projeto utiliza um modelo que traduz as incertezas especificadas em um nvel detalhado do projeto para seu impacto potencial nos objetivos do projeto. As simulaes so normalmente realizadas usando a tcnica de Monte Carlo.

5.1.4.3 Sadas Anlise Qualitativa de Riscos So as sadas no processo da anlise quantitativa dos riscos: O Registro de riscos iniciado no processo Identificao de riscos e atualizado na anlise qualitativa de riscos. Ele novamente atualizado na anlise quantitativa de riscos. Os registros dos riscos tm as seguintes componentes principais: a. Anlise probabilstica do projeto. So feitas estimativas dos possveis resultados do cronograma e custo do projeto, listando as datas de trmino e custos possveis juntamente com seus nveis de confiana associados. Essas sadas, normalmente expressas como uma distribuio cumulativa usada em conjunto com as tolerncias a risco das partes interessadas para permitir a quantificao das reservas para contingncias dos custos e de tempo. b. Lista priorizada de riscos quantificados. Esta lista de riscos inclui os que representam a maior ameaa ou oferecem a maior oportunidade ao projeto. Esses incluem os riscos que exigem a maior contingncia de custo e os riscos com maior probabilidade de influenciar o caminho crtico. c. Tendncias dos resultados da anlise quantitativa de riscos. Conforme a anlise repetida, pode ficar evidente uma tendncia que leva a concluses que afetam as respostas a riscos. 5.1.5 Planejamento de Respostas a Riscos O planejamento de respostas a riscos o processo que ir fornecer as opes e quais as aes sero tomadas para melhorar oportunidades e reduzir ameaas para os objetivos do projeto. Os riscos identificados so devidamente endereados para indivduos ou partes envolvidas com suas responsabilidades definidas. A eficcia do

63 planejamento de resposta determinar diretamente se o risco do projeto cresce ou diminui. O plano de resposta ao risco deve ser apropriado para a severidade do risco, estimando um custo real, o tempo necessrio para ser bem-sucedido, dentro de um contexto realstico, acordado por todas as partes envolvidas e designado um responsvel. Frequentemente requerida a seleo da melhor resposta dentro das vrias opes. 5.1.5.1 Entradas do Planejamento de respostas a Riscos A entrada do Planejamento de respostas a riscos o Plano de Gerncia de Risco, conforme descrito nas Sadas do Plano de gerenciamento de Riscos, item 5.1.1.3. 5.1.5.2 Tcnicas e Ferramentas para o Planejamento de Resposta ao Risco Aps a elaborao das anlises pode-se chegar concluso de vrias respostas estratgicas ao risco. Deve-se relacionar a melhor estratgia para cada risco previsto e para se implementar essa estratgia algumas aes especficas devem ser desenvolvidas. interessante traar uma estratgia principal e uma segunda alternativa, caso a primeira no venha a funcionar. Evitar o risco: Quando o projeto ainda est em seu inicio, pode-se identificar um risco, o que j suficiente para mudar parte do projeto a fim de proteger os objetivos do projeto. Os eventos de risco podem ser evitados atravs da elaborao de planos de contingncia, obtendo-se informaes, melhorando a comunicao ou consultando especialistas. Para evitar o risco, tomamos como exemplo algumas alternativas: uma atividade de alto risco pode ter o escopo reduzido, acrescentar recursos ou tempo ou evitar um fornecedor desconhecido. Planos de Contingncia: So planos usados para minimizar os danos causados por riscos previamente conhecidos. So estabelecidos gatilhos (trigers) que ao identificar o risco acontecendo ativam os planos de continncia. Um exemplo o acidente de uma aeronave nas proximidades de um aeroporto. No plano de contingncia conta com a ao rpida dos bombeiros do aeroporto e do corpo de bombeiros da cidade, so acionados as ambulncias e policiais para o local do acidente e os hospitais para receber os feridos.

64 Transferir riscos: Alguns riscos podem ter responsabilidade transferida a uma empresa terceirizada ou ao cliente, desde que estes estejam previamente cientes do fato. Transferir no significa dizer que o risco foi eliminado. Na verdade foi dado a um terceiro a responsabilidade de gerenciar isto. Geralmente os contratos so usados para transferir a responsabilidade para um terceiro, e quase sempre envolve valores financeiros para que este assuma o risco, podendo impactar no custo do projeto. Mitigar os riscos: mitigar significa: aliviar, suavizar, atenuar. A ao de mitigao a utilizao de mtodos que procura reduzir a probabilidade ou conseqncias de um fator de risco.Uma caracterstica que so aes realizadas antes do fator de risco se tornar realidade. A mitigao de risco pode envolver condies de mudanas em que a probabilidade de ocorrncia de risco seja reduzida. Quando no for possvel reduzir a probabilidade, a mitigao da resposta pode enderear o impacto do risco para determinar a o grau de severidade. Aceitar o risco: existe a possibilidade de se aceitar o risco quando a equipe que decide no mudar o plano do projeto ou no possvel nenhuma ao para identificar uma estratgia de resposta apropriada ao plano do projeto. Como exemplo o caso da explorao espacial da Lua. Existe sempre o risco de algum problema na propulso da nave no caminho da lua. Como plano de contingncia poderia se construir uma segunda nave, apenas para resgate. Como invivel o custo desta nave de emergncia, aceitar o risco deixa de ser opo. Encerrar o Projeto: quando o projeto tem a probabilidade de um risco alto e de custo muito elevado, que no vale a pena transferir, mitigar ou aceit-lo, faz-se um estudo junto s outras gerncias para decidir ento encerrar o projeto.

5.1.5.3 Sadas para o Planejamento de Resposta ao Risco So as sadas para o Planejamento de Resposta ao Risco: O Plano de resposta ao risco: consiste no registro do risco e deve ser escrito no nvel de detalhe em que as aes sero tomadas. Nele devem estar inclusos: a. os riscos identificados, suas descries, a(s) rea(s) do projeto afetada(s) suas causas e como ele pode afetar os objetivos do projeto; b) os donos dos riscos e designao de responsabilidades; b. os resultados dos processos de anlises quantitativas e qualitativas de risco;

65 c. acordos de respostas incluem evitar, transferir, mitigar ou aceitar para cada risco no plano de resposta ao risco; d. o nvel de risco residual esperado para ser concludo depois de a estratgia ser implementada; e. aes especficas para implementar a estratgia de resposta escolhida.; f. g. oramentos e tempos para as respostas; Planos de contingncia e planos de retrocedimento.

Os Riscos residuais: so aqueles que restam depois de terem sido tomadas respostas de evitar, transferir ou mitigar. Eles tambm incluem riscos sem importncia que tm de ser aceitos e endereados. Os Riscos secundrios: riscos, que surgem como um resultado direto da implementao da resposta ao risco. Eles devem ser identificados e a sua resposta planejada. Os Acordos contratuais: podem fazer parte de cada especificao de responsabilidade para riscos especficos atravs de seguros, servios e outros itens apropriados para evitar ou mitigar ameaas. As Necessidades de montante de reserva de contingncia: a anlise probabilstica do projeto e os riscos limiares ajudam o gerente de projeto a determinar a quantia de reserva ou contingncia necessria para reduzir o risco de ultrapassar o nvel aceitvel para a organizao dos objetivos do projeto. Os Inputs para outros processos: a maioria das respostas ao risco envolve gastos de tempos adicionais, custo ou recursos e requer mudanas do plano de projeto. Organizaes querem garantias que o gasto justificvel pelo nvel de reduo do risco. Estratgias alternativas devem alimentar nos processos apropriados em outras reas de conhecimento. Os Inputs para um plano de projeto revisado: os resultados do processo de planejamento devem ser incorporados no plano de projeto, para assegurar que aes acordadas sejam implementadas e monitoradas como parte de um projeto em andamento.

66 5.1.6 Monitoramento e Controle dos Fatores de Risco Durante o decorrer do projeto a preocupao com o risco no diminui, pois os riscos encontrados no inicio do projeto devem ser monitorados at sua concluso. H outro processo que deve continuar que a busca por novos riscos: alguns ainda no identificados, novos riscos ocasionados por mudanas no projeto e riscos residuais. Conforme demonstrado na Figura 12 Processo Cclico de Gerncia de Risco:

Identificao dos riscos

Avaliaes de Riscos

Monitoramento dos fatores de risco

Planejamento de Aes de Tratamento dos Riscos

Figura 12 Processo Cclico de Gerncia de Risco.

Fonte: GURGEL (2007) Monitoramento e controle do risco um processo contnuo para o ciclo de vida do projeto. Os processos de monitoramento so considerados bons, quando do informaes relativas s tomadas decises eficazes para conter o avano de ocorrncias de riscos. preciso que haja comunicaes entre todas as partes envolvidas, pois elas so necessrias para avaliar periodicamente a aceitabilidade do nvel de risco no projeto. A proposta de monitoramento de risco contm os seguintes questionamentos: As respostas ao risco esto sendo implementadas como planejadas? As aes de respostas ao risco esto eficazes como esperadas ou se novas respostas devem ser desenvolvidas? As hipteses ainda so vlidas? A anlise de tendncias da exposio do risco tem mudado as prioridades? Ocorreu algum detonador do risco? As polticas e procedimentos adequados esto sendo seguidos?

67 Tm ocorrido ou surgido riscos que no foram identificados anteriormente?

O Controle do risco pode envolver escolha de algumas alternativas como: Implementar um plano de contingncia; Tomar aes corretivas ou; Re-planejar o projeto.

O responsvel pela resposta ao risco dever relatar periodicamente para o gerente do projeto e para o lder da equipe a eficcia do plano, alguns efeitos no previstos e alguma necessidade de correo no curso para mitigar o risco. Todas as gerncias tm o mesmo objetivo: o sucesso do projeto, pois os fatores de risco esto alocados dentro de todas as reas. Sendo assim se faz necessria uma integrao das informaes coletadas e a realizao de um trabalho em conjunto. 5.1.6.1 Entradas para o Monitoramento e Controle do Risco So as entradas para o monitoramento e controle dos riscos: O Plano de gerncia do risco. O plano de gerncia do risco conforme descrito nas Sadas do item 5.1.1.3 O Plano de resposta ao risco conforme descrito nas Sadas do item 5.1.1. A Comunicao do projeto: resultados do trabalho da Gerncia de Comunicaes e outros registros do projeto descritos fornecem informao sobre o desempenho e riscos do projeto. Relatrios comumente usados para monitorar e controlar riscos inclui Logs de Pendncias, Relao de Ocorrncias, Listas de Itens de Aes, Advertncias de Risco ou Avisos de Escalada. (definir esses relatrios) A Identificao e anlise de risco adicional: como o desempenho do projeto medido e informado, riscos potenciais no identificados anteriormente podem vir tona. Devemos implementar os seis ciclos dos processos do risco para estes novos riscos. As Mudanas de escopo5: as mudanas de escopo freqentemente requerem novas anlises e planos de resposta.

Uma mudana do escopo qualquer modificao no escopo inicial do projeto, conforme definido pela EAP aprovada. As mudanas do escopo do projeto, freqentemente, exigem ajustes no custo, no prazo, na qualidade ou em outros objetivos do projeto. Mudanas do escopo so retornos (feedback) ao longo do processo, os documentos tcnicos e de planejamento so atualizados conforme necessidade, e as partes envolvidas so informadas conforme for apropriado.

68 5.1.6.2 Tcnicas e Ferramentas para o Monitoramento e Controle do Risco So as tcnicas e ferramentas utilizadas para o monitoramento e controle dos riscos: As Auditorias da resposta ao risco do projeto: auditores examinam e documentam a eficcia da resposta ao risco. As auditorias de risco so realizadas durante o ciclo de controle de risco do projeto. As Revises peridicas do risco do projeto: revises do risco do projeto devem ser regularmente programadas em todas as reunies do projeto pois a classificao e priorizao do risco podem mudar durante o ciclo de vida do projeto. Algumas mudanas podem requerer anlises de qualificao e quantificao adicionais. A Anlise do trabalho realizado: o trabalho realizado usado para avaliar o desempenho do projeto versus um plano inicial (baseline - definir). Os resultados de uma anlise do trabalho realizado podem indicar desvio potencial de custo para concluir o projeto e os objetivos do cronograma. Quando um projeto desvia significativamente do plano original, devem ser realizadas novas anlises e atualizaes do risco. Esta anlise uma ferramenta contida na fase do Relato do Desempenho que se encontra dentro da Gerncia de Comunicao. A Tcnica de medio do desempenho: a tcnica de medio do desempenho compara a realizao tcnica executada do projeto com a realizao planejada. Demonstrao de desvios como a no funcionalidade planejada para um milestone, pode implicar um risco para realizao do escopo do projeto. O Planejamento adicional de resposta ao risco: ele se faz necessrio para controlar o risco se, um risco emergente que no havia sido previsto no plano de resposta ao risco ou o impacto dele nos objetivos, maior que o esperado, logo a resposta planejada pode no ser adequada. 5.1.6.3 Sadas do Monitoramento e Controle do Risco Ainda, de acordo com o PMBOK so as sadas do monitoramento e controle dos riscos: (PMI, 2004) Os Planos de contornos: contornos so respostas no planejadas para riscos emergentes que no foram identificados ou aceitos anteriormente. Os desvios devem ser documentados e incorporados ao plano do projeto e ao plano de resposta ao risco.

69 As Aes corretivas: consiste de realizar o plano de contingncia ou contornos. As Requisies de mudanas do projeto: para implementar planos de contingncia ou contornos frequentemente feito um requerimento para mudar o plano de projeto para responder aos riscos. O resultado a emisso de uma requisio de mudana o qual est inserido na Gerncia de Integrao e monitorada na fase de Controle Integrado de Mudana. As requisies de mudanas podem ocorrer de diferentes formas: orais ou escritas, diretas ou indiretas, de fonte externa ou interna, e opcionais ou judicialmente impostas. As Atualizaes para o plano de resposta ao risco: os riscos podem ocorrer ou no. Os riscos que se concretizam devem ser documentados e avaliados. Por isso os controles de riscos podem reduzir o impacto ou probabilidade dos riscos identificados. A classificao do risco deve ser verificada para que novos riscos, e riscos importantes possam ser controlados de forma correta. Os riscos que no ocorreram devem ser documentados e encerrados no plano de risco do projeto. O Banco de dados do risco: o uso do banco de dados ir organizar o gerenciamento do risco gerando formulrios de programas de lies aprendidas. Dever existir um responsvel que cuida de coletar, manter e analisar dados garantindo o uso nos processos de gerncia de risco. As Atualizaes para o cheklist da identificao do risco: os cheklists com as experincias do projetor devero estar sempre atualizados, pois podero auxiliar o gerenciamento de futuros projetos.

70

6. GERNCIA DE RISCOS NO PMBOK X GERNCIA DE RISCOS NO DESENVOLVIMENTO DE SOFTWARE

A gerncia de desenvolvimento de software em um mbito geral, so metodologias, guias, frameworks entre outras formas de gesto de desenvolvimento de software. Ao compar-las, especificamente com o tratamento do risco, observamos que a maioria j tem uma forma de tratamento, est desenvolvendo ou tem a possibilidade de desenvolver.

O CMMI no define como os processos devem ser implementados, prescreve suas caractersticas estruturais e semnticas em termos de objetivos e de grau de qualidade com que o trabalho deve ser realizado. Constitui tanto um modelo de capacidade como um modelo de maturidade, onde mensurada a capacidade em prticas individuais. O MSF (Microsoft Solutions Framework) uma metodologia de

desenvolvimento gil de Software. Isso no significa que foi desenvolvido para projetos pequenos e simples. uma metodologia cclica, assim divide o projeto em questo em ciclos demarcando com milestones.6 A caracterstica que marca o MSF e aplicvel a qualquer gesto de desenvolvimento so seus oito princpios:

I. Comunicao aberta II. Trabalhar em prol de uma viso compartilhada III. Capacitar os membros da equipe IV. Estabelecer uma responsabilidade clara e partilhada V. Concentrar os esforos na entrega do produto, uma prestao de valor VI. Manter a agilidade dos processos e estar preparado para mudanas VII. Manter o foco na qualidade continuamente VIII. Aprender com todas as experincias

O termo uma expresso inglesa (referente a um marco quilomtrico) utilizada como designao de um ponto de controle em um cronograma, atravs da definio de pontos de checagem ou marcos de desenvolvimento. Representa a concluso de um conjunto de tarefas ou fase.

71 O modelo de gesto RUP (Rational Unified Process) uma metodologia orientada a objetos, isso significa que sua estrutura baseada na composio e interao de diversas unidades. Sua concepo foi voltada para grandes projetos, mas pode-se customiz-lo para projetos menores e menos complexos. Seu projeto e sua documentao utilizam a notao UML (Unified Modeling Language) para ilustrar os processos em ao. O PMBOK um guia genrico para gerncia de projetos, pois adaptvel a diferentes tipos de projetos. O grande diferencial em utilizar o PMBOK na gerncia de riscos de desenvolvimento de software porque ele um guia completo, pois alm de explicar como e por que devem ser gerenciados os riscos, ele contm as prticas que devem ser utilizadas bem como as ferramentas e tcnicas de gesto. Para gerir com responsabilidade o desenvolvimento de software fundamental a utilizao das prticas de gerenciamento de riscos contidas no PMBOK, pois maiores sero suas probabilidades de alcanar o to esperado sucesso. (ROCHA e BELCHIOR, 2004) O quadro 6 apresenta um mapeamento da gesto do risco nas formas de administrar o desenvolvimento de software. Foi tomado como base o PMBOK e feito uma relao com o CMMI-SW, RUP e MSF.

72 Quadro 6 Risco em PMBOK, CMMI-SW, RUP e MSF.

PMBOK rea Gerncia de Risco

CMMI-SW rea de Processo Gerncia de Risco Preparar-se para a Gerncia dos Riscos (SG 1)

RUP Disciplina Gerncia de Projetos Planejamento do Projeto.

Desenvolver o Plano de Gerenciamento de Riscos.

MSF Disciplina Gerncia de Riscos

Planejamento da Gerncia de Riscos

Determinar Fontes e Categorias de Riscos (SP1.1) Definir Parmetros de Riscos (SP 1.2) Estabelecer uma Estratgia para Gerncia de Risco (SP 1.3)

Planejamento da Gesto de Risco

Avaliar o Escopo do Identificao dos Riscos Identificar e Analisar Risco (SG 2) Identificar Riscos (SP 2.1) Projeto e os Riscos.
Identificar e Avaliar os Riscos

Identificao dos Riscos

Anlise Qualitativa dos Riscos Anlise Quantitativa dos Riscos Planejamento de Respostas aos Riscos Monitorao e Controle dos Riscos

Avaliar o Escopo do Identificar e Analisar Risco (SG 2) Avaliar, Categorizar e Priorizar Riscos (SP 2.2) Projeto e os Riscos.
Identificar e Avaliar os Riscos. Analise e Priorizao de Riscos

Avaliar o Escopo do Identificar e Analisar Risco (SG 2) Avaliar, Categorizar e Priorizar Riscos (SP 2.2) Projeto e os Riscos.
Identificar e Avaliar os Riscos. Analise e Priorizao de Riscos

Mitigar Riscos (SG 3) Desenvolver Planos de Mitigao de Riscos (SP 3.1) Mitigar Riscos (SG 3) Implementar os Planos de Mitigao de Riscos (SP 3.2)

Avaliar o Escopo do Projeto e os Riscos.

Identificar e Avaliar os Riscos.

Agendamento e Planejamento de resposta ao Risco Aprendizagem com Risco Relatrios de Rastreamento dos Riscos Controle de Riscos

Monitorar e Controlar o Projeto.

Monitorar o Status do Projeto.

Fonte: Adaptado de Rocha e Belchior(2004) MICROSOFT(2002)

6.1 Planejamento da Gerncia de Riscos O Planejamento da Gerncia de Riscos no PMBOK o processo de decidir como abordar e conduzir as atividades da gerncia de riscos para um projeto. Isto importante para assegurar que o nvel, o tipo e a visibilidade da gerncia de riscos sejam proporcionais ao risco e importncia do projeto para a organizao. Isto garantir tambm recursos e prazos suficientes para as atividades da gerncia de risco,

73 estabelecendo uma base consensual para a avaliao dos riscos. O resultado desse processo o Plano de Gerenciamento de Riscos, que descreve como o gerenciamento dever ser estruturado e executado no projeto. No CMMI realizado o planejamento da gesto de risco, onde so decididas as estratgias de gesto de risco. A formalizao deste planejamento concretizada com a elaborao do documento chamado Plano de Gerenciamento de Riscos. A estratgia da gerncia de risco refere-se s aes especficas, a abordagem gerencial usadas para aplicar e controlar o programa da gerncia de risco. Isto inclui identificar as fontes do risco, o esquema usado para categorizar riscos, e os parmetros usados para avaliar, limitar e controlar riscos para uma manipulao eficaz. No RUP, o Plano de Gerenciamento de Riscos um artefato de sada da Atividade Desenvolver o Plano de Gerenciamento de Riscos, que pertence ao fluxo de trabalho detalhado Planejamento do Projeto. Essa atividade tem como objetivo criar um plano documentado para identificao, anlise e priorizao dos riscos e identificar as estratgias de gerenciamento para os riscos mais relevantes do projeto. (ROCHA e BELCHIOR, 2004) A disciplina da gesto dos riscos no MSF defende a gesto de riscos dinmica, avaliao de risco contnua, e integrao na tomada de deciso durante todo o projeto ou o ciclo de vida operacional. Os riscos so avaliados continuamente, monitorados, e controlados ativamente at que estejam resolvidos. O processo da gesto de riscos se define em seis etapas lgicas atravs das quais a equipe controla riscos atuais. So eles:

Identificao de Riscos Anlise e Definio de Prioridade dos Riscos Planejamento e Agendamento de Controle dos Riscos Rastreamento e Repasse de Riscos Controle de Riscos Aprendizagem dos Riscos 6.2 Identificao dos Riscos A Identificao de Riscos no PMBOK envolve a determinao de quais riscos podem ocorrer em um projeto em particular, determinar quais deles podem afetar esse projeto e documentar suas caractersticas. Trata-se de um processo iterativo, porque

74 novos riscos podem surgir durante o ciclo de vida do projeto. A frequncia das iteraes e de quem deve participar de cada ciclo varia caso a caso. O processo de Identificao de Riscos relaciona-se bastante com o processo de Anlise Qualitativa dos Riscos. Alternativamente, esse processo pode se relacionar diretamente com o processo de Anlise Quantitativa dos Riscos, quando conduzido por um gerente com experincia em riscos. Em alguns casos a simples identificao do risco j sugere respostas a estes, que devem ser registradas para posterior anlise e implementao no processo de Planejamento das Respostas aos Riscos. Para o CMMI, a identificao de potenciais situaes, perigos, ameaas e vulnerabilidades, que poderiam afetar negativamente os esforos ou planos de trabalho, a base para a gerncia de risco bem-sucedida. Os riscos devem ser identificados e documentados em uma linguagem concisa, que inclua o contexto, as condies e as consequncias de sua ocorrncia, para que possam ser analisados e controlados corretamente. Os riscos identificados formam uma base para o inicio das atividades de gerenciamento de riscos. A lista dos riscos deve ser revista periodicamente, para que se identifiquem novas possveis fontes de riscos e de mudanas nos riscos identificados anteriormente, ou mesmo riscos que foram negligenciados ou no existiam quando a estratgia da gerncia de risco foi elaborada. A atividade Identificar e Avaliar Riscos do RUP tem o propsito de identificar, analisar e priorizar os riscos para o projeto e determinar as estratgias apropriadas de gerenciamento de riscos. Os seguintes passos dessa atividade esto diretamente ligados identificao dos riscos: Identificar Riscos Potenciais: tem o objetivo de criar e manter atualizada a lista de riscos. Rever Riscos durante a Iterao: tem o objetivo de verificar o que mudou. Rever Riscos no Final de uma Iterao: objetiva eliminar riscos que tenham sido totalmente mitigados e introduzir riscos recentemente descobertos. A lista de Riscos, que o produto da atividade Identificar e Avaliar Risco, um artefato fundamental para o RUP, pois serve como um ponto focal para as atividades do projeto e a base em torno da qual as iteraes so organizadas. O risco direciona os planos das iteraes, que so voltadas para o tratamento de riscos especficos, tentando

75 elimin-los ou reduzi-los. A lista de riscos deve ser revista periodicamente, para avaliar a eficcia das estratgias de mitigao do risco, que, por sua vez, conduzem a revises do plano do projeto e dos planos das iteraes subsequentes. O MSF defende o uso de uma aproximao estruturada para a gesto de riscos. Para o desenvolvimento de software, o uso da classificao do risco durante a etapa da identificao do risco uma maneira til de fornecer uma aproximao consistente, reprodutvel, mensurvel. A classificao do risco fornece uma base para o risco, o contedo do relatrio e o seguimento so as crticas em bases de conhecimentos e de manutenes do risco aprendidos. Dentro da etapa da identificao do risco, a lista da classificao do risco ajuda a equipe a detalhar o seu pensamento sobre o risco do projeto fornecendo base de manuteno dos riscos. Esta base de informaes comparada com uma base de informaes precedente ou de outros projetos similares para ter uma perspectiva do risco e sua soluo ou procedimento a ser tomado. O reconhecimento do risco e sua anlise so as tcnicas utilizadas dentro de MSF para avaliar um projeto especfico e para gerar a documentao necessria para priorizar o risco. (MICROSOFT, 2002)

6.3 Anlise Qualitativa dos Riscos A Anlise Qualitativa dos Riscos no PMBOK geralmente um meio rpido de estabelecer prioridades para o planejamento da resposta do risco, alm de fornecer a base para a anlise quantitativa do risco, se esta for requerida. Esse processo avalia a prioridade dos riscos identificados, usando sua probabilidade de ocorrncia e o impacto correspondente nos objetivos do projeto, se os riscos ocorrerem. As definies dos nveis de probabilidade e de impacto, as entrevistas com peritos e a avaliao da qualidade da informao disponvel no projeto podem ajudar a corrigir as polarizaes7, que esto frequentemente presentes nos dados usados neste processo. A anlise qualitativa do risco deve ser revista durante o ciclo de vida do projeto, para ficar atualizada de acordo com as mudanas nos riscos do projeto. No CMMI-SW, a anlise qualitativa dos riscos est especificada na prtica especfica: Avaliar, Categorizar e Priorizar Riscos.

Divergir uma soluo em duas hipteses distintas.

76 A avaliao e a categorizao de cada risco identificado so realizadas utilizando as categorias e os parmetros de riscos e sua prioridade determinada. Os parmetros de riscos definidos podem incluir a probabilidade, a consequncia (severidade ou impacto) e os limites. Os valores de parmetro atribudos ao risco podem ser integrados para produzir medidas adicionais, tais como a exposio ao risco, que pode ser usada para priorizar os riscos. A avaliao dos riscos necessria para se determinar a importncia relativa de cada risco identificado, sendo usada na determinao de quando a ateno apropriada da gerncia requerida. O produto de trabalho desta prtica a lista de riscos com sua respectiva prioridade. A atividade Identificar e Avaliar Riscos do RUP tem o propsito de identificar, analisar e priorizar os riscos para o projeto e determinar as estratgias apropriadas de gerenciamento de riscos. Os seguintes passos dessa atividade esto diretamente ligados com a anlise dos riscos: Analisar e Priorizar Riscos: consiste em combinar riscos similares, para reduzir tamanho da Lista de riscos, e em classific-los em termos de seu impacto no projeto. Rever Riscos durante a Iterao: objetiva garantir que a lista de riscos mantida atualizada no decorrer do projeto, inclusive no que se refere priorizao dos riscos. Rever Riscos no Final de uma Iterao: reavalia a magnitude e reordena os riscos aps a eliminao dos riscos mitigados, e tambm introduz novos riscos lista de riscos.

No MSF anlise qualitativa e quantitativa de riscos descrita na prtica anlise e priorizao de riscos. Estas prticas so a segunda etapa na gesto de riscos. A anlise de risco envolve a converso de dados do risco em um formulrio que facilite tomada de deciso. A priorizao do risco assegura-se de que os membros da equipe enderecem a maioria riscos importantes do projeto primeiramente. Durante esta etapa, a equipe examina a lista de artigos do risco produzidos no risco etapa da identificao e lhes d prioridade para a ao, gravando esta ordem na lista mestra do risco.

77 Da lista mestra do risco, a equipe pode determinar uma lista de riscos superiores para qual destinaro recursos para o planejamento e a execuo de uma estratgia especfica. A equipe pode igualmente identificar que risco, eventualmente, seja de tal baixa prioridade para a ao que pode ser retirado da lista. Como o projeto se move para a concluso, e como as circunstncias do projeto mudam, a identificao e a anlise de risco sero repetidas durante o projeto e os riscos sero reavaliados. (MICROSOFT, 2002)

6.4 Anlise Quantitativa dos Riscos A Anlise Quantitativa dos Riscos no PMBOK objetiva analisar numericamente a probabilidade de cada risco identificado e sua consequncia para os objetivos do projeto. Este processo geralmente segue-se anlise qualitativa dos riscos, embora gerentes com experincia em riscos tendam, s vezes, a execut-lo diretamente aps a identificao do risco. Em alguns casos, a anlise quantitativa do risco pode no ser requerida para desenvolver respostas efetivas ao risco. A disponibilidade de tempo e de oramento e a necessidade de declaraes qualitativa ou quantitativa sobre o risco e seus impactos determinaro quais mtodos devem ser usados para um projeto particular. No CMMI, a anlise quantitativa dos riscos referenciada na prtica especfica Avaliar, Categorizar e Priorizar Riscos. Na prtica avaliar os riscos identificados, utilizando os parmetros definidos, que requerem que cada risco seja avaliado e receba uma atribuio de valores, segundo parmetros definidos para o mesmo. Esses parmetros podem ser agregados e produzirem medidas adicionais, tais como a exposio ao risco, que pode ser usada para prioriz-los. Geralmente, uma escala com trs a cinco valores usada para avaliar a probabilidade e a consequncia do risco. Valores provveis so usados frequentemente para quantificar a probabilidade. As consequncias so relacionadas geralmente ao custo, ao cronograma, ao impacto ambiental ou s medidas humanas (tais como as horas de trabalho perdidas e a severidade do dano). Esta avaliao frequentemente uma tarefa difcil, e que consome tempo. Especialidades ou tcnicas especficas do grupo

78 podem ser necessrias para avaliar os riscos e ganhar a confiana no momento de prioriz-los. (ROCHA e BELCHIOR, 2004) No RUP, a anlise quantitativa dos riscos referenciada tambm na atividade. Identificar e Avaliar Riscos onde enfatizado que os riscos sejam priorizados de acordo com a exposio geral que o mesmo representa para o projeto de software. Para determinar a exposio de cada risco deve haver a estimativa das seguintes informaes: Impacto do risco: desvios do planejamento referentes a cronograma, esforo ou custos, caso o risco ocorra. Probabilidade de ocorrncia: probabilidade de que o risco realmente ocorra (geralmente expressa como porcentagem) Exposio ao risco: produto do impacto pela probabilidade de ocorrncia.

O MSF (Microsoft Solutions Framework) associa o risco (probabilidade) a um valor numrico. Este valor numrico utilizado utilizado em formulas matemticas para gerar informaes de tomada de decises, como exemplificado nas figuras 13 e 14.

Probabilidade 0% at 20% 21% at 40% 41% at 60% 61% at 80% 81% at 100%

ndice 1 2 3 4 5

Figura 13 Associao de probabilidades a ndices. Fonte: Elaborao do autor

79 Prioridade 1 2 3 4 Probabilidade 5 4 5 2 Impacto 5 5 2 2 Exposio 5 x 5 = 25 4 x 5 = 20 5 x 2 = 10 2x2=4

Figura 14 Exemplo de prioridade utilizando ndices Relacionados a probabilidades de risco. Fonte: Elaborao do autor

Independente da tcnica utilizada, a equipe precisar desenvolver uma aproximao para derivar um nico valor para a probabilidade do risco que representa sua opinio de consenso a respeito de cada risco. O impacto do risco uma estimativa da severidade de efeitos adversos, ou o valor de uma perda, ou do custo de opo potencial se um risco for realizado dentro de um projeto. As medidas da exposio ameaa total do risco, combinando a informao que expressa a probabilidade da perda real com a informao que expressa o valor da perda potencial em uma nica estimativa numrica. A disciplina do risco de MSF refere-se lista de riscos como a lista mestra do risco. Sob a forma de tabela, a lista mestra do risco identifica a condio do projeto que causa o risco, o efeito adverso potencial (consequncia), e o critrio ou a informao usado para a classificao, como probabilidade, impacto, e exposio.

6.5 Planejamento das Respostas aos Riscos Para o PMBOK o planejamento de respostas ao risco o processo que ir fornecer as opes para as tomadas de decises, sejam para as oportunidades para reduzir as ameaas aos objetivos do projeto. Os riscos identificados so devidamente endereados para indivduos ou partes envolvidas com suas responsabilidades definidas. O plano de resposta ao risco deve ser apropriado para a severidade do risco, estimando um custo real, o tempo necessrio para ser bem-sucedido, dentro de um

80 contexto realstico, acordado por todas as partes envolvidas e designado um responsvel. Para o CMMI-SW, as etapas do tratamento de riscos incluem desenvolver opes de tratamento de riscos, monitorao de riscos e execuo das atividades de tratamento, quando os limites definidos forem excedidos. Os planos de mitigao de riscos so desenvolvidos e executados, para que o impacto potencial da ocorrncia dos riscos selecionados sejam proativamente reduzidos. Isto pode tambm incluir planos de contingncia, para tratar do impacto dos riscos selecionados, que podem ocorrer apesar das tentativas de mitig-los. Os parmetros usados para disparar as atividades de tratamento do risco so definidos pela estratgia da gerncia de risco. O plano de mitigao para um risco inclui tcnicas e mtodos usados para evitar, reduzir e controlar a probabilidade de sua ocorrncia, e a extenso dos danos causados caso ocorra (plano de contingncia). Os planos de mitigao e de contingncia do risco frequentemente so gerados somente para os riscos selecionados, onde as consequncias dos riscos so determinadas como elevadas ou inaceitveis. Outros riscos podem ser aceitos e simplesmente monitorados. As opes para o tratamento de riscos normalmente incluem alternativas como: Anulao de riscos: mudar ou baixar requisitos enquanto ainda atender s necessidades dos usurios; Controle de riscos: tomar atitudes para minimizar riscos; Transferncia de riscos: rever os requisitos de projeto para baixar riscos. Monitorao de riscos: periodicamente reavaliar os riscos para identificar possveis mudanas nos parmetros atribudos aos riscos.

A atividade Identificar e Avaliar Riscos no RUP tem o propsito de identificar, analisar e priorizar os riscos para o projeto e determinar as estratgias apropriadas de gerenciamento de riscos. Os seguintes passos dessa atividade esto diretamente ligados ao planejamento da resposta aos riscos: Identificar Estratgias para Evitar Riscos: tem o propsito de reorganizar o projeto para eliminar riscos.

81 Identificar Estratgias para Mitigar Riscos: desenvolve planos de mitigao do risco para reduzir o impacto dos riscos. Identificar Estratgias de Contingncia: gera planos alternativos, que devem conter o indicador do risco e ao a ser tomada caso ele ocorra.

No MSF, a terceira etapa do gerenciamento do risco compreende o planejamento do risco e o agendamento das aes contra o risco. As atividades do planejamento realizadas por uma equipe que desenvolve a lista prioritria do risco e planos de ao. O planejamento envolve desenvolver estratgias e aes detalhadas para cada um dos riscos com maior prioridade. Entre as estratgias do combate ao risco esto: a mitigao, os planos de contingncia, disparadores de aes, e aes contra um determinado risco. O agendamento envolve a integrao das tarefas exigidas para executar os planos de ao de preveno ao risco no programa do projeto, atribuindo aes e responsabilidades aos stakeholders do projeto.

6.6 Monitorao e Controle dos Riscos Para o PMBOK, o Monitoramento e controle do risco um processo contnuo para o ciclo de vida do projeto. Os processos de monitoramento so considerados bons, quando do informaes relativas s tomadas de decises eficazes para conter o avano de ocorrncias de riscos. O Controle do risco pode envolver escolha de algumas alternativas como:

Implementar um plano de contingncia; Tomar aes corretivas ou; Re-planejar o projeto.

O responsvel pela resposta ao risco dever relatar periodicamente para o gerente do projeto e para o lder da equipe a eficcia do plano, alguns efeitos no previstos e alguma necessidade de correo no curso para mitigar o risco.

82 O CMMI-SW determina que para controlar e gerenciar eficazmente os riscos durante o esforo de trabalho deve seguir um programa proativo para monitorar regularmente os riscos e o status, alm dos resultados das aes de acompanhamento dos riscos. A estratgia da gerncia de riscos define os intervalos em que o status do risco deve ser revisado. Isto pode resultar na descoberta de novos riscos ou de novas opes de manipulao, que podem requerer o re-planejamento e a reavaliao. Em ambos os eventos, os limites de aceitao associados com o risco devem ser comparados com o status, para determinar a necessidade de execuo do plano de mitigao de riscos. A prtica especfica de que trata esta monitorao Implementar Planos de Mitigao de Riscos. No RUP, a atividade Monitorar o Status do Projeto composta pelos seguintes passos: Capturar o Status do Trabalho: coleta informaes de qualidade e progresso do projeto para avaliao do status atual. Derivar Indicadores de Progresso: avalia apropriadamente o progresso do projeto com relao aos planos. Derivar Indicadores de Qualidade: usa mtricas de qualidade. Avaliar Indicadores x Planos: compara o estado esperado do projeto de acordo com o que foi definido no Plano de Desenvolvimento e no Plano da Iterao.

No MSF o monitoramento dos riscos realizado na quarta etapa do gerenciamento do risco e chamado de rastreamento do risco, enquanto o controle do risco realizado na quinta etapa. So estabelecidos disparadores de aes caso seja identificado caso um risco se tornar fato. So realizadas tomadas de decises conforme as informaes registradas nas etapas anteriores. Entre as aes realizadas esto a mitigao de riscos e aes de contingncia. Todos os acontecimentos so registrados como lies aprendidas para que casos no venham a se repetir. (MICROSOFT, 2002)

83

7. CONCLUSO
Os principais resultados negativos do desenvolvimento de software so: custo superado de sua estimativa original, produtos com problemas que precisam ser resolvidos ps entrega, perda do prazo de entrega, diferena entre o proposto e o realizado e quando na pior das hipteses, o cancelamento do projeto. Parte destes problemas se deve a constantes mudanas, como por exemplo: na rea da tecnologia, no escopo do projeto, alta rotatividade no quadro de pessoal do desenvolvimento, m qualidade na documentao etc. Os motivos acima descritos j so bastante conhecidos pelos profissionais da rea de tecnologia e em qualquer das metodologias citadas no presente trabalho. A documentao dos erros e suas devidas solues so consideradas como aprendizagem do desenvolvimento de software. Este trabalho teve como objetivo apresentar a importncia do gerenciamento do risco no desenvolvimento de software, a apresentao de uma metodologia de gesto do risco e um comparativo com outras formas de gerenciar riscos. Foi realizado um comparativo entre a gesto de risco em quatro metodologias diferentes. Mesmo com prticas diferentes os objetivos no mudam: encontrar, documentar, pesar, refletir o impacto, planejar resposta e monitorar os riscos. Para realizar estas prticas de forma adequada, deve-se levar em conta no mnimo os princpios explanados pelo MSF (Microsoft Solutions Framework): Ter uma comunicao aberta, trabalhar com uma viso compartilhada, capacitar a equipe, estabelecer responsabilidades e partilh-las, respeitar os milestones, estar preparado para mudanas, manter a qualidade do software e sempre estar aprendendo. Quando se fala em gerir o risco, calculando as probabilidades de erro, do no cumprimento do cronograma, significa que o projeto deve funcionar como um relgio, onde todas as peas se conectam e funcionam perfeitamente. Como descrito anteriormente, a indstria do desenvolvimento de software est presente em todos os meios, seja desenvolver um programa para controle de um satlite ou gerir a rea financeira de uma empresa. As atividades destes projetos devem ser dinmicos e exatos. Possveis falhas no desenvolvimento, ou posteriormente, quando o produto estiver pronto, podem acarretar prejuzos maiores que o custo do prprio projeto.

84 Cada metodologia apresenta uma forma de gerenciar o risco de um projeto, seja dividindo, estabelecendo tarefas, documentando ou confiando na responsabilidade das pessoas. Como apresentado neste trabalho, a gesto de risco de fato uma prtica importante na gesto do desenvolvimento de software. Como as empresas esto preocupadas em entregar seus produtos ou adequar estes produtos a alguma licitao pblica, muitas vezes a gesto de riscos no considerada. Para a conscientizao da gesto do risco sugere-se como tema de futuro trabalho: A abordagem da gesto de risco no desenvolvimento de software em empresas do Cear. Como um trabalho futuro, poderamos realizar a apresentao de um relatrio sobre o tema, focando nas empresas de desenvolvimento de

software do Cear.

85

8. REFERNCIAS BIBLIOGRFICAS
ALENCAR, A. J., SCHMITZ, E. A., Anlise de Risco em Gerncia de Projetos. Rio de Janeiro, Editora Brasport, 2006.

BERNSTEIN, P., O Desfio aos Deuses: A Fascinante Histria do Risco. Rio de Janeiro, Campus, 1997.

BOEHM, B., Software risk management: principles and practices. Piscataway: IEEE Software,1991. CHAOS REPORT, Disponvel em: http://itprojectguide.blogspot.com/2009/04/standish-2009-chaos-report.html Acessado em: 03 de dezembro de 2009. DINSMORE, P. C., Como se Tornar um Profissional em Gerenciamento de Projetos. 2 ed. Rio de Janeiro, Editora Qualytmark, 2005.

GURGEL, C. G. S., Curso preparatrio para certificao PMP. PMI-CE Fortaleza, 2007.

GUSMO, C. M. G., MOURA, P. H., ISO, CMMI, and PMBOK Risk Management: a Comparative Analysis. The International Journal of Applied Management and Technology, Volume 1, Number 1. 2003.

LEOPOLDINO, C. B., Avaliao de Riscos em Desenvolvimento de Software. Dissertao de Mestrado - Mestrado em Cincias da Computao, Universidade Federal do Rio Grande do Sul, Porto Alegre, 2004.

MACHADO, C. (2002) A-Risk: Um mtodo para identificar e quantificar risco de prazo em projetos de desenvolvimento de software. Curitiba, 2002.

86 MICROSOFT CORPORATION. 2002. Microsoft Solutions Framework - White Paper. Disponvel em: http://msdn.microsoft.com/en-us/teamsystem/aa718795.aspx Acessado em: 12/05/2009. PMI-SP, Disponvel em: http://www.pmisp.org.br/instituto.asp Acessado em: 10 de julho de 2009. PRESSMAN, R. S. Engenharia de Software 5 Editora: Makron Books, 1995.

PROJECT MANAGEMENT INSTITUTE (PMI), Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos Terceira edio (Guia PMBOK). Project Management Institute, inc, 2004.

RISK MANAGEMENT. Disponvel em: http://www.cmmi.de/cmmi_v1.2/browser.html#hs:i:true:m:2:c:all:r:b:a:RSKM:g:null:p: null:l:data_a=RSKM:la:RSKM. Acessado em: 04 de Janeiro de 2009. ROCHA, P.C. ; BELCHIOR, A.D. Mapeamento do Gerenciamento de Riscos no PMBOK, CMMI-SW e RUP. Disponvel em: http://www.simpros.com.br/Apresentacoes_PDF/Artigos/Art_24_Simpros2004.pdf Acesso em: 14 de outubro de 2009. RUP. Rational Unified Process, Version 2003.06.00.65, CD-ROM. Rational Software Corporation, Cupertino, California, 2003. SEIBERT, W. Estudo de Caso Sobre Gerncia de Projetos com o Foco em Gerncia de Riscos. Dissertao de Bacharelado em Cincias da Computao, Universidade Luterana do Brasil - Faculdade de Informtica, Canoas, 2004.

SOMMERVILLE, I. Engenharia de Software. 6 ed. Editora Pearson / Prentice Hall, 2003. VARGAS, R. Gerenciamento de riscos e de projetos. http://www.ricardo-vargas.com/pt/podcasts/riskmanagement/. Acessado em: 10 de julho de 2009. Disponvel em: