Gerência de riscos em desenvolvimento de software

O processo de desenvolvimento de software envolve muitos fatores, por isso é necessário ter muita cautela e planejamento antes de começar a desenvolver, caso contrário, erros graves podem ocorrer durante as várias etapas a serem cumpridas, o que pode comprometer as demais, ao ponto de a única solução ser abortar o projeto.

Autores: Gabriel Dias Junckes e Paulo Morgado. Universidade do Sul de Santa Catarina (UNISUL).

Planejar não é uma atividade muito fácil, desenvolver então, menos ainda, o que acontece em uma empresa de desenvolvimento de software já bem consolidada, é a execução de atividades antes, durante e depois do desenvolvimento de um projeto. É na etapa de planejamento que se encontra uma grande parte do enfoque deste artigo. Todos os dias ao saírem de casa, pessoas correm riscos, risco de ser assaltadas, de torcer o pé e cair, de perder o ônibus, de pegar chuva, etc. O que evita o fato de esses riscos se tornarem uma realidade é a prevenção, ou seja, não andar com objetos valiosos a mostra, usar um sapato adequado, sair de casa a tempo de não perder o ônibus, levar guarda-chuvas, etc. O mesmo acontece com os projetos de software, ao fazer um planejamento dos custos e do tempo, por exemplo, é necessário prever os riscos de o projeto atrasar ou se tornar caro demais. Há algumas maneiras de se prevenir contra os fatores que podem vir a atrapalhar o bom andamento de um projeto de software, entre elas destaca-se identificar e analisar possíveis riscos e planejar respostas para controlar e monitorar a ocorrência de atividades indesejáveis ao projeto.

Fixação dos objetivos

Os objetivos precisam estar muito bem claros antes de fazer a identificação de riscos, pois ajuda a identificar e classificar melhor todos os riscos de um projeto. A identificação e mapeamento de todos os objetivos facilitam a visualização dos ricos, o planejamento de respostas, melhora a produtividade do projeto, com foco melhor nas atividades que podem ser mais bem direcionadas.

Identificação dos Riscos

A etapa de identificação dos riscos se encontra no planejamento do projeto, porém também é uma atividade a ser executada durante todo o desenvolvimento, só que em menor grau de detalhe.

Figura 1: Identificação dos riscos Fonte: [LMDM 2008]

Para uma boa identificação de riscos, pode-se fazer uso de tabelas ou planilhas para listá-los, há na literatura de engenharia de software abordagens que têm uma tabela pronta de riscos externos (Tabela 1) e internos (Tabela 2), com os riscos ao desenvolvimento de software, é claro que cada organização é diferente e vai identificar riscos particulares ao seu projeto, contudo é bom ter uma boa base para iniciar o processo de identificação.

Tabela 1: Identificação dos riscos externos

Tabela 2: Identificação dos riscos internos

Os riscos citados acima nas tabelas um e dois, que foram obtidos no livro de [FACCIONI 2011], são genéricos, servem para qualquer tipo de projeto de desenvolvimento de software, cabe á organização, na fase de planejamento, obter uma lista mais detalhada dos riscos de problemas que possam ocorrer dentro do seu contexto.

Identificação de Eventos

A definição de um evento pode ser feita através de uma ocorrência que podem ser originadas através de fontes internas ou externas que influenciam nos objetivos de forma positiva, negativa ou ambas.

Os eventos em potenciais, internos ou externos, que trarão impacto negativo exigem uma análise e um planejamento de uma resposta. Também podemos considerar os eventos de impacto positivo, esses representam oportunidades para ajudar os objetivos a serem alcançados.

Com o objetivo de melhorar a análise dos eventos, pode ser útil fazer o agrupamento por categorias. Através dessas informações podemos formar uma base mais consolidada de informações, é possível ter uma visão melhor sobre as semelhanças, grau de completude de seus esforços e outras informações que irão facilitar a identificação de riscos. As categorias podem ser feitas de acordo com as necessidades do objetivo, alguns exemplo de classificação abaixo:

• Econômicos
• Meio Ambiente
• Políticos
• Sociais
• Tecnológicos

Análise dos riscos

Feita a identificação, o próximo passo é analisar os riscos listados, um por um detalhadamente, a fim de obter o grau de periculosidade de cada risco, isto é, inserir os riscos em uma nova lista categorizando-os e nivelando-os.

Quanto às categorias, elas variam de acordo com o escopo do projeto e os recursos que a empresa possui, segundo [NAKASHIMA 2004], as mais comuns são: técnica, programática, suporte, custo e cronograma. Os níveis de risco estão relacionados com seu grau de periculosidade para o bom andamento do projeto, o nível de um risco é inversamente proporcional ao quanto de dano ele pode causar, ou seja, se o problema for atrasar a entrega do projeto ou aumentar o seu custo, provavelmente o nível será entre um e quatro, pois este é um problema grave.

Para dar continuação a fase de análise dos risos é preciso realizar um planejamento, abrangente o suficiente para saber o que fazer se caso um risco venha a se tornar uma realidade. O ideal é que esse planejamento esteja documentado e a gerência do projeto tenha pleno conhecimento sobre o mesmo. Segundo [PRITCHARD 2001] é necessário identificar os riscos, mas não há a necessidade de gerenciar todos, apenas os que realmente valerem a pena o esforço, essa decisão de escolha entre gerenciar um risco ou não, geralmente cabe ao líder, apoiado logicamente por sua equipe técnica. Fazem parte da etapa de análise, a investigação qualitativa e quantitativa, quando se busca saber como um problema pode afetar o andamento do projeto, é uma análise qualitativa, já a quantitativa é quando se busca saber o quanto o projeto vai atrasar por conta daquele problema, ou então quanto o projeto vai custar a mais se um determinado problema não for resolvido.

Análise qualitativa

Ao iniciar uma análise qualitativa dos riscos de um projeto de software, o principal objetivo é obter uma classificação dos riscos em categorias, bem como listas relacionando os riscos que exigirão uma resposta em curto prazo, e os com baixa prioridade. Se possível, uma análise de tendências, que nada mais é do que responder se o projeto tende a ir bem ou mau, ajuda a deixar mais claro o futuro do desenvolvimento, é uma informação simples, porém muito valiosa e de difícil aceitação se for negativa, afinal nenhum gerente de projetos gostaria de admitir que não fosse conseguir finalizar seu projeto.

Análise quantitativa

O objetivo de uma análise quantitativa é obter uma análise probabilística do projeto de software e também uma lista priorizada de riscos quantificados, pois os números em determinadas situações, dizem mais do que as palavras. A análise quantitativa é um processo que avalia a prioridade dos riscos identificados, usando sua probabilidade de ocorrência e o impacto correspondente nos objetivos do projeto, se os riscos ocorrerem afirmam [ROCHA e BELCHIOR 2004].

Planejamento de resposta

O planejamento de resposta de risco é uma carta que o responsável pelo projeto tem na manga, se bem utilizada os problemas podem ser minimizados, o planejamento nada mais é do que se precaver para o caso de o risco se tornar realidade. Um item importante do planejamento de resposta é a exatidão, não é possível prever tudo o que pode acontecer durante o andamento do projeto, principalmente os riscos externos relacionados a causas naturais, mas a resposta exata de o que fazer em determinados casos ou tipos de casos pode evitar muita dor de cabeça. É muito importante que o cliente também esteja ciente dos possíveis problemas, isso pode ser documentado já no contrato, para não haver discordâncias futuras. Nem tudo se pode falar ao cliente, até por que ele não quer saber de tudo, explicando melhor, pode-se citar o uso de uma tecnologia qualquer, o cliente não deseja saber se ela é difícil de interpretar ou se a equipe não tem experiência com ela, o cliente quer o produto ou serviço pronto o quanto antes e com a melhor qualidade possível. Alguns tópicos abaixo podem ser usados para o planejamento de resposta:

• Identificar riscos, causas, descrição, categoria e como pode afetar o andamento do projeto;
• Mapear o responsável por cada risco;
• Documentar o resultado dos processos de análise quantitativa e qualitativa de riscos;
• Para acordos de resposta são inclusos transferir, evitar, aceitar ou migrar, o acordo é feito para cada plano de resposta;
• Qual ação específica deve ser tomada para implantar o planejamento de resposta;
• Qual o orçamento e tempo para as respostas;
• E, Planos de contingência e retrocedimento.

Riscos Secundários

Podemos classificá-los como um efeito colateral de uma implantação de uma resposta. O risco secundário tem origem após a implantação de um planejamento de resposta onde gera outro(s) erro(s).

Riscos Residuais

São riscos que mesmo após a implantação de um plano de resposta continuam, podem ser riscos sem importância que devem ser apenas mapeados e monitorados. Temos como exemplo alguma lei que o governo alterou que não garante mais um procedimento, não temos autoridade nenhuma para mudar o cenário, o mais correto nesses casos é fazer o mapeamento e monitorar.

Monitoração e controle

Os riscos não são estáticos, durante a fase de desenvolvimento de um projeto de software, pode haver mudança nos níveis de risco, um problema que no planejamento era aparentemente pequeno pode se tornar um impeditivo para alguma tarefa importante, por esse motivo existe a monitoração e controle.

Em se tratando de software, pode-se dizer que a constante é a mudança, desde que são idealizados na cabeça de alguém até o momento em que caem em desuso, os softwares estão sempre mudando, sendo atualizados ou melhorados. Um programa de computador assim como um automóvel, precisa de manutenção, assim também é o gerenciamento de riscos, a cada marco do projeto faz-se necessário reavaliar a criticidade dos problemas presentes e futuros. Durante todo o projeto, o monitoramento e controle está presente (Figura 2), mesmo que não se tome uma posição imediata ao encontrar um problema ou enxergar um risco, é importante anotar e repassar para a equipe que está monitorando e controlando se houver.

Figura 2: Monitoramento e controle em projetos de software. Fonte: [RAMIREZ 2010]

O processo de monitoramento e controle de riscos em projetos de software abrange relatórios e análises muito importantes, um bom exemplo é o plano de contingência, o gerente de projetos precisa calcular através de métodos dinâmicos, o quanto de recurso irá precisar. No decorrer do desenvolvimento, o plano pode mudar, aumentando ou diminuindo a quantidade de recursos empenhados com a produção. Segundo [LOSS 2007], as informações sobre o desempenho do trabalho, ações corretivas e relatórios de desempenho, são entradas importantes do monitoramento e controle de riscos, com isso pode-se dizer que não basta ter os melhores profissionais trabalhando juntos, é preciso comandá-los e sempre verificar se estão fazendo as coisas certas, tudo com o objetivo de finalizar o projeto com sucesso e no tempo planejado.

Controle de Mudança de Escopo

Em muitos projetos acontecem mudanças de escopo, seja qual for o motivo, existem diversos métodos para tentar minimizar o impacto e diminuir os riscos dessas mudanças no projeto. A mudança de escopo tem como inicio a requisição de mudança, que é feita de forma oral ou escrita, tem origem interna ou externa e podem ser opcional ou imposta. Exemplos das principais mudanças são:

• Evento externo, que pode ser a mudança em uma lei.
• Erro no detalhamento do escopo do projeto.
• Implementação de um plano de contingência.

Um ponto importante de ser analisado quando ocorre à mudança de escopo são as variações do escopo inicial, onde vai interferir diretamente na base do projeto e vai exigir uma ação corretiva. Dependendo da mudança, a base do projeto pode até ser modificada refletindo as alterações aprovadas. Para que a mudança de escopo ocorra com sucesso, ela precisa ser planeja. Isso tudo implica em custo, prazo, qualidade e outros objetivos do projeto, um ponto importante que precisa de cuidado é quando um projeto está sobre contrato, a mudança de escopo deve estar também em todas as conformidades das cláusulas relevantes do contrato.

Conclusão

Através dos estudos realizados sobre Gerência de Riscos em Desenvolvimento de Software, pôde-se obter um conhecimento teórico a mais de como a literatura ensina a gerenciar riscos, bem como o modo como as organizações enxergam os projetos e as atividades primordiais aos mesmos. Visto que a área de Engenharia de Software possui conteúdo extremamente amplo, constatou-se a possibilidade de aprofundamento teórico na análise de riscos nos projetos de software, considera-se ainda que o conteúdo estudado seja muito importante não só para o entendimento da disciplina de Engenharia de Software II, mas para uma boa formação de conhecimento para competir no concorrido mercado de trabalho.

Referências

• NAKASHIMA, D. T. V. (2004) "Identificação de riscos em projetos de TI".
• FACCIONI, M. F. (2011), Gerência de Projetos, 4ª edição.
• RAMIREZ, F. (2010), Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e UML, 5ª edição. PRITCHARD, C.
• L.: Risk Management – Concepts and Guidance, ESI International, 2001. ROCHA, P. C, BELCHIOR, A. D (2004) "Mapeamento do Gerenciamento de Riscos no PMBOK, CMMI-SW e RUP".
• LOSS, L. (2007) "Pós-Graduação em Segurança da Informação: Análise de Riscos".
• LMDM (2008) "Gerenciamento de Riscos".