Plano de Gerenciamento de Riscos
Esse documento tem como objetivo identificar riscos futuros que podem atrasar ou dificultar o desenvolvimento da aplicação,sendo internos ou externos e traçar planos de contingências para minimizar ou até mesmo evitar que eles ocorram.É de suma importância para o desenvolvimento do projeto,visando que ainda possam existir riscos não mapeados.
Domínio tecnolǵico - É relacionado a tecnologias e ferramentas que serão utilizadas no processo de desenvolvimento do projeto.
Requisitos -É relacionado aos requisitos,se todos foram cumpridos ao final do desenvolvimento,se foram colhidos e entendidos corretamente de acordo com a ideia que o cliente possuía ou possui.
Infraestrutura - Esse é um dos pontos mais críticos do gerenciamento de riscos em projetos de software, pois geralmente nos esquecemos de providenciar com antecedência a infraestrutura onde o software será executado. É um ponto crítico de conflitos entre a área de infraestrutura, suporte e desenvolvimento.
Funcionalidade-Contempla tudo relacionado a funcionalidade do software como garantir que os requisitos foram atendidos de forma satisfatória,garantir que atende a real necessidade do usuário e se retornará resultados precisos.
Usabilidade- A usabilidade engloba todos os aspectos referentes à interface com o usuário, que se sinta a vontade com o uso do sistema e que o entenda, com o mínimo de treinamento, aspecto muito bem estruturado nos sites ou celulares onde a aplicação irá ser utilizada
Eficiência-Garantir que o usuário consiga ter as respostas da aplicação de forma rápida e correta. portabilidade-Se refere a que plataformas / sistemas operacionais o software irá rodar.
mercado de trabalho-A carência por parte de profissionais de TI é algo que existe,e caso tenhamos perda do desenvolvedores,temos que desenvolver um plano de contingência para essa perda.
Ambiente-O ambiente pode influenciar no desempenho da equipe e no desenvolvimento do produto,um exemplo aplicado ao nosso projeto é o fato de a maior parte do desenvolvimento ocorre na FGA e uma das limitações que pode ocorrer é a falta da internet ou mesmo greves.
Cliente-é relacionado a aceitação dos clientes ao utilizar a aplicação e de como ele foi atendido ao utilizar ,no nosso caso os alunos,ou seja,nós mesmo somos os clientes então a visão de como a aplicação está atendendo o requisitado.
Prioridade de Projeto - Muitos projetos sofrem pausas e cancelamentos devido à mudanças de prioridade,no nosso caso seria os projetos ou trabalhos de outras matérias,por exemplo,alguns alunos cursam a matéria de GPP,e isso pode ser um problema devido a prioridade de projeto.
Estrutura - é relacionado a estrutura física da empresa onde a aplicação será desenvolvida,o ambiente de desenvolvimento ,se possui algum risco ,dificuldade de transporte até o local,barulho ,distrações entre outros.No nosso caso o ambiente de desenvolvimento comum é a FGA,o maior problema dentro do ambiente que estamos trabalhando o transporte para cá e a situação da internet precária.
Mudanças de escopo - É muito frequente na engenharia de software a mudança de escopo ocorrer,pois tratam de uma transformação de uma abstração em real,ainda sendo da forma virtual.É possível lidar de 2 formas com essas possíveis mudanças,a primeira é orçar já calculando essas mudanças de escopo e a outra é efetuar o controle integrado de mudanças.
Prazo inadequado - O prazo do projeto é estipulado pela equipe,mas pode ocorrer atrasos em casos que a equipe não levou em consideração a elicitação de requisitos,testes,mudança de escopo e operação assistida. Partes interessadas - ocorre quando os stakeholders não são identificadas da forma correta,as vezes a falta de entendimento da parte interessada com o que propomos,ou partes interessadas contrárias ao projeto entre outros.
Comunicação - é referente a comunicação entre equipe de desenvolvimento com o cliente,a periodicidade de reuniões para análise de progresso, relatórios de status entre outras coisas
A Análise SWOT é uma ferramenta utilizada para fazer análise ambiental, sendo a base da gestão e do planejamento estratégico numa empresa ou instituição. Graças à sua simplicidade pode ser utilizada para qualquer tipo de análise de cenário, desde a criação de um blog à gestão de uma multinacional.Ao utilizar o SWOT podemos ter uma visão geral dos pontos internos da equipe,a matriz do SWOT do PlanUp é :
| Forcas | Fraquezas |
|---|---|
| Comprometimento da equipe. Experiência com projetos utilizando a mesma metodologia. Conhecimento prévio de conceitos da disciplinas por meio de alguns integrantes. | Falta de conhecimento da linguagem e framework. Falta de comunicação |
| Oportunidade | Ameaças |
|---|---|
| Ao final da disciplina dar continuidade a aplicação se houver uma demanda para a sua utilização média/grande escala | Atraso nas entregas de tarefas. Pouco conhecimento das tecnologias utilizadas. Greve da Universidade de Brasília. Baixa produtividade. Trancamento de algum membro da equipe. Dificuldade para encontros presenciais. |
Diante dos riscos a que qualquer projeto encontra-se exposto, torna-se necessário encontrar uma ferramenta que possibilite priorizá-los de forma, no mínimo, aceitável. É nesse cenário que surge a matriz de probabilidade e impacto. Elas especificam as combinações de probabilidade e impacto que resultam em uma classificação dos riscos como de prioridade em muito baixa,baixa,moderado,alta e muito alta.
| Ponto | Atributos | Probabilidade |
|---|---|---|
| 5 | esperado | 0,81 - 1,0 |
| 4 | Muito provável | 0,61 - 0,80 |
| 3 | Provável | 0,41 - 0,60 |
| 2 | Pouco Provável | 0,21 - 0,40 |
| 1 | Quase nula | 0 - 0,20 |
| Pontos | Avaliação | Escopo e atributos |
|---|---|---|
| 5 | alto | impacto significante às operações |
| 4 | elevado | alto impacto para as operações, projeto e orçamento |
| 3 | moderado | impacto morederado para as operações |
| 2 | baixo | baixo impacto para algumas atividades, alguma fraqueza de controle |
| 1 | limitado | impacto limitado nas operações, regulamentos/leis ou responsabilidades |
| P/I | limitado | baixo | moderado | elevado | alto |
|---|---|---|---|---|---|
| quase nula | 1 | 2 | 3 | 4 | 5 |
| pouco provavel | 2 | 4 | 6 | 8 | 10 |
| provável | 3 | 6 | 9 | 12 | 15 |
| muito provável | 4 | 8 | 12 | 16 | 20 |
| esperado | 5 | 10 | 15 | 20 | 25 |
| Risco | Impacto | Probabilidade | Prevenção | Resposta | Prioridade |
|---|---|---|---|---|---|
| Dificuldade com as tecnologias utilizadas | alto | provável | treinamento e pareamento | pareamento e troca de informações entre os membros | 15 |
| Dificuldade para manter a rastreabilidade dos requisitos | alto | pouco provável | definir rastreabilidade dos requisitos | manter os rastros para mantermos a rastreabilidade | 5 |
| Risco | Impacto | Probabilidade | Prevenção | Resposta | Prioridade |
|---|---|---|---|---|---|
| Ausencia de cliente | moderado | provável | definir um escopo de acordo com o que a disciplina exige | redefinir escopo | 9 |
| Professores da UnB entrarem em greve | alto | esperado | - | - | 25 |
| Risco | Impacto | Probabilidade | Prevenção | Resposta | Prioridade |
|---|---|---|---|---|---|
| Ausencia de testes | alto | muito provável | utilizar testes na aplicação | capacitação da equipe e execução de testes | 20 |
| Sistema falhar | baixo | pouco provável | testas as funcionalidades | deixa o código o mais conciso e coeso para que não ocorram erros | 4 |
| Risco | Impacto | Probabilidade | Prevenção | Resposta | Prioridade |
|---|---|---|---|---|---|
| Falta de comprometimento ou desistência da disciplina por algum integrante da equipe | alto | pouco provável | tentar motivas os membros da equipe | ajudar os membros da equipe a melhorar o desempenho | 10 |
| Falta de comunicação entre os membros da equipe | alto | provável | fazer com que todos os membros consigam ter uma comunicação direta | melhorar a comunicação entre a equipe usando meios de comunicação online | 15 |
| Risco | Impacto | Probabilidade | Prevenção | Resposta | Prioridade |
|---|---|---|---|---|---|
| Escopo mal definido | alto | moderado | Identificar requisitos utilizando técnicas de elicitação | redefinir escopo | 15 |
| Atrasao na entrega de tarefas | alto | esperado | Utilização de um cronograma com atribuição de tempo suficiente | Reavaliar cronograma e demonstrar a importância do cumprimento dos prazos | 25 |
| Equipe ser auto gerenciável | alto | moderado | Definir um PO e ScrumMaster | Gerenciamento e cobrança para a entrega das histórias por parte do PO e scrum master | 15 |
- Gerenciamento de riscos para projetos de software. Disponível emhttps://www.elirodrigues.com/2013/09/21/gerenciamento-de-riscos-ear-para-projetos-de-software/.
- Gerenciando ricos atraves de matrizes. Disponível emhttps://danielettinger.com/2011/06/14/gerenciando-os-riscos-do-projeto-com-a-matriz-de-probabilidade-e-impacto/
- Probabilidade e impacto de riscos. Disponível em https://teoriadapratica.org/2014/01/01/probabilidade-e-impacto-de-riscos/