Renata Miranda Pires Boente

Transcrição

1 Uso do Modelo Qualitativo de Análise de Risco (Karolak) na Gestão de Projetos de TI: Um estudo de caso na Justiça Federal de Primeiro Grau Seção Judiciária do Rio de Janeiro Renata Miranda Pires Boente Justiça Federal - Seção Judiciária do Rio de Janeiro (TRF-RJ) Av. Rio Branco, Rio de Janeiro - RJ - Brasil boente.renata@gmail.com Resumo. Administrar riscos é tarefa primordial para tudo que se faz na vida. O gerenciamento de riscos é um processo que está diretamente envolvido com a gestão de projetos (PMI Standards Committee, 2013, p. 78). Portanto, quando se ouve fala em gestão de projetos de sistemas de informação é impossível não estar falando em gerenciamento de riscos, visto que não existem projetos com risco zero, por mais perfeito que ele aparente ser. O objetivo deste artigo é apresentar uma abordagem do modelo qualitativo de Karolak para gerenciamento de riscos de projetos de sistemas de informação na Justiça Federal de Primeiro Grau Seção Judiciária do Rio de Janeiro. 1. Introdução Com o advento da globalização, as empresas precisam se adequar para poder estar concorrendo a um lugar no mercado competitivo seja com produtos ou prestação de serviços de qualquer natureza. Independentemente do tipo de projeto, imprevistos certamente podem ocorrer. Por este motivo, riscos precisam ser previstos em projetos. Riscos em projetos de sistemas de informação são condições que, caso venham ocorrer, podem comprometer ou impedir a realização de um projeto. A necessidade de gerenciar riscos decorre, principalmente, da constatação de que a quantidade e diversidade dos riscos de projeto excedem o montante de recursos alocados para neutralizar todos esses riscos durante a execução de certo projeto. Essa situação demanda que os riscos devam ser priorizados ou "gerenciados" adequadamente. Assim, uma modelagem qualitativa dos riscos nos ajuda a identificar, analisar e tratar dos possíveis riscos de projetos de sistemas de informação. Neste viés buscou-se, através do Modelo Karolak, tratar de modo qualitativo, as fases do gerenciamento de projetos de TI na Justiça Federal de Primeiro Grau Seção Judiciária do Rio de Janeiro, com ênfase na análise de riscos. 2. Gerenciamento de Riscos Boente (2003, p. 90) afirma que o gerenciamento, gerência ou gestão de riscos do projeto inclui os processos envolvidos na identificação, análise e resposta aos riscos do projeto. Gerenciamento de riscos possibilita a chance de melhor compreender a natureza do projeto, envolvendo os stakeholders da equipe de projetos de modo a identificar as

2 potenciais forças e riscos do projeto e responder a eles, geralmente associados a tempo, qualidade e custo (Vargas, 2002, p. 84). Segundo Alencar e Schmitz (2005, p. 24), a gerência de risco é um conjunto de atividades que tem por objetivo, de uma forma economicamente racional, maximizar o efeito dos fatores de risco positivos e minimizar o efeito dos negativos. Administrar riscos não é uma tarefa muito fácil, porém necessária para que seu projeto possa ser concluído com êxito e sucesso, sem incertezas e fracassos. Schmitz, Alencar e Villar (2006, p. 20) afirmam que para determinar as chances de sucesso do projeto, devemos, primeiramente, definir quais são os critérios que serão utilizados para o estabelecimento do seu eventual sucesso ou fracasso. Gambôa, Caputo e Bresciani Filho (2004, p. 50) afirmam que [...] projetos têm uma grande quantidade de riscos associados que podem comprometer o sucesso da implementação. As técnicas de gestão de riscos devem identificar, minimizar e controlar os riscos durante todo o projeto. Para auxiliar na gerência de riscos em projetos, cuja prioridade é o prazo, visando gastar mais tempo planejando as contingências, é que buscou-se o Modelo Qualitativo de Karolak, voltado para a análise de riscos de projetos de TI, de acordo com PMI Standards Committee (2013, p. 101). 3. Modelagem e Análise de Risco Ao se comparar incerteza do risco com a quantidade arriscada, tem-se que no início de um projeto de sistema de informação, o nível de incerteza é elevado, mas a quantidade arriscada é pequena uma vez que se está em uma fase inicial (Vargas, 2002, p. 35). O gerenciamento de riscos envolve diversas atividades durante o planejamento do projeto. A este processo dá-se o nome de análise de riscos. Segundo Schmitz, Alencar e Villar (2006, p. 24) [...] análise de risco envolve um conjunto de atividades que visa identificar os fatores de riscos e da execução das atividades contingenciadas, requeridas para tratar o aparecimento dos fatores de risco. A quantificação dos riscos envolve a avaliação dos riscos e suas interações para previsão de prováveis resultados do projeto (Boente, 2003, p. 91). Sabe-se que essa análise de riscos pode ter uma abordagem tanto qualitativa quanto quantitativa. Um processo é um conjunto de atividades encadeadas. O gerenciamento de riscos é um processo da gestão de projetos de TI, que tecnicamente é dividido em análise de riscos e controle de riscos, conforme pode ser observado na Figura 1. O processo de análise de riscos envolve as atividades de identificação dos objetivos do projeto de sistema de informação, identificação dos fatores de riscos, estimação do impacto dos fatores de riscos, definição das ações de tratamento dos riscos e redefinição do planejamento do projeto. Boente (2003, p. 49) afirma que a atividade de identificação dos objetivos traçados para o projeto determina quais os critérios de sucesso, os procedimentos e recursos necessários. Na fase de identificação de riscos, o gerente do projeto e sua equipe procuram identificar os fatores de riscos a que o projeto está exposto (Alencar e Schmitz, 2005, p. 37).

3 Figura 1. Processo de Gerenciamento de Riscos Fonte: Alencar e Schmitz, 2005 Schmitz, Alencar e Villar (2006, p. 26) afirmam que é necessário fazer a estimativa tanto da probabilidade de ocorrência do fator de risco quanto de seu impacto em cada um dos objetivos do projeto. Dependendo da probabilidade e do impacto de cada um dos fatores de riscos as ações de eliminar, contingenciar e ignorar, são definidas como ações de tratamento dos riscos. O desenvolvimento das respostas dos riscos envolve definir os passos necessários para o aproveitamento das oportunidades e respostas às possíveis ameaças existentes para um determinado projeto. Boente (2003, p. 92) afirma que as respostas às ameaças geralmente se enquadram em uma das três categorias: evitar, mitigar e aceitar. O monitoramento e a execução das atividades de contingências são atividades que compõem o processo de controle de riscos de um projeto. Vargas (2002, p. 87) afirma que se tratando de gerenciamento de riscos, é importante que se atente para os seguintes aspectos: compreensão do projeto, produto ou processo a ser empreendido; identificação dos elementos do projeto sujeito a riscos; desenvolvimento de uma lista de ameaças e fraquezas para cada elemento; priorização das ameaças e as fraquezas; identificação dos impactos; identificação dos controles a serem adotados para evitar, ou minimizar os impactos; criação de controles alternativos para quando os controles principais não forem efetivos e geração de documentação base para futuros projetos. 4. Aplicação do Modelo de Karolak: Caso Justiça Federal de Primeiro Grau Seção Judiciária do Rio de Janeiro Em gerenciamento de riscos, os riscos e as contingências do processo de desenvolvimento de software devem ser minimizados (Karolak, 1996, p. 13). Karolak utiliza o modelo de estimativa de risco qualitativo SERIM (Software Engineering Risk Model). Esse modelo utiliza três critérios de sucesso, dez categorias de risco e oitenta e um fatores de risco onde para cada fator de risco é atribuído o valor 0 ou 1 e, os riscos

4 de cada um dos três critérios de sucesso são determinados pela soma ponderada dos valores das categorias, e a probabilidade de sucesso do projeto é a média ponderada das probabilidades dos três fatores de sucesso (Schmitz, Alencar e Villar, 2006, p. 80). Aplicando o modelo Karolak ao caso da Gestão de Projetos de TI na Justiça Federal de Primeiro Grau Seção Judiciária do Rio de Janeiro, cujo objetivo é a implantação de um novo sistema de informação que viesse auxiliar na Prestação Jurisdicional do TRF/RJ, Rio de Janeiro. Na primeira etapa foi passado o questionário do modelo SERIM e foram levantadas objetivando levantar todas as respostas necessárias para aplicação do modelo Karolak, com base nas dez categorias apresentadas a seguir: C1) Quanto à Categoria Organização O1: O gerente de projeto tem mais de 20 anos de experiência em desenvolvimento de Software 1,0 Só gerentes com grande experiência serão utilizados. O2: A tecnologia de implementação nunca foi utilizada na empresa 0,0 Nenhuma vez O3: A empresa possui uma estrutura organizacional formal 1,0 Estrutura organizacional formal O4: Com o resultado da fusão, espera-se que a estrutura organizacional mude bastante durante o decorrer do projeto de TI 0,0 Muda frequentemente O5: O gerente de projeto de TI é conhecido por sua garra e dedicação à empresa 1,0 Alta confiança O6: A distância física entre as equipes do TRF/RJ e TRF/ES, segunda região, faz com que a comunicação seja regular 0,5 Comunicação regular O7: O processo de gerência de configuração na empresa ainda é incipiente 0,0 Muito pouca ou nenhuma O8: O TRF não possui uma equipe dedicada ao controle de qualidade 0,0 Muito pouca ou nenhuma C2) Quanto à Categoria Estimação E1: Os conflitos entre as partes interessadas no projeto faz pressão sobre as estimativas

5 0,3 Ditado pelas circunstâncias E2: A empresa não tem nenhum modelo para estimativa de custo 0,0 Nenhum modelo é utilizado E3: O TRF não possui medidas de produtividade de sua equipe E4: Como os dados históricos não são coletados, não é possível fazer estimativas E5: As estimativas são revistas sempre que existe uma pressão no prazo 0,5 Atualizadas, porém não mensalmente E6: Sabe-se que as estimativas de custos são da ordem de 50% 0,5 50% de diferença E7: As estimativas anteriores de prazo são piores 0,0 100% de diferença C3) Quanto à Categoria Monitoramento M1: O plano inicial do projeto define metas intermediárias para todas as fases 1,0 Existem metas intermediárias que permitem acompanhar todas as fases M2: O plano inicial foi definido a partir de um WBS 1,0 Utiliza WBS adequadamente M3: Não existe um processo formalizado para acompanhamento M4: O gerente do projeto gera relatórios atualizados de custos e prazos sob demanda 0,5 Sim sem atualização mensal M5: Alguns relatórios de acompanhamento são atualizados mensalmente 0,5 Atualizadas, porém não mensalmente M6: O estilo gerencial do TRF é apagar incêndios. Não existe um sistema para registro formal de problemas 0,0 Nenhum registro formal M7: Os problemas técnicos encontrados são sempre resolvidos, porém sempre de uma forma ad-hoc 0,0 Nenhum recurso específico

6 C4) Quanto à Categoria Metodologia de Desenvolvimento DM1: O TRF não possui uma metodologia de desenvolvimento de software DM2: Os desenvolvedores de software não estão treinados na metodologia DM3: A metodologia não é seguida a risca DM4: A metodologia inclui pouca ou nenhuma revisão e inspeção de código, projeto e requisitos 0,0 Pouco ou nenhum DM5: A metodologia não requer planos de testes para todos os componentes de software DM6: A metodologia não requer documentação dos requisitos, projeto e demais atividades de desenvolvimento requer DM7: Testes de regressão são executados em alguns casos 0,5 Sim, em alguns casos C5) Quanto à Categoria Ferramentas T1: A gerência do projeto de TI já tinha providenciado um treinamento na equipe antes do início do projeto 0,5 Algum treinamento T2: O ambiente de desenvolvimento a ser utilizado possui alguns recursos de projeto 0,5 Alguma ferramenta é utilizada ou a que é utilizada não corresponde adequadamente T3: A equipe pretende utilizar ferramentas automatizadas somente para testes de carga 0,5 Algum ferramenta ou a que é utilizada não é adequada T4: A empresa ainda está estudando a compra de uma ferramenta para a geração automática de caso de teste 0,5 Alguma ferramenta é utilizada ou a que é utilizada não é adequada T5: O TRF não dispõe ferramentas para teste

7 T6: Não são utilizadas ferramentas automatizadas para rastreamento de requisitos T7: Não são utilizadas ferramentas automatizadas para reengenharia T8: O ambiente de desenvolvimento a ser utilizado é bastante estável e documentado 1,0 Muito estável e sem problemas T9: Todas as ferramentas estão disponíveis a qualquer hora 1,0 Todas C6) Quanto à Categoria Cultura de Risco RC1: A empresa está almejando assumir alguns riscos de orçamento adicionais por uma melhor margem de lucro 0,5 Alguma troca RC2: A empresa está almejando assumir alguns riscos de prazos adicionais por uma melhor margem 0,5 Alguma troca RC3: A empresa está almejando assumir menores riscos técnicos por uma melhor margem 0,5 Alguma troca RC4: A empresa não está almejando assumir menores riscos de orçamento por menores lucros 1,0 Não nenhum RC5: A empresa não está almejando assumir riscos de cronograma adicionais por uma melhor margem 1,0 Não nenhum RC6: A empresa não está almejando assumir menores funcionalidades técnicas por menores lucros 1,0 Não, nenhuma RC7: A empresa é totalmente orientada ao mercado 0,0 Sim, totalmente RC8: A cultura da empresa é muito conservadora na tomada de decisões 1,0 Sim, conservadora RC9: Os investimentos em tecnologia por parte da empresa tendem a ser moderados

8 0,5 Investimentos moderados RC10: A empresa tende tanto a adquirir quanto a desenvolver novos produtos de tecnologia 0,5 Existe um mix de produtos desenvolvidos e adquiridos RC11: A empresa não pratica o Gerenciamento de Riscos C7) Quanto à Categoria Usabilidade U1: Não irá existir manual de usuário U2: Para algumas telas existirá ajuda on-line 0,5 Algumas das telas possuem U3: O usuário está totalmente envolvido na revisão dos protótipos ou nas primeiras versões do software 1,0 Usuário totalmente envolvido U4: As interface terão formato padrão de indústria 1,0 Padrões de indústria ou do usuário são seguidos U5: O usuário estará disponível para consulta 0,5 Muitas vezes U6: O design foi totalmente avaliado para minimizar as operações de teclado e entrada de dados 1,0 Sim, todo o design foi avaliado C8) Quanto à Categoria Correção C1: Todos os requisitos foram paulatinamente identificados e documentados 0,5 Sim, paulatinamente C2: Quase todos os requisitos foram identificados no projeto de software 0,5 Alguns C3: Todos os requisitos serão identificados na codificação 1,0 Sim, todos C4: Quase todos os requisitos serão identificados nos procedimentos de teste 0,5 Sim, alguns C5: Esperam-se poucas mudanças nos requisitos especificados 1,0 Sim poucas (1 por mês) C6: O projeto do software será parcialmente rastreado no código

9 0,5 Algumas das características serão rastreadas C7: O projeto do software está parcialmente rastreado nos procedimentos de teste 0,5 Algumas das características serão rastreadas C8: Vários itens de ações do software serão implementados antes da entrega do cliente 0,5 Alguns C9: Todos os procedimentos de teste serão executados antes da entrega ao cliente 1,0 Sim, todos C9) Quanto à Categoria Cultura de Risco R1: Para algumas situações existirá tratamento de execução no código 0,5 Algumas R2: Em alguns casos o software continuará rodando quando houver erro detectado 0,5 Em alguns casos R3: Algumas tolerâncias foram definidas para erros de entrada e saída de dados 0,5 Alguns níveis de tolerância foram definidos R4: Todas as entradas de dados ao software serão validadas antes do processamento ser iniciado 1,0 Sim, todos os dados serão validados R5: Alguns defeitos de hardware serão detectados 0,5 Sim, alguma detecção será implementada R6: Não será feito uso de variáveis globais 1,0 Totalmente restrito ao uso R7: Serão coletados parcialmente dados de problemas durante a integração dos componentes de software 0,5 Sim, em parte R8: Nem todos os dados de problemas serão registrados e eliminados antes da entrega ao cliente 0,5 Alguns serão registrados e eliminados R9: Nenhum modelo será utilizado para predicação do nível de confiabilidade do software, nenhum R10: Todos os testes serão executados com plano de teste

10 1,0 Todos os testes serão executados seguindo um plano R11: Testes de estresse serão executados em todo o software 1,0 Sim, em todo o software R12: Os testes serão parcialmente executados por um grupo diferente do de software 0,5 Parte do software será testado por um grupo independente C10) Quanto à Categoria Pessoal P1: Toda a equipe está identificada e disponível 1,0 Todos P2: A experiência da equipe no software a ser desenvolvido é praticamente inexistente 0,0 Nenhuma experiência P3: A experiência da equipe no ambiente de desenvolvimento do software é nenhuma 0,0 Nenhuma experiência P4: A equipe não tem experiência na linguagem de implementação 0,0 Nenhuma experiência P5: Poucas pessoas estarão trabalhando em determinado momento durante o desenvolvimento do software 1,0 Pequeno (menos de 20) Tabela 1. Influência das Categorias de Risco nos Critérios de Sucesso Categoria Média Técnico 0,49 Custo 0,39 Cronograma 0,39 Fonte: Elaboração própria Após o levantamento inicial, o modelo SERIM, sugeri calcular as probabilidades de sucesso (médias aritméticas dos fatores de riscos associados à categoria de risco) de cada uma das categorias de risco P(C k ), mostrado na Tabela 1, onde 1 k 10, utilizando a fórmula: P( C k ) f j i P( n Fr j )

11 risco; risco. Onde: 1 k 10; P(C) é a probabilidade de cada uma das categorias de risco; i é a métrica inicial e f a métrica final; P(Fr) é a resposta de cada fator de risco associado à categoria de n é a quantidade de fatores de risco associados à categoria de Em seguida, se deve calcular a probabilidade dos critérios de sucesso a serem atingidos, conforme ilustra a Tabela 2, com base na seguinte fórmula: P( CS k ) 10 j 1 10 W[ j, k] P( j 1 W[ j, k] C j ) risco; Onde: 1 k 3; P(CS) é a probabilidade de cada critério de sucesso a ser atingido; P(C) é a probabilidade de sucesso em cada uma das categorias de W é o peso da influência do fator de risco. Tabela 2. Relação dos Fatores de Risco com as Categorias de Risco Código Categorias Valor C1 Organização 0,44 C2 Estimação 0,19 C3 Monitoramento 0,43 C4 Metodologia 0,07 C5 Ferramentas 0,39 C6 Cultura de Risco 0,58 C7 Usabilidade 0,67 C8 Correção 0,69 C9 Confiabilidade 0,63 C10 Pessoal 0,40 Fonte: Elaboração própria

12 Finalmente, calcula-se a probabilidade de sucesso do projeto a ser implementado, conforme ilustra a Figura 3, usando a fórmula: 3 1 P( ) j j P ( SUCESSO) 3 Onde: P(SUCESSO) é a probabilidade de sucesso do projeto de TI; P(C) é a probabilidade de cada uma das categorias de risco. C Tabela 3. Influência das Categorias de Risco nos Critérios de Sucesso Probabilidade Projeto 0,42 Fonte: Elaboração própria Neste estudo, o valor calculado da probabilidade de sucesso do projeto foi de 42%, o que é considerado relativamente baixo para uma tomada de decisão de implantar um novo sistema de informação dedicado a Prestação Jurisdicional na Justiça Federal de Primeiro Grau Seção Judiciária do Rio de Janeiro. Categoria de Risco Organização Estimação Monitoramento Metodologia Ferramentas Cultura de Risco Usabilidade Ação Montar uma equipe dedicada à gerência do projeto. Esta equipe deve incluir pessoas de comunicação, garantia de qualidade e de gerência de configuração de software. Contratar uma consultoria externa para fazer estimativas para o custo e prazo do projeto usando modelos de análise de risco. Contratar uma consultoria externa para elaborar o plano de acompanhamento do projeto. Selecionar duas empresas para o desenvolvimento do sistema. A primeira especializada em requisitos deve ficar encarregada em produzir uma especificação do sistema. A segunda deve ser uma fábrica de software que comprove competência no uso de metodologia de desenvolvimento de sistemas. Selecionar uma fábrica de software que comprove competência no conhecimento e uso de ferramentas automatizadas. Contratar um especialista para fazer uma palestra sobre cultura de risco destinada à direção da empresa. Definir um grupo, formado por funcionários da casa, com o objetivo de testar e aprovar a interface do sistema.

13 Correção Confiabilidade Pessoal Essa categoria requer duas ações: determinar que alguém técnico seja responsável pela aprovação da implementação e que a fábrica de software tenha processos formais de inspeção e verificação dos produtos gerados como parte de seu processo. Colocar no contato com a fábrica de software os critérios desejados para os testes de sistema. Estes critérios devem incluir os valores de carga e a confiabilidade do sistema a ser entregue. Explicitar no contato com fornecedores a quantidade e disponibilidade da equipe que vai participar tanto da especificação como da implementação do sistema. Quadro 1. Procedimentos a serem adotados pela Stylus On-Line Fonte: Elaboração própria Portanto, algumas ações necessárias devem ser tomadas pelo TRF para inverter esse quadro inicial, conforme ilustra o Quadro 1. Desta forma, após o TRF adotar tais procedimentos, a empresa alcançara algo em torno de 90%, para as categorias que dependam de fornecedores externos, e no mínimo, 80%, para aquelas categorias que dependam da equipe interna. Estes valores, 0,90 e 0,80, tornar-se-iam mais que suficientes para uma tomada de decisão de expansão da empresa em três estados diferentes, pois ao reaplicar as fórmulas aos novos valores encontrados, obter-se-ia 0,86, ou seja, 86% como valor da probabilidade de sucesso do projeto de TI dar efetivamente certo. 5. Considerações Finais O gerenciamento de riscos requer identificar, analisar e responder aos riscos inerentes de certo projeto. A fase de análise de riscos pode ter tanto uma abordagem qualitativa quanto uma abordagem quantitativa. Neste artigo foi explorada a abordagem qualitativa através do modelo Karolak. Esse modelo é bem abrangente e minucioso onde através do exame de dez dimensões de riscos distintas (organização, estimativas, monitoramento, metodologia de desenvolvimento, ferramentas, cultura de risco, usabilidade, correção, confiabilidade e pessoal) procura-se responder oitenta e uma perguntas buscando avaliar se um projeto é viável de ser implementado, se será entregue dentro do prazo e custo e se será executado conforme os requisitos pré-estabelecidos. Em consideração ao baixo valor encontrado para a probabilidade de sucesso do projeto de TI do TRF, 42%, aconselhou-se algumas ações necessárias para inversão do valor crítico obtido para uma tomada de decisão efetivamente segura. Por ser um modelo bem abrangente, pode ser aplicado a outros tipos de projeto de TI, independentemente desse projeto ser ou estar dedicado à uma instituição pública ou privada.

14 Referências Alencar, A.J., Schmitz, E.A. (2005) Análise de Risco em Gerência de Projetos. Rio de Janeiro: Brasport. Boente, A.N.P. (2003) Gerenciamento e Controle de Projetos. Rio de Janeiro: Axcel Books. Gambôa, F.A.R., Caputo, M.S., Bresciani Filho, E. (2004) Risk Management Method to ERP Systems Implementation Based on Critical Success Factors. Revista de Gestão da Tecnologia e Sistemas de Informação. Journal of Information Systems and Technology Management Vol. 1, No. 1, 2004, pp Karolak, D.W. (1996) Software Engineering Risk Management. IEEE Computer Society Press. PMI Standards Committee. (2013) A guide to the project management body of knowledge (PMBOK Guide). 8. ed. USA. Schmitz, E.A., Alencar, A.J., Villar, C.B. (2006) Modelos Qualitativos de Análise de Riscos para Projetos de Tecnologia da Informação. Rio de Janeiro: Brasport. Vargas, R. V. (2002) Gerenciamento de Projetos: Estabelecendo Diferenças Competitivas. 3. ed. Rio de Janeiro: Brasport.