Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ARISCO - FERRAMENTA PARA APOIO AO GERENCIAMENTO DE
RISCOS DE PROJETOS CONFORME O PMBOK
Área de Gerência de Projetos
por
Mateus Müller Figueiredo
Adriana Gomes Alves, M. Eng.
Orientadora
Itajaí (SC), dezembro de 2009
UNIVERSIDADE DO VALE DO ITAJAI
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ARISCO - FERRAMENTA PARA APOIO AO GERENCIAMENTO DE
RISCOS DE PROJETOS CONFORME O PMBOK
Área de Gerência de Projetos
por
Mateus Müller Figueiredo
Relatório apresentado à Banca Examinadora do
Trabalho de Conclusão de Curso de Ciência da
Computação para análise e aprovação.
Orientadora: Adriana Gomes Alves, M. Eng.
Itajaí (SC), dezembro de 2009
ii
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................. iv
LISTA DE FIGURAS.................................................................................v
LISTA DE TABELAS...............................................................................vi LISTA DE QUADROS.............................................................................vii RESUMO..................................................................................................viii ABSTRACT................................................................................................ ix
1 INTRODUÇÃO......................................................................................1 1.1 PROBLEMATIZAÇÃO ..................................................................................... 2 1.1.1 Formulação do Problema................................................................................. 3 1.1.2 Solução Proposta ............................................................................................... 3 1.2 OBJETIVOS ........................................................................................................ 3 1.2.1 Objetivo Geral ................................................................................................... 3 1.2.2 Objetivos Específicos ........................................................................................ 3 1.3 METODOLOGIA................................................................................................ 4 1.4 ESTRUTURA DO TRABALHO ....................................................................... 5
2 FUNDAMENTAÇÃO TEÓRICA ........................................................7 2.1 BENEFÍCIOS DO GERENCIAMENTO DE RISCOS ................................... 9 2.2 PROCESSO DE GERENCIAMENTO DE RISCOS..................................... 10 2.2.1 Planejamento do Gerenciamento de Riscos ................................................. 11 2.2.2 Identificação dos riscos................................................................................... 12 2.2.3 Análise de riscos .............................................................................................. 16 2.2.4 Planejamento de respostas a riscos ............................................................... 23 2.2.5 Monitoramento e controle de riscos .............................................................. 25 2.3 ANÁLISES DE FERRAMENTAS SIMILARES........................................... 25
3 PROJETO.............................................................................................29 3.1 REQUISITOS DA FERRAMENTA................................................................ 29 3.1.1 Requisitos Funcionais ..................................................................................... 29 3.1.2 Requisitos Não-Funcionais............................................................................. 30 3.1.3 Regras de Negócio ........................................................................................... 31 3.2 DIAGRAMA DE CASOS DE USO ................................................................. 31 3.3 DIAGRAMA DE CLASSES............................................................................. 35 3.4 DIAGRAMA DE ATIVIDADES...................................................................... 36
4 IMPLEMENTAÇÃO...........................................................................38 4.1 BANCO DE DADOS ......................................................................................... 38 4.2 FRAMEWORK SYMFONY ............................................................................ 41 4.3 DRAW2D............................................................................................................ 42
iii
5 APRESENTAÇÃO DA FERRAMENTA..........................................43 5.1 LAYOUT ............................................................................................................ 43 5.2 A FERRAMENTA............................................................................................. 43 5.3 PRINCIPAIS DIFICULDADES ENCONTRADAS ...................................... 64
6 TESTES E VALIDAÇÃO ...................................................................66
7 CONCLUSÃO ......................................................................................68 7.1 TRABALHOS FUTUROS................................................................................ 69
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................70
A DESCRIÇÃO DOS CASOS DE USO ................................................72
iv
LISTA DE ABREVIATURAS
ASC American System Corporation BMP Best Manufacturing Practices CSS Cascading Style Sheets EAP Estrutura Analítica do Projeto EAR Estrutura Analítica de Riscos GNU GPL Great Nation Universalizing General Public License GTZ Deutsche Gesellschaft für Technische Zusammenarbeit GmbH ICE Integrated Computer Engineering MVC Model-view-controller PHP Hypertext Preprocessor PMBOK Project Management Body of Knowledge PMI Project Management Institute SWOT Strengths, Weaknesses, Opportunities and Threats TCC Trabalho de Conclusão de Curso UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí VME Valor Monetário Esperado WEB World Wide Web
v
LISTA DE FIGURAS
Figura 1- Fluxograma de processo do gerenciamento de riscos do projeto .......................................11 Figura 2 - Estrutura analítica dos riscos (EAR). ................................................................................15 Figura 3 - Análise qualitativa de riscos: Entradas, ferramentas e técnicas, e saídas..........................17 Figura 4 - Diagrama de pacotes..........................................................................................................32 Figura 5 - PCT01 – Entradas..............................................................................................................33 Figura 6 - PCT02 - Identificação de riscos usando Delphi ................................................................34 Figura 7 - PCT03 – Controle..............................................................................................................34 Figura 8 - PCT05 – Cadastros Gerais.................................................................................................35 Figura 9 - Diagrama de Classes..........................................................................................................36 Figura 10 - Diagrama de Atividades ..................................................................................................37 Figura 11 - Interface principal do DBDesigner 4...............................................................................39 Figura 12 - Diagrama de Entidade Relacionamento ..........................................................................40 Figura 13 - Layout padrão do sistema................................................................................................43 Figura 14 - Tela de login ....................................................................................................................44 Figura 15 - Manter Empresa...............................................................................................................45 Figura 16 - Manter Funcionário .........................................................................................................46 Figura 17 - Manter Projeto .................................................................................................................47 Figura 18 - Escolha de projeto a ser Gerenciado ..............................................................................48 Figura 19 - Manter Plano de Gerenciamento de Riscos.....................................................................49 Figura 20 - Manter Matriz de Impacto ...............................................................................................50 Figura 21 - Manter EAR - Estrutura Analítica de Riscos modo Lista ...............................................51 Figura 22 - Manter EAR - Estrutura Analítica de Riscos modo gráfico ............................................52 Figura 23 - Manter Riscos.................................................................................................................53 Figura 24 - Controle técnica Delphi ...................................................................................................55 Figura 25 - Identificação Fase 1 .........................................................................................................56 Figura 26 - Identificação Fase 2 .........................................................................................................57 Figura 27 - Identificação Filtragem....................................................................................................58 Figura 28 - Gerar Análise dos riscos ..................................................................................................60 Figura 29 - Plano de respostas - lista de riscos ..................................................................................61 Figura 30 - Plano de respostas - inclusão de respostas ......................................................................62 Figura 31 - Ocorrência de riscos - lista de riscos ...............................................................................63 Figura 32 - Ocorrência de riscos - informar ocorrência .....................................................................63 Figura 33 – Relatório Gerencial .........................................................................................................64
vi
LISTA DE TABELAS
Tabela 1. Exemplo de Matriz de Probabilidade e Impacto ................................................................19 Tabela 2. Cenário UC001 – Criar Plano de Gerenciamento de Riscos..............................................72 Tabela 3. Cenário UC002 - Criar EAR ..............................................................................................73 Tabela 4. Cenário UC003 - Manter lista de Riscos............................................................................74 Tabela 5. Cenário UC004 - Criar Matriz de impacto dos riscos ........................................................75 Tabela 6. Cenário UC005 - Gerar análise ..........................................................................................76 Tabela 7. Cenário UC006 - Identificação dos riscos..........................................................................77 Tabela 8. Cenário UC007 - Cenário Revisar lista de riscos...............................................................78 Tabela 9. Cenário UC008 - Informar ocorrência do risco..................................................................79 Tabela 10. Cenário UC009 - Criar respostas aos riscos.....................................................................79 Tabela 11. Cenário UC010 - Filtrar lista de riscos.............................................................................80 Tabela 12. Cenário UC011 - Manter Empresa...................................................................................82 Tabela 13. Cenário UC012 - Manter Funcionário..............................................................................83 Tabela 14. Cenário UC013 - Manter Projeto .....................................................................................83
vii
LISTA DE QUADROS Quadro 1 - Análise Swot ....................................................................................................................14 Quadro 2 - Matriz de Classificação de Impactos dos Riscos .............................................................18 Quadro 3 - Funcionalidades dos softwares avaliados e da ferramenta proposta................................27 Quadro 4 - Características gerais dos softwares avaliados e da ferramenta proposta........................28
viii
RESUMO
FIGUEIREDO, Mateus Müller. Arisco - Ferramenta para apoio ao gerenciamento de riscos de projetos conforme o PMBOK. Itajaí, 2009. 90p. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2009. Este trabalho de Conclusão de Curso teve como objetivo desenvolver uma ferramenta computacional que apóie o gerenciamento de riscos em projetos, conforme o Guia PMBOK - 3ª Edição (Project Management Body of Knowledge). No trabalho foi destacada a grande importância de se utilizar uma metodologia para se gerenciar projetos. Dentre as nove áreas do gerenciamento de projetos, é dado ênfase para a área de gerenciamento de riscos, enfatizando cada processo necessário para se ter um gerenciamento correto e eficaz. Entre esses processos destacam-se o planejamento do gerenciamento de riscos, a identificação de riscos, a criação da estrutura analítica de riscos (EAR), a análise qualitativa e quantitativa de riscos, o plano de respostas aos riscos e o controle e monitoramento de riscos. O gerenciamento de riscos é uma das áreas mais delicadas no gerenciamento de projetos, e atualmente, as ferramentas que existem no mercado com o propósito de auxiliar esse gerenciamento não atingem as expectativas esperadas, sendo essa a motivação para a realização deste trabalho. A ferramenta Arisco é voltada a WEB, onde foi construída utilizando a linguagem de programação PHP e a ferramenta Draw2D para gerar a EAR e banco de dados MySQL. Palavras-chave: PMBOK. Gerenciamento de Projetos. Risco.
ix
ABSTRACT
This work of Conclusion of Course has as objective to develop a computational tool that assists the Risk Management in projects, as Guide PMBOK - 3rd Edition (Project Management Body of Knowledge). In the work it was detached the great importance to use a methodology to manage projects. Inside the nine areas of the project management, is given emphasis for the area of risk management, emphasizing to have a correct and efficient management. Between these processes are distinguished the planning of the risk management, the identification of risks, the creation of the analytical structure of risks (ASR), the qualitative and quantitative analysis of risks, the plan of answers to the risks and the control and monitor of risks. The management of risks is one of the areas most delicate in the project management, and currently, the tools that exists in the market with the intention of assisting this management do not reach the waited expectations, being this a great reason to the accomplishment of this work. The modeling of the system also is included in this work, emphasizing the use cases diagrams, activities diagrams, classrooms diagrams and the prototype of the main screens of the system. With intention to develop the tool for the WEB, the tool will be constructed with the PHP programming language, using the Draw2D tool to generate the ASR and MySQL data base.
Key-words: PMBOK. Project Management. Risk.
1 INTRODUÇÃO
Segundo o PMI (2004), um projeto é um empreendimento único, com início e fim
determinados, utilizando recursos de diversas origens, podendo envolver uma única pessoa a
milhares e ter a duração de alguns dias ou vários anos, visando atingir seus objetivos predefinidos.
Sendo assim, um projeto se caracteriza por ser temporário, exclusivo e progressivo. Por progressivo
entende-se que, quanto mais compreendido, maior será seu detalhamento.
Segundo Vargas (2005, p. 3), vive-se em um ambiente caracterizado pela velocidade das
mudanças, tornando-se indispensável um modelo de gerenciamento baseado no foco em prioridades
e objetivos. Deste fator vem a explicação do crescimento acentuado do gerenciamento de projetos
nos últimos anos. Peters (apud VARGAS, 2005, p. 3) afirma que “Você é o seu projeto” que, muito
breve, todo o trabalho dos executivos no planeta será desenvolvido por meio de projetos. Cleland
(apud VARGAS, 2005, p. 3) também afirma que no futuro, os projetos serão utilizados em todas as
mudanças de infraestruturas sociais em todo o mundo, sejam países desenvolvidos ou não.
Vargas (2005, p. 4), também menciona que várias pessoas mal informadas podem ver o
gerenciamento de projetos como uma “moda” gerencial, mas na realidade o gerenciamento de
projetos não propõe nada revolucionário ou novo, sua proposta é estabelecer um processo
estruturado e lógico para lidar com eventos que se caracterizam pela novidade, complexidade e
dinâmica ambiental.
Para um bom e eficaz gerenciamento de um projeto é necessário um conjunto de ferramentas
gerenciais que permitem que a empresa desenvolva dentro de um cenário de tempo, custo e
qualidade predeterminado, um conjunto de habilidades, incluindo conhecimento e capacidades
individuais, destinado ao controle de eventos não repetitivos, únicos e complexos (VARGAS,
2005).
Um exemplo de ferramenta que auxilia o gerenciamento de projetos é a ferramenta criada
pelo acadêmico da UNIVALI, Cristiano Born, do curso de Ciência da Computação, com tema
Gerenciamento de Escopo em Projetos conforme o PMBOK (BORN, 2009). A utilização de uma
ferramenta como esta pode diminuir bruscamente os riscos de projetos. Mas não basta apenas
gerenciar o escopo, todas as áreas impactam na execução dos projetos. Todas as áreas deveriam ser
gerenciadas através de ferramentas computacionais que suprissem as necessidades para o bom
gerenciamento (DISMORE, 2007).
2
Segundo Vargas (2005), em grande parte dos projetos, os riscos associados com grandes
empreendimentos tem merecido uma atenção especial no seu gerenciamento, devido não só às
grandes somas em dinheiro que estão nas mãos do gerente de projetos, mas também pela reputação
do time e dos seus patrocinadores.
O risco não é necessariamente um problema, mas sim a possibilidade de algo que poderá
ocorrer no futuro, gerenciar os riscos possibilita o melhor entendimento da natureza do projeto, de
modo a identificar e responder às potenciais forças e riscos do projeto, geralmente associados a
tempo, qualidade e custos. Por esse motivo, a sobrevivência de qualquer empreendimento está
intimamente vinculada ao conceito de aproveitar uma oportunidade, dentro de um espectro de
incertezas. Fatores diversos como o aumento da competitividade, o avanço tecnológico e as
condições econômicas, fazem com que os riscos assumam proporções muitas vezes incontroláveis,
justificando a grande importância do gerenciamento de riscos em projetos.
1.1 PROBLEMATIZAÇÃO
Os projetos estão ficando cada dia maiores e de complexidade muito mais elevada. Isso está
fazendo com que as organizações adotem cada vez mais a utilização do gerenciamento de projetos,
aumentando assim, a necessidade da utilização de ferramentas computacionais para apoiar no
gerenciamento (HELDMAN, 2005).
Mesmo com a grande quantidade de benefícios gerados pelos projetos, boa parte deles
falham, ou não atingem os resultados esperados. Muitas destas falhas ocorrem por obstáculos
naturais ou externos que não são controláveis pelas organizações, porém, muitas vezes eles podem
ser minimizados ou evitados através de um gerenciamento de riscos eficiente (VARGAS, 2005).
Segundo o PMI (2004), o risco do projeto é algo incerto, mas que se ocorrer pode ter um
efeito positivo ou negativo sobre pelo menos um objetivo do projeto. A ocorrência de um risco não
pré-identificado pode afetar bruscamente os objetivos do projeto, pois as respostas ao risco não
estarão disponíveis de antemão aos integrantes da equipe de gerenciamento do projeto.
Cabe ao gerente de projetos e sua equipe controlar as possibilidades de insucessos que
podem ocorrer no decorrer do projeto. Vargas (2005) afirma que não se pode criar a ilusão de que o
projeto é algo não controlável, citando a frustrante definição de projetos proposta por Kerzner de
que “gerenciamento de projetos é a arte de criar ilusões de que todos os resultados obtidos pelo
3
projeto foram previamente previstos e planejados quando, na realidade, não passaram de uma
seqüência absurda de pura sorte.”
1.1.1 Formulação do Problema
Diante desses fatos, fica clara a importância do gerenciamento de projetos nas organizações,
e de um modo especial o gerenciamento de riscos em projetos. Os processos de Iniciação,
Planejamento, Execução, Monitoramento/ Controle e Encerramento dos riscos são cruciais e
críticos para o sucesso do projeto como um todo. Sendo um dos fatores que influenciaram na
idealização deste Trabalho de Conclusão de Curso, sendo de grande valia na execução de projetos a
utilização de uma ferramenta computacional que auxilie o gerenciamento de riscos de projetos.
Outro fator que também influenciou a idealização deste trabalho foi o TCC do acadêmico da
UNIVALI, Cristiano Born, que elaborou seu TCC com foco no gerenciamento de escopo em
projetos conforme o PMBOK. Estudando a ferramenta proposta por Born (2009), idealizou-se a
criação de uma ferramenta para o gerenciamento das outras áreas de projetos. Como já citado
acima, o presente trabalho tratará exclusivamente da área de gerenciamento de riscos, seguindo a
metodologia PMBOK.
1.1.2 Solução Proposta
Diante da importância do gerenciamento de riscos em projetos, este Trabalho de Conclusão
de Curso apresenta o estudo das recomendações do Guia PMBOK terceira edição, enfatizando a
área de gerenciamento de riscos em projetos. Foi realizado um estudo de ferramentas similares já
existentes com vistas a se criar uma ferramenta computacional que proporcione ao gerente de
projetos e aos demais interessados, o apoio no gerenciamento de riscos de projetos.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste projeto de conclusão do curso é o desenvolvimento de uma
ferramenta computacional que apóie o gerenciamento de riscos em projetos, conforme
recomendações do Guia PMBOK terceira edição.
1.2.2 Objetivos Específicos
4
Os objetivos específicos deste projeto de conclusão de curso são:
• Compreender o processo de gerenciamento de projetos conforme as recomendações do
Guia PMBOK terceira edição, com ênfase na área de Gerenciamento de Riscos;
• Pesquisar e analisar soluções de software similares;
• Determinar os requisitos exigidos pelo sistema;
• Pesquisar os conceitos e tecnologias necessários à implementação do sistema;
• Realizar a modelagem conceitual do sistema;
• Implementar o sistema;
• Testar e validar a implementação do sistema;
• Documentar o desenvolvimento e os resultados do sistema.
1.3 Metodologia
A metodologia deste trabalho foi dividida em duas etapas principais. Na primeira foi
levantado todo o conhecimento teórico necessário para a elaboração da ferramenta proposta,
conhecimentos que são debatidos no Capítulo 2 deste documento. Para que o conhecimento teórico
pudesse ser adquirido, foi efetuada uma pesquisa detalhada em livros, artigos, e documentos
publicados na internet a fim de entender melhor o processo e assim, poder propor a solução mais
eficaz e adequada para o problema.
Ainda nesta etapa, foi desenvolvido o projeto da ferramenta proposta, que é detalhado no
Capítulo 3, descrevendo seus requisitos funcionais, requisitos não funcionais e regras de negócio.
Também foi elaborado o Diagrama de Casos de Uso, bem como a descrição do cenário de cada caso
de uso o protótipo das principais telas do sistema, para assim, ter uma maior noção de como é o
funcionamento da ferramenta. Outro diagrama fundamental para o melhor entendimento da
ferramenta é o Diagrama de Classes, onde se pode ter uma visão mais clara de todas as classes
criadas no processo de desenvolvimento da ferramenta. Para ter o entendimento de como se dá o
processo de gerenciamento de riscos, foi criado um Diagrama de Atividades, detalhando as
atividades desenvolvidas no gerenciamento desde a criação de seu plano de gerenciamento até a
criação do plano de respostas aos riscos, ficando sem citar apenas o processo de monitoramento de
5
controle de riscos, processo esse que pode ser desempenhado durante todo o processo de
gerenciamento.
Para a elaboração dos diagramas de UML - Unified Modeling Language foi utilizada a
ferramenta Enterprise Architect 7.1.
Na segunda etapa, foi desenvolvido o projeto da ferramenta computacional criada conforme
citado acima na primeira fase deste trabalho. Sendo utilizado o componente gráfico Draw2D
(HERZ, 2008), que possibilita através de uma biblioteca de Javascript, a criação de gráficos,
suprindo a necessidade de criação da EAR.
Após o desenvolvimento da ferramenta, foram realizadas baterias de testes no sistema, onde
foi simulado o gerenciamento de riscos do projeto em questão, como pode ser visto no capítulo de
apresentação da ferramenta, buscando eventuais problemas e visando avaliar as funcionalidades
desenvolvidas durante o levantamento de requisitos do projeto, sendo devidamente documentados.
Outra etapa foi a documentação do projeto, onde consta como ocorreu a implementação da
ferramenta.
1.4 Estrutura do trabalho
O trabalho esta dividido em sete capítulos, sendo: Introdução, Fundamentação Teórica,
Projeto, Implementação, Apresentação da ferramenta, Testes e Validações e Considerações Finais.
No primeiro capítulo deste trabalho aborda-se uma breve introdução sobre o tema em
questão, descrevendo o problema e a proposta de solução do mesmo. Contendo também, o objetivo
geral e os objetivos específicos que deve ser alcançados até a finalização deste trabalho.
O segundo capítulo apresenta uma revisão bibliográfica sobre o tema discutido, começando
com o gerenciamento de projetos em um modo geral e aos poucos enfatizando seu foco que é o
gerenciamento de riscos em projetos. Neste capítulo também serão apresentadas breves avaliações
de ferramentas já existentes no mercado que visam à mesma finalidade da ferramenta proposta.
No terceiro capítulo é apresentado o projeto do sistema, seus requisitos, modelagem de casos
de uso, classes e banco de dados e respectivas especificações.
No quarto capítulo é apresentado o desenvolvimento da ferramenta, o banco de dados
escolhido, os aplicativos e componentes utilizados para desenvolver as interfaces.
6
O quinto capítulo apresenta a ferramenta ARISCO, suas telas, funcionalidades e aspectos
principais.
No último capítulo são apresentadas as considerações finais sobre o trabalho desenvolvido,
as lições aprendidas durante esse processo, as dificuldades encontradas durante o projeto e
sugestões para trabalhos futuros que possam aprimorar o funcionamento da ferramenta
desenvolvida.
2 FUNDAMENTAÇÃO TEÓRICA
Num mercado cada vez mais globalizado e competitivo onde as organizações estão em
permanente mudança, as empresas têm buscado intensamente o uso de melhores práticas de
gerenciamento de projetos. Pensando nisso, no ano de 1996, o PMI (Project Management Institute)
lançou a primeira versão do Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos
(Guia PMBOK® - Project Management Body of Knowledge), o qual está em sua quarta edição,
lançado no ano de 2008. Nele encontram-se explicações detalhadas, constando situações de tomadas
de decisões que o gerente de projeto enfrenta no dia-a-dia, com o objetivo de tornar mais claros os
conceitos inclusos no Guia, como práticas tradicionais amplamente aplicadas e práticas inovadoras
que estão surgindo para o auxílio no gerenciamento de projetos(PMI, 2004).
Segundo o PMI (2004), existem dois tipos de ciclo de vida relacionados a projetos, o Ciclo
de Vida do Projeto e o Ciclo de Vida do Gerenciamento do Projeto. O diferencial entre eles é que o
ciclo de vida do projeto consiste no conjunto das diversas fases de um projeto, sendo determinadas
pelas características específicas e necessidades de cada projeto, em outras palavras, descrevem o
que precisa ser feito no projeto. Já o ciclo de vida do gerenciamento do projeto descreve o conjunto
de processos que devem ser seguidos para que o projeto seja bem gerenciado, sendo divido em
cinco grupos: Iniciação, Planejamento, Execução, Monitoramento/ Controle e Encerramento.
O PMI (2004) também divide o projeto em 9 áreas de conhecimento: integração, escopo,
tempo, custo, qualidade, recursos humanos, comunicação, riscos e aquisições.
A área de riscos é uma das áreas mais delicadas em projetos, pois riscos estão presentes em
toda atividade que possa ser executada no dia-a-dia. Quando se trata de gerenciamento de projetos,
compreender os riscos e saber como minimizar seus impactos(ou tirar total proveito da
oportunidade que eles representam) é essencial para o sucesso. Os riscos, assim como as
informações coletadas em outros processos do planejamento, vão mudando no decorrer do projeto;
daí a necessidade de mantê-los sob constante monitoramento (HELDMAN, 2005).
A palavra risco vem do italiano antigo risicare, e, no sentido de incerteza, é derivada do
latim risicu e riscu. Sendo assim, a palavra risco deve ser interpretada como um conjunto de
incertezas encontrada quando ousamos fazer algo, e não apenas como problema (BERNSTEIN,
8
1997). Segundo Heldman (2005), risco é a probabilidade de acontecer uma situação adversa,
problema ou dano e as conseqüências deste mesmo.
Uma das principais preocupações do gerente de projetos e de sua equipe em relação aos
riscos deve acontecer logo no início do projeto, no planejamento do gerenciamento de riscos, que
vem a ser uma breve reflexão inicial de como irão lidar com os riscos do projeto ao longo de sua
concepção e desenvolvimento (SALLES JUNIOR et. al., 2007).
Os riscos se manifestam por vários motivos, internos ao projeto ou externos ao projeto. O
ambiente do projeto, o planejamento, o processo de gerenciamento, recursos inadequados, entre
outros, podem contribuir neste sentido. Alguns riscos já são conhecidos de antemão, podendo haver
uma preparação durante o processo com vias a evitá-los ou minimizá-los, já outros acontecerão de
forma inesperada no decorrer do projeto. O processo de Gerenciamento de Riscos especifica como
se preparar para uma eventual ocorrência de um risco no projeto (HELDMAN,2005).
O PMI (2004, p. 242) afirma que o Planejamento do Gerenciamento de Riscos é um
fundamento crucial de todos os processos que se seguem, no sentido de
(...) garantir que o nível, tipo e visibilidade do gerenciamento de riscos estejam de acordo
com o risco e a importância do projeto em relação a organização, para fornecer tempo e
recursos suficientes para as atividades de gerenciamento de riscos e para estabelecer uma
base acordada de avaliação de riscos (...)
Segundo Heldman (2005, p. 165), “(...) A finalidade do Gerenciamento de Riscos é criar um
plano de gerenciamento de riscos, que especifica como estes serão definidos, monitorados e
controlados ao longo do projeto e é a única saída desse processo.” Pelo plano pode-se saber como se
dará a implementação, monitoramento e controle dos processos de gerenciamento de riscos (dentre
eles a identificação, a análise, o planejamento de respostas e o monitoramento e controle de riscos)
durante toda a vida do projeto.
Os riscos ocorrem nas mais diversas áreas, cada item do escopo, cada caixa da
EAP(Estrutura Analítica do Projeto), cada atividade do cronograma, cada recurso do orçamento, são
fontes potenciais de riscos, podendo assim, considerar que todas as áreas de conhecimento de
gerenciamento de projetos podem ser fontes geradoras potenciais de riscos, como é o exemplo de
um escopo mal definido ou prazos e orçamentos apertados e inviáveis (SALLES JUNIOR et. al.,
2007).
9
Existem várias categorias de riscos as quais representam uma forma de identificar
sistematicamente os riscos e servem de base para a sua compreensão (HELDMAN, 2005). Dentre as
categorias já identificadas, destacam-se: Infraestrutura, organizacional, recursos humanos, dentre
outras. Sendo que ao longo dos projetos, novas categorias podem surgir e serem utilizadas.
2.1 Benefícios do Gerenciamento de Riscos
O gerenciamento de riscos proporciona os seguintes benefícios (SALLES JUNIOR et. al.,
2007):
• Garante que o projeto está controlado, em um nível que nunca esteve antes, pois se
reduziram as incertezas;
• Redução substancialmente da ocorrência de surpresas e problemas, com planos de ação
para atacar os riscos;
• Melhoramento da relação comercial, pois reduzir as surpresas e criar mecanismos de
defesa proporciona um maior poder de negociação e aproxima mais o planejamento do
efetivamente realizado;
• E, finalmente, aumenta substancialmente as chances de sucesso do projeto.
Já Vargas (2005), detalha mais a fundo os principais benefícios do gerenciamento de
projetos, destaca os seguintes:
• Permitir desenvolver diferenciais competitivos e novas técnicas, uma vez que toda a
metodologia está sendo estruturada;
• Antecipar as situações desfavoráveis que poderão ser encontradas, para que ações
preventivas e corretivas possam ser tomadas antes que essas situações se consolidem
como problemas;
• Adaptar os trabalhos ao mercado consumidor e ao cliente;
• Disponibilizar os orçamentos antes do início dos gastos;
• Agilizar as decisões, já que as informações estão estruturadas e disponibilizadas;
• Facilitar e orientar as revisões da estrutura do projeto que forem decorrentes de
modificações no mercado ou no ambiente competitivo, melhorando a capacidade de
adaptação do projeto;
• Otimizar a alocação de pessoas, equipamentos e materiais necessários;
• Documentar e facilitar as estimativas para futuros projetos.
10
2.2 Processo de Gerenciamento de Riscos
O gerenciamento de riscos, conforme o PMI (2004) é composto dos seguintes processos:
1. Planejamento do gerenciamento de riscos
2. Identificação de riscos
3. Análise qualitativa dos riscos
4. Análise quantitativa dos riscos
5. Planejamento de respostas a riscos
6. Monitoramento e controle de riscos
A Figura 1 apresenta o fluxograma do processo de gerenciamento de riscos, o seu
planejamento, identificação dos riscos, as análises, planejamento de respostas e o monitoramento e
controle, com as principais interações entre os processos e os principais fluxos de dados.
11
Figura 1- Fluxograma de processo do gerenciamento de riscos do projeto
Fonte: PMI (2004).
Nos itens seguintes, os processos de gerenciamento de riscos são detalhados.
2.2.1 Planejamento do Gerenciamento de Riscos
Segundo PMI (2004), um planejamento cuidadoso e explícito aumenta a possibilidade de
sucesso dos outros cinco processos do gerenciamento de riscos. Nesse processo é decidido como
abordar e executar as atividades de gerenciamento de riscos de um projeto, garantindo que o nível e
tipo de visibilidade do gerenciamento de riscos estejam de acordo com o risco e a importância do
projeto em relação a organização.
12
Segundo Salles Junior et. al. (2007), o gerenciamento de riscos deve ser feito na concepção
do projeto, no momento de seu planejamento inicial, antes mesmo de se tomar a decisão final se o
projeto deve seguir em frente ou não.
Assim, o gerenciamento de riscos só deve ser iniciado após o projeto já estar planejado, com
seu objetivo definido, EAP desenvolvida, as entregas do projeto já planejadas, a qualidade, o
cronograma, a estimativa de custos ou projeção de resultados, enfim, a proposta do projeto
concluída (SALLES JUNIOR et. al., 2007).
Segundo Salles Junior et. al. (2007), riscos estão presentes em todo e qualquer projeto, pois
não existe projeto que não ocorram algumas incertezas. Por isso, tem que pensar nas possíveis
incertezas e tentar identificá-las.
2.2.2 Identificação dos riscos
Hillson (apud SALLES JUNIOR et. al., 2007, p. 37) afirma que “o objetivo do processo de
identificação dos riscos é gerar uma lista refinada daqueles que podem ameaçar ou gerar
oportunidades com relação aos objetivos do projeto”. Dando início ao processo de tratamento dos
riscos do projeto, podendo ser desenvolvidas em três etapas distintas e complementares: analogia
com projetos anteriores, identificação de novos riscos e desenvolvimento de uma lista de riscos do
projeto e sua categorização (SALLES JUNIOR et. al., 2007) .
Várias ferramentas e técnicas de dinâmicas de grupo auxiliam a equipe para a identificação
de tais riscos, entre elas SALLES JUNIOR et. al. (2007) menciona o Brainstorming, Brainwriting,
Delphi e Swot, as quais são descritas a seguir.
Brainstorming
Brainstorming é a técnica mais conhecida, sendo realizada uma reunião de dinâmica de
geração de idéias, onde a idéia central é a “carona na idéia do outro”. Nesta dinâmica, tem-se a
visão de que toda idéia é válida, nada pode ser descartado. Com o debate, as idéias vão ganhando
forma e chegando a conclusões mais precisas (SALLES JUNIOR et. al., 2007).
Segundo Salles Junior et. al. (2007), o processo de brainstorming compreende os seguintes
passos:
• Selecionar participantes, distribuir as informações sobre o projeto, designar-se um
secretário e agendar a sessão;
• Na sessão, o gerente de projetos deve atuar como facilitador, instigando e buscando a
participação e a contribuição de todos.
13
Esse processo tem uma regra básica: dizer não ao não. Todas as idéias devem ser
aproveitadas, sem serem questionadas, senão estará colocando freios no processo criativo (SALLES
JUNIOR et. al., 2007).
Brainwritting
Brainwritting é decorrente da brainstorming, porém, as idéias são geradas por escrito. Ao
invés de debates, os participantes anotam os principais riscos em uma folha, trocando-se as folhas
entre os participantes sucessivamente até que seja elaborada uma lista de riscos do grupo,
selecionando-se os riscos que farão parte da lista final (SALLES JUNIOR et. al., 2007).
Segundo Salles Junior et. al. (2007), o processo de brainwritting compreende os seguintes
passos:
• Cada participante, sob seu ponto de vista, anota os principais riscos em uma folha;
• Após certo período de tempo, as folhas são trocadas entre os participantes;
• Repete o passo quantas vezes forem necessárias, elaborando assim, uma lista de riscos
do grupo;
• Finalizando, selecionam-se os riscos que farão parte da lista final.
Nas técnicas de brainstorming e brainwritting apresentam-se dois aspectos limitantes que
dificultam a realização das mesmas: para sua realização pressupõe-se que todos os participantes
estejam disponíveis fisicamente para a sessão e caso existam participantes de uma mesma estrutura
hierárquica, pode ocorrer a inibição e a conseqüente não-contribuição por parte dos subordinados
(SALLES JUNIOR et. al., 2007). Uma alternativa é a técnica Delphi, descrita a seguir.
Delphi
Delphi é uma técnica utilizada para suprir os limitadores das técnicas de brainstorming e
brainwritting, pois funciona como se fosse um Brainstorming remoto e anônimo, onde somente o
facilitador (geralmente o gerente do projeto ou stakeholder designado por ele) terá conhecimento
sobre os participantes e suas respectivas respostas. Os participantes geram uma lista de riscos e
enviam para o facilitador, onde o mesmo consolida as diversas listas em uma e redistribui entre os
participantes, assim sucessivamente até gerar uma lista unificada dos riscos (SALLES JUNIOR et.
al., 2007).
Swot
Na técnica Swot considera-se que todo projeto está associado a um negócio, e deve-se estar
preparado para atender o que for identificado no ambiente externo no qual esse negócio está
14
inserido. É uma análise estratégica cuja abreviação deriva de forças, fraquezas, oportunidades e
ameaças (strengths, weakness, opportunities e threats) (SALLES JUNIOR et. al., 2007).
Segundo Salles Junior et. al. (2007), pode-se definir cada elemento da análise Swot como
abaixo:
• Oportunidades (opportunities): Tendências sociais, econômicas, comerciais,
mercadológicas e políticas, com conseqüências positivas para o projeto;
• Ameaças (threats): Tendências sociais, econômicas, comerciais, mercadológicas e
políticas, com conseqüências negativas para o projeto;
• Forças (strengths): Recursos e competências superiores de que se dispõe para
explorar/alavancar oportunidades e minimizar ameaças;
• Fraquezas (weakness): Deficiências que inibem a capacidade de desempenho e
devem ser superadas para explorar/alavancar oportunidades e minimizar ameaças.
Para facilitar esta análise, criou-se o modelo gráfico conforme apresentado no Quadro 1
onde cada quadrante tem seu significado explícito na tabela.
Quadro 1 - Análise Swot
Ameaças Oportunidades
For
ças Estamos prontos para
enfrentar essas ameaças
Estamos prontos para capturar ou alavancar essas oportunidades
Fra
quez
as
Não estamos prontos para enfrentar essas ameaças
Não estamos prontos para capturar ou alavancar essas oportunidades
Fonte: Adaptado de Salles Junior et. al. (2007).
A partir do que for identificado nos quadrantes da análise Swot é desenvolvido o plano de
ação. As oportunidades e ameaças para as quais a equipe estiver pronta devem ser cuidadas para
não se perderem. Porém, as oportunidades e ameaças que a equipe não estiver pronta, deverão ter
um plano de ação para transformar a fraqueza em força (SALLES JUNIOR et. al., 2007).
Categorizando os riscos
Após a identificação e descrição correta dos riscos, deve-se categorizá-los, ou seja, agrupar
os riscos por afinidades, criando as categorias ou refinando. Esse agrupamento é válido para auxiliar
15
no levantamento de riscos para projetos futuros, onde as categorias funcionam como filtros e
elementos instigadores da reflexão para identificação dos riscos. As categorias também servem para
divisão de tarefas dentro da equipe, procurando alocar as categorias para pessoas com
conhecimentos específicos para lidar com elas (SALLES JUNIOR et. al., 2007).
Segundo Heldman (2005), existem diferentes maneiras de descrever as categorias de riscos,
podendo ser revisados projetos anteriores para verificar as categorias usadas e adaptá-las para
projetos atuais.
Heldman (2005) também aconselha a criação de uma estrutura analítica dos riscos (EAR),
listando as categorias e subcategorias, conforme exemplificado na Figura 2.
Figura 2 - Estrutura analítica dos riscos (EAR).
Fonte: PMI (2004).
As categorias podem refletir o tipo de indústria ou área de aplicação em que o projeto se
encontra. Um exemplo seria os projetos de tecnologia da informação, onde provavelmente vão
apresentar inúmeros riscos da categoria técnica, enquanto projetos de construção civil devem estar
mais sujeitos a riscos externos (HELDMAN, 2005).
Observando a Figura 2, destacam-se quatro categorias, as quais são descritas segundo
Heldman (2005) a seguir:
16
• Riscos técnicos, de qualidade ou desempenho: nesta categoria de risco incluem-se
aqueles associados a tecnologias semidesconhecidas, tecnologias complexas ou
modificações tecnológicas previstas no decorrer do projeto.
• Riscos de gerenciamento do projeto: esta categoria engloba o planejamento
inadequado do cronograma e dos recursos. Resumindo, todo risco que pode ser gerado
por algo mal planejado no projeto, seja qual for sua área de gerenciamento.
• Riscos organizacionais: nesta categoria podem-se incluir conflitos de recursos
decorrentes de projetos diversos ocorrendo simultaneamente na organização. Objetivos
de escopo, tempo e custo pouco realistas e falta de financiamento ou desvio de fundos
deste para outros projetos.
• Riscos externos: nesta categoria incluem-se fatores externos ao projeto, tais como novas
legislações ou regulamentações, dificuldades trabalhistas, condições meteorológicas,
dentre outros.
2.2.3 Análise de riscos
Segundo Salles Junior et. al. (2007), um dos processos mais importantes no gerenciamento
de riscos é a análise dos riscos. Nele, pode-se dar uma dimensão, um peso, para cada risco, podendo
assim gerenciá-los de forma diferenciada.
O processo de análise de riscos deve ser feito em uma reunião, preferencialmente com o
mesmo grupo que identificou e categorizou os riscos. A equipe deve analisar a probabilidade e o
impacto de cada risco, decidindo seu peso ou grau de acordo com o método escolhido (SALLES
JUNIOR et. al., 2007).
Os processos de tratamento qualitativo e quantitativo, explicados nos próximos sub-itens,
são utilizados para tal análise, onde os dois processos podem ser usados individualmente ou em
conjunto. Na qualificação é realizada uma pré-seleção dos riscos para que sejam posteriormente
quantificados apenas os riscos selecionados (SALLES JUNIOR et. al., 2007).
Segundo Salles Junior et. al. (2007), sem o peso de cada risco, não se pode decidir
adequadamente qual reação tomar perante o risco ou quanto estariam dispostos a pagar para lidar
com tal risco.
Análise Qualitativa
A abordagem qualitativa gera uma primeira dimensão do peso dos riscos, podendo
classificar as variáveis probabilidade e impacto em escalas ordinais. Para tal procedimento, podem-
17
se usar ferramentas computacionais que auxiliam o trabalho da equipe (SALLES JUNIOR et. al.,
2007).
A análise qualitativa de riscos avalia a prioridade dos riscos identificados com base na
probabilidade deles ocorrerem, o impacto correspondente nos objetivos do projeto caso o risco
ocorra, dentre outros fatores (PMI, 2004).
Segundo PMI (2004), a análise qualitativa é geralmente uma maneira rápida e econômica de
estabelecer prioridades ao planejamento de respostas a riscos, e caso seja aplicada a análise
quantitativa de riscos, já proporciona uma base para sua aplicação.
Na Figura 3, é apresentado um breve resumo dos componentes da análise qualitativa de
riscos.
Figura 3 - Análise qualitativa de riscos: Entradas, ferramentas e técnicas, e saídas.
Fonte: Adaptado de PMI (2004).
Para cada risco identificado deve-se avaliar a probabilidade e o impacto do risco perante o
projeto. As probabilidades e impactos são de acordo com as definições fornecidas no plano de
gerenciamento de riscos. Riscos com baixa probabilidade ou impacto não serão classificados,
porém, serão incluídos em uma lista para gerenciamento futuro. Essa avaliação pode ser feita
através de reuniões com os membros da equipe de projeto, e se necessário, especialistas de fora do
projeto (PMI,2004).
Segundo Heldman (2005), uma probabilidade é a chance de um evento ocorrer. Já o
impacto refere-se a quantidade de danos ou ganhos que um determinado evento de risco representa
para um projeto. Os impactos podem ser expressos tanto com valores numéricos ou de escala
cardinal (assim como na probabilidade), ou valores como alto, médio ou baixo.
18
O Quadro 2 apresenta uma escala de riscos utilizada para os objetivos de custo, tempo e
qualidade com classificações que variam de alto-alto ao baixo-baixo. Para cada classificação é
atribuído um valor cardinal que será utilizado na matriz de probabilidade e impacto (HELDMAN,
2005).
Quadro 2 - Matriz de Classificação de Impactos dos Riscos
Objetivos Baixo-Baixo
Baixo Médio Alto Alto-Alto
0,05 0,2 0,4 0,6 0,8
Custo Nenhum impacto significativo
Aumento inferior a 6%
Aumento de 7% a 12%
Aumento de 13% a 18%
Aumento superior a 18%
Tempo Nenhum impacto significativo
Aumento inferior a 6%
Aumento de 7% a 12%
Aumento de 13% a 18%
Aumento superior a 18%
Qualidade Nenhum impacto significativo
Poucos componentes afetados
Impacto significativo, exigindo aprovação do cliente para continuar
Qualidade inaceitável
Produto inutilizável
Fonte: Heldman (2005).
Segundo Heldman (2005), os valores atribuídos para probabilidade e impacto servem para
desenvolver medidas predefinidas que descrevam o valor a ser atribuído ao evento de risco. Para
chegar até esses valores, podem ser utilizadas técnicas como o brainstorming e Delphi, já
comentadas anteriormente no processo de identificação de riscos.
A avaliação da importância de cada risco é normalmente realizada usando uma tabela de
pesquisa ou uma matriz de probabilidade e impacto. Essa matriz especifica as combinações de
probabilidade e impacto que levam a classificação dos riscos como de prioridade baixa, moderada
ou alta (PMI, 2004).
Exemplificando a utilização da matriz de probabilidade e impacto (HELDMAN, 2005),
imagine que foi identificado um evento de risco que pode causar impactos no projeto que pode
gerar 18% de aumento de custos. Analisando o Quadro 2, nota-se que se o risco gerar aumento de
13% à 18% no objetivo custo, o risco assumirá impacto alto (0,6) no projeto. Assume-se também
que na identificação do risco a sua probabilidade de ocorrência foi estipulada em média (0,4).
19
A Tabela 1 é uma matriz que especifica as combinações de probabilidade e impacto que
levam a classificação dos riscos, podendo ser utilizados termos descritivos ou valores numéricos,
dependendo da preferência organizacional (PMI, 2004).
Analisando a Tabela 1, relacionando a probabilidade (0,4) x impacto (0,6) chega-se a uma
pontuação de criticidade do risco perante o projeto. Neste caso, assume o valor 0,24, ficando dentro
do limiar médio. Sendo que os valores sem formatação são considerados valores baixos, valores em
negrito são considerados valores médios e valores em negrito e itálico são considerados valores
altos.
Tabela 1. Exemplo de Matriz de Probabilidade e Impacto
Valores do impacto Probabilidade 0,05 0,2 0,4 0,6 0,8 0,8 0,04 0,16 0,32 0,48 0,64
0,6 0,03 0,12 0,24 0,36 0,48
0,4 0,02 0,08 0,16 0,24 0,32 0,2 0,01 0,04 0,08 0,12 0,16 Fonte: Adaptada de Heldman (2005).
Na análise qualitativa, exigem-se dados exatos e imparciais para ser confiável. A análise da
qualidade dos dados sobre riscos é uma técnica para avaliar o grau de utilidade dos dados sobre
riscos para o gerenciamento de riscos (PMI, 2004). Ou seja, com ela, examina-se até que ponto o
risco é entendido, sua exatidão, qualidade, confiabilidade e integridade dos dados.
Segundo PMI (2004), após a análise qualitativa dos riscos, a lista de riscos é atualizada e
incluída no plano de gerenciamento do projeto. Entre as atualizações na lista de riscos a partir da
análise qualitativa, o PMI (2004) destaca as seguintes:
• Classificação relativa ou a lista de prioridades dos riscos do projeto: a partir da
matriz de probabilidade e impacto, podem-se classificar riscos de acordo com sua
importância individual.
• Riscos agrupados por categoria: após a análise qualitativa os riscos podem ser
agrupados por categoria, assim, a descoberta de concentrações de riscos pode aumentar
a eficácia de suas respectivas respostas.
• Lista de riscos que exigem resposta a curto prazo: os riscos podem ser agrupados
dependendo de sua urgência nas respostas.
• Lista de riscos para análise e respostas adicionais: alguns riscos podem necessitar
de análises adicionais, inclusive a análise quantitativa de riscos e ações de resposta.
20
• Lista de observação de riscos de baixa prioridade: como já mencionado
anteriormente, os riscos que não foram avaliados como importantes podem ser
colocados em uma lista para serem monitorados continuamente.
• Tendências dos resultados da análise qualitativa de riscos: após análises repetidas,
uma tendência a riscos específicos pode se tornar evidente, podendo fazer com que as
respostas a riscos ou a análise adicional sejam mais, ou menos, importantes/urgentes.
Análise Quantitativa
Segundo Salles Junior et. al. (2007), as organizações demonstram dificuldade ou
desconforto em estimar a probabilidade e o impacto de forma quantitativa, por ser uma análise mais
complicada que a análise qualitativa. Desta forma, as organizações costumam utilizar critérios
qualitativos ordinais no gerenciamento de riscos de seus projetos, pois qualificar é mais rápido e
fácil que quantificar. No entanto, a quantificação chega a resultados melhores e mais precisos que a
qualificação, permitindo um melhor gerenciamento dos riscos nos projetos.
Segundo Heldman (2005, p 185), “a análise quantitativa dos riscos avalia os impactos e
quantifica a exposição do projeto aos riscos por meio da atribuição de probabilidades numéricas a
cada um e aos seus impactos sobre objetivos do projeto”. Algumas técnicas são utilizadas para tais
ações. Segundo o PMI (2004), essas técnicas são utilizadas para :
• Quantificar os possíveis resultados e probabilidades do projeto.
• Determinar a probabilidade de atingir os objetivos do projeto.
• Identificar riscos que requeiram maior atenção, quantificando sua contribuição para o
risco geral do projeto.
• Identificar metas de cronograma, custos ou escopo realistas e viáveis.
• Tomar as melhores decisões possíveis de gerenciamento de projeto quando os
resultados forem incertos.
A análise quantitativa de riscos, assim como a análise qualitativa, verifica cada risco e seu
possível impacto sobre os objetivos do projeto. Cabe ao gerente de projetos decidir se a análise de
riscos quantitativa será utilizada no gerenciamento de riscos do projeto, tendo como base para essa
decisão a complexidade do projeto e a política organizacional relacionada ao planejamento de
riscos. Caso essa análise seja utilizada, deve-se tomar o cuidado para repeti-la cada vez que o
processo de planejamento de respostas a riscos for executado e como parte do monitoramento e
controle dos riscos (HELDMAN, 2005).
21
A análise quantitativa de riscos analisa o efeito dos eventos de riscos atribuindo uma
classificação numérica a esses riscos (PMI, 2004). Segundo Salles Junior et. al. (2007), a
probabilidade de um risco ocorrer será sempre um percentual, enquanto o impacto poderá ser
metido em termos de diversas unidades, como escopo, qualidade, tempo e custo.
Essas diversas unidades de impacto tornam difícil, se não impossível, a comparação de
riscos de categorias diferentes entre si. Por esse motivo, devem-se analisar todos os impactos com
base em uma unidade comum entre todos os eles, como qualquer unidade de medida pode ser
transformada em dinheiro, e a única unidade comum a todos os riscos é a financeira. Essa
transformação fará que os riscos possam ser comparados entre si (SALLES JUNIOR et. al., 2007).
Segundo Heldman (2005), existem dois conjuntos de ferramentas e técnicas no processo de
análise quantitativa de riscos, descritos a seguir:
Coleta de dados e técnicas de representação
Segundo Heldman (2005), entre as técnicas de coleta de dados incluem-se as entrevistas,
distribuição de probabilidade e opinião especializada.
Nas entrevistas, os integrantes da equipe de gerenciamento de projeto, stakeholders e
especialistas no assunto são os principais candidatos às entrevistas de risco, levantando suas
experiências anteriores e sobre como trabalhar com os tipos de tecnologia ou processos que serão
usados no projeto em pauta (HELDMAN, 2005).
Se a técnica de entrevistas for utilizada, primeiramente, devem-se determinar os métodos de
distribuição de probabilidade, o que será descrito logo a seguir. Dependendo da técnica utilizada
serão delimitados os tipos de informações que precisam ser coletadas. Por exemplo, utilizar uma
escala de três pontos que avalia os cenários de risco otimista, pessimista e mais provável ou utilizar
cálculos de desvio-padrão (HELDMAN, 2005).
Segundo Heldman (2005), geralmente, a técnica de distribuições de probabilidade utilizada
na análise quantitativa de riscos são as contínuas, que segundo o PMI (2004), abrangem as
distribuições normal, logarítmica normal, triangular, beta e uniforme.
As distribuições triangulares são baseadas nas estimativas de três pontos (pessimistas, mais
prováveis e otimistas), enquanto a normal e logarítmica normal usam os desvios médio e padrão
para quantificar os riscos (HELDMAN, 2005).
Quanto à opinião especializada, Heldman (2005) menciona que os especialistas podem ser
internos ou externos à organização e devem ter experiência aplicável ao projeto, se o projeto
22
envolve a fabricação de um novo produto ou de uma de suas partes, seria interessante consultar
especialistas como engenheiros ou estatísticos.
Análise quantitativa de riscos e técnicas de modelagem
Segundo Heldman (2005), existem quatro técnicas agrupadas nesta ferramenta: análise de
sensibilidade, análise do valor monetário esperado, análise da árvore de decisões e modelagem e
simulação.
Segundo o PMI (2004), a análise de sensibilidade ajuda a identificar quais riscos apresentam
maior impacto potencial no projeto. Uma representação típica da análise de sensibilidade é o
diagrama de tornado, que é útil para comparar a importância relativa das variáveis que possuem um
alto grau de incerteza com as que são mais instáveis.
Segundo Vargas (2005), todo risco necessita ser avaliado por dois aspectos: probabilidade
de ocorrência e gravidade das conseqüências. Multiplicando a probabilidade de um determinado
risco acontecer com sua gravidade, normalmente expressa em valores de prejuízos financeiros,
formando um conceito fundamental para a quantificação dos riscos denominado Valor Monetário
Esperado (VME). Sendo que a prioridade de respostas aos riscos será para os eventos que
apresentarem maior VME.
Árvore de decisões são diagramas que mostram a sequência de decisões inter-relacionadas e
os resultados esperados de acordo com a alternativa escolhida. Geralmente, no evento de um risco,
existe mais de uma escolha ou decisão das conseqüências que o mesmo traria para o projeto. As
escolhas disponíveis são expostas em forma de árvore, com suas possíveis conseqüências. Essas
árvores geralmente são usadas para expressar eventos de riscos associados a tempo e custo
(HELDMAN, 2005).
Segundo Heldman (2005), a modelagem permite que transforme em impacto os riscos
potenciais em pontos específicos do projeto para conseguir determinar como os objetivos do projeto
são afetados. As técnicas de simulação computam o modelo do projeto utilizando diversas entradas,
como custo ou duração do cronograma, para assim, encontrar a distribuição de probabilidade para a
variável escolhida.
Segundo o PMI(2004), as simulações são normalmente realizadas usando a técnica de
Monte Carlo, que calcula por meio de interações, o custo do projeto ou o cronograma do projeto
várias vezes, utilizando valores de entrada selecionados aleatoriamente utilizando distribuições de
probabilidade dos possíveis custos ou durações, para assim, calcular uma distribuição do custo total
possível do projeto ou de datas de término.
23
Assim como na análise qualitativa, a análise quantitativa tem como saída as atualizações do
registro de riscos. Assim, segundo Heldman (2005), existem novos elementos a serem registrados:
Análise probabilística do projeto: resultados previstos do cronograma e custos do projeto
em decorrência das conclusões da análise de riscos, incluindo a data de término e os custos
previstos e o grau de certeza associado a cada um. O nível de confiança nos resultados também
pode ser descrito pelo grau de certeza.
Probabilidade de cumprimento dos objetivos de custos e tempo: esta saída documenta o
que é atribuído de probabilidade para o cumprimento dos objetivos de custos e tempo do projeto
durante a análise quantitativa.
Lista de classificação dos riscos quantificados: é uma lista contendo os riscos de maior
ameaça, ou oportunidade, ao projeto e seus respectivos impactos. Incluindo também, os riscos de
maior probabilidade de impacto sobre o caminho crítico e os que apresentam custos mais altos para
a contingência.
Tendências dos resultados da Análise Quantitativa de riscos: essas informações mostram
a utilidade da análise quantitativa de riscos à medida que o projeto avança, evidenciando os riscos
mais ameaçadores e criando a oportunidade de se efetuarem outras análises ou iniciar-se o
desenvolvimento de planos de resposta a riscos.
2.2.4 Planejamento de respostas a riscos
Segundo Heldman (2005), no planejamento de respostas a riscos são especificadas as
medidas a serem tomadas para reduzir ameaças e tirar proveito das oportunidades encontradas e
ainda nela é realizada a designação de departamentos ou integrantes da equipe para a execução dos
planos de respostas a riscos.
Segundo Salles Junior et. al. (2007), neste processo, procura-se reduzir ou minimizar os
possíveis impactos ou a probabilidade de um risco negativo no projeto, porém, nos riscos positivos,
agir de maneira oposta.
Segundo PMI (2004), as respostas aos riscos planejadas precisam ser adequadas a
importância do risco, econômicas, rápidas, realistas no contexto do projeto, acordadas por todas as
partes envolvidas e ser de propriedade de uma pessoa específica.
No planejamento de respostas aos riscos, utilizam-se componentes importantes do plano de
gerenciamento de riscos como funções e responsabilidades, definições da análise de risco, tempo e
orçamento necessário para realizar o gerenciamento do projeto. Também se utiliza os registros de
24
riscos identificados no início do gerenciamento de riscos e atualizados durante os processos de
análise qualitativa e quantitativa (PMI, 2004).
Ferramentas e técnicas do planejamento de respostas a riscos
Segundo Heldman (2005), existem quatro ferramentas e técnicas no processo de
planejamento de repostas a riscos, sendo que cada uma delas envolve uma estratégia.
A seguir são detalhadas essas ferramentas e técnicas citadas por Heldman.
• Estratégias para riscos negativos ou ameaças: nesta técnica utiliza três estratégias
para lidar com os riscos negativos ou ameaças. A primeira é a prevenção, onde o
objetivo é evitá-los por completo, eliminando a causa dos eventos de riscos ou
modificando o plano do projeto de modo a resguardar seus objetivos contra tais eventos.
A segunda é a transferência, onde o risco e suas conseqüências são deslocados para
terceiros, não eliminando o risco, mas se livrando da responsabilidade de gerenciá-lo. E
por último, a mitigação, onde essa estratégia procura reduzir o impacto e a probabilidade
de ocorrência a níveis aceitáveis.
• Estratégias para riscos positivos ou oportunidades: nesta técnica também são
utilizadas três estratégias. A primeira é a exploração, onde buscam-se oportunidades de
impactos positivos. A segunda é o compartilhamento, onde o risco é entregue para um
grupo mais bem preparado para lidar com ele. A terceira é a melhoria, onde a estratégia
é observar a probabilidade e/ou o impacto do evento do risco para garantir que a
organização perceba seus benefícios.
• Estratégias tanto para ameaças quanto para oportunidades: ou em outras palavras,
aceitação. Esta estratégia pode ser utilizada tanto para eventos de riscos que apresentam
ameaça quanto para os que representam oportunidades para o projeto. Na aceitação
passiva não é criado nenhum plano para evitar ou mitigar o risco, preferindo aceitar as
suas conseqüências. Na aceitação ativa, criam-se reservas de contingência para lidar com
os riscos caso eles venham a ocorrer.
• Estratégias de respostas para contingência: nesta técnica são criadas alternativas de se
lidar com os riscos caso eles ocorram. Este processo visa a concretização do risco e
prepara a reação.
O Processo de reação
A decisão de como reagir perante os riscos deve iniciar analisando-se a descrição do risco e
o seu valor esperado (tanto para ameaças, quanto para oportunidades), imaginando assim, que tipo
25
de reação seria possível para lidar com esse risco. Neste processo, podem aparecer várias
alternativas, as quais devem ser analisadas e escolhida a melhor. As reações podem gerar custos,
por esse motivo, deverão obrigatoriamente, alterar ou a probabilidade de ocorrência do risco (se a
causa raiz do problema for atacada) ou seu impacto (se o efeito for atacado), alterando seu valor
esperado (SALLES JUNIOR et. al., 2007).
Segundo Salles Junior et. al. (2007), a reação decidida a se tomar na ocorrência dos riscos
pode ser feita em dois diferentes momentos. Reações imediatas são feitas no momento da
identificação e da análise dos riscos, pode ser chamada também de reação de prevenção ou de
contenção, e acontece antes da decisão final sobre o projeto. Reações de contingência são as ações
planejadas agora, mas que serão efetuadas no momento que o risco acontecer, o que significarão
custos futuros que precisam ser planejados em reservas financeiras.
Os dois momentos citados por Salles Junior et. al. (2007), podem ser complementares, assim
poderá existir riscos com duas reações. Podendo haver riscos com uma ou mais reações de
prevenção ou uma ou mais reação de contingência, ou ainda riscos sem prevenção, porém pode-se
contingenciá-los no futuro.
2.2.5 Monitoramento e controle de riscos
Segundo o PMI (2004), as respostas planejadas aos riscos serão executadas durante o ciclo
de vida do projeto, porém, o trabalho do projeto deve ser monitorado continuamente visando
encontrar novos riscos ou mudanças nos já encontrados.
Segundo Salles Junior et. al. (2007), controle, no contexto de gerenciamento de riscos,
significa verificar se determinado risco aconteceu, caso ocorra, os stakeholders devem ser avisados
no intuito de alterá-los.
Quando um risco se materializa, o responsável pelo seu acompanhamento deve dar o alerta,
para que seja respondido aos eventos de riscos durante a execução do projeto (SALLES JUNIOR et.
al., 2007).
Salles Junior et. al. (2007), também menciona que sistema gerencial dos riscos significa
como vamos acompanhá-los, sua periodicidade, quem estará envolvido, quais os momentos deve-se
parar para fazer uma revisão nos riscos sobre sua responsabilidade. Os principais momentos para se
fazer uma revisão são quando houver qualquer mudança no projeto, sempre que um evento de risco
realmente aconteça ou sempre que o projeto atinja um ponto de decisão ou milestone.
2.3 ANÁLISES DE FERRAMENTAS SIMILARES
26
Com o intuito de apoiar a análise e projeto da ferramenta para Gerência de Riscos de
projetos, objetivo deste TCC (Trabalho de Conclusão de Curso), foram pesquisadas e avaliadas
algumas ferramentas utilizadas para gerenciamento de riscos em projetos que já estão disponíveis
no mercado. A análise foi feita através de dois aspectos: funcionais e não-funcionais. Os softwares
avaliados são os seguintes:
1. Risk Radar v3.3.1
2. RiskTrake
3. @Risk
4. Project Builder
O Risk Radar1 é uma ferramenta desenvolvida pela ICE (Integrated Computer Engineering)
da ASC (American System Corporation). Essa ferramenta explora bem alguns recursos visuais.
Contém uma boa documentação, explicando conceitos gerais de gerenciamento de riscos e
funcionalidades da aplicação. Permite a impressão de mais de 20 diferentes tipos de relatórios. Está
disponível somente em inglês.
O RiskTrake2 foi desenvolvida pela Risk Services & Technolog. Essa ferramenta segue um
processo próprio e não contempla nenhuma metodologia como o PMBOK. Não é muito intuitivo,
mas dispõe de diveros wizards que auxiliam no preenchimento das informações, suportando
múltiplos projetos e múltiplos usuários. Contém boa documentação e possui help online sensível ao
contexto. É bastante limitado em relatórios, tendo apenas seis tipos de relatórios que podem ser
visualizados e impressos. Está disponível somente em inglês.
A Ferramenta @Risk3 foi desenvolvida pela empresa americana Palisad. O foco da
ferramenta é analisar e quantificar os riscos de negócios e auxiliar nas tomadas de decisões. Para
utilizar essa ferramenta é necessário ter um bom conhecimento do Microsoft Excel, pois a mesma é
um add-in da ferramenta. Permite a execução de vários tipos de simulação, mas não suporta
1 Risk Radar. Disponível em <http://www.americansystems.com/default.htm>. Acesso em 30 maio 2009. 2 RiskTrake. Disponível em < http://www.risktrak.com/products/products.htm> Acesso em 30 maio 2009. 3 @Risk. Disponível em <http://www.palisade.com/html/risk.asp>. Acesso em 30 maio 2009.
27
múltiplos projetos nem múltiplos usuários. Contém documentação em inglês, francês, espanhol e
alemão. Disponibiliza diversos relatórios, incluindo gráficos. Está disponível somente em inglês.
O Project Builder4 foi desenvolvido pela empresa brasileira Project Builder Ltda. O software
auxilia o gerenciamento de projetos e está fundamentado em conceitos e nas boas práticas
compiladas pelo PMI (Project Management Institute) e GTZ (Método ZOPP). A ferramenta é
totalmente voltada para WEB, tendo a disposição na ferramenta gráfico de Gantt, painel de
controle dos projetos, estrutura analítica do projeto - EAP (disponível em formato gráfico) e
histórico do projeto. Está disponível em inglês e português.
Para os softwares citados acima, o RiskTrake e o Risk Radar foi possível baixar uma versão
de demonstração do aplicativo e testá-las, permitindo uma avaliação mais precisa. As outras
ferramentas não dispunham de uma versão de demonstração.
Considerando o estudo sobre gerenciamento de riscos segundo o PMBOK, uma ferramenta
deve conter algumas utilidades primordiais para permitir apoiar todos os processos necessários para
o bom gerenciamento de riscos em projetos. Dentre elas, criar um plano de gerenciamento de riscos,
permitir registrar os riscos, conter uma ferramenta para auxiliar na identificação dos riscos, permitir
categorizar os riscos, permitir a análise quantitativa e qualitativa, monitorar e controlar os riscos e
integrar-se com outras áreas de gerenciamento de projetos (escopo, tempo, qualidade).
Os quadros 3 e 4 apresentam uma comparação das ferramentas analisadas com as principais
funcionalidades e também requisitos não-funcionais. Nas tabelas também está incluso o software
proposto pelo presente TCC.
Quadro 3 - Funcionalidades dos softwares avaliados e da ferramenta proposta
Software Avaliado
Criação da EAR
(Gráfico)
Integração com
outras áreas
Monitoramento e controle dos
riscos
Contempla o PMBOK
Categorização dos riscos
Auxílio na identificação
Risk Radar Sim Não Sim Não Sim Não RiskTrake Não Não Sim Não Sim Não
@Risk - Não Sim - - Não
Project Sim Sim Não Sim Não Não
4 Project Builder. Disponível em <http://www.projectbuilder.com.br/>. Acesso em 30 maio 2009.
28
Builder Ferramenta Proposta
Sim Não Sim Sim Sim Sim
Quadro 4 - Características gerais dos softwares avaliados e da ferramenta proposta
Software Avaliado Software Gratuito
Plataforma Web Língua Portuguesa
Risk Radar Não Não Não RiskTrake Não Não Não @Risk Não Não Não Project Builder Não Sim Sim Ferramenta Proposta Sim Sim Sim
Através da análise realizada, é possível constatar que as ferramentas disponíveis no mercado
não contemplam todos os aspectos para um bom gerenciamento de riscos conforme a metodologia
do PMBOK. Com a análise constatou-se que as ferramentas não se enquadram nas boas técnicas de
usabilidade, de difícil entendimento, logo de difícil manuseio.
A ferramenta proposta terá alguns pontos marcantes e que farão a diferença na hora de
gerenciar os riscos dos projeto, tais como: (i) a criação da EAR, (ii) a designação de responsáveis
pelas categorias, onde as atividades ficam melhor divididas, diminuindo o risco de algo passar sem
ser notado e; (iv) a ferramenta para auxílio na identificação dos riscos.
3 PROJETO
Neste capítulo é apresentada a análise desenvolvida para especificação do software para
gerenciamento de riscos, conforme estudado na revisão bibliográfica. São apresentados os
requisitos funcionais, requisitos não-funcionais, as regras de negócio, casos de uso e protótipo de
telas, além do modelo de classes de domínio.
O projeto em questão foi desenvolvido para integrar-se com a ferramenta de Gerenciamento
de escopo em projetos (BORN, 2009), conforme citada no primeiro capítulo deste trabalho. A
princípio, a ferramenta Arisco utilizaria de todos os recursos já criados na ferramenta de
gerenciamento de escopo, bem como suas tabelas e classes. Porém, ao analisar mais a fundo a
ferramenta de gerenciamento de escopo, notou-se que o código gerado na criação da ferramenta é
de difícil entendimento e a vinculação atrasaria muito o processo de desenvolvimento.
Sendo assim, o projeto foi alterado, retirando a vinculação com a ferramenta de
gerenciamento de escopo. Utilizando da mesma, apenas a estrutura de cadastros de empresa,
funcionário e projeto, sendo que as classes para manipulação dos dados dessa estrutura foram
refeitas, pois a ferramenta de gerenciamento de escopos foi desenvolvida com o framework
ScriptCase e a ferramenta Arisco desenvolvida com o framework Symfony, o que impossibilitou a
reutilização dos códigos fonte, conforme é justificado no capítulo 4.
3.1 REQUISITOS DA FERRAMENTA
A seguir, são listados os requisitos funcionais, requisitos não-funcionais e regras de negócio
referentes à ferramenta proposta no trabalho em questão.
3.1.1 Requisitos Funcionais
Segundo Macoratti (2006), requisitos funcionais são a descrição das funções que clientes e
usuários querem que o software possua, definindo a funcionalidade desejada do software.
A seguir, os requisitos funcionais da ferramenta desenvolvida:
• RF01. O sistema deve permitir que o gerente crie o plano de gerenciamento de riscos.
• RF02. O sistema deve permitir que os riscos sejam identificados, alterados ou excluídos.
• RF03. O sistema deve permitir que os riscos sejam categorizados.
30
• RF04. O sistema deve permitir que seja realizada a análise qualitativa dos riscos.
• RF05. O sistema deve permitir que seja realizada a análise quantitativa dos riscos.
• RF06. O sistema deve permitir criar o plano de respostas aos riscos.
• RF07. O sistema deve permitir que seja informada a ocorrência do risco.
• RF08. O sistema deve permitir criar, alterar ou excluir a EAR (Modo gráfico e em forma
de lista).
• RF09. O sistema deve permitir que o gerente defina responsáveis por cada categoria.
• RF10. O sistema deve permitir a geração de relatórios de controle dos riscos, com filtros
determinados pelo usuário.
• RF11. O sistema deve conter uma ferramenta de auxílio a identificação dos riscos
utilizando a Técnica Delphi.
• RF12. O sistema deve permitir a criação da matriz de classificação de impacto dos
riscos.
• RF13. O sistema deve permitir o cadastro, alteração e exclusão de empresas.
• RF14. O sistema deve permitir o cadastro, alteração e exclusão de funcionários.
• RF15. O sistema deve permitir o cadastro, alteração e exclusão de projetos.
3.1.2 Requisitos Não-Funcionais
Segundo Macoratti (2006), requisitos não-funcionais são as qualidade globais de um
software, como usabilidade, desempenho e custo. A seguir, os requisitos não funcionais da
ferramenta desenvolvida:
• RNF01. Todos os relatórios devem ser emitidos em até 30 segundos após a solicitação.
• RNF02. O Sistema deve ser compatível com o banco de dados MySql.
• RNF03. O sistema deve ser implementado na linguagem PHP.
• RNF04. O sistema deve estar conforme a definição de Gerenciamento de Riscos
apresentada pelo Guia PMBOK- Terceira Edição, 2004.
31
3.1.3 Regras de Negócio
Segundo Dallavalle e Cazarini (2000) , regras de negócios são componentes de um sistema
de informação organizacional, nelas são uma nova categoria de requisitos do sistema que
representam decisões sobre como executar o negócio. A seguir pode-se observar a descrição das
regras de negócio da ferramenta proposta:
• RN01. Para identificar os riscos, o planejamento do gerenciamento de riscos deve estar
criado e autorizado.
• RN02. Para categorizar os riscos, os mesmos devem estar identificados.
• RN03. Para gerar a análise dos riscos, os mesmos devem estar categorizados.
• RN04. Para gerar o plano de respostas a riscos, a análise já deve ter sido realizada.
3.2 DIAGRAMA DE CASOS DE USO
O diagrama de casos de uso é composto por quatro atores denominados: Administrador,
Equipe, Gerente e Responsável.
O ator Responsável representa um usuário para quem foi designada alguma função especial.
A equipe representa todos os envolvidos no processo de identificação de riscos utilizando a
ferramenta de auxílio. Já o ator gerente é o gerente do projeto e o ator administrador é responsável
pelos cadastros de empresa, funcionários e projetos.
Foram criados cinco diagramas de caso de uso, como pode ser visto no Diagrama de pacotes
abaixo (Figura 4).
32
Figura 4 - Diagrama de pacotes
Para melhor entendimento dos casos de uso, o PCT04 contém apenas os atores que serão
utilizados.
No PCT01 estão todos os cenários de entrada de informações no sistema, podendo ser
melhor analisado na Figura 5.
33
uc PCT01 - Entradas
Gerente
(from PCT04 - Atores)
Responsáv el
(from PCT04 - Atores)
UC001 - Criar Plano de
Gerenciamento de Riscos
UC002 - Criar EAR
UC003 - Manter lista
de Riscos
UC004 - Criar Matriz de
impacto dos riscos
UC009 - Criar respostas
aos riscos
«extend»
Figura 5 - PCT01 – Entradas
No PCT02 estão todos os processos identificados para a ferramenta de auxílio na
identificação de riscos utilizando a técnica Delphi. Podendo ser melhor analisado na Figura 6.
34
uc PCT02 - Identificação de riscos usando Delphi
Equipe
(from PCT04 - Atores)
UC006 - Identificação
dos riscos
UC007 - Rev isar lista
de riscos
UC010 - Filtrar lista de
riscos
Responsável
(from PCT04 - Atores)
Figura 6 - PCT02 - Identificação de riscos usando Delphi
No PCT03 estão os processos de controle dos riscos. Como pode ser melhor analisado na
Figura 7.
uc PCT03 - Controle
UC005 - Gerar
análisesUC008 - Informar
ocorrëncia do risco
Responsáv el
(from PCT04 - Atores)
Gerente
(from PCT04 - Atores)
Figura 7 - PCT03 – Controle
No PCT05 estão todos os cadastros de responsabilidade do ator administrador, que seriam os
cadastros de funcionário, empresa e projeto. Conforme Figura 8.
35
uc Cadastros gerais
UC012 - Manter
Funcionário
UC011- Manter Empresa
UC013 - Manter Projeto
Administrador
(from PCT04 - Atores)
Figura 8 - PCT05 – Cadastros Gerais
A descrição dos casos de uso da ferramenta proposta, com suas especificações, requisitos
externos e cenários é apresentada no Apêndice A.
3.3 DIAGRAMA DE CLASSES
A Figura 9 corresponde ao diagrama das principais classes do projeto. Sendo que as classes
Projeto, Colaborador e Empresa são classes do trabalho de Born (2009) foram reimplementadas
para suportar o framework Symfony.
36
Figura 9 - Diagrama de Classes
3.4 DIAGRAMA DE ATIVIDADES
O diagrama de atividade a seguir, demonstra o fluxo de atividades desde a criação do plano
de gerenciamento de riscos até a criação do plano de respostas aos riscos. Quanto ao processo de
controle e monitoramento de riscos não foi exposto no diagrama pois esse é um processo que ocorre
durante toda a execução do projeto.
37
act Diagrama de atividadeGerente equipe Responsável
Cria Plano degerenciamento de riscos
Novo
projeto
Ferramenta de
auxílio para
identicação? Inclui possív eis riscos
Inclui riscos
Filtra riscos selecionados Rev isa lista de riscos
Identificação
Aprovada?
Categoriza os riscos
Designa responsáveispelas categorias
Elabora Matriz de impacto
Manter respostas para osriscos
Valida plano de respostas
Aprova
respostas
Gerar análises
Análise
OK?
Final do processo
EAR
Criar EAR
Reav alia probabilidades eimpactos
[Sim]
[Sim]
[Sim]
[Não]
[Não]
[Sim]
[Não]
[Não]
[Sim]
[Não]
Figura 10 - Diagrama de Atividades
38
4 IMPLEMENTAÇÃO
Neste capítulo são apresentados os resultados alcançados durante a fase de implementação,
abordando as ferramentas utilizadas no processo de desenvolvimento, os componentes utilizados e
também o banco de dados.
4.1 BANCO DE DADOS
Conforme o projeto de software, o banco de dados utilizado para a base do sistema é o
MySQL 5.0.51b. Para a criação do modelo de entidade de relacionamento foi utilizado o software
DBDesign 4 (FABFORCE.NET, 2003), esta versão está disponível para download gratuito e está
publicado sob a licença GNU GPL.
A ferramenta é de fácil utilização, tendo uma interface simples , permitindo a criação de
uma modelagem bem detalhada. Na Figura 11 é apresentada a interface do DBDesign 4, podendo
visualizar algumas entidades e seus relacionamentos.
39
Figura 11 - Interface principal do DBDesigner 4
Na Figura 12, é apresentado o Modelo de Entidade Relacionamento desenvolvido no
DBDesigner para o projeto em questão.
Figura 12 - Diagrama de Entidade Relacionamento
4.2 FRAMEWORK SYMFONY
Com a finalidade de aumentar a velocidade de implementação e facilitar a criação das
interfaces, foram pesquisados alguns frameworks onde destaca-se o ScriptCase5 e o Symfony6. Para
escolher o melhor, foi levado em consideração os requisitos básicos para o desenvolvimento deste
projeto, sendo que os dois frameworks se encaixaram nos requisitos por suportarem a linguagem
PHP, banco de dados MySQL e são compatíveis com o sistema operacional Windows.
Porém, o ScriptCase é uma ferramenta paga e de difícil utilização, pois os códigos que a
mesma gera são de difícil entendimento e difíceis de serem alterados manualmente, com isso, a
integração com outras ferramentas ou componentes se torna muito complexa, levando-se em base
que no trabalho do BORN(2009) foram encontradas várias dificuldades para realizar a comunicação
entre as classes geradas pela ScriptCase e o componente Draw2D, que também é utilizado para o
desenvolvimento da ferramente Arisco. Já o Symfony é Open-Source, não precisando se preocupar
com licença para a utilização do mesmo e gera códigos limpos e de fácil entendimento para quem
conhece a linguagem PHP.
Após a análise dos frameworks, o Symfony se destacou e foi escolhido para a utilização no
desenvolvimento da ferramenta.
O Symfony foi criado a fim de cumprir alguns requisitos: (a) Fácil instalação e configuração
em mais plataformas;(b) Mecanismo de banco de dados independente;(c) Fácil de usar, até em
situações mais complexas;(d) Compatível com a maioria das melhores práticas WEB e padrões de
design;(e) Código legível, documentação e fácil manutenção (ESPAKE, 2008).
Framework de aplicação Web para projetos PHP. Com um número muito reduzido de
requisitos, o Symfony pode ser instalado em qualquer configuração, bastando apenas ter um
servidor WEB e PHP instalado, sendo compatível com quase todos os tipos de base de dados
(SYMFONY, 2003).
Contendo bastante conteúdo de ajuda na internet. Como é o exemplo da página do
aplicativo, onde se pode pesquisar em vários tutoriais e fóruns, muito explicativos e de fácil
5 ScriptCase – Disponível em: http://www.scriptcase.com.br/. Acesso em 02 novembro 2009. 6 Symfony – Disponível em: http://www.symfony-project.org. Acesso em 02 novembro 2009.
42
entendimento. O framework visa construir aplicações robustas em um contexto empresarial, assim
pode-se ter total controle sobre sua configuração: desde a estrutura de diretórios até as bibliotecas
estrangeiras, quase tudo pode ser personalizado (SYMFONY, 2003).
Para a plataforma Windows, o módulo de desenvolvimento do Symfony é acessado via linha
de comando do DOS, onde se pode criar toda a estrutura de arquivos necessários para a execução de
um projeto, dentre eles destacam-se as classes do modelo MVC, que é um padrão de arquitetura de
software, onde se trabalha com 3 camadas de classes: camadas de Interface, controle e de modelos,
separando a lógica do sistema dos dados. Sendo que o Symfony gera a estrutura dos projetos 100%
em MVC (SYMFONY, 2003).
4.3 DRAW2D
Para a criação da EAR -Estrutura Analítica de Riscos-, foi utilizado o componente Draw2D,
que foi desenvolvido por Herz (2008), e está disponível sobre licença LGPL. Este componente
permite elaborar desenhos e diagramas interativos, utilizando o navegador padrão de internet.
Baseia-se na biblioteca JavaScript Vector Graphics Library, podendo assim criar diagramas de
maneira mais simples e rápida.
A escolha da utilização deste componente, justifica-se pela facilidade que o componente
oferece para a geração de diagramas utilizando JavaScript, contemplando a necessidade de uma
ferramenta para a geração da EAR - Estrutura Analítica de Riscos - em modo gráfico.
43
5 APRESENTAÇÃO DA FERRAMENTA
A ferramenta para Gerenciamento de Risco de Projetos (ARISCO) começou a ser
desenvolvida de acordo com a modelagem especificada anteriormente, em especial o modelo ER
proposto, pois o Symfony gera automaticamente toda a estrutura de classes necessárias para iniciar
a implementação da ferramenta a partir do banco de dados.
5.1 LAYOUT
Primeiramente foi construído o layout padrão para a ferramenta, sendo fixo para todas as
telas do sistema. Para isso foram utilizadas as configurações pré-definidas por CSS – Cascading
Style Sheets. O layout gerado pode ser visualizado na Figura 13. Analisando a figura, pode-se notar
o cabeçalho da ferramenta, o menu flutuante e no canto direito do menu o projeto que está sendo
gerenciado no momento, sendo que neste exemplo nenhum projeto foi ainda selecionado.
Figura 13 - Layout padrão do sistema
5.2 A FERRAMENTA
A primeira ação do usuário ao utilizar a ferramenta é efetuar o login, conforme pode ser visto
na Figura 14. Onde na primeira utilização da ferramenta, o administrador da mesma deverá
cadastrar a empresa, funcionários e projetos para que possam ser gerenciados.
44
Figura 14 - Tela de login
Ao efetuar o login, o administrador deverá realizar os devidos cadastros de empresa,
funcionários(usuários do sistema) e do projeto. Para isso, foi criada a parte administrativa do
sistema, onde pode ser realizado esses cadastros.
Na Figura 15, tem-se a tela desenvolvida para cadastro/atualização/exclusão de empresas.
45
Figura 15 - Manter Empresa
Na Figura 16, pode-se visualizar a tela a tela criada para manutenção de dados de
funcionários. Na tela pode-se observar que no momento que o administrador inclui um novo
funcionário o mesmo já cadastra um usuário e senha para o mesmo, sendo que a senha pode ser
alterada posteriormente pelo próprio usuário.
46
Figura 16 - Manter Funcionário
Na Figura 17, pode-se visualizar a tela criada para cadastro/atualização/exclusão de projetos.
47
Figura 17 - Manter Projeto
48
Antes de iniciar o gerenciamento ativo dos riscos, deve-se escolher qual projeto será
gerenciado, acessando no menu principal a opção Home, onde serão listados todos os projetos que o
usuário pode acessar. O acesso a cada projeto é definido conforme a função do usuário no processo
de gerenciamento de riscos. Caso o usuário seja gerente do projeto, o mesmo terá acesso total às
funcionalidades do gerenciamento. A tela para escolha do projeto a ser gerenciado pode ser
visualizada na Figura 18.
Figura 18 - Escolha de projeto a ser Gerenciado
Após o escolha do projeto, inicia-se assim as etapas do gerenciamento de riscos, conforme já
mencionado no projeto presente, iniciando pelo plano de gerenciamento de riscos que será
visualizado ao escolher o projeto. Somente o gerente do projeto pode incluir/alterar o plano de
gerenciamento de riscos, caso o usuário não seja o gerente, o mesmo só terá acesso ao modo de
visualização do plano, não podendo alterá-lo. A Figura 19 mostra a tela onde pode ser controlado o
plano de gerenciamento de riscos.
49
Figura 19 - Manter Plano de Gerenciamento de Riscos
É na etapa de planejamento também que se deve criar a matriz de impacto dos riscos,
clicando na opção “Matriz Impacto” existente na tela do plano de gerenciamento de riscos ou pelo
50
menu principal na opção “Outros” e “Matriz de Impacto”. Com pode ser visto na Figura 20, nesta
tela, deve ser informado para cada objetivo x Impacto em qual situação o mesmo será empregado.
Figura 20 - Manter Matriz de Impacto
Outra etapa do planejamento do gerenciamento é a elaboração da EAR – Estrutura Analítica
de Riscos- caso o gerente deseje utilizá-la. Para isso o mesmo deve marcar a opção “Usar EAR”
presente na tela do plano de gerenciamento de riscos. Após cadastro do plano, acessar a opção
“Outros” do menu principal e “Manter EAR”. A Figura 21 mostra a tela onde é gerada a EAR em
modo de lista, conforme pode ser visualizado. Para inserção dos itens da EAR, basta o usuário
informar a categoria que deseja incluir, qual a sua categoria pai e o responsável pela mesma, sendo
que para inclusão de categorias pai, basta informar a categoria, deixando os outros campos em
branco.
51
Figura 21 - Manter EAR - Estrutura Analítica de Riscos modo Lista
52
Caso na tela acima, o usuário desejar visualizar a EAR em modo gráfico, basta clicar no
botão “EAR Gráfica” na parte inferior da tela. Na Figura 22, pode ser visualizada a tela onde é
visualizada a EAR em modo gráfico.
Figura 22 - Manter EAR - Estrutura Analítica de Riscos modo gráfico
Após planejar como os riscos serão gerenciados, inicia-se o processo de identificação dos
riscos, processo esse que pode ser revisto durante todo o processo de gerenciamento. O responsável
por incluir os riscos no sistema é o Gerente do projeto ou quem ele designar. A Figura 23 mostra a
tela de inclusão de riscos.
53
Figura 23 - Manter Riscos
Além do modo de inclusão manual de riscos, a ferramenta Arisco disponibiliza para o
gerente a opção de utilizar a técnica Delphi para a identificação dos riscos, conforme já descrita no
capítulo 2. Seria como realizar uma sessão de brainstorming, porém, sem a necessidade de todos os
envolvidos estarem presentes fisicamente pois a ferramenta Arisco é voltada para a WEB, podendo
ser acessada de qualquer dispositivo com acesso a internet.
Para a utilização desta ferramenta, o gerente de projetos deve informar no plano de
gerenciamento de riscos que a mesma será utilizada, conforme pode ser visto na Figura 19. Após
isso, o gerente poderá acessar pelo menu principal as opções “Delphi” e “Status”, para assim, poder
54
iniciar o uso da ferramenta. Conforme pode ser visto na Figura 24, na tela o gerente poderá
controlar as fases da identificação, onde:
• Não iniciado: nesta fase o gerente já informou que a ferramenta será utilizada, porém a
identificação ainda não foi iniciada.
• Fase 1: quando o gerente alterar o status para esta fase, é enviado um e-mail para todos os
envolvidos no gerenciamento de riscos do projeto, informando que o processo de
identificação foi iniciado. A descrição do e-mail será o que o gerente informar na tela.
• Fase 2: assim como na fase 1, quando o gerente alterar o status para esta fase, é enviado um
e-mail para todos os envolvidos no gerenciamento do projeto, informando que a segunda
fase da identificação de riscos foi iniciada.
• Em análise: esta opção é escolhida pelo gerente em cada intervalo entre as fases de
identificação. É nesta fase que o mesmo terá acesso a tela de filtragem dos riscos já
selecionados e poderá assim analisar os riscos, conforme será melhor explicado mais abaixo.
• Encerrado: esta opção é selecionada pelo gerente no momento que o mesmo acha que o
processo de identificação já está encerrado. Quando esta opção é selecionada e o gerente
confirma a operação, todos os riscos identificados durante a utilização da ferramenta delphi
são copiados para os riscos efetivos no projeto, sendo que até então os mesmos só se
encontravam na própria ferramenta Delphi. Após isso, segue-se todo o fluxo do
gerenciamento de riscos.
55
Figura 24 - Controle técnica Delphi
Quando a identificação de riscos encontra-se em status “Fase 1”, os usuários podem iniciar a
inclusão dos riscos, conforme Figura 25. Nesta fase cada usuário terá acesso somente aos riscos que
ele mesmo cadastrou, não podendo visualizar o restante.
56
Figura 25 - Identificação Fase 1
Quando a identificação de riscos encontra-se em status “Fase 2”, os usuários poderão ter
acessos a todos os riscos identificados por todos os usuários, porém, não poderão edita-los nem
excluí-los, mas poderão incluir comentários aos riscos, que será analisado pelo gerente e ele sim
poderá alterar o risco caso necessário. Conforme pode ser visto na Figura 26. Caso o gerente ache
necessário, a fase 2 poderá ser repetida quantas vezes achar necessário. Nesta fase também podem
ser incluídos novos riscos, pelo botão “Incluir risco” na parte inferior da tela.
57
Figura 26 - Identificação Fase 2
Quando a identificação de riscos encontra-se em status “em análise”, o único usuário que
terá acesso a ferramenta será o gerente, pois nessa fase ele analisará todos os riscos cadastrados,
editando ou excluindo os que achar necessário. Esta fase é muito importante para o processo de
identificação, pois é nela que o gerente deve analisar todos os riscos, bem como seus comentários e
decidir quais farão parte do projeto e quais serão descartados. A tela utilizada para essa análise pode
ser vista na Figura 27.
58
Figura 27 - Identificação Filtragem
Após o gerente estar convicto de que o processo está encerrado, o mesmo atualiza o status
para “Encerrado” e o processo de identificação de riscos será finalizado, incluindo definitivamente
os riscos identificados no gerenciamento de riscos do projeto.
Após finalizar o processo de inclusão de riscos e sempre que for preciso, conforme
planejado no plano de gerenciamento de riscos, devem ser realizadas as análises qualitativas e
quantitativas dos riscos, acessando o menu principal na opção “Gerência” e “Gerar Análise”,
conforme pode ser visto na Figura 28. Neste processo, o sistema percorre risco a risco, calculando
as análises de cada um, bem como a análise geral do projeto com base na análise de cada risco,
podendo ser visualizada na tela de relatório gerencial.
A análise qualitativa de cada risco é calcula multiplicando-se a sua probabilidade de
ocorrência pelo seu valor de impacto, esse valor de impacto refere-se ao valor atribuído na matriz
de impacto, conforme pode ser visto na Figura 20. Com base neste resultado, os riscos são
classificados por prioridades (baixa, média, alta). Já a análise qualitativa geral do projeto é
calculada da seguinte forma:
• Soma-se os resultados de probabilidade x impacto de todos os riscos identificados.
• O valor dessa soma é dividido pela quantidades de riscos identificados, tendo assim uma
média ponderada de probabilidade x impacto dos riscos.
59
• Essa média é dividida pela multiplicação da maior probabilidade e maior impacto que pode
ser encontrado nos riscos, para o projeto em exemplo, a probabilidade de ocorrência pode
ser de 0 a 1 e o impacto de 0.05 a 0.8, sendo assim, multiplicando 1 e 0.8 chega-se ao
resultado 0.8.
• Para finalizar, esse resultado é dividido por 100 para se ter um valor percentual ao resultado
obtido.
Para a análise quantitativa de cada risco, foi escolhido a técnica do VME - valor monetário
esperado – onde é realizada a multiplicação do impacto financeiro do risco pela sua probabilidade
de ocorrência, chegando assim ao seu valor esperado, que nada mais é do que um valor médio
atrelado para o risco levando em consideração quanto teria de impacto caso o mesmo ocorresse e a
sua probabilidade de ocorrência.
Na análise quantitativa geral do projeto, é calculado o melhor caso, valor base, valor
esperado e pior caso para o projeto. Onde:
• Melhor caso: Subtração do Valor base e a soma de todos os impactos financeiros de riscos
com efeitos de oportunidade. Seria como imaginar que todos os riscos que trazem benefícios
para o projeto acontecessem, e nenhum risco de efeito ameaçador.
• Valor base: Valor pré-estipulado no plano de gerenciamento de riscos, Figura 19.
• Valor esperado: soma do valor base com o resultado da soma de todos os VMEs de riscos
de efeito ameaça, menos a soma de todos os VMEs de riscos de efeito oportunidade.
• Pior caso: soma do valor base com o resultado da soma de todos os impactos financeiros de
riscos com efeito ameaça. Seria como imaginar que todos os riscos que trazem gastos para o
projeto acontecessem, e nenhum risco de efeito oportunidade.
60
Figura 28 - Gerar Análise dos riscos
No processo de composição do plano de respostas ao riscos, o gerente do projeto ou o
responsável por cada risco, que é definido de acordo com sua categoria já cadastrada anteriormente
na EAR, deverá incluir as respostas para o risco. Acessando no menu a opção “Gerência” e “Manter
Respostas”, o usuário terá acesso para informar as respostas a todos os riscos de sua
responsabilidade, conforme pode ser visto na Figura 29 , onde visualiza-se o risco e sua respectiva
categoria.
61
Figura 29 - Plano de respostas - lista de riscos
Após escolher o risco para o qual deseja incluir as respostas, pode-se realizar o cadastro das
mesmas, como pode ser visualizado na Figura 30. Sendo que depois de inclusa uma resposta, a
mesma pode ser editada ou excluída.
62
Figura 30 - Plano de respostas - inclusão de respostas
Na ocorrência de um determinado risco, o mesmo pode ser informado acessando a opção do
menu “Gerência” e “Informar Ocorrência”. O gerente do projeto ou responsável por cada risco,
deverá incluir a ocorrência no sistema e informar qual ou quais respostas foram efetuadas para tal
ocorrência. Na Figura 31, pode-se visualizar a tela onde o usuário informa o risco ocorreu.
63
Figura 31 - Ocorrência de riscos - lista de riscos
Após selecionar o risco desejado, será visualizada a tela onde é informada a ocorrência do
risco, conforme pode ser visualizado na Figura 32.
Figura 32 - Ocorrência de riscos - informar ocorrência
64
Para se ter um controle mais efetivo dos riscos, a ferramenta disponibiliza a execução de
relatórios, conforme pode ser visto na Figura 33. No exemplo, a busca foi realizada levando em
consideração o funcionário responsável pelos riscos, retornando assim, apenas os riscos daquele
funcionário específico. Esta consulta também poderia ser incrementada com os parâmetros de
impacto, categoria ou prioridade.
Figura 33 – Relatório Gerencial
5.3 PRINCIPAIS DIFICULDADES ENCONTRADAS
Durante o projeto, foram encontradas algumas dificuldades, buscando sempre a melhor
forma possível para supera-las e entre elas pode-se citar:
• Compreensão das metodologias de desenvolvimento do framework Symfony, para
construção do sistema. Para isto, foi necessário estudar o tutorial da ferramenta, manuais
de funcionamento, documentação disponível, além de tirar dúvidas com
desenvolvedores que conhecem a ferramenta mais a fundo.
• Compreensão do funcionamento e metodologia utilizada pelo componente Draw2D.
Para isto, foi necessário estudar a documentação disponível da biblioteca, exemplos de
aplicações disponíveis, estudo dos tutoriais disponíveis na internet.
• Integração do componente Draw2D com o framework Symfony. Para isto, foram
realizadas diversas pesquisas, porém, não foi encontrado nenhum exemplo claro da
integração entre essas ferramentas. Porém, conhecendo um pouco mais da estrutura de
arquivos do Symfony, foi possível encontrar a maneira correta de realizar tal integração.
65
Pois o Symfony tem uma estrutura de arquivos pré-definida, tendo diretórios específicos
para imagens, arquivos CSS, arquivos JavaScript, bibliotecas, dentre outros.
66
6 TESTES E VALIDAÇÃO
Foram realizados diversos testes durante o desenvolvimento da aplicação. Porém, sem uma
metodologia de testes específica, o que pode fazer com que alguns casos específicos de erro, não
sejam detectados a tempo, e que ocorram apenas em situações específicas, dificultando sua
resolução. Uma forma de contornar esse problema, seria através da utilização de métodos mais
eficazes para realização dos testes, porém, o curto prazo dificultou os testes.
Mesmo não utilizando uma metodologia para os testes, tentou-se simular várias situações
que poderiam ocorrer no decorrer da utilização da ferramenta, analisando assim o seu desempenho e
o seu bom funcionamento. Desde situação mais simples como o Cadastro de empresa, funcionário e
projetos, até situações mais complexas como o cálculo das análises qualitativas e quantitativas dos
riscos.
Durante os testes da ferramenta utilizando a técnica Delphi, prestou-se muito cuidado quanto
ao sigilo das informações digitadas pelos usuários, para não fugir da idéia de que os riscos
mencionados por cada usuário do sistema seriam visíveis a todos, porém, ninguém saberia quem o
identificou.
Outro ponto muito focado nos testes foi a criação da EAR, onde foram criadas várias
estruturas diferentes, com diferentes números de categorias e sub-categorias, gerando as estruturas
gráficas com o componente Draw2D conforme previsto.
Para finalizar a fase de testes da ferramenta, foi realizado um teste integrado de todas as
funcionalidades empregadas na mesma. O cadastro do plano de gerenciamento de riscos, a
identificação dos riscos utilizando a técnica Delphi e a inclusão de riscos da forma direta, a criação
do plano de respostas aos riscos, o cálculo das análises qualitativas e quantitativas de riscos, a
informação da ocorrência de riscos, geração de relatórios e a geração da EAR em modo de lista e
em módulo gráfico.
Não foi possível realizar os testes com profissionais da área de gerenciamento de riscos
quanto a precisão das informações geradas nas análises qualitativas e quantitativas dos riscos, esses
testes seriam de grande importância para os resultados atingidos pela ferramenta. Porém foram
realizados testes de mesa repetitivas vezes, onde foram utilizados exemplos encontrados em livros e
67
na internet, onde as informações apresentadas pela ferramenta coincide com as informações
disponibilizadas nos exemplos utilizados.
68
7 CONCLUSÃO
O principal objetivo deste projeto foi o desenvolvimento de uma ferramenta computacional
para apoio ao gerenciamento de riscos em projetos conforme o PMBOK, possibilitando aos gerentes
de projetos, um melhor gerenciamento dos riscos que possam vir a acontecer durante o andamento
de seus projetos.
Diante do que foi exposto neste trabalho, nota-se a grande importância do gerenciamento de
riscos em projetos. Um pequeno descuido pode fazer com que o projeto não se concretize como
esperado ou nem ao menos se concretize. O gerenciamento de riscos não só diminui as chances de
ameaças causarem grandes impactos nos projetos, mas também, com ele, pode-se aproveitar de
maneira bem mais significante as oportunidades que surgem durante o projeto e em muitos casos
até transformar uma ameaça em oportunidade.
Geralmente, projetos possuem riscos de todas as áreas, sendo imprescindível um melhor
controle dos mesmos, os identificado já no início da elaboração do projeto. Com este processo, na
ocorrência de um risco, pode-se prever o impacto que o mesmo causaria no projeto. Documentar as
respostas que serão tomadas na ocorrência do risco também é um processo crucial no
gerenciamento de riscos. Com isso, na ocorrência do risco, a equipe de projetos já sabe de antemão
quais ações tomar para diminuir o impacto do risco ou até mesmo eliminá-lo.
Muitos projetos não se concretizam pela ocorrência de riscos não pré-identificados, não
tendo assim respostas imediatas e pré-avaliadas. Utilizando uma ferramenta computacional que
apóie o gerenciamento de riscos em projetos, fica muito mais fácil e rápido identificar e controlar os
riscos que eventualmente podem ocorrer. Com a ferramenta, o risco do projeto não se concretizar é
diminuído bruscamente.
Durante a análise das ferramentas existentes no mercado foi notável a grande dificuldade de
se encontrar uma ferramenta que supra as necessidades de gerenciamento de riscos em projetos que
sigam as recomendações do PMBOK.
Ao desenvolver essa ferramenta foi possível compreender o funcionamento de novas
tecnologias, tais como o framework Symfony e o componente Draw2D, adquirindo também, um
bom conhecimento da linguagem de desenvolvimento PHP. Foram encontradas diversas
69
dificuldades durante o desenvolvimento, dentre elas destacam-se a utilização do componente
Draw2D e a integração do mesmo com as classes geradas com o framework Symfony.
Ao realizar testes na ferramenta foi possível concluir que essa fase merece uma atenção
especial durante o processo de desenvolvimento, pois o importante quando se implementa um
software é assegurar que ele funciona, e a única maneira de se assegurar isso é testando a
ferramenta a fundo, eliminando possíveis erros que possam surpreender futuramente.
O objetivo principal deste trabalho foi alcançado, pois foi desenvolvida uma ferramenta para
apoiar efetivamente o gerenciamento de riscos de projetos. Além do desenvolvimento da
ferramenta, foram obtidos vários conhecimentos através das pesquisas, estudos, análises e
desenvolvimento da ferramenta, assim como o grande aprendizado sobre gerenciamento de riscos
de projetos conforme o PMBOK, e de outras áreas que de certa forma interagem com a área de
riscos.
7.1 TRABALHOS FUTUROS
Devido a alteração realizada no escopo deste projeto, onde a integração com a ferramenta de
gerenciamento de escopo (BORN, 2009) foi removida, fica aberta a possibilidade de alteração da
ferramenta Arisco para suportar a integração com a ferramenta de Born(2009) ou até mesmo a
alteração de tecnologia de desenvolvimento da ferramenta de gerenciamento de escopo para assim
integrá-la a ferramenta Arisco.
Além da integração com a área de escopo citada acima, novas áreas podem ser incorporadas
a esta ferramenta, tais como a área de custos do projeto, tempo e aquisições. Visto que são áreas que
influenciam diretamente os riscos do projeto e também são muito importantes para o bom
gerenciamento de projetos.
Outro trabalho futuro que pode ser desenvolvido, seria uma reestruturação da ferramenta
Arisco, melhorando principalmente seu design e a validação das informações digitadas pelos
usuários para evitar possíveis erros no momento que as mesmas sejam salvas no banco de dados da
ferramenta.
REFERÊNCIAS BIBLIOGRÁFICAS
BORN, Cristiano. Ferramenta para auxiliar no gerenciamento de escopo de projetos conforme o PMBOK. Itajaí, 2009. 57p. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2009. Trabalho não publicado.
BERNSTEIN, P. L. Desafio aos deuses: a fascinante história do risco. São Paulo: Elservier/Campus, 1997.
DALLAVALLE, Silvia Inês; CAZARINI, Edson Valmir. Regras do Negócio, um fator chave de
sucesso no processo de desenvolvimento de Sistemas de Informação. São Paulo: USP- EESC,
2000.
DINSMORE, Paul Campbell. Como se tornar um profissional em Gerenciamento de Projetos – Rio de Janeiro: Editora Qualitymark, 2007.
ESPAKE, Patrick; Introdução ao framework Symfony, 2008. Disponível em: http://phpbrasil.com/artigo/FjxQgMUoUau/introducao-ao-framework-symfony. Acesso em 02 Nov. 2009.
HELDMAN, Kim. Gerência de Projetos, Guia para o exame oficial do PMI - Terceira Edição – Rio de Janeiro: Elsevier, 2005.
HERZ, A. Open-jACOB Draw2D, 2008. Disponível em: <http://draw2d.org>. Acesso em: 20 out. 2008.
MACORATTI, José Carlos. A Gestão de Requisitos, 2006. Disponível em: http://imasters.uol.com.br/artigo/3860/des_de_software/a_gestao_de_requisitos . Acesso em 17 jul. 2009.
Project Management Institute – PMI. Guia PMBOK: Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos – Terceira Edição – Pennsylvania, 2004
SALLES JÚNIOR, Carlos A. C.; SOLER, Alonso M.; VALLE, José A. S.; RABECHINI JUNIOR, Roque. Gerenciamento de Riscos de Projetos – Rio de Janeiro - Editora FGV, 2007.
SYMFONY, Symfony. Disponível em http://www.symfony-project.org. Acesso em 02 nov. 2009.
VARGAS, Ricardo Viana. Gerenciamento de Projetos : Estabelecendo Diferenciais Competitivos – Sexta Edição – Rio de Janeiro – Brasport, 2005.
71
APÊNDICES
A DESCRIÇÃO DOS CASOS DE USO
Neste apêndice são apresentadas as descrições detalhadas dos casos de uso do projeto
UC001 – Criar Plano de Gerenciamento de Riscos
Este caso de uso tem como cenário principal a criação do plano de gerenciamento de riscos
(Figura 19 – Tela Manter Plano de Gerenciamento de Riscos).
• Requisitos:
RF01. O sistema deverá permitir que o gerente crie o plano de gerenciamento de riscos.
Pré-condição: O projeto deve estar criado e o usuário deve ser o gerente do projeto
Pós-condição: O plano de gerenciamento de riscos deve ser criado.
Tabela 2. Cenário UC001 – Criar Plano de Gerenciamento de Riscos
Criar ou alterar plano de gerenciamento de riscos - Principal 1. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto: - Nome do Projeto 2. O usuário informa os dados necessários, conforme a tela Manter Plano de Gerenciamento de Riscos. 3. O usuário confirma. 4. O sistema armazena os dados.
Cancelar plano de gerenciamento de riscos - Exceção
Caso o usuário opte por cancelar o plano de gerenciamento de riscos do projeto, durante a sua criação: 1. O sistema não armazena nenhuma informação.
Período de identificação inválido – Exceção Caso o usuário informe um período inválido para a identificação dos riscos: 1. O sistema retorna mensagem informando o erro ocorrido
UC002 - Criar EAR
Permite que seja criada a Estrutura Analítica de Riscos (EAR) do projeto (Figura 21– Tela
Manter EAR - Estrutura Analítica de Riscos modo Lista e Figura 22- Tela Manter EAR - Estrutura
Analítica de Riscos modo Gráfico).
• Requisitos:
73
RF08. O sistema deverá permitir criar, alterar ou excluir a EAR (Modo gráfico e em forma
de lista) .
RF05. O sistema deve permitir que os riscos sejam categorizados.
RF09. O sistema deverá permitir que o gerente defina responsáveis por cada categoria
Pré-condição: O plano de gerenciamento de riscos deve estar criado.
Pós-condição: E estrutura analítica de riscos deve ser criada.
Tabela 3. Cenário UC002 - Criar EAR
Criar EAR - Principal 1. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto: - Nome do Projeto Vai para o cenário Incluir categoria 2. O usuário confirma a criação da EAR. 3. O sistema armazena os dados.
Carregar EAR já existente - Alternativo
No passo 2 do cenário principal, caso o gerente de projetos queira utilizar uma EAR já criada em outro projeto: 1. Clica no botão 'Buscar EAR’. 2. O sistema permitirá que o gerente escolha de qual projeto ele deseja copiar a EAR. 3. O gerente escolhe a EAR que deseja utilizar. 4. O sistema carrega a EAR desejada.
Excluir Categoria ou Subcategoria - Alternativo Caso o usuário deseje excluir uma categoria criada: 1. O usuário clica no botão de excluir ao lado do item que ele deseja. 2. O sistema exclui a categoria da estrutura analítica de riscos. 3. O sistema atualiza a lista de categorias. 4. O sistema armazena os dados.
Alterar EAR - Alternativo
No passo 1 do cenário principal, caso o usuário queira alterar a EAR já existente: 1. O sistema carrega EAR. 2. O usuário clica no botão editar ao lado da categoria deseja alterar. 5. O sistema habilita categoria para alteração. 6. O usuário realiza alteração. 7. O usuário confirma. 8. O sistema atualiza EAR.
Incluir categoria - Alternativo Caso o usuário pretenda incluir uma nova categoria: 1. O usuário informa a nova categoria.
74
2. O usuário informa a categoria pai caso seja uma categoria filho. 3. O usuário informa o responsável pela categoria caso seja uma categoria filho. 3. O usuário adiciona a nova categoria. 4. O sistema adiciona a nova categoria na estrutura analítica de riscos. 5. O sistema atualiza a lista de categorias. 6. O sistema atualiza EAR.
Cancelar a criação da EAR - Exceção
Caso no passo 2 do cenário principal, o usuário opte por cancelar: 1. O sistema não armazena os dados.
Exclusão de categoria pai – Exceção Caso o usuário solicite a exclusão de uma categoria pai que tenha filhos atreladas a ela: 1. O sistema retorna mensagem informando que a categoria contém filhos e não pode ser excluída. 2. A categoria não é excluída.
UC003 - Manter lista de Riscos
Permite que seja atualizada a lista de riscos, podendo acrescentar, alterar ou excluir os riscos
(Figura 23 – Tela Manter Riscos).
• Requisitos:
RF02. O sistema deverá permitir que os riscos sejam identificados, alterados ou excluídos.
RF03. O sistema deve permitir que os riscos sejam categorizados.
Pré-condição: A matriz de impacto deve estar criada; A Estrutura analítica de riscos deve
estar criada.
Pós-condição: A lista de riscos deve ser atualizada com os riscos inseridos pelo usuário.
Tabela 4. Cenário UC003 - Manter lista de Riscos
Incluir/alterar riscos - Principal 1. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto: - Nome do Projeto 2. O usuário informa os dados necessários, conforme a Tela Manter Riscos. 3. O usuário confirma. 4. O sistema armazena os dados.
Excluir Riscos - Alternativo
Caso no passo 2, o usuário desejar excluir o risco: 1. O usuário clica no botão 'Excluir'. 2. O sistema atualiza lista de riscos.
Cancelar inclusão/alteração de risco - Exceção
Caso o usuário opte por cancelar a inclusão/alteração:
75
1. O sistema não armazena nenhuma informação.
Exclusão de risco já ocorrido – Exceção Caso o usuário solicite a exclusão de um risco que já tenha ocorrência cadastrada: 1. O sistema informa o usuário que risco já tem ocorrência cadastrada 2. O sistema não exclui o risco.
UC004 - Criar Matriz de impacto dos riscos
Permite que seja criada a matriz de classificação de impacto dos riscos no projeto. (Figura 20
– Tela Manter Matriz de Impacto)
• Requisitos:
RF12. O sistema deverá permitir a criação da matriz de classificação de impacto dos riscos.
Pré-condição: O plano de gerenciamento de riscos deve estar criado.
Pós-condição: A matriz de impacto dos riscos deve ser criada.
Tabela 5. Cenário UC004 - Criar Matriz de impacto dos riscos
Criar Matriz impacto - Principal 1. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto: - Nome do Projeto 2. O usuário define os pesos para cada nível. 3. O sistema atualiza a matriz de impacto. Vai para o cenário adiciona informações na matriz. 4. O usuário confirma a criação da matriz. 5. O sistema grava os dados.
Adiciona/altera informações na matriz - Alternativo
1. O usuário informa o campo da matriz que deseja inserir as informações (ex. Custo x Alto). 2. O usuário informa a informação que deve ser inserida. 3. O usuário confirma. 4. O sistema atualiza a matriz de impacto.
Cancelar - Exceção
Caso o usuário cancela alguma ação: 1. O sistema não armazena os dados.
UC005 - Gerar análises
Permite que seja gerada a análise do impacto dos riscos sobre o projeto (Figura 28 – Tela
Gerar Análise).
• Requisitos:
76
RF04. O sistema deverá permitir que seja realizada a análise qualitativa dos riscos.
RF05. O sistema deverá permitir que seja realizada a análise quantitativa dos riscos.
Pré-condição: A lista de riscos deve ter sido criada.
Pós-condição: A lista de riscos deve ser atualizada com os valores calculados na análise.
Tabela 6. Cenário UC005 - Gerar análise
Gerar análises - Principal 1. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto: - Nome do Projeto 2. O usuário solicita execução da análise. 3. O sistema gera análise. 4. O usuário confirma. 5. O sistema grava os dados.
Gerar análise qualitativa dos riscos - Alternativo
No passo 3 do cenário principal, caso os riscos sejam analisados com o uso da análise qualitativa: 1. O sistema busca as informações necessárias para gerar a análise (probabilidade de ocorrência e impacto do risco). 2. O sistema gera a análise qualitativa. 3. O sistema percorre a lista de riscos e atualiza os pesos de cada risco. 4. O sistema atualiza risco total do projeto. Volta ao passo 4 do cenário principal.
Gerar análise quantitativa dos riscos - Alternativo
No passo 3 do cenário principal, caso os riscos sejam analisados com o uso da análise quantitativa: 1. O sistema busca as informações necessárias para gerar a análise (probabilidade de ocorrência e impacto em R$ do risco). 2. O sistema gera a análise quantitativa. 3. O sistema atualiza os pesos de cada risco. 4. O sistema atualiza risco total do projeto. Volta ao passo 4 do cenário principal.
Cancelar Análise - Exceção
Caso o usuário opte por cancelar a análise: 1. O sistema não grava nenhuma informação.
UC006 - Identificação dos riscos
Este caso de uso permitirá que a equipe do projeto faça a identificação dos riscos através da
técnica Delphi (Figura 25 - Identificação Fase 1). Neste caso de uso, os usuários vão registrar os
possíveis riscos.
• Requisitos:
77
RF02. O sistema deverá permitir que os riscos sejam identificados, alterados ou excluídos.
RF11. O sistema deverá conter uma ferramenta de auxílio a identificação dos riscos
utilizando a Técnica Delphi
Pré-condição: O plano de gerenciamento de riscos deve estar criado, onde a opção de
utilizar a ferramenta Delphi deverá ser selecionada; O status da identificação dos riscos deve estar
na fase 1.
Pós-condição: A lista de riscos da ferramenta Delphi deve ser atualizada com os riscos
informados pelo usuário.
Tabela 7. Cenário UC006 - Identificação dos riscos
Criar lista de riscos - Principal 1. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto: - Nome do Projeto 2. O usuário inclui os riscos (Cenário Inclui risco) 3. O usuário confirma. 4. O sistema valida os dados. 5. O sistema armazena os dados.
Inclui risco - Alternativo
1. O usuário Informa risco. 2. O usuário confirma. 3. O sistema atualiza matriz de riscos.
Limpar dados - Alternativo
Caso após o passo 1 do cenário Inclui risco, o usuário optar por limpar o campo de digitação do risco: 1. O usuário clica no botão 'cancelar'. 2. O sistema limpa campo para digitação.
Cancelar Identificação de riscos - Exceção
Caso o usuário opte por cancelar a identificação de riscos: 1. O sistema não armazena nenhuma informação.
UC007 - Revisar lista de riscos
Este caso de uso permitirá que a equipe do projeto faça a identificação dos riscos através da
técnica Delphi. Os membros da equipe terão acesso a lista completa de riscos, podendo acrescentar
comentários aos mesmos, ou novos riscos (Figura 26 - Identificação Fase 2).
• Requisitos:
RF02. O sistema deverá permitir que os riscos sejam identificados, alterados ou excluídos.
78
RF11. O sistema deverá conter uma ferramenta de auxílio a identificação dos riscos
utilizando a Técnica Delphi.
Pré-condição: Status da identificação de riscos deve estar na fase 2.
Pós-condição: Lista de riscos atualizada com os comentários informados pelos usuários.
Tabela 8. Cenário UC007 - Cenário Revisar lista de riscos
Revisar Lista de Riscos - Principal 1. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto: - Nome do Projeto 2. O sistema carrega lista atualizada dos riscos. Vai para o cenário inclui comentário. 3. O usuário confirma. 4. O sistema armazena os dados.
Incluir comentário - Alternativo
Caso o usuário pretenda incluir um comentário sobre o risco em questão: 1. O usuário clica no botão 'Comentário'. 2. O sistema abre tela para digitação do comentário. 3. O usuário confirma. 4. O sistema grava os dados.
Inserir novo risco - Alternativo Caso o usuário opte por inserir novo risco: 1. O usuário clica no botão ‘Incluir risco’. 2. O sistema abre tela de inclusão de riscos. Vai para UC006 – Identificação dos riscos
Cancelar - Exceção
Caso o usuário opte por cancelar algum processo: 1. O sistema não grava nenhuma informação.
UC008 - Informar ocorrência do risco
Permite que seja informada a ocorrência de um risco (Figura 32 – Tela Informar Ocorrência)
• Requisitos:
RF07. O sistema deve permitir o controle e monitoramento dos riscos.
RF10. O sistema deverá permitir a geração de relatórios de controle dos riscos, com filtros
determinados pelo usuário.
Pré-condição: O risco deve ter sido identificado; Plano de resposta ao risco deve estar
criado.
Pós-condição: A ocorrência deve ser salva.
79
Tabela 9. Cenário UC008 - Informar ocorrência do risco
Informar ocorrência de risco - Principal Para informar a ocorrência de risco: 1. O sistema apresenta Tela Lista de riscos com os riscos de responsabilidade do usuário. 2. O usuário escolhe o risco a ser informada a ocorrência. 3. O sistema abre tela de Ocorrência de riscos. 4. O usuário informa os dados conforme a tela. 5. O usuário confirma. 6. O sistema grava os dados.
Cancelar - Exceção
Caso o usuário opte por cancelar a informação de ocorrência do risco: 1. O sistema não armazena nenhuma informação.
Resposta(s) ao risco não informada – Exceção Caso no passo 4 do cenário principal, o usuário não informar a(s) resposta(s) para o risco: 1. O sistema informa o usuário que pelo menos uma resposta deve ser selecionada. 2. O sistema retorna para o passo 3 do cenário principal.
Data de ocorrência superior a data atual – Exceção Caso no passo 4 do cenário principal, o usuário informe a data de ocorrência superior a data atual: 1. O sistema informa o usuário que a data de ocorrência deve ser igual ou inferior a data atual. 2. O sistema retorna para o passo 3 do cenário principal.
UC009 - Criar respostas aos riscos
Permite que sejam criadas respostas aos riscos (Figura 30 – Inclusão de Respostas).
• Requisitos:
RF06. O sistema deverá permitir criar o plano de respostas aos riscos
Pré-condição: A lista de riscos deve estar criada.
Pós-condição: Plano de respostas aos riscos deve ser criado.
Tabela 10. Cenário UC009 - Criar respostas aos riscos
Criar resposta ao risco - Principal 1. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto: - Nome do Projeto 2. O sistema apresenta tela com os riscos de responsabilidade do usuário. 3. O usuário escolhe o risco a ser informado as respostas. 4. O sistema abre tela de inclusão de respostas. 5. O sistema carrega os dados do risco: - Descrição do risco - Respostas sugeridas
80
6. O usuário informa a resposta desejada. 7. O usuário confirma. 8. O sistema atualiza lista de respostas. 9. O usuário confirma. 10. O sistema grava os dados.
Atualiza resposta - Alternativo
Caso usuário pretenda atualizar resposta já inclusa: 1. O usuário clica no botão de editar ao lado da resposta. 2. O sistema carrega a resposta para ser alterada. 3. O usuário altera o que deseja. 4. O usuário confirma. 5. O sistema atualiza a matriz.
Excluir resposta - Alternativo 1. O usuário clica no botão excluir ao lado da resposta desejada. 2. O sistema exclui a resposta. 3. O sistema atualiza a matriz.
Cancelar - Exceção
Caso o usuário cancele alguma ação: 1. O sistema não armazena os dados.
UC010 - Filtrar lista de riscos
Este caso de uso permitirá que a equipe do projeto faça a identificação dos riscos através da
técnica Delphi. O gerente avaliará a lista de riscos, filtrando-os e re-enviando à equipe se necessário
Figura 27 - Identificação Filtragem).
• Requisitos:
RF02. O sistema deverá permitir que os riscos sejam identificados, alterados ou excluídos.
RF11. O sistema deverá conter uma ferramenta de auxílio a identificação dos riscos
utilizando a Técnica Delphi.
Pré-condição: Status da identificação de riscos deve estar na “Em análise”.
Pós-condição: Lista de riscos atualizada.
Tabela 11. Cenário UC010 - Filtrar lista de riscos
Filtrar lista de riscos - Principal 1. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto: - Nome do Projeto 2. O sistema carrega matriz de riscos atualizada. Vai para o cenário alterar risco. 3. O usuário confirma.
81
4. O sistema armazena os dados.
Cancelar - Alternativo
Caso o usuário opte por cancelar a filtragem dos riscos: 1. O sistema não armazena nenhuma informação.
Excluir risco - Alternativo
Caso o usuário optar por excluir um risco: 1. O usuário solicita exclusão do risco. 2. O sistema atualiza a matriz de riscos.
Alterar risco - Alternativo
Se o usuário desejar alterar o risco em questão: 1. O usuário altera o risco. 2. O usuário confirma. 3. O sistema atualiza a lista de riscos.
Finalizar processo de identificação (Figura 24 - Controle técnica Delphi) - Alternativo No passo 3 do cenário principal Filtrar lista de riscos, o usuário opte por finalizar a identificação dos riscos: 1. O usuário atualiza o status da identificação para “Encerrada”. 2. O sistema valida as informações. 3. O sistema grava os dados. 4. O sistema atualiza lista de riscos final.
Reenviar lista de riscos (Figura 24 - Controle técnica Delphi) - Alternativo No passo 3 do cenário principal Filtrar lista de riscos, o usuário opte por reenviar a lista de riscos para ser reavaliada pela equipe: 1. O usuário atualiza o status da identificação para “Fase 2”. 2. O sistema grava os dados. 3. O sistema reenvia a lista de risco para ser reavaliada.
Cancelar - Exceção
Caso o usuário cancele alguma ação: 1. O sistema não armazena os dados.
Exclusão de risco com comentários cadastrados – Exceção Caso o usuário solicite a exclusão de um risco que contém comentários cadastrados: 1. O sistema exclui primeiramente todos os comentários para o risco. 2. O sistema exclui o risco. 3. O sistema atualiza lista de riscos.
UC011 - Manter Empresa
Permite ao administrador manter os dados da empresa (Figura 15 - Manter Empresa).
• Requisitos:
82
RF13. O sistema deve permitir o cadastro, alteração e exclusão de empresas.
Pré-condição: O usuário deve ser administrador do sistema.
Tabela 12. Cenário UC011 - Manter Empresa
Incluir empresa - Principal 1. O usuário informa os dados da empresa. 2. O usuário confirma os dados da empresa. 3. O sistema armazena as informações no banco de dados.
Alterar Empresa – Alternativo 1. O sistema carrega os dados da empresa cadastrada. 2. O usuário altera os dados da empresa. 3. O usuário confirma a alteração. 4. O sistema armazena as informações no banco de dados.
Excluir Empresa – Alternativo 1. O sistema carrega os dados da empresa cadastrada. 2. O usuário seleciona a opção de excluir a empresa. 3. O sistema verifica se a empresa possui projeto ou funcionário cadastrado. 3. O sistema exclui os dados do banco de dados.
Cancelar - Exceção
Caso o usuário cancele alguma ação: 1. O sistema não armazena os dados.
Exclusão de empresa com projetos ou funcionários cadastrados – Exceção Caso o usuário solicite a exclusão de empresa que possua projeto ou funcionário cadastrado: 1. O sistema informa o usuário que a empresa não pode ser excluída pois possui projeto ou funcionário cadastrado, dependendo do caso. 2. O sistema não executa a operação.
UC012 - Manter Funcionário
Permite ao administrador manter os dados dos funcionários (Figura 16 - Manter
Funcionário).
• Requisitos:
RF14. O sistema deve permitir o cadastro, alteração e exclusão de funcionários.
Pré-condição: O usuário deve ser administrador do sistema; A empresa que o funcionário
trabalha deve estar criada.
Pós-condição: Funcionário deve ser criado.
83
Tabela 13. Cenário UC012 - Manter Funcionário
Incluir Funcionário - Principal 1. O usuário informa os dados do usuário. 2. O usuário confirma os dados do usuário. 3. O sistema grava armazena as informações no banco de dados.
Alterar Funcionário – Alternativo 1. O sistema carrega os dados do funcionário cadastrado. 2. O usuário altera os dados do funcionário. 3. O usuário confirma a alteração. 4. O sistema armazena as informações no banco de dados.
Excluir Funcionário – Alternativo 1. O sistema carrega os dados do funcionário cadastrado. 2. O usuário seleciona a opção de excluir funcionário. 3. O sistema exclui os dados do banco de dados.
Cancelar - Exceção
Caso o usuário cancele alguma ação: 1. O sistema não armazena os dados.
Exclusão de funcionário cadastrado como gerente ou autor de algum projeto– Exceção Caso o usuário solicite a exclusão de funcionário cadastrado como gerente ou autor de um projeto: 1. O sistema informa o usuário que o funcionário não pode ser excluído pois possui projeto atrelado a ele. 2. O sistema não executa a operação.
UC013 - Manter Projeto
Permite ao administrador manter os dados dos Projetos (Figura 17 - Manter Projeto).
• Requisitos:
RF15. O sistema deve permitir o cadastro, alteração e exclusão de projetos.
Pré-condição: O usuário deve ser administrador do sistema; A empresa do projeto deve estar
criada; O autor e o gerente do projeto devem ter seus cadastros de funcionário criados.
Pós-condição: Projeto deve ser criado.
Tabela 14. Cenário UC013 - Manter Projeto
Incluir Projeto - Principal 1. O usuário informa os dados do projeto. 2. O usuário confirma os dados do projeto. 3. O sistema grava armazena as informações no banco de dados.
84
Alterar Projeto – Alternativo 1. O sistema carrega os dados do projeto cadastrado. 2. O usuário altera os dados do projeto. 3. O usuário confirma a alteração. 4. O sistema armazena as informações no banco de dados.
Excluir Projeto – Alternativo 1. O sistema carrega os dados do projeto cadastrado. 2. O usuário seleciona a opção de excluir projeto. 3. O sistema exclui os dados do banco de dados.
Cancelar - Exceção
Caso o usuário cancele alguma ação: 1. O sistema não armazena os dados.
Exclusão de projeto cujo processo de gerenciamento de riscos já foi iniciado – Exceção Caso o usuário solicite a exclusão de um projeto cujo o processo de gerenciamento de riscos já foi iniciado: 1. O sistema informa o usuário que o projeto não pode ser excluído pois seu processo de gerenciamento de riscos já foi iniciado. 2. O sistema não executa a operação.
