---

Gestão de riscos nos projectos de software

Introdução

Estas duas frases ilustram bem o conceito de risco, e que qualquer
projecto implica risco: “O objectivo de fazer um projecto é obter ou
estabelecer algo novo, apostar, arriscar, correr o risco.” [1] "Todos
os projectos `risk-free` já foram realizados" [2]

Apesar do risco ser algo inerente aos projectos de desenvolvimento
de sistemas de software, uma atitude comum face ao risco, é ignorar e
esperar que nada grave aconteça. Contudo existem inúmeros exemplos de
projectos de software desastrosos que poderiam ter sido evitados caso
tivesse sido realizada uma devida gestão de riscos desde a fase inicial
do projecto, nomeadamente na Gestão de Requisitos. Alguns exemplos de
projectos falhados: a explosão do Ariane 5 [6], o problema Patriot-Scud
[7], a perda do Mars Climate Orbiter [8].

Este artigo analisa uma metodologias e a suas aproximação quanto á
Gestão de Riscos nos projectos de software, o RUP - Rational Unified
Process[3]. O focus da análise feita é na Engenharia de Requisitos.

O conceito de risco

Para fazer decisões eficientes, é necessário ter mão nos riscos que
o projecto enfrenta e claras estratégias para os tratar ou eliminar.
Portanto risco é tudo o que pode estar entre nós e o sucesso, e que é
actualmente incerto ou desconhecido.

Objectivo da engenharia de requisitos

O grande objectivo da engenharia de requisitos é ter os clientes e
stakeholders contentes. Para tal existe um conjunto de erros típicos
que nos levaram a identificar riscos típicos de projectos de software.

Sucesso nos projectos de software

O tabela abaixo transcreve um estudo sobre quais os factores de sucesso nos projectos de desenvolvimento de software.

Factor de Sucesso de Projecto
das respostas


User Involvement
16 %


Executive Management Support
14 %


Clear Statement of Requirements
13 %


Proper Planning
10 %


Realistic Expectations
8  %


Smaller Project Milestones
8  %


Competent Staff
7  %


Ownership
5  %


Clear Vision & objectives
3  %


Hard-working, Focused Staff
2  %


Other
14 %

[4] Facilmente esta tabela pode ser transcrita para riscos na
engenharia de requisitos como vemos a seguir, nalguns exemplos de
riscos na engenharia de requisitos:

1-Um grande risco típico de projectos é o não envolvimento dos
utilizadores no processo de levantamento de requisitos, desenvolvendo
por vezes sistemas totalmente desadequados para os mesmos, que são
encostados ou postos na gaveta pouco tempo depois de serem
implementados.

2-Outro risco social que também ocorre frequentemente, é o não
envolvimento da chefia ou gestão, num projecto durante a fase de
identificação de requisitos. Este não envolvimento nas reuniões e
sessões de trabalho pode levar ao não comprometimento ou mesmo bloqueio
relativamente á implementação e sucesso do projecto. Ou pode levar ao
atraso do projecto por apenas inserir o gestor a meio do projecto,
pondo este em causa o mesmo, e obrigando ao refazer, reiterar, algumas
questões, conflitos entretanto já fechados.

3-Os requisitos estarem insuficientemente especificados ou claros.
Dado que o planeamento do projecto é feito com base nos requisitos
aprovados e na sua prioridade para cada iteração, se eles estão mal
especificados, o planeamento vai ser erróneo ou desfasado da realidade.
O que pode levar a planos irrealistas e sem ligação á realidade.

4-Se os requisitos forem demasiado ambiciosos relativamente ao
‘knowhow’, ao tempo disponível ou recursos humanos disponíveis,
poderemos ter nos braços expectativas nada realistas. O projecto final
pode-se tornar uma desilusão e serem goradas as expectativas dos
utilizadores ou mesmo dos stakeholders.

5-Os requisitos serem definidos sem existir uma clara visão do
sistema, também pode levar aos dois pontos enumerados anteriormente,
levando ao despiste do projecto, ou a um grande prolongamento de
manutenção, baseado em remendos para tapar buracos derivados de uma má
especificação.

6.Sobreinvestimento de tempo no processo de engenharia de requisitos

A própria engenharia de requisitos, é um processo que acarreta
riscos, na qual é difícil obter um equilíbrio no triângulo: -qualidade;
-tempo; -custo. Ao reforçar um vértice desta relação, vai se alterar o
equilíbrio do projecto. Exemplo disso é a aposta elevada na qualidade
do processo de engenharia de requisitos, aumentando o tempo despendido
para a mesma, tal pode levar a que o custo sofrer um aumento
significativo, sendo projecto mais custoso. Para além disso este "tempo
a mais" poderá comprometer o `Time to market` do produto. Isto é, ao
apostar numa grande qualidade, com muitas iterações minuciosas de
revisão dos requisitos, pode-se perder oportunidades do mercado por
chegar tarde ao mesmo.

7.Sobinvestimento de tempo no processo de engenharia de requisitos

O exemplo anterior é um exemplo claro, mas que provavelmente não é o
mais comum na nossa realidade empresarial . Em muitas empresas
Portuguesas o problema é justamente o contrário, comparativamente com a
realidade dos países do norte da europa, existe uma fraca aposta na
qualidade, na documentação dos requisitos, e os projectos são iniciados
muitas vezes sem requisitos claros, logo sem estimativas claras, e
baseados na intuição. Alguns podem até correm bem, mas mais cedo ou
mais tarde os riscos inerentes que não são tidos em conta, não são
afrontados e analisados vão comprometer o sucesso dos projectos.

Características dos riscos a ter em conta para requisitos:

1-Qualificação Riscos associados á implementação do requisito

Os riscos podem ser considerados:

-risco Directos - um risco cujo o projecto tem grande poder de controlo (ex: insuficiente dominio de uma tecnologia;)
-risco Indirecto - um risco cujo projecto tem pouco poder de controlo ou nenhum. (ex: se houver dependência com outros sistemas, que ainda não temos acesso á especificação)

2-O impacto no projecto

A cada risco identificado pode se associar qual o impacto que caso o risco se torne um facto, e ocorra um problema no projecto, qual o impacto nesse projecto.

3-Probabilidade de ocorrência

A probabilidade de ocorrência de um determinado risco varia. Existem riscos que podem ter grande severidade mas cuja probabilidade de ocorrerem é muito reduzida. Uma sugestão para definição da probabilidade, pode ser definida como 1-Frequentemente, 2-ás vezes, 3-Raramente, 4-Nunca

4-Severidade

Uma severidade grave é aquela que afecta o projecto com profundidade, aumentando o risco de insucesso ou de cancelar o projecto.

5-Tipos de riscos Alguns exemplos: -Sociais, -tecnológicos, -económicos, -politicos, -ambientais

Diminuir riscos na definição de requisitos

Uma maneira de diminuir o risco de ter requisitos de baixa qualidade
é utilizar ‘templates’ que garantam que os requisitos estão
suficientemente definidos, como exemplo sugiro

%TABLE{sort="on" tableborder="0" cellpadding="1" cellspacing="3"
headerbg="#336633" databg="#C8CB8F, #DBDDB5" headercolor="#FFFFCC"
headerrows="2" footerrows="1" }% |*Definição de um bom requisito pelo
IEEE:*| |-Unambiguous| |-Complete| |-Verifiable| |-Consistent|
|-Modifiable| |-Traceable| |-Usable during operations and maintenance|
[5]

Melhores práticas do RUP

O RUP segue um conjunto de melhores práticas para maximizar o
sucesso dos projectos: %TABLE{sort="on" tableborder="0" cellpadding="1"
cellspacing="3" headerbg="#336633" databg="#C8CB8F, #DBDDB5"
headercolor="#FFFFCC" headerrows="2" footerrows="1" }% |*Melhores
práticas do RUP*| |1-Desenvolver software por iterações| |2-Gerir
requisitos| |3-Usar arquitectura baseada em componentes| |4-Modelar
visualmente o software| |5-Verificar a qualidade do software|
|6-Controlar as alterações no software|

Destas práticas destaca-se uma aposta forte, na gestão dos
requisitos e posterior seguimento dos mesmos requisitos durante e após
o desenvolvimento com a gestão de alterações.

O desenvolvimento em iterações também leva a minimizar o risco associados à tradicional aproximação `waterfall development`

Processo de gestão de projecto do RUP e a importância da gestão de riscos neste processo

O gestor de projecto segue todo o processo da gestão de projecto. O
processo começa com a identificação dos riscos, seguido de um plano de
projecto (que inclui os requisitos a desenvolver). Após o `stafing` do
projecto, começam as iterações: 1- É definida um plano de iterações. 2-
É executada a iteração 3- A execução é avaliada 4- A lista de riscos é
revisitada Estes 4 passos são repetidos para cada iteração, mas no
final de cada iteração temos uma lista revisitada de riscos.

É desenvolvida uma lista inicial de requisitos, que são
prioritizados, serão implementados em várias iterações consoante essa
prioridade. Esta prioritização deve ser também baseada nos riscos de
implementação dos diferentes requisitos, tecnologias, etc. As primeiras
iterações podem por exemplo, para servir como experimentação ou
definição de um protótipo com os requisitos cujos riscos tecnológicos
são mais elevados. Após as primeiras iterações podemos reavaliar os
riscos do projecto, logo se necessário alterar prioridades
relativamente á implementação. Desta maneira o RUP tenta minimizar e
identificar riscos que na aproximação tradicional só seriam detectados
"tarde de mais", verificando a qualidade e controlando-a.

Estratégias do RUP para lidar com o risco

A ideia chave da gestão de risco é não esperar passivamente até o
risco se materializar e tornar-se um problema ou mesmo acabar com o
projecto, antes de se decidir o que fazer com o risco. Para cada risco
identificado é necessário definir o que se vai fazer com ele. O RUP
sugere três possibilidades: -evitar o risco - implica reorganizar o
projecto; -transferir o risco - reorganizar o projecto para outra
pessoa ficar com o risco; -Aceitar o risco - viver com o risco;

Conclusão

A gestão de riscos é essencial em todo o projecto, e se não for
iniciada com o inicio da engenharia de requisitos, pode criar grandes
dissabores, quer a nível de expectativas de utilizadores, gestores,
quanto ás funcionalidades, quer a nível de budget, timing e qualidade
do projecto. O RUP tem uma estratégia interessante de tentativa de
minimização de riscos baseada nas melhores práticas de desenvolvimento
iterativo, com cada iteração a ser baseada nos requisitos e seus riscos
associados. Desta maneira em vez de fechar os olhos aos riscos, toma-se
decisões conscientes e medidas com base nas incertezas analizadas.

Referências

[1] Project Management Body of Knowledge (PMBOK), 1987) http://www.dacs.dtic.mil/awareness/newsletters/technews2-1/prototyping.html , 29-12-2005, 10h11

[2] Philippe Kruchten, The Rational Unified Process

[3] The Capibility Maturity Model, Guidelines for improving the
software process, Carnegie Mellon University - Software Engineering
Institute

[4] Standish group CHAOS report

[5] IEEE Guide to Software Requirements Specifications, 1984

[6] Ariane 5, Explosion (data conversion of a too large number, 1996)

http://www.math.psu.edu/dna/disasters/ariane.html

[7] Patriot-Scud (rounding error, 1991) www.math.psu.edu/dna/disasters/patriot.html

[8] Mars Climate Orbiter, Loss (Mixture of pounds and kilograms, 1999)

mirror of old NASA webpage

DISALLOWED (DmRelatedItem)