QUALIDADE DE SOFTWARE
TIPOS DE RISCOS
1
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Plano de Gerência de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• Todo projeto de software deve ter um plano de gerência de riscos.
• Quais são os riscos identificados
• Uma análise qualitativa ou quantitativa de cada risco que indique, por exemplo, a
probabilidade de sua ocorrência e de seu impacto sobre o projeto, caso ocorra.
2
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Plano de Gerência de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• Como a probabilidade de o risco ocorrer pode ser reduzida (plano de redução de
probabilidade
• Como o impacto do risco, caso ocorra, pode ser reduzido (plano de redução de impacto
• O que fazer se o que era um risco se tornar efetivamente um problema (plano de
resposta ao risco
• Como monitorar os riscos?
3
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Plano de Gerência de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• Os planos de redução de probabilidade e impacto também são chamados planos de
mitigação de risco, ou seja, são planos executados de forma preventiva para evitar que o
risco ocorra e, se ainda assim ele ocorrer, seu prejuízo seja reduzido.
4
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Plano de Gerência de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• Uma característica altamente desejada para um planejador, e mesmo para um gerente de
projeto, em relação ao risco é a capacidade de visão antecipada.
• Um bom planejador e um bom gerente são capazes de visualizar com antecedência
possíveis situações anômalas que poderiam impedir o bom andamento do projeto.
5
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Plano de Gerência de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• Essa previsão, longe de ser uma atitude pessimista, poderá salvar o projeto no futuro ou
pelo menos mantê-lo dentro do cronograma e do orçamento previstos.
• Além disso, nem todos os riscos precisam preocupar o planejador de projeto. Como será
visto mais adiante, apenas os riscos de maior exposição merecerão mais atenção.
6
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Plano de Gerência de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• Outro princípio importante é a antecipação das atividades de maior risco, como
preconizado nos modelos Espiral, RUP e métodos ágeis. A ideia é: se um risco pode
inviabilizar um projeto, é melhor que isso seja analisado e descoberto o quanto antes,
porque quanto mais tempo passar, maior terá sido o investimento e, por conseguinte, o
custo.
7
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Plano de Gerência de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• Os riscos podem ser classificados em três grupos em relação ao conhecimento que se tem deles:
• • Conhecidos: são aqueles já identificados e para os quais a equipe possivelmente estará
preparada.
• • Desconhecidos: são aqueles que poderiam ter sido descobertos se as medidas de identificação
adequadas tivessem sido tomadas.
• • Impossíveis de prever: são aqueles que não teriam sido descobertos nem mesmo com as
melhores técnicas de identificação.
8
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Plano de Gerência de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• Assim, o plano de gerência de riscos vai poder tratar apenas o primeiro grupo de riscos.
• Para minimizar o segundo grupo, boas atividades de identificação de riscos devem ser
desenvolvidas.
• Já o terceiro grupo vai depender da capacidade do gerente de responder de forma
organizada a situações totalmente imprevistas.
9
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Identificação de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• Normalmente, um risco compõe-se de três elementos:
• • Uma causa, na forma de uma condição incerta ou desconhecida, mas que pode ocorrer
com uma determinada probabilidade. Por exemplo, o uso de uma tecnologia nova que
não é dominada pela equipe de desenvolvimento.
10
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Identificação de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• • Um problema, que pode ocorrer em função da causa. Por exemplo, a equipe ter
dificuldades sérias para implementar os requisitos usando essa tecnologia.
• • Um efeito causado pelo problema em um ou mais objetivos do projeto ou iteração. Por
exemplo, um atraso no cronograma ou um produto desenvolvido com qualidade inferior
à desejada.
11
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Identificação de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• Assim, um risco é um problema que tem uma causa e pode ocasionar um efeito. Se esse
problema ocorrer, estima-se que um dos objetivos do projeto será impactado, seja no
tempo, custo, qualidade, seja em outro aspecto.
• Por exemplo: “Como consequência do uso de um novo hardware (uma exigência
definida), erros inesperados de integração do sistema podem ocorrer (um risco incerto),
o que levaria ao estouro dos custos do projeto (um efeito sobre o objetivo do
orçamento)”.
12
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Identificação de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• Assim como os requisitos de um projeto, os riscos devem ser identificados e priorizados
para serem abordados adequadamente.
• O ideal é que o planejador tenha a sua disposição um catálogo com riscos que ocorreram
no passado em projetos semelhantes.
13
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Identificação de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• É importante que esse histórico nunca se perca, mas, caso não exista tal registro, uma
identificação de riscos pode ser feita em uma reunião com a equipe e discussão sobre
possíveis incertezas relacionadas com os tópicos mencionados.
14
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Identificação de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• O Processo Unificado associa diferentes tipos de risco com as diferentes fases do projeto:
• • Concepção: riscos de requisitos e de negócio.
• • Elaboração: riscos de tecnologia e arquitetura de sistema.
• • Construção: riscos de programação e teste de sistema.
• • Transição: riscos de utilização do sistema no ambiente final.
15
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Identificação de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• A literatura apresenta várias técnicas para identificação de riscos na fase de planejamento
de um projeto. Podem-se citar as seguintes:
• • Uso de checklists predefinidos com possíveis riscos: tais listas podem ser obtidas tanto
na literatura ou na Internet quanto a partir de projetos anteriores executados pela
mesma equipe.
16
QUALIDADE DE SOFTWARE
• # Planejamento Estratégico = Identificação de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• • Reuniões e brainstormings com gerente e equipe de projeto com experiência em outros
projetos.
• • Análise de cenários e lições aprendidas em projetos anteriores com contexto
semelhante.
• A identificação de riscos deve considerar diferentes fontes, tais como tecnologia, pessoas
e o próprio projeto. As subseções a seguir discutem mais detalhadamente estas possíveis
fontes.
17
QUALIDADE DE SOFTWARE
• # Riscos Potenciais = Riscos Tecnológicos
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• Os riscos tecnológicos: estão relacionados com todas as incertezas referentes ao modo
como a equipe será capaz de lidar com a tecnologia necessária para realizar o projeto.
Quanto menos experiência a equipe tiver com essas tecnologias, maiores serão os riscos.
18
QUALIDADE DE SOFTWARE
• # Riscos Potenciais = Riscos Relacionados com Pessoas
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• • Riscos de pessoal: projetos são executados por pessoas. Então, perder uma pessoa da
equipe de forma permanente ou temporária pode ter um grande impacto na medida em
que essa pessoa for insubstituível.
19
QUALIDADE DE SOFTWARE
• # Riscos Potenciais = Riscos Relacionados com Pessoas
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• • Riscos de cliente: até que ponto o cliente se manterá interessado no projeto?
Mudanças políticas ou administrativas poderão afetar o interesse da organização em
investir no projeto? Mesmo que a organização mantenha o interesse no projeto, o cliente
estará disponível para esclarecer requisitos e realizar testes?
20
QUALIDADE DE SOFTWARE
• # Riscos Potenciais = Riscos Relacionados com Pessoas
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• • Riscos de negócio: muitas vezes, a empresa até constrói um bom produto no prazo e
com o custo definidos, mas mesmo assim o projeto fracassa. Entre outras coisas, a
organização pode não ter a habilidade necessária para vender o produto, ou a empresa
pode até ter essa habilidade, mas o produto não apresenta efetivamente apelo
comercial.
21
QUALIDADE DE SOFTWARE
• # Riscos Potenciais = Riscos Relacionados com Pessoas
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• • Riscos legais: existem problemas ou possibilidade de litígio? Uso de material protegido
por direitos autorais? Necessidade de celebração de contrato com terceiros? Normas e
leis específicas em outros estados ou países?
22
QUALIDADE DE SOFTWARE
• # Riscos Potenciais = Riscos de Projeto
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• Riscos de gerenciamento: do projeto envolvem a capacidade da equipe de planejar e
seguir o plano dentro do cronograma e do custo previstos. Esse tipo de risco costuma se
manifestar das seguintes formas:
23
QUALIDADE DE SOFTWARE
• # Riscos Potenciais = Riscos de Projeto
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• • Riscos de requisitos: a equipe, por ser inexperiente, pode não ter sido capaz de
identificar corretamente os requisitos do projeto, o que causará problemas ao longo
dele. Requisitos poderão ser insuficientes, excessivos ou incorretos. Ou, ainda, os
requisitos podem ser naturalmente instáveis, em razão de características do próprio
projeto.
24
QUALIDADE DE SOFTWARE
• # Riscos Potenciais = Riscos de Projeto
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• • Riscos de processo: o modelo de processo escolhido é adequado às características do
projeto? A equipe tem experiência com o processo? O gerente tem experiência em
projetos anteriores?
25
QUALIDADE DE SOFTWARE
• # Riscos Potenciais = Riscos de Projeto
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• • Riscos de orçamento: até que ponto a verba necessária para o projeto está garantida?
Os custos foram corretamente previstos em projetos anteriores?
26
QUALIDADE DE SOFTWARE
• # Riscos Potenciais = Riscos de Projeto
• (Fonte: RAUL, Wazlawick - Engenharia de Software)
• • Riscos de cronograma: é possível que os prazos sejam alterados e a ordem em que as
funcionalidades devem ser entregues possa mudar? O planejador deve saber em que
grau a equipe se mostrou capaz de ater-se ao cronograma em projetos passados.
27
QUALIDADE DE SOFTWARE
• # Riscos Potenciais = Checklist de Riscos
• (Fonte: RAUL, Wazlawick - Engenharia de Software) – 8.3
•F.I.M.
28