TCC Base Risco de Projetos PDF

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

v
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

x
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.

Requisitos
Envolve a definio dos requisitos do sistema e de como gerenciar escopo e
mudanas de requisitos.
Anlise e Projeto
Envolve a traduo dos requisitos numa especificao que descreva como
implementar o sistema. A linguagem UML utilizada para modelar o sistema.
Implementao
Envolve o desenvolvimento de cdigo: classes, objetos, etc., testes de unidade
e integrao de subsistemas.
Testes
Envolve a verificao do sistema como um todo, com testes de integrao e
conformidade com os requisitos especificados.
Disponibilizao
Envolve o empacotamento, distribuio, instalao e treinamento de usurios,
assim como o planejamento e conduo de testes preliminares.
Gerncia de Projetos
Envolve o gerenciamento de riscos, planejamento e acompanhamento do
projeto.
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 negcio
1
.
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)).

1
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

2
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
SG 1: Preparar-se para a gerncia de riscos
SP 1.1: Determinar as origens e categorias dos riscos
SP 1.2: Definir os parmetros dos riscos
SP 1.3: Estabelecer uma estratgia de gerncia de riscos
SG 2: Identificar e analisar os riscos
SP 2.1: Identificar os riscos
SP 2.2: Avaliar, categorizar e priorizar os riscos
SG 3: Mitigar os Riscos
SP 3.1: Desenvolver planos de mitigao de riscos
SP 3.2: Implementar os planos de mitigao dos riscos
GG 3: Institucionalizar um processo definido
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
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 inter-
relacionada 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 pr-
ativa 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)

Fonte:PMI (2004)

1. Plano de Gerncia de Risco
1.1 Entradas
Fatores ambientais
Ativos de processos
organizacionais
Declarao do escopo do projeto
Plano de gerenciamento do
projeto
1.2 Tcnicas e Ferramentas
Reunies de planejamento
1.3 Sadas
Plano de gerenciamento de
riscos
2. Identificao do Risco
2.1 Entradas
riscos
Fatores ambientais
Ativos de processos
organizacionais
projeto
Reviso da documentao
Tcnicas de coleta de
informaes.
Anlise da lista de verificao
Anlise das premissas
Tcnicas de diagramao
2.3 Sadas
Registro de riscos
3. Anlise Qualitativa do risco
3.1 Entradas
Ativos de processos
organizacionais
Plano de gerenciamento de riscos
Registro de riscos
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. Plano de Gerncia de Risco
1.1 Entradas
Fatores ambientais
Ativos de processos
organizacionais
projeto
Reunies de planejamento
1.3 Sadas
riscos
2. Identificao do Risco
2.1 Entradas
riscos
Fatores ambientais
Ativos de processos
organizacionais
projeto
Reviso da documentao
Tcnicas de coleta de
informaes.
Anlise da lista de verificao
Anlise das premissas
Tcnicas de diagramao
2.3 Sadas
Registro de riscos
3. Anlise Qualitativa do risco
3.1 Entradas
Ativos de processos
organizacionais
Plano de gerenciamento de riscos
Registro de riscos
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
4.3 Sadas
Registro de riscos
atualizados
5.3 Sadas
projeto (atualizaes)
Acordos contratuais
relacionados a riscos
4. Anlise quantitativa do risco
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
Estratgias para riscos
negativos ou ameaas
positivos ou oportunidades
Estratgias para ameaas e
oportunidades
Estratgia para respostas
contigenciadas
6. Monitorando e Controlando risco
6.1 Entradas
Registro de Riscos
Solicitao de mudanas aprovadas
Informaes sobre o desempenho
do trabalho
Relatrios de desempenho
Reavaliao de riscos
Auditorias de risco
Anlise das tendncias e da variao
Medio do desempenho tcnico
Anlise das reservas
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)
4.1 Entradas
Ativos de processos
organizacionais
Registro de Riscos identificados
Cronograma
Custos
4.3 Sadas
Registro de riscos
atualizados
5.3 Sadas
projeto (atualizaes)
Acordos contratuais
relacionados a riscos
4. Anlise quantitativa do risco
Tcnicas de representao e
coleta de dados.
Anlise quantitativa de riscos
e tcnicas de modelagem
5. Plano de Resposta ao risco
5.1 Entradas
Registro de Riscos
negativos ou ameaas
positivos ou oportunidades
Estratgias para ameaas e
oportunidades
Estratgia para respostas
contigenciadas
6. Monitorando e Controlando risco
6.1 Entradas
Registro de Riscos
Solicitao de mudanas aprovadas
Informaes sobre o desempenho
do trabalho
Relatrios de desempenho
Reavaliao de riscos
Auditorias de risco
Anlise das tendncias e da variao
Medio do desempenho tcnico
Anlise das reservas
Reunies de andamento
6.3 Sadas
Registro de riscos(atualizaes)
Mudanas solicitadas
Aes corretivas recomendadas
Ativos de processos organizacionais
(atualizaes)
(atualizaes)
4.1 Entradas
Ativos de processos
organizacionais
Registro de Riscos identificados
Cronograma
Custos

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 entregas
3
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.

3
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.
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.

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)

Realizao de um
questionrio/inqurito
Anlise das Respostas do
questionrio
Sim
No
Tabelamento das respostas e entrega da
informao ao grupo
Desenvolvimento do questionrio
seguinte
Compilao dos resultados num
resumo final
Atingiu-se
consenso?

Incio
Fim

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.


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

Ambiente Interno
PONTOS FORTES PONTOS FRACOS
OPORTUNIDADES AMEAAS
1. O que voc (empresa/equipe/pessoa) faz bem?
2. Que recursos especiais voc possui e pode aproveitar ?
3. 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?
1. Que ameaas (leis, regulamentos, concorrentes)
podem lhe prejudicar ?
2. O que seu concorrente est fazendo?
1. Quais so as oportunidades externas que voc pode
identificar?
2. Que tendncias e novas tecnologias voc pode
aproveitar em seu favor?
Ambiente Externo

51

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


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.

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

Figura 8 Diagrama de Ichikawa ou Fishbone.

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.

Efeito

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.


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
Probabilidade

Alto Mdio Baixo
I
m
p
a
c
t
o
Alto Alto Alto Mdio
Mdio Alto Mdio Baixo
Baixo Mdio Baixo Baixo

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).

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.

Figura 11 Matriz de probabilidade e impacto em tons de branco e preto.
Fonte: Elaborada pelo autor.
Probabilidade
Alto Mdio Baixo
I
m
p
a
c
t
o

Alto Alto Alto Mdio
Mdio Alto Mdio Baixo
Baixo Mdio Baixo Baixo

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 causas-
raiz 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. oramentos e tempos para as respostas;
g. 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:

Figura 12 Processo Cclico de Gerncia de Risco.

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?
Identificao
dos riscos
Avaliaes de
Riscos
Planejamento de
Aes de
Tratamento dos
Riscos
Monitoramento
dos fatores de
risco

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 escopo
5
: as mudanas de escopo freqentemente requerem
novas anlises e planos de resposta.

5
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

6
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 CMMI-SW RUP MSF
rea
Gerncia de
Risco
rea de Processo
Gerncia de Risco
Disciplina
Gerncia de Projetos
Disciplina
Gerncia de Riscos
Planejamento
da Gerncia de
Riscos
Preparar-se para a Gerncia dos Riscos (SG 1)
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 do
Projeto.
Desenvolver o Plano de
Gerenciamento de
Riscos.
Planejamento da Gesto de
Risco
Identificao
dos Riscos
Identificar e Analisar Risco (SG 2)
Identificar Riscos (SP 2.1)
Avaliar o Escopo do
Projeto e os Riscos.
Identificar e Avaliar os
Riscos
Identificao dos Riscos
Anlise
Qualitativa dos
Riscos
Avaliar, Categorizar e Priorizar Riscos (SP 2.2)
Avaliar o Escopo do
Riscos.
Analise e Priorizao de
Riscos
Anlise
Quantitativa
dos Riscos
Avaliar, Categorizar e Priorizar Riscos (SP 2.2)

Avaliar o Escopo do
Riscos.
Analise e Priorizao de
Riscos
Planejamento
de Respostas
aos Riscos
Mitigar Riscos (SG 3)
Desenvolver Planos de
Mitigao de Riscos (SP 3.1)
Avaliar o Escopo do
Riscos.
Agendamento e
Planejamento de resposta
ao Risco
Aprendizagem com Risco
Monitorao e
Controle dos
Riscos
Mitigar Riscos (SG 3)
Implementar os Planos de Mitigao de Riscos
(SP 3.2)
Monitorar e
Controlar o Projeto.
Monitorar o Status do
Projeto.
Relatrios de Rastreamento
dos Riscos
Controle de Riscos
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 polarizaes
7
, 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.

7
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,
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 ndice
0% at 20% 1
21% at 40% 2
41% at 60% 3
61% at 80% 4
81% at 100% 5

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

79
Prioridade Probabilidade Impacto Exposio
1 5 5 5 x 5 = 25
2 4 5 4 x 5 = 20
3 5 2 5 x 2 = 10
4 2 2 2 x 2 = 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,
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. Disponvel em:
http://www.ricardo-vargas.com/pt/podcasts/riskmanagement/.
Acessado em: 10 de julho de 2009.

TCC Base Risco de Projetos PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC Base Risco de Projetos PDF

Enviado por

Direitos autorais:

Formatos disponíveis

FACULDADE LOURENO FILHO

Você também pode gostar