UNIVERSIDADE LUTERANA DO BRASIL

FACULDADE DE INFORMÁTICA
BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
CAMPUS CANOAS

ESTUDO DE CASO SOBRE GERÊNCIA

DE PROJETOS COM FOCO EM
GERÊNCIA DE RISCOS

Werner Seibert

Monografia desenvolvida durante a disciplina de Trabalho

de Conclusão de Curso em Informática II e apresentada ao
Curso de Ciência da Computação da Universidade
Luterana do Brasil, campus Canoas, como pré-requisito
para a obtenção do título de Bacharel em Ciência da
Computação.

Orientador: Prof. Msc. Roberto Petry

Canoas, Junho de 2004.

 DEDICATÓRIA

Este trabalho é dedicado aos meus pais e minha

esposa, pois só eles sabem por tudo o que eu e eles

passaram para que esse momento chegasse.

AGRADECIMENTOS

Quando comecei este trabalho eu juntei minhas

mãos e me dirigi a Deus em oração solicitando força

e sabedoria para poder concluir este trabalho. Assim

sendo, quero fazer das palavras de Davi a minha

gratidão agora que o trabalho foi concluído. “Bendito

és tu, Senhor, Deus de nosso pai Israel, de

eternidade em eternidade. Tua, Senhor, é a

grandeza, o poder, a honra, a vitória e a majestade;

porque teu é tudo quanto há nos céus e na terra; teu,

Senhor, é o reino. Contigo está o engrandecer e a

tudo dar força”. Louvado sejas, ó bom Deus.

Obrigado, Roberto Petry, pelo apoio, conselhos e

orientações que recebi de ti neste trabalho.

 SUMÁRIO

DEDICATÓRIA ....................................................................................................................... 2
AGRADECIMENTOS ............................................................................................................. 3
LISTA DE FIGURAS............................................................................................................... 6
LISTA DE QUADROS............................................................................................................. 8
RESUMO................................................................................................................................... 9
ABSTRACT ............................................................................................................................ 10
1 INTRODUÇÃO.................................................................................................................. 11
1.1 OBJETIVOS .................................................................................................................. 13
2 GERENCIAMENTO DE PROJETOS ............................................................................ 15
3 RISCO SOB A ÓTICA DE ALGUMAS METODOLOGIAS ....................................... 18
3.1 A ABORDAGEM DA NBR ISO/IEC 12207. ................................................................... 19
3.2 A ABORDAGEM DO SW-CMM..................................................................................... 20
3.2.1 SRE...................................................................................................................... 22
3.2.1.1 O Método SRE........................................................................................... 23
3.2.1.1.1 Contratação ......................................................................................... 23
3.2.1.1.2 RI&A (Identificação e Análise de Risco) ........................................... 24
3.2.1.1.3 Relatório Provisório............................................................................ 26
3.2.1.1.4 MSP (Plano para a Estratégia de Mitigação)...................................... 26
3.2.1.1.5 Relatório Final .................................................................................... 27
3.2.2 Considerações finais sobre o CMM .................................................................... 27
3.3 A ABORDAGEM DO PMBOK........................................................................................ 28
3.3.1 Planejamento da Gerência de Risco .................................................................... 30
3.3.2 Identificação dos Riscos...................................................................................... 34
3.3.3 Análise Qualitativa dos Riscos............................................................................ 36
3.3.4 Análise Quantitativa dos Riscos.......................................................................... 38
3.3.5 Planejamento de Resposta a Riscos .................................................................... 39
3.3.6 Controle e Monitoração de Riscos ...................................................................... 41
4 FERRAMENTAS DE GERENCIAMENTO DE RISCO .............................................. 44
4.1 PERTMASTER ............................................................................................................... 44
4.2 RISKTRAK.................................................................................................................... 47
 4.3 RISK+ .......................................................................................................................... 49
5 PROPOSTA DE GERENCIAMENTO DE RISCOS ..................................................... 52
5.1 MODELAGEM DO PROTÓTIPO....................................................................................... 53
5.2 DESENVOLVIMENTO DO PROTÓTIPO ............................................................................ 63
5.3 RESULTADOS OBTIDOS ................................................................................................ 75
6 CONCLUSÃO .................................................................................................................... 78
REFERÊNCIAS E OBRAS CONSULTADAS.................................................................... 80
GLOSSÁRIO .......................................................................................................................... 83
 LISTA DE FIGURAS

Figura 1 – Organização da norma NBR ISO/IEC 12207 ......................................................... 20

Figura 2 – Áreas do SRE .......................................................................................................... 23
Figura 3 – Ciclo da Entrevista .................................................................................................. 25
Figura 4 – Áreas de Conhecimento do PMBOK. ..................................................................... 29
Figura 5 – Visão do processo de Planejamento da Gerência de Risco..................................... 31
Figura 6 – Visão do processo de Identificação dos Riscos....................................................... 34
Figura 7 – Visão do processo de Análise Qualitativa dos Riscos ............................................ 36
Figura 8 – Visão do processo de Análise Quantitativa dos Riscos .......................................... 38
Figura 9 – Visão do processo de Planejamento de Resposta a Riscos ..................................... 40
Figura 10 – Visão do processo de Controle e Monitoração de Riscos ..................................... 42
Figura 11 – Gerenciamento de Projetos no Pertmaster ............................................................ 45
Figura 12 – Gráfico de tempo por riscos .................................................................................. 46
Figura 13 – Gráfico de tempo para o projeto............................................................................ 46
Figura 14 – Exemplo de uma Lista de Riscos no RiskTrak ..................................................... 48
Figura 15 – Query no banco de dados ...................................................................................... 48
Figura 16 – Exemplo de definição de risco no RiskTrak ......................................................... 49
Figura 17 – Integração do Risk+ com o MS Project ................................................................ 50
Figura 18 – Entrada de dados para análise de tempo e custo no Risk+.................................... 51
Figura 19 – Resultado da análise de tempo no Risk+............................................................... 51
Figura 20 – UML Use Case – Visão Macro ............................................................................. 54
Figura 21 – UML Use Case – Visão “Definir Usuários” ......................................................... 56
Figura 22 – UML Use Case – Visão “Manter Projeto”............................................................ 59
Figura 23 – UML Use Case – Visão “Manter Riscos”............................................................. 60
Figura 24 – UML Diagrama de Classes ................................................................................... 62
Figura 25 – Protótipo – Login .................................................................................................. 63
Figura 26 – Protótipo – Administração de Contas de Acesso .................................................. 64
Figura 27 – Protótipo – Seleção do Projeto.............................................................................. 65
Figura 28 – Protótipo – Lista de Riscos do Projeto Selecionado ............................................. 66
Figura 29 – Protótipo – Planejamento do Projeto .................................................................... 67
Figura 30 – Protótipo – Definição de Membros ....................................................................... 68
Figura 31 – Protótipo – Atribuição de Permissões ................................................................... 68
Figura 32 – Protótipo – Definição da Metodologia e Documentos de Apoio .......................... 69
Figura 33 – Protótipo – Definição da Matriz de Impacto......................................................... 70
Figura 34 – Protótipo – Especificação do Orçamento da Gerência de Riscos ......................... 70
Figura 35 – Protótipo – Definição de Responsabilidades no Projeto ....................................... 71
Figura 36 – Protótipo – Administração de um Risco ............................................................... 74
Figura 37 – Protótipo – Histórico de Mudanças de um Risco.................................................. 75
 LISTA DE QUADROS

Quadro 1 – Exposição de Riscos .............................................................................................. 24

Quadro 2 – Exemplo de Relatório de Riscos............................................................................ 33
Quadro 3 – Método de pontuação de impacto com abordagem ordinal................................... 37
Quadro 4 – Classificação do risco com abordagem cardinal de probabilidade x impacto....... 37
 RESUMO

Na área de informática um dos maiores fatores de sucesso ou não nos

projetos está diretamente relacionado ao uso de metodologias de gerenciamento de

projetos e não necessariamente na tecnologia das ferramentas utilizadas. Levando

em conta este cenário, o trabalho tem como principais objetivos o de estudar as

metodologias padrões de mercado para a Gerência de Projetos com foco em

Gerência de Riscos e propor um modelo de Gerenciamento de Riscos que seja

aplicável comercialmente e desenvolver um protótipo que atenda os princípios

básicos desta metodologia.

 ABSTRACT

One of the biggest factors of success or not in projects from the area of

computer science is directly related to the use of project management methodologies

and not necessarily to the technology of the used tools. Taking in account this scene,

this work has as main objectives to study the standard market methodologies for

Project Management with focus on Risk Management and to propose a Risk

Management model that is commercially applicable and to develop an archetype that

takes care of the basic principles of this methodology.

 11

1 INTRODUÇÃO

A Gerência de Projetos é muito importante para o sucesso de qualquer

atividade que se caracterize como um projeto, isto é, que tenha um início, meio e

fim. Um exemplo disso é a famosa “crise de software” que tem sido bastante

estudada pela comunidade de software e outras instituições como o DOD

(Departamento de Defesa dos Estados Unidos) e do Standish Group.

O estudo conduzido pelo DOD indicou que 75% de todos os grandes

sistemas intensivos de software adaptados falham e que a causa principal é o pobre

gerenciamento por parte do desenvolvedor e adquirente e o problema não é de

desempenho técnico.

O estudo desenvolvido pelo Standish Group chamado de relatório do

“Chaos” tem como foco a indústria de software comercial. Resumidamente, todas

essas análises levaram as mesmas conclusões que são:

• Desenvolvimento de software é ainda imprevisível;

• Somente 10% dos projetos de software são entregues com sucesso

dentro das estimativas de orçamento e custo;

 12

• A disciplina de gerência é mais um discriminador de sucesso ou

falha do que são os avanços tecnológicos;

• O nível de software jogado fora e que tem necessidade de re-

trabalho é um indicativo de processo imaturo.

Segundo o PMI (Project Management Institute), no mundo estima-se

que US$ 10 trilhões são gastos anualmente no mundo em projetos, o que equivale a

25% do PIB mundial.

O “Chaos Report” divulgado pelo Standish Group em 2001 nos dá

outros números ainda mais impressionantes sobre os projetos:

• Somente 16% são bem sucedidos;

• Somente 28% foram entregues no prazo e no orçamento previsto;

• 23% são cancelados;

• 94% vão reiniciar pelo menos uma vez;

• Somente 61% vão manter o escopo original.

Alguns problemas típicos em projetos são [SOTSD]:

• Atrasos no cronograma;

• Custos acima do previsto;

• Falta de recursos de pessoal;

 13

• Mudanças de requisitos e especificações;

• Qualidade abaixo da esperada;

• Complexidade acima da capacidade;

• Produtos mal projetados;

• Produtos que não funcionam;

• Projetos que são cancelados;

Com a disponibilização desses estudos ficou evidente que as práticas

de gerência de projetos devem ser melhoradas para que se tenha sucesso nos

projetos de tecnologia da informação [MAC01].

Visto a importância do tema, faz-se necessário uma análise dos

principais modelos de Gerenciamento de Projetos com foco em Gerência de Riscos

para que desta forma possamos propor um modelo de Gerência de Riscos que seja

útil e aplicável em um ambiente comercial.

1.1 OBJETIVOS

Este trabalho tem alguns objetivos. Os principais são o de estudar as

metodologias padrões de mercado para a Gerência de Projetos com foco em

Gerência de Riscos, adotar como modelo uma destas metodologias e desenvolver

um protótipo que atenda os princípios básicos desta metodologia.

 14

Além destes, o trabalho apresenta como objetivos específicos:

• Estudar o modelo de Gerenciamento de Riscos do PMBOK e

outros modelos equivalentes;

• Analisar as Ferramentas para Gerência de Risco disponíveis no

mercado;

• Modelar um protótipo que atenda os princípios básicos da

metodologia definida;

• Desenvolver o protótipo.
 15

2 GERENCIAMENTO DE PROJETOS

Segundo a definição do PMBOK (Project Management Body of

Knowledge), um projeto é um empreendimento com características próprias, tendo

princípio e fim, conduzido por pessoas, para atingir metas estabelecidas dentro de

parâmetros de prazo, custo e qualidade [PMI00].

Gerenciamento de projeto é a aplicação de conhecimentos,

habilidades, ferramentas e técnicas em projetos com o objetivo de atingir ou até

mesmo exceder às necessidades e expectativas dos clientes e demais partes

interessadas do projeto. Outra característica do gerenciamento de projetos é que ele

é acompanhado de processos tais como: iniciação, planejamento, execução,

controle e encerramento. Assim sendo, a Gerência de Projetos é distribuída em nove

áreas de conhecimento onde cada uma delas descreve seus respectivos processos

a fim de garantir que os objetivos planejados sejam atingidos. Segue, de forma bem

sucinta, uma explicação sobre cada uma destas áreas:

Gerência de integração: O objetivo principal é realizar as negociações

dos conflitos entre objetivos e alternativas do projeto com a finalidade de atingir ou

exceder as necessidades e expectativas de todas as partes interessadas. Envolve o

desenvolvimento e a execução do plano do projeto, e o controle geral de mudanças.

 16

Gerência de Escopo: O objetivo principal é definir e controlar o que

deve e o que não deve estar incluído no projeto. Consiste da iniciação,

planejamento, definição, verificação e controle de mudanças do escopo.

Gerência de Tempo do Projeto: O objetivo principal é garantir o término

do projeto no tempo certo. Consiste da definição, ordenação e estimativa de duração

das atividades, e de elaboração e controle de cronogramas.

Gerência de Custo: O objetivo principal é garantir que o projeto seja

executado dentro do orçamento aprovado. Consiste de planejamento de recursos, e

estimativa, orçamento e controle de custos.

Gerência de Qualidade do Projeto: O objetivo principal é garantir que o

projeto satisfará as exigências para as quais foi contratado. Consiste de

planejamento, garantia e controle de qualidade.

Gerência de Recursos Humanos: O objetivo principal é garantir o

melhor aproveitamento das pessoas envolvidas no projeto. Consiste de

planejamento organizacional, alocação de pessoal e desenvolvimento de equipe.

Gerência de Comunicação: O objetivo principal é garantir a geração

adequada e apropriada, coleta, disseminação, armazenamento e disposição final

das informações do projeto. Consiste do planejamento da comunicação, distribuição

da informação, relatório de acompanhamento e encerramento administrativo.

Gerência de Risco: O objetivo principal é maximizar os resultados de

ocorrências positivas e minimizar as conseqüências de ocorrências negativas.

 17

Consiste de identificação, quantificação, tratamento e controle de tratamento de

riscos.

Gerência de Aquisição: O objetivo principal é obter bens e serviços

externos à organização executora. Consiste do planejamento de aquisição,

planejamento de solicitação, solicitação de propostas, seleção de fornecedores, e

administração e encerramento de contratos [PMI00].

Conforme já indicado, entre estas áreas de conhecimento está o

Gerenciamento de Riscos, que é a área da Gerência de Projetos responsável pelos

processos de identificação, análise e resposta aos riscos envolvidos num projeto. O

risco possui três componentes: o evento; a probabilidade de ocorrência deste evento

e o impacto que ele pode ter no projeto.

O risco também possui algumas características que os diferem uns dos

outros. Existem os riscos puros e os riscos de negócios. Risco puro é o risco que só

traz perdas enquanto que o risco de negócio pode trazer perdas, mas também existe

a chance dele trazer oportunidades de ganhos. Além destas características também

se dividem os riscos em conhecidos e desconhecidos. Os conhecidos são os que

nos permitem serem trabalhados, onde podemos estudá-los e nos antecipar aos

seus eventos, podendo desta forma minimizar ou até mesmo evitar algum evento.

Dessa forma podemos ver que a Gerência de Riscos nos traz um

grande benefício que é o de maximizar os resultados dos eventos positivos e

minimizar a conseqüência dos eventos adversos podendo inclusive eliminar a

ocorrência de eventos desta natureza [PER99].

 18

3 RISCO SOB A ÓTICA DE ALGUMAS METODOLOGIAS

Cada modelo de Gerência de Projetos possui um objetivo específico e

é voltado para um determinado público. Assim sendo, mesmo que alguns modelos

possuam objetivos e características semelhantes, a abordagem utilizada em alguns

assuntos que são idênticos entre esses modelos pode ter um tratamento

completamente diferente.

Talvez por possuírem papéis e prioridades diferente, os riscos do

projeto são tratados de forma bem singular em alguns modelos de gerenciamento de

projetos. Em alguns, o assunto é tratado com muita atenção e análise e em outros é

tratado superficialmente, não explicando exatamente o que deve ser feito, citando

apenas o resultado final.

Seja qual for o modelo utilizado, é sempre útil conhecer a abordagem

de outros métodos, pois por mais que algumas pessoas e/ou instituições tenham

trabalhado para desenvolver um padrão, ainda existe a possibilidade de algum

assunto relevante para o seu projeto não estar sendo devidamente tratado.

Segue uma análise sobre os riscos de um projeto de algumas

metodologias bem conhecidas.

 19

3.1 A ABORDAGEM DA NBR ISO/IEC 12207.

A NBR ISO/IEC 12207 é uma norma brasileira que tem como objetivo

estabelecer processos, atividades e tarefas a serem executadas durante os

processos de aquisição, fornecimento, operação, desenvolvimento e manutenção de

software e o seu público alvo são os compradores, fornecedores, operadores,

desenvolvedores, mantenedores, gerentes, profissionais de qualidade e os usuários

[ABN97].

Apesar da norma ser muito útil no que se refere à definição de

processos e definição de estrutura e linguagem comum entre o seu público alvo, a

norma deixa a desejar no que se refere ao gerenciamento de riscos.

Não há nenhuma conceituação sobre o que são riscos ou os seus

impactos no gerenciamento de um projeto.

Para os compradores, a norma faz duas recomendações sobre riscos:

Que antes de se escolher entre a aquisição de um novo

software, ou o desenvolvimento interno de um novo software, ou

a melhoria de um software já existente, ou até mesmo uma

mescla entre estas opções, que se avalie os riscos envolvidos

em cada uma destas escolhas;

Que se faça e execute um plano de aquisição onde, além de

outros itens, deve conter os riscos considerados assim como os

métodos para gerenciá-los.

 20

Para os fornecedores, ela faz apenas uma referência a riscos, a

mesma destacada no primeiro item de recomendações feita aos compradores.

As demais recomendações são para os processos organizacionais e

apoio ao ciclo de vida, onde se alerta para possíveis riscos quanto à parte técnica,

referentes à tecnologia de software utilizada, a complexidade do produto a ser

desenvolvido ou a itens críticos de proteção e segurança.

Figura 1 – Organização da norma NBR ISO/IEC 12207

Fonte: [PROSD]

3.2 A ABORDAGEM DO SW-CMM

O SW-CMM (Capability Maturity Model) é um modelo para medição da

maturidade de uma organização de desenvolvimento de softwares que foi criado

pelo SEI (Software Engineering Institute). O SW-CMM é baseado em cinco estágios

de maturidade que vai do nível 1 (processo inicial), que é apenas um ponto de

 21

referência e que teoricamente é onde o caos impera, até ao nível 5, que é o

processo com melhoria contínua, também conhecida como Otimizado. Estes

estágios são caracterizados pela existência (definição, documentação e execução)

de determinados processos dentro da organização que são chamados de KPA's

(Key Process Areas) [PAU93].

O CMM trata os riscos de um projeto com muito cuidado e atenção. Ele

começa definindo os riscos de acordo com o dicionário americano Webster, que diz

o seguinte: “Risk is the possibility of suffering loss”. Traduzindo, Risco é a

possibilidade de sofrer perdas.

Em um ambiente de projeto, uma perda significa um impacto direto na

qualidade do produto final, no atraso do cronograma, num aumento de custos ou até

mesmo na falha do projeto.

O SW-CMM faz inúmeras referências a riscos em um projeto de

desenvolvimento de software ao longo de sua metodologia, mas não trata de forma

isolada o assunto. Contudo, ela faz referência a outros documentos específicos para

gerenciamento de risco em projetos de desenvolvimento de software.

Um destes documentos é o SRE (Software Risk Evaluation) que foi

desenvolvido pelo SEI, mesma instituição que criou o SW-CMM.

 22

3.2.1 SRE

O SRE é uma metodologia para identificar, analisar e desenvolver

estratégias de mitigação para os riscos num ambiente de desenvolvimento de

software [WPB99].

Além da definição de risco que o SW-CMM utiliza, o SEI define ainda

um paradigma para gerenciamento de risco calcado nas seguintes áreas:

Identificação;

Análise;

Planejamento;

Acompanhamento/Monitoração;

Controle;

Comunicação.

O SRE trabalha com as áreas de identificação, análise, planejamento e

comunicação com o objetivo de criar uma visão dos riscos que podem afetar o

projeto. Entre tantos benefícios, podemos destacar alguns:

Cria uma visão compartilhada dos riscos entre as pessoas

envolvidas com o projeto;

Cria uma estrutura comum para falar sobre riscos e a mitigação

dos riscos;
 23

Cria uma “foto” de cada risco, isto é, tem uma visão com todas

as informações para cada risco.

3.2.1.1 O Método SRE

O SRE é implementado em cinco áreas conforme o esquema da Figura

2 que segue abaixo:

Figura 2 – Áreas do SRE

Fonte: [WPB99]

Essas cinco áreas possuem uma compatibilidade muito grande com as

áreas de gerenciamento de riscos do PMBOK, que é tratado no capítulo 3.3.

De forma bem sucinta, segue uma descrição de cada área.

3.2.1.1.1 Contratação

Definido pelo próprio SEI como uma das áreas mais importantes, esta

área tem como principais funções à de definir as expectativas do próprio gerente de

projetos bem como as dos stakeholders1; deixar explícito o que será entregue no

1
Stakeholders são todos os interessados e envolvidos no projeto.
 24

final do projeto, garantindo um acordo comum entre os stakeholders; garantir o

patrocínio do gerenciamento do projeto e uma participação ativa e um suporte visível

para as atividades de gerência de riscos; elaborar um acordo de trabalho entre o

líder do time de SRE e o patrocinador que visa assegurar que o trabalho feito por

ambas às partes sejam beneficiados e compartilhado da mesma forma; padronizar

as medidas que serão utilizadas para as análises de exposição ao risco de acordo

com o seu impacto e probabilidade. A Quadro 1 é um exemplo de uma tabela de

referência para exposição de riscos.

Probabilidade
Impacto Muito Provável Provavelmente Improvável
4 - Catástrofe Alto/6 Alto/5 Médio/4
3 - Crítico Alto/5 Médio/4 Médio/3
2 - Médio Médio/4 Médio/3 Baixo/2
1 - Negligenciável Médio/3 Baixo/2 Baixo/1

Quadro 1 – Exposição de Riscos

Fonte: Adaptado de [WPB99]

3.2.1.1.2 RI&A (Identificação e Análise de Risco)

Nessa fase o time de SRE visita o ambiente de desenvolvimento para

poder extrair informações relacionadas a riscos através de entrevistas estruturadas

com os membros da equipe. As informações de risco são analisadas, priorizadas de

acordo com o impacto no projeto, e agrupadas em áreas de risco e por fim, o time de

SRE apresenta os resultados de todo esse trabalho para a equipe do projeto e

gerentes envolvidos.

As entrevistas são feitas obedecendo a um critério, formando

assim um ciclo de entrevista de acordo com a Figura 3.

 25

Figura 3 – Ciclo da Entrevista

Fonte: [WPB99]

Passo 1: O entrevistador fará as perguntas exatamente como

foram escritas (para assegurar consistência e manter um suspense intencional com

a pergunta). Se a resposta à pergunta indicar que existe uma preocupação naquela

área, então o entrevistador passará direto para o passo3.

Passo 2: Se a pergunta do passo 1 não gerou nenhum assunto ou

preocupação e se existir uma pergunta de acompanhamento para futuras

investigações da área, então o entrevistador fará a pergunta exatamente como está

escrita. Se mesmo assim não existir nenhum assunto que cause alguma

preocupação, então o entrevistador volta para o passo 1 com outra pergunta.

 26

Passo 3: O entrevistado colocará num formulário de riscos em branco as

suas preocupações, conselhos e outras informações que julgar que sejam

importantes.

Passo 4: A pessoa responsável por registrar os riscos irá escrever em

um flipchart (por exemplo), num formato de Condição-Consequência, para que todos

os entrevistados possam ler. O entrevistado deverá confirmar se o que está escrito

(no flipchart) é exatamente o que ele quis dizer. E por fim, os demais entrevistados

são questionados se entenderam o assunto que foi levantado. Não é necessário que

os entrevistado concordem com o risco levantado, mas que entendam o que o

colega entrevistado quis dizer. Após estas confirmações, volta-se ao passo um até

que se completem todas as perguntas ou se esgote o tempo para a entrevista, que

não deve ultrapassar duas horas e meia.

3.2.1.1.3 Relatório Provisório

Nessa fase ocorre uma análise dos dados de saída da fase anterior

(RI&A) sob o ponto de vista do relacionamento interno dos riscos com as áreas de

risco. É feita uma recomendação ao gerente de projeto sobre os riscos que devem

ser considerados no plano para a estratégia de mitigação (próxima fase, MSP) e

após um acordo quanto às áreas de risco, a fase de MSP é agendada.

3.2.1.1.4 MSP (Plano para a Estratégia de Mitigação)

A fase de MSP tem como principal objetivo o de iniciar a estratégia

para o desenvolvimento do plano de mitigação dos principais riscos (mais

 27

importantes) que foram identificados durante a fase de RI&A. Isso será feito através

de um trabalho conjunto entre a equipe do projeto, gerentes e o time de SRE, onde

estes criarão as metas, estratégias e atividades para o desenvolvimento do MSP.

3.2.1.1.5 Relatório Final

Essa última fase tem como saída o relatório final, onde é feita uma

consolidação dos dados resultantes das fases de RI&A e MSP. Os membros da

equipe de SRE ajudam a escrever o relatório final que é por sua vez entregue pelo

líder de equipe do SRE para o gerente de projetos e encerram-se as atividades da

equipe de SRE.

3.2.2 Considerações finais sobre o CMM

Apesar do método SRE ser bem trabalhado e cumprir com o seu

objetivo, que é o de trabalhar com as áreas de identificação, análise, planejamento e

comunicação, o CMM não deixa claro em sua metodologia ou documentos de apoio,

como serão tratadas as outras duas áreas do gerenciamento de projetos (segundo o

seu próprio paradigma) que são o de acompanhamento/monitoração e controle.

Dessa forma, sem uma metodologia padrão que oriente o gerente de projetos a

conduzir essas duas áreas, o trabalho final de gerência de riscos ainda dependerá

única e exclusivamente das habilidades e experiência do próprio gerente de projetos,

que poderá fazer ou não um acompanhamento e controle dos riscos de forma

adequada.
 28

Uma das grandes contribuições que o CMM trouxe foi a de

consolidar a importância da gerência de projetos para a engenharia de software

[SALSD].

Contudo, já existe uma nova versão do CMM, o CMMI (Capability

Maturity Model Integrated) onde a gerência de riscos ganha ainda mais destaque. O

modelo CMMI é uma evolução do SW-CMM. No CMMI está definida uma área de

gerência de projeto composta por seis áreas de processo: planejamento de projeto,

acompanhamento e controle de projeto, gerenciamento de acordos com

fornecedores, gerenciamento integrado do projeto, gerenciamento de risco, e

gerenciamento quantitativo de projeto [SALSD].

3.3 A ABORDAGEM DO PMBOK

O PMBOK é reconhecido hoje em dia como uns das melhores

referências para gerenciamento de projetos e foi desenvolvido pelo PMI (Project

Management Institute). O PMI foi fundado em 1969 como uma instituição sem fins

lucrativos e está sediada na Filadélfia, Estados Unidos da América [PMISD].

Por ser uma metodologia de gerência de projetos que foi desenvolvida

para qualquer tipo de projeto e devido à natureza de sua instituição, o PMBOK é um

modelo que cobre todas as disciplinas, métodos e técnicas que fazem parte do

universo da gerência de projetos e as melhores práticas dentro da área.

 29

Figura 4 – Áreas de Conhecimento do PMBOK.

Fonte: Adaptado de [PMISD]

O seu reconhecimento se tornou tão grande que se tornou um padrão

americano pela American National Standards Institute (ANSI) que por sinal é o

padrão no qual está se baseia a norma brasileira.

Além da ANSI, o IEEE (Institute of Eletrical and Eletronic Engineers)

também o reconheceu como padrão de gerenciamento de projetos e a está sendo

utilizado como referência pela ISO (International Standards Organization) e por

empresas que desenvolvem sua própria metodologia de gerenciamento de projetos.

Embora já se tenham notícias da nova versão do PMBOK, a edição

2004 ainda não se encontra disponível. O que se sabe, através de fontes não oficiais

(afiliados do PMI) é que a edição 2000 possui o mesmo número de processos (seis)

na área de gerenciamento de riscos que a edição 2004. Talvez seja um indício de

que haja poucas mudanças nessa área. Assim sendo, este estudo foi baseado na

edição de 2000, a versão oficial e atual [SOTSD].

 30

Os seis processos na área de gerenciamento de riscos são:

Planejamento da Gerência de Risco; Identificação dos Riscos; Análise Qualitativa

dos Riscos; Análise Quantitativa dos Riscos; Planejamento de Resposta a Riscos;

Controle e Monitoração de Riscos.

Estes processos têm como finalidade à identificação, análise e

resposta aos riscos de um projeto e estes processos interagem entre si e entre as

demais áreas de gerenciamento de projetos, conforme explicado na introdução.

Os conceitos sobre o que são riscos já foram abordados no capítulo 2 e

assim sendo, não serão novamente discutidos nesta seção, pois se trata da mesma

definição.

Quanto aos processos de gerenciamento de riscos, segue uma

descrição de seu funcionamento [PMI00].

3.3.1 Planejamento da Gerência de Risco

O processo de planejamento da gerência de risco é fundamental, pois

é nele que será decidido como serão abordados e tratados os riscos ao longo do

projeto.

Na figura abaixo são citadas algumas entradas para este processo. O

Project Charter e o EAP (Estrutura Analítica do Projeto) são resultados de outra área

de gerenciamento de projetos, a área de escopo.

 31

Figura 5 – Visão do processo de Planejamento da Gerência de Risco

Fonte: [PMI02]

Os demais itens de entrada são referentes a políticas e padrões da

própria organização, as pessoas que são responsáveis por decidir cada assunto

relacionado ao projeto e as definições de níveis de tolerâncias a risco que a

organização tem.

Após serem analisados os dados de entrada em reuniões com o

gerente de projetos e os líderes de cada área de gerenciamento de projetos, chega-

se a um denominador comum, em forma de relatório, que é o plano de gerência de

riscos, onde há descrição de como e com que pesos serão tratados cada um dos

próximos processos da área de gerenciamento de risco.

Este relatório não possui um formato pré-estabelecido, mas possui uma

definição bem clara quanto aos dados que deve conter. Entre outras definições, o

plano de gerenciamento de risco deve indicar:

• Qual a metodologia será utilizada;

 32

• As funções e responsabilidades de cada membro da equipe de

gerenciamento de riscos;

• O orçamento previsto para a equipe de gerenciamento de riscos;

• Com que freqüência será executado o processo de gerenciamento

de riscos;

• As medidas que serão utilizadas para pontuação e interpretação,

garantindo dessa forma a utilização das mesmas medidas durante

todo o projeto;

• Quais serão os níveis de tolerância a risco;

• O formato e o conteúdo do plano de resposta a riscos (não é o

plano em si, mas como será estruturado o plano);

• A monitoração dos riscos.

Embora não exista uma definição quanto ao formato do relatório, o

Quadro 2 é um exemplo de como seria um relatório, baseando-se nas

recomendações do PMBOK.

Onde:

1. Número que identifica o risco. Seqüencial iniciando em 1.

2. Descrição do risco.
 33

3. Área do projeto que é afetado com esse risco.

4. Sintomas que possam indicar a possibilidade de ocorrência do

risco.

5. A causa do risco e o impacto deste risco nos objetivos do projeto.

6. Pessoa ou departamento responsável pelo risco.

7. Quais as responsabilidades designadas e o prazo de conclusão

para cada item relatado no campo 5.

8. Em qual data e qual foram às ações tomadas para cada risco. Isso

inclui respostas acordadas, fuga, transferência, mitigação ou

aceitação.

9. Quais medidas serão tomadas em caso de falha de

responsabilidades e de ações.

1 - ID 2 - Descrição
-
3 - Área(s)
-
4 - Sintoma(s)
-
5 - Efeito e Impacto
-
6 - Responsável(eis) 7 - Responsabilidade e prazo
- -
8 - Histórico (data e ação)
-
9 - Contingência
-
Quadro 2 – Exemplo de Relatório de Riscos
 34

3.3.2 Identificação dos Riscos

Esse processo, como o nome já diz, tem como função à identificação

de riscos que podem vir a afetar o projeto e documentar as principais características

de cada risco.

Figura 6 – Visão do processo de Identificação dos Riscos

Fonte: [PMI02]

Pode-se ver claramente através do diagrama acima a interação entre si

dos processos e entre as áreas. O primeiro item de entrada para este processo é o

item de saída do processo anterior. O segundo item é o resultado de saída das

outras áreas de gerenciamento de projetos (conforme o modelo do PMBOK), como

por exemplo, o Project Charter, a EAP, a descrição do produto, o cronograma e

estimativa de custo, o plano de aquisição entre outros tantos planos.

As categorias de riscos visam poder classificar os riscos por áreas, de

acordo com o perfil de cada risco, como por exemplo, riscos técnicos, de qualidade,

de desempenho, de gerência de projetos, organizacionais, externos e outros tantos

quanto forem possíveis, desde que se aplique a área de negócio da organização e

ao projeto em si.
 35

Informações históricas são outros dados de entrada e que possuem um

papel muito interessante. Baseado nas lições aprendidas de projetos passados

pode-se ter novas identificações de riscos.

Para que se possam identificar os riscos, existem técnicas de coleta de

informações das mais variadas, que podem ser utilizadas em reuniões coletivas ou

individuais. Técnicas amplamente utilizadas são as de brainstorming, Delphi, SWOT

e entrevistas. Também podem ser desenvolvidos checklists para a identificação dos

riscos com base em informações históricas.

Além dos riscos envolvidos na execução do projeto, existem ainda os

riscos envolvidos nas hipóteses e premissas utilizadas na definição do projeto. A

análise de premissas é uma técnica que envolve a validação das premissas,

evitando-se assim a execução de um projeto baseado em premissas irreais.

Já as técnicas de diagramação podem incluir entre outros, o diagrama

de fishbone, castas de fluxo de processo e diagrama de influência.

O resultado de tanta análise é um documento com a relação de todos

os riscos identificados com uma descrição do próprio risco e dos sintomas (gatilhos)

que servem como sinais de advertência de que o risco aconteceu ou está preste a

acontecer.

Além da identificação dos riscos, pode ocorrer ainda a identificação de

falha(s) em um ou mais planos de outras áreas, gerando então uma entrada para as

outras áreas.
 36

3.3.3 Análise Qualitativa dos Riscos

O principal objetivo da análise qualitativa é o de avaliar o impacto e a

probabilidade dos riscos identificados e prioriza os riscos de acordo com o seu efeito

potencial nos objetivos do projeto.

Figura 7 – Visão do processo de Análise Qualitativa dos Riscos

Fonte: [PMI02]

Os dois primeiros itens de entrada são resultados dos processos

anteriores e já foram abordados. Os itens de Situação do Projeto, Tipo do Projeto,

Precisão de dados e Restrições são dados referentes ao momento em que se

encontra o projeto e informações já utilizadas nos processos anteriores. Servem

como apoio e base para a análise de probabilidade e impacto. Quanto ao item de

Escala de Probabilidade e Impacto, essa escala será utilizada de acordo com as

definições no plano de projeto, onde os dados de pesos e medidas foram definidos e

servem justamente para garantir que os processos utilizem as mesmas unidades.

Os dois primeiros itens da fase de Ferramentas e Técnicas são

construídos baseados nas definições do plano de gerência de riscos de acordo com

os pesos e medidas que foram previamente definidos. Exemplos de avaliação de

 37

impactos nos objetivos do projeto e de uma matriz de probabilidade versus impactos

do projeto são mostrados nos quadros Quadro 3 e Quadro 4 respectivamente.

As saídas desse processo são listas de riscos prioritários e de riscos

para análise, bem como a classificação do risco global para o projeto. Com a

repetição dessas rotinas pode-se criar uma tendência nos resultados, provocando

uma resposta aos riscos ou uma análise adicional.

Quadro 3 – Método de pontuação de impacto com abordagem ordinal

Fonte: Adaptado de [PMI02]

Quadro 4 – Classificação do risco com abordagem cardinal de probabilidade x impacto.

Fonte: Adaptado de [PMI02]
 38

3.3.4 Análise Quantitativa dos Riscos

O processo de análise quantitativa muitas vezes se confunde com o de

análise qualitativa. No entanto, enquanto que a análise qualitativa visa avaliar o

impacto e a probabilidade dos riscos identificados, a análise quantitativa tem como

objetivo analisar numericamente a probabilidade de cada risco e sua conseqüência

nos objetivos do projeto. Mesmo assim, os processos de análise qualitativa e

quantitativa podem ser utilizados em conjunto ou separadamente.

Figura 8 – Visão do processo de Análise Quantitativa dos Riscos

Fonte: [PMI02]

Os primeiros cinco itens e o último item de entrada são resultados de

saída de processos anteriores ou já foram discutidos, portanto não serão

comentados novamente.

O item de Avaliação Especializada é discutido em outra área da

gerência de projetos, a de Escopo. Basicamente este tipo de avaliação é feito por

pessoas que possuem elevado conhecimento em um determinado assunto e são

consultados. Essas pessoas podem ou não fazer parte da equipe ou organização.

 39

As técnicas utilizadas nesse processo são de entrevistas técnicas que

visam quantificar a probabilidade e as conseqüências dos riscos nos objetivos do

projeto, de análises de sensibilidade que tem como objetivo determinar quais são os

riscos que possuem o maior potencial de impacto no projeto, de análise de árvore de

decisão que permite uma visualização gráfica com valores para cada decisão

tomada, facilitando o tomador de decisões, e de simulação, que normalmente utiliza

a técnica de análise de Monte Carlo.

Como saída temos um relatório com os riscos que possuem maior

ameaça ou maior oportunidade para o projeto. Outra saída é um relatório com todas

as previsões de cronogramas e resultados de custos prováveis do projeto e outro

relatório com a probabilidade de se alcançar os objetivos do projeto.

3.3.5 Planejamento de Resposta a Riscos

Esse processo tem como principal objetivo o de desenvolver opções e

determinar ações para ampliar as oportunidades e reduzir as ameaças aos objetivos

do projeto.

Todos os dados de entrada já foram tratados nos processos anteriores.

Apesar de não haver nenhuma novidade quanto aos dados de entrada, esse

processo consegue chegar a essa quantidade de informações de saída graças à

análise conjunta de todas esses dados de entrada em conjunto com as técnicas de

evitar o risco, onde o plano do projeto é modificado para garantir que o risco seja

evitado, transferir o risco, quando a responsabilidade e as conseqüências do risco é

transferida para uma terceira parte, a mitigação, que é a técnica de reduzir o máximo
 40

possível à probabilidade do evento de risco ocorrer e se ocorrer, que a sua

conseqüência seja a menor possível e a técnica de aceitação, que visa não fazer

qualquer alteração no plano do projeto para lidar com um risco.

Figura 9 – Visão do processo de Planejamento de Resposta a Riscos

Fonte: [PMI02]

Os resultados de tanta análise são diversas saídas. O plano de

resposta aos riscos é um, onde entre outros, procura-se, sempre que possível,

preencher com os seguintes dados:

• Riscos identificados, suas descrições a(s) área(s) do projeto

afetado(s), suas causas e como eles podem afetar o objetivo do

projeto;

• Os responsáveis pelo risco e as responsabilidades designadas;

• Resultados dos processos de análise qualitativa e quantitativa;

 41

• Respostas acordadas incluindo fuga, transferência, mitigação ou

aceitação, para cada risco no plano de respostas a riscos;

• Ações específicas para implementar a estratégia da resposta

escolhida;

• Orçamento e prazos para a resposta;

• Planos de contingência e planos de reserva.

Outras saídas são os relatórios de riscos residuais e secundários onde

respectivamente são tratados os riscos que permanecem depois das respostas de

fuga, transferência ou mitigação ou os riscos que surgem como resultado direto de

uma ação de resposta a um risco.

Uma saída que também é muito utilizada, especialmente por

departamentos comerciais, é a utilização de acordos comerciais, que visam pré-

estabelecer a responsabilidade de cada parte mediante a ocorrência de algum risco

específico.

Quanto às saídas restantes, o próprio nome já indica o que são e já

foram comentados nos processos anteriores.

3.3.6 Controle e Monitoração de Riscos

É o processo que deve manter a rastreabilidade dos riscos

identificados, monitorar riscos residuais e identificar novos riscos, bem como

 42

assegurar a execução dos planos de risco e avaliar a sua efetividade em redução

dos riscos.

Figura 10 – Visão do processo de Controle e Monitoração de Riscos

Fonte: [PMI02]

Os dois primeiros itens são resultados de processos anteriores e o

terceiro e último item são resultados de processos de outras áreas de gerenciamento

de projetos, a de comunicação e de escopo respectivamente.

A Análise e Identificação de Riscos Adicionais ocorrem na medida em

que o desempenho do projeto é medido e informado e potenciais riscos que

previamente não foram identificados aparecem.

Através da aplicação das técnicas relacionadas na Figura 10, teremos

como resultado as seguintes saídas:

• Planos de workaround (contorno). É a documentação das respostas

aos riscos que anteriormente foram aceitos ou que não foram

identificados.
 43

• Ações corretivas. Consiste em executar o plano de contingência ou

workaround.

• Solicitações de Mudança no Projeto. Este tipo de documento visa

solicitar a mudança no projeto em função da implementação dos

planos de contingência ou workaround.

• Atualizações no plano de resposta a riscos. Ao longo do projeto, os

riscos previamente identificados podem vir a ocorrer, diminuir e até

mesmo deixar de existir. Essas mudanças de probabilidade e

ocorrência devem ser devidamente registradas.

• Atualizações de checklist de identificação de risco e Banco de

dados de risco são meios de proporcionar no futuro a consulta

sobre dados históricos.

 44

4 FERRAMENTAS DE GERENCIAMENTO DE RISCO

São poucas as ferramentas disponíveis no mercado que auxiliam o

gerenciamento de riscos. Esse capítulo tem como função fazer uma análise sobre

algumas destas ferramentas.

4.1 PERTMASTER

O pertmaster é uma ferramenta que pode importar os arquivos de

gerenciamento de projetos do MS Project e do PRIMAVERA, que são as

ferramentas mais conhecidas nessa área e fazer uma análise de risco do projeto ou

até mesmo criar todo o projeto diretamente na própria ferramenta.

A Figura 11 (pg.45) é uma amostra de um projeto sendo controlado

através do Pertmaster.

Através do registro de estimativas mínima, máxima e provável do

tempo de cada tarefa, bem como a indicação da probabilidade da ocorrência de

cada risco, podemos fazer o programa rodar uma análise dos riscos do projeto. A

ferramenta procura dar a resposta para a pergunta de qual é a probabilidade de

entregar o projeto no prazo.

 45

Figura 11 – Gerenciamento de Projetos no Pertmaster

As figuras Figura 12 e Figura 13 (pg.46) são amostras de resultado de

análise de risco em um projeto hipotético.

Além da análise de risco relativa a tempo e probabilidade, há ainda a

possibilidade de avaliar os riscos do projeto referentes ao custo do mesmo.

A ferramenta é de fácil manuseio, intuitiva e conta com um bom tutorial

para criação de novos projetos e criação e análise de riscos do projeto.

A versão do produto analisado foi a 7.5.2.13, licença de avaliação.

 46

Figura 12 – Gráfico de tempo por riscos

Figura 13 – Gráfico de tempo para o projeto

 47

4.2 RISKTRAK

O RiskTrak é uma ferramenta de Gerenciamento de riscos com suporte

a múltiplos usuários que permite a todos que utilizam a ferramenta e que possuem

as permissões de acesso, a visualização, análise, comunicação, criação de

relatórios e gerenciar os riscos (custo, tempo e técnico) durante todo o projeto.

O RiskTrak também pode importar o projeto de outras ferramentas. Ele

importa os dados de projeto do MS Project e de qualquer outra ferramenta que tenha

a possibilidade de exportar o projeto em um arquivo CSV.

Este programa oferece algumas funcionalidades bem interessantes,

como por exemplo, um questionário para medir os riscos do projeto atual. Ao criar o

projeto, pode-se optar por criar um projeto novo, do zero, baseando-se apenas nas

informações que o usuário da ferramenta possui ou pode-se criar projetos através de

assistentes, que através de perguntas focadas em riscos, ajudam a definir a

estrutura do projeto. Outra funcionalidade é a de poder gerar relatórios de status

através de queries diretamente em sua base de dados, como pode ser visto na

Figura 15 (pg.48) e a possibilidade de facilmente gerar diversos gráficos dos riscos

do projeto no que se refere a tempo e custo.

Um ponto muito forte da ferramenta é quanto à identificação, análise e

mitigação do risco. A ferramenta oferece um editor de riscos que permite inúmeras

atribuições ao risco, entre elas: custo, tempo, probabilidade, proporção, estratégia de

mitigação, descrição completa do risco, fase do risco, classe, status, responsável,

prazo para resolução e campo para comentário. Veja exemplo na Figura 16 (pg.49).
 48

Figura 14 – Exemplo de uma Lista de Riscos no RiskTrak

Figura 15 – Query no banco de dados

 49

Figura 16 – Exemplo de definição de risco no RiskTrak

A ferramenta é muito interessante e dá uma boa visibilidade dos

conceitos e métodos de gerenciamento de risco. A versão utilizada para a análise da

ferramenta foi a 4.50.03, versão de demonstração.

4.3 RISK+

O Risk+ é uma ferramenta que funciona de forma integrada com o MS

Project. Visto que o gerenciamento de risco não é contemplado no MS Project, o

Risk+ trabalha como uma ferramenta que visa suprir esta necessidade. Ao ser
 50

instalado, o Risk+ inclui um menu no MS Project referente as suas ferramentas,

conforme ilustrado na Figura 17.

Figura 17 – Integração do Risk+ com o MS Project

Contudo, o Risk+ é uma ferramenta focada apenas no controle de

riscos envolvidos com o controle de tempo e de custos. As simulações que a

ferramenta utiliza para quantificar o risco são baseadas na técnica de Monte Carlo.

O Risk+ utiliza as informações de tempo e custo que foram definidas no

MS Project para fazer as suas projeções, contudo, os campos são abertos para

modificação de acordo com a percepção do usuário, como pode ser visto na Figura

18.
 51

Figura 18 – Entrada de dados para análise de tempo e custo no Risk+

Após os ajustes (se necessário) para tempo e custo, pode-se rodar a

ferramenta de análise. A Figura 19 é um exemplo do resultado desta análise.

Figura 19 – Resultado da análise de tempo no Risk+

A versão do Risk+ utilizado para esta análise foi a 2.0.

 52

5 PROPOSTA DE GERENCIAMENTO DE RISCOS

O modelo de gerenciamento de riscos propostos pelo PMBOK se

destacou dos demais por ser um modelo que não é direcionado a um determinado

público.

Por ser uma metodologia de gerenciamento de projetos que se aplica a

qualquer tipo de projeto, por ter sido criado baseando-se em práticas de mercado

que tiveram sucesso comprovado, por ter sido definido como referência e, em alguns

casos, como modelo padrão para gerenciamento de projetos por outros institutos de

reconhecimento nacional e internacional, como, por exemplo, a ANSI, IEEE e a ISO,

e por não ter motivos para se re-inventar a roda, é que o PMBOK foi escolhido como

metodologia base para ser aplicada no estudo de caso.

Para possibilitar a aplicação da metodologia do PMBOK num ambiente

de infraestrutura de TI, fez-se necessário desenvolver um protótipo de ferramenta

que atenda os requisitos e processos do gerenciamento de riscos desta

metodologia.

Assim sendo, algumas ferramentas de apoio foram escolhidas para

auxiliar estas fases de desenvolvimento. Duas ferramentas da Borland foram

 53

escolhidas, uma para criar a modelagem em UML do protótipo e a outra para o

desenvolvimento do software. A ferramenta de modelagem da Microsoft também foi

utilizada para dar apoio à fase de modelagem. Segue a relação das ferramentas

utilizadas:

• Borland Delphi Enterprise Trial – Versão 7.0 (Build 4.453);

• Borland Model Maker Demo – Versão 6.20 (Build 1402);

• Microsoft Visio Professional 2002 SR-1.

5.1 MODELAGEM DO PROTÓTIPO

A metodologia de gerenciamento de riscos do PMBOK é muito rica de

informações e já foi bem referenciada no capítulo 3.3 e, portanto, não será

novamente discutida aqui. No entanto, com o intuito de extrair os principais

processos da metodologia, faz-se necessário entrar novamente na metodologia para

tirar um “raio x” de sua estrutura principal.

Para que o protótipo venha a ter condições de suportar a metodologia,

é necessário que os principais processos da metodologia sejam corretamente

representados dentro da ferramenta. São seis os processos e, o resultado de cada

um serve de entrada para o próximo. São eles:

• Planejamento da Gerência de Risco;

• Identificação dos Riscos;

 54

• Análise Qualitativa dos Riscos;

• Análise Quantitativa dos Riscos;

• Planejamento de Resposta a Riscos;

• Controle e Monitoração de Riscos.

Esse é o “raio x” da metodologia de gerenciamento de riscos escolhida

e que serviu de norte para o desenvolvimento do protótipo.

Visto que existem diferentes papéis no que diz respeito a gerência de

riscos, fez-se necessário distinguir os diferentes tipos de usuários do protótipo. Num

primeiro nível estaria o gerente do projeto e em outros níveis os Stakeholders. Além

desta distinção, existe ainda a distinção entre os membros do projeto, pois alguns

podem estar apenas acompanhando o projeto e outros muito mais envolvidos,

colaborando nas diversas fases do mesmo. Assim sendo, surgiu a necessidade de

diferenciar os tipos de acessos de cada participante do projeto.

Figura 20 – UML Use Case – Visão Macro

 55

Numa visão macro, o sistema deve possibilitar ao gerente de projetos a

manutenção do(s) seu(s) projeto(s), riscos e usuários que fazem parte da sua equipe

de trabalho. Os membros do projeto passam a ter acesso às informações do projeto

e os riscos envolvidos no mesmo, de acordo com seu perfil (classe) de usuário.

Surgiu também a visão de um administrador da ferramenta, que seria o responsável

por criar as contas dos gerentes de Projetos. A Figura 20 (pg.54) exemplifica melhor

esta visão.

Para entender melhor a proposta, vamos expandir a visão para cada

uma das funcionalidades do protótipo.

Por ordem de funcionalidade, vamos analisar a visão “Definir Usuários”,

como é ilustrado na Figura 21. Existem apenas dois perfis de usuários que teriam

acesso a essa funcionalidade, o usuário administrador e o gerente. O usuário

administrador pode criar usuários e suas principais funções seriam a de atribuir ao

usuário o perfil de gerente de projeto e também excluir usuários da ferramenta.

O usuário com perfil de gerente de projeto tem acesso completo em

todas as atividades de seu projeto, diferente do que ocorre com um membro do

projeto. Porém, o administrador não tem o poder de definir a qual projeto o usuário

irá pertencer e tão pouco apontar o papel dele no projeto. Esse é um papel que só

diz respeito ao perfil de gerente do projeto.

Para a criação de usuários, são necessárias algumas informações

básicas, como por exemplo, nome do usuário, telefone, e-mail entre outras. Isso está

representado no diagrama através da função de “Incluir Informações do Usuário”.

 56

Figura 21 – UML Use Case – Visão “Definir Usuários”

Outra função representada no diagrama é o de atribuir um login e

senha para o usuário.

Apesar da metodologia não fazer nenhuma menção a tipos de

usuários, existe sim a distinção do Gerente do Projeto e dos demais membros do

mesmo. Existe ainda uma referência aos papéis de cada membro da equipe no

projeto. Portanto, para representar essa hierarquia e ao mesmo tempo para tornar os

dados do projeto mais seguro, fez-se esta classificação.

Essa distinção de usuários se torna ainda mais perceptível quando

expandimos a visão “Manter Riscos”, conforme ilustrado na Figura 23 (pg.60). O

membro do projeto terá o acesso às informações que o seu perfil de usuário permitir.
 57

Os níveis de acesso foram classificados em “Simples”, “Colaborador” e

“Avançado”. O perfil de acesso “Simples” é o mais básico de todos. Só permite a

visualização dos riscos. O acesso de “Colaborador” só libera o acesso aos riscos,

mas este por sua vez já possui a liberdade de fazer alterações, adicionar e remover

riscos. Por fim, o perfil de usuário “Avançado” permite total liberdade de ação na

área de riscos e ainda permite visualizar todas as informações referentes ao projeto.

Na visão “Manter Projeto”, conforme ilustrada na Figura 22 (pg.59),

temos toda a estrutura do projeto. É lá que serão inseridas as informações

gerenciais do projeto. O primeiro (um dos mais trabalhosos para o gerente de

projetos) dos seis processos, o Planejamento da Gerência de Riscos, está

caracterizado de forma bem explícita nessa modelagem. Se olharmos a metodologia

com atenção, veremos que este processo é um dos mais importantes e de maior

volume de informações. Por se tratar do processo inicial e de planejamento de toda

a gerência de riscos, ele teve um destaque especial no protótipo. Assim sendo, as

seguintes funções do primeiro processo foram atribuídas ao protótipo: descrição do

projeto; a forma com que os riscos serão lidados e conseqüentemente a tolerância

aos riscos; a metodologia que será utilizada ao longo do projeto; a definição do

orçamento para a gerência de riscos; escolha dos membros da equipe, seus papéis

e permissões.

A definição da matriz de impacto embora também seja ligado ao

planejamento da gerência de riscos está totalmente relacionada a outros dois

processos, o de “Análise Qualitativa” e “Análise Quantitativa”, servindo como base

para os cálculos e análises realizados nestes processos.

 58

Três dos seis processos principais da gerência de riscos já foram

abordados na modelagem até aqui. Para entender como os outros três processos

são suportados no protótipo, vamos focar as atenções na visão “Manter Riscos” que

está representada na Figura 23 (pg.60).

Embora muitas funções são utilizadas em mais de um processo, isto é,

são utilizadas explicitamente num processo e servem como apoio e tomadas de

decisão nos outros processos, vamos procurar separar as funções para que se

possa ter uma visibilidade dos processos da metodologia.

A função de descrever o risco faz parte do processo de “Identificação

do Risco”. Embora as funções relacionadas ao risco, como por exemplo “Indicar a

Área Afetada” e “Descrever os Sintomas dos Riscos” possam parecer que fazem

parte do processo de “Identificação dos Riscos”, elas não fazem. Estão relacionadas

com o processo de “Planejamento de Resposta a Riscos” que além destas funções

ainda possui outras, como por exemplo, a função de “Atribuir Responsabilidades”.

 59

Figura 22 – UML Use Case – Visão “Manter Projeto”

 60

Figura 23 – UML Use Case – Visão “Manter Riscos”

 61

Outras funções fazem parte desse processo, mas se fundem com os

processos de “Análise Qualitativa” e “Análise Quantitiva” como por exemplo, as

funções “Definir Ações de Mitigação ou Contingência”, “Determinar o Impacto no

Projeto”, “Determinar a Probabilidade“ e “Determinar o Impacto no Objetivo do

Projeto.

Por fim, o processo de “Controle e Monitoração de Riscos” está

caracterizado através da função de ”Acesso Histórico de Aç ões”, contudo, não fica

restrito a apenas esta função, uma vez que a ferramenta permitirá alterações nas

informações dos riscos ao longo do projeto como, por exemplo, a mudança de status

do risco, de impacto e criticidade.

Estas visões podem parecer um tanto quanto confusas. Existem

funções servindo para mais de um processo e ações que são o resultado da saída

de um ou mais processos e, todas, sendo exibidas em uma única modelagem.

Embora a modelagem dê margem para tal interpretação (confusão), ela passa a ser

muito clara no momento que os processos da metodologia de gerenciamento de

riscos são bem conhecidos, pois a própria metodologia força uma interação entre os

processos, criando um ciclo que só terminará quando o projeto for concluído.

Levando em conta o resultado obtido com a modelagem de “Use Case”

proposta, o próximo passo foi de modelar as classes do protótipo. A Figura 24

(pg.62) é o resultado final do diagrama de classes em UML.

A classe “Projeto” se tornou a principal classe em virtude de todas as

atividades estarem relacionadas ao projeto. Ou seja, não há riscos ou pessoas

gerenciando riscos sem que estes estejam alocados a um projeto.

 62

Existe ainda uma herança no diagrama, a classe “Membro” herda as

propriedades da classe “Pessoa” e o relacionamento da classe “Membro” com a

classe “Projeto” gera uma outra classe, que é a de “Permissões”. Nesse

relacionamento estará definido que tipo de acesso cada usuário terá nas

informações de cada projeto.

Tendo em vista que o diagrama de classes é auto-explicativo e que o

diagrama de “Use Case” já explicou os objetivos de funcionalidade do protótipo, o

próximo passo é o de desenvolvimento do protótipo.

Figura 24 – UML Diagrama de Classes

 63

5.2 DESENVOLVIMENTO DO PROTÓTIPO

Tendo em vista que todo o planejamento do protótipo já foi feito e

explicado nas sub-seções anteriores, vamos ver agora como foi desenvolvido o

protótipo.

Como um dos itens modelados estava relacionado diretamente aos

perfis de usuários e suas permissões de acesso nos projetos, a primeira tela teria

que ser a de login (veja Figura 25). Tendo em vista que é necessário ter pelo menos

um usuário com permissões para criar outros usuários, o usuário padrão do protótipo

é o administrador. O usuário administrador terá o poder de criar novos usuários e

definir se o usuário terá o perfil de “Gerente”, ou seja, o responsável por gerenciar os

riscos de cada projeto.

Figura 25 – Protótipo – Login

 64

Após o logon, os menus de “Projetos” e “Usuários” se tornam

disponíveis para os gerentes de projetos e no caso dos stakeholders, apenas o

menu de “Projetos”.

Figura 26 – Protótipo – Administração de Contas de Acesso

Caso o gerente de projetos queira adicionar novos membros a sua

equipe, ele terá que acessar o menu usuários. Nesta tela o gerente terá a

possibilidade de adicionar, remover e até mesmo editar as informações de um

membro do projeto (veja todas as informações na Figura 26).

No menu de projetos existe a possibilidade de criar um novo projeto ou

de selecionar um previamente cadastrado conforme ilustrado na Figura 27, pg.65.

Nessa tela é possível ter uma visão macro do projeto.

 65

Figura 27 – Protótipo – Seleção do Projeto

Uma nova tela com acesso as informações do projeto e a lista dos

riscos será exibida após a seleção do projeto que se deseja trabalhar (veja Figura

28, pg.66). Essa tela é muito interessante para o gerente de projetos, pois o mesmo

tem uma visão macro dos riscos envolvidos no projeto e, através dos campos de

“probabilidade” (a probabilidade de o risco vir a ocorrer) e “criticidade” do risco, tem

ainda informações gerenciais que servem de apoio para tomadas de decisão.

A informação de “criticidade” não é uma informação imputada pelo

gerente de projetos e tão pouco pelos stakeholders. Essa informação é gerada

automaticamente pelo protótipo através do cruzamento de informações previamente

imputadas. O cruzamento é feito com a probabilidade de ocorrência do risco versus

o impacto que este mesmo risco tem nos objetivos principais do projeto.
 66

Após este cruzamento o resultado é comparado com uma tabela,

modelo do PMBOK, onde é definido o valor de criticidade do risco que pode ser

baixo, moderado ou alto.

Figura 28 – Protótipo – Lista de Riscos do Projeto Selecionado

Se selecionarmos o botão de “Informações” que está na área “Projeto”

da Figura 28, uma nova tela será exibida com informações relacionadas ao

planejamento da gerência de riscos conforme ilustra a Figura 29, pg.67.

Nesta tela o Gerente de Projetos terá o espaço para registrar todas as

informações gerenciais do projeto. Fará a descrição detalhada do projeto, definirá

qual será a linha para a tolerância aos riscos e terá acesso as demais funções

gerenciais.
 67

Se o gerente quiser definir os membros de sua equipe para o projeto

em questão ele irá clicar no botão “Membros” e a tela ilustrada na Figura 30, pg.68,

será exibida. Uma vez definidos os membros do projeto o gerente deverá atribuir as

permissões de acordo com uma das classes de permissão disponíveis através do

botão “Permissões” na tela de projetos. Na nova tela (Figura 31, pg.68) o gerente irá

escolher o membro da sua equipe e irá atribuir um dos três níveis de acesso2

disponíveis para os stakeholders que são: simples, colaborador e avançado.

Figura 29 – Protótipo – Planejamento do Projeto

A descrição da metodologia que será utilizada para as reuniões com os

stakeholders e demais atividades voltadas a levantar as informações de riscos está

disponível através do botão “Metodologia” na tela de projetos. O gerente também

poderá incluir referências a documentos de apoio ao projeto (Figura 32, pg.69).

2
A explicação detalhada encontra-se na seção 5.1 onde é explicado a Figura 21 – UML Use Case – Visão “Definir Usuários”
 68

Figura 30 – Protótipo – Definição de Membros

Figura 31 – Protótipo – Atribuição de Permissões

 69

Figura 32 – Protótipo – Definição da Metodologia e Documentos de Apoio

Ainda na tela de projetos (Figura 29, pg.67), o gerente terá a

possibilidade de criar a sua matriz de impacto através do botão de mesmo nome.

Conforme já explicado, será através do cruzamento das informações da matriz de

impacto (Figura 33, pg.70) com a probabilidade que será gerada a informação de

criticidade.

As informações referentes ao orçamento do projeto são definidas a

partir da tela de projetos, no botão “Orçamento”. O gerente terá o espaço para

informar qual é o orçamento previsto para a gerência de riscos, a previsão real de

gastos (sem margens) e o valor que realmente foi gasto até o momento (veja Figura

34, pg.70).
 70

Finalizando a tela de projetos, o gerente poderá definir funções e

responsabilidades em nível de projeto, como pode ser visto na Figura 35, pg.71.

Figura 33 – Protótipo – Definição da Matriz de Impacto

Figura 34 – Protótipo – Especificação do Orçamento da Gerência de Riscos

 71

Figura 35 – Protótipo – Definição de Responsabilidades no Projeto

Ao fechar a tela de projetos, o protótipo volta para a tela inicial,

exibindo o projeto que foi selecionado e a lista de riscos registrados para aquele

projeto (Figura 28, pg.66). O usuário do sistema (de acordo com seu perfil de

acesso) poderá acrescentar, editar ou remover um ou mais riscos do projeto.

Para entender melhor como funciona o protótipo, vamos pegar o

primeiro item da lista de riscos como exemplo (Figura 36, pg.74). Todas as

informações relacionadas ao risco estão disponíveis na mesma tela e por se tratar

de uma tela de suma importância para o correto funcionamento do protótipo, vamos

explicar cada campo. A tela está dividida em duas áreas. A primeira, denominada

de “Informações” contém a identificação do risco em si e a segunda, denominada de

“Responsabilidades” está relacionada a todas as tarefas/ações que foram planejadas

e/ou executadas para o risco em questão. A seguir, a descrição dos campos das

duas áreas.
 72

• Descrição: É identificação do Risco. Uma situação que pode vir a

prejudicar o projeto.

• Área Afetada: São as áreas da empresa e/ou do projeto que serão

afetadas caso o risco ocorra.

• Sintoma: Este espaço é destinado aos eventos típicos que

ocorrem antes do risco em questão se tornar realidade, auxiliando

desta forma a prever a ocorrência do mesmo.

• Efeito / Impacto: Para registrar os possíveis efeitos do risco no

projeto e os principais impactos do mesmo caso o risco ocorra.

• Probabilidade: A probabilidade é uma informação que depende

muito da sensibilidade dos membros do projeto e do conhecimento

histórico nas atividades envolvidas ao risco. Seus valores variam

entre Muito Baixo, Baixo, Moderado, Alto e Muito Alto. Estes

valores conceituais estão atrelados a uma tabela com valores

numéricos (0.1, 0.3, 0.5, 0.7 e 0.9) que será utilizada para cruzar as

informações com os valores selecionados da matriz de impacto.

• Objetivo no Projeto / Impacto no Objetivo: Define qual é o

objetivo do projeto e o tamanho do impacto que é causado caso o

risco ocorra. Os valores que estão disponíveis para escolha são os

valores atribuídos na matriz de impacto. A matriz de impacto possui

valores conceituais, que variam de “Muito Baixo” até “Muito Alto”.

 73

Contudo, cada valor conceitual possui um valor numérico atrelado

de acordo com a coluna que ele está associado (0.05, 0.1, 0.2, 0.4

e 0.8). Dessa forma, é possível fazer o cálculo, cruzando os valores

de probabilidade com os valores de impacto do risco. O sistema,

através de um modelo proposto pelo PMBOK, atribui um conceito

de criticidade ao risco que pode ser “Baixo”, “Moderado” e “Alto”.

• Responsável: É a pessoa (membro do projeto) que será

responsável por uma ação relacionada ao risco.

• Prazo de Conclusão: Serve para atribuir uma data limite para a

execução da ação que foi atribuída ao membro do projeto.

• Ação: É a descrição da tarefa que foi designada ao membro do

projeto.

• Tipo de Ação: Segundo o PMBOK, uma ação pode ser do tipo

“Mitigação”, isto é, uma ação que é executada com o intuito de

minimizar os impactos do risco nos objetivos do projeto ou pode ser

de “Contingência”, isto é, uma espécie de plano B, se o risco vier a

ocorrer essa ação será tomada para remediar o problema.

• Status: Este campo é para dar o devido acompanhamento e

monitoração as ações relacionadas ao risco. A ação pode estar

engatilhada, atrasada, agendada ou já estar executada.

 74

• Histórico: O botão de histórico não permite qualquer tipo de

edição. Serve tão somente para ter visibilidade de todas as

mudanças que ocorreram com o risco. Seu papel é registrar os

valores anteriores a mudança e os novos valores para cada campo

da tela de Riscos, informando quem fez a alteração e a data de

modificação (Figura 37, pg.75).

Figura 36 – Protótipo – Administração de um Risco

 75

Figura 37 – Protótipo – Histórico de Mudanças de um Risco

5.3 RESULTADOS OBTIDOS

Tendo em vista a metodologia de gerenciamento de riscos adotada

(PMBOK) e que o que a proposta de desenvolvimento seria um protótipo e não um

sistema de gerenciamento de riscos efetivamente, o protótipo contribuiu bastante

para demonstrar as funcionalidades e as vantagens que uma ferramenta efetiva de

gerenciamento de riscos pode trazer tanto para o projeto quanto para o gerente de

projetos.

Por se tratar de um protótipo e não de uma ferramenta, não foi possível

testar o seu uso de forma real dentro de um projeto em alguma empresa. Apesar dos

dados relacionados nas telas do protótipo não configurarem um ambiente de

produção real, eles espelham informações pertinentes a projetos reais de infra-

 76

estrutura de TI, permitindo dessa forma uma visão clara da aplicação do protótipo

para este fim.

Mesmo assim, o protótipo foi demonstrado para algumas pessoas da

empresa Dell Computadores com o intuito de ter uma opinião sobre uma futura

utilização de uma ferramenta que siga os moldes do protótipo.

As opiniões foram unânimes em apontar que existe uma deficiência de

ferramentas que apóiem a metodologia do PMBOK para gerenciamento de riscos.

O protótipo, de maneira geral, foi bem recebido. Varias sugestões de

melhorias foram relatadas, as quais poderiam configurar melhorias e extensões no

trabalho desenvolvido, como por exemplo: o calculo automático do custo do risco

para o projeto, a definição de uma área exclusiva para riscos de negócio, a

substituição de alguns campos descritivos por valores previamente cadastrados que

facilitariam o trabalho de levantamento de métricas.

Segue abaixo o relato do Sr. Alexandre Lima, coordenador de Infra-

Estrutura de TI na unidade do GDC (Global Development Center) da Dell

Computadores. E-mail para contato: alexandre_lima@dell.com

“Uma de minhas funções na Dell, seja suportando a infra-

estrutura do Centro de Desenvolvimento de Software da Dell (GDC) ou
a fábrica no Brasil e escritórios no Chile e na Argentina, é o
gerenciamento de projetos de infra-estrutura, ou seja, abrangendo as
áreas de telecomunicações, cabeamento, redes, servidores, sistemas
de segurança e estrutura física predial. Este conjunto tão grande de
áreas gera uma quantidade muito grande de variáveis a serem
 77

analisadas e consideradas quando estou na fase de planejamento de

um projeto. O sucesso do projeto estará sempre diretamente ligado ao
máximo de alternativas, contingências e projeções feitas em cima de
todas as ações que antecedem a fase de implementação de um
projeto. Assim sendo, um dos pontos principais e mais críticos no
planejamento de meus projetos é a análise de riscos.

Analisando o protótipo da farramenta, pude perceber

alguns aspectos bastante relevantes para meu trabalho. Dentre estes
aspectos, gostaria de salientar dois que no meu ponto de vista são de
grande importância:

1) O Centro de Desenvolvimento de Software da Dell é

uma organização CMM Nível 2 e a metodologia PMBOK de
Gerenciamento de Riscos, nítidamente servindo de base ao protótipo,
vêm de encontro a todos os padrões de trabalho já definidos pela
organização.

2) A ferramenta auxilia na identificação de criticidade dos

riscos.

E é neste aspecto que visualizo a principal aplicação

desta ferramenta no meu trabalho e como a mesma poderia ser útil no
planejamento de meus projetos. Isto porquê, diferentemente de um
projeto de software desenvolvido internamente, um projeto de infra-
estrutura está norteado por diversas variáveis, muitas vezes externas à
organização, como fornecedores e prazos de entrega, desacordos
comerciais, condições climáticas para execução de trabalhos externos,
oscilações de preço e câmbio entre outros.

Assim, com uma ferramenta nos moldes propostos, eu

teria melhor visibilidade dos riscos do meu projeto e o quanto cada um
pode impactar nos meus objetivos finais”.
 78

6 CONCLUSÃO

As estatísticas nos mostram que o grande culpado pelos maus

resultados de um determinado trabalho, ao contrário do que normalmente se

imagina, não é a tecnologia envolvida na criação do produto, mas sim na forma com

que este produto foi projetado, constatando-se assim que o fator determinante para

o sucesso do projeto é a utilização de uma metodologia para gerenciamento de

projetos.

Baseando-se em todos os conceitos de risco, de gerenciamento de

risco e de ferramentas de gerenciamento de risco que foram aqui estudados,

analisados e comentados, o PMBOK foi escolhido como a metodologia de

gerenciamento de riscos mais completa, tendo ainda o mérito de não ter um público

alvo, servindo a qualquer atividade que se caracterize como um projeto.

Os riscos envolvidos nos projetos sempre são um fator de grande

preocupação e de difícil análise. Os benefícios da prática do gerenciamento de

riscos ficaram bem claros, pois além da possibilidade de evitar o risco através da

identificação e da criação de um plano de resposta a todos os riscos que podem vir a

prejudicar os objetivos do projeto, existe ainda a possibilidade de se identificar riscos

 79

de negócio, ou seja, que se forem bem tratados, podem trazer benefícios para a

organização.

O objetivo do protótipo era o de instrumentalizar através de uma

ferramenta de apoio os principais processos de gerenciamento de riscos propostos

pelo PMBOK. Apesar de conceitualmente poder ser aplicado a qualquer área de

projetos, o protótipo foi exemplificado com projetos específicos da área de infra-

estrutura de TI, visando apresentar um modelo de gerência de riscos aplicado a esta

área.

Algumas automatizações e melhorias devem ser conduzidas para a

implementação do protótipo, porém o mesmo pode servir de base para validação do

processo de gerência de riscos em qualquer área de aplicação.

Deixo ainda a sugestão, para os colegas que por ventura queiram no

futuro propor extensões deste trabalho ou que venham a atuar com trabalhos

correlatos que uma boa oportunidade seria a implementação de algum mecanismo

de integração com o Microsoft Project ou outras ferramentas de Gerenciamento de

Projetos, integrando a base de dados de projetos e possibilitando o uso efetivo desta

ferramenta proposta como uma ferramenta complementar no gerenciamento de

projetos.
 REFERÊNCIAS E OBRAS CONSULTADAS

[ABN97] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC

12207/1997: Processos de Ciclo de Vida de Software. Rio de Janeiro: ABNT, 1997.

[CES03] - CESAR, Genilson. Engenharia do software em evolução. e-Manager, [s.l.],

p. 12-3, Maio 2003.

[DIN03] - DINSMORE, Paul C. Project Management in Action: Education Foundation

Practices What It Preaches. PMI Today, News and Views of the Project Management

Institute. Newtown Square, p. 2, Agosto 2003.

[FIO98] - FIORINI Soeli et al. Engenharia de Software com CMM. São Paulo:

Brasport, 1998.

[ISO97] - Tecnologia de Informação – Processos de Ciclo de vida de software.

Disponível em: http://www.abntdigital.com.br/

[MAC01] – MACHADO, Cristina A. F.; BURNETT, Robert C. Gerência de Projetos na

Engenharia de Software em Relação às Práticas do PMBOK. [s.l.]: [s.ed.], 2001.

[PAU93] – PAULK, Mark C. et al. Key Practices of the Capability Maturity Model.

Pittsburgh: SEI, 1993. Disponível em:

http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.025.html

[PER99] – PEREIRA, Lauro Zanforlin Alves. I Encontro Mineiro de Gerenciamento de

Projetos. [s.l.]: PMI-MG, 1999. Disponível em:
http://ww.pmimg.org.br/ppt/RiscoSitePMIMG.ppt

[PMI00] - PROJECT MANAGEMENT INSTITUTE. A Guide to the Project

Management Body of Knowledge: PMBOD Guide 2000 Edition. Newtown Square:

Project Management Institute Inc., 2000.

[PMI02] - PMI-MG. Tradução livre do PMBOK 2000. Belo Horizonte: PMIMG, 2002.

[PMISD] - PMI-RS. Metodologias e Práticas de Gerenciamento de Projetos.

Apresentação em sala de aula disponibilizada através de arquivo PDF.

[PRA99] - PRADO, Darci. Gerência de Projetos em Tecnologia da Informação. [s.l.]:

DG, 1999.

[PROSD] - PROCERGS. Qualidade de software: Visão Geral. Apresentação em sala

de aula disponibilizada através de arquivo de MS Power Point.

[QUA02] - QUADROS, Moacir. Gerência de Projetos de Software. [s.l.]: Visual

Books, 2002.

[SALSD] - SALVIANO, Clenio F. Contribuições da Melhoria de Processo e Gerência

de Projetos: Transformando Boas Idéias em Resultados. [s.l.]: [s.ed.], [s.d.].

Disponível em:

http://www.bfpug.com.br/islig-rio/Downloads/Contribuicoes_da_Melhoria_de_Processos.pdf
[SIL03] - SILVERSTEIN, Ken. Closing the Circuit. PM Network, Newtown Square, p.

40-4, Agosto 2003.

[SOTSD] - SOTILLE, Mauro. Um novo paradigma em Gerenciamento de Projetos.

PMI-RS. Apresentação em sala de aula disponibilizada através de arquivo de MS

Power Point.

[WPB99] – WILLIAMS, Ray C.; PANDELIOS, George J.; BEHRENS, Sandra G.

Software Risk Evaluation (SRE) Method Description (Version 2.0). Pittsburgh: SEI,

1999.
 GLOSSÁRIO

Brainstorming – É uma técnica muito utilizada para a identificação de riscos que

tem como objetivo obter uma lista de riscos compreensível, que pode ser

endereçada mais tarde nos processos de análise qualitativa e quantitativa.

Delphi – Esta técnica é uma maneira de encontrar um consenso entre os

especialistas em um determinado assunto que participam anonimamente. Um

facilitador usa um questionário para solicitar idéias sobre riscos importantes do

projeto. As respostas são apresentadas e então circuladas entre os especialistas,

para comentários adicionais. Benefícios desta técnica são de possibilitar a redução

dos desvios nos dados e elimina o poder de influência das pessoas no grupo, visto

que os especialistas participam de forma anônima.

EAP – Estrutura Analítica do Projeto é um agrupamento de componentes de projeto

que organiza e define o escopo total do projeto. É um dos resultados de saída de um

processo da gerência de escopo, de acordo com a definição da metodologia do

PMBOK.

KPA – Key Process Areas. É uma definição dos processos mais importantes que

devem ser executados em cada um dos níveis de maturidade do CMM.

Monte Carlo – É uma técnica de análise que executa várias vezes uma simulação

do projeto com o intuito de calcular e apontar os valores mais prováveis de ocorrer.

MSP – Mitigation Strategy Plan. É o processo que defini o plano para a estratégia de

mitigação dos riscos das metodologias do SRE e SW-CMM.

Planos de workaround – Workaround significa contorno. É a documentação das

respostas aos riscos que anteriormente foram aceitos ou que não foram

identificados.

PMBOK – Project Management Body of Knowledge. É o método de gerenciamento

de projetos desenvolvido pelo PMI e que se baseia em nove áreas de

gerenciamento.

PMI – Project Management Institute. Instituição que desenvolveu o PMBOK.

Project Charter – É um documento que autoriza formalmente o projeto. É um dos

resultados de saída de um processo da gerência de escopo, de acordo com a

definição da metodologia do PMBOK.

RI&A – Risk Identification & Analysis. É o processo de identificação e análise do

Risco que faz parte das metodologias do SRE e SW-CMM.

SEI – Software Engineer Institute. Instituto que desenvolveu a metodologia SW-

CMM.
SRE – Software Risk Evaluation. É uma metodologia utilizada pelo SW-CMM que

visa a identificação, análise, planejamento e comunicação com o objetivo de criar

uma visão dos riscos que podem afetar o projeto.

Stakeholders – É um termo inglês que se refere a todos as pessoas que estão

interessadas ou envolvidas no projeto.

SW-CMM – Capability Maturity Model. Metodologia para gerenciamento de projetos

voltada para os desenvolvedores de software. Foi desenvolvido pelo SEI.

SWOT – É uma técnica de análise de riscos. A sigla vem da abreviação de um termo

em inglês (strengths, weaknesses, opportunities and threats) e significa que é uma

análise de forças, fraquezas, oportunidades e ameaças.