Gerenciamento de risco para desenvolvimento de software

O gerenciamento de riscos é um sistema para identificar, abordar e eliminar problemas que podem ser prejudiciais ao custo, cronograma ou sucesso técnico de um projeto ou ao moral da equipe do projeto.

“Os problemas de amanhã são os riscos de hoje.” Portanto, “risco” é claramente definido como um problema que pode causar algum dano ou ameaçar o cronograma do projeto, mas ainda não ocorreu.

Se você não tomar a iniciativa de gerenciar riscos, você enfrentará riscos.

O desenvolvimento de software  é uma atividade de alto risco e pode haver riscos em qualquer estágio do processo de desenvolvimento do projeto. Adotar um método de gerenciamento de risco ativo pode tornar o processo do projeto mais estável, obter uma alta capacidade de rastrear e controlar o projeto e pode evitar e transferir riscos ou mitigar os efeitos adversos dos riscos.

O gerenciamento de riscos é o processo de identificar, analisar, responder e monitorar os riscos do projeto. É uma atividade gerencial muito importante no gerenciamento de projetos. A implementação efetiva do gerenciamento de riscos de software é a garantia para a conclusão tranquila do desenvolvimento do projeto de software.

A realização da gestão de riscos deve incluir três elementos:

  • Um plano de gerenciamento de risco deve ser formulado no plano de desenvolvimento do projeto;
  • O orçamento do projeto deve incluir os fundos necessários para resolver o risco;
  • Ao avaliar o risco, o impacto do risco também deve ser incluído no planejamento do projeto.

Vamos discutir como podemos tomar ações preventivas para mitigar os riscos que ocorrem frequentemente durante o desenvolvimento de software.

  1. Requisitos pouco claros  — Requisitos pouco claros são problemas frequentemente encontrados no processo de desenvolvimento de software. Tais problemas geralmente se manifestam em muitos aspectos, como escopo indefinido de requisitos, requisitos não refinados, descrição de requisitos pouco clara, requisitos ausentes e requisitos conflitantes. No ciclo de vida do processo de desenvolvimento de software, o desperdício causado por requisitos pouco claros é o maior e deve ser resolvido o mais rápido possível. É muito difícil determinar as necessidades do usuário.

Ações preventivas

  • Permita que os usuários participem do desenvolvimento por meio de discussões e reuniões curtas e mais frequentes
  • Desenvolva e comunique-se com as partes interessadas usando protótipos de wireframe/interface de usuário

2. Para projetos com uma ampla distribuição de usuários e um grande número de usuários, muitas vezes é difícil coletar os requisitos do usuário de forma abrangente, e as reuniões de pesquisa de requisitos geralmente são adotadas para confirmar os requisitos.

Ações preventivas

Algumas semanas antes da reunião, pesquisamos as necessidades dos usuários em várias regiões e departamentos e, em seguida, reunimos representantes de usuários de todas as regiões ou departamentos para realizar um seminário de requisitos para coletar os requisitos durante a reunião. Este método é adequado para usuários com certa experiência em TI.

2.  Armadilha 80/20  — Quando um gerente de projeto ou um desenvolvedor diz que 80% da tarefa foi concluída, você deve ser cauteloso. Porque os 20% restantes podem demorar 80% do tempo, ou talvez nunca sejam concluídos.

Os projetos de desenvolvimento de software geralmente não têm visibilidade em termos de progresso do projeto e qualidade do software. Quanto menor a visibilidade do projeto, mais difícil é controlá-lo e mais provável é que ele falhe. Podemos aumentar a visibilidade do projeto por meio de desenvolvimento iterativo, revisão técnica e integração contínua.

Ações preventivas:

  • Desenvolvimento iterativo Usando um modelo de desenvolvimento iterativo, o processo de entrega do produto é dividido em vários estágios e entregue de forma incremental de acordo com as funções.
  • A revisão técnica é uma parte importante para garantir a qualidade do software. A revisão técnica inclui simulação de código, revisão de reunião e revisão por pares. A revisão de código pode ser uma revisão cruzada entre desenvolvedores ou uma revisão de desenvolvedores comuns por desenvolvedores seniores; A revisão da reunião geralmente é realizada pelo menos uma vez a cada duas semanas, e o tempo de cada revisão não deve ser muito longo, o que é uma garantia importante para o sucesso do projeto.
  • A integração contínua pode dispersar o processo final de integração e comissionamento em larga escala para o progresso de desenvolvimento semanal e diário do projeto. Para que todos no projeto possam entender o progresso geral atual a qualquer momento e encontrar e resolver rapidamente os problemas no processo de integração.

3.  A inovação tecnológica  é uma atividade tecnológica e econômica exploratória e criativa. No processo de desenvolvimento, a introdução de novas tecnologias inevitavelmente encontrará vários riscos. Medidas como desenvolvimento de software em forma de T e prototipagem com novas tecnologias com histórias de usuários de pico.

4.  Problemas de desempenho  — Devido à falta de conhecimento do projeto de software, os problemas de desempenho geralmente são expostos após a implantação do sistema ou o uso de um novo sistema por um período de tempo. Os problemas de desempenho geralmente exigem muito trabalho de otimização, ou mesmo redesenho parcial ou abrangente. Nem usuários nem desenvolvedores querem problemas de desempenho. A equipe precisa estar ciente desse problema, implementar planejamento e testes de desempenho em todo o processo de desenvolvimento e incluir requisitos de desempenho em requisitos não funcionais.

5.  Problemas de usabilidade —  A usabilidade do software inclui muitos fatores, como se o software é eficiente, fácil de aprender, fácil de lembrar, agradável e não fácil de cometer erros. Muitas vezes devido à má usabilidade do software, os usuários ficam insatisfeitos e até mesmo eliminados pelo mercado. No desenvolvimento do projeto, deve-se prestar atenção às questões de usabilidade para evitar riscos de usabilidade do software.

Estrutura de detalhamento de risco

Podemos usar a estrutura de detalhamento de risco para classificar o risco potencial para diferentes aspectos:

A estrutura de detalhamento de riscos é a decomposição hierárquica dos riscos, começando pelo elemento do nó raiz que representa o projeto e descendo para as várias categorias de risco e, em seguida, para os riscos de nível mais fino.

Além de apresentar os riscos do projeto em uma Estrutura de Detalhamento de Riscos, é possível combinar o uso de Color Legend na representação do impacto do risco. Dê uma olhada no exemplo de Estrutura de Detalhamento de Riscos abaixo, uma legenda de Impacto com cinco itens foi configurada, representando os cinco níveis de impactos que os riscos podem ter no projeto com cinco códigos de cores distintos.

Aqui está um exemplo de estrutura de detalhamento de risco:

Exemplo de estrutura de detalhamento de risco

Edite esta estrutura de detalhamento de risco online )

Existem muitas ferramentas de gerenciamento de risco que você pode usar na estruturação de riscos. Além da Estrutura de Detalhamento de Riscos, você também pode considerar o uso do  Diagrama de Causa e Efeito  (também conhecido como Diagrama Espinha de Peixe).

Conclusão

Quanto mais cedo o risco for identificado e gerenciado, maior será a probabilidade de evitar o risco ou reduzir o impacto do risco quando ele ocorrer. Especialmente em projetos complexos com um grande número de participantes do projeto, uma ampla gama de envolvimento e alto conteúdo técnico devem ser fortalecidos.


Leave a Reply

O seu endereço de email não será publicado.