GUSTAVO PAIVA MESSIAS RIBEIRO

UM ESTUDO SOBRE GERENCIAMENTO DE RISCOS NOPROCESSO DE DESENVOLVIMENTO DE SOFTWARE

LONDRINA2019

GUSTAVO PAIVA MESSIAS RIBEIRO

UM ESTUDO SOBRE GERENCIAMENTO DE RISCOS NOPROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Versão Preliminar de Trabalho de Conclusãode Curso apresentado ao curso de Bachare-lado em Ciência da Computação da Univer-sidade Estadual de Londrina para obtençãodo título de Bacharel em Ciência da Compu-tação.

Orientador: Rodolfo Miranda de BarrosCoorientador: Prof(a). Dr(a). Nome do(a)

Coorientador(a)

LONDRINA2019

Ficha de identificação da obra elaborada pelo autor, através do Programa de GeraçãoAutomática do Sistema de Bibliotecas da UEL

P149 Ribeiro, Gustavo Paiva Messias.UM ESTUDO SOBRE GERENCIAMENTO DE RISCOS NOPROCESSO DEDESENVOLVIMENTO DE SOFTWARE / Gustavo Paiva Messias Ribeiro. -Londrina, 2019.39 f.

Orientador: Rodolfo Miranda de Barros Barros.Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) -

Universidade Estadual de Londrina, Centro de Ciências Exatas, Graduação emCiência da Computação, 2019.

Inclui bibliografia.

1. GERENCIAMENTO DE PROJETOS - TCC. 2. GERENCIAMENTO DERISCOS - TCC. 3. GERENCIAMENTO DE RISCOS NO PROCESSO DESOFTWARE - TCC. I. Barros, Rodolfo Miranda de Barros. II. UniversidadeEstadual de Londrina. Centro de Ciências Exatas. Graduação em Ciência daComputação. III. Título.

CDU 519

Powered by TCPDF (www.tcpdf.org)

GUSTAVO PAIVA MESSIAS RIBEIRO

UM ESTUDO SOBRE GERENCIAMENTO DE RISCOS NOPROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Versão Preliminar de Trabalho de Conclusãode Curso apresentado ao curso de Bachare-lado em Ciência da Computação da Univer-sidade Estadual de Londrina para obtençãodo título de Bacharel em Ciência da Compu-tação.

BANCA EXAMINADORA

Orientador: Rodolfo Miranda de BarrosUniversidade Estadual de Londrina

Prof. Dr. Segundo Membro da BancaUniversidade/Instituição do SegundoMembro da Banca – Sigla instituição

Prof. Dr. Terceiro Membro da BancaUniversidade/Instituição do TerceiroMembro da Banca – Sigla instituição

Prof. Ms. Quarto Membro da BancaUniversidade/Instituição do Quarto

Membro da Banca – Sigla instituição

Londrina, 24 de novembro de 2019.

A mente que se abre a uma nova ideiajamais voltará ao seu tamanho original.

(Albert Einstein)

AGRADECIMENTOS

Quero agradecer a minha Família e aos meus amigos. A Deus pelas oportunidadesque continuamente coloca em minha vida. A todos os professores inspiradores que tive aolongo de minha formação. Ao meu orientador Prof. Rodolfo Miranda de Barros, por meaceitar como orientando e me guiar e apoiar nessa reta final. E também a UniversidadeEstadual de Londrina e o Departamento de Computação por me proporcionarem esseótimo ambiente de estudo.

“Aprendera ha muito que a sociedadeImpõe insultos que devem ser suportados,

confortados pelo conhecimento de que nestemundo chega o momento em que o mais

humilde dos homens, se conservar os olhosabertos, pode vingar-se do mais poderoso.

(Don Vito Corleone)

RIBEIRO, N. A.. Um estudo sobre gerenciamento de riscos no processo de de-senvolvimento de software. 2019. 42f. Trabalho de Conclusão de Curso – Versão Pre-liminar (Bacharelado em Ciência da Computação) – Universidade Estadual de Londrina,Londrina, 2019.

RESUMO

Nos dias atuais para um gerenciamento de projeto é imprescindível o gerenciamento deriscos de um projeto, para que não ocorra atrasos e nem um aumento de orçamento.Graças ao Gerenciamento de Riscos podemos identificar e controlar os riscos antes queeles afetem o projeto. Este trabalho tem por objetivo estudar sobre o gerenciamento deriscos no processo de desenvolvimento de software e aplicar o GAIA Riscos na metologiaágil Scrum.

Palavras-chave: Gerenciamento de riscos. Gerenciamento de Projetos. Scrum

RIBEIRO, N. A.. Title of the Work. 2019. 42p. Final Project – Draft Version (Bachelorof Science in Computer Science) – State University of Londrina, Londrina, 2019.

ABSTRACT

Nowadays for project management it is essential to manage the risk of a project so thatthere is no delay and no budget increase. This paper aims to study risk management inthe software development process and apply GAIA Risks to agile methodology Scrum.

Keywords: Risk management. Project management. Scrum

LISTA DE ILUSTRAÇÕES

Figura 1 – Relacionamento entre o Grupo de Processos do PMBOK[1] . . . . . . . 17Figura 2 – Visão geral de Planejamento do Gerenciamento dos riscos[1] . . . . . . 22Figura 3 – Visão geral de identificar os riscos[1] . . . . . . . . . . . . . . . . . . . 23Figura 4 – Visão geral de realizar a análise qualitativa dos riscos[1] . . . . . . . . . 24Figura 5 – Visão geral de realizar a análise quantitativa dos riscos[1] . . . . . . . . 25Figura 6 – Visão geral de planejar as Respostas aos Riscos[1] . . . . . . . . . . . . 26Figura 7 – Visão geral de Implementar as Respostas aos Riscos[1] . . . . . . . . . 27Figura 8 – Visão geral de Monitorar os Riscos[1] . . . . . . . . . . . . . . . . . . . 28Figura 9 – Estrutura do framework GAIA Riscos[2] . . . . . . . . . . . . . . . . . 31Figura 10 – Componentes do Serviço do framework GAIA Riscos[2] . . . . . . . . . 32Figura 11 – Modelo de Questão do framework GAIA Riscos[2] . . . . . . . . . . . . 34Figura 12 – Peso de questão nos serviços do framework GAIA Riscos[2] . . . . . . . 35Figura 13 – Método Scrum [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figura 14 – Linha de Tempo de um Sprints do Scrum [4] . . . . . . . . . . . . . . . 38Figura 15 – Linha de Tempo de um Sprints do Scrum[4] com QAD[2] . . . . . . . 39

LISTA DE TABELAS

LISTA DE ABREVIATURAS E SIGLAS

GP Gerenciamento de Projeto

GQ Grupos de Questões

GR Gerenciamento de Risco

PDS Processo de Desenvolvimento de Software

PMBOK Project Management Body of Knowledge

PMI Project Management Institute

QAD Questionário de Avaliação Diagnostica

PRINCE2 Projects in Controlled Environments

BDH Banco de Dados Histórico

RF Resultado Final

FP Faixa de Pontuação

FM Fator Multiplicado

FA Fator de Ajuste

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . 152.1 Gerenciamento de Projetos . . . . . . . . . . . . . . . . . . . . . . 152.1.1 A Guide to the Project Management Body of Knowledge (PMBOK) . 152.1.2 PRINCE2 (Projects In Controlled Environments) . . . . . . . . . . . . 172.1.2.1 Princípios do PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.2.2 Temas do PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.2.3 Processos do PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.3 Gerenciamento de Projetos no Desenvolvimento de Software . . . . . . 202.2 Gerenciamento de Riscos . . . . . . . . . . . . . . . . . . . . . . . 20

3 ESTUDO SOBRE O FRAMEWORK GAIA RISCOS . . . . . 303.0.1 Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.0.2 Níveis de Maturidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.0.3 Questionário de avaliação Diagnóstica . . . . . . . . . . . . . . . . . . 333.1 Scrum aplicado a Framework GAIA Riscos . . . . . . . . . . . . 363.1.1 Aplicação Scrum no Framework GAIA Riscos . . . . . . . . . . . . . . 36

4 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

13

1 INTRODUÇÃO

A utilização do gerenciamento de projetos cresceu muito nos últimos anos e vemsendo o alvo de estudos, as organizações estão optando por gerenciamento de projetoscomo um meio de alcançar as metas de seus planejamentos estratégicos[5].

Um projeto tem seu inicio e fim definidos em tempo, com conjunto específico deoperações destinadas a atingir um objetivo. No projeto existe equipes que inclui pessoase elas devem ser gerenciadas de forma especializada para apresentarem os resultados,aprendizados e integração essencial para a organizações dentro do prazo e do orçamentoprevistos[5].

Para poder desenvolver um projeto de software, precisa-se de um bom processo dedesenvolvimento de software, para isso precisa de muita cautela e um bom planejamentoantes de começar a desenvolver senão pode ocorrer erros graves durante várias etapas,podendo comprometer o projeto ao ponto de abortar [5].

Para planejar não é fácil e desenvolver também não, em uma empresa de desenvol-vimento de software já bem consistente, são executadas atividades antes, durante e depoisdo desenvolvimento do projeto[5]. Todos os dias, pessoas correm riscos, de pegar chuva,de cair, de sofrer acidente de transito, de se cortar com faca fazendo alguma coisa decomida e etc. Isso são alguns riscos no dia a dia que podem ocorrer, para prevenção des-ses riscos, levar guarda chuva para não se molhar, prestar atenção ao andar, ficar atentoao transito e caso esteja dirigindo sempre prestar atenção, prestar atenção na hora decortar algum alimento etc. Essas são algumas prevenção para aqueles riscos[5], o mesmoacontece para um projeto de software, que ao planejar um projeto é necessário prever osriscos que impedem que alcance os objetivos definidos no projeto[1].

No planejamento do projeto que se encontra a identificação de riscos, porém tam-bém é uma atividade a ser executada durante todo o desenvolvimento do projeto. Para ocontrole riscos é fundamental um programa que previna percas e diminua a frequência ea gravidade de acidentes [6].

O gerenciamento de riscos pode possibilitar a compreensão da natureza do projetograças ao envolvimento dos membros da equipe, que identificam e respondem quais ospossíveis riscos esse projeto pode apresentar[7]. Normalmente os riscos estão vinculadosa tempo, qualidade e custos [7].

De acordo com estatísticas, cerca de 32% dos projetos de software são entreguesdentro do planejado, 44% acabam sendo entregue depois do prazo e 24% são encerradosantes da sua conclusão, ou seja, acabam não sendo entregues [6].

14

Com a finalidade de acabar com essa realidade nas quais os projetos de softwaresão afetados por algum tipo de problema, as entidades devem aderir recursos e processoscada vez mais eficazes para manterem seguros. Tornando o Gerenciamento de Projetosuma atividade de grande importância por meios de métodos, ferramentas e processos, osgerentes podem identificar, analisar e avaliar os impactos que uma certa ameaça podecausar ao projeto e assim esses gerentes podem planejar e executar ações corretivas parao projeto[1].

Neste trabalho apresenta o estudo de Gerenciamento de Riscos no processo dedesenvolvimento de software, onde foi comparado alguns processos de gerenciamentos deriscos. Também falado sobre a metodologia ágil scrum[8], onde aplica-se no frameworkGAIA RISCOS.

A organização segue da seguinte maneira: No Capítulo 1, compreende está intro-dução. O Capítulo 2, são apresentados conceitos e definições usados neste trabalho e olevantamento de trabalhos relacionados. No Capítulo 3 será descrito um estudo sobre oFramework GAIA RISCOS e a metodologia ágil Scrum e sua aplicação. No Capítulo 4,encontram-se as conclusões finais sobre o trabalho.

15

2 FUNDAMENTAÇÃO TEÓRICA

Para melhorar o entendimento deste trabalho, nesta seção explicaremos algunsconceitos que embasam a elaboração deste trabalho.

2.1 Gerenciamento de Projetos

Um Projeto é um conjunto de atividades temporárias, realizadas em um grupo,destinada a produzir um produto e um resultado. O projeto tem inicio e fim definidos emtempo, e assim um escopo e recursos são definidos envolvendo um determinado numerode pessoas, as quais normalmente são organizadas em um time.

Os projetos criam valor e benefícios para as organizações. Atualmente no ambientede negócios, os lideres que gereciam projetos, precisam gerenciar estes orçamentos cadavez mais apertados, custos, prazos, recursos mais escassos e uma tecnologia que mudarapidamente. Como é dinâmico o ambiente de negocio, com esse ritmo acelerado de mu-dança, as empresas para se manterem competitivas na economia mundial, estão adotandoo gerenciamento de projetos para entregar valor ao negócio de forma consistente.

O Gerenciamento de Projeto (GP)[9] é a aplicação de conhecimentos, habilidades,ferramentas e técnicas às atividades do projeto a fim de cumprir os seus requisitos[2].O GP cria um equilíbrio entre um projeto, onde se envolve um determinado número depessoas, as quais geralmente são organizadas em times, na qual garante a entrega doproduto de acordo com as metas de prazo, qualidade e custo[10].

2.1.1 A Guide to the Project Management Body of Knowledge (PMBOK)

Project Management Institute (PMI) [1], é uma instituição internacional sem finslucrativos que associa profissionais de gestão de projetos. Em seu livro A Guide to theProject Management Body of Knowledge (PMBOK)[11], descreve conceitos e melhorespraticas das áreas de gerenciamento. Esse guia se divide em dez áreas de Conhecimentoque são utilizadas na maioria dos projetos na maior parte das vezes[1]. As 10 áreas degerenciamento[1] são:

∙ Gerenciamento da integração do projeto: engloba processos e atividades ne-cessárias para definir, unificar, combinar e coordenar processos e atividades de GPnos grupos de processo de gerenciamento de projetos[1];

∙ Gerenciamento do escopo do projeto: Contém processos necessários para as-segurar que o projeto contemple todo o trabalho necessário[1];

16

∙ Gerenciamento do cronograma do projeto: engloba os processos necessáriospara gerenciar o término pontual do projeto[1];

∙ Gerenciamento dos custos do projeto: Contém os processos relacionados aoscustos do projeto, para que o projeto possa ser terminado dentro do orçamentoaprovado[1];

∙ Gerenciamento da qualidade do projeto: inclui processos relacionados com aqualidade do projeto e do produto de forma que consiga atender as expectativas daspartes interessadas[1];

∙ Gerenciamento dos recursos do projeto: engloba os processos para identifi-car, adquirir e gerenciar os recursos necessários para a conclusão satisfatória doprojeto[1];

∙ Gerenciamento das comunicações do projeto: Contém os processos necessá-rios para garantir que as informações do projeto sejam planejadas, coletadas, cria-das, distribuídas, armazenadas, recuperadas, gerenciadas, controladas, monitoradase organizadas[1];

∙ Gerenciamento dos riscos do projeto: Contém os processos de condução deplanejamento, identificação e analise de gerenciamento de riscos, planejamento deresposta, implementação de resposta e monitoramento de risco em um projeto[1];

∙ Gerenciamento das aquisições do projeto: Contém os processos necessáriospara comprar ou adquirir produtos, serviços ou resultados externos à equipe doprojeto[1];

∙ Gerenciamento das partes interessadas do projeto: Contém os processos exi-gidos para identificar as pessoas, grupos ou organizações que podem impactar ouserem impactados pelo projeto, analisar as expectativas das partes interessadas e seuimpacto no projeto, e desenvolver estratégias de gerenciamento para suas decisõese execução do projeto[1].

Os Grupos de Processos de Gerenciamento de Projetos[12] são independentes das fases doprojeto, um agrupamento lógico de processos de GP para atingir os objetivos específicosdo projeto. Esses processos são agrupados em cinco Grupos de Processos de GP[1]:

∙ Grupo de processos de iniciação: repensável por obter autorização para iniciarum projeto ou uma fase[1];

17

∙ Grupo de processos de planejamento: estipula o que deve ser feito e como deveser feito por meio da declaração do escopo e do planejamento de gerencia do projeto,pelo qual foi objetivado[1];

∙ Grupo de processos de execução: mediante a integração de pessoas, organizaçãoe recursos é possível realizar as entregas do projeto ao serem executadas[1];

∙ Grupo de processos de monitoramento e controle: Identificam os desvios e oinício das mudanças necessárias ao acompanhar e revisar regularmente o progressoe o desempenho do projeto[1];

∙ Grupo de processos de encerramento: formalizam o encerramento do projetoe finalizam as atividades dos grupos de processos, encerram os contratos e a desmo-bilização da equipe[1].

A figura 1 mostra o relacionamento entre os grupos.

Figura 1 – Relacionamento entre o Grupo de Processos do PMBOK[1]

2.1.2 PRINCE2 (Projects In Controlled Environments)

Com o sucesso do PMBOK[13], outras associações lançaram guias de melhorespraticas para o GP. No reino unido tem sido muito utilizado como padrão para gerenci-amento de projetos o PRINCE2 (Projects In Controlled Environments)[14], atualmentepropriedade da AXELOS Limited, porém a utilização do PRINCE2 nas organizações élivre, sem custos. PRINCE2[15] é um método baseado no processo para a gestão eficaz deum projeto. Projetado para ser genérico, para que possa ser aplicado a qualquer projeto,independentemente da escala do projeto, o método PRINCE2[15] trata do gerenciamento

18

de projetos com quatro elementos integrados princípios, temas, processos e o ambiente doprojeto:

∙ Princípios PRINCE2: São as obrigações orientadoras e boas práticas que determi-nam se o projeto está sendo usado pelos sete princípios gerenciado pelo PRINCE2[15].

∙ Temas PRINCE2: Os sete temas são abordados continuamente e em paraleloao longo do projeto, explicando o tratamento específico para várias disciplinas deGP[15].

∙ Processos PRINCE2: Descrevem uma progressão da atividade pré-projeto deintrodução, por meio das etapas do ciclo de vida do projeto, até o encerramento doprojeto[15].

∙ Ambiente de Projeto: Geralmente as organizações desejam uma abordagem con-sistente para gerenciar projetos e adaptar PRINCE2 para criar seu próprio métodode gerenciamento de projetos[15].

Esses são os requisitos que determinam se o projeto está sendo gerenciado genui-namente usando o PRINCE2[15].

2.1.2.1 Princípios do PRINCE2

Os sete princípios do PRINCE2 são:

1. Justificativa continuada de negócios: deve haver uma razão justificável para es-tar executando e gerenciando o projeto. Caso contrario,o projeto deve ser fechado[16].

2. Aprenda com a experiência: toda equipe de projeto PRINCE2, aproveita con-tinuamente as lições aprendidas nos trabalhos passados[16].

3. Papéis e responsabilidades definidos: para se ter um trabalho eficiente, asequipes de projeto PRINCE2, precisam ter uma estrutura organizacional clara eenvolver as pessoas certas nas tarefas certas[16].

4. Gerenciar por etapas: os projetos do PRINCE2 devem ser planejados, monitora-dos e controlados passo-a-passo[16].

5. Gerenciar por exceção: cada membro da equipe do projeto PRINCE2, devem re-ceber a quantidade certa de autoridade para trabalhar efetivamente no ambiente[16].

6. Foco nos produtos: o foco do projeto do PRINCE2 se concentram nos requisitosde definição, qualidade do produto e entrega[16].

19

7. Adaptar para se adequar ao ambiente do projeto: O PRINCE2 deve ser adap-tado para se adequar ao ambiente, tamanho, complexidade, capacidade, importânciae risco do projeto[16].

2.1.2.2 Temas do PRINCE2

Os temas devem ser abordados em paralelo ao longo do projeto, explicando otratamento especifico exigido pelo PRINCE2[15], indicando o requisito mínimo essencialpara cada tema, e oferece orientações especificas sobre como adaptar estes temas a deter-minados ambientes. Os setes temas são:

1. Business case: Crie e mantenha um registro da justificativa comercial do projeto[16].

2. Organização: definir a equipe os papeis e responsabilidade individuais[16].

3. Qualidade: para saber como o projeto será entregue, precisam compreender quaissão os requisitos e medidas de qualidade[16].

4. Planos: são etapas fundamentais para o desenvolvimento de planos e técnicas[16].

5. Risco: identificar de fato os riscos e oportunidades que possam impactar o projeto[16].

6. Mudança: como o gerente de projeto avaliará e agirá em mudanças no projeto[16].

7. Progresso: a efetividade e comportamento contínuos dos planos e como e se oprojeto deve continuar[16].

2.1.2.3 Processos do PRINCE2

Os processos representam as fases do ciclo devida do projeto, desde a ideia inicialate o fechamento do projeto. Cada processo oferece listas de verificação de atividadesrecomendadas, responsabilidades e orientação. Os sete processos são[15]:

1. Começando um projeto

2. Direcionando um projeto

3. Iniciando um projeto

4. Controlando um estágio

5. Gerenciando a entrega de produtos

6. Gerenciando os limites do palco

7. Fechando um projeto

20

2.1.3 Gerenciamento de Projetos no Desenvolvimento de Software

Os projetos de desenvolvimento de software apresentam um desafio distinto quandocomparado à maioria dos outros tipos de projetos existentes. No fato dos projetos deengenharia ou manufatura, por exemplo, as condições são facilmente identificados e errosde uma parte do projeto é raro[1].

Já em projetos de softwares, é comum ocorrer erros e alterações durante o projeto.Um exemplo, em construções civil ou nas industrias tradicionais, não é comum que ocor-rem alterações nas especificações durante as fases de construção ou produção. Quandoocorre, os orçamentos acabam sendo altíssimos. Em projetos de software como dito écomum que ocorrem alterações nas especificações, entregas fora do prazo, problemas noorçamento, manutenção e custo acima da expectativa.

O projeto de software, é uma fase de desenvolvimento, na qual são feitos mode-los com todas as entidades que serão construídas posteriormente a partir dos requisitosdo sistema. Focado em 4 áreas, como dados, arquitetura, interface e componentes. Asatividades do GP, procuram criar um equilíbrio para o projeto, garantindo a entrega doproduto de acordo com as metas de prazo, qualidade e custo.

No GP, é essencial a necessidade de se utilizar metodologias eficientes para admi-nistrar os projetos de software. Citaremos algumas metodologias de GP, para o o aumentode qualidade dos processos, como visto o PMBOK, modelo PRINCE2 e modelos de me-lhoria de processo de software.

2.2 Gerenciamento de Riscos

Em qualquer projeto existem riscos, tendo graus variados de complexidade quepossam proporcionar benefícios, alguns podendo ser conflitantes e mutáveis[1]. As enti-dades devem escolher por correr o risco do projeto de maneira controlada e com intuiçãode criar valor e ao mesmo tempo manter equilibrado os riscos e recompensas que podemocorrer no projeto[1].

Com o objetivo de controlar os riscos, o Gerenciamento de Riscos (GR)[17] doprojeto, visa identificar e controlar os riscos que não são considerados pelos outros pro-cessos de Gerenciamento de Projeto. No momento estes riscos não são gerenciados e temcapacidade para desviar o projeto do plano e impedir que alcance os objetivos definidosno projeto[1].

O Gerenciamento de Riscos contém os processos de gerência do planejamento, daidentificação, da análise, do planejamento das respostas, da implementação das respostase do monitoramento dos riscos em um projeto [1]. Tem-se por objetivo aumentar a pro-babilidade e/ou impacto de riscos positivos e diminuir a probabilidade e/ou impacto de

21

riscos negativos que irão prejudicar o projeto. Existem processos para o GR, que são:

∙ Planejar o Gerenciamento de Riscos: definir as atividades de gerenciamentodos projetos de riscos. Figura 2[1].

∙ Identificar Riscos: Identificar os riscos individuais e documentar suas caracterís-ticas. Figura 3[1].

∙ Realizar a Análise qualitativa dos riscos: Prioriza riscos individuais do projetopara análise, através de sua probabilidade e impacto no projeto. Figura 4[1].

∙ Realizar a Análise quantitativa dos riscos: Analisar numericamente o efeitocombinado dos riscos individuais do projetos. Figura 5[1].

∙ Planejar as respostas aos Riscos: Criar alternativas, selecionando estratégiaspara lidar com a exposição geral de riscos e tratar os riscos individuais. Figura 6[1].

∙ Implementar Respostas a Riscos: Implementar planos de respostas aos riscos.Figura 7[1].

∙ Monitorar os Riscos: Monitorar a implementação de planos de respostas aosriscos, acompanhar os riscos identificados, identificar e analisar novos riscos e assimavaliar a ação do processo de risco ao longo do projeto. Figura 8[1].

22

Figura 2 – Visão geral de Planejamento do Gerenciamento dos riscos[1]

23

Figura 3 – Visão geral de identificar os riscos[1]

24

Figura 4 – Visão geral de realizar a análise qualitativa dos riscos[1]

25

Figura 5 – Visão geral de realizar a análise quantitativa dos riscos[1]

26

Figura 6 – Visão geral de planejar as Respostas aos Riscos[1]

27

Figura 7 – Visão geral de Implementar as Respostas aos Riscos[1]

28

Figura 8 – Visão geral de Monitorar os Riscos[1]

29

Segundo o PMBOK[1], todos os projetos apresentam, existem riscos em dois ní-veis. Todo projeto contém riscos próprios, que podem afetar o alcance dos objetivos doprojeto[1]. Considerando o grau de risco em que o projeto está, que aconteça a combinaçãodos riscos individuais do projeto e de outros motivos de incerteza. Os processos de GR doprojeto tratam dos dois graus de risco em projetos, sendo:

∙ O risco individual do projeto Um evento que se acontecer, causara um efeitopositivo ou negativo em um ou mais objetivos do projeto[1].

∙ O risco geral do projeto Efeito de incerteza do projeto, resultantes de todas asfontes de incerteza, incluindo riscos individuais, representando a definição das partesinteressadas, sejam positivas ou negativas[1].

Os riscos continuarão a surgir durante o ciclo de vida do projeto, sendo que osprocessos de GR devem ser realizados iterativamente. Os riscos são abordados durante oplanejamento através da modelagem de estratégia do projeto, sendo também, monitoradose gerenciados no decorrer do projeto, para garantir que o projeto seja como planejado eos riscos planejados sejam tratados.

Para gerenciar os riscos de forma positiva em determinado projeto, a equipe deprojeto precisa conhecer qual nível mostra que o risco é aceitável para a realização dosobjetivos do projeto[1].

30

3 ESTUDO SOBRE O FRAMEWORK GAIA RISCOS

Este capitulo apresenta o framework GAIA Riscos [2], para gerenciamento de ris-cos em projetos de software, criado pelo Fernando Henrique Gaffo. Segundo Gaffo [2], oframework tem como objetivo melhorar os processos para determinar o contexto, identi-ficar, analisar, avaliar, tratar, comunicar e monitorar os riscos por meio de melhorias noProcesso de Desenvolvimento de Software(PDS) de uma organização.

GAIA Riscos é dividido em quatro componentes principais, que são:

1. Sete serviços: Esses serviços têm como objetivo oferecer qualidade aos clientes,proporcionando que eles alcancem seus resultados, sem que eles assumam com oscustos e riscos envolvidos[2].

2. Cinco níveis de maturidade: Estabelecem estágios para evoluir a gestão e propor-cionar às organizações benefícios para adotar as atividades envolvidas no processo[2].

3. Questionário de avaliação diagnostica(QAD): Organizado em sete Grupos deQuestões(GQ), tem como função identificar, por meio das respostas do questionário,o grau de maturidade com que o PDS que está sob analise[2].

4. Processo de Implantação: Para a implantação do framework GAIA Riscos em umPDS, precisa seguir alguns procedimentos que determinam o nível de maturidadedo PDS, revisar sua ligação a um determinado nível e avaliar sua capacidade deevolução para níveis superiores[2].

31

Na figura 9 é possivel observar a estrutura do framework GAIA Riscos[2].

Figura 9 – Estrutura do framework GAIA Riscos[2]

3.0.1 Serviços

Os sete serviços do GAIA Riscos[2], possui cinco áreas que organizam as informa-ções adequados a esse gerenciamento, podendo ser alterado ao decorrer do projeto. Ascinco áreas são:

∙ Ferramentas e Técnicas: Abrange recursos e metodologias que permitem aplicare introduzir as práticas do GR em uma organização[2];

∙ Templetes de Documentos: São modelos de documentos com a finalidade denormalizar os registros do GR[2];

∙ Indicadores de Desempenho: Determinam métricas, para avaliar a evolução doGR e estimular a evolução desta gerencia[2];

∙ Workflows: Caracterizar os processos padrão para controlar os riscos em umaorganização[2];

∙ Vocabulários: Abrangem terminologias, nomenclaturas e siglas comuns a ativida-des dos serviços[2];

32

Esses cinco componentes de serviços como observado na figura 10, organizam asinformações convenientes a esta gerencia.

Figura 10 – Componentes do Serviço do framework GAIA Riscos[2]

A seguir os sete serviços do GAIA Riscos[2], são:

∙ Identificar Riscos: Analisar os planos do projeto para adquirir uma lista de riscos.Para compor a lista de riscos, realizam-se reuniões brainstorming, análise documen-tais, entrevistas com os envolvidos e consultorias no BDH[2].

∙ Estabelecer o Contexto: São as definições que irão orientar as atividades de iden-tificação, análise, avaliação, tratamento e monitoramento dos riscos, como tambéma comunicação entre os envolvidos[2].

∙ Analisar Riscos: Entendimento dos riscos identificados para gerar uma lista deriscos analisados[2].

∙ Avaliar Riscos: Semelhança dos riscos analisados com os parâmetros pré definidospara classificar a lista de riscos[2].

∙ Tratar Riscos: Processos para desenvolver os planos de tratamento dos riscos,planos de contingência e implementar os processos necessários. Esses processos re-sultam em relatórios de desempenho e lições aprendidas, que armazenam no BDHda organização[2].

33

∙ Monitoramento e Controle: As ações que determinam a eficiência do processode GR. Os dados obtidos resultam em determinados serviços do framework, repre-sentando a evolução das ações do GR[2].

∙ Comunicação e consulta: Reconhecimento dos envolvidos com o projeto e osmeios de comunicação essencial para disseminar as informações[2].

3.0.2 Níveis de Maturidade

Os níveis de maturidade são importante componente do GAIA Riscos, pois deter-minam estágios para evoluir a gestão e também possibilitar às organizações adquirir asatividades envolvidas neste processo. Ao evoluir seu grau de maturidade, uma organizaçãopassa por três estágios[2]:

∙ Imaturidade: Fase em que os processos organizacionais são inválidos.

∙ Maturidade: Período na qual os processos organizacionais são definidos, e começama ser padronizados e controlados.

∙ Excelência: Estágio em que os processos organizacionais são definidos, padroniza-dos e controlados procura da melhoria contínua.

O GAIA Riscos[2], compreende três estágios citados acima e cinco níveis de ma-turidade, os quais apresentam caminhos de melhorias do processo de uma organização.Esses cinco níveis de maturidade são:

∙ Nível 1 - Inicial: Falta de preparo dos envolvidos com o projeto, ou não conhecemo GR[2].

∙ Nível 2 - Conhecido: Executam atividades para gerir riscos do projeto[2].

∙ Nível 3 - Padronizado: Desde o processo de identificação dos riscos, as organiza-ções devem executar atividades para definir os parâmetros do GR e aderir processospara analisar, avaliar e tratar os riscos[2].

∙ Nível 4 - Gerenciado: Monitoramento do GR, para possibilidade de identificarnovos riscos ao longo do desenvolvimento do projeto de software[2].

∙ Nível 5 - Otimizado: Troca de informações entre os envolvidos com o projeto[2].

3.0.3 Questionário de avaliação Diagnóstica

O serviço do Questionário de Avaliação Diagnóstica (QAD) segundo o GAIARiscos[2] é identificar, pelas respostas oferecidas pelo usuário com o grau de maturidade

34

com que o PDS se encontra. As questões são de múltipla escolha e compreendem umconjunto de alternativas categoricamente ocorridas no dia-a-dia das organizações, com oobjetivo de simplificar o preenchimento do questionário pelos usuários[2].

As questões são de múltipla escolha, cada alternativa possui um Fator Multiplica-tivo (FM), a qual quantifica seu impacto em relação à questão que pertence. Estes fatoresauxiliam no cálculo da taxa de atendimento do serviço, conforme a figura 11[2].

Figura 11 – Modelo de Questão do framework GAIA Riscos[2]

35

Outro importante componente do QAD é o relacionamento entre as questões e osserviços do framework GAIA Riscos, qual dado por pesos, na Figura 12

Figura 12 – Peso de questão nos serviços do framework GAIA Riscos[2]

Por meios da ligação entre a Figura 11, podemos verificar que a questão tomadacomo exemplo exerce forte influência sobre os serviços Estabelecer Contexto e IdentificarRiscos, com seus pesos de questões nos serviços conforme o GAIA Riscos [2];

Segundo [2] baseado nas informações obtidas pelo QAD, obtém-se o resultado daavaliação do PDS. Sendo necessário calcular o produto entre o peso da questão no serviçoe o FM(Fator Multiplicado) relacionado a alternativa selecionada, segundo [2]. Tendo apontuação final pela somatória destes produtos de cada serviço.

Para calcular o porcentual de atendimento de cada serviço[2], a pontuação finaldeve ser ajustada com base nos valores que determinam o intervalo entre seu maior(VMax)e o menor(VMin) valor possível[2]. Para calcular VMax multiplica-se o maio FM de cadaquestões pelo pesos em cada um dos serviços. Somando os valores alcançados para cadaserviço obtemos o valor total de VMax[2].

Para calcular o VMin deve-se multiplicar o menor FM de cada questão pelo peso

36

em cada um dos serviços. E somando os valores alcançados para cada serviço para obtero valor total de VMin[2]. Tendo os valores máximos e mínimos possíveis para cada ser-viço, torna-se necessário definir uma Faixa de Pontuação(FP)[2], na qual é obtida peladiferença de VMax e VMin. O resultado final(RF) deve ser ajustado por um Fator deAjuste(FA) que é pela diferença entre 0 e VMin[2]. Tendo esses dados torna possível cal-cular o resultado de avaliação diagnóstica, somando os produtos entre o peso de questão -para cada serviço - e o FM da alternativa selecionada[2]. Para finalizar o calculo da taxade atendimento segundo[2], calcula-se o Resultado Final(RF) do questionário por serviço,divide-se a somatória das respostas com os FA pela FP. Assim uma vez determinado oRF de cada serviço, aquele que obteve o menor porcentual de atendimento irá determinaro grau de maturidade segundo[2]. Tendo o conhecimento para calcular e determinar ograu de maturidade conforme o GAIA Riscos, utilizaremos o GAIA Riscos na aplicaçãode metodologia ágil Scrum.

3.1 Scrum aplicado a Framework GAIA Riscos

Scrum[8] é uma metodologia ágil[18] para gestão de Projetos de Software. Emscrum os projetos são divididos em ciclos (tipicamente mensais) Chamados de Sprints.O Sprint representa um TimeBox entre um conjunto de atividades deve ser executa-das. Metodologias ágeis de desenvolvimento de software são iterativos, sendo divido emiterações, neste caso são chamados de sprints no caso do Scrum[8].

As funções a serem implementadas em um projeto são mantidas em uma lista queé conhecida como Product Backlog. No inicio de cada Sprint, faz-se um Sprint PlannigMeeting, uma reunião de planejamento em que o Product Owner prioriza os elementosdo Product Backlog, e o time seleciona as tarefas que será capaz de implementar duranteo Sprint. Assim o Scrum Master, é encarregado de facilitar, deve ajudar a equipe aresolver os problemas e fazer melhorias no uso do Scrum.

Normalmente no Scrum[19], o time faz uma breve reunião, chamada Daily Scrumcom o objetivo de compartilhar conhecimento sobre o que foi feito no dia anterior e o quesera feito no dia. Ao final de um Sprint, o time apresenta as funcionalidades implementadasem uma Sprint Review Meeting. Finalizando o Sprint, faz-se uma Sprint Retrospec-tive e o time parte para o planejamento do próximo Sprint, reiniciando o ciclo. Conformea Figura 13:

3.1.1 Aplicação Scrum no Framework GAIA Riscos

Para aplicação do framework GAIA Riscos, tem se como objetivo usar o Sprintpara o Gerenciamento de Risco no Projeto de Software. Sabendo-se o funcionamento doScrum, usaremos no Projeto de Software para o Gerenciamento do Projeto, aplicando o

37

Figura 13 – Método Scrum [3]

Scrum[20] no projeto, teremos os Sprints, que são realizados em iterações ou ciclos de atéum mês de calendário.

A cada sprint realizado deve criar algo de valor tangível para o cliente ou o usuário.Os Sprints são timeboxed(duração fixa) com finalidade que tenham sempre um início e fimda data fixa, e geralmente todos tenham a mesma duração conforme a figura 14. Destemodo podemos aplicar o GAIA Riscos para analisar como está encaminhando o projeto,utilizando o Questionário de Avaliação Diagnostica(QAD), para Identificar os Riscos.

38

Figura 14 – Linha de Tempo de um Sprints do Scrum [4]

Na metodologia ágil scrum, durante o processo de priorização do Backlog(Listasmais importantes do projeto) do produto, o Product Owner pode realizar um levantamentode risco relacionado ao projeto, sendo armazenado na lista de riscos.

Como na figura 14, em cada reunião de Planejamento da Sprint, junto com oScrum Master e o Product Owner realizam levantamentos de prováveis riscos relacionadosa execução de cada atividade do projeto, atualizando a lista criada pelo Product Owner,onde o Scrum Master monitora os riscos.

Em Daily Scrum, podem ser removidos da lista de riscos, caso não seja consideradocomo um risco, sendo monitorado pelo Scrum Master.

Quando termina uma Sprint na reunião, inclui o Questionário de Avaliação Di-agnóstica (QAD)[2] que será incluindo nas Sprint Retrospective como na figura 15 assimimplantando o GAIA Riscos[2] e sempre quando termina um Sprint depois da avaliaçãodiagnostica, com os cálculos descrito no capitulo 3, verifica-se o nível de maturidade doprojeto, até então tentando chegar a Otimizado, não afetando o prazo de entrega, nem ocusto do projeto.

39

Figura 15 – Linha de Tempo de um Sprints do Scrum[4] com QAD[2]

40

4 CONCLUSÃO

Analisando a utilização do GP que vem sendo cada vez mais utilizada, principal-mente na área de desenvolvimento de software. Tende-se a planejar um projeto de ummodo eficiente e seguro, assim são escolhidas metodologias ágeis, para o desenvolvimentodo projeto de software. O gerenciamento de riscos é essencial no gerenciamento de pro-jeto, pois é necessário prever os riscos que impedem que alcance os objetivos definidos noprojeto e trata-los.

A conclusão obtida por meio da realização desta pesquisa, e o estudo sobre oFramework GAIA Riscos o qual baseia-se em serviços e níveis de maturidade para facilitara implantação desta gerência. Neste contexto, este trabalho apresenta-se o FrameworkGAIA Riscos, para gerenciar riscos na metodologia ágil Scrum.

Assim aplicado o Framework na teoria no método ágil Scrum, podemos observarque o GAIA Riscos, se sairia muito bem na metologia ágil Scrum, pois cada finalizaçãode sprint geraria um novo resultado final, uma nova pontuação de avaliação diagnostica,sabendo-se se o projeto a cada sprint consegue chegar a nível Otimizado, podendo preveniratrasos e novos orçamentos do projeto.

Como trabalho futuros, pretende-se aplicar o framework GAIA Riscos[2] a Meto-dologias Ágeis, com a aplicação Scrum obtida nesse projeto, com varias equipes para queseja possível mostrar que o framework é adaptável com novas Metodologias Ágeis, parafacilitar o gerenciamento de risco no desenvolvimento de software.

41

REFERÊNCIAS

[1] PMBOK R. Um Guia do Conhecimento em Gestão de Projetos. [S.l.: s.n.], 2017.17 p. ISBN 9781628253900.

[2] FERNANDO Henrique Gaffo Gaia Riscos : Framework Para O Gerenciamento DeRiscos No. 2013.

[3] VIEIRA, D. No Title. 2014. Disponível em: <http://www.mindmaster.com.br/wp-content/uploads/2014/06/Scrum-Process1-630x315.png>.

[4] MINDMASTER. No Title. Disponível em: <http://www.mindmaster.com.br/wp-content/uploads/2014/06/Sprints.png>.

[5] CAMARGO, R. Gerenciamento de projetos: saiba por que vale a penainvestir nesta carreira. Disponível em: <https://robsoncamargo.com.br/blog/Gerenciamento-de-projetos-saiba-por-que-vale-a-pena-investir-nesta-carreira>.

[6] MACEDO, M. H. B.; SALGADO, E. G. Gerenciamento de risco aplicado aodesenvolvimento de software. Sistemas & Gestão, v. 10, n. 1, p. 158–170, 2015.

[7] VARGAS, R. V. Gerenciamento de Projetos (6a edição). [S.l.]: Brasport, 2005.

[8] PEREIRA, P.; TORREÃO, P.; MARÇAL, A. Entendendo Scrum para GerenciarProjetos de Forma Ágil. Mundo PM, p. 1–11, 2007. Disponível em: <http://www.siq.com.br/DOCS/EntendendoScrumparaGerenciarProjetosdeFormaAgil.pdf>.

[9] FRANCO, E. Alternativas para o gerenciamento de projetos de desenvolvimento desoftwares. Dados, 2004.

[10] ENAMI, L. N. M. Ótimo - Um Modelo De Gerenciamento De Projetos Para UmAmbiente De Desenvolvimento Distribuído De Software. p. 217, 2006. Disponívelem: <http://www.din.uem.br/~mestrado/diss/2006/enami.p>.

[11] MORAES, E. A. P. Guia Pmbok Para Gerenciamento. VIII Congresso Nacional deExcelência em Gestão, 2012.

[12] XAVIER, C. M. D. S. Metodologia de Gerenciamento de Proyectos. p. 204, 2012.

[13] MATOS, S.; LOPES, E. Prince2 or PMBOK – A Question of Choice. ProcediaTechnology, Elsevier B.V., v. 9, p. 787–794, 2013. ISSN 22120173. Disponível em:<http://dx.doi.org/10.1016/j.protcy.2013.12.087>.

[14] WINKIPÉDIA. No Title. Disponível em: <https://pt.wikipedia.org/wiki/PRINCE2>.

[15] (AXELOS). Managing Successful Projects With Prince2 - 2017. [s.n.], 2017.v. 6th. 406 p. ISBN 9780113310593. Disponível em: <http://www.amazon.com/Managing-Successful-Projects-Government-Commerce/dp/0113310595/ref=sr\_1\_1?ie=UTF8&s=books&qid=12680>.

42

[16] SANTOS, V. M. D. Prince2: Como funciona a Gestão de Projetos Inglesa?Disponível em: <https://www.fm2s.com.br/prince2-gestao-de-projetos-inglesa/>.

[17] Conforto, Edivandro C.; Amaral, Daniel C.; da Silva, S. L. 9149. Cbgdp, v. 8o

CONGRES, n. 12, 13 E 14 DE SETEMBRO DE 2011, p. 1–12, 2011. ISSN 09265805.

[18] DESENVOLVIMENTOAGIL. No Title. Disponível em: <https://www.desenvolvimentoagil.com.br/scrum/>.

[19] MARÇAL, A. S. C. et al. Estendendo o SCRUM segundo as Áreas de Processo deGerenciamento de Projetos do CMMI. Clei Eletronic Journal, p. 1–12, 2007.

[20] SOARES, M. D. S. Metodologias Ágeis Extreme Programming e Scrum para oDesenvolvimento de Software. Revista Eletrônica de Sistemas de Informação, v. 3,n. 1, 2004. ISSN 1677-3071.