M ODELAGEM DO P ROTÓTIPO

A metodologia de gerenciamento de riscos do PMBOK é muito rica de informações e já foi bem referenciada no capítulo 3.3 e, portanto, não será novamente discutida aqui. No entanto, com o intuito de extrair os principais processos da metodologia, faz-se necessário entrar novamente na metodologia para tirar um “raio x” de sua estrutura principal.

Para que o protótipo venha a ter condições de suportar a metodologia, é necessário que os principais processos da metodologia sejam corretamente representados dentro da ferramenta. São seis os processos e, o resultado de cada um serve de entrada para o próximo. São eles:

• Planejamento da Gerência de Risco;

• Análise Qualitativa dos Riscos;

• Análise Quantitativa dos Riscos;

• Planejamento de Resposta a Riscos;

• Controle e Monitoração de Riscos.

Esse é o “raio x” da metodologia de gerenciamento de riscos escolhida e que serviu de norte para o desenvolvimento do protótipo.

Visto que existem diferentes papéis no que diz respeito a gerência de riscos, fez-se necessário distinguir os diferentes tipos de usuários do protótipo. Num primeiro nível estaria o gerente do projeto e em outros níveis os Stakeholders. Além desta distinção, existe ainda a distinção entre os membros do projeto, pois alguns podem estar apenas acompanhando o projeto e outros muito mais envolvidos, colaborando nas diversas fases do mesmo. Assim sendo, surgiu a necessidade de diferenciar os tipos de acessos de cada participante do projeto.

Numa visão macro, o sistema deve possibilitar ao gerente de projetos a manutenção do(s) seu(s) projeto(s), riscos e usuários que fazem parte da sua equipe de trabalho. Os membros do projeto passam a ter acesso às informações do projeto e os riscos envolvidos no mesmo, de acordo com seu perfil (classe) de usuário. Surgiu também a visão de um administrador da ferramenta, que seria o responsável por criar as contas dos gerentes de Projetos. A Figura 20 (pg.54) exemplifica melhor esta visão.

Para entender melhor a proposta, vamos expandir a visão para cada uma das funcionalidades do protótipo.

Por ordem de funcionalidade, vamos analisar a visão “Definir Usuários”, como é ilustrado na Figura 21. Existem apenas dois perfis de usuários que teriam acesso a essa funcionalidade, o usuário administrador e o gerente. O usuário administrador pode criar usuários e suas principais funções seriam a de atribuir ao usuário o perfil de gerente de projeto e também excluir usuários da ferramenta.

O usuário com perfil de gerente de projeto tem acesso completo em todas as atividades de seu projeto, diferente do que ocorre com um membro do projeto. Porém, o administrador não tem o poder de definir a qual projeto o usuário irá pertencer e tão pouco apontar o papel dele no projeto. Esse é um papel que só diz respeito ao perfil de gerente do projeto.

Para a criação de usuários, são necessárias algumas informações básicas, como por exemplo, nome do usuário, telefone, e-mail entre outras. Isso está representado no diagrama através da função de “Incluir Informações do Usuário”.

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

Outra função representada no diagrama é o de atribuir um login e senha para o usuário.

Apesar da metodologia não fazer nenhuma menção a tipos de usuários, existe sim a distinção do Gerente do Projeto e dos demais membros do mesmo. Existe ainda uma referência aos papéis de cada membro da equipe no projeto. Portanto, para representar essa hierarquia e ao mesmo tempo para tornar os dados do projeto mais seguro, fez-se esta classificação.

Essa distinção de usuários se torna ainda mais perceptível quando expandimos a visão “Manter Riscos”, conforme ilustrado na Figura 23 (pg.60). O membro do projeto terá o acesso às informações que o seu perfil de usuário permitir.

Os níveis de acesso foram classificados em “Simples”, “Colaborador” e “Avançado”. O perfil de acesso “Simples” é o mais básico de todos. Só permite a visualização dos riscos. O acesso de “Colaborador” só libera o acesso aos riscos, mas este por sua vez já possui a liberdade de fazer alterações, adicionar e remover riscos. Por fim, o perfil de usuário “Avançado” permite total liberdade de ação na área de riscos e ainda permite visualizar todas as informações referentes ao projeto.

Na visão “Manter Projeto”, conforme ilustrada na Figura 22 (pg.59), temos toda a estrutura do projeto. É lá que serão inseridas as informações gerenciais do projeto. O primeiro (um dos mais trabalhosos para o gerente de projetos) dos seis processos, o Planejamento da Gerência de Riscos, está caracterizado de forma bem explícita nessa modelagem. Se olharmos a metodologia com atenção, veremos que este processo é um dos mais importantes e de maior volume de informações. Por se tratar do processo inicial e de planejamento de toda a gerência de riscos, ele teve um destaque especial no protótipo. Assim sendo, as seguintes funções do primeiro processo foram atribuídas ao protótipo: descrição do projeto; a forma com que os riscos serão lidados e conseqüentemente a tolerância aos riscos; a metodologia que será utilizada ao longo do projeto; a definição do orçamento para a gerência de riscos; escolha dos membros da equipe, seus papéis e permissões.

A definição da matriz de impacto embora também seja ligado ao planejamento da gerência de riscos está totalmente relacionada a outros dois processos, o de “Análise Qualitativa” e “Análise Quantitativa”, servindo como base para os cálculos e análises realizados nestes processos.

Três dos seis processos principais da gerência de riscos já foram abordados na modelagem até aqui. Para entender como os outros três processos são suportados no protótipo, vamos focar as atenções na visão “Manter Riscos” que está representada na Figura 23 (pg.60).

Embora muitas funções são utilizadas em mais de um processo, isto é, são utilizadas explicitamente num processo e servem como apoio e tomadas de decisão nos outros processos, vamos procurar separar as funções para que se possa ter uma visibilidade dos processos da metodologia.

A função de descrever o risco faz parte do processo de “Identificação do Risco”. Embora as funções relacionadas ao risco, como por exemplo “Indicar a Área Afetada” e “Descrever os Sintomas dos Riscos” possam parecer que fazem parte do processo de “Identificação dos Riscos”, elas não fazem. Estão relacionadas com o processo de “Planejamento de Resposta a Riscos” que além destas funções ainda possui outras, como por exemplo, a função de “Atribuir Responsabilidades”.

Outras funções fazem parte desse processo, mas se fundem com os processos de “Análise Qualitativa” e “Análise Quantitiva” como por exemplo, as funções “Definir Ações de Mitigação ou Contingência”, “Determinar o Impacto no Projeto”, “Determinar a Probabilidade“ e “Determinar o Impacto no Objetivo do Projeto.

Por fim, o processo de “Controle e Monitoração de Riscos” está caracterizado através da função de ”Acesso Histórico de Aç ões”, contudo, não fica restrito a apenas esta função, uma vez que a ferramenta permitirá alterações nas informações dos riscos ao longo do projeto como, por exemplo, a mudança de status do risco, de impacto e criticidade.

Estas visões podem parecer um tanto quanto confusas. Existem funções servindo para mais de um processo e ações que são o resultado da saída de um ou mais processos e, todas, sendo exibidas em uma única modelagem. Embora a modelagem dê margem para tal interpretação (confusão), ela passa a ser muito clara no momento que os processos da metodologia de gerenciamento de riscos são bem conhecidos, pois a própria metodologia força uma interação entre os processos, criando um ciclo que só terminará quando o projeto for concluído.

Levando em conta o resultado obtido com a modelagem de “Use Case” proposta, o próximo passo foi de modelar as classes do protótipo. A Figura 24 (pg.62) é o resultado final do diagrama de classes em UML.

A classe “Projeto” se tornou a principal classe em virtude de todas as atividades estarem relacionadas ao projeto. Ou seja, não há riscos ou pessoas gerenciando riscos sem que estes estejam alocados a um projeto.

Existe ainda uma herança no diagrama, a classe “Membro” herda as propriedades da classe “Pessoa” e o relacionamento da classe “Membro” com a classe “Projeto” gera uma outra classe, que é a de “Permissões”. Nesse relacionamento estará definido que tipo de acesso cada usuário terá nas informações de cada projeto.

Tendo em vista que o diagrama de classes é auto-explicativo e que o diagrama de “Use Case” já explicou os objetivos de funcionalidade do protótipo, o próximo passo é o de desenvolvimento do protótipo.