Uma Ferramenta de Gerenciamento de Riscos em Projetos de Desenvolvimento de Software

Transcrição

1 UNIVERSIDADE DO VALE DO RIO DOS SINOS CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE INFORMÁTICA Uma Ferramenta de Gerenciamento de Riscos em Projetos de Desenvolvimento de Software Fernando Lutz Prof. Luís Felipe Schilling Orientador Monografia submetida como requisito parcial para a obtenção do título de Bacharel em Informática. São Leopoldo, novembro de 2006

2 Não é importante ser melhor do que alguma outra pessoa, mas ser melhor do que ontem. (Jigoro Kano) A mente que se abre a uma nova idéia jamais volta ao seu tamanho original. (Albert Einstein) 2

3 Agradecimentos Este trabalho não é resultado de um esforço individual. Várias pessoas participaram direta ou indiretamente para que ele chegasse ao seu término, por isso quero deixar aqui o meu sincero agradecimento. Agradeço aos professores da Unisinos, pelo inestimável conhecimento recebido e compartilhado na área de Sistemas de Informação. Ao meu orientador Luís Felipe Schilling, por ter me conduzido nesse trabalho. A minha família, especialmente aos meus pais Valdomiro e Hedi, e ao meu irmão Vanderlei pelo esforço e dedicação na formação de meu caráter e construção de meus valores, além de estarem comigo ao longo da minha vida. A minha amada Tatiane, pelo amor, carinho e companheirismo que têm me proporcionado, além de paciência e auxílio durante esta longa jornada. Aos amigos de curso, pelo companheirismo e ajuda. Também agradeço a Deus, por me conceder saúde e forças para conseguir vencer mais esta etapa de minha vida. Em fim, um grande abraço a todos que tive a felicidade de conviver durante a minha passagem pela Unisinos. A todos o meu muito obrigado. 3

4 Resumo O desenvolvimento de software é geralmente repleto de riscos, com problemas que ocasionam o aumento de custos, os atrasos de cronogramas ou entrega dos produtos com baixa qualidade. Embora alguns riscos não possam ser completamente resolvidos, grande parte pode ser controlada através de ações de prevenção. A área de gerência de projetos que trata com esses riscos mesmo antes que eles ocorram é a gerência de riscos, sendo considerada pelos autores da área, de grande importância para o sucesso dos projetos. O gerenciamento de riscos visa, sobretudo a identificação, a análise e a definição de respostas aos riscos do projeto. Levando em conta esse cenário, esse trabalho apresenta um estudo sobre a área de gerência de projetos, com foco em gerência de riscos. Com base na pesquisa realizada, o trabalho apresenta o desenvolvimento de um protótipo de uma ferramenta de apoio aos processos de gerenciamento de riscos para projetos de desenvolvimento de software. Palavras-chave: Gerência de riscos, gerência de projetos, desenvolvimento de software. 4

5 Abstract The software development is generally full of risks, with problems that can cause a raise of costs, schedule delays, or delivery of low quality products. Although some risks cannot be avoided, some of them can be controlled through preventive actions. The project management area which deals with this risks even before they occur, is the risk management area, which is considered by the authors to have a great importance for the success of the projects. The risk management aims, at over all, the identification, analysis and definition of answers to the project risks. Taking this scenario in account, this work presents a study about the project management area, with focus on risk management. Based on research done, this work also presents the development of a prototype of a supporting tool to the process of risk management on software development projects. Keywords: Risk management, project management, software development. 5

6 Índice Agradecimentos Resumo Abstract Lista de figuras... 8 Lista de tabelas Lista de abreviaturas Introdução Objetivos do Trabalho Objetivo Geral Objetivos Específicos Metodologia Classificação da Pesquisa Modelo de pesquisa Estrutura do Trabalho Revisão Bibliográfica Gerenciamento de Projetos Projeto Ciclo de Vida do Projeto PMI Project Management Institute Gerenciamento de Projetos Processos do Gerenciamento de Projetos Áreas de Conhecimento Gerenciamento de Riscos Definição de Risco Gerenciamento de Riscos Importância e benefícios Categorias de Riscos Gerenciamento de Riscos no PMBOK Gerenciamento de Riscos no CMMI Gerenciamento de Riscos no RUP Comparação dos Modelos / Metodologias de GR Ferramentas de Gerenciamento de Riscos RiskTrak Comparativo das Ferramentas Desenvolvimento da Ferramenta de Gerenciamento de Riscos Visão Geral Características do Protótipo Modelagem

7 4.3.1 Modelagem UML Seleção da Ferramenta Case Modelagem dos Casos de Uso Especificação dos Casos de Uso Modelagem de Classes Implementação Tecnologia Mapeamento Objeto-Relacional Criação das Classes Bases Protótipo Manutenção de usuário Permissão aos usuários Manutenção de projeto Estrutura analítica de risco Planejamento da gerência de risco Riscos Comuns Identificação de risco Análise de risco Simular o projeto Planejamento de resposta ao risco Monitorar o risco Relatório dos maiores riscos Gráfico de riscos por grupo Gráfico de andamento dos riscos Programa de Instalação Manual do Usuário Resultados obtidos Considerações Finais Propostas de trabalhos futuros Bibiografia Anexos

8 Lista de Figuras Figura 1 Passos do trabalho Figura 2 Exemplo de ciclo de vida de projeto (PMI, 2004, p.21) Figura 3 Integração de grupos de processos (PMI, 2004, p. 68) Figura 4 Exemplo de uma EAR (PMI, 2004, p.244) Figura 5 Processos de Gerenciamento de Riscos (PMI, 2004) Figura 6 Resultados da simulação de risco de custo (PMI, 2004, p.259) Figura 7 Estrutura do RUP - Extraído de KRUTCHEN (2003) Figura 8 Tela com lista de riscos no RiskTrak Figura 9 Tela de definição do risco no RiskTrak Figura 10 Tela da 44 Figura 11 Atores do Sistema Figura 12 Diagrama de pacotes do sistema Figura 13 Diagrama de caso de uso do pacote de administração Figura 14 Diagrama de caso de uso do pacote de segurança Figura 15 Diagrama de caso de uso do pacote de negócio parte I Figura 16 Diagrama de caso de uso do pacote de negócio parte II Figura 17 Diagrama de caso de uso do pacote de negócio parte III Figura 18 Diagrama de classes do sistema Figura 19 Exemplo de cadastro (modo de pesquisa) Figura 20 Exemplo de cadastro (modo de edição) Figura 21 Protótipo Tela principal Figura 22 Protótipo Manutenção de usuário Figura 23 Protótipo Permissão ao usuário Figura 24 Protótipo Manutenção de projeto Figura 25 Protótipo EAR Figura 26 Protótipo Planejamento da gerência de risco Figura 27 Protótipo Cadastro de risco comum Figura 28 Protótipo Identificação de risco Figura 29 Protótipo Importar riscos Figura 30 Protótipo - Análise de risco Figura 31 Protótipo Simulação do Projeto

9 Figura 32 Protótipo Gráfico da Simulação de Custo Figura 33 Protótipo Planejamento de resposta ao risco Figura 34 Protótipo Exportar atividades para o Project Figura 35 Protótipo Monitoramento de risco Figura 36 Protótipo Relatório dos maiores riscos Figura 37 Protótipo Gráfico de riscos por grupo Figura 38 Protótipo Gráfico de andamento dos riscos Figura 39 Programa de Instalação do ProRisk Figura 40 Manual do Usuário Figura 41 Conteúdo do CD em anexo

10 Lista de Tabelas Tabela 1 Mapeamento dos processos de gerenciamento de projeto Adaptado PMI (2004, p. 70) Tabela 2 Princípios básicos da gerência de risco (HIGUERAG, 1994) Tabela 3 Taxonomia de risco de software (SEI, 1993) Tabela 4 Entradas, técnicas e saídas dos processos da gerência de risco (PMI, 2004) Tabela 5 Avaliação dos impactos do risco nos objetivos do projeto Adaptado (PMI, 2004, p.245) Tabela 6 Matriz da probabilidade/impacto do risco - Adaptado PMI (2004, p.252).32 Tabela 7 Estimativas de custo coletadas durante a entrevista sobre riscos (PMI, 2004) Tabela 8 Áreas de Processo do CMMI (SEI, 2002) Tabela 9 Distribuição das áreas chaves nos processos do CMMI (SEI, 2002) Tabela 10 Comparação dos modelos de gerenciamento de riscos Tabela 11 Comparação entre as ferramentas de gerenciamento de riscos Tabela 12 Exemplo de Caso de Uso Tabela 13 Comparação do ProRisk com outras ferramentas... 73

11 Lista de Abreviaturas CMMI EAP EAR GP GR PMBOK PMI PMP RUP SEI UML VME Capability Maturity Model Integration Estrutura analítica do projeto Estrutura analítica de risco Gerência de Projetos Gerência de riscos Project Management Body of Knowledge Project Management Institute Project Management Professional Rational Unified Process Software Engineering Institute Unified Modeling Language Valor monetário esperado 11

12 1 Introdução A gerência de projetos tem cada vez mais se tornado um assunto de grande importância para as organizações e para sua capacidade de sobrevivência (DINSMORE, 2005). O mundo está numa era de muitas mudanças, como a globalização do mercado, o acirramento da concorrência e a evolução tecnológica, o que torna o gerenciamento de projetos de forma eficiente um dos grandes desafios para os executivos modernos (KERZNER, 2006). Um projeto é um empreendimento único, com início e fim definidos, que utiliza recursos limitados e é conduzido por pessoas, visando atingir metas e objetivos predefinidos estabelecidos dentro de parâmetros de custo, prazo e qualidade (PMI, 2004). Por se tratar de um empreendimento único, cada projeto está exposto a incertezas das mais variadas origens, principalmente, os que envolvem tecnologia. O desenvolvimento de software é uma atividade que particularmente envolve riscos, envolvendo inúmeros fatores que são imprevisíveis e de difícil controle, como inovações tecnológicas e mudanças constantes nos requisitos do cliente, dentre muitos outros (KENDRICK, 2003). Esses riscos fazem com que grande parte dos projetos exceda o prazo e os orçamentos previstos, além de não atender às expectativas do cliente em termos de funcionalidades e qualidade. Segundo estudo realizado pelo Standish Group (2004), apenas 29% dos projetos de software são concluídos no prazo e dentro do orçamento, com todos os requisitos e as funcionalidades originalmente especificados e 18% são cancelados antes de sua conclusão. Diante desse cenário, um gerenciamento eficaz tem-se evidenciado como de fundamental importância para o sucesso de projetos de software (DINSMORE, 2005). Uma vez que a incerteza é inerente a esse tipo de projeto, o gerenciamento de riscos está se tornando cada vez mais relevante nesse contexto, sendo considerado parte integrante de um bom gerenciamento e fundamental para conseguir bons resultados (COOPER, 2005). O gerenciamento de riscos é uma área de grande interesse na atualidade, sendo tratado por muitos autores, associações de gerenciamento de projetos e instituições governamentais de todo o mundo (COOPER, 2005). Muitos modelos estão sendo desenvolvidos. Nesse trabalho serão abordados os modelos PMBOK (PMI, 2004), CMMI (SEI, 2002) e RUP (2003). O problema que motivou a realização desse trabalho é a importância do tema, a escassez de ferramentas específicas para gerenciamento de riscos existentes no mercado e a dificuldade de acesso a essas ferramentas, devido a seu alto custo. 12

13 1.1 Objetivos do Trabalho Objetivo Geral O objetivo principal desse trabalho é desenvolver um protótipo de uma ferramenta de apoio aos processos de gerenciamento de riscos em projetos de desenvolvimento de software Objetivos Específicos Os objetivos específicos desse trabalho são: Analisar o referencial teórico sobre gerência de projetos e gerência de riscos; Comparar as metodologias de gerência de riscos estudadas, mostrando como e onde essas práticas se relacionam e como podem oferecer os meios para desenvolvimento da área de gerência de projetos; Estudar ferramentas disponíveis no mercado para gerência de riscos, bem como suas particularidades e o suporte que elas proporcionam ao gerente de projetos; Realizar a análise e o projeto da ferramenta; Desenvolver a ferramenta proposta; Documentar a ferramenta. 1.2 Metodologia A seguir é descrita a metodologia utilizada para permitir o alcance do objetivo desta monografia Classificação da Pesquisa Esse trabalho, busca através da utilização de um método científico uma proposta de solução de uma ferramenta para gerenciamento de riscos. Segundo Andrade (2001), pesquisa é um processo formal e sistemático de desenvolvimento do método científico. O objetivo fundamental da pesquisa é descobrir respostas para problemas mediante o emprego de procedimentos científicos. Uma pesquisa pode ser classificada em diversos tipos em função da natureza (área da ciência), dos objetivos (exploratória, descritiva ou explicativa) e dos objetos (bibliográfica, laboratório, campo). A cada tipo de pesquisa são aplicados métodos e técnicas diferenciadas. Segundo as classificações definidas por Andrade (2001), a pesquisa desse trabalho envolve uma fase exploratória que tem como finalidade entender o problema e desenvolver um modelo que auxilie pesquisas futuras. Essa classificação foi obtida em função da necessidade de familiarização do autor com o problema de pesquisa para o desenvolvimento da ferramenta, bem como do aprofundamento das teorias relevantes ao tema estudado. Como o objetivo principal do trabalho é o desenvolvimento de uma ferramenta, a seguir serão apresentadas quatro abordagens metodológicas possíveis e geralmente aceitáveis a área de Sistemas de Informação e Engenharia de Software, criadas por Morrison e Goerge (1995). Esses autores atribuem à pesquisa nesta área todos os 13

14 aspectos relativos ao processo de desenvolvimento de software, incluindo formulação, implementação, descrição, evolução, modelagem e avaliação de software. As metodologias são essas: a) Pesquisa formulativa - envolvendo desenvolvimento e refinamento de teorias, modelos ou frameworks que orientam atividades de pesquisa e suportam progressos científicos através de mudança de paradigma; b) Pesquisa avaliativa - envolvendo metodologias que aplicam método científico e normalmente consistem de formulação de teorias ou modelos, ou observação seguida de formulação de hipóteses e teste; c) Pesquisa descritiva - em que teorias ou modelos são desenvolvidos e descritos para estabelecer a entrada para desenvolvimento de unidades de teorias, suas leis de interação, estados do sistema e limites dos modelos; d) Pesquisa de desenvolvimento - que envolve geração de conhecimento para explicação ou solução de problemas genéricos. Sendo assim, de acordo com Morrison e Goerge (1995) a pesquisa desse trabalho abrange duas abordagens: a descritiva e a de desenvolvimento. A metodologia descritiva por apresentar as especificações, os processos de desenvolvimento, os diagramas, os modelos de dados e o protótipo da ferramenta proposta; e a metodologia de desenvolvimento devido à criação da ferramenta de gerenciamento de riscos. Ainda, nesta abordagem estão incluídas as metodologias próprias de desenvolvimento de software, em que foram considerados do processo de software (ou ciclo de vida de software) e o método orientado a objetos de desenvolvimento de software Modelo de pesquisa O modelo de pesquisa utilizado na realização dessa monografia é explicado através da figura abaixo, que ilustra a seqüência de atividades desenvolvidas. Os passos metodológicos são descritos a seguir. 1. Revisão bibliográfica 2. Análise e comparação de ferramentas de GR 3. Análise e projeto da ferramenta 6. Considerações finais 5. Avaliação da ferramenta 4. Desenvolvimento da ferramenta Figura 1 Passos do trabalho 14

15 1. Revisão bibliográfica A primeira etapa realizada para esse trabalho foi a revisão bibliográfica. Essa revisão foi dividida em dois grupos de estudo: gerência de projetos e gerência de riscos. 2. Análise e comparação de ferramentas de gerência de riscos Nessa etapa foi realizado um estudo sobre as ferramentas de gerência de riscos disponíveis no mercado e um comparativo entre elas. Esta análise teve como objetivo sustentar, de forma mais consistente, a necessidade do desenvolvimento da ferramenta criada nesse trabalho. 3. Análise e projeto da ferramenta Nesse passo foi realizado a análise e projeto do sistema baseado na notação UML - Unified Modeling Language (BOOCH, 2005). Esta etapa teve como objetivo especificar e diagramar as funcionalidades e necessidades da ferramenta. 4. Desenvolvimento da ferramenta Uma vez realizado a análise e o projeto foi realizado o desenvolvimento do protótipo da ferramenta a partir dos requisitos levantados. Como parte complementar ao desenvolvimento, foi elaborada uma breve documentação sobre a utilização e instalação da ferramenta, para guiar os usuários do sistema. 5. Avaliação da ferramenta O passo seguinte foi a avaliação da ferramenta. Essa avaliação teve como objetivo verificar a usabilidade e utilidade da ferramenta para gerenciar os riscos em projetos de desenvolvimento de software. 6. Considerações finais O último passo realizado foi elaboração das considerações finais sobre o trabalho realizado, bem como as sugestões para trabalhos futuros. 1.3 Estrutura do Trabalho Esse trabalho é composto por cinco capítulos: Capítulo I Introdução, objetivos e fundamentos metodológicos; Capítulo II Fundamentos teóricos sobre gerência de projetos e gerência de riscos; Capítulo III Ferramentas de gerenciamento de riscos; Capítulo IV Desenvolvimento da ferramenta; Capítulo V Conclusões. 15

16 2 Revisão Bibliográfica Nesse capítulo são apresentadas as principais definições e as características sobre gerenciamento de projetos e gerenciamento de riscos, de forma a situar o leitor nos conceitos relativos ao mesmo. 2.1 Gerenciamento de Projetos A seguir são apresentadas algumas características de um projeto e de seu ciclo de vida, além dos processos e áreas de conhecimento da gerência de projetos segundo o PMBOK (PMI, 2004) Projeto Segundo Prado (2003), projeto é um esforço temporário (possui data de início e de término) com o objetivo de produzir um bem (produto ou serviço) com características peculiares que o diferenciam de outros. Vargas (2002) faz a seguinte definição: Projeto é um empreendimento não repetitivo, caracterizado por uma seqüência clara e lógica de eventos, com início, meio e fim, que se destina a atingir um objetivo claro, definido, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade (VARGAS, 2002, p. 8). O Project Management Institute (PMI, 2004) resume essas definições: Projeto é um esforço temporário realizado de forma progressiva para criar um serviço ou produto único; Do fato de projetos serem temporários, decorre que cada projeto tem um início e um fim, bem definidos. Chega-se ao fim de um projeto quando os seus objetivos foram alcançados, ou quando se torna claro que os objetivos do projeto não serão ou não poderão ser atingidos. O projeto então é encerrado. O fato dos projetos serem temporários não necessariamente significa que sejam curtos; Os projetos possuem uma elaboração progressiva por serem únicos e pelas características peculiares que os distinguem. A elaboração progressiva das características do produto precisa ser cuidadosamente coordenada com a correta definição do escopo do projeto Ciclo de Vida do Projeto As organizações que desenvolvem projetos normalmente dividem o projeto em várias fases para obter um controle melhor e uma ligação com os processos operacionais. Esse conjunto de fases é denominado ciclo de vida do projeto (PRADO, 2003). 16

17 O ciclo de vida do projeto serve para definir o início e o fim de um projeto (PMI, 2004). Embora muitos ciclos de vida de projetos tenham nomes similares com produtos semelhantes, poucos são idênticos. Alguns possuem quatro ou cinco fases, mas outros podem vir a ter nove ou mais fases. Mesmo numa área de aplicação podem existir variações significativas. O ciclo de vida de projetos de organizações de desenvolvimento de software pode ser composto por uma fase de projeto, enquanto outra organização pode instituir fases separadas para requisitos, análise, projeto, implementação, teste e implantação. Subprojetos de um mesmo projeto também podem possuir diferentes ciclos de vidas de projeto (VARGAS, 2002). Os ciclos de vida dos projetos geralmente definem qual trabalho técnico deve ser realizado em cada fase e quem deve estar envolvido em cada fase. A maioria das descrições de ciclo de vida do projeto apresentam algumas características em comum (PMI, 2004): O custo e a quantidade de pessoas integrantes da equipe são baixos no início do projeto, sofrem incrementos no decorrer do mesmo e se reduzem drasticamente com a chegada de seu término. Esse modelo é ilustrado na Figura 2. No início do projeto, a probabilidade de terminá-lo com sucesso é baixa e, portanto, o risco e a incerteza são altos. Normalmente a probabilidade de sucesso vai aumentando à medida que o projeto caminha em direção ao seu término. A capacidade das partes envolvidas de influenciar as características finais do produto do projeto e o seu custo final é alta no início e vai se reduzindo com o andamento do projeto. Isso acontece, principalmente, porque o custo de mudanças e correção de erros geralmente aumenta à medida que o projeto se desenvolve. Figura 2 Exemplo de ciclo de vida de projeto (PMI, 2004, p.21) 17

18 2.1.3 PMI Project Management Institute O PMI é uma instituição sem fins lucrativos fundada em 1969, com sede na Pensilvânia, Estados Unidos. Foi o pioneiro na regulamentação e distribuição do conhecimento da disciplina de gerenciamento de projetos. Sua missão é promover o profissionalismo e desenvolver o estado da arte na gestão de projetos. O PMI tem publicado um documento chamado PMBOK Guide (A guide to The Project Management Book of Knowledge), um guia que contém as melhores práticas em gestão de projetos (DINSMORE, 2005). O PMI possui atualmente mais de membros em todo o mundo e já certificou mais de PMP Project Management Professional. No Brasil, possui unidades regionais, conhecidas como chapters nos seguintes locais: São Paulo, Rio de Janeiro, Minas Gerais, Paraná, Rio Grande do Sul, Brasília, Pernambuco, Amazonas, Bahia, Santa Catarina, Espírito Santo, Ceará, Maranhão e Goiás (DINSMORE, 2005) Gerenciamento de Projetos O Gerenciamento de Projetos foi objeto de estudo de vários autores e pesquisadores, que apresentaram suas visões e definições sobre a área (DINSMORE, 2005; KERZNER, 2006; VARGAS, 2002; VERZUH, 2000). Esses autores compartilham do mesmo conceito a estruturação do gerenciamento de projetos por meio de processos que está alinhada ao conceito divulgado pelo PMI (2004). Preocupado com a padronização de conceitos, mas também com a aplicação prática, o PMI (2004, p. 8) descreve o gerenciamento de projetos como [...] a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto, a fim de atender aos seus requisitos. Enfatiza que o gerenciamento de projetos é realizado através da aplicação e da integração dos seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução, monitoramento e controle e encerramento (PMI, Ibid.). Segundo o PMI (2004), gerenciar um projeto inclui: A identificação das necessidades; O estabelecimento de objetivos claros e alcançáveis; O balanceamento de demandas conflitantes de qualidade, escopo, tempo e custo; A adaptação das especificações, dos planos e da abordagem às diferentes preocupações e expectativas das diversas partes interessadas. O gerenciamento de projetos fornece a empresa ferramentas poderosas que melhoram a habilidade de planejamento, organização, execução e controle das atividades de maneira a conseguir atingir os resultados esperados, dentro do custo e prazo previstos, mesmo para projetos de alta complexidade (DINSMORE, 2005). Kerzner (2006) complementa que, para ser bem sucedida, a gestão de projetos necessita uma coordenação e um fluxo de trabalho horizontal (e não mais vertical como na gerência tradicional utilizada em décadas passadas), com destaque na comunicação, no aumento da produtividade, da eficácia e da eficiência, com destaque especial às atribuições e ao papel do gerente de projeto. 18

19 2.1.5 Processos do Gerenciamento de Projetos Conforme destacado no tópico anterior, alguns autores abordam o gerenciamento de projetos segundo um enfoque de processos (DINSMORE, 2005; KERZNER, 2006; PMI, 2004; VARGAS, 2002; VERZUH, 2000). Verzuh (2000) apresenta uma estruturação dos projetos por meio dos seguintes processos: definição, planejamento, execução e encerramento. Destaca que estes se repetem ao longo dos vários estágios do ciclo de vida do projeto. Kerzner (2006) também trabalha essa estruturação por processos e inclui a importante discussão sobre o papel da cultura da organização no processo de gerenciamento de projetos. Destaca que dificilmente duas empresas gerenciarão seus projetos da mesma maneira e que, por isso, a implementação do gerenciamento de projetos deve ter por referência a cultura de cada organização. Segundo o PMI (2004, p ), o gerenciamento de projetos é realizado através de processos, usando conhecimento, habilidades, ferramentas e técnicas do gerenciamento de projetos que recebem entradas e geram saídas. Processo é definido como um conjunto de ações e atividades inter-relacionadas realizadas para obter um conjunto pré-especificado de produtos, resultados ou serviços. Os diferentes processos do gerenciamento de projetos, definidos com base em boas práticas 1, são apresentados no PMBOK (PMI, 2004, p.41) com seus objetivos e integração. Esses processos encontram-se reunidos em cinco grupos: Grupo de processos de iniciação: define e autoriza o projeto ou uma fase do projeto; Grupo de processos de planejamento: define e refina os objetivos e planeja as ações necessárias para atingir os objetivos e o escopo para os quais o projeto foi concebido; Grupo de processos de execução: integra pessoas e outros recursos visando à execução do plano de gerenciamento do projeto; Grupo de processos de monitoramento e controle: mede e monitora regularmente o progresso do projeto para identificar variações em relação ao plano, de forma a possibilitar a tomada de ações corretivas quando necessário, sempre com o intuito de atender aos objetivos do projeto; Grupo de processos de encerramento: formaliza a aceitação final do produto, serviço ou resultado e conduz o projeto, ou uma fase, a um final ordenado. Os grupos de processos da gerência de projetos não ocorrem de maneira isolada ou descontínua. Esses grupos são formados por atividades que se sobrepõe e ocorrem com intensidade variável durante as fases do projeto. A figura a seguir apresenta a sobreposição e nível de interação dos grupos de processos ao longo do ciclo de vida do projeto. 1 Boa prática significa que [...] existe acordo geral de que a aplicação desses processos de gerenciamento de projetos tem demonstrado aumentar a chance de sucesso em uma ampla série de projetos (PMI, 2004, p. 38). 19

20 Figura 3 Integração de grupos de processos (PMI, 2004, p. 68) Áreas de Conhecimento O Gerenciamento de Projetos, de acordo com o PMBOK (PMI, 2004), identifica e descreve as principais áreas de conhecimento e práticas. Cada uma destas áreas (no total de 9) é descrita através de processos (no total de 44) e refere-se a um aspecto a ser considerado dentro da gerência de projetos. As áreas de conhecimento de gerenciamento são: integração, escopo, tempo, custo, qualidade, recursos humanos, comunicação, risco e contratação. O gerenciamento do escopo descreve os processos necessários para garantir que o projeto atenda todo o trabalho requerido, e somente o requerido, para completar o projeto com sucesso. O objetivo principal é definir e controlar o que está ou não incluído no projeto (DINSMORE, 2005; PMI, 2004). O gerenciamento do tempo descreve os processos necessários para garantir que o projeto termine dentro do prazo previsto. Kerzner (2006) cita que o ambiente de gerenciamento do tempo é extremamente turbulento, sendo composto por várias reuniões, escrita de relatórios, resolução de conflitos, planejamento e replanejamento contínuo, comunicação com o cliente e gerenciamento de crises. O correto gerenciamento do tempo é de vital importância para o sucesso do projeto (DINSMORE, 2005; PMI, 2004). O gerenciamento do custo descreve os processos necessários para garantir que o projeto termine dentro do orçamento previsto. No projeto, várias atividades afetam os custos do projeto e, dessa forma, planejamento e controle dos custos são fundamentais (DINSMORE, 2005; PMI, 2004). O gerenciamento da qualidade descreve os processos necessários para garantir que o projeto esteja em conformidade com seus objetivos iniciais, solicitados pelo cliente ou contratante. O projeto tem qualidade quando é concluído em conformidade aos requisitos e adequado ao uso (DINSMORE, 2005; PMI 2004). O gerenciamento de recursos humanos descreve os processos necessários para otimizar a utilização das pessoas envolvidas no projeto. É uma área muitas vezes subjetiva e complexa, exigindo constante pesquisa, sensibilidade e muita vivência do dia-a-dia para saber lidar com o ser humano (DINSMORE, 2005; PMI 2004). 20

21 O gerenciamento das comunicações descreve os processos necessários para garantir a geração, a captura, a distribuição, o armazenamento e a pronta apresentação das informações do projeto para que sejam feitas de forma adequada e no tempo certo. Essa área é freqüentemente ignorada pelos gerentes de projeto. No entanto, nos projetos concluídos com sucesso, o gerente gasta 90% do seu tempo envolvido com algum tipo de comunicação (formal, informal, verbal, escrita) (DINSMORE, 2005; PMI 2004). O gerenciamento de riscos descreve os processos que dizem respeito à identificação, à análise e à resposta aos riscos do projeto. Alguns autores citam que gerenciar projetos é gerenciar riscos. O gerenciamento de riscos é muito importante para o sucesso do projeto e é composto pelos seguintes processos: planejamento da gerência de risco, identificação dos riscos, análise qualitativa de riscos, análise quantitativa de riscos, desenvolvimento das respostas aos riscos e controle e monitoramento de riscos (DINSMORE, 2005; PMI 2004). Na próxima seção desse trabalho, o gerenciamento de riscos será mais detalhado. O gerenciamento de aquisições descreve os processos que compram ou adquirem produtos, serviços ou resultados, além dos processos de gerenciamento de contratos. Essa área é discutida do ponto de vista do comprador na relação comprador fornecedor (PMI, 2004). O gerenciamento da integração descreve os processos necessários para garantir que os diversos elementos do projeto sejam corretamente coordenados. A integração envolve tomada de decisão e escolhas diretamente ligadas aos objetivos do projeto e aos processos das etapas de desenvolvimento e execução do plano do projeto, assim como ao processo de controle de alterações (PMI, 2004). A não execução de processos de uma área afeta negativamente o projeto, pois esse é um esforço integrado. Por exemplo, uma mudança de escopo quase sempre afeta o custo do projeto. Entretanto, ela pode ou não afetar a moral da equipe e a qualidade do produto (PMI, 2004). A Tabela 1 apresenta o mapeamento dos processos de gerenciamento de projetos e a sua associação aos grupos de processos e às áreas de conhecimento de acordo com o PMI (2004, p. 70). 21

22 Grupos de processos de gerenciamento de projetos Área de conhecimento Iniciação Planejamento Execução Monitoramento e controle Gerenciamento da integração Gerenciamento do escopo Gerenciamento de tempo Gerenciamento de custos Gerenciamento da qualidade Gerenciamento de recursos humanos Gerenciamento das comunicações Gerenciamento de riscos Gerenciamento das aquisições Desenvolvimento do termo de abertura do projeto Desenvolvimento da declaração de escopo preliminar do projeto Desenvolvimento do plano de gerenciamento do projeto Planejamento do escopo Definição do escopo Criação da EAP Definição da atividade Seqüenciamento de atividades Estimativa de recursos da atividade Estimativa de duração da atividade Desenvolvimento do cronograma Estimativa de custos Orçamento Planejamento da qualidade Planejamento de Recursos humanos Planejamento das comunicações Planejamento do GR Identificação de riscos Análise qualitativa de riscos Análise quantitativa de riscos Planejamento de respostas a riscos Planejamento das compras e aquisições Planejamento das contratações Orientação e gerenciamento da execução do projeto Realização da garantia da qualidade Contratação ou mobilização da equipe do projeto Desenvolvimento da equipe do projeto Distribuição das informações Solicitação das respostas de fornecedores Seleção de fornecedores Monitoramento e controle do trabalho do projeto Controle integrado de mudanças Verificação do escopo Controle do escopo Controle do cronograma Controle de custos Realização do controle da qualidade Gerenciamento da equipe do projeto Relatório de desempenho Gerenciamento das partes interessadas Monitoramento e controle de riscos Administração de contrato Tabela 1 Mapeamento dos processos de gerenciamento de projeto Adaptado PMI (2004, p. 70) Encerramento Encerramento do projeto Encerramento de contrato 22

23 2.2 Gerenciamento de Riscos A seguir são apresentados algumas das principais definições, características e benefícios do gerenciamento de riscos, além da visão apresentada pelos modelos PMBOK (PMI, 2004), CMMI (SEI, 2002) e RUP (2003) Definição de Risco O SEI (2002) define risco como a possibilidade de sofrer perda. Em desenvolvimento de projeto, a perda representa o impacto sobre o projeto em termos de diminuição da qualidade do produto final, aumento de custos, atraso na conclusão ou fracasso. Para Cooper (2005), risco é a exposição à incerteza, à probabilidade de algo que poderá acontecer que terá impacto nos objetivos do projeto. Risco envolve dois fatores: a probabilidade de ocorrência e as suas conseqüências (KENDRICK, 2003). Projetos de software possuem inúmeros fatores de riscos, como requisitos incertos, tecnologia desconhecida pela equipe, dependência de outros projetos, falta de documentação, cronograma irreal e baixa moral da equipe Gerenciamento de Riscos Segundo o PMBOK (PMI, 2004), o gerenciamento de riscos visa à identificação de problemas potenciais e de oportunidades antes que ocorram, com o objetivo de eliminar ou reduzir a probabilidade de ocorrência e o impacto de eventos negativos para os objetivos do projeto, além de potencializar os efeitos da ocorrência de eventos positivos. Segundo Verzuh (2000), a gerência de risco começou a ser largamente utilizada no século XX, principalmente, nas áreas de saúde, finanças e seguros de vida. Todos os projetos tratam riscos, pois o lucro depende do balanceamento entre as oportunidades e os riscos bem calculados. A idéia principal da gerência de risco é não aguardar passivamente até que um risco se materialize e se torne um problema ou acabe com o projeto, mas antecipar o que fazer com isso, ou seja, a equipe do projeto precisa possuir um comportamento próativo (ALENCAR, 2005). Cooper (2005) enfatiza que um bom gerenciamento de risco envolve: A participação efetiva dos stakeholders 2 nos processos; Ser integrada às outras áreas do gerenciamento do projeto; Iniciar no início do projeto; Ser contínua durante todo o ciclo de vida do projeto; Possuir planejamento. Complemento essa visão de Cooper (2005), a tabela 2 apresenta oito princípios básicos da gerência de risco num processo de desenvolvimento de software. Os princípios básicos da gerência de risco são os fatores norteadores das atividades que precisam ser desenvolvidas. 2 Termo em inglês que se refere a todos os interessados ou envolvidos no projeto. 23

24 Princípio Visão compartilhada do produto Trabalho em equipe Perspectiva global Visão antecipadora Comunicação aberta Gerenciamento integrado Continuidade do processo Acesso ao conhecimento Característica Compartilhamento da visão do produto com base em propósito comum, responsabilidade e comprometimento coletivo com o projeto; Foco em resultados. Trabalho cooperativo para atingir metas comuns; Concentração e disponibilização de talentos, habilidades e conhecimento. Visualização do desenvolvimento de software (definição, projeto e desenvolvimento); Reconhecimento do valor potencial das oportunidades e do impacto dos possíveis fatores adversos. Pensamento voltado para o futuro, identificação de incertezas, antecipação de possíveis desfechos, gerenciamento dos recursos e atividades do projeto. Facilitação da comunicação formal, informal e espontânea; Utilização de processos decisórios baseados em consenso que permitam valorizar opiniões individuais. A gerência de risco é parte integral e vital para a gerência de projetos; Adaptação dos métodos e ferramentas de gerência para a infraestrutura do projeto, respeitando-se a cultura. Identificação e gerência dos riscos executada rotineiramente em todas as fases do ciclo de vida do projeto. Amplo acesso ao conhecimento sobre gerência de riscos, domínio do problema e sobre o processo de desenvolvimento de software. Tabela 2 Princípios básicos da gerência de risco (HIGUERAG, 1994) Importância e benefícios A idéia de que a gerência de riscos é importante e deve ser integrada a gerência de projetos é consenso na literatura (DINSMORE, 2005; KEELLING, 2002; KERZNER, 2006; PMI, 2004; VARGAS, 2002; VERZUH, 2000). Segundo Dinsmore (2005), o gerenciamento de riscos é a melhor forma para antecipar ações, reduzir efeitos negativos e finalizar os projetos com sucesso. Executar projetos sem sua utilização é viver apagando incêndio, atrasando projetos e extrapolando custos. Para Vargas (2002), o que faz a gerência de projetos tão importante são fatores diversos, como o aumento da competitividade, o avanço da tecnologia e as condições econômicas, que fazem com que os riscos assumam proporções muitas vezes incontroláveis. Os benefícios da gerência de risco são claros, segundo Boehm (1997): "a gerência de risco é importante principalmente porque ajuda as pessoas a evitar desastres, evitar re-trabalho, evitar cancelamento de projetos e estimular uma situação de sucesso nos projetos de software 24

25 2.2.4 Categorias de Riscos As categorias de riscos representam uma forma de identificar sistematicamente os riscos e servem de base para a sua compreensão. As categorias de riscos visam a classificação dos riscos por áreas, de acordo com o perfil de cada risco (HELDMAN, 2002). Segundo o PMBOK (PMI, 2004), as categorias de riscos podem ser: Técnicos: envolve os riscos técnicos, tais como dificuldade de implementação, tecnologia complexa, problemas com desempenho, qualidade, etc. Gerência de projeto: problemas com a administração de projetos, tal como alocação precária de tempo e recursos, plano de projeto inadequado, etc. Organizacional: problemas como conflitos de recurso com outros projetos dentro da organização, competências mal definidas, etc. Externo: envolve os riscos sobre os quais a equipe de projeto não tem domínio, tal como mudanças nas leis, mudança de prioridades do responsável pelo projeto, etc. O uso dessas categorias ajuda a melhorar o processo de identificação de risco, pois estabelece uma descrição comum dos riscos para todos os envolvidos. Existem diversas maneiras de descrever as categorias de riscos. Uma delas é construir uma estrutura analítica de risco (EAR) que liste as categorias e sub-categorias, conforme exemplificado na figura 4, mas ela também pode ser uma simples listagem dos diversos aspectos do projeto (PMI, 2004). Figura 4 Exemplo de uma EAR (PMI, 2004, p.244) Na literatura existem alguns modelos de categorias de riscos, como é o caso das categorias criadas por Kangari (1989), Wideman (1998) e SEI (1993). A categorização de riscos criada pelo SEI, com o nome de taxonomia de riscos, é especifica para projetos de software, enquanto as outras são genéricas para qualquer tipo de projeto. 25

26 A taxonomia de riscos do SEI possui três categorias principais e diversas subcategorias, conforme tabela 3. A seguir uma descrição dessas três categorias principais: Engenharia de produto: compreende as atividades de engenharia de sistema e software relacionados ao desenvolvimento de um produto que satisfaçam os requisitos especificados e as expectativas do cliente; Ambiente de desenvolvimento: os métodos, os procedimentos e as ferramentas usados para o desenvolvimento de um produto; Restrições de programa: os fatores contratuais, organizacionais e operacionais contidos no desenvolvimento de software. Normalmente, esses riscos estão fora do domínio direto do gerente do projeto. Engenharia de produto 1. Requisitos a. Estabilidade b. Completeza c. Clareza d. Validade e. Viabilidade f. Precedente g. Escala 2. Projeto a. Funcionalidade b. Dificuldade c. Interface d. Desempenho e. Testabilidade f. Restrições de hardware g. Software não desenvolvido 3. Codificação e teste unitário a. Viabilidade b. Teste unitário c. Codificação e implementação 4. Teste e integração a. Ambiente b. Produto c. Sistema 5. Especialidade de engenharia a. Manutenibilidade b. Confiabilidade c. Segurança d. Proteção e. Fatores humanos f. Especificações Ambiente de desenvolvimento 1. Processo de desenvolvimento a. Formalidade b. Adequação c. Controle do processo d. Familiaridade e. Controle do produto 2. Desenvolvimento do sistema a. Capacidade b. Adequação c. Usabilidade d. Familiaridade e. Confiabilidade f. Suporte ao sistema g. Entregabilidade 3. Processo de gerência a. Planejamento b. Organização do projeto c. Experiência gerencial d. Interfaces de projeto 4. Métodos gerenciais a. Monitoramento b. Gerência pessoal c. Garantia da qualidade d. Gerência de configuração 5. Ambiente de trabalho a. Atitude para a qualidade b. Cooperação c. Comunicação d. Moral Restrições de programa 1. Recursos a. Cronograma b. Equipe c. Orçamento d. Facilidades 2. Contrato a. Tipo de contrato b. Restrições c. Dependências Tabela 3 Taxonomia de risco de software (SEI, 1993). 3. Interfaces de projeto a. Cliente b. Contratos associados c. Subcontratados d. Principal contratador e. Gerente corporativo f. Vendedores g. Políticos 26

27 2.2.5 Gerenciamento de Riscos no PMBOK O PMBOK divide a gerência de riscos em seis processos, representados na figura 5: Planejamento do gerenciamento de riscos; Identificação de risco; Análise qualitativa dos riscos; Análise quantitativa dos riscos; Planejamento da resposta ao risco; Monitoramento e controle de risco. Figura 5 Processos de Gerenciamento de Riscos (PMI, 2004) Cada um desses processos ocorre pelo menos uma vez ao longo do ciclo de vida do projeto e caracterizam-se por terem uma forte integração com processos de outras áreas de conhecimento (PMI, 2004). Assim como os processos das demais áreas de conhecimento, os seis processos da gerência de riscos do projeto também são compostos por entradas, técnicas e saídas. A tabela 4 apresenta quais são as entradas, as técnicas e as saídas de cada um dos processos que compõem a gerência de riscos, além do grupo de processo do ciclo de vida do projeto que o processo ocorre. 27

28 Processo Entradas Técnicas Saídas Planejamento da gerência de riscos (planejamento) Identificação dos riscos (planejamento) Análise qualitativa dos riscos (planejamento) Análise quantitativa dos riscos (planejamento) Planejamento de resposta aos riscos (planejamento) Monitoramento e controle dos riscos (monitoramento e controle) Fatores ambientais da empresa Ativos de processos organizacionais Declaração do escopo do projeto Plano de gerenciamento do projeto Fatores ambientais da empresa Ativos de processos organizacionais Declaração do escopo do projeto Plano de gerenciamento de riscos Plano de gerenciamento do projeto Ativos de processos organizacionais Declaração do escopo do projeto Plano de gerenciamento de riscos Registro de riscos Ativos de processos organizacionais Declaração do escopo do projeto Plano de gerenciamento de riscos Registro de riscos Plano de gerenciamento do projeto (cronograma e custo) Plano de gerenciamento de riscos Registro de riscos Plano de gerenciamento de riscos Registro de riscos Solicitações de mudança aprovadas Informações sobre o desempenho do trabalho Relatórios de desempenho Análise e reuniões de planejamento Revisões da documentação Técnicas de coleta de informações Análise da lista de verificação Análise das premissas Técnicas com diagramas Avaliação de probabilidade e impacto de riscos Matriz de probabilidade e impacto Avaliação da qualidade dos dados sobre riscos Categorização de riscos Avaliação da urgência Técnicas de representação e coleta de dados Análise quantitativa de riscos e técnicas de modelagem Estratégias para riscos negativos ou ameaças Estratégias para riscos positivos ou oportunidades Estratégia para ameaças e oportunidades Estratégia para respostas contingenciadas Reavaliação de riscos Auditorias de riscos Análise das tendências e da variação Medição do desempenho técnico Análise das reservas Reuniões de andamento Plano de gerenciamento de riscos Registro de riscos Registro de riscos (atualizações) Registro de riscos (atualizações) Registro de riscos (atualizações) Plano de gerenciamento de projeto (atualizações) Acordos contratuais relacionados a risco Registro de riscos (atualizações) Mudanças solicitadas Ações corretivas recomendadas Ações preventivas recomendadas Ativos de processos organizacionais (atualizações) Plano de gerenciamento do projeto (atualizações) Tabela 4 Entradas, técnicas e saídas dos processos da gerência de risco (PMI, 2004) 28

29 A seguir é apresentada uma descrição detalhada de cada um dos seis processos: Planejamento do Gerenciamento de Riscos O processo de planejamento do gerenciamento de risco tem como objetivo decidir como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto. O planejamento é fundamental para a possibilidade de sucesso dos outros processos (PMI, 2004). Como resultado desse processo é criado o plano de gerência de riscos, onde há descrição de como e com que pesos serão tratados cada um dos próximos processos da área de gerenciamento de risco (DINSMORE, 2005). O plano de gerência de riscos não possui um formato pré-estabelecido, mas possui uma definição bem clara quanto aos dados que deve conter. Entre outras definições, o plano de gerenciamento de risco deve indicar (PMI, 2004): Qual a metodologia será utilizada, ou seja, as abordagens, as ferramentas e as fontes de dados que podem ser usadas para executar o gerenciamento de riscos; As funções e as responsabilidades de cada membro da equipe de gerenciamento de riscos; O orçamento previsto para a equipe de gerenciamento de riscos; Com que freqüência será executado o processo de gerenciamento de riscos; Categorias de riscos; Definições de probabilidade e impacto: é o detalhamento das possibilidades de ocorrência de um evento de risco (probabilidade) e as conseqüências enfrentadas pelo projeto em decorrência do evento de risco; Matriz de probabilidade e impacto; Quais serão os níveis de tolerância a risco; O formato e o conteúdo do plano de resposta a riscos (não é o plano em si, mas como será estruturado o plano); O monitoramento dos riscos Identificação de Risco Esse processo, como o nome já diz, tem como função a identificação de riscos que podem vir a afetar o projeto, além de documentar as principais características de cada risco. Informações históricas possuem um papel muito interessante para esse processo, baseado nas lições aprendidas de projetos passados, pode-se ter novas identificações de riscos (PMI, 2004). Riscos podem ser identificados a partir de diversos aspectos ou áreas do projeto. Assim, é uma boa prática rever o conteúdo do plano de gerenciamento do projeto com esse enfoque. A estrutura analítica do projeto (EAP) é um componente essencial neste sentido (DINSMORE, 2005). Existem diversas técnicas para identificar riscos do projeto. Algumas dessas técnicas utilizadas são: 29

30 a) Brainstorming: o objetivo é obter uma lista de riscos que podem ser endereçados posteriormente nos processos de análise qualitativa e quantitativa de riscos. Segundo o PMBOK (2004), é provavelmente a técnica de identificação de risco mais freqüentemente utilizada. b) Delphi: tem como objetivo obter um consenso de especialistas em relação a determinado assunto, no caso, riscos. Especialistas em riscos são identificados, mas participam anonimamente. Um facilitador usa um questionário para solicitar idéias sobre riscos importantes. As respostas são apresentadas e circulam para a inserção de comentários adicionais. O consenso quanto aos principais riscos pode ser atingido com poucas rodadas, quando utilizado esse processo. Como vantagens temos que a técnica Delphi ajuda a reduzir desvios nos dados e que mantém o equilíbrio de influências dos especialistas. Como desvantagem, há uma dependência em relação ao questionário formulado pelo facilitador, cujo uso pode limitar a troca de idéias (DINSMORE, 2005). c) Entrevista com especialista: tem como primeiro passo a identificação dos entrevistados, a preparação da agenda e das perguntas que serão feitas durante a entrevista. Após esses preparativos, as entrevistas são conduzidas a partir das perguntas preparadas pelo entrevistador. As vantagens desse método são a obtenção de diversas visões dos riscos, pois os entrevistados podem ter perfis diferentes, contribuindo na identificação de diversos aspectos relacionados aos riscos, e a facilidade para a sua aplicação. Dentre as desvantagens, temos a necessidade do entrevistador definir as perguntas de modo que não limite a entrevista, e que esse método é fortemente dependente do entrevistado e do entrevistador (HELDMAN, 2002). d) Análise de pontos fortes, pontos fracos, oportunidades e ameaças (SWOT 3 ): consiste, inicialmente, em obter informações do ambiente e separá-las em questões internas (pontos fortes e pontos fracos) e externas (oportunidades e ameaças). Em seguida, determina-se se a informação que indica algo que irá ajudar a empresa a alcançar seus objetivos (um ponto forte ou uma oportunidade) ou se indica um obstáculo que deverá ser evitado ou minimizado para alcançar os resultados desejados (fraquezas e ameaças) (COOPER, 2005). e) Análise da lista de verificação: podem ser utilizadas na identificação de risco a partir de informação histórica e conhecimentos acumulados de projetos similares anteriores e de outras fontes de informação. Uma vantagem de utilizar uma lista de verificação é que a identificação de risco é rápida e simples. Uma desvantagem é que é impossível construir uma lista de verificação de riscos exaustiva, e o usuário pode ficar limitado às categorias ali apresentadas. Deve-se tomar cuidado em explorar itens que não aparecem na lista de verificação padrão se eles são relevantes para um determinado projeto. A lista de verificação deveria relacionar todos os tipos possíveis de riscos para o projeto. É importante rever essa lista como um passo formal no 3 Strengths, Weaknesses, Opportunities, Threats 30

31 procedimento de finalização de cada projeto, para melhorar a lista de riscos potenciais e sua descrição (COOPER, 2005). f) Análise de premissas: cada projeto é concebido e desenvolvido baseado em um conjunto de hipóteses, cenários ou premissas. A análise de premissas é uma técnica que explora a validade de premissas. Por meio dessa técnica, são identificados os riscos do projeto em termos de falta de acurácia, consistência ou completude de premissas (PMI, 2004). g) Diagrama de causa e efeito: esse diagrama é também conhecido como Ishikawa ou espinha de peixe sendo útil para identificar as causas dos riscos. Apresenta a relação entre os efeitos dos problemas e suas respectivas causas e mostram as causas possíveis para esses problemas e os efeitos que cada solução proposta terá sobre eles. A filosofia da análise causal é que se um erro ocorrer, ele irá acontecer novamente, ao menos que se faça alguma coisa para evitá-lo (HELDMAN, 2002). Todas essas técnicas constituem maneiras de identificar os riscos do projeto. É importante detectar todos os riscos tão logo quanto possível, pois quanto mais eficiente for o trabalho de identificação de riscos, melhor será o plano de respostas a eles (COOPER, 2005) Análise Qualitativa de Risco O principal objetivo da análise qualitativa é o de avaliar o impacto e a probabilidade dos riscos identificados e priorizar os riscos de acordo com o seu efeito potencial nos objetivos do projeto (HELDMAN, 2002). De acordo com o PMBOK (PMI, 2004), as principais ferramentas e técnicas utilizadas no processo de análise qualitativa de risco envolvem: probabilidade e impacto do risco e matriz da probabilidade/impacto do risco. A probabilidade do risco e suas conseqüências podem ser descritas em termos qualitativos tais como muito alta, alta, moderada, baixa e muito baixa. A probabilidade de risco é a probabilidade de um risco ocorrer. As conseqüências do risco são os efeitos nos objetivos do projeto se o evento de risco ocorre. Essas duas dimensões de risco são aplicadas para determinar eventos de risco específicos e não o risco do projeto. As análises de risco que usam probabilidade e conseqüências ajudam a identificar esses riscos que deveriam ser gerenciados agressivamente (PMI, 2004). Uma matriz pode ser construída para atribuir classificação aos riscos ou às condições a partir da combinação de probabilidade e escalas de impacto. A escala do impacto do risco reflete a severidade de seu efeito no objetivo do projeto. O impacto pode ser ordinal ou cardinal, dependendo da cultura da organização que conduz a análise. Escalas ordinais são simplesmente valores ordenados, tais como muito baixo, baixo, moderado, alto e muito alto. Escalas cardinais atribuem valores para esses impactos. A probabilidade de um risco naturalmente fica entre 0.0 (sem probabilidade) e 1.0 (certeza). Esses valores são usualmente lineares (isto é, 0.1/ 0.3/ 0.5/ 0.7/ 0.9), mas também podem ser não-lineares (isto é, 0.05/ 0.1/ 0.2/ 0.4/ 0.8), refletindo o desejo da organização em evitar riscos de alto impacto. A intenção de ambas as abordagens é atribuir um valor relativo ao impacto dos objetivos do projeto se o risco em questão ocorre (PMI, 2004). A tabela 5 apresenta um exemplo da avaliação dos impactos do risco nos objetivos do projeto. Ele ilustra seu uso pela abordagem ordinal ou cardinal. 31

32 Condições definidas para escalas de impacto de um risco nos principais objetivos do projeto Objetivo do projeto Custo Tempo Escopo Muito baixo (0,05) Aumento não significativo Aumento não significativo Diminuição quase imperceptível Baixo (0,10) Aumento < 10% Aumento < 5% Áreas menos importantes afetadas Moderado (0,20) Aumento de 10% a 20% Aumento de 5% a 10% Áreas importantes afetadas Alto (0,40) Aumento de 20% a 40% Aumento de 10% a 20% Redução de escopo inaceitável para o cliente Muito Alto (0,80) Aumento > 40% Aumento > 20% Item final do projeto sem nenhuma utilidade Tabela 5 Avaliação dos impactos do risco nos objetivos do projeto Adaptado (PMI, 2004, p.245) A tabela 6 é uma matriz de Probabilidade-Impacto. Ela ilustra a simples multiplicação da escala de valores atribuídos à estimativa de probabilidade e impacto, um modo comum de combinar essas duas dimensões, para determinar se um risco é considerado baixo, moderado ou alto. A organização deve determinar quais combinações de probabilidade e impacto resultam na classificação de um risco como alto risco (condição cinza escuro), risco moderado (condição cinza médio) e baixo risco (condição cinza claro) para cada abordagem. O escore do risco auxilia a colocar o risco na categoria que irá guiar ações de resposta ao risco. Probabilidade Muito baixo Baixo (0,10) Moderado Alto (0,40) Muito Alto (0,05) (0,20) (0,80) 0,90 0,05 0,09 0,18 0,36 0,72 0,70 0,04 0,07 0,14 0,28 0,56 0,50 0,03 0,05 0,10 0,20 0,40 0,30 0,02 0,03 0,06 0,12 0,24 0,10 0,01 0,01 0,02 0,04 0,08 Tabela 6 Matriz da probabilidade/impacto do risco - Adaptado PMI (2004, p.252). As saídas desse processo são listas de riscos prioritários e de riscos para análise, bem como a classificação do risco global para o projeto. Com a repetição dessas rotinas, pode-se criar uma tendência nos resultados, provocando uma resposta aos riscos ou uma análise adicional (HELDMAN, 2002) Análise Quantitativa de Risco O processo de análise quantitativa muitas vezes se confunde com o de análise qualitativa. No entanto, enquanto que a análise qualitativa visa avaliar o impacto e a probabilidade dos riscos identificados, a análise quantitativa tem como objetivo analisar numericamente a probabilidade de cada risco e sua conseqüência nos objetivos do projeto. Mesmo assim, os processos de análise qualitativa e quantitativa podem ser utilizados em conjunto ou separadamente (DINSMORE, 2005). As principais técnicas utilizadas nesse processo são (PMI, 2004): a) Análise de sensibilidade: tem como objetivo determinar quais são os riscos que possuem o maior potencial de impacto no projeto. De acordo com Keelling (2002, p. 60), no trabalho de projeto, a análise de sensibilidade se concentra no efeito de risco derivado de mudanças que poderiam acontecer durante a implementação do projeto ; 32

33 b) Entrevistas técnicas: visam quantificar a probabilidade e as conseqüências dos riscos nos objetivos do projeto. As informações necessárias dependem do tipo de distribuições de probabilidades (uniforme, normal, triangular, beta ou logaritma) que será usado. Por exemplo, as informações seriam coletadas nos cenários otimista, pessimista e mais provável para algumas distribuições comumente usadas (conforme exemplo na tabela 7), e a média e desvio padrão para outras. As distribuições representam a probabilidade e a conseqüência dos componentes do projeto. Elemento da EAP Otimista Provável Pessimista Projeto Desenvolvimento Teste Total Tabela 7 Estimativas de custo coletadas durante a entrevista sobre riscos (PMI, 2004). c) Análise do valor monetário esperado (VME): técnica estática que calcula o resultado médio do impacto da decisão, sendo utilizada em conjunto com a análise da árvore de decisão, multiplicando-se a probabilidade do risco pelo impacto e, em seguida, soma-se os dois (HELDMAN, 2002); d) Análise de árvore de decisão: trata-se de um diagrama que descreve uma decisão sob consideração e as implicações de escolher uma ou outra das alternativas disponíveis, mostrando o melhor caminho para o tomador de decisões; e) Simulação: é um modelo que traduz as incertezas especificadas a um nível detalhado. Esse método simula o projeto completo, considerando os impactos dessas incertezas. Simulações de projetos são, tipicamente, executadas usando a técnica de Monte Carlo 4 (DINSMORE, 2005), que não é o escopo desse trabalho. Um exemplo do resultado de uma simulação de risco dos custos é mostrado na figura a seguir: Figura 6 Resultados da simulação de risco de custo (PMI, 2004, p.259) 4 Técnica estatística que utiliza simulação analisando vários cenários segundo um modelo de probabilidade. 33

34 As principais saídas produzidas pelo processo de análise quantitativa de risco envolvem: lista de riscos priorizados quantificados, análise probabilística do projeto, probabilidade de atingir os objetivos de custo e prazo e tendências nos resultados das análises qualitativa e quantitativa de risco (PMI, 2004) Planejamento da Resposta ao Risco Esse processo tem como objetivo desenvolver opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto. Responsáveis devem ser designados, atividades, orçamentos e prazos estabelecidos, além da incorporação de planos de contingência. As principais estratégias para lidar com os riscos são (PMI, 2004): a) Prevenir: o plano do projeto é modificado para eliminar a ameaça do risco; b) Transferir: quando a responsabilidade e as conseqüências do risco são transferidas para uma terceira parte; c) Mitigar: técnica utilizada para reduzir o máximo possível à probabilidade do evento de risco ocorrer e se ocorrer, que a sua conseqüência seja a menor possível; d) Aceitar: visa não fazer qualquer alteração no plano do projeto para tratar um risco. No plano de resposta aos riscos, procura-se, sempre que possível, preencher com os seguintes dados (PMI, 2004): Riscos identificados, suas descrições, a(s) área(s) do projeto afetado(s), suas causas e como eles podem afetar o objetivo do projeto; Os responsáveis pelo risco e as responsabilidades designadas; Resultados dos processos de análise qualitativa e quantitativa; Respostas acordadas incluindo transferência, mitigação ou aceitação, para cada risco no plano de respostas a riscos; Ações específicas para implementar a estratégia da resposta escolhida; Orçamento e prazos para a resposta; Planos de contingência e planos de reserva Monitoramento e Controle de Risco É o processo que deve manter a rastreabilidade dos riscos identificados, monitorar riscos residuais e identificar novos riscos, bem como assegurar a execução dos planos de resposta ao risco e avaliar a sua efetividade em redução dos riscos (DINSMORE, 2005). De acordo com o PMBOK (PMI, 2004), as principais ferramentas e técnicas utilizadas no processo de monitoramento e controle de risco envolvem: a) Auditoria das respostas aos riscos do projeto: os auditores de risco examinam e documentam a efetividade da resposta ao risco. b) Revisões periódicas dos riscos do projeto: a classificação e priorização dos riscos pode mudar durante a vida do projeto. Desse modo, qualquer mudança pode requerer análises qualitativas e quantitativas adicionais. 34

35 c) Análise do valor agregado: o valor agregado é usado para monitorar o desempenho do projeto a partir de um plano inicial, buscando identificar eventuais desvios dos custos e prazos planejados. Esse processo pode envolver a escolha de estratégias alternativas, a implementação de um plano de contingência ou emergência, a tomada de ações corretivas ou o replanejamento do projeto. Podem surgir também outros riscos para o projeto, que devem ser comunicados para o gerente para correções e tomadas de decisão. Ações corretivas, solicitações de mudança no projeto, atualização do banco de dados de risco e atualização do checklist de identificação de risco são normalmente as saídas do processo de monitoramento (PMI, 2004) Gerenciamento de Riscos no CMMI O CMMI (Capability Maturity Model Integration) foi criado para integrar os vários modelos CMM que atendem às diversas atividades relacionadas ao desenvolvimento de software, e ainda torná-lo compatível com a ISO/IEC O objetivo dessa integração foi de conduzir a avaliação e a melhoria dos processos das organizações e a habilidade para gerenciar o desenvolvimento, a aquisição e a manutenção de serviços ou produtos (SEI, 2002). Segundo o SEI (2002), o CMMI oferece uma avaliação e melhoria de processos organizacionais de forma eficiente e efetiva; promove uma visão integrada da melhoria dos processos organizacionais; diminui os custos de avaliação e formação; e um novo meio de representação da informação de disciplinas específicas, através do uso de modelos de melhoria testados. O CMMI possui representação por estágios ou contínua. A representação estagiada pode ser utilizada para verificar o nível de maturidade da organização em geral. A representação contínua pode ser utilizada para verificar o nível de capacidade dos processos (SEI, 2002). Na representação por estágios existem cinco níveis de maturidade: inicial, gerenciado, definido, gerenciado quantitativamente e em otimização. Cada nível é composto por um conjunto de áreas de processos (SEI, 2002). Cabe também ressaltar que cada área de processo é composta por objetivos específicos e objetivos genéricos. Cada objetivo específico pode ser constituído por um conjunto de práticas específicas. Um objetivo específico (SG) descreve as características que devem estar presentes para satisfazer uma área de processo. Uma prática específica (SP) é a descrição de uma atividade que é considerada importante para se alcançar o objetivo específico a ela associado (SEI, 2002). Na Tabela 8 pode-se visualizar os níveis e as áreas de processos correspondentes. Nota-se também que as atividades de gerência de risco estão definidas no nível 3 (Definido), na área de processo de gerenciamento de riscos. 35

36 Nível Nível Área de Processo 5 - Otimizado Melhoramento contínuo do processo Inovação organizacional Análise de causas e resoluções. 4 Gerenciado quantitativamente Gerenciamento quantitativo Performance organizacional do processo Gerenciamento quantitativo de projetos 3 Definido Padronização do processo Requisitos de desenvolvimento Soluções técnicas Integração de produtos Verificação Validação Foco no processo organizacional Definição do processo organizacional Treinamento organizacional Gerenciamento de projeto integrado Gerenciamento de riscos Integração da equipe de trabalho Gerenciamento integrado de suprimentos Análise de decisões Ambiente organizacional para integração 2 - Gerenciado Gerenciamento básico de Projetos 1 Inicial - - Gerenciamento de requisitos Planejamento do projeto Controle e monitoração do projeto Gerenciamento de suprimentos Avaliação e análise Garantia da qualidade do processo e produto Configuração do gerenciamento Tabela 8 Áreas de Processo do CMMI (SEI, 2002). O modelo CMMI é também subdividido em áreas de processos, com quatro categorias: processos de gerência de processo, processos de gerência de projeto, processos de engenharia e processos de apoio. A tabela 9 mostra as áreas-chave de processos dentro dessas categorias: 36

37 Categoria de Processo Gerência de Processo Gerência de Projeto Engenharia Processo de Apoio Grupo de Área de Processo Básico Avançado Básico Avançado Básico Avançado Processos Foco no Processo Organizacional Definição do Processo Organizacional Treinamento Organizacional Execução do Processo Organizacional Entrega e inovação organizacional Planejamento de Projeto Monitoramento e Controle de Projeto Gerência de Contratos com Fornecedores Gerência integrada de projeto Gerência de risco Gerência quantitativa de projeto Desenvolvimento de requisitos Gerência de requisitos Solução técnica Integração do Produto Verificação Validação Gerência de Configuração Gerência de Qualidade de Produto e de Processo Análise e Medição Resolução e análise de decisão Resolução e análise de causa Tabela 9 Distribuição das áreas chaves nos processos do CMMI (SEI, 2002). Para o CMMI (SEI, 2002), a gerência de riscos tem como objetivos principal identificar potenciais riscos antes que eles ocorram. Assim, atividades de tratamento para estes riscos podem ser planejadas e utilizadas quando necessário, mitigando impactos adversos sobre os objetivos a serem atingidos. A gerência de risco pode iniciar no nível 2 do CMMI, dentro da área de processo de Planejamento de Projeto e Monitoramento e Controle de Projeto, com a simples identificação dos riscos, tendo como objetivo o seu conhecimento e tratamento quando ocorrerem. A área de processo Gerência de Risco (nível 3) é uma evolução dessas práticas para: planejamento sistemático, antecipação e minimização de riscos para a redução pró-ativa de seus impactos no projeto. A área de processo gerência de riscos é composta por três objetivos específicos e suas práticas específicas (SEI, 2002): Preparar-se para a gerência de riscos: determinar fontes e categorias de riscos; definir parâmetros de riscos; e estabelecer uma estratégia para a gerência de risco. Identificar e analisar os riscos: identificar riscos; e avaliar, categorizar e priorizar riscos. 37

38 Mitigar riscos: desenvolver planos de mitigação de riscos; e implementar planos de mitigação de riscos. A preparação para a gerência de riscos define uma estratégia com ações específicas para aplicar e controlar a gerência de risco nas atividades de identificação, análise e mitigação de riscos. Isso inclui identificar as fontes do risco, o esquema usado para categorizar riscos e os parâmetros usados para avaliar, limitar e controlar riscos de forma eficaz. Normalmente, isso é documentado em um plano de gerenciamento de riscos (SEI, 2002). A prática específica Identificar Riscos, pertencente ao objetivo específico Identificar e Analisar tem como objetivo a identificação de potenciais situações, perigos, ameaças e vulnerabilidades, que poderiam afetar negativamente o projeto. O resultado desta prática é a lista dos riscos identificados, incluindo o contexto, as condições e as conseqüências da ocorrência do risco. A lista dos riscos deve ser revisada regularmente, para que se identifiquem novas possíveis fontes de riscos e de alterações nos riscos identificados anteriormente (SEI, 2002). A prática específica Avaliar, Categorizar e Priorizar Riscos, que pertence ao objetivo específico Identificar e Analisar Risco tem como objetivo realizar a avaliação e a categorização de cada risco identificado e determinação de sua prioridade. Essa categorização envolve definir a probabilidade, a conseqüência (severidade ou impacto) e os limites. A avaliação dos riscos é necessária para se definir a importância relativa de cada risco identificado. O resultado dessa prática é uma lista de riscos com sua respectiva prioridade (SEI, 2002). No objetivo específico Mitigar Riscos são desenvolvidos e executados planos de mitigação aos riscos, para que o impacto potencial de ocorrência desses riscos sejam proativamente reduzidos (SEI, 2002) Gerenciamento de Riscos no RUP O Rational Unified Process (RUP) é um processo de engenharia de software, que fornece uma abordagem disciplinada para assumir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Seu objetivo é assegurar a produção de software de alta qualidade que satisfaça as necessidades de seus usuários finais dentro do prazo e orçamento previsíveis (KRUTCHEN, 2003). Segundo Krutchen (2003), o RUP é composto por duas dimensões: uma dimensão estática, representada por disciplinas que agrupam atividades, papéis e artefatos, e uma dimensão dinâmica, representada por fases, iterações e marcos. O ciclo de vida proposto pelo RUP é composto por quatro fases seqüenciais, cada uma com atividades e objetivos específicos. Essas fases são: 1. Iniciação (Inception) - entendimento da necessidade e visão do projeto; definição dos objetivos e viabilidade do projeto (a idéia do projeto) e do escopo de vários aspectos. 2. Elaboração (Elaboration) - especificação e abordagem dos pontos de maior risco; eliminação dos elementos de maior risco do projeto através da criação de uma arquitetura coerente e consistente da solução. 3. Construção (Construction) - desenvolvimento principal do sistema; desenvolvimento de todos os componentes e características não resolvidas nas fases anteriores, testando-as e integrando-as na forma de um produto. 38

39 4. Transição (Transition) - ajustes, implantação e transferência de propriedade do sistema; realiza a transição do produto para a comunidade de usuários. O processo de desenvolvimento de software do RUP é iterativo, onde uma iteração reúne um conjunto de disciplinas, conforme figura 7. Uma das principais vantagens da abordagem iterativa é a identificação e o combate dos principais riscos do projeto em tempo hábil. Figura 7 Estrutura do RUP - Extraído de KRUTCHEN (2003) Segundo o RUP (2003), os riscos devem ser identificados e combatidos o quanto antes no ciclo de vida do projeto, sempre priorizando a garantia da produção de software com alta qualidade, de acordo com as necessidades dos usuários e produzidos dentro do prazo e custo previstos. Riscos não identificados significam que se pode estar investindo em uma arquitetura falha ou em um conjunto não otimizado de requisitos. O gerenciamento de riscos no RUP (2003) está incorporado na disciplina de gerenciamento de projeto e possui as seguintes atividades: Desenvolver o plano de gerenciamento de riscos; Identificar e avaliar riscos; Monitorar o status do projeto. A atividade Desenvolver o Plano de Gerenciamento de Riscos que pertence ao fluxo de trabalho detalhado no planejamento do projeto, tem como finalidade criar um plano documentado para identificar, analisar e priorizar os riscos, além de identificar as estratégias de gerenciamento para os riscos mais importantes do projeto (RUP, 2003). A atividade Identificar e Avaliar Riscos do RUP tem o objetivo de identificar, analisar e priorizar os riscos para o projeto e determinar as estratégias adequada de gerenciamento de riscos. As seguintes etapas fazem parte dessa atividade (RUP, 2003): Identificar riscos potenciais: possui o objetivo de criar e manter atualizada a lista de riscos. Analisar e priorizar riscos: tem a finalidade de agrupar riscos similares (reduzindo o tamanho da lista de riscos) e de classificá-los de acordo com seu impacto no projeto. 39

40 Identificar estratégias para evitar riscos: tem o objetivo de reorganizar o projeto para eliminar riscos. Identificar estratégias para mitigar riscos: desenvolve planos de mitigação do risco para diminuir o impacto dos riscos. Identificar estratégias de contingência: gera planos alternativos, que devem conter o indicador do risco e a ação a ser realizada caso ele ocorra. Rever riscos durante a iteração: tem a finalidade de verificar o que mudou. Rever riscos no final de uma iteração: tem o objetivo de eliminar riscos que tenham sido totalmente mitigados e incluir riscos recentemente descobertos. A atividade Monitorar o Status do Projeto tem como objetivo reunir as informações de qualidade e de andamento do projeto para avaliar o status atual. É composta dos seguintes passos (RUP, 2003): Capturar o status do trabalho: reúne informações de qualidade e progresso do projeto para avaliação do status atual. Derivar indicadores de progresso: avalia apropriadamente o andamento do projeto com relação aos planos. Derivar indicadores de qualidade: usa métricas de qualidade. Avaliar indicadores x planos: compara o estado esperado do projeto de acordo com o que foi definido no plano de desenvolvimento e no plano da iteração. Apesar de ter um processo para gerenciamento de riscos similar ao PMBOK e ao CMMI, o RUP trata como essencial apenas para projetos maiores ou de alto risco, e o coloca como opcional para projetos menores, onde seria suficiente apenas a elaboração da lista de riscos Comparação dos Modelos / Metodologias de GR A tabela 10 apresenta uma comparação entre os modelos de gerenciamento de riscos apresentadas nesse trabalho. Através dessa tabela pode-se melhor visualizar as similaridades e as diferenças entre esses modelos. Essa tabela tem como base os processos do PMBOK, que se mostrou o mais completo dos modelos / metodologias estudados. A comparação é realizada utilizando os processos do PMBOK, as práticas específicas do CMMI e as atividades do RUP. 40

41 PMBOK CMMI RUP Planejamento da gerência de Estabelecer uma estratégia Desenvolver o plano de riscos para a gerência dos riscos gerenciamento de riscos Identificação dos riscos Identificar riscos Identificar e avaliar os riscos Análise qualitativa dos riscos Análise quantitativa dos riscos Avaliar, categorizar e priorizar riscos Planejamento das respostas aos riscos Monitoramento e controle dos riscos Desenvolver planos de mitigação de riscos Implementar os planos de mitigação de riscos Monitorar o status do projeto Tabela 10 Comparação dos modelos de gerenciamento de riscos Nota-se que o processo de análise quantitativa dos riscos do PMBOK não é descrito separadamente no CMMI ou no RUP. Como no PMBOK esta prática é tratada como um processo, há uma maior clareza sobre como ela deve ser conduzida. Nota-se também que no RUP, os processos de identificação e análise são realizadas numa única atividade. A partir desse comparativo, verificou-se que o gerenciamento de riscos nesses modelos está em conformidade em seus aspectos essenciais, não havendo nenhuma incompatibilidade fundamental entre eles. Isto comprova a importância da gerência de riscos para os projetos de software, particularmente por dar um tratamento adequado às incertezas, e promover a melhoria dos processos de software. Deve-se apenas ressaltar que todas as atividades são baseadas e centradas na comunicação, devendo ser realizadas de forma cíclica e contínua dentro do processo de gerência de risco. 41

42 3 Ferramentas de Gerenciamento de Riscos Nesse capítulo, será apresentado um estudo sobre as ferramentas de gerência de riscos disponíveis no mercado e um comparativo entre elas. Este estudo teve como finalidade ressaltar, de forma mais consistente, a necessidade do desenvolvimento da ferramenta criada nesse trabalho. Foram analisadas duas ferramentas através de versões de demonstração disponibilizadas na Internet. No entanto, as ferramentas são poucas e todas comerciais, e, muitas vezes, o custo elevado inviabiliza a compra por empresas de pequeno e médio porte. As ferramentas analisadas foram a RiskTrak 3.1 RiskTrak O RiskTrak (figuras 8 e 9) é uma ferramenta desenvolvida pela empresa americana Risk Services & Technology 5. A ferramenta segue um processo próprio de gerenciamento de riscos, denominado ARM (assessment report manage), suportando a identificação, a análise e a mitigação do risco. Figura 8 Tela com lista de riscos no RiskTrak O RiskTrak dá suporte a múltiplos usuários. Permite a todos que utilizam a ferramenta e que possuem as permissões de acesso, a visualização, a análise, a comunicação, a criação de relatórios, bem como o gerenciamento dos riscos (custo, tempo e técnico) durante todo o projeto. 5 Disponível em < 42

43 A ferramenta possui assistentes que ajudam a definir a estrutura do projeto através de perguntas focadas em risco. Um aspecto importante é quanto à identificação, à análise e à mitigação do risco. A ferramenta oferece um editor de riscos (figura 9) que permite inúmeras atribuições ao risco, entre elas: custo, tempo, probabilidade, proporção, estratégia de mitigação, fase do risco, status, responsável, prazo para resolução. Figura 9 Tela de definição do risco no RiskTrak O RiskTrak é uma ferramenta com funcionalidades limitadas, mas fornece uma boa visibilidade dos conceitos e métodos de gerenciamento de risco. é uma ferramenta criada pela empresa Palisade 6, sendo utilizada em conjunto com o Microsoft Excel. Essa ferramenta não permite múltiplos projetos, nem múltiplos usuários. O seu principal objetivo é analisar e quantificar riscos através de simulações. Suporta 37 diferentes tipos de distribuições de probabilidade e utiliza a técnica de Monte Carlo. Essa ferramenta requer uma boa experiência do usuário, com a utilização do Microsoft Excel, principalmente com suas fórmulas. A figura 10 apresenta um exemplo de gráficos gerados a partir de uma simulação realizada 6 Disponível em < 43

44 Figura 10 Tela da 3.3 Comparativo das Ferramentas A tabela a seguir apresenta uma comparação entre as características avaliadas das ferramentas de gerenciamento de riscos disponíveis no mercado. Característica Processos de GR Planejamento Não Não Identificação Sim Sim Análise qualitativa Sim Não Análise quantitativa Não Planejamento das respostas Monitoramento e controle Sim Não Sim Não Não Valor da licença (1 usuário) US$ 1485,00 US$ 685,00 Plataforma Windows. Windows e Excel Usabilidade Relatórios Boa, bem intuitiva Poucos, apenas 6 tipos Idioma Inglês Inglês Versão Razoável, exige uma boa experiência com o Excel Vários, principalmente gráficos Tabela 11 Comparação entre as ferramentas de gerenciamento de riscos 44

45 4 Desenvolvimento da Ferramenta de Gerenciamento de Riscos A fim de apresentar os resultados obtidos na realização desse trabalho, este capítulo especifica a ferramenta, apresenta a modelagem e, por fim, descreve o protótipo gerado, em que as especificações dos requisitos foram implementadas. 4.1 Visão Geral Vista a importância do tema, a dificuldade de acesso, a carência e o alto custo das ferramentas específicas nessa área, este trabalho criou um protótipo de uma ferramenta de apoio aos processos de gerenciamento de riscos, que seja útil e aplicável pelas organizações. Essa ferramenta recebeu o nome de ProRisk. A ferramenta tem como objetivo auxiliar os gerentes de projetos a gerenciarem os riscos de seus projetos. Os integrantes das equipes de projeto também poderão fazer uso da ferramenta auxiliando o gerente a identificar e a analisar riscos, assim como para obter visibilidade sobre os riscos dos projetos aos quais estão vinculados. Os demais envolvidos nos projetos também poderão utilizar a ferramenta tanto para obter visibilidade dos riscos quanto para gerarem relatórios informativos da situação dos projetos com relação à gerência de riscos. A ferramenta permite uma estruturação dos dados relativos a riscos, uma viabilidade de reutilização de conhecimento e também orienta a equipe do projeto na correta utilização do processo de gerenciamento de risco. 4.2 Características do Protótipo O protótipo proposto tem como base as práticas descritas no PMBOK, contemplando os processos da área de gerenciamento de riscos. O PMBOK foi o modelo que apresentou o processo de gerenciamento de riscos mais completo e detalhado, conforme mostrado na seção desse trabalho. Além disso, a ferramenta contempla também as características descritas no CMMI, visto que os processos são semelhantes ao PMBOK e por ser um modelo para desenvolvimento de software. Para que o protótipo venha a ter condições de suportar esses modelos, é necessário que os processos sejam corretamente representados dentro da ferramenta. São seis os processos, e o resultado de cada um serve de entrada para o próximo. São eles: Planejamento da Gerência de Risco; Identificação dos Riscos; Análise Qualitativa dos Riscos; Análise Quantitativa dos Riscos; Planejamento de Resposta a Riscos; Controle e Monitoramento de Riscos. 45

46 Cada um desses processos citados de gerenciamento de riscos possui um conjunto de técnicas e ferramentas. Devido à limitação de tempo do projeto, decidiu-se por implementar apenas técnicas simples, porém eficientes, de cada um dos processos. Como exemplo, não foram implementadas técnicas como a de análise de árvore de decisão e simulação de Monte Carlo, utilizadas no processo de análise quantitativa de risco. Por se tratar de um projeto acadêmico, a ferramenta é totalmente gratuita e poderá seu projeto e a sua modelagem ser disponibilizados a outros desenvolvedores, o que propiciará a melhoria constante do projeto original. As principais características da ferramenta, a fim de contemplar esses objetivos, são: Gratuidade a ferramenta não exige a aquisição de nenhum software adicional para que o sistema possa ser executado. Facilidade de uso a ferramenta deve ser de fácil utilização, permitindo sua operação por usuários sem muita experiência com o uso de ferramentas. Para isso, o mesmo deve ter uma interface intuitiva, que guie o usuário na interação com o sistema. Segurança dos dados os dados devem ser armazenados em um sistema gerenciador de banco de dados robusto e confiável, que possua regras de integridade, controle transacional e controle de acesso aos dados. Controle de acesso a ferramenta deve possuir um controle de acesso através de senhas, garantindo o acesso às informações somente para usuários autorizados. Além disso, deve contemplar diferentes tipos de acesso, de acordo com o tipo de usuário, que pode ser um administrador da ferramenta, um gerente ou um membro do projeto. Multiusuário o software pode ser utilizado tanto em um ambiente desktop (um único computador utilizando o software e o banco de dados instalado localmente) quanto em um ambiente client-server (uma cópia do software instalada em cada estação acessando o mesmo banco de dados em um servidor). Instalação amigável deve existir um software para auxiliar e facilitar a instalação da ferramenta. 4.3 Modelagem Esta seção mostrará as etapas realizadas para a modelagem e a especificação do protótipo. As etapas são: 1. Seleção da ferramenta case. 2. Modelagem dos casos de uso. 3. Especificação dos casos de uso. 4. Modelagem de classes. A seguir veremos uma breve descrição da UML, a linguagem que foi adotada para modelar o sistema e, posteriormente, as etapas citadas, acompanhadas de considerações sobre suas particularidades. 46

47 4.3.1 Modelagem UML Definir um modelo de desenvolvimento é uma etapa importante na construção de sistemas, de modo que se possa afirmar que o software é construído com padrões previamente estabelecidos (PRESSMAN, 2002). Segundo Booch (2005), a UML (Unified Modeling Language) é a linguagem de modelagem padrão atualmente, usada no desenvolvimento dos mais diversos tipos de sistemas. Ela abrange sempre qualquer característica de um sistema, vindo a ser aplicada em diferentes fases do desenvolvimento orientado a objetos, desde a especificação da análise de requisitos até a finalização com a fase de testes. O objetivo da UML é descrever qualquer tipo de sistema em termos de diagramas orientado a objetos. Naturalmente, o uso mais comum é para criar modelos de sistemas de software, mas a UML é também usada para representar sistemas não necessariamente apoiados por software (FURLAN, 1998). Modelar um sistema complexo, contudo, é uma tarefa extensiva, sendo necessária a descrição de vários aspectos diferentes, incluindo o funcional (estrutura estática e interação dinâmica), não funcional (tempo de processamento, confiabilidade, produção) e organizacional (organização do trabalho, mapeamento e código). Esses aspectos são chamados de visões (BOOCH, 2005). As visões mostram diferentes aspectos do sistema que está sendo modelado. Não se trata de apenas um gráfico, mas de uma abstração consistindo em uma série de diagramas. Definindo um número de visões, cada uma mostrará aspectos particulares do sistema, dando enfoque a ângulos e níveis de abstrações diferentes e uma figura completa do sistema (BOOCH, 2005). A UML possui vários tipos de diagramas que são usados em combinação para prover todas as visões do sistema (BOOCH, 2005): Diagrama de Classes; Diagrama de Caso de Uso; Diagrama de Seqüência; Diagrama de Colaboração; Diagrama de Estado; Diagrama de Atividade; Diagrama de Componente; Diagrama de Implantação. Os sistemas em geral possuem uma estrutura estática e um comportamento dinâmico. A UML suporta modelos estáticos (estrutura estática), dinâmicos (comportamento dinâmico) e funcionais. Segundo Booch (2005), a modelagem estática é suportada pelo diagrama de classes, que consiste nas classes e nos seus relacionamentos. A modelagem dinâmica é suportada pelos diagramas de casos de uso, seqüência, colaboração, estado e atividade; a modelagem funcional é suportada pelos diagramas de componente e implantação. 47

48 Esse trabalho usa apenas uma parte da metodologia, apresenta dois diagramas, de casos de uso e de classes, já que não é proposto o desenvolvimento completo do sistema e, sim, um protótipo com as funcionalidades básicas. Esses diagramas serão detalhados nas próximas seções Seleção da Ferramenta Case O primeiro passo para a modelagem do projeto foi a seleção de uma ferramenta case. Essa escolha recaiu sobre aquela ferramenta que é atualmente umas das mais modernas e utilizadas nas empresas. Essa ferramenta se trata do Rational Rose da IBM 7. Essa ferramenta foi escolhida também pelo conhecimento do autor neste software, além da facilidade de uso e da boa documentação encontrada sobre a mesma em tutoriais e livros Modelagem dos Casos de Uso Primeiramente, optou-se por se modelar os casos de uso (use cases), parte da modelagem de alto nível do sistema, para se identificar as funcionalidades que o sistema deveria abranger, como base dos requisitos do sistema. Segundo Furlan (1998), diagramas de caso de uso fornecem um modo de descrever a visão externa do sistema e as suas interações com o mundo exterior, representando uma visão de alto nível de funcionalidade intencional mediante o recebimento de um tipo de requisição do usuário. Ainda segundo Furlan (1998), o propósito primário dos casos de uso é: 1. Descrever os requisitos funcionais do sistema de maneira consensual entre os usuários e os desenvolvedores de sistemas. 2. Fornecer uma descrição consistente e clara sobre as responsabilidades que devem ser cumpridas pelo sistema, além de formar a base para a fase de projeto. 3. Oferecer as possíveis situações do mundo real para o teste do sistema. Após a definição acerca do funcionamento da ferramenta, foi possível identificar os seguintes atores que compõem os casos de uso, conforme a figura 11: Figura 11 Atores do Sistema 7 Maiores informações em < > 48

49 Usuário generalização de todos os tipos de atores do sistema. Utilizado para representar que determinado caso de uso pode ser iniciado por qualquer ator. Administrador ator com o mais alto nível de acesso ao sistema. Responsável pela configuração do sistema, criação de novos projetos, usuários e definição de permissões do sistema. Tem acesso a todos os projetos da organização. Gerente do Projeto este ator tem controle sobre os projetos e permissões para gerenciar os riscos, como exemplo, identificar e analisar os riscos. Membro do Projeto este ator possui acesso limitado à ferramenta. Ele pode somente visualizar a gerência de riscos dos projetos e auxiliar a identificar/analisar riscos. Após a definição dos atores, foram definidos os casos de uso da aplicação. Para auxiliar no entendimento, eles foram agrupados em pacotes 8, separados de acordo com a classificação funcional de cada um. Sendo assim, foram mapeados três pacotes, conforme a figura 12: Administração pacote com os casos de uso com as funcionalidades de configuração do sistema, de administração de projeto, usuários e permissões de acesso ao sistema. Segurança pacote com os casos de uso que contêm as funcionalidades de autenticação e acesso do usuário na aplicação. Negócio pacote com os casos de uso que irão suportar a execução dos processos de negócio relativos ao gerenciamento de riscos. Administ ração Segurança Negócio Figura 12 Diagrama de pacotes do sistema Depois da definição dos pacotes, serão apresentados os casos de uso definidos e uma breve descrição dos objetivos de cada um. Para o pacote de administração do sistema, foram identificados os seguintes casos de uso, conforme mostrado no diagrama a seguir: 8 Um pacote é definido como um mecanismo de propósito geral para organizar elementos semanticamente relacionados em grupos (BOOCH, 2005). 49

50 Manter Usuários <<extend>> Administrador (from Atores) Definir Permissões Manter Projetos Figura 13 Diagrama de caso de uso do pacote de administração 1. Manter usuários Permitir que o administrador realize a manutenção (inclusão, edição e exclusão) dos usuários do sistema. Cada usuário deverá ter login e senha para ter acesso ao sistema. 2. Definir permissões Permitir que o administrador defina permissões de acesso e alteração de dados dos programas existentes no sistema, para cada usuário cadastrado. 3. Manter projetos Permitir que o administrador realize a manutenção (inclusão, edição e exclusão) dos projetos da empresa. Também poderão ser definidas a equipe e as atividades que compõem o projeto. Para o pacote de segurança do sistema, foram identificados os seguintes casos de uso conforme mostrado no diagrama a seguir: Efetuar Logon Usuário Efet uar Logoff (from Atores) Alterar Senha Figura 14 Diagrama de caso de uso do pacote de segurança 1. Efetuar logon Autenticar o usuário no sistema para lhe permitir acesso aos projetos e as demais funcionalidades do sistema. 2. Efetuar logoff Encerrar a conexão do usuário no servidor, liberando os recursos alocados. 3. Alterar senha Permitir que o usuário efetue a troca da senha atual por uma nova senha. 50

51 Por último, foram definidos os casos de uso do pacote de negócio do sistema conforme os diagramas a seguir: Planejar a Gerência de Riscos <<include>> Manter EAR Gerente do Projeto (from Atores) Montar Plano de Resposta aos Riscos Membro do Projeto (from Atores) <<extend>> Exportar Atividades Figura 15 Diagrama de caso de uso do pacote de negócio parte I <<extend>> Simular Projeto Identificar Riscos Importar Riscos Comuns Gerente do Projeto (from Atores) Monitorar e controlar risco Membro do Projeto (from Atores) Manter Riscos Comuns Analisar Riscos Figura 16 Diagrama de caso de uso do pacote de negócio parte II 51

52 Gráfico de Riscos por Grupo Relatório dos Maiores Riscos Gerente do Projeto (from Atores) Gráfico de Andamento dos Riscos Figura 17 Diagrama de caso de uso do pacote de negócio parte III 1. Planejar a Gerência de Risco Permitir que o gerente do projeto crie um plano de gerência de riscos para o projeto. Neste plano, será possível definir itens como as categorias de riscos e as definições de probabilidade e impacto. 2. Manter EAR Permitir que o gerente realize a manutenção (inclusão, edição e exclusão) das categorias de riscos do sistema. Essas categorias são estruturadas em forma de árvore e conhecidas como EAR (estrutura analítica de risco). 3. Identificar riscos Permitir a identificação dos riscos para o projeto. Para cada risco, o gerente pode definir a categoria, o tipo, as causas e as conseqüências. 4. Manter riscos comuns Permitir a manutenção dos riscos mais comuns por tipo de projeto. 5. Importar riscos comuns Permitir que o gerente importe os riscos para o projeto a partir da base histórica dos riscos mais comuns por tipo de projeto. Para essa importação, é utilizada uma lista de verificação (checklist). 6. Analisar riscos Permitir que o usuário realize a análise dos riscos identificados para o projeto. Para cada risco, o gerente do projeto definirá a probabilidade do risco acontecer e os impactos nos objetivos do projeto. A partir dessa análise, será possível classificar e priorizar os riscos de maior perigo ao projeto para uma posterior definição de estratégias para combatêlos. 7. Simular projeto Permitir que o gerente do projeto realize uma simulação de custo e tempo a partir de estimativas para cada atividade de seu projeto. A partir dessa simulação, é criado um gráfico de probabilidades. 8. Montar plano de respostas aos riscos Permitir que o usuário crie um plano de resposta a cada um dos riscos identificados do projeto. No plano, são definidos os responsáveis por gerenciar o risco, além de estratégias e ações para combater os riscos. 52

53 9. Exportar atividades Permitir que o usuário exporte as atividades (ações) de combate aos riscos de um projeto. Essas atividades serão exportadas para um arquivo para ser utilizado pelo Microsoft Project. 10. Monitorar e controlar riscos Permitir que o usuário possa criar informações de monitoramento e controle de um risco para acompanhar o andamento do mesmo. 11. Relatório dos maiores riscos Permitir que o usuário gere um relatório com os maiores riscos existentes, ou seja, que ofereçam maior perigo para os objetivos do projeto. 12. Gráfico de riscos por grupo Permitir que o usuário gere um gráfico de riscos, agrupando-os por categoria, estado ou probabilidade de ocorrer. 13. Gráfico de andamento dos riscos Permitir que o usuário gere um gráfico do andamento do nível de probabilidade de ocorrência dos riscos, visualizando a evolução dos riscos a cada mês Especificação dos Casos de Uso Após a definição e modelagem dos casos de uso, foi realizada a especificação de cada um. Abaixo está detalhado apenas um caso de uso, como exemplo dos resultados obtidos com a atividade de especificação. Os demais casos de uso, também importantes para o presente trabalho, estão no documento de requisitos no CD entregue em anexo. Com base nesse documento, todo o sistema deveria se pautar. Se fosse necessário modificar algum item na especificação, em virtude de necessidades encontradas no decorrer do desenvolvimento, deveria alterar essa especificação. Caso de Uso: Identificar Riscos Objetivo Permitir a identificação de riscos para o projeto. Para cada risco, o gerente pode definir a categoria, o tipo, as causas e as conseqüências. Atores Gerente do Projeto Pré-Condições Usuário autenticado no sistema. Usuário ter acesso ao programa. Existirem projetos cadastrados. Curso normal 1. O caso de uso se inicia quando o usuário opta por identificar riscos para um projeto. 2. O sistema apresenta uma lista com todos os projetos disponíveis. 3. O usuário seleciona um projeto (RN1). 4. O sistema apresenta os riscos cadastrados para o projeto. 5. O usuário escolhe uma das seguintes operações: Incluir (A01), Alterar (A02), Excluir (A03). 6. O caso de uso encerra-se após a operação selecionada ser completada. 53

54 Curso alternativo Identificação Descrição A01 - Incluir A02 - Alterar A03 - Excluir Regras de negócio Identificação Descrição RN1 RN2 RN3 RN4 Pós-Condições 1. O sistema apresenta diversos campos que o usuário deverá preencher para cadastrar o risco. 2. O usuário informa os seguintes dados para o risco: a. Título do risco b. Descrição detalhada c. Data da identificação d. Responsável pela identificação e. Categoria do risco (requisitos, recursos, tecnologia, cliente, comunicação, etc) (RN2) f. Tipo do risco (ameaça ou oportunidade) g. Causa principal do risco h. Conseqüências do risco para o projeto i. Estado do risco (identificação, análise, planejamento de resposta, monitoramento, concluído) (RN3) j. Observação 3. O usuário confirma a operação. 4. O sistema registra o risco. 1. O usuário seleciona o risco que deseja alterar. 2. O sistema apresenta os dados do risco. 3. O usuário altera os dados do risco. 4. O usuário confirma a operação. 5. O sistema salva as informações. 1. O usuário seleciona o risco que deseja excluir (RN4). 2. O usuário confirma a operação. 3. O sistema exclui o risco do sistema. O usuário só poderá selecionar um projeto para identificar riscos em que ele seja o gerente. As categorias de riscos estão definidas na estrutura analítica de risco utilizada pelo plano de gerência de riscos do projeto. Ao incluir um risco, o estado do risco deve ser definido como identificação, e o usuário não poderá alterar esse estado. Somente risco que esteja no estado de identificação pode ser excluído. Riscos salvos para o projeto e prontos para serem analisados. Tabela 12 Exemplo de Caso de Uso 54

55 4.3.5 Modelagem de Classes Após a especificação dos casos de uso, foram modeladas as classes de negócio do sistema através do diagrama de classes. Segundo Furlan (1998), o diagrama de classe é a essência da UML, pois é o resultado de uma combinação de diagramas propostos pela OMT, Booch (método de Grady Booch) e vários outros métodos. Trata-se de uma estrutura lógica estática com o objetivo de descrever as classes contidas no sistema (em seus atributos e métodos), bem como os relacionamentos e a cardinalidade existentes entre as classes. O diagrama de classes da UML é essencialmente rico em sua capacidade de modelagem, em virtude, principalmente, do número de elementos que o compõem e de sua notação correspondente. Apesar disso, no presente projeto, não se buscou usar todos os recursos disponibilizados por essa linguagem, mas apenas os julgados necessários à modelagem do sistema de forma a atingir seus objetivos. Durante essa fase, procurou-se seguir algumas dicas sugeridas por Furlan (1998) para evitar um detalhamento muito extenso nas fases iniciais da modelagem do sistema. Uma síntese dessas dicas é colocada a seguir: Identifique os comportamentos iniciais, definindo os objetos que exibem esses comportamentos, classificando esses objetos e modelando seus ciclos de vida. Comece a modelagem de classes de forma simples, iniciando com classes, associações, atributos e generalizações; introduzindo novas notações somente quando necessárias. Na perspectiva de análise, crie modelos conceituais. Os modelos subseqüentes de especificação e de implementação deverão ser concebidos em suas próprias perspectivas. Concentre-se na modelagem de áreas-chaves, evitando especificar modelos que serão pouco ou nunca utilizados. O diagrama foi construído apenas com as classes que pertencem ao domínio principal do software, ou seja, classes técnicas que gerenciem banco de dados, interface, comunicação, concorrência e outros não estarão presentes neste diagrama. A figura 18 demonstra as classes utilizadas no projeto do protótipo proposto. Sobre o diagrama, cabe ressaltar alguns aspectos relevantes para a correta compreensão do mesmo. Inicialmente, chama-se a atenção para as associações de composição (representadas por um losângulo preenchido), como por exemplo, entre as classes Projeto e Risco. O objetivo foi de mostrar que uma classe vive e constitui a outra, ou seja, se o objeto da classe que contém a composição for destruído, as demais classes serão destruídas juntamente com a principal. Outro aspecto interessante é a presença de associações de agregação (representadas por um losângulo não preenchido), como por exemplo, entre as classes Plano Gerencia Risco e EAR. O objetivo foi de mostrar que classes envolvidas existem por si, porém cada uma delas mantém um grau de dependência em relação à outra. Nota-se também que as classes Risco e Projeto são as mais importantes do modelo, visto que possuem relacionamento com grande parte das demais. Além disso, vale salientar a existência de herança, como o caso da classe Usuario que herda o comportamento da classe Pessoa. 55

56 Figura 18 Diagrama de classes do sistema

57 4.4 Implementação Depois de encerrada a fase da modelagem do sistema, foi realizada a implementação do mesmo. Esta etapa do projeto envolveu uma série de tarefas que foram concluídas em seqüência, a fim de garantir um resultado final satisfatório e um protótipo que atenda aos requisitos apontados nas seções anteriores. São estas: 1. Definição da tecnologia: a escolha da linguagem de programação, do sistema gerenciador de banco de dados e da plataforma na qual o sistema foi executado levando em conta uma série de fatores, dentre os quais, o conhecimento sobre as ferramentas utilizadas, visando à redução do risco tecnológico do projeto e à confiabilidade das soluções. 2. Mapeamento objeto-relacional: na definição da tecnologia optou-se pela utilização de um banco de dados relacional. Portanto, foi necessário fazer o mapeamento objeto-relacional, em que as classes definidas nos diagramas de classes foram transformadas em entidades em um modelo entidaderelacionamento. Foi necessária a criação de tabelas adicionais para representar as relações de cardinalidade n-n do sistema, que não são representadas no diagrama de classes. 3. Criação das classes base que implementarão as telas do aplicativo: foram criados templates que posteriormente foram herdados para as telas do sistema. Dessa maneira, conseguiu-se um ganho de produtividade e de qualidade; uma vez que a classe base estando bem testada e certificada, as telas originárias da mesma precisaram ter pouco ou até mesmo nenhum código, reduzindo-se, assim, a possibilidade de erros e o tempo de desenvolvimento. 4. Implementação: nesta etapa, o protótipo foi efetivamente escrito na linguagem Delphi versão Criação do programa de instalação: foi criado o programa de instalação Tecnologia O software foi desenvolvido na linguagem de programação Delphi na versão 7.0, utilizando como meio de armazenamento o banco de dados open source PostgreSQL 9. O software funciona no sistema operacional Windows nas versões 98 ou superiores. No caso da utilização do sistema no modelo client-server, o banco de dados pode ser instalado nos seguintes sistemas operacionais: Darwin, Freebsd, HPux, Linux, Sinixz, Solaris e Windows (NT, 2000 ou XP). Acompanhará o instalador do programa um instalador para a versão Windows do banco de dados PostgreSQL, na versão 8.1. A fim de facilitar o desenvolvimento e possibilitar uma eventual mudança do banco de dados, causando o menor impacto possível no projeto, todas as rotinas e os componentes de acesso aos dados estão dentro de um DataModule, uma classe especial do Delphi que aceita apenas componentes não-visuais, tipicamente de acesso a dados. Nas telas de entrada e pesquisa de dados, os componentes visuais apontam para o DataModule, bastando, então, no caso da necessidade de mudança do banco de dados, a sua substituição no sistema. 9 Disponível em < 57

58 4.4.2 Mapeamento Objeto-Relacional Para criação do modelo de entidade-relacionamento, foi utilizado o software CASE Studio 10 na versão 2.19, produzido pela empresa CHARONWARE. Esse software foi escolhido devido à sua facilidade de uso e ao fato de gerar os scripts para criação do banco de dados em vários formatos, inclusive para o padrão PostgreSQL. O modelo de entidade-relacionamento criado, bem como os scripts gerados estão disponíveis no CD entregue em anexo ao trabalho Criação das Classes Bases A fim de padronizar e agilizar o desenvolvimento da ferramenta, foram definidos templates 11 para as telas de cadastro. Dessa forma, todo o código dos cadastros mais simples ficou na classe base. As Figuras 19 e 20 mostram uma tela criada a partir do template, o cadastro de usuário. Nota-se que a tela foi concebida com o objetivo de ser a mais intuitiva possível, a fim de facilitar o uso do sistema. Ao entrar na tela de cadastro, o sistema abre-a em modo de pesquisa (figura 19). Nesse modo, todos os registros da tabela correspondente são exibidos um abaixo do outro, com suas respectivas informações. Figura 19 Exemplo de cadastro (modo de pesquisa) Ao acionar os botões incluir e editar, será mostrada uma tela de digitação de dados, mostrada na figura 20. Caso tenha sido escolhida a opção de incluir, o sistema gerará automaticamente a chave principal para a tabela. O usuário deve, então, informar os dados solicitados e clicar em OK para salvar as alterações, ou Cancelar para que as mesmas não sejam salvas. No botão excluir, o sistema pedirá confirmação da exclusão e, caso seja dada à confirmação, o registro será excluído se não acarretar a violação de nenhuma das chaves do banco de dados. Estarão também disponíveis os botões de imprimir os dados da tabela e para fechar a tela. 10 Disponível em < 11 Padrões, classes bases das quais as outras serão herdadas 58

59 4.5 Protótipo Figura 20 Exemplo de cadastro (modo de edição) O objetivo desta seção é apresentar o protótipo criado para gerenciamento de riscos. Como mencionado anteriormente, este protótipo foi denominado ProRisk. A figura 21 mostra uma visão geral da tela principal do ProRisk. A tela possui um menu que oferece acesso a todas as funcionalidades disponíveis ao usuário. Além do menu, disponibiliza também alguns ícones de atalho aos principais programas. Figura 21 Protótipo Tela principal A partir das próximas subseções serão apresentadas as principais funcionalidades do protótipo. 59

60 4.5.1 Manutenção de usuário A primeira tarefa que o administrador deve fazer ao usar o ProRisk é criar os usuários. Os usuários são todas as pessoas envolvidas nos projetos, nas atividades da gerência de risco e que irão utilizar a ferramenta. A figura 22 apresenta um exemplo da tela de manutenção de usuário. Ao abrir essa tela, o administrador deverá informar o nome do usuário, o , o telefone, o login e a senha para acesso ao sistema, além de uma opção para o usuário trocar a sua senha no próximo acesso Permissão aos usuários Figura 22 Protótipo Manutenção de usuário Uma vez criado o usuário, o administrador deve informar as permissões para acesso e para manter os dados dos programas (telas) existentes na ferramenta. Caso o usuário não tenha permissão de acesso ao programa, ele não poderá executá-lo. Caso o usuário não tenha permissão de manter os dados de um programa, poderá apenas visualizar. A figura 23 apresenta um exemplo da tela de permissão aos usuários. Figura 23 Protótipo Permissão ao usuário 60

61 Cabe ressaltar que a definição dessas permissões tem como objetivo ter diferentes níveis de usuários para a ferramenta, garantindo uma maior segurança e integridade das informações Manutenção de projeto A tela de manutenção de projeto tem como objetivo manter todos os projetos da empresa que utilizarão o gerenciamento de riscos. A figura 24 apresenta um exemplo da tela de manutenção de projeto. Ao abrir essa tela, o administrador deverá informar a descrição do projeto, o gerente, o tipo de projeto, a previsão de início e término, a situação, o orçamento e a observação. Figura 24 Protótipo Manutenção de projeto Além dessas informações, o administrador pode definir na página Membros dessa mesma tela, a equipe do projeto, ou seja, a pessoa e função de cada uma. Finalmente, na página Atividades, poderão ser definidas as atividades do projeto, com a descrição, a data de início, a data de término e responsável por cada atividade. Uma vez criado o projeto, o usuário pode passar para os processos específicos da gerência de risco Estrutura analítica de risco Uma estrutura analítica de risco representa uma forma de representar as categorias de riscos em diversos níveis. As categorias de riscos representam uma estruturação dos tipos de riscos. Segundo o SEI (2002), uma EAR também é usada como um método que auxilia na identificação de riscos, a partir da análise de suas categorias. No contexto dessa ferramenta, a EAR é utilizada pelo plano do gerenciamento de riscos e as suas categorias de riscos na identificação dos riscos. A figura 25 apresenta um exemplo da tela de manutenção da EAR. Nota-se, nessa tela, a existência de 61

62 hierarquia das categorias de riscos, em que cada categoria pode ter várias sub-categorias e assim sucessivamente. A ferramenta já possui cadastradas as categorias de risco do Kangari (1989), Wideman (1998) e SEI (1993), citadas na seção Podem ser definidas novas categorias, conforme as necessidades de cada tipo de projeto. Além disso, essas categorias podem ser atualizadas constantemente. Figura 25 Protótipo EAR Planejamento da gerência de risco Após criar o projeto e a estrutura analítica de risco, o gerente deve detalhar o plano de gerência de riscos para o projeto. Segundo o PMBOK (2004), esse plano é de fundamental importância para o sucesso dos demais processos da gerência de risco, pois serve como base para eles e para a equipe de risco. A figura 26 apresenta um exemplo da tela de planejamento da gerência de risco. Nessa tela o gerente deverá informar a data da criação do plano, a metodologia (abordagens, ferramentas e fonte de dados que podem ser usadas para executar o gerenciamento de risco no projeto), o orçamento previsto para a gerência de risco, o tempo (freqüência que o gerenciamento de risco será executado durante o ciclo de vida do projeto), a estrutura analítica de risco usado para categorizar os riscos e observação. Além dessas informações, o gerente pode definir na página Responsabilidades dessa mesma tela, as responsabilidades de cada membro da equipe dentro do processo de gerenciamento de riscos. Finalmente, na página Probabilidade X Impacto, devem ser definidas as escalas e as definições de probabilidade e o impacto para os objetivos do projeto. A partir dessas informações será possível construir uma matriz de probabilidade e impacto, que serve como referência para a análise de risco. 62

63 Figura 26 Protótipo Planejamento da gerência de risco Riscos Comuns A ferramenta permite à equipe do projeto, manter uma base histórica dos riscos mais comuns para cada tipo ou natureza de projeto da organização. Essa base deve ser constantemente atualizada e serve como uma grande fonte de informação para a identificação de riscos em novos projetos. A figura 27 apresenta um exemplo da tela de manutenção de riscos comuns. Ao abrir essa tela, o gerente deverá informar a descrição do título do risco, a descrição detalhada, o tipo de risco, a categoria, a causa principal, as conseqüências do risco para o projeto e uma observação. Na página Sugestão de mitigação, deverá informar a estratégia a ser adotada caso o risco realmente ocorra, além de uma descrição dessa estratégia e um plano de contingência. Figura 27 Protótipo Cadastro de risco comum 63

64 4.5.7 Identificação de risco Após a criação do plano do plano para o gerenciamento de riscos, o gerente poderá cadastrar os riscos identificados para o projeto. Cabe ressaltar que a identificação de riscos pode ser realizada durante todo o ciclo de vida do projeto, à medida que sejam consideradas potenciais ameaças ou oportunidades ao projeto. Outro aspecto importante, é que a identificação de risco pode envolver a participação de qualquer envolvido no projeto, mas somente o gerente ou usuário com essa permissão poderá cadastrar na ferramenta. A figura 28 apresenta um exemplo da tela de identificação de risco. Nessa tela o gerente deverá informar a descrição do título do risco, a descrição detalhada, o tipo de risco, a data e o responsável pela identificação, a situação, a categoria, a causa principal, as conseqüências do risco para o projeto e uma observação. Figura 28 Protótipo Identificação de risco Para agilizar o processo de identificação, a ferramenta permite a utilização da base de riscos comuns, citada na seção anterior, para realizar a importação dos riscos para um projeto. Para isso o gerente deve selecionar os riscos que deseja importar. A figura 29 apresenta um exemplo da tela de importação de risco. Figura 29 Protótipo Importar riscos 64

65 4.5.8 Análise de risco Uma vez identificado um risco para o projeto, o gerente pode realizar a sua análise qualitativa. Essa análise tem como objetivo definir a probabilidade do risco acontecer e os impactos nos objetivos do projeto. A partir dessa análise será possível classificar e priorizar os riscos de maior perigo ao projeto para uma posterior definição de estratégias para combatê-los. A figura 30 apresenta um exemplo da tela de análise de risco. Nessa tela o gerente deverá informar a data da análise, a probabilidade do risco acontecer, o impacto causado para cada objetivo do projeto (definidos no plano de gerência de risco), uma observação sobre a análise, além de selecionar as atividades do projeto que sofrerão impacto caso os riscos ocorram (funcionalidade disponível na página Atividades impactadas). Cabe ressaltar que a partir da definição da probabilidade e do impacto, é gerado um índice geral do risco, que é um indicador importante para classificar os riscos de maior perigo ao projeto. Por fim, a cada alteração nessa análise, as informações são armazenadas no histórico para que a equipe de gerenciamento de riscos tenha um acompanhamento da evolução do risco (disponível na página Histórico) Simular o projeto Figura 30 Protótipo - Análise de risco A ferramenta tem disponível a técnica de simulação do projeto. Segundo o PMBOK (2004), essa técnica faz parte do processo de análise quantitativa de risco, que complementa a análise qualitativa. Essa técnica consiste em realizar uma simulação de custo e tempo a partir de estimativas para cada atividade do projeto. A figura 31 apresenta um exemplo da tela de simulação. Nessa tela o gerente deverá informar uma estimativa mínima, uma mais provável e outra máxima referente ao custo e ao tempo de cada atividade do projeto. A partir dessas informações serão gerados gráficos com as probabilidades de conclusão de custo e tempo dentro dos prazos estimados, conforme exemplo de custo na figura

66 Figura 31 Protótipo Simulação do Projeto Figura 32 Protótipo Gráfico da Simulação de Custo Planejamento de resposta ao risco Assim que os riscos estiverem analisados, poderá ser criado o plano de resposta para os riscos que oferecerem maior perigo aos objetivos do projeto. Segundo o RUP (2003), a empresa deve trabalhar no máximo com os dez maiores riscos para cada projeto. O objetivo desse planejamento é definir um plano de resposta aos riscos identificados do projeto, com estratégias e atividades para combater os riscos. A figura 33 apresenta um exemplo da tela de planejamento de resposta ao risco. Nessa tela o gerente deverá informar a data do planejamento, a estratégia a ser utilizada, o responsável por gerenciar o risco, a descrição da estratégia a ser realizada, as 66

67 atividades e o plano de contingência. Na página Histórico, dessa mesma tela, encontram-se todas as alterações realizadas no plano de resposta. Figura 33 Protótipo Planejamento de resposta ao risco Esse programa permite também exportar as atividades de combate aos riscos de um projeto para serem usadas pelo software de gestão de projetos Microsoft Project 12, ou seja, essas atividades poderão ser importadas por este software e serão vinculadas ao cronograma do projeto. A figura 34 apresenta um exemplo da tela para exportar as atividades. Figura 34 Protótipo Exportar atividades para o Project 12 Maiores informações em < 67