Imagine uma situação hipotética em que você esteja desenvolvendo um aplicativo ASP.NET baseado na Web de algum tipo. O processo geral de análise de riscos envolve a identificação dos riscos, a estimativa da probabilidade de cada um, a determinação da perda associada a eles e a combinação de informações de possibilidade e de perda em um valor chamado exposição de risco.
Mas como identificar riscos? Como estimar perda e probabilidade de risco? É possível executar análise de riscos ainda que a perda e a probabilidade de risco não possam ser estimadas?
Apesar dos diversos esforços no sentido de formalizar e padronizar a terminologia da análise de riscos, na prática, termos diferentes tendem a ser usados em diferentes áreas problemáticas. Usarei o termo "análise de riscos" para significar a computação de exposição de risco por meio da multiplicação da possibilidade ou probabilidade de risco pela perda de risco, ou para indicar o processo geral de identificação, análise e gerenciamento de risco em projetos de software.
Embora a análise de riscos seja uma parte fundamental do desenvolvimento de software, minha experiência mostra que ainda há muitas técnicas de análise de riscos desconhecidas do grande público na comunidade de teste de software. Se você pesquisar na Web, encontrará milhares de referências a análise de riscos de software. Entretanto, a maioria dessas referências trata a análise de riscos em um nível muito alto, não apresenta técnicas práticas ou apresenta apenas uma técnica específica e não explica como adaptá-la a uma estrutura geral de análise de riscos. Apresentarei uma visão geral da análise de riscos, assim como técnicas úteis que podem ser empregadas imediatamente no ambiente de desenvolvimento de software.
Nas seções desta coluna, descrevo dois meta-riscos que são comuns a todos os projetos de software. Em seguida, apresento três formas de identificar riscos específicos associados ao seu projeto de software e três maneiras de analisar risco. Em particular, mostrarei uma interessante técnica nova de análise de riscos chamada Exposição de Projetos usando PERIL (Possibilidade e Impacto Classificados), que é especialmente útil em ambientes de desenvolvimento de software. Eu concluo com uma breve discussão sobre gerenciamento de risco. Acredito que as técnicas aqui apresentadas serão de grande valia para o seu kit de ferramentas de desenvolvimento, gerenciamento e teste de software.
Meta-riscos
Dois tipos especiais de análises de riscos de projetos de software são o que chamamos de análises de meta-riscos de custo e de tempo. O gerenciamento de projetos tradicional define um conceito que tem nomes diferentes como "a restrição tripla de gerenciamento de projetos" e "o triângulo de gerenciamento de projetos". Em resumo, a idéia é que praticamente todo projeto tem três fatores de limitação: custo, cronograma e escopo. Custo é quanto dinheiro você tem para gastar no projeto; cronograma é quanto tempo você tem para concluir o projeto; e escopo é o conjunto de recursos necessários e a qualidade deles.
Essas três restrições de projeto têm vários aliases. Por exemplo, custo também é conhecido como orçamento ou dinheiro. Cronograma costuma ser chamado de tempo ou duração. E escopo é chamado algumas vezes de recursos, qualidade ou até recursos/qualidade. Observe que essa última restrição pode ser (e, na verdade, geralmente é) considerada como duas restrições distintas.
Uma noção importante é que uma alteração em qualquer das restrições provavelmente modificará uma das outras restrições ou as duas. Por exemplo, se você estiver desenvolvendo um aplicativo de software e, de repente, precisar concluir o projeto em um prazo menor que o planejado, provavelmente terá de gastar mais dinheiro (para adquirir recursos adicionais ou terceirizar parte do projeto) ou cortar na qualidade ou em alguns recursos. Se o orçamento do seu projeto for cortado, é provável que você tenha de estender o prazo de conclusão do projeto, remover alguns recursos ou reduzir a qualidade do projeto. Usando o paradigma de triângulo de gerenciamento de projetos, já que a finalidade do teste de software é melhorar a qualidade de um sistema, conclui-se que os dois níveis mais altos de risco em um projeto de software são que o projeto não seja concluído dentro do prazo e que exceda o orçamento.
Identificação de riscos
Ao contrário dos meta-riscos de custo e de tempo, nos quais os eventos de risco podem ser determinados de forma gradativa (embora nada fácil) decompondo-se iterativamente tarefas em subtarefas menores, a identificação de riscos costuma ser muito menos mecânica. Em um ambiente de desenvolvimento e teste de software, há três abordagens principais para a identificação de riscos: uma baseada em taxonomia, outra em cenário e uma terceira em especificação.
Uma taxonomia é simplesmente uma lista de classificação. Considere a analogia a seguir. Você vai viajar de avião, por isso usa uma lista de lembretes padrão reservada para antes de cada viagem. A lista contém assertivas ou perguntas como "Estou com minha carteira de identidade?" e "Verifiquei se o vôo está no horário?"
Ao longo dos anos, muitas pessoas e organizações criaram taxonomias de risco de software. Uma dessas listas foi criada por Barry Boehm, pioneiro e conhecido pesquisador na área de risco de projetos de software. Em 1989, Boehm identificou uma taxonomia com 10 principais riscos de software, que foi atualizada por ele em 1995. Esta é a versão de 1995:
Problemas com pessoal
Cronogramas, orçamentos, processo
Software comercial pronto para uso, componentes externos
Incompatibilidade de requisitos
Incompatibilidade com a interface do usuário
Arquitetura, desempenho, qualidade
Alterações nos requisitos
Software herdado
Tarefas executadas externamente
Ciência da computação exigida além do limite
Você deve ter observado que a lista de Boehm com os 10 principais riscos não identifica imediatamente os riscos. Em vez disso, a taxonomia serve apenas como ponto de partida para você começar a pensar nos riscos que se aplicam ao seu projeto de software. Por exemplo, o primeiro risco, "Problemas com pessoal", abrange vários riscos diferentes que podem estar relacionados a equipe. É possível que o seu projeto simplesmente não tenha engenheiros suficientes para criar o aplicativo ou sistema. Ou talvez um engenheiro importante deixe o projeto no meio do caminho. Ou, quem sabe, a equipe de engenheiros não tem a qualificação técnica necessária para o projeto. E assim por diante.
Você já deve estar familiarizado com a maioria das 10 principais categorias de risco, exceto talvez a décima, "Ciência da computação exigida além do limite". Trata-se de uma categoria abrangente que engloba tarefas relacionadas a itens como análise técnica, análise do custo-benefício e criação de protótipos.
Outra lista de taxonomia de risco de software muito usada é a criada pelo Software Engineering Institute (SEI). O SEI é um dos 36 centros de desenvolvimento e pesquisa financiados pelo Governo dos Estados Unidos. Esses centros são organizações híbridas meio estranhas, porque são financiadas por dinheiro público, mas vendem produtos e serviços. A taxonomia de risco de software do SEI foi criada em 1993 e consiste em aproximadamente 200 perguntas. Por exemplo, a primeira pergunta é "Os requisitos são estáveis? Caso negativo, qual é o efeito no sistema (qualidade, funcionalidade, cronograma, integração, design, teste)?" A pergunta nº 16 é "Como determinar a viabilidade de algoritmos e designs (criação de protótipos, modelagem, análise, simulação)?" A taxonomia de risco de software do SEI pode ser encontrada em um apêndice ao documento.
Na identificação de riscos de software baseada em cenário, você se imagina em diferentes funções, cria cenários para essas funções e identifica o que sairia errado em cada cenário. Usando a analogia da viagem de avião descrita anteriormente, você poderia traçar mentalmente as etapas da sua viagem. Por exemplo, "Primeiro, vou de carro até o aeroporto. Depois, estaciono o carro. Em seguida, faço check-in no balcão da companhia aérea". Esse processo de cenário poderia revelar muitos riscos, como engarrafamentos devido a um acidente ou a manutenção de estradas, falta de vagas no estacionamento, esquecimento da carteira de identidade, etc.
Em um ambiente de projeto de software, algumas funções comuns usadas para a identificação de riscos baseada em cenário são usuários, desenvolvedores, testadores, vendedores, arquitetos de software e gerentes de projeto. Um cenário de usuário poderia ser algo como "Primeiro, instalo o aplicativo. A seguir, inicializo o aplicativo". Em muitos casos, um cenário de identificação de riscos é mapeado diretamente para um caso de teste.
As funções da identificação de riscos baseada em cenário não são necessariamente pessoas. Também podem ser subsistemas ou módulos de software. Por exemplo, suponha que você tem um objeto C# que executa criptografia e descriptografia. Você pode imaginar que o objeto é a função e criar cenários como "Primeiro, aceito uma entrada e crio uma instância de mim mesmo. Em seguida, aceito uma entrada e a passo para o meu método de criptografia". Tem havido menos pesquisas sobre a identificação de riscos de software baseada em cenário do que sobre a identificação baseada em taxonomia. O artigo de pesquisa encontrado em Risk Identification Patterns for Software Projects apresenta uma boa visão geral do campo e propõe uma abordagem teórica, baseada em padrões e interessante para a identificação de riscos.
Além das estratégias de identificação de riscos baseada em cenário e em taxonomia, existe uma terceira abordagem, que é a baseada em especificação. Nela, você examina detalhadamente cada recurso e processo nos documentos de especificação do seu sistema ou produto e tenta identificar o que pode dar errado. Usando a analogia da viagem de avião, você poderia examinar cuidadosamente um itinerário de viagem criado por um agente de viagens. Imagine que um dos seus documentos de especificação de um aplicativo Web declara que você pretende usar um prestador de serviços terceirizado para produzir os diversos arquivos de ajuda para o aplicativo. Uma dependência de projeto externa pode dar origem a uma longa lista de riscos. E se o prestador de serviço não entregar dentro do prazo? E se a qualidade do trabalho dele não atender aos padrões exigidos por você?
Não existe uma estratégia de identificação de riscos ideal, pois cada uma tem prós e contras. As taxonomias de risco são uma maneira excelente de iniciar o processo de identificação dos riscos em seu projeto de software. Elas oferecem uma forma um tanto mecânica de dar início, pois você começa simplesmente examinando cada pergunta ou assertiva na taxonomia. As taxonomias também ajudam a distribuir o processo de identificação de riscos entre várias pessoas atribuindo diferentes perguntas de taxonomia a elas. O lado negativo do uso de taxonomias para identificação de riscos é que elas podem ser demoradas. Além disso, como são genéricas por natureza, não são capazes de identificar riscos específicos do seu sistema de software, a menos que você dedique esforços para descobri-los.
Comparada com a identificação de riscos baseada em taxonomia, uma vantagem da abordagem baseada em cenário é que ela tende a ser menos genérica e força você, desde o início, a ser mais preciso. Por outro lado, como a identificação de riscos baseada em cenário é um pouco mais arte do que ciência, fica fácil perder um cenário importante. A identificação de riscos baseada em especificação normalmente é uma abordagem menos genérica, mais específica. Entretanto, a confiabilidade de seus resultados está diretamente relacionada à dos documentos de especificação. Quando usadas em conjunto, as três abordagens permitem identificar os riscos de software de modo preciso.
Análise de riscos
A análise de riscos é o processo de combinar a probabilidade (ou possibilidade) de um evento de risco com a perda monetária (ou efeito negativo) que ocorrerá se esse evento acontecer, visando produzir um valor que possa ser usado para comparar e priorizar o risco em relação a outros riscos. Nesta seção, apresento duas abordagens mais antigas para análise de riscos (a técnica de valor esperado e a categórica) e uma abordagem chamada PERIL.
Usando esse método, a exposição de risco é apenas uma forma de valor esperado. Obviamente, há vários problemas importantes com a abordagem de valor esperado. Como estimar probabilidades de risco? Como estimar uma perda de risco? Em algumas situações, é possível que você tenha uma boa experiência ou dados históricos sólidos nos quais basear suas estimativas, mas isso é raro na criação de software. A minha experiência mostra que a abordagem de valor esperado para análise de riscos geralmente não é viável em ambientes de desenvolvimento de software.
É importante compreender que a análise de riscos deve ser um processo contínuo e iterativo, não importa como você decida gerenciar seu esforço de risco. Como o desenvolvimento de projetos de software é uma atividade dinâmica, você deve revisar os resultados e os dados de risco conforme o projeto evolui.
