Feeds:
Posts
Comentários

Vantagens:

  • Processo robusto e bem definido com a geração de artefatos importantes;
  • Os maiores riscos são atacados primeiro, diminuindo as chances de fracasso do projeto

Desvantagens:

  • Complexo e trabalhoso para projetos de pequeno porte;
  • Exige experiência da equipe.

Apresentação

Rational Requisite®Pro : Facilita escritura, compartilhamento e disseminação de requisitos.
Rational ClearQuest: Controle de solicitação de mudanças.
Rational Rose® 98 : Modelagem Visual de processos de negócios, requisitos e componentes.
Rational SoDA® : Geração de documentação.
Rational Purify® : Perfil de consumo de memória.
Rational Visual Quantify™ : Perfil de consumo de CPU.
Rational Visual PureCoverage™ : Alcançabilidade de código.
Rational TeamTest : Automatiza testes funcionais.
Rational PerformanceStudio™ : Analisa desempenho de sistemas cliente-servidor para a Web.
Rational ClearCase® : Gerência de configuração de software.

Lidando com Riscos

No livro de Martin Fowler, encontramos algumas estratégias para lidar com riscos:

1-    Riscos de Requisitos – Um dos elementos mais importantes no manejo de requisitos é obter acesso a uma especialidade de domínio. Falta de acesso a pessoas que, realmente, conhecem o domínio é uma das causas mais comuns para que projetos falhem. A participação de pessoas que realmente conheçam o domínio do sistema pode ampliar a qualidade do software e evitar riscos de requisitos.

2-    Riscos Tecnológicos – A coisa mais importante é construir um protótipo que experimente as partes da tecnologia que você está pensando em utilizar.  Os riscos tecnológicos são inerentes a como os componentes utilizados se encaixam. Portanto, é interessante construir uma aplicação simples com os componentes a serem utilizados no projeto. Esta aplicação poderá evitar surpresas na implementação do projeto.

3-    Riscos de Habilidades – Treinamento é um modo de evitar erros. Errar toma tempo e tempo custa dinheiro. Então, você paga de qualquer maneira, mas a falta de treinamento faz com que o projeto se estenda.

Uma estratégia efetiva deve observar os seguintes pontos:

Prevenir Riscos

Monitorar Riscos

Gerenciamento de Riscos e Planos de Contingência

Para adotar uma estratégia proativa, prevenir riscos é sempre uma boa idéia. Torna-se necessário o desenvolvimento de um plano para minimizar os riscos. Por exemplo, se um risco do projeto for a possibilidade de alta rotatividade na equipe, devemos desenvolver uma estratégia para reduzir a rotatividade como melhorar as condições de trabalho.

Monitorar riscos também é muito importante para evitar surpresas. No caso da alta rotatividade, um item a ser monitorado seria o número de faltas ao trabalho.

O gerenciamento de riscos e planos de contingência assume que o esforço de prevenir riscos falhou e o risco tornou-se realidade. Portanto devem ser tomadas atitudes que contornem os problemas. No caso da alta rotatividade, se muitas pessoas saíram do projeto, as novas devem ser treinadas com urgência com a documentação armazenada.

Uma estratégia efetiva deve observar os seguintes pontos:

Prevenir Riscos

Monitorar Riscos

Gerenciamento de Riscos e Planos de Contingência

Para adotar uma estratégia proativa, prevenir riscos é sempre uma boa idéia. Torna-se necessário o desenvolvimento de um plano para minimizar os riscos. Por exemplo, se um risco do projeto for a possibilidade de alta rotatividade na equipe, devemos desenvolver uma estratégia para reduzir a rotatividade como melhorar as condições de trabalho.

Monitorar riscos também é muito importante para evitar surpresas. No caso da alta rotatividade, um item a ser monitorado seria o número de faltas ao trabalho.

O gerenciamento de riscos e planos de contingência assume que o esforço de prevenir riscos falhou e o risco tornou-se realidade. Portanto devem ser tomadas atitudes que contornem os problemas. No caso da alta rotatividade, se muitas pessoas saíram do projeto, as novas devem ser treinadas com urgência com a documentação armazenada.

Identificando Riscos

Identificando os riscos conhecidos e previsíveis, o gerente do projeto pode dar o primeiro passo para evitá-los. Existem dois tipos de riscos entre as categorias citadas acima: genéricos e específicos do produto. Os riscos genéricos são aqueles que podem ocorrer em qualquer projeto de software e os riscos específicos são aqueles relacionados a determinado produto.

Uma forma de identificar riscos é criar um “checklist “ de riscos. O “checklist” é baseado em alguns itens genéricos:

–          Tamanho do produto

–          Impacto de negócios

–          Características do cliente

–          Definição de processo

–          Ambiente de desenvolvimento

–          Tecnologia de implementação

–          Tamanho e experiência da euipe

Na sessão “Checklist de Riscos”, encontrado na página deste trabalho, há um questionário que dará um índice do risco do projeto de software. Trata-se de um exemplo simples que fornece uma boa base para o entendimento dos fatores de risco.

A tabela abaixo ajuda a identificar o grau de risco total que está envolvido no projeto. Com base em informações de impacto e probabilidade.

Risco Total:

Impacto /

Probabilidade

Muito Alto Alto Médio Baixo Muito Baixo
Catastrófica Alto Alto Moderado Moderado Baixo
Crítica Alto Alto Moderado Baixo Nenhum
Marginal Moderado Moderado Baixo Nenhum Nenhum
Despresível Moderado Baixo Baixo Nenhum Nenhum


Algumas categorias de riscos são:

1) Riscos de Projeto – São riscos ligados diretamente ao projeto. Se os riscos de projeto se tornarem reais, o custo e o tempo de projeto podem aumentar drasticamente. Os fatores que estão intimamente ligados a estes riscos são: requisitos, pessoal, recursos, cliente e cronograma.

2) Riscos Técnicos – São riscos relacionados à qualidade do software a ser desenvolvido. Se os riscos técnicos se tornarem reais, a implementação do sistema pode se tornar difícil ou impossível.

Riscos técnicos envolvem problemas de design, implementação, interface e manutenção.

3) Riscos de Negócios – São riscos relacionados à viabilidade do projeto. Se os riscos de negócios se tornarem reais, o projeto pode ser até cancelado. Entre os riscos de projeto estão:

a)    Construção de um sistema excelente que ninguém vai precisar;

b)    Troca do gerente do projeto;

c)    Construção de um produto que não se encaixa no mercado.


Uma outra classificação proposta por Chrarette no Livro Sotware Engineering Risk Analysis and Management:

1) Riscos ConhecidosSão riscos descobertos após cuidadosa avaliação do projeto. Como, por exemplo, datas não realistas de entrega.

2) Riscos PrevisíveisSão riscos que são conhecidos por experiência em outros projetos.

3) Riscos Não-Previsívies São riscos extremamente difíceis de identificar.

No livro UML Essencial de Martin Fowler são descritos quatro tipos de riscos

1- Riscos de Requisitos – Torna-se um grande perigo construir um sistema que não faz o que o cliente necessita;

2- Riscos Tecnológicos – Refere-se à possibilidade de escolha da tecnologia que não possibilitará a perfeita implementação do sistema;

3- Riscos de habilidades – Refere-se à capacidade técnica de sua equipe;

4- Riscos políticos – Refere-se às forças políticas de que podem interferir e afetar seriamente o projeto.

Uma outra classificação proposta por Chrarette no Livro Sotware Engineering Risk Analysis and Management:

1- Riscos ConhecidosSão riscos descobertos após cuidadosa avaliação do projeto. Como, por exemplo, datas não realistas de entrega.

2- Riscos PrevisíveisSão riscos que são conhecidos por experiência em outros projetos.

3- Riscos Não-PrevisíviesSão riscos extremamente difíceis de identificar.

No livro UML Essencial de Martin Fowler são descritos quatro tipos de riscos: