CENTRO TECNOLÓGICO
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO SISTEMAS DE INFORMAÇÃO
Marcel Figueiredo Vieira
UM GUIA PARA GESTÃO ÁGIL DE RISCOS EM PROJETOS DE SOFTWARE
Florianópolis 2020
Marcel Figueiredo Vieira
UM GUIA PARA GESTÃO ÁGIL DE RISCOS EM PROJETOS DE SOFTWARE
Trabalho Conclusão do Curso de Graduação em Sistemas de informação do Centro tecnológico da Universidade Federal de Santa Catarina como requisito para a obtenção do título de Barachel em Sistemas de informação. Orientador: Prof. Dr. Jean Carlo Rossa Hauck Coorientador:Prof. Dr. Raul Sidnei Wazlawick
Florianópolis 2020
Marcel Figueiredo Vieira
UM GUIA PARA GESTÃO ÁGIL DE RISCOS EM PROJETOS DE SOFTWARE
Este Trabalho Conclusão de Curso foi julgado adequado para obtenção do Título de “Bacharel” e aprovado em sua forma final pelo Curso Sistemas de informação.
Florianópolis, 01 de novembro de 2020.
Banca Examinadora:
________________________ Prof. Jean Carlo Rossa Hauck, Dr.
Orientador UFSC
________________________ Prof. Raul Sidnei Wazlawick, Dr.
Avaliador UFSC
________________________
Profa. Fabiane Barreto Vavassori Benitti, Dra. Avaliadora
Este trabalho é dedicado à minha família, professores e amigos, que sempre me incentivaram e me ensinaram o poder transformador da educação.
AGRADECIMENTOS
Agradeço primeiramente ao meus pais, Nadir e Mauro pelo incentivo aos estudos, pela paciência, educação e dedicação ao longo da vida e, especialmente, durante o período de graduação.
À minha família pelo suporte e contribuição no meu desenvolvimento pessoal e profissional.
Ao meu orientador, Prof. Dr. Jean Carlo Rossa Hauck, por todo incentivo, dedicação e disponibilidade durante o desenvolvimento deste presente trabalho.
Aos meus amigos pelo companheirismo, incentivo e troca de conhecimento durante o desenvolvimento deste presente trabalho.
À Universidade Federal de Santa Catarina – UFSC e aos professores desta instituição, por me fornecerem uma educação pública e de qualidade.
RESUMO
O processo de desenvolvimento de software é dinâmico e os modelos ágeis têm sido utilizados como uma alternativa aos modelos mais prescritivos. Como projetos de software tendem a ser pouco previsíveis e estáveis, aplicar técnicas provenientes de modelos ágeis para minimizar os efeitos das constantes mudanças, tem surtido efeito. Entretanto, a falta de formalização e explicitação da gestão de riscos nas modelos ágeis pode acarretar no fracasso de um projeto, pois não identificar potenciais riscos e não possuir um plano de contingência, pode gerar diversos problemas, como ultrapassar o cronograma e o custo planejados. Assim, a gestão de riscos em projetos de software tem como objetivo identificar, monitorar e controlar, de forma contínua, os riscos que podem surgir no desenvolvimento de software em todas as etapas, já que realizar um planejamento adequado dos riscos e monitorar corretamente sua evolução, pode evitar que ameaças se tornem problemas, e caso ocorram, tenham seu impacto mitigado. Dito isto, o presente trabalho apresenta um guia para gestão ágil de riscos em projetos de software, por meio de conjuntos de práticas que podem ser adicionadas aos modelos ágeis, sem perder sua essência dinâmica. O guia foi desenvolvido com base na literatura, na análise do estado da arte e nas experiências dos autores. A avaliação inicial do guia levanta indícios de que ele possui conteúdo abrangente e aplicabilidade prática para auxiliar na gestão de riscos em contextos de desenvolvimento ágil de software.
Palavras-chave: Gestão de projetos, gestão de risco, desenvolvimento de software, Modelos
ABSTRACT
The software development process is dynamic and agile models have been used as an alternative to more prescriptive models. As software projects tend to be unpredictable and stable, applying techniques from agile models to minimize the effects of constant changes has been having an effect. However, the lack of formalization and clarification of risk management in agile models can result in the failure of a project, as not identifying potential risks and not having a contingency plan, can generate several problems, such as exceeding the planned schedule and cost. Thus, risk management in software projects aims to identify, monitor and control, on an ongoing basis, the risks that may arise in software development at all stages, since carrying out adequate risk planning and correctly monitoring its evolution , can prevent threats from becoming problems, and if they do occur, their impact is mitigated. That said, the present work presents a guide for agile risk management in software projects, through sets of practices that can be added to agile models, without losing its dynamic essence. The guide was developed based on the literature, the analysis of the state of the art and the experiences of the authors. The guide's initial assessment raises evidence that it has comprehensive content and practical applicability to assist in risk management in agile software development contexts.
LISTA DE FIGURAS
Figura 1 - Princípios básicos da gestão de riscos. ... 23
Figura 2 – Definição de escalas de impactos em relação aos objetivos do projeto. ... 25
Figura 3 – Abordagens frequentemente utilizadas na identificação de riscos ... 27
Figura 4 – Forma de cálculo para a importância de um risco... 28
Figura 5 – Diagrama da árvore de decisão. ... 29
Figura 6 – Um possível ciclo de vida de um risco... 32
Figura 7 - Exemplo de uma atividade modelada utilizando UML ... 38
Figura 8 – Comparativo entre modelos tradicionais e ágeis ... 40
Figura 9 – Princípios compartilhados de modelos ágeis. ... 41
Figura 10 – Exemplo de quadro Kanban. ... 44
Figura 11 - Visão geral do XP. ... 46
Figura 12 - Visão geral do Scrum ... 49
Figura 13 - Termos retornados após a busca. ... 55
Figura 14 – Resultados retornados após iterações de busca. ... 56
Figura 15 – Estrutura padrão do Guia de gestão ágil de riscos. ... 74
Figura 16 – Menu principal da ferramenta. ... 81
Figura 17 – Guia completo apresentado na ferramenta. ... 81
Figura 18 – Tutorial de uso da ferramenta. ... 82
Figura 19 – Enviar feedback sobre a ferramenta. ... 83
Figura 20 – Interface desktop da página principal da ferramenta RM-Agile. ... 85
Figura 21 – Interface mobile da página principal da ferramenta RM-Agile. ... 85
Figura 22 – Página inicial do H5P. ... 86
Figura 23 – Criação de livro interativo utilizando H5P... 87
Figura 24 – Elementos para desenvolvimento de um livro interativo usando H5P. ... 88
Figura 25 – Código HTML5 para integração do H5P. ... 89
Figura 26 – Interface da ferramenta MySimpleShow. ... 89
Figura 27 – Interface da ferramenta Kapwing. ... 90
Figura 28 – Interface da página de tutorial da ferramenta RM-Agile. ... 91
Figura 29 – Interface da funcionalidade de feedback da ferramenta. ... 92
Figura 30 – Código de implementação do banco de dados. ... 92
Figura 31 – Visão geral abordagem GQM. ... 94
Figura 33 – Resultados das perguntas derivadas da meta 1. ... 101 Figura 34 – Resultados das perguntas derivadas da meta 2. ... 103
LISTA DE QUADROS
Quadro 1 – Níveis de integridade do software/sistema baseado em possíveis erros. ... 35
Quadro 2 – Consequências em caso de erro ou falha do software/sistema. ... 36
Quadro 3 – Elemento de um processo de software. ... 37
Quadro 4 – Descrição dos elementos PICOC da Pesquisa. ... 51
Quadro 5 – Termos de pesquisa. ... 53
Quadro 6 – Strings de busca. ... 54
Quadro 7 – Questões de análise. ... 56
Quadro 8 – Classificação de estudos ... 58
Quadro 9 – Artigos analisados em relação ao processo de gestão de riscos ... 60
Quadro 10 – Elementos componentes do Guia de gestão ágil de riscos ... 75
Quadro 11 – Requisitos funcionais da ferramenta RM-Agile. ... 78
Quadro 12 – Requisitos não funcionais da ferramenta RM-Agile. ... 79
Quadro 13 – Informações sobre a formação dos avaliadores. ... 97
Quadro 14 – Análise dos resultados da avaliação derivadas da meta 1. ... 99
LISTA DE ABREVIATURAS E SIGLAS
CRC - Classe Responsabilidade Colaborador CSS - Cascading Style Sheets
EPF - Eclipse Process Framework
GARA - Gestão Ágil de Riscos de Ambiente GQM - Goal/Question/Metric
H5P - HTML5 Package
HTML - HyperText Markup Language
IEEE - Institute of Electrical and Electronics Engineers IDE - Integrated Development Environment
MSL - Mapeamento Sistemática da Literatura OMG - Object Management Group
PHP - PHP Hypertext Preprocessor
PICO - População, Intervenção, Comparação, Outcome
PICOC - População, Intervenção, Comparação, Outcome e Contexto RM – Risk Management
XP - Extreme programming
PMBOK - Project Management Body of Knowledge PMI - Project Management Institute
SEBRAE - Serviço Brasileiro de Apoio às Micro e Pequenas Empresas SEI - Software Engineering Institute
SPEM - Software Process Engineering Metamodel Specification SWEBOK - Software Engineering Body of Knowledge
UML - Unified Modeling Language
SUMÁRIO 1 INTRODUÇÃO ... 15 1.1 OBJETIVOS ... 16 1.1.1 Objetivo Geral ... 16 1.1.2 Objetivos Específicos ... 16 1.2 MÉTODO DE PESQUISA ... 17 2 FUNDAMENTAÇÃO... 19 2.1 GERENCIAMENTO DE PROJETOS ... 19 2.2 GERENCIAMENTO DE RISCOS... 21
2.2.1 Planejar o gerenciamento de riscos ... 23
2.2.2 Identificar os riscos ... 26
2.2.3 Análise qualitativa dos riscos ... 27
2.2.4 Análise quantitativa dos riscos ... 28
2.2.5 Planejar as respostas aos riscos ... 29
2.2.6 Implementar respostas aos riscos ... 31
2.2.7 Monitorar os riscos ... 31
2.3 NORMAS E MODELOS RELACIONADOS ... 33
2.3.1 Norma ISO/IEC 16085 ... 33
2.3.2 Norma IEEE 1012-2012 para verificação e validação de sistema e software . 34 2.3.3 Descrição de processos norma ISO/IEC 24774 e meta-modelo SPEM 2.0 ... 36
2.4 MODELOS ÁGEIS ... 38 2.4.1 Lean ... 42 2.4.2 Kanban ... 43 2.4.3 XP ... 45 2.4.4 Scrum ... 47 3 ESTADO DA ARTE ... 50
3.2 FOCO E NECESSIDADE DA REVISÃO ... 51 3.3 ESTRATÉGIAS DE BUSCA ... 51 3.3.1 Bases de dados ... 52 3.3.2 Critérios de pesquisa ... 52 3.3.3 Termos de pesquisa ... 53 3.3.3.1 Strings de busca ... 54
3.4 SELEÇÃO DOS ARTIGOS ... 55
3.5 EXTRAÇÃO DOS DADOS ... 56
3.6 ANÁLISE DOS RESULTADOS ... 58
3.6.1 Modelos ágeis utilizados no estudo ... 59
3.6.2 Processos de gestão de riscos ... 60
3.6.3 Resultados da integração de gerenciamento de riscos e modelos ágeis ... 66
3.6.4 Contexto do estudo de caso ... 67
3.6.5 Referências utilizadas para integrar gestão de riscos e modelos ágeis ... 68
3.6.6 Papéis dos membros de equipes na gestão de riscos ... 69
3.7 AMEAÇAS À VALIDADE ... 70 4 PROPOSTA DE SOLUÇÃO ... 72 4.1 ESTRUTURA DO GUIA ... 72 4.2 ELABORAÇÃO DO GUIA ... 75 4.3 ESTRUTURA DA FERRAMENTA ... 77 4.3.1 Requisitos ... 77
4.3.2 Requisitos funcionais da ferramenta ... 78
4.3.3 Requisitos não funcionais ... 78
4.3.4 Prototipação ... 80
4.3.4.1 Menu principal... 80
4.3.4.2 Guia completo ... 81
4.3.4.4 Enviar feedback ... 82
4.4 IMPLEMENTAÇÃO DA FERRAMENTA ... 83
4.4.1 Preparação do ambiente de desenvolvimento ... 83
4.4.2 Desenvolvimento da Página principal ... 84
4.4.3 Desenvolvimento do Guia online ... 86
4.4.4 Desenvolvimento do tutorial ... 89
4.4.5 Desenvolvimento da funcionalidade de feedback ... 91
5 AVALIAÇÃO ... 93
5.1 PLANEJAMENTO DA AVALIAÇÃO ... 93
5.2 APLICAÇÃO DA AVALIAÇÃO ... 96
5.3 ANÁLISE DOS RESULTADOS ... 99
5.4 AMEAÇAS À VALIDADE ... 104
6 CONCLUSÃO ... 105
6.1 TRABALHOS FUTUROS ... 106
REFERÊNCIAS ... 107
APÊNDICE A – Estudos do Mapeamento Sistemático da Literatura ... 111
APÊNDICE B – Guia de gestão ágil de riscos completo ... 114
APÊNDICE C – Artigo desenvolvido ... 184
1 INTRODUÇÃO
Os projetos de desenvolvimento de software muitas vezes apresentam um conjunto de incertezas e riscos que podem representar seu sucesso ou fracasso. A falha de um projeto pode ser atribuída aos mais diversos riscos que não foram devidamente identificados e mitigados, que acabam se tornando problemas graves, como o cronograma não cumprido, custos que vão além do planejamento estipulado ou a qualidade abaixo do esperado (WAZLAWICK, 2019). Ao aplicar estratégias de gestão e controle de riscos nos projetos, impactos positivos significativos são observados em sua implementação, melhorando o desempenho, reduzindo custos e atrasos (SARIGIANNIDIS; CHATZOGLOU, 2011).
O Chaos Report (STANDISH GROUP, 2015) mostra que menos de um terço dos projetos de software foram entregues com sucesso, implicando que a taxa de falhas em projetos de desenvolvimento de software permanece alta, principalmente considerando a complexidade e os riscos inerentes destes tipos de projetos (WAZLAWICK, 2019). No entanto, dentre as principais áreas de conhecimento de gestão de projetos, a gestão de riscos tem sido a menos frequentemente implementada, o que denota o foco maior em outras áreas, que buscam definir a solução de problemas em seu caminho perfeito, sem estimar as imprevisibilidades que possam surgir (KWAK; IBIS, 2000).
O uso de modelos ágeis tem crescido na indústria de software, visando, principalmente, a redução de falhas e aumento na taxa de sucesso de entregas de projetos (VERSIONONE, 2018). Alguns exemplos de modelos ágeis são Scrum (SCHWABER; SUTHERLAND, 2016) e Kanban (ANDERSON, 2010). Segundo pesquisa conduzida anualmente pela Versionone (2020), dos 1121 profissionais de tecnologia de informação entrevistados de todos os continentes, 51% indicam obter redução de riscos com a adoção de modelos ágeis, e 42% relataram que obtiveram qualidade nos produtos desenvolvidos.
Alguns valores, como flexibilidade, mudança de prioridades de forma eficiente e entregas mais rápidas são consideradas razões para o sucesso dos modelos ágeis e dos projetos que os implementam. A definição formal dos princípios e valores dos modelos ágeis foram explicitados no Manifesto ágil (BECK et al., 2001), a partir da compilação de boas práticas de gerenciamento do desenvolvimento de software.
Atualmente, Scrum e o híbrido entre Scrum e Kanban, chamado de ScrumBan, lideram como os modelos ágeis mais utilizados pelas organizações de software, sendo implementados
em 78% das empresas que participaram da pesquisa, sendo mais utilizados que modelos ágeis como XP e Lean (VersionOne, 2020).
No entanto, os modelos ágeis ao serem aplicados no desenvolvimento de software, tipicamente não incluem técnicas explícitas de gestão de risco, pois acredita-se que os ciclos de desenvolvimento com iterações curtas, feedback mais frequente e maior previsibilidade dos projetos de software tendem a minimizar os riscos (ODZALY; GREER; STEWART, 2014).
Contudo, o fato dos modelos ágeis dependerem muito da competência das pessoas envolvidas no projeto, do conhecimento do domínio do problema e como será realizada a solução, implica que não possuir pessoas com habilidades técnicas para tal, nem utilizar boas práticas de desenvolvimento e gestão de riscos, podem desencadear o fracasso de um projeto (NERUR; MAHAPATRA; MANGALARAJ, 2005).
Estudo realizado com 64 gerentes de projetos que atuam em projetos de desenvolvimento de software (TOMANEK; JURICEK, 2015), indicam que 60% dos entrevistados acreditam que adicionar técnicas de gerenciamento de riscos aos modelos ágeis é enriquecedor e útil. Assim, acredita-se que o desenvolvimento de um Guia para gestão ágil de riscos pode contribuir positivamente para a adoção de práticas de gestão de riscos complementares aos modelos ágeis.
1.1 OBJETIVOS
A partir da apresentação da contextualização do problema, foram definidos os objetivos do presente trabalho.
1.1.1 Objetivo Geral
O presente trabalho tem como objetivo geral o desenvolvimento de um Guia de gestão ágil de riscos focado em organizações que atuam na área de desenvolvimento de software e utilizam modelos ágeis.
1.1.2 Objetivos Específicos
Objetivo 1: Analisar e fundamentar teoricamente os processos de gerenciamento de projetos, gestão de riscos, normas relacionadas e modelos ágeis.
Objetivo 2: Identificar o estado da arte sobre a execução da gestão de riscos em organizações que trabalham com desenvolvimento de software e implementam modelos ágeis.
Objetivo 3: Desenvolver um Guia de gestão ágil de riscos.
Objetivo 4: Desenvolver uma ferramenta online para comportar o Guia de gestão ágil de riscos.
Objetivo 5: Avaliar a aplicabilidade, abrangência e cobertura do Guia de gestão ágil de riscos.
1.2 MÉTODO DE PESQUISA
Este trabalho foi desenvolvido a partir da aplicação dos conhecimentos obtidos com embasamento teórico sobre gerenciamento de projetos, gestão de riscos, modelos ágeis e normas com foco em organizações da área de desenvolvimento de software.
Para alcançar os objetivos do presente trabalho, foram definidas quatro atividades de pesquisa, implementação e validação, sendo demonstrado abaixo estas atividades com as respectivas tarefas.
Atividade 1. Fundamentar teoricamente.
Nesta atividade do projeto são compilados os principais conceitos fundamentais da literatura correlacionados com gerenciamento de projetos, gestão de risco, normas e modelos ágeis. As tarefas que compõem esta etapa são as seguintes:
Tarefa 1.1 – Fundamentar os principais conceitos sobre gerenciamento de projetos. Tarefa 1.2 – Fundamentar os principais conceitos sobre gestão de riscos.
Tarefa 1.3 – Fundamentar normas relacionadas ao desenvolvimento de software, gestão de riscos, modelos ágeis e descrição de processos.
Tarefa 1.4 – Fundamentar os principais conceitos sobre modelos ágeis.
Atividade 2. Identificar o estado da arte.
O processo de identificação do estado da arte, segundo os autores Vosgerau e Romanowski (2014, p. 172) “Não se restringe a identificar a produção, mas analisá-la, categorizá-la e revelar os múltiplos enfoques e perspectivas”. Portanto, nesta atividade do projeto são definidos os critérios de pesquisa e o levantamento de estudos correlacionados com
gerenciamento de projetos, gestão de riscos e modelos ágeis, além do desenvolvimento de análises da pesquisa realizada. As atividades que compõem esta etapa são as seguintes:
Tarefa 2.1 – Especificação do problema.
Tarefa 2.2 – Definição dos critérios de pesquisa.
Tarefa 2.3 – Filtrar a busca a partir da visão de diferentes autores. Tarefa 2.4 – Selecionar os estudos relacionados com tema.
Tarefa 2.5 – Extrair e analisar os dados.
Atividade 3. Desenvolver um guia e uma ferramenta para gestão ágil de riscos
Esta atividade do projeto tem como objetivo, a partir dos conhecimentos elencados em estudos teóricos e práticos, a elaboração de um Guia de gestão ágil de riscos com foco em organizações da área de desenvolvimento de software. A disponibilidade web do Guia é feita a partir do desenvolvimento de uma ferramenta online. As atividades que compõem esta etapa são as seguintes:
Tarefa 3.1: Planejar o guia e a ferramenta online de gestão ágil de riscos. Tarefa 3.2: Estruturar o guia e a ferramenta online de gestão ágil de riscos Tarefa 3.2: Desenvolver o guia e a ferramenta online de gestão ágil de riscos.
Atividade 4. Avaliar o Guia de gestão ágil de riscos
Esta tarefa do projeto tem como objetivo a avaliação do Guia de gestão ágil de riscos utilizando técnicas para verificar a aplicabilidade, abrangência e cobertura do conteúdo do Guia, para verificar se o que foi proposto teoricamente tem aderência prática, se o conteúdo do Guia pode ser aplicado em organizações que desenvolvem software e utilizam modelos ágeis com diferentes características e se a extensão do conteúdo fornece, em quantidade e qualidade, elementos necessários para o processo de gestão ágil de riscos.
Tarefa 4.1: Estruturar a avaliação. Tarefa 4.2: Desenvolver a avaliação.
Tarefa 4.3: Realizar a avaliação, coletando dados. Tarefa 4.4: Analisar os dados coletados.
2 FUNDAMENTAÇÃO
Neste capítulo são apresentados os conceitos fundamentais apresentados durante este trabalho, servindo de embasamento para o desenvolvimento do Guia de gestão ágil de riscos, relacionados a gerenciamento de projetos, gestão de riscos, normas relacionadas e modelos ágeis.
2.1 GERENCIAMENTO DE PROJETOS
A definição do PMBOK (PMI, 2009, p. 10) do que é um projeto é a seguinte: “Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo". O temporário refere-se ao tempo de execução, que possui um início e um término devidamente estipulados, com os objetivos definidos de forma clara e coerente, resultando assim, em um produto, serviço ou resultado único.
Já a área que permeia a gestão de múltiplos aspectos de um projeto é denominada de gerenciamento de projetos, cujos profissionais responsáveis devem realizar a aplicação de conhecimentos e técnicas para projetar e apoiar o desenvolvimento das atividades, com a finalidade de executar requisitos e responder as expectativas das partes interessadas, também conhecidas como stakeholders (PMI, 2017). O PMBOK (PMI, 2017) destaca e descreve o modelo de gerenciamento de projetos em cinco grupos de processos e dez áreas de conhecimento. Os grupos de processos são distribuídos em relação as saídas que produzem e em sua maioria, uma saída se torna a entrada de outro processo. Os grupos de processos são organizados da seguinte forma:
Processo de iniciação: Reconhecimento e definição do início de um projeto ou fase, cujas partes interessadas se comprometem a executá-lo.
Processo de planejamento: Planejamento e desenvolvimento de um escopo de trabalho realista, com a finalidade de atingir os objetivos que determinaram a existência de um projeto.
Processo de execução: Abrange todos os processos que devem ser realizados para execução do plano de projeto proposto.
Processo de monitoramento e controle: Assegurar que os objetivos do projeto estão sendo executados e atingidos, e quando necessário, lidar com as mudanças e aplicar ações corretivas.
Processo de encerramento: Formalizar o encerramento do projeto ou da fase de forma organizada.
Complementar aos grupos de processos, as áreas de conhecimento do gerenciamento de projetos, são definidas por suas áreas de abrangência em termos de processos que as compõem, suas ferramentas e práticas. Existem dez áreas de conhecimento, detalhadas conforme o PMBOK (PMI, 2017).
Gerenciamento de integração: Incorpora os processos que asseguram que os elementos que compõem um projeto sejam adequadamente coordenados durante o ciclo de vida do mesmo.
Gerenciamento de escopo: Incorpora todos os processos necessários, e somente aqueles necessários, para entregar um produto, serviço ou resultado exclusivo. Gerenciamento do cronograma: Incorpora todos os processos necessários para
estimar uma sequência de eventos de forma precisa.
Gerenciamento de custos: Incorpora todos os processos necessários para assegurar que um projeto seja devidamente finalizado dentro do orçamento acordado.
Gerenciamento da qualidade: Inclui todos os processos necessários para determinar a qualidade de projeto durante o ciclo de vida do mesmo.
Gerenciamento de recursos: Inclui os processos necessários para possibilitar a identificação, aquisição e gestão, com eficiência, dos recursos fundamentais para um projeto.
Gerenciamento de comunicação: Inclui todos os processos necessários para assegurar que as informações relativas ao projeto sejam transmitidas de forma coerente entre as partes interessadas.
Gerenciamento de risco: Inclui os processos necessários para maximização dos eventos positivos e minimização de possíveis ameaças que venham ocorrer durante a execução de um projeto.
Gerenciamento de aquisições: inclui os processos necessários para aquisição de bens ou serviços externos a organização detentora do projeto.
Gerenciamento das partes interessadas: inclui os processos necessários para gerenciar as partes interessadas, com o objetivo de aumentar o seu engajamento em relação ao projeto.
O PMBOK (PMI, 2017) é uma referência no quesito de gerenciamento de projetos, porém pode ser aplicado em diversas áreas, como saúde e finanças. A gestão de projetos aplicada diretamente ao desenvolvimento de software possui particularidades únicas, as quais os gerentes de projetos devem ficar atentos (WAZLAWICK, 2019). O SWEBOK (BOURQUE; FAIRLEY, 2014) destaca algumas destas particularidades, listadas abaixo:
Os stakeholders, em sua maioria, possuem dificuldade de compreender as reais dificuldades no desenvolvimento de software, principalmente em relação a mudança de requisitos no escopo.
Pode haver muitas mudanças de requisitos, podendo ocorrer um processo de refinamento interativo tanto no escopo, quanto no desenvolvimento.
A engenharia de software requer muita criatividade e disciplina, sendo difícil o balanceamento entre estes dois aspectos.
O grau de complexidade para desenvolver um software é extremamente alto, principalmente se considerado as novas tecnologias que surgem no mercado. Por fim, o gerente de projetos deve ter a habilidade de gerenciar os riscos, a partir da visualização de ameaças, antecipação de problemas e, se necessário, execução de ações preventivas (WAZLAWICK, 2019). Na seção seguinte são apresentadas as definições do que é um risco e o processo de gerenciamento de riscos.
2.2 GERENCIAMENTO DE RISCOS
Segundo o dicionário online Michaelis (2019, não paginado), o risco é: “Probabilidade de prejuízo ou de insucesso em determinado empreendimento, projeto, coisa etc. em razão de acontecimento incerto, que independe da vontade dos envolvidos”. Já a definição científica do que é o risco iniciou juntamente a época renascentista, em meados do século XVI, a partir dos estudos de Blaise Pascal, em 1654, com a Teoria da probabilidade, que estuda experimentos ou fenômenos aleatórios, a partir da probabilidade de eventos ocorrerem (NOGUEIRA, 2009).
Complementando estas definições, o PMBOK (PMI, 2004, p. 238) trata o risco como: “evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, âmbito ou qualidade”.
Com o passar do tempo, surgiu a importância de gerenciar riscos, se tornando um processo amplamente difundido nas mais diversas áreas, como administração, saúde e na parte de finanças, até ser formalmente difundido na área de software nos anos de 1980, com a definição do Modelo espiral (BOEHM, 1986), através da análise de risco iterativa, que buscava a avaliação e redução de riscos, através da definição de objetivos e planejamento prévio.
Riscos, em projetos de software, podem ter diversas causas, e caso ocorram, podem ter um ou mais impactos em um projeto. Estas causas podem ser requisitos, premissas, restrições ou condições, que criem a possibilidade de resultados positivos ou negativos (PMI, 2017).
O Risco, portanto, tem origem na incerteza existente em todos os projetos. Em tese, todo projeto de desenvolvimento de software há algum grau de incerteza que pode gerar problemas (WAZLAWICK, 2019). Os riscos conhecidos são aqueles que foram identificados e analisados, possibilitando o planejamento de respostas. Determinados riscos não podem ser gerenciados de forma proativa, o que sugere que a equipe do projeto crie um plano de contingência (WAZLAWICK, 2019).
Muitas organizações e partes interessadas estão dispostas a aceitar vários graus de riscos, o que é chamado de tolerância a riscos, pois busca-se sempre o equilíbrio entre as recompensas em assumir os riscos e as consequências que podem ser geradas (PMI, 2017).
Nesse sentido, o planejamento da gestão de riscos, quando realizado de forma correta, pode evitar retrabalho e problemas futuros em projetos de software. Dito isto, o objetivo deste processo, de maneira mais realista, é a prevenção e mitigação dos riscos, tornando os projetos, aos gerentes, mais previsíveis e controlados, através de aplicações de ações preventivas e corretivas (NOGUEIRA, 2009). Os princípios básicos para gestão de riscos estão descritos na figura 1.
Figura 1 - Princípios básicos da gestão de riscos.
Fonte: Figura adaptada de Nogueira (2009)
O processo completo de gerenciamento de riscos, pela definição do PMBOK (PMI, 2017), é composto pelos seguintes processos: planejamento da gestão, identificação, análise qualitativa e quantitativa, planejamento e implementação de respostas, monitoramento e controle de riscos.
Já o modelo de gerenciamento de riscos proposto pelo Software Engineering Institute (CARR et al, 1993) envolve, além destes cinco processos, a comunicação, pois é um processo fundamental ao longo do projeto em relação a prevenção e tratamento dos riscos, porém não é considerado um processo específico, já que permeia todas as atividades de gestão de riscos (WAZLAWICK, 2019).
Nos próximos capítulos são apresentados, com as respectivas descrições e detalhamento, os processos de gerenciamento de riscos proposto pelo PMBOK (PMI, 2017).
2.2.1 Planejar o gerenciamento de riscos
Segundo o PMBOK (PMI, 2017), o planejamento do gerenciamento de riscos engloba o processo de definição de como conduzir as atividades que envolvem os riscos de um projeto,
sendo assim, importante para fornecer tempo e recursos suficientes para as atividades de gestão dos riscos e para estabelecer uma base para a análise dos mesmos. O planejamento, em geral, determina não somente os riscos que serão avaliados, mas todo o plano de ação e contingência, para aqueles riscos que vão além da capacidade de mitigação (PIVETTA, 2002). O processo de planejar o gerenciamento dos riscos deve começar na concepção do projeto e ser concluído nas fases iniciais do planejamento do projeto.
Como entrada deste processo, há: declaração do escopo projeto, que estabelece a estrutura para o nível de importância que o esforço de gerenciamento dos riscos pode atingir, o plano de gerenciamento dos custos do projeto, que define o orçamento necessário para arcar com os riscos, o plano de gerenciamento do cronograma, que define como as contingências do cronograma serão reportadas e utilizadas, plano de gerenciamento de comunicações, que define as interações entre as partes interessadas, fatores ambientais da empresa, que definem as tolerâncias e atitudes em relação aos riscos que a organização pode suportar e os ativos de processos organizacionais, que podem influenciar no processo de planejamento da gestão dos riscos (PMI, 2017).
A definição de atividades do planejamento da gestão de riscos, pode acontecer em reuniões com os membros do projeto, com a finalidade de definir a forma que estes riscos serão tratados durante o ciclo de vida do projeto, como a priorização e o impacto das oportunidades e ameaças (PMI, 2017). Como resultado, é definido um plano de gerenciamento de risco que contempla, em geral, as seguintes informações: metodologia, papéis e responsabilidades, orçamento, prazos, categorias dos riscos, definições de probabilidade e impacto dos riscos, matriz de probabilidade e impacto, tolerância revisada das partes interessadas, formatos dos relatórios e monitoramento (PMI, 2017).
Como exemplificado na Figura 2, existem técnicas para definir os diferentes níveis de probabilidade e impacto dos riscos em projetos. Outras técnicas para identificação de riscos podem ser utilizadas, como o uso de checklists, com os possíveis riscos em um projeto e o relatório SEI de taxonomia de riscos (CARR et al, 1993).
Figura 2 – Definição de escalas de impactos em relação aos objetivos do projeto.
Fonte: PMI (2017)
Outro princípio que pode ser considerado para gestão de riscos é a antecipação de atividades de maior risco, já que certas ameaças podem inviabilizar o prosseguimento de um projeto, podendo se tornar um problema impossível de mitigar. Os riscos podem ser classificados em três grupos em relação ao conhecimento que se tem deles (WAZLAWICK, 2019):
Conhecidos: São os riscos já identificados e devidamente analisados que a equipe provavelmente já terá conhecimento e estará preparada.
Desconhecidos: Aqueles riscos que poderiam ter sido previstos, caso as medidas para identificação adequadas tivessem sido aplicadas.
Impossíveis de prever: Aqueles que não poderiam ser previstos, independentemente das técnicas de identificação de risco.
O plano de gerenciamento de riscos auxilia no tratamento do primeiro grupo de riscos. Para os riscos desconhecidos é necessário desenvolver e aplicar boas práticas de identificação. Já o terceiro grupo é necessário que o gerente de projeto e sua equipe estejam preparados para
responder, de forma organizada, as imprevisibilidades que um projeto de software possui (WAZLAWICK, 2019). Na seção seguinte é apresentado, com mais detalhes, aspectos relacionados com a identificação de riscos.
2.2.2 Identificar os riscos
Identificar os riscos é um processo de determinação de quais riscos podem afetar o projeto, antes que eles se tornem, efetivamente, problemas ou oportunidades inesperadas (PMI, 2017). Com os objetivos do projeto bem definidos, é possível realizar um levantamento inicial dos riscos possíveis em um projeto e iniciando, assim, o processo de identificação de oportunidades e ameaças, que pode ser conduzido sem precisar, necessariamente, buscar uma solução imediata para os riscos encontrados (NOGUEIRA, 2009).
A identificação de riscos é um processo iterativo, já que novos riscos podem surgir ou se tornar conhecidos durante o ciclo de vida de um projeto, cuja frequência da iteração e os participantes de cada ciclo variam de acordo com a situação (PMI, 2017). Os riscos podem trazer resultados positivos ou negativos, pela sua característica incerta. Semelhante aos requisitos de um projeto, os riscos devem ser identificados e priorizados adequadamente (WALZAWICK, 2019).
Para realizar esta atividade, deve-se considerar uma série de fatores para identificação dos riscos, como: estimativa de custos das atividades, estimativa de duração das atividades, linha de base do escopo, registro das partes interessadas, documentos do projeto, fatores ambientais da empresa, ativos de processos organizacionais e os planos de gerenciamento dos riscos, custos, cronograma e qualidade (PMI, 2017).
Há uma série de ferramentas e abordagens que podem ser aplicadas para realizar a identificação dos riscos, como demonstrado na Figura 3:
Figura 3 – Abordagens frequentemente utilizadas na identificação de riscos
Fonte: Figura adaptada de NOGUEIRA (2009)
O resultado do processo de identificação dos riscos é um registro dos riscos que, geralmente, contém os resultados dos outros processos de gerenciamento de ameaças e oportunidades, sendo atualizado e revisado conforme estes processos tenham o seu nível de complexidade aumentado, conforme o andamento do projeto (PMI, 2017). O registro dos riscos segue um modelo de causa e consequência, ou seja, se determinado evento ocorrer, terá uma causa, um impacto e um efeito.
2.2.3 Análise qualitativa dos riscos
Realizar a análise qualitativa dos riscos é o processo de priorizar os riscos conforme a probabilidade e o impacto de cada risco em potencial (PMI, 2017). As organizações podem definir a prioridade de cada atividade conforme os riscos mais relevantes e determinar se vale a pena despender esforço para sua prevenção (WAZLAWICK, 2019). Os impactos que os riscos podem acarretar nos objetivos do projeto consideram diversos fatores, como o intervalo de tempo para resposta e a tolerância a riscos da organização associada, a partir das restrições de
custo, cronograma, escopo e qualidade do projeto. A análise quantitativa dos riscos deve ser reavaliada durante o ciclo de vida de um projeto (PMI, 2017).
O processo de análise qualitativa dos riscos possui as seguintes entradas: o registro dos riscos, a declaração do escopo do projeto e os ativos de processo organizacional, para assim, fomentar uma forma consiste para tratamento destes riscos.
Segundo Sommerville (2011), para cada risco identificado deve-se fazer um julgamento sobre a probabilidade e gravidade desses riscos, partindo dos projetos anteriores e dos problemas que surgiram neles, confiando no potencial do gerente de projetos e da equipe, sem considerar, em termos numéricos, os impactos destes riscos, sendo recomendando utilizar técnicas para tabulação de riscos, agrupando-os por categorias de importância, conforme a Figura 4:
Figura 4 – Forma de cálculo para a importância de um risco.
Fonte: Figura adaptada de PMI (2017)
O resultado da categorização deve ser atualizado no registro dos riscos e incluído no documento do projeto, podendo ser adicionado também as causas de riscos ou áreas do projeto que requerem atenção especial, lista de riscos que requerem resposta a curto prazo, lista de riscos para análise e resposta adicional, listas de observação de riscos de baixa prioridade e tendências nos resultados da análise qualitativa de riscos (PMI, 2017).
2.2.4 Análise quantitativa dos riscos
O objetivo da análise quantitativa de riscos é considerar, numericamente, os impactos dos riscos identificados no projeto a partir de classificações individuais ou conjuntas de cada risco. Em alguns casos, realizar a análise quantitativa pode não ser necessária para desenvolver respostas eficazes a riscos, sendo em muitos casos uma etapa opcional, dependendo das necessidades da empresa (PMI, 2017).
O processo de análise quantitativa de riscos tem as seguintes entradas: registro dos riscos, ativos de processos organizacionais e os planos de gerenciamento de custos e cronograma.
O PMBOK (PMI, 2017) cita diversas técnicas para desenvolver a análise de risco, como entrevistas, distribuições de probabilidade, análise de sensibilidade e do valor monetário esperado. Uma ferramenta que é bastante difundida e utilizada para análise de impacto, que determina as possibilidades de cenários que podem acontecer e impactar nos objetivos de um projeto é a árvore de decisão, como mostrado na Figura 5:
Figura 5 – Diagrama da árvore de decisão.
Fonte: PMI (2017)
Os resultados destas análises devem ser adicionados ao registro de riscos com as outras informações levantadas a partir da análise qualitativa (PMI, 2017).
2.2.5 Planejar as respostas aos riscos
Planejar as respostas aos riscos tem como objetivo o fornecimento de opções e ações para aumentar as oportunidades e diminuir as ameaças referentes as metas do projeto. Esta etapa considera os riscos individualmente, possibilitando a fomentação de ações a serem tomadas em
relação a eles, que a partir da constante atualização do andamento do projeto, possibilita que problemas possam ser antecipados e mitigados o quanto antes. Para esta etapa não há um processo simples e definido que possa ser seguido, baseando-se muito na experiência da equipe e do gerente de projetos (SOMMERVILLE, 2011).
As respostas planejadas devem ser adequadas à relevância do risco e possuir eficácia de custos para atender aos desafios do projeto, por isso, deve-se considerar uma série de fatores preestabelecidos, como já possuir o registro dos riscos e o plano de gerenciamento dos riscos para definir quais as melhores ferramentas e técnicas a serem utilizadas. O PMBOK (PMI, 2017) sugere as seguintes estratégias para riscos negativos ou ameaças:
Prevenir: Para eliminar um risco por completo deve-se realizar a alteração do plano de projeto ou isolar o objetivo referente a este risco. Como consequência, poderá ocorrer alteração de cronograma e custo, e nos piores casos, até cancelamento do projeto.
Transferir: A transferência de um risco exige a mudança de responsabilidades para um terceiro, não o eliminando completamente. Esta estratégia é comumente utilizada quando se trata de riscos financeiros, como uso de fianças e seguros. Mitigar: A mitigação de um risco tem como objetivo a minimização dos efeitos
adversos de um evento dentro dos limites alcançáveis. Adotar estratégias de antecipação dos riscos e possuir planos de reparo auxilia a reduzir os danos aos objetivos do projeto em relação as medidas corretivas.
Aceitar: A aceitação de um risco é adotada quando é decidido não alterar o plano de projeto a partir de um evento de risco, seja pela falta de adoção de estratégias para contenção ou por decisão da equipe. A aceitação serve tanto para um risco positivo ou negativo.
Em relação aos riscos positivos ou oportunidades, o PMBOK (PMI, 2017) sugere outros tipos de estratégias:
Escalar: Esta estratégia é recomendada quando as respostas aos riscos estão fora do escopo e devem ser gerenciados por outra parte da organização e não no projeto que está sendo desenvolvido.
Explorar: Quando há a oportunidade de exploração de um risco com impactos positivos, as organizações tendem a reduzir as incertezas e garantir ao máximo a obtenção de benefícios em relação ao risco iminente, através de estratégias bem definidas.
Compartilhar: Ao compartilhar um risco é adotado a estratégia de alocação da oportunidade a um terceiro, melhor capacitado, que possa obter maior benefício. Melhorar: Essa estratégia é comumente utilizada para maximizar os benefícios que um risco pode trazer, desenvolvendo planos para impulsionar os impactos positivos ao projeto.
Como resultado do processo de planejamento de respostas aos riscos, pode-se atualizar o registro dos riscos e o plano de gerenciamento do projeto, além do documento completo do projeto, pois dependendo dos impactos dos riscos mensurados, pode haver comprometimento por completo dos objetivos de um projeto. Caso os riscos encontrados forem muito alarmantes, pode-se criar cláusulas contratuais para mitigação ou transferência dos riscos, por exemplo (PMI, 2017).
2.2.6 Implementar respostas aos riscos
Nesta etapa implementa-se as respostas aos riscos planejados, garantindo que as práticas acordadas para lidar com os riscos sejam executadas corretamente. Para este processo ser aplicado, deve-se utilizar como entrada o registro e o relatório de riscos (PMI, 2017).
Algumas ferramentas e técnicas devem ser consideradas como, a opinião especializada, habilidade da equipe e os sistemas para gerenciamento de projeto, que auxiliam no acompanhamento das respostas aos riscos (PMI, 2017).
O resultado desta etapa pode acarretar na solicitação de mudanças no plano de gerenciamento de um projeto, podendo haver alterações nos custos, cronogramas e recursos (PMI, 2017).
2.2.7 Monitorar os riscos
Monitorar os riscos é o processo para verificação das suposições realizadas sobre os riscos na etapa de planejamento, avaliando se o que foi proposto está se mantendo útil durante o ciclo de vida do projeto. O monitoramento de riscos também considera análises iterativas e regulares, para verificar se a probabilidade de ocorrência e impacto de um risco é iminente (SOMMERVILLE, 2011). Esta análise regular permite que as decisões acerca de um projeto possam ter como base as informações atuais sobre a exposição geral e individual de um risco (PMI, 2017).
A partir do registro e relatório de riscos, gerados na etapa de planejamento, é possível levantar informações importantes sobre o desempenho do projeto para determinar se as respostas aos riscos implementadas são efetivamente funcionais, se surgiram novos riscos ao longo do projeto e se as premissas estabelecidas ainda são válidas, pois caso a realidade do projeto seja diferente do que foi planejado, é necessário definir estratégias de controle para mitigar os efeitos de um risco (PMI, 2017).
Para realizar o monitoramento dos riscos, existem ferramentas e técnicas que auxiliam neste processo, como auditorias e reuniões rotineiras para revisão dos riscos, examinando se o que foi planejado está de fato acontecendo (PMI, 2017). Para fundamentar estas reuniões e auditorias, pode-se criar ou utilizar sistemas de controle de riscos já existentes, que permitam a atualização do status dos riscos, além de possibilitar o cadastro de novos riscos que possam ocorrer durante um projeto. A Figura 6 apresenta um possível ciclo de vida de um risco.
Figura 6 – Um possível ciclo de vida de um risco
Fonte: WAZLWICK (2019)
Como resultado do monitoramento de riscos, pode ocorrer mudanças nos custos e cronograma ou em outros componentes do plano de gerenciamento do projeto, e se necessário, deverá ser realizado ações, previamente planejadas no plano de contingência, para controlar os riscos.
Quando a atividade de monitoramento de risco se encerra, deve-se documentar e justificar as ações relacionadas as estratégias de controle, demonstrando todas as atividades realizadas para lidar com os riscos (NOGUEIRA, 2009). Este documento pode servir como base para lidar com riscos em outros projetos, auxiliando no desenvolvimento de planos de respostas aos riscos a partir de experiências anteriores (PMI, 2017).
Os processos de planejamento, implementação de respostas e monitoramento de riscos, podem se tornar extremamente custosos, em termos de tempo, cronograma e recursos, caso seja seguido formalmente todas as atividades relacionadas a gestão de riscos, principalmente em projetos de desenvolvimento de software (WAZLAWICK, 2019).
Portanto, no tópico seguinte são apresentadas normas relacionadas ao gerenciamento de riscos em projetos de desenvolvimento de software, que possam dar mais dinamicidade ao processo de gestão de riscos, considerando as especificidades deste tipo de projeto.
2.3 NORMAS E MODELOS RELACIONADOS
Nesta seção da fundamentação teórica são apresentadas normas e um meta-modelo que estão relacionados com o tema de gerenciamento de projetos, gestão de riscos e desenvolvimento de processos de software.
2.3.1 Norma ISO/IEC 16085
O PMBOK (PMI, 2017) fornece práticas gerais para gerenciamento de projetos, incluindo a gestão de risco. Entretanto, para a área de desenvolvimento de software existem algumas particularidades, abordadas pela norma ISO/IEC 16085 (ISO/IEC, 2006), que descreve um processo para a gestão de riscos direcionado a fornecedores, adquirentes, desenvolvedores e gerentes da área de software, em um único processo amplo. Esta norma não fornece uma técnica detalhada para gestão de riscos, mas se concentra na definição de um processo em que várias técnicas podem ser aplicadas.
O objetivo do gerenciamento de riscos, segundo a norma ISO/IEC 16085 (ISO/IEC, 2006), é identificar, analisar, tratar e monitorar os riscos continuamente e como resultado tem-se:
O escopo do gerenciamento de riscos.
Estratégias apropriadas de gerenciamento de riscos.
Riscos identificados à medida que se desenvolvem durante o ciclo de vida de um projeto.
Riscos analisados, considerando o impacto e a probabilidade de ocorrência, verificando-se a necessidade de angariar recursos para o tratamento destes riscos.
Medidas para controle dos riscos são definidas, aplicadas e avaliadas.
As respostas aos riscos, definidas para corrigir ou diminuir os impactos de eventuais problemas, com base na prioridade, probabilidade e consequência das ameaças.
Diferentemente da abordagem do PMBOK (PMI, 2017), possuir um plano para gerência de riscos é importante, porém, deve-se seguir uma avaliação iterativa com informações e feedback adquirido dos usuários e analistas durante o ciclo de vida de um projeto, podendo surgir novas formas de lidar com os riscos. O processo de gerenciamento de risco não é um processo cascata e todas as decisões realizadas, mesmo que iterativas, devem ser comunicadas as partes interessadas e os recursos devem ser estabelecidos (ISO/IEC, 2006).
Além das atividades práticas para gestão de riscos, a norma ISO/IEC 16085 (ISO/IEC, 2006) também fornece um padrão de documento, que deve ser completado pela empresa detentora do projeto, com a finalidade de registrar o gerenciamento de riscos através de um plano formal que deve ser compartilhado com as partes interessadas do projeto.
Esta norma oferece um processo mais dinâmico, considerando as especificidades dos projetos de software. No próximo tópico é apresentado a norma 1012-2012 (IEEE, 2012) que aborda modelos de avaliação e melhoria de processos, incluindo a gestão de riscos para organizações que atuam no desenvolvimento de software.
2.3.2 Norma IEEE 1012-2012 para verificação e validação de sistema e software
A norma 1012-2012 (IEEE, 2012) tem como objetivo fornecer padrões para verificação e validação de sistema e software, auxiliando organizações da área de tecnologia da informação a incorporar qualidade no software durante todo o ciclo da vida dos projetos, a partir de avaliações objetivas, determinando se os requisitos de software e sistema são corretos, completos, precisos, consistentes e testáveis, verificando se estão em conformidade com o que foi solicitado e atendendo as necessidades do usuário.
Os critérios de verificação e validação são os seguintes: avaliação, análise, revisão, inspeção e teste de produtos de software e sistemas (IEEE, 2012). Esta etapa é realizada em paralelo ao desenvolvimento do software, não na conclusão do esforço de desenvolvimento, permitindo que as organizações façam modificações no software em tempo hábil, afim de reduzir os riscos e impactos na conclusão de projetos (IEEE, 2012).
O processo de avaliação inclui a atividade de verificação do nível de integridade do software baseado em riscos, no qual define-se quatro níveis de integridade, descrevendo as consequências em caso de erros ou falha do software. Esta atividade permite interpretações individuais de quais riscos são aceitáveis dependendo da aplicação (IEEE, 2012). O Quadro 1 a seguir apresenta esses níveis de integridade com as respectivas descrições. O Quadro 2 apresenta as consequências dos erros com as respectivas descrições (IEEE, 2012).
Quadro 1 – Níveis de integridade do software/sistema baseado em possíveis erros.
Descrição Níveis
Um erro em uma função ou recurso do sistema causa:
- Consequências catastróficas para o sistema com probabilidade razoável, provável ou ocasional da ocorrência de um estado operacional que contribua para o erro; ou
- Consequências críticas com probabilidade razoável ou provável de ocorrência de uma operação estado que contribui para o erro.
4
Um erro em uma função ou recurso do sistema que causa:
- Consequências catastróficas com probabilidade ocasional ou infrequente de ocorrência de uma operação estado de contribuição que contribui para o erro;
ou
- Consequências críticas com probabilidade provável ou ocasional de ocorrência de uma operação estado que contribui para o erro;
ou
- Consequências marginais com probabilidade razoável ou provável de ocorrência de uma operação estado que contribui para o erro.
3
Um erro em uma função ou recurso do sistema que causa:
- Consequências críticas com probabilidade infrequente de ocorrência de um estado operacional que contribui ao erro;
ou
- Consequências marginais com probabilidade provável ou ocasional de ocorrência de uma operação estado que contribui para o erro;
ou
- Consequências negligenciáveis com probabilidade razoável ou provável de ocorrência de uma operação estado que contribui para o erro.
Um erro em uma função ou recurso do sistema que causa:
- Consequências críticas com probabilidade infrequente de ocorrência de um estado operacional que contribui ao erro;
ou
- Consequências marginais com ocorrência ocasional ou pouco frequente de um estado operacional que contribui para o erro;
ou
- Consequências negligenciáveis com probabilidade provável, ocasional ou infrequente de ocorrência de um estado operacional que contribui para o erro.
1
Fonte: Quadro adaptado de IEEE (2012).
Quadro 2 – Consequências em caso de erro ou falha do software/sistema.
Consequência Definição
Catastrófica
O elemento de software deve executar corretamente ou graves consequências ocorrerá (perda de vida, perda de sistemas e perda no viés econômico ou social). Nenhuma mitigação é possível.
Crítico
O elemento de software deve ser executado corretamente ou o uso pretendido (missão) do sistema / software não será realizado, causando sérias consequências (lesões permanentes, degradação do sistema, impacto econômico ou social). Mitigação parcial é possível.
Marginal
O elemento de software deve ser executado corretamente ou uma função pretendida não será realizada, causando pequenas consequências. Possível mitigação completa.
Negligenciável
O elemento de software deve ser executado corretamente ou a função pretendida não será realizada, causando consequências insignificantes. Mitigação não necessária.
Fonte: Quadro adaptado de IEEE (2012)
Concluindo, esta norma apresenta múltiplas atividades para verificação e validação de sistemas e software, baseando-se nos níveis de integridade de software para determinar quais atividades devem ser realizadas. Softwares com alto nível de criticidade requerem um conjunto mais complexo de processo, implementando tarefas mais rigorosas de gerenciamento de projetos, incluindo a gestão de riscos.
Na seção seguinte é apresentado uma norma e um meta-modelo, que possibilita o desenvolvimento de processos de software.
O presente trabalho propõe o desenvolvimento de um guia de gestão ágil de riscos. No sentido de entender como estruturar o conteúdo desse guia, a norma ISO/IEC 24774 e o Meta-modelo SPEM 2.0 são apresentados nesta seção.
A norma ISO/IEC 24774, cujo título é Gerenciamento de ciclo de vida - Orientações para descrição de processos (ISO/IEC, 2010) e o Meta-modelo SPEM 2.0 (OMG, 2008), tem como objetivo em comum fornecer, através de um guia estrutural, padrões para o desenvolvimento e aplicação de processos de software e sistemas, incluindo modelos para descrição de atividades, tarefas, ferramentas e outros.
A norma ISO/IEC 24774 apresenta um relatório técnico que fornece diretrizes específicas com o objetivo de uniformizar e facilitar o desenvolvimento de novos processos. O quadro 3 apresenta os elementos que compõem este relatório (ISO/IEC, 2010):
Quadro 3 – Elemento de um processo de software.
Elementos do processo Descrição
Título Cabeçalho descritivo do processo. Propósito Objetivo de executar o processo.
Saídas Resultados observáveis esperados do desempenho bem-sucedido do processo.
Atividades Lista de ações que podem ser utilizadas para alcançar os resultados. Cada atividade pode ser elaborada como um grupo de pequenas ações relacionadas.
Tarefas Ações específicas que podem ser executadas para alcançar uma atividade. Várias tarefas relacionadas são geralmente agrupadas em uma atividade.
Itens de informação Informações separadamente identificáveis, produzidas e armazenadas para uso pessoal durante um ciclo de vida do sistema ou software.
Fonte: Quadro adaptado de ISO/IEC (2010).
Nesta norma, os processos desenvolvidos, não obrigatoriamente, precisam contemplar todos os itens da tabela acima, podendo ter apenas o título, propósito e saídas, por exemplo, as atividades e as tarefas podem ser complementadas utilizando outras normas, como a ISO/IEC 15288:2008 (ISO/IEC, 2010).
O SPEM 2.0 (OMG, 2008), segue uma estrutura semelhantes a norma ISO/IEC 24774 (ISO/IEC, 2010), servindo como um guia para entender a semântica deste meta-modelo e os elementos necessários para desenvolver atividades de modelagem de processos, possuindo uma vasta gama de recursos, implementando a Linguagem de modelagem unificada (UML), permitindo a modelagem, através de aspectos gráficos, o desenvolvimento de implementações de sistemas e processos de software (GUEDES, 2009).
Assim, como a norma supracitada, o SPEM 2.0 (OMG, 2008) também provê um tipo de relatório técnico, que contém modelos estruturados, que descrevem os elementos que o compõe, como atividades, tarefas e outros elementos adicionais, como a descrição de papéis, equipes e ferramentas. Um exemplo de processo modelado utilizando a notação UML presente no SPEM 2.0 (OMG, 2008) é exemplificado na figura abaixo.
Figura 7 - Exemplo de uma atividade modelada utilizando UML
Fonte: OMG (2008)
2.4 MODELOS ÁGEIS
Segundo o Agile Practice Guide (PMI, 2017), o Agile pode ser um método, prática, abordagem, modelo ou framework, dependendo da situação que é utilizado, sendo que os termos mais genéricos são modelos e abordagens ágeis. Outras nomenclaturas são utilizadas quando há especificação do termo Agile, como ocorre com o Scrum, definido como um framework.
O uso de modelos ágeis está cada vez mais popular nas organizações que desenvolvem software. A atuação em ambiente globalizado exige respostas rápidas a mudanças e, valores como rapidez e flexibilidade são requeridos neste meio, fazendo com que muitas empresas
optem pela diminuição da qualidade e compromisso com os requisitos de software, focando em desenvolver sistemas mais funcionais e ágeis (SOMMERVILLE, 2011).
Em 2001, um grupo composto por 17 especialistas em elaboração e gestão de software se reuniram e definiram um guia com boas práticas de desenvolvimento de software, o chamado de Manifesto ágil (BECK et al., 2001). Os quatro valores que permeiam estas práticas são:
Interações e indivíduos em categoria superior a processos e ferramentas. Software funcional em categoria superior a documentação abrangente. Cooperação do cliente em categoria superior a negociação de contrato. Responder a mudanças em categoria superior a seguir um plano.
Estes valores são importantes, porém não significa que os modelos ágeis não valorizem processos, ferramentas, documentações e planos, como nos modelos prescritivos, mas estes elementos só possuem sentido se os valores acima forem cumpridos, pois pouco adianta cumprir contratos se o software não for funcional (WAZLAWICK, 2019). O Manifesto ágil (BECK et al., 2001), além dos valores apresentados, é complementado por doze princípios, citados a seguir:
Satisfazer o cliente através da entrega rápida e contínua de software funcional e com valor agregado.
Alterações de requisitos podem ocorrer mesmo de forma tardia. Os modelos ágeis utilizam-se de mudanças para obter vantagens.
Os períodos de entrega do software devem ser de poucas semanas a poucos meses, dando preferência a períodos mais curtos.
Área de negócio e equipe de desenvolvimento devem trabalhar alinhados durante o ciclo de vida do projeto.
Construir projetos com base em indivíduos motivados, confiando que irão cumprir os objetivos determinados.
O método mais eficiente para tratar a comunicação dentro da equipe é através da conversa pessoal e direta.
A principal medida do andamento de um projeto é o software funcional. O desenvolvimento deve ser realizado em ritmo constante de sustentável. A excelência técnica e design com qualidade, devem ser característica primárias
Deve-se prezar pela simplicidade, minimizando, sempre que possível, a quantidade de trabalho.
Equipes auto organizadas geram as melhores arquiteturas, requisitos e designs. A equipe deve regular sua eficiência, realizando os ajustes necessários.
Com a explicitação dos valores e princípios do desenvolvimento ágil de software é possível realizar comparações entre as modelos ágeis e tradicionais, como mostra a Figura 8:
Figura 8 – Comparativo entre modelos tradicionais e ágeis
Fonte: PRIKLADNICKI (2014)
Alguns obstáculos podem ser encontrados ao escolher metodologias ágeis para o desenvolvimento de software, como a dificuldade em escalar estas metodologias em grandes sistemas e organizações, principalmente as que possuem equipes com quantidade de membros abundantes, já que o foco principal dos modelos ágeis está em pequenas equipes bem integradas (SOMMERVILLE, 2011).
Outro exemplo de obstáculo identificado foi encontrado a partir de testes utilizando metodologias ágeis para o desenvolvimento de sistemas críticos, pois a necessidade de proteção dos dados e um nível maior de segurança do software, exigiu uma adequação significativa destes modelos, perdendo a agilidade e outros princípios que permeiam o Agile (SOMMERVILLE, 2011).
Na prática, os princípios e valores explicitados anteriormente dos modelos ágeis podem não se concretizar por diversos outros fatores, como, a falta de envolvimento das partes interessadas, membros da equipe que não interagem, não conseguir lidar com as mudanças que venham a ocorrer nos requisitos e a falta de adaptação a cultura ágil (SOMMERVILLE, 2011). Como muitas empresas não dispõem tempo exclusivamente para lidar com os riscos que possam vir a ocorrer nos projetos, como os riscos supracitados, as organizações tendem a fazer processos ágeis adaptáveis, de forma incremental, ou seja, a equipe de desenvolvimento se adapta em relação ao feedback do cliente e ao andamento do projeto, melhorando sua eficiência de forma proativa, para que não ocorra retrabalho e desperdício de recursos.
Uma forma de fazer isto é desenvolver protótipos ou entregar parte do sistema funcional, em um período curto de tempo, para que o cliente participe do processo de desenvolvimento e possa fornecer feedbacks (PRESSMAN, 2011).
Dito isto, escolher um modelo ágil que melhor se adapte ao modo de desenvolvimento de software de uma empresa pode ser uma tarefa complexa. De acordo com o Agile Practice Guide (PMI, 2017), os modelos ágeis cobrem uma variedade extensa de framework, métodos e práticas, sendo resumido na Figura 9 alguns destes modelos e como eles compartilham princípios e valores.
Figura 9 – Princípios compartilhados de modelos ágeis.
Fonte: PMI (2017)
Nos subcapítulos seguintes são apresentados alguns destes modelos ágeis com suas respectivas descrições e detalhamento.
2.4.1 Lean
O Lean, diferentemente do XP, exemplo de metodologia ágil, é considerado uma filosofia de gestão, inspirada em práticas e resultados do Sistema Toyota, não sendo uma metodologia propriamente dita (GUSTAVSSON, 2011). O autor Gustavsson (2011) também aborda que metodologias ágeis são aplicadas exclusivamente ao desenvolvimento de software, enquanto o Lean é um conceito muito mais abrangente da indústria, pois utiliza-se de conjuntos de ferramentas, para visar a logística eficiente e a eliminação de desperdícios.
O responsável pelo desenvolvimento e implementação do Lean foi Taiichi Ohno, também mentor do Sistema Toyota de Produção, cujo dilema principal é eliminar desperdícios (OHNO, 1997). Contudo, os responsáveis por trazer os conceitos do Lean para área de desenvolvimento de software, cunhando o termo Lean Software Development, foram os autores Tom e Mary Poppendieck (2013), que listaram sete princípios básicos do Lean com foco em desenvolvimento software, sendo eles:
Eliminar o desperdício: despender recursos somente com o que agregue valor real ao cliente.
Amplificar o aprendizado: Evitar postergar e precipitar decisões. Sempre que possível realizar ciclos de feedback menores e entregas frequentes.
Melhorar continuamente: As práticas de desenvolvimento de software podem ser melhoradas sempre.
Entregar eficientemente: O ciclo de desenvolvimento de software deve ser pensado com entregas incrementais, pensando nas mudanças que possam vir a ocorrer.
Engajar pessoas: O software não é construindo somente pela equipe de desenvolvimento, necessitando de profissionais de múltiplas áreas.
Manter a qualidade: Sempre que possível, desenvolver softwares modulares e integrados, evitando que os erros se propaguem.
Otimizar o todo: O software deve ter valor desde o entendimento do negócio e das necessidades do cliente.
O Lean pode ser aplicado em organizações que entendem seus processos, elencando os principais empecilhos para melhorar os processos internos e o fluxo de entrega dos projetos de software, com o objetivo de eliminar o máximo de desperdícios e gerar com valor ao cliente. (POPPENDIECK; POPPENDIECK, 2011).
No desenvolvimento de software, as principais causas dos desperdícios estão relacionadas com: trabalhos não finalizados, processos extensos, funcionalidades não planejadas, esperas, falhas, defeitos e equipes desfocadas (POPPENDIECK; POPPENDIECK, 2011).
Concluindo, as ferramentas e técnicas que contemplam o Lean, como o Just in time (CHASE, 2006), cuja ideia central é produzir exatamente a quantidade necessária para suprir as entregas ou o Jidoka (BLOKDYK, 2017) que permite a análise de qualidade pelo funcionário em processos automatizados, faz com que o Lean seja utilizado em organizações de múltiplas áreas, como a automobilística e o desenvolvimento de software, pois partindo dos seus princípios, pode-se adaptar à realidade de cada área, por isso, é considerado uma filosofia de gestão e não uma metodologia (POPPENDIECK; POPPENDIECK, 2011).
2.4.2 Kanban
O Kanban é uma abordagem gerencial utilizada em diversas áreas, incluindo a indústria automobilística e de desenvolvimento de software (ANDERSON, 2010). Sua origem teve início na década de 1950, por Taiichi Onho, que utilizando-se da ideia da administração, Just in time, propôs somente o uso de recursos necessários e nada mais, para chegar aos objetivos do projetos (OHNO, 1997).
A implementação experimental desta abordagem foi realizada na fábrica da Toyota, na qual utilizou-se o controle da produção e de estoque de forma dinâmica, conforme a demanda, para reduzir os custos associados ao estoque de materiais excedentes, se tornando um modelo pioneiro indústria automobilística (LIKER, 2004).
Após verificar o potencial do Kanban, o autor David J. Anderson atualizou o Kanban como uma abordagem ágil também aplicável na área de desenvolvimento de software, apresentando os seguintes princípios (ANDERSON, 2010):
Implementar naturalmente o Kanban, integrando com o que já está sendo feito. Não resistir a mudanças, muito pelo contrário, encorajá-las.
Respeitar a atual organização de processos, responsabilidades e funções. Liderar deve ser um ato de todos.
O Kanban pode ser aplicado nas mais diferentes esferas da produção de software, desde o desenvolvimento, até na parte de manutenção e testes. O autor Boeg (2012) destaca
