Esse artigo faz parte da revista Engenharia de Software 2 edição especial. Clique aqui para ler todos os artigos desta edição

imagem

Planejamento

Visão da gerência de riscos na engenharia de software

 

As organizações vivem atualmente grande competitividade comercial, demandando rápidas decisões, melhor alocação de recursos e uma clara definição de foco. Em um ambiente de desenvolvimento de software típico não é diferente. Vários tipos de projetos são propostos, com diferentes objetivos, em que é preciso gerenciar estrategicamente de acordo com as metas organizacionais.

Em gerenciamento de projetos, para garantir o sucesso das metas organizacionais e dos objetivos definidos do projeto, é preciso identificar fatores positivos e adversos, considerados críticos. Os fatores positivos, também chamados oportunidades, são diferenciais em um ambiente mercadológico e tecnológico competitivo, e o tratamento dos fatores adversos, tidos como riscos, favorecem o alcance das oportunidades identificadas.

Os riscos possuem diferentes significados, como os de ordem física, estrutural, econômica, social e ambiental. Podendo ainda se desdobrar em diversos componentes e sucessivos níveis de detalhamento.

As incertezas fazem parte do cotidiano humano. Desde os primórdios o homem procura defender-se dos riscos que o cercam, galgando níveis de satisfação das necessidades básicas, de segurança e culminando nas necessidades de cunho puramente profissional. As pessoas, em sua grande maioria, diariamente fazem escolhas, com graus diferenciados de riscos, mas também com um alto grau de oportunidade e benefícios associados.

Atualmente todos os ramos da atividade humana dependem de alguma forma da utilização de software para operar, dar suporte, controlar equipamentos e fluxos de informações, gravar ou processar atividades. A área de Engenharia de Software tem promovido vários estudos com a finalidade de produzir modelos de melhoria, processos, métodos e ferramentas para aumentar a probabilidade de sucesso na execução de projetos de software, garantindo a qualidade de seus produtos e minimizando possíveis problemas associados [SEI 2001, PMI 2004]. Portanto, na capacidade de prevenir e controlar essas variáveis pode estar o diferencial para gerir os riscos de projetos na indústria de software.

  Todo projeto de software enfrenta problemas de qualidade, de cronograma, e de custo que estão sendo afetados por riscos que são inesperados, não planejados ou ignorados simplesmente pela falta de conhecimento.

  Através de perspectivas globais de negócios muitas organizações estão tornando-se cada vez mais dependentes do sucesso ou do fracasso dos softwares que desenvolvem. Neste contexto, a Gerência de Riscos não é apenas baseada em boas práticas para o desenvolvimento de software, mas sim, boas práticas para gerir negócios.

 

Riscos em Engenharia de Software

Ainda que o conceito de risco esteja bastante associado a perigos e impactos negativos, já vem sendo utilizado como "exposição a conseqüências da incerteza", sendo cada vez mais aplicado tanto no gerenciamento de perdas como no de ganhos potenciais. Nas próximas seções serão tratados os conceitos relativos à incerteza, oportunidade e riscos.

 

Incerteza, Oportunidade e Risco

Um fator comum que provoca preocupação na análise de projetos e no seu investimento é a incerteza. Surge como uma das conseqüências da falta de controle absoluto dos eventos que acontecerão num futuro próximo. Pode-se fazer a previsão sobre o comportamento de determinados eventos, mas não se pode determinar exatamente quando e em que intensidade eles deverão ocorrer. Exemplos desses eventos são os comportamentos futuros da economia de um país, as vendas futuras de determinados produtos e sua aceitação no mercado, o desgaste e custos de manutenção de equipamentos, entre outros.

         Considerando que a noção de risco associada à possibilidade de dano, perda ou estrago é de conhecimento claro e direto, alguns autores fazem uma distinção teórica entre o risco e incerteza. Marshall [Marshall 2002] e Knight [Knight 1921] diferenciam risco – resultados que, embora não certos possuem probabilidades quantificáveis pela experiência ou dados estatísticos e para a qual é possível fazer uma estimativa – de incerteza, quando a ausência de experiências ou ocorrências anteriores impossibilita quantificar adequadamente o resultado. No entanto, conforme M. H. Simonsem [Simonsem 1994], em seu livro Dinâmica Macroeconômica (1994: p. 399), “Risco é quando a variável aleatória tem uma distribuição de probabilidades conhecida e, Incerteza, quando essa distribuição é desconhecida”.

         No contexto da Gerência de Projetos, o risco de projeto pode ser definido como o efeito cumulativo das incertezas que adversamente afetam os objetivos do projeto. Em outras palavras, é o grau de exposição a eventos negativos e a probabilidade de ocorrência e seu impacto nos objetivos do projeto, expressos em termos de escopo, custo, prazo e qualidade.

         A meta principal do gerenciamento de riscos de projeto é afastar as incertezas relacionadas aos riscos e direcionar os projetos para oportunidades. Outra forma de tratar os riscos é listar fatores de riscos que são variáveis que podem tornar-se riscos em um baixo, médio ou alto grau de incidência no ambiente.

 

Categorias e Tipos de Riscos

Risco na área de software foi representado de forma sistemática por Barry W. Boehm, em 1988, através do Modelo Espiral [Boehm et al 2004], que tem como princípio ser incremental e dirigido à análise de riscos. O desenvolvimento incremental é uma estratégia para a obtenção de progresso em pequenos passos, pela divisão de um problema em subproblemas e a posterior combinação das soluções encontradas (alternativas definidas).

         Atualmente, a área que trata riscos na Engenharia de Software evoluiu, passando de uma análise dentro das fases do modelo de desenvolvimento de software para se tornar uma gerência que permeia todos os processos do ciclo de vida do software (o ciclo de vida do software vai desde a concepção de idéias até a descontinuidade do produto de software).

         Risco de software pode ser caracterizado como [PMI 2004]:

§         Riscos de Projeto de Software. Define os parâmetros operacionais, organizacionais e contratuais do desenvolvimento de software. Inclui limites de recursos, interfaces, relacionamentos com fornecedores ou restrições de contratos.

§         Riscos de Processo de Software. Relacionam-se os problemas técnicos e de gerenciamento. Nos procedimentos de gerência podem-se encontrar riscos em atividades como: planejamento, definição e contratação de equipe de trabalho, garantia de segurança e configuração de gerência. Nos procedimentos técnicos, podem-se encontrar riscos nas atividades: análise de requisitos, projeto, codificação e testes, por exemplo.

§         Riscos de Produto de Software. Contém as características intermediárias e finais do produto. Estes tipos de riscos têm origens nos requisitos de estabilidade do produto, desempenho, complexidade de codificação e especificação de testes.

         Muitas classificações são encontradas na literatura relacionada à Gerência de Projetos [Gustafson 2002, PMI 2004], uma delas é o uso de taxonomia de riscos (Taxonomy-Based Risk Identification) como a apresentada pelo Instituto de Engenharia de Software (SEI - Software Engineering Institute), onde os riscos são classificados dentro de categorias para melhor entendimento de sua natureza. Alguns estudos e abordagens na literatura, que tratam a área de Gerência de Riscos, evoluíram, ou mesmo adaptaram, as categorias de riscos inicialmente apresentadas na taxonomia proposta pelo SEI [Costa et al 2005, Gusmão et al 2005 e Webster et al 2005].

         As categorias de riscos favorecem a identificação dos riscos em um ambiente, promovendo uma classificação e organização dos riscos identificados em grupos lógicos. Alguns exemplos de categorias de riscos e suas abrangências estão relacionados na Tabela 1.

Não existe uma diferenciação clara entre os termos “classificação e categorização de riscos” na literatura de Engenharia de Software. Em muitas abordagens são utilizados como sinônimos. O próprio Guia PMBOK (Project Management Body of Knowledge), tanto na sua segunda quanto terceira edições, além de sub-classificar os riscos, os organiza em categorias [PMI 2004].

 

Categoria

Descrição

Técnico e Desempenho

Riscos associados a aspectos técnicos do projeto. Pode estar relacionado ao grau de inovação tecnológica do projeto em questão.

Negócio

Risco associado ao marketing ou ao tempo de lançamento de releases dos produtos ou novas versões. Também pode estar associado às informações dos competidores.

Gerência de Projeto

Riscos associados com o processo de gerenciamento de projeto, maturidade organizacional e habilidade.

Processo

Riscos associados ao processo de negócio ou outro processo que possa impactar a organização, o usuário (cliente) ou o projeto.

Tabela 1. Exemplos de Categorias de Riscos

 

         De forma geral, nos modelos de processos de gerenciamento de riscos é solicitada a definição das categorias ou classes de riscos (classificações) de acordo com as características do ambiente de desenvolvimento em questão.

 

Gerência de Riscos e Tomada de Decisão

A incerteza é um fator que pode dificultar a tomada de decisão racional. A maioria das decisões, sobretudo aquelas importantes, está baseada em algum tipo de estimativa, colocando a incerteza como elemento do processo decisório. E mesmo que a situação não exija estimativa, deve-se considerar a insuficiência das informações para a tomada de decisão.

Um risco só deveria ser tratado quando o seu benefício potencial (oportunidade) para a organização e as chances de ganhos excedesse o valor do custo reparador de uma decisão mal sucedida e as chances de perdas dentro de uma margem satisfatória. Para que isso possa acontecer é preciso que o gerente de projeto, ou o profissional responsável pelo risco, encontre as respostas para algumas questões, tais como o motivo pelo qual o risco deve ser tratado; quais são os ganhos associados ou o que poderá ser perdido; as reais chances de sucesso (ou fracasso); o que poderá ser feito se os objetivos definidos não forem alcançados; se o custo de estratégias de tratamento vale o esforço para um risco em específico.

Dessa forma, torna-se importante fazer uma análise do grau de incerteza existente no processo de decisão, ou seja, procurar uma estimativa dos riscos envolvidos. Deve-se ressaltar a importância do uso de abordagens qualitativa e quantitativa na análise e desenvolvimento dos investimentos, de uma empresa, seja ela de pequeno, médio ou grande porte [Moura et al 2004].

A evolução das organizações, a complexidade das demandas dos mercados e o processo de globalização tornaram a utilização das práticas das finanças, as estratégias e o marketing cada vez mais desafiantes. Dominar e compreender a aplicação de técnicas de análise de oportunidade e incerteza, quantitativamente ou qualitativamente, é imposição real para a sobrevivência organizacional, quer pelas implicações do trabalho assalariado, quer pelas operações de compra e venda, quer pelos investimentos e decisões associadas.

Geralmente, quando se fala em correr riscos, pensa-se logo em perdas ou sacrifícios financeiros. Muitos riscos fazem parte de nosso dia a dia de tal forma, que mal os levamos em consideração, ao invés disso, as reações muitas vezes são subconscientes.

Ao atravessar uma rua, o pedestre deve olhar para ambos os lados e quando não houver tráfego, atravessará. Caso esteja com pressa, pode assumir riscos e atravessar entre os veículos, quando aparecer uma chance. Se o trânsito estiver pesado, prudentemente, deve se dirigir às áreas de cruzamento de pedestre, garantindo sua passagem com segurança.

Caberá à gerência optar por assumir estes riscos e enfrentar o desafio. Tudo vai depender do contexto não significando que outros riscos não serão visualizados ou percebidos.

 

Gerência de Riscos versus Gerência de Projetos

A Gerência de Riscos tem uma aplicabilidade bastante ampla em ambientes organizacionais. Quando se fala em gerir projetos, é inevitável que se fale em gerir riscos. Por este motivo, muitas vezes, é difícil definir limites entre as duas gerências.

Ainda não existe um consenso sobre o relacionamento entre a gerência de projetos e a gerência de riscos. Normas, padrões e modelos são apresentados, na área de Engenharia de Software, mas não tratam esse relacionamento de forma explícita. Não existe um padrão que descreva o elo existente entre a Gerência de Riscos e a Gerência de Projeto, nem tão pouco apresente o objetivo do processo e das atividades da Gerência de Riscos. Isto evidencia a imaturidade da comunidade de Engenharia de Software, onde as normas e modelos deveriam consolidar este conhecimento já existente.

  Uma das áreas de aperfeiçoamento futuro da Gerência de Projetos, segundo David Hillson [Hillson 2005] é a integração da Gerência de Riscos e a cultura organizacional. Esta visão enfoca o uso da Gerência de Riscos como parte integral do negócio organizacional sendo um processo construtivo e não repreensivo.

A falta de padronização dificulta o entendimento, a definição de processos e papéis em relação à Gerência de Riscos, o cumprimento dos objetivos organizacionais, pois não se tem uma visão integrada. A Tabela 2 apresenta uma coletânea de visões, capturadas na literatura da área de Engenharia de Software, sobre os possíveis relacionamentos existentes entre a Gerência de Projetos e a Gerência de Riscos de Software.

De acordo com Stephen Grey existem três visões, de uma forma geral, para o relacionamento entre a Gerência de Riscos e a Gerência de Projeto [Grey 1995]:

·         Dependência – A Gerência de Riscos é vista como parte da gerência de projeto. A execução é de responsabilidade do gerente de projeto ou é delegada a outro membro da equipe de projeto. Desta forma, as atividades de gestão de riscos são realizadas em nível de projeto na organização (nível operacional);

·         Existência – A motivação para a execução de um projeto é a gerência de seus riscos. A existência da gerência de projetos está condicionada à Gerência de Riscos. Se não existe risco, não existe necessidade da gerência de projeto. Neste caso tornar-se-ia uma mera atividade administrativa. Este tipo de abordagem é comumente conhecido como “gerência de projetos dirigida a riscos”;

·         Independência – através desta visão, a Gerência de Riscos é um processo distinto e de apoio para todos os projetos da organização, desde o nível estratégico até o operacional.

 

Visão

Opiniões

Autores

Dependência

Segundo Jyrki Kontio a administração do processo de gerência de risco é responsabilidade do gerente de projeto.

O PMI, no Guia PMBOK 2000, embora enfatize que a Gerência de Riscos deva ter um responsável, determina que o gerente de projetos integre todas as áreas de conhecimento

Na norma NBR/ISO 10006, que define diretrizes de qualidade na gerência de projetos, considera que a gerência de riscos é uma das preocupações da gerência de projetos.

Jyrki Kontio; PMI – Project management Institute; NBR/ISO 10006

Existência

Implementar Gerenciamento de Risco implica na inserção dos princípios e boas práticas no gerenciamento de projetos de uma organização.

A Gerência de Risco é parte integral e vital para a gerência de projetos.

Gerenciar projetos é gerenciar riscos.

Barry W. Boehm; Ronald P. Higuera e Yacov Y. Haimes; Tom De Marco e Timothy Lister. 

Independência

Robert Charette enfoca a necessidade de uma comunicação aberta (entre níveis organizacionais e dentro dos projetos) como peça chave para um gerenciamento de sucesso.

Os padrões ISO/IEC 12207 (versão 2000) e a ISO/IEC 15504 apresentam a Gerência de Risco como um processo separado da gerência de projetos.

Revista Software Tech News – uma publicação do Departamento de Defesa Norte-Americano (volume 2, número 2); ISO/IEC 12207 e ISO/IEC 15504.

Tabela 2. Visões da Gerência de Riscos

     

Independentemente da visão adotada, a organização deve ter consciência da importância da aplicação dos processos da Gerência de Riscos de forma integrada e contínua, em seu ambiente de desenvolvimento de software.

 

Considerações Finais

Nos dias atuais, os ambientes organizacionais demandam uma crescente dinamicidade e proatividade nas respostas aos problemas e fatores de riscos associados, isso devido à grande influência exercida pela globalização, pelas inovações e mudanças não só internamente, mas também externamente. Decorrente dessa nova realidade, funções relacionadas à gestão de riscos estão sendo incorporadas nas organizações traduzindo um empenho em manter boas práticas nos ambientes corporativos.

Atualmente, gerir riscos envolve o estabelecimento de uma cultura e infra-estrutura adequadas, bem como a aplicação de uma metodologia lógica e sistemática para administrar os riscos associados a qualquer atividade, função, processo ou projeto.

         Uma limitação atual da Gerência de Riscos é a quantidade pequena de estudos práticos divulgados, apresentando indicadores de sucesso dos projetos de software desenvolvidos, conforme relato em pesquisadas disponibilizadas na área [Coelho 2004, Leopoldino 2004].

         Cada dia fica mais clara a percepção de que gerenciar projetos é gerenciar riscos. Mas isto não basta. É necessário que o gerente de projetos seja capaz de identificar problemas concretos e, de preferência, com a probabilidade de sua ocorrência. Além disso, há riscos e riscos! Determinados tipos de projetos são intrinsecamente mais arriscados do que outros.

         Possuir uma visão integrada do risco é fundamental para as organizações que buscam o desenvolvimento e a continuidade do negócio, e ainda dependem de uma infra-estrutura operacional sob risco controlado.

         Uma grande dificuldade atual para o gerenciamento dos riscos do processo de desenvolvimento de software é a existência de diversas visões parciais sobre as técnicas e formas de gerenciamento. Quando transportadas para a prática estas visões podem trazer muitos problemas e ineficiências. Isto porque qualquer desenvolvimento, por maior a hegemonia de um determinado conteúdo tecnológico, implica em conhecimento diversificado. Cada visão parcial carrega consigo também um vocabulário e determinados valores próprios, dificultando a integração entre os diversos profissionais pela ausência de padronização.

         Enfrentar esta situação depende da construção de uma imagem única e integrada do processo de gerenciamento, em especial, da Gerência de Riscos. Nisto, percebe-se a importância da disseminação dos conceitos de gestão nos ambientes de desenvolvimento de software, como também a definição de um processo que suporte as atividades de gerenciamento dos riscos dos projetos.

A realização e concretização dos projetos organizacionais estão associadas a eventos inesperados e incertos, é por tal motivo que a Gerência de Riscos tem sua importância, permitindo avaliar a viabilidade das atividades a serem realizadas, bem como os custos e benefício (oportunidades) das mesmas. 

Este artigo apresentou uma visão inicial sobre a área de gerenciamento de riscos, através de conceitos e fundamentos que são considerados chave na área de Engenharia de Software. Dentro deste contexto, nas próximas edições, serão apresentados alguns modelos e abordagens para gerenciamento de riscos; em seguida ferramentas, técnicas e métodos de apoio e, por fim, serão tratadas algumas tendências, como maturidade de projetos, portfólio e gerenciamento de riscos em ambientes de múltiplos projetos.

 

Referências

[Boehm et al 2004] Boehm, B. W.; Brown, A. W; Basili, V; Turner, R. (2004) Spiral Acquisition of Software-Intensive Systems of Systems, Cross talk – The Journal of Defense Software Engineering, DoD – Department of Defense. pp 4-9.

[Coelho 2004] Coelho, P. G. (2004) Identificação das Estratégias de Aprendizado utilizadas pelos PMP´s e Aspirantes a Certificação PMP. Projeto PMK – Environment Learning. CIn /UFPE – Centro de Informática – Universidade Federal de Pernambuco.

[Costa et al 2005] Costa, H. R.; Barros, M. O.; Travassos, G.H. (2005) Uma Abordagem Econômica baseada em Riscos para Avaliação de uma Carteira de Projetos de Software. In 19º Simpósio Brasileiro de Engenharia de Software. Uberlândia – MG – Brasil.

[Grey  1995] Grey, S. (1995) Practical Risk Assessment for Project Management. John Wiley & Sons.

[Gusmão e Moura 2004] Gusmão, C. M. G. e Moura, H. P. (2004) Gerência de Risco em Processos de Qualidade de Software: uma Análise Comparativa.  Anais do III Simpósio Brasileiro de Qualidade de Software. Brasília – DF – Brasil.

[Gusmão et al 2005] Gusmão, C. M. G.; Buarque, T.; Valeriano, F. L. (2005) Ontologia de Domínio de Riscos. Relatório Técnico - Suppera Solutions, Centro de Informática, Universidade Federal de Pernambuco. Recife. Brasil.

[Gustafson 2002] Gustafson, D. A. (2002) Theory and Problems of Software Engineering. New York: McGRAW Hill, USA.

[Hillson 2005] Hillson, D. (2005) Gerenciamento de Riscos. Revista Mundo PM Nº4. pp 38-42.

[Knight 1921] Knight, F.H. (1921) Risk, Uncertainty and Profit. Houghton Mifflin Company, Boston. pp 22-24.

[Leopoldino 2004] Leopoldino, C. B. (2004) Avaliação de Riscos em Desenvolvimento de Software. Dissertação de Mestrado. Universidade Federal do Rio Grande do Sul – Escola de Administração. Porto Alegre. Brasil.

[Marshall 2002] Marshall, C. (2002) Medindo e gerenciando riscos operacionais em instituições financeiras. Rio de Janeiro: Qualitymark.

[Moura et al 2004] Moura, H. P.; Gusmão, C. M. G.; Correira, B. C. S. (2004) Portfolio Management: A Critical View of Risk Factors Balancing. Anais do NORDNET – International PM Conference. Helsinki – Finlândia.

[PMI 2004] PMI - Project Management Institute. (2004) A Guide to the Project Management Body of Knowledge – ANSI/PMI 99-01-2004. Project Management Institute. Four Campus Boulevard. Newtown Square. USA.

[SEI 2001] SEI - Software Engineering Institute. (2001) CMMI - Capability Maturity Model Integration version 1.1 Pittsburgh, PA. Software Engineering Institute, Carnegie Mellon University. USA.

[Simonsem 1994] Simonsem, M. H. (1994) Dinâmica Macroeconômica. São Paulo: Atlas. Brasil.

[Webster et al 2005] Webster, K. P. B. et al. (2005) Taxonomia de Riscos para Manutenção de Software.  In Anais do IV Simpósio Brasileiro de Qualidade de Software. Porto Alegre – RS – Brasil.