Felipe Rafael Motta Cardoso PDF

Trabalho apresentado para obtenção do título de especialista
em Gestão de Negócios - 2016
Um framework para o gerenciamento de riscos de projetos: estudo aplicado à

projetos de software
Felipe Rafael Motta Cardoso¹; Cassia Renata Pinheiro2

1 Instituto Tecnológico de Aeronáutica - Mestre em Engenharia Eletrônica e Computação - Praça Marechal
Eduardo Gomes, 50 – Vila das Acácias – CEP 12228-901 – São José dos Campos (SP), Brasil
2 PECEGE – Doutora em Ciências - Rua Alexandre Herculano 120, sala T4 – Vila Monteiro – CEP 13418-
445 – Piracicaba (SP), Brasil
1
Um framework para o gerenciamento de riscos de projetos: estudo aplicado à

projetos de software
Resumo
Diante da pluralidade das variáveis que devem ser administradas no contexto

da Gestão de Projetos, a ausência de um instrumento que propicie monitoramento,
controle e uma visão holística das mesmas, pode impactar negativamente na obtenção
do objetivo almejado em determinado projeto. Neste cenário, uma solução que pode
auxiliar na administração desta problemática, é a utilização de um Framework para o
Gerenciamento de Riscos de Projetos para mitigar e não negligenciar elementos que
possam ser danosos ao projeto. Sob a perspectiva de Gestão, tendo como contexto
Projetos de Software, desenvolver sistemas seguros requer a utilização de métodos
que propiciem o gerenciamento de riscos em todo o ciclo de vida do software. Deste
modo, esta pesquisa apresenta um Framework que visa prover, ao Gestor de Projetos,
um mecanismo para identificar e controlar riscos que possam impactar negativamente
nos objetivos do projeto, facilitando a tomada de decisão. O Framework desenvolvido
contempla as Práticas Específicas do Modelo Integrado de Maturidade e de
Capacidade para Desenvolvimento que abordam riscos de projeto de software. Foram
identificados nove processos para representar os elementos contidos no Framework,
que foram descritos funcionalmente segundo a notação Entry criteria, Task definitions,
Validation definitions, eXit criteria [ETVX]. O aspecto temporal da gestão de riscos
utilizou as etapas de desenvolvimento do Processo Unificado. O Framework foi
aplicado a uma unidade organizacional de uma Fábrica de Software no interior de São
Paulo. O uso do Framework fornece conhecimento proativo e uma visão holística dos
riscos para todos stakeholders envolvidos.
Palavras-chave: Gestão de Projetos, Modelo Integrado de Maturidade e de
Capacidade para Desenvolvimento, Engenharia de Software
A framework for project risk management: study applied to software project
Abstract
Given the plurality variables that must be administered in the context of project
management, the absence of an instrument that provides monitoring, control and a
holistic view of them, can negatively impact on achieving the desired objective in a
project. In this scenario, a solution that can help manage this problem is a Framework
for Project Risk Management, to mitigate and not overlook elements that may be
harmful to the project. From the perspective of management within Software Project
context, develop secure systems requires the use of methods, techniques and tools
that provide risk management throughout the software lifecycle. Thus, this monograph
presents a Framework that aims to provide a mechanism to identify and control risks
that may negatively impact on the project objectives, facilitating decision-making. The
Framework developed includes the Specific Practices of the Capability Maturity Model
Integration for Development that address software project risks. Nine processes were
identified to represent the elements contained in the Framework, which have been
described functionally according to Entry criteria, Task definitions, Validation
definitions, eXit criteria [ETVX] notation. The temporal aspect of risk management used
the development stages of the Unified Process. The Framework has been applied to an
organizational unit of a software factory in São Paulo. The Framework provides
proactive use knowledge and a holistic view of the risks to all stakeholders involved.
Keywords: Project Management, Capability Maturity Model Integration for
Development, Software Engineering
2
Introdução
Desde a década de 60, a complexidade essencial dos sistemas de software de

computador aumenta na medida em que as aplicações precisam lidar com um número
crescente de requisitos (Pressmann, 2006) e variáveis críticas. Descrições ambíguas
de requisitos elevam a complexidade acidental no gerenciamento de riscos para o
processo de desenvolvimento de software.
Uma solução que pode auxiliar na administração destas complexidades é a
utilização de um Framework que apoie um Sistema de Informação Gerencial [SIG]
(Laundon e Laundon 2011), com o objetivo de verificar se os pontos que apresentam
risco para o projeto são mitigados.
Em um contexto de controle da qualidade amparada por segurança no
desenvolvimento de software, esta pesquisa visou elaborar um Framework que
propicie ao Gestor de Projetos um instrumento que o auxilie na identificação e controle
de riscos que pudessem impactar negativamente nos objetivos da organização.
A estrutura do Framework será composta por Áreas de Processo “Process
Areas” [PAs] do modelo de qualidade CMMI (CMMI Product Team, 2010). O
desenvolvimento de um Framework que integre elementos que possibilitem a
identificação, monitoramento e gerenciamento de riscos, oriundos de um modelo de
qualidade, facilitam acompanhar pontos críticos do projeto para o tomador de decisão.
Esta pesquisa consiste em projetar e desenvolver um Framework, que propicie
identificar, monitorar e gerenciar riscos de projeto de software, a fim de prover uma
visão holística dos elementos que possam impactar negativamente nos objetivos do
projeto, facilitar a tomada de decisão e apoiar a comunidade de Engenharia de
Software e Gestores de Projetos.
Metodologia
O estudos do Framework foi aplicado a uma unidade organizacional de um

Fábrica de Software no interior de São Paulo. Utilizou-se como modelo de referência o
Modelo Integrado de Maturidade e de Capacidade para o Desenvolvimento [CMMI-
DEV] (CMMI Product Team, 2010). Este modelo foi elaborado pelo Instituto de
Engenharia de Software [SEI] e recebe patrocínio expressivo do “Departament of
defense” [DoD], visto a importância que as atividades de desenvolvimento possuem.
Amplamente utilizado e aceito pela comunidade de Engenharia de Software. Ele
3
auxilia às organizações na melhoria de seus processos por meio de diretrizes de

qualidade.
Do CMMI-DEV foram extraídas as áreas de processos que abordam riscos em
projetos, que foram descritas funcionalmente segundo a notação “Entry criteria, Task
definitions, Validation definitions, eXit criteria” [ETVX] (Radice, 1985). No que concerne
ao aspecto temporal da gestão de riscos foram utilizadas as etapas de
desenvolvimento do Processo Unificado (Booch et al., 2005).
Para a compreensão da metodologia e mineração dos pontos de interesse, a
seguir é apresentada de forma sucinta a descrição dos componentes do Modelo CMMI
(CMMI Product Team, 2010) comumente utilizados nesta pesquisa.
Área de Processo “Process Area” [PA]: Uma Área de Processo é um conjunto
de práticas relacionadas a uma área, que quando implementadas, satisfazem a um
conjunto de objetivos importantes para realizar melhorias significativas naquela área.
Objetivo Específico “Specific Goal” [SG]: Um objetivo específico descreve as
características que devem estar presentes para uma implementação adequada de
uma Área de Processo. Ele é um componente requerido do modelo utilizado nas
avaliações para determinar se uma Área de Processo está implementada.
Prática Específica “Specific Practice” [SP]: A prática específica é a descrição de
uma atividade considerada importante para a satisfação de um objetivo específico
associado. São componentes esperados do modelo que descrevem as atividades
esperadas visando à satisfação dos objetivos específicos de uma Área de Processo.
Subpráticas: Descrições detalhadas que servem de guia para interpretação de práticas
específicas ou genéricas. As PAs do CMMI-DEV são agrupadas em quatro categorias
(Tabela 1).
As Áreas de Processo de Gestão de Projetos, foco desta pesquisa, tratam das
atividades de gestão relacionadas a planejamento, monitoramento e controle de
projeto.
Na Tabela 1 observam-se as Categorias e as PAs do CMMI-DEV. Após um
estudo dos elementos centrais presentes nas 4 (quatro) Categorias descritas pelo
modelo de qualidade de referência utilizado, verificou-se que a Categoria
Gerenciamento de Projetos continha os elementos centrais para compor o Framework
proposto. Esta Categoria contém 6 (seis) PAs. Uma nova mineração nos elementos
presentes em cada PA foi realizada a fim de extrair as funções que abordam os riscos
no desenvolvimento de projetos de software. Desta mineração, 3 (três) PAs foram
utilizadas: Planejamento de Projeto “Project Planning” [PP], Monitoramento e Controle
4
de Projeto “Project Monitoring and Control” [PMC] e Gerenciamento de Riscos “Risk

Management” [RSKM], cujas descrições sucintas são apresentadas a seguir.
Tabela 1. Categorias de Processos do CMMI

Categorias e Áreas de Processos do CMMI-DEV
Categorias Área de Processo
Gerenciamento de Processos -
Gerenciamento Quantitativo de Projeto
Gerenciamento de Riscos
Gerenciamento Integrado de Projeto
Gerenciamento de Projetos Gerenciamento de Acordo com Fornecedores
Monitoramento e Controle de Projetos
Planejamento de Projetos
Gerenciamento de Requisitos
Engenharia -
Suporte -
Fonte: Elaborado pelo autor, com base em CMMI Product Team (2010)
Na PA Planejamento de Projeto os riscos são identificados e analisados. A

análise envolve a determinação do impacto que determinado risco trará ao projeto,
assim como sua probabilidade de ocorrência. Propicia uma visão holística dos pontos
que possam impedir que os objetivos previamente estabelecidos sejam atingidos.
Desta forma, é possível priorizar os riscos cuja ocorrência tenha essa natureza.
Os pontos inerentes à identificação e análise dos riscos do projeto da PA PP
estão presentes no Objetivo Específico 2 “Specific Goal” [SG2] - Elaborar um Plano de
Projeto, em particular na Prática Específica 2.2 “Specific Practice” [SP2.2] - Identificar
e Analisar Riscos do Projeto e em suas subpráticas relacionadas. Os riscos
identificados são analisados para apoiar o planejamento do projeto.
Na PA Monitoramento e Controle de Projeto os riscos previamente identificados
são monitorados. Periodicamente a documentação de riscos é revisada no contexto do
status do projeto. Caso alguma informação adicional seja verificada, a mesma é
incorporada ao documento e passa a ser monitorada. O status de risco de projeto é
informado aos stakeholders. Um risco quando identificado e monitorado, pode ter sua
probabilidade e prioridade alteradas durante o ciclo de vida do projeto.
Os pontos inerentes ao monitoramento e controle dos riscos do projeto da PA
PMC estão presentes no Objetivo Específico 1 “Specific Goal” [SG1] - Monitorar o
Projeto em Relação ao Plano, em particular na Prática Específica 1.3 “Specific
Practice” - 1.3 e em suas subpráticas relacionadas.
A PA Gerenciamento de Riscos visa à identificação de potenciais problemas
antes que os mesmos ocorram, de forma que as atividades de gerenciar riscos
5
possam ser planejadas e realizadas quando necessárias ao longo do ciclo de vida do

produto ou projeto, para mitigar impactos adversos nos objetivos.
O Gerenciamento de Riscos é contínuo e pró-ativo. Para tal, as fontes e
dimensões de riscos são determinadas, bem como os parâmetros que as envolvem.
Com estes dados, uma estratégia de gerenciamento de riscos é estabelecida.
As PAs PP e PMC tratam o gerenciamento de riscos de forma reativa e focam
a identificação dos riscos para a conscientização. A PA RSKM por sua vez, é munida
de recursos que propiciam ao Gestor de Projetos a identificação de riscos de maneira
contínua e pró-ativa. Para tal, as fontes e categorias de riscos são determinadas, bem
como os parâmetros que as envolvem. Com estes dados, uma estratégia de
gerenciamento de riscos é estabelecida.
O Framework proposto facilita acompanhar pontos críticos do projeto e atua
como parte integrante de um Sistema de Informação Gerencial [SIG]. Propicia apoio à
decisão do gerenciamento de riscos e suporta o processo de triagem de problemas, a
fim de diminuir os defeitos residuais inerentes às atividades de construção de
software.
Para facilitar a identificação do contexto desta pesquisa, a Figura 1 ilustra a
redução de escopo do CMMI-DEV para o Framework proposto. Nela é possível
visualizar a estratégia de obtenção do Framework, com destaque para as SPs
utilizadas.
Foram identificados 9 processos que integram o Framework. O Processo 1
tratou o risco no Planejamento de Projeto, Nível 2 [N2] do CMMI-DEV. Concentrou em
aspectos inerentes a concepção do projeto, com base no background e know-how
presente na literatura e/ou na organização.
O Processo 2 tratou do Monitoramento e Controle, Nível 2 [N2] do CMMI-DEV.
Os Processos 3, 4 e 5 relacionaram-se com a Preparação da Gestão de
Riscos, Nível 3 [N3] do CMMI-DEV. Neste estágio verificações foram efetuadas, a fim
de documentar e monitorar possíveis alterações tanto no risco (inclusão, remoção),
quanto em seu status (impacto, probabilidade de ocorrência, fator de exposição e
priorização).
Os Processos 6 e 7 propiciaram a Identificação e Análise de Riscos, Nível 3
[N3] do CMMI-DEV. O foco concentrou-se em aspectos relacionados ao projeto em
produção, às atividades em desenvolvimento, cuja base foram os processos
previamente analisados. Estes processos propiciaram a inserção de elementos que
6
poderiam impactar nos objetivos do projeto, para que os mesmos possam ser
gerenciados de forma proativa.
Figura 1. Redução de escopo do CMMI para o Framework proposto

Fonte: Elaborado pelo autor, com base em CMMI Product Team (2010)
Os Processos 8 e 9 trataram da Mitigação de Riscos, Nível 3 [N3] do CMMI-

DEV. De posse de todos os processos anteriormente efetuados, foram elaborados e
implementados Planos de Mitigação de Riscos.
Cada um dos 9 processos apresentados foi descrito segundo a notação ETVX
conforme Radice (1985).
O produto intermediário gerado pela saída de cada processo resultou em
fragmentos de um Framework. O somatório destes fragmentos propiciou a composição
final do Framework que contempla a Gestão de Riscos.
A Tabela 2 exemplifica os elementos inerentes ao Processo 1, cujo conteúdo é
parte integrante do Framework. Contempla os elementos citados pelo CMMI-DEV e
sua estrutura segue a taxonomia de Schmidt et al. (2011).
7
Tabela 2. Exemplo de um fragmento do Framework inerente ao Processo 1

Risco Probabilidade Impacto
Fonte: Dados originais da pesquisa
As definições para a escala de probabilidade e impacto agregadas à taxonomia

de risco selecionada seguem os níveis descritos pelo “Project Management Body of
Knowledge” [PMBoK] (PMI, 2008).
O monitoramento dos riscos propicia visibilidade do progresso do projeto, de
forma que ações corretivas possam ser implementadas quando o projeto desviar do
plano (CMMI Product Team, 2010). A Tabela 3 ilustra um exemplo do Framework
inerente ao Processo 2.

Identificador Probabilidade Impacto Probabilidade Impacto
Observações
do Riscos Inicial Inicial Atual Atual
Os parâmetros para riscos fornecem critérios para comparação dos vários

riscos a serem gerenciados. A Tabela 4 apresenta os níveis de probabilidade e
impacto utilizados nesta pesquisa. Os níveis apresentados seguem a classificação do
PMBoK (PMI, 2008).
Tabela 4. Níveis de Probabilidade e Impacto dos Riscos nos Objetivos do Projeto

Nível Probabilidade de Ocorrência (%) Impacto (%)
Muito Baixo (MB) 10% 5%
Baixo (B) 30% 10%
Moderado (M) 50% 20%
Alto (A) 70% 40%
Muito Alto (MA) 90% 80%
Fonte: Elaborado pelo autor com base em PMI (2008)
O nível de impacto e probabilidade foi definido pelos especialistas para cada

risco identificado no Planejamento de Projeto, seguindo a classificação apresentada
na Tabela 4. Os parâmetros atribuídos são a base para a análise qualitativa a
posteriori e estruturam o julgamento no que concerne aos riscos do projeto.
8
A análise qualitativa estabelece os riscos prioritários, obtidos pela análise da

magnitude do impacto e da probabilidade de ocorrência (PMI, 2008).
Os riscos são priorizados de acordo com as suas potenciais implicações nos
objetivos do projeto. Utilizou-se uma matriz de probabilidade e impacto como
abordagem para priorização de riscos (Tabela 5). A organização deve determinar,
fundamentadas em experiência do staff e outros critérios que podem ser próprios,
quais combinações de probabilidade e impacto resultam na classificação de alto risco
(≥ 0.18), risco moderado (0.06 ≤ risco moderado ≤ 0.14) ou risco baixo (≤ 0.05).
Tabela 5. Matriz de Probabilidade e Impacto

Nível de Impacto
Probabilidade de
Muito Baixo Moderado Alto Muito Alto
ocorrência
Baixo (5%) (10%) (20%) (40%) (80%)
Muito Alta (90%) 0.05 0.09 0.18 0.36 0.72
Alta (70%) 0.04 0.07 0.14 0.28 0.56
Moderada (50%) 0.03 0.05 0.1 0.2 0.4
Baixa (30%) 0.02 0.03 0.06 0.12 0.24
Muito Baixa (10%) 0.01 0.01 0.02 0.04 0.08
Fonte: PMI (2008)
As Tabela 4 e Tabela 5 apresentaram os Níveis de Probabilidade e Impacto

dos Riscos nos Objetivos do Projeto e a Matriz de Probabilidade e Impacto.
As referidas tabelas são parte integrante do Framework e propiciam: a) avaliar
um determinado risco, no qual o analista atribui de um nível de impacto causado pelo
risco e pela sua probabilidade de ocorrência; b) classificar um risco envolve defini-lo
como alto, baixo ou moderado; e c) priorizar um risco, em virtude da classificação
obtida por uma matriz de probabilidade e impacto.
A Tabela 6 ilustra um fragmento do Framework inerente ao Processo 6. Os
seguintes agentes compõem a referida Tabela: 6.1) Identificador do Riscos; 6.2) Risco;
6.3) Dimensão do Risco; 6.4) Fonte/Natureza do Risco; 6.5) Probabilidade de
Ocorrência; 6.6) Impacto; 6.7) Fator de Exposição; 6.8) Equipe Responsável; e
Observações. Contempla os elementos citados pelo modelo de qualidade de
referência utilizado.

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9
9
O Processo 7 avalia, dimensiona e prioriza os riscos. A Tabela 7 apresenta um

fragmento do Framework do referido Processo. Os seguintes agentes compõem a
referida Tabela: 7.1) Identificador do Riscos; 7.2) Risco; 7.3) Descrição do Riscos; 7.4)
Dimensão; 7.5) Fonte do Risco; 7.6) Probabilidade; 7.7) Impacto; e 7.8) Fator de
Exposição.

7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8
Os planos para mitigação dos riscos são elaborados para reduzir o impacto
potencial de ocorrência dos riscos mais relevantes para o projeto. Os riscos são
monitorados com base em seus parâmetros.
Os planos de mitigação de riscos e de contingência (caso os riscos ocorram)
são frequentemente gerados somente para riscos selecionados, onde as
consequências dos riscos são definidas como altas. Outros riscos podem ser aceitos e
monitorados.
Munido dos riscos prioritários do projeto, desenvolveu-se mecanismos para
monitorá-los e controlá-los. Avaliaram-se os riscos cuja ocorrência impacta
negativamente nos objetivos do projeto a fim de definir a execução de um plano de
mitigação ou contingência.
Para cada risco selecionado, a organização efetua uma análise de alternativas,
que propicia evitá-lo, o seu controle ou mitigação, transferi-lo, monitorá-lo ou aceitá-lo.
Tais opções bem como suas descrições são apresentadas na Tabela 8.
Tabela 8. Opções de Tratamento de Riscos

Opção de Tratamento Descrição
Evitar o risco implica em mudar ou diminuir requisitos,
Evitar o risco
mantendo o atendimento às necessidades do usuário.
A mitigação de riscos exige a redução da probabilidade
Controlar ou mitigar o
e/ou impacto de um evento de risco adverso até um limite
risco
aceitável. Executar ações para minimizar os riscos.
Exige a passagem do impacto negativo de uma ameaça
Transferir o risco
para terceiros, juntamente com a propriedade da resposta.
Observar e periodicamente reavaliar os riscos com relação
Monitorar o risco
a mudanças nos parâmetros de riscos atribuídos.
Aceitar o risco Reconhecer o risco, mas não tomar nenhuma ação.
Fonte: Elaborado pelo autor com base em CMMI Product Team (2010)
10
O Processo 9 - Implementar Planos de Mitigação de Riscos, monitora

periodicamente o status de cada risco e executa o plano de mitigação quando
apropriado.
A Tabela 9 ilustra o exemplo de um fragmento do Framework inerente ao
Processo 9. Apresenta o status atual do risco (probabilidade, impacto, fator de
exposição) e o progresso das ações escolhidas para mitigação. Os seguintes agentes
compõem a referida Tabela: 9.1) Identificador do Riscos; 9.2) Probabilidade Inicial;
9.3) Impacto Inicial; 9.4) Fator de Exposição Inicial; 9.5) Probabilidade Atual; 9.6)
Impacto Atual; 9.7) Fator de Exposição Atual; 9.8) Progresso; e 9.9) Observações.

9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9
De maneira simplificada foi apresentada a descrição funcional do Framework

proposto que encapsulou os 9 (nove) processos previamente explicitados.
Uma arquitetura simplificada dos recursos principais utilizados na
implementação dos processos contidos no Framework é apresentada na Figura 2. A
implementação almejou propiciar um ambiente que reunisse todos os elementos
presentes nas Tabelas 2 a 9 de maneira dinâmica. Visou utilizar recursos de
Tecnologia da Informação para que os processos contidos no Framework estivessem
de fácil acesso para a organização na qual o Gerenciamento de Riscos de Projeto de
Software fosse efetuado.
Ao final, como produto do mapeamento do Framework e sua implementação
em um ambiente Web, produziu-se uma ferramenta de apoio a Gestão de Riscos,
intitulada “Risk Management Environment” [RIMAE]
Figura 2. Arquitetura simplificada das tecnologias utilizadas no RIMAE

11
A ferramenta RIMAE, foi concebida para encapsular os elementos presentes no

Framework, tendo em vista os aspectos relacionados à consulta, armazenamento e
principalmente interface com a organização.
A estratégia objetivou prover ao Gestor de Projetos um mecanismo de fácil
visualização do status do projeto. O foco concentrou-se em prover uma visão holística
do estudo, a fim de contemplar as dimensões de risco (Ambiente corporativo;
Patrocinador/ proprietário do projeto; Gestão de relacionamento; Gestão de projetos;
Escopo; Requisitos; Financiamento; Cronograma; Processo de desenvolvimento;
Pessoal; Pessoal de apoio; Tecnologia; Dependência externa; e Planejamento) e dos
elementos que as circundam.
O ambiente desenvolvido concentrou todos os elementos oriundos da
operacionalização dos 9 (nove) processos descritos anteriormente (Figura 3). A seguir
é apresentada uma descrição dos mesmos:
(1) Visão simplificada dos principais elementos contidos no Framework elaborado.
Relacionou-se com o Processo 5 presente no Framework;
(2) Nome do Projeto analisado;
(3) Categoria do CMMI-DEV;
(4) Identificador do Risco. Cada Risco identificado recebeu um identificador, que foi
composto pela Dimensão ao qual o risco pertence e pela sequência que o mesmo se
encontra listado. Facilitou a localização do risco e da Dimensão que o mesmo
pertence no processo de rastreabilidade. Relacionou-se com os Processos 1 e 6
presentes no Framework;
(5) Risco. Contém os riscos inerentes ao projeto de software avaliado. Relacionou-se
com os Processos 1 e 6 presentes no Framework;
(6) Identificador da Dimensão. Cada Dimensão identificada recebeu um identificador.
Facilitou a localização da Dimensão que um dado Risco pertence no processo de
rastreabilidade. Relacionou-se com os Processos 3 e 7 presentes no Framework;
(7) Dimensão do Risco. Contém as Dimensões inerentes ao projeto de software
avaliado. Relacionou-se com os Processos 3 e 7 presentes no Framework;
(8) Fonte do Risco: Contém os principais causadores de riscos no projeto de software.
Áreas comuns de origem dos riscos. Relacionou-se com os Processos 3 e 7 presentes
no Framework;
(9) Descrição / Detalhamento da Fonte do Risco: Orientação sucinta relacionada às
características nativas da Fonte do Risco previamente identificada. Relacionou-se com
os Processos 3 e 7 presentes no Framework;
12
(10) Etapa de Desenvolvimento: Aspecto temporal no qual a Gestão de Riscos atuou

no contexto da produção do software. Relacionou-se com o Processo 2 presente no
Framework;
(11) Probabilidade de Ocorrência do Risco: Chance de um evento do risco ocorrer. O
stakeholder definiu para cada risco identificado sua probabilidade de ocorrência no
contexto do cenário em estudo. Base para a análise qualitativa a ser efetuada a
posteriori. Relacionou-se com os Processos 1 e 4 presentes no Framework;
(12) Impacto do Risco: Efeito potencial de um risco sobre o objetivo do projeto. O
stakeholder definiu para cada risco identificado seu impacto no contexto do cenário em
estudo. Base para a análise qualitativa a ser efetuada a posteriori. Relacionou-se com
os Processos 1 e 4 presentes no Framework;
(13) Fator de Exposição: Oriundo da combinação da Probabilidade de ocorrência de
um dado Risco e de seu Impacto para o projeto. Insumo para análises de priorização.
Relacionou-se com os Processo 4 presente no Framework;
(14) Prioridade do Risco: Munidos dos dados de probabilidade, impacto e fator de
exposição foi definido se o Risco em análise tratou-se de um Risco Prioritário ou Não
prioritário no contexto do cenário em estudo. Relacionou-se com o Processo 4
presente no Framework;
(15) Opções de Tratamento: Para cada Risco identificado e munido das informações
obtidas pelas análises, foram definidas Opções de Tratamento. Relacionou-se com os
Processos 8 e 9 presente no Framework;
(16) Descrição da Opção de Tratamento: Orientação sucinta relacionada às
características da Opção de Tratamento escolhida. Relacionou-se com os Processos 8
e 9 presente no Framework;
(17) Plano de Mitigação: Ações que visaram reduzir o nível do fator de exposição dos
riscos prioritários para o projeto. Relacionou-se com os Processos 8 e 9 presente no
Framework;
(18) Pessoa ou Equipe Responsável: Para cada risco presente no projeto, identificou-
se uma pessoa ou equipe responsável da organização para acompanhar os aspectos
relacionados à este elemento. Relacionou-se com os Processos 8 e 9 presente no
Framework;
(19) Plano de Contingência: Apresentaram as medidas a serem tomadas na
ocorrência de um Risco Prioritário. Relacionou-se com os Processos 8 e 9 presente no
Framework;
13
(20) Status: Propiciou verificar o status de um risco para o projeto. Relacionou-se com
o Processo 2 presente no Framework; e
(21) Observações: Campo para inserir qualquer informação referente à análise
realizada.
O experimento realizado envolveu a aplicação dos 9 (nove) processos
encapsulados no Framework proposto, a fim de aferir pontos que poderiam impactar
negativamente nos objetivos do projeto e suportar a Gestão de Riscos no
desenvolvimento do software. Os processos do Framework apoiaram a construção dos
elementos principais que compõe a Gestão de Riscos deste trabalho de pesquisa. A
união dos dados oriundos do output dos processos, advindos de suas
operacionalizações, está inserida no contexto semântico. Este por sua vez
caracterizou-se como um dos componentes do conhecimento que tem a função de
representar o significado.
A operacionalização dos processos propiciou a coleta dos dados.
A Figura 3 ilustra o exemplo de 1 (um) risco armazenado na base de dados.
Possibilitou verificar todo o cenário que circunda o Risco analisado. Inicialmente
identificou o Risco e a Dimensão (Anexo 1) do mesmo. De posse desta informação foi
verificado sua origem e apresentada sua descrição tendo em vista o objeto em estudo.
A equipe técnica estipulou as etapas de desenvolvimento (Anexo 2) no qual o
risco identificado poderia afetar negativamente o progresso das atividades.
O staff da organização definiu a probabilidade de ocorrência do risco e o
impacto que o mesmo ocasionaria ao projeto. O produto da probabilidade e do impacto
propiciou a informação relacionada ao Fator de Exposição, insumo para a definição da
prioridade associada ao risco. De posse das informações obtidas, a equipe analisou e
escolheu por uma opção de tratamento. Para fins de documentação uma descrição da
opção escolhida foi apresentada. Assim como as etapas de desenvolvimento foram
previamente definidas, dados ligados à equipe responsável por responder aos
aspectos inerentes ao risco avaliado foram agregados.
O exemplo apresentado na Figura 3 trata-se de um risco que se enquadrou em
uma região da matriz de probabilidade e impacto relacionada a um Risco Alto, desta
forma ações de mitigação e contingência foram estipuladas.
Por fim a equipe de projetos inseriu observações relacionadas ao processo
realizado. Campo dedicado para descrever qualquer particularidade referente ao
estudo efetuado.
14
Trabalho apresentado para obtenção do título de especialista em Gestão de Negócios - 2016
Figura 3. Cenário referente a 1 (um) risco avaliado

15
Resultados e Discussão
O Framework foi aplicado a uma unidade organizacional de uma Fábrica de

Software no interior de São Paulo.
A aplicação do Framework foi satisfatória e proveu aos stakeholders uma visão
holística dos riscos nos quais o projeto estaria exposto.
Os resultados obtidos pela aplicação do Framework propiciaram a Gestor de
Projetos uma consciência situacional do objeto a ser gerenciado no contexto de Riscos
de Projeto de Software.
Verificou-se que todos os elementos identificados, após a execução das ações
de mitigação, estariam encapsulados em uma faixa considerada aceitável pela
organização.
Os dados coletados propiciaram ao Gestor de Projetos suporte para tomada de
decisão no que concerne à premissa da necessidade de conhecer os riscos inerentes
ao objeto em desenvolvimento.
Foram identificados 34 Riscos, encapsulados nas Dimensões: Ambiente
Corporativo; Relação com o Patrocinador; Gerenciamento das Relações;
Gerenciamento de Projeto; Escopo; Requisitos; Financiamento; Cronograma;
Processo de Desenvolvimento; Integrantes da Equipe; Equipe; Tecnologia;
Dependências Externas; e Planejamento. Tais dados encontram-se no Apêndice 1.
A combinação da probabilidade e do impacto de cada risco possibilitou a
análise qualitativa e suas classificações: Risco Alto, Risco Moderado e Risco Baixo
(Apêndice 2).
Dentre os resultados obtidos com a operacionalização do Framework, destaca-
se a visualização dos pontos que poderiam impactar negativamente nos objetivos do
projeto, das dimensões que os mesmos pertencem, e de suas classificações (
).
16
3 Risco Alto
2,5 Risco Moderado
2 Risco Baixo
1,5
1
0,5
0
Figura 4. Classificação dos riscos associado às dimensões do projeto avaliado

(primeira análise)
Fonte: Resultados originais da pesquisa
A análise qualitativa efetuada possibilitou estabelecer os riscos prioritários para

o projeto e os seus respectivos Planos de Mitigação (Apêndice 3). Estes visaram de
modo proativo reduzir o impacto potencial da ocorrência dos riscos para um nível
considerado aceitável pela organização. A Figura 5 ilustra os riscos identificados, suas
dimensões e classificações após a intervenção da equipe de desenvolvimento.
17
4 Risco Alto
3,5 Risco Moderado
3
Risco Baixo
2,5
2
1,5
1
0,5
0
Figura 5. Classificação dos riscos associado às dimensões do projeto avaliado (após

ações de mitigação)
A Figura 6 possibilita visualizar os riscos identificados, suas respectivas
classificações e as etapas nativas de desenvolvimento.
12 Risco Alto
10 Risco Moderado
Risco Baixo
8
6
4
2
0
Figura 6. Classificação dos riscos associado às etapas desenvolvimento do projeto

avaliado.
18
A Figura 6 propiciou ao Gestor de Projetos uma visão holística e temporal das

etapas de desenvolvimento que poderiam ser afetadas negativamente pelos riscos,
insumo para o planejamento e tomada de decisão pontual. Verificou-se que a maior
parte dos riscos concentrou-se na Gerência de Projeto, Modelagem de Negócio,
Requisitos, Gerência de Configuração e Teste respectivamente.
Dentre as principais vantagens que a utilização do Framework propiciou,
ressaltam-se: o uso de diretrizes de qualidade consolidadas e aceitas pela
comunidade de Engenharia de Software, oriundas do CMMI-DEV, como passo inicial
para a concepção de uma possível solução no suporte à Gestão de Riscos de Projetos
de Software; o acesso aos elementos que guiam o Gestor de Projetos na identificação
e controle dos riscos que possam afetar negativamente o desenvolvimento de
Software em um único ambiente, o Framework; a disseminação transparente dos
riscos observados na Gestão de Riscos a todos os stakeholders envolvidos; o
conhecimento proativo dos riscos, insumo para a tomada de decisão no contexto de
atenuar efeitos adversos e retrabalhos em atividades futuras do desenvolvimento; o
aprendizado com a implantação do Framework e a catalogação de ações que visaram
diminuir a probabilidade de ocorrência dos riscos identificados para o projeto; e, uma
base de dados oriunda das experiências obtidas para que as mesmas possam ser
reaplicáveis e aprimoradas em projetos futuros.
Conclusão
Esta pesquisa teve como principal objetivo conceber e desenvolver um

Framework para o Gerenciamento de Riscos de Projeto de Software, visando prover
ao Gestor de Projetos um mecanismo para identificar e controlar riscos que possam
impactar negativamente nos objetivos previamente estabelecidos, facilitar a tomada de
decisão e apoiar a comunidade de Engenharia de Software.
O A aplicação do Framework mostrou-se satisfatória e propiciou à organização
no qual o Estudo de Caso foi elaborado um instrumento de suporte à Gestão de
Riscos de Projeto de Software. Conduziu a equipe na preparação de respostas que
visou anular ou atenuar os efeitos adversos advindos de sua ocorrência e possui
potencial para ser aplicado em outros projetos da mesma organização ou em projetos
de organizações distintas, cuja atividade principal esteja relacionada com o
desenvolvimento de software.
19
Agradecimentos
Aos meus pais que abdicaram de muitas realizações pessoais em benefício de

seus filhos; Ao PECEGE por propiciar um canal de aprimoramento acessível e de
extrema importância profissional; À Professora Cássia Pinheiro pela orientação; e à
turma GN151 pela parceria e cooperação nos estudos.
Referências
Booch, G.; Rumbaugh, J.; Jacobson, I. 2005. The unified modeling language user
guide. 2ed. Reading: Addison Wesley.
CMMI Product Team. 2010. CMMI for development: version 1.3. Carnegie Mellon
University, Pittsburgh, PA, USA.
Laundon, K. C.; Laundon, J. P. 2011. Sistemas de informação gerenciais. 9ed.

Pearson Education, São Paulo, SP, Brasil.
Pressmann, R. S. 2006. Engenharia de software. 6ed. McGrawHill, New York, NY,

USA.
Project Management Institute [PMI]. 2008. A guide to the Project Management Body of
Knowledge. 4ed. Project Management Institute, Philadelphia, PA, USA.
Radice, R., A. 1985. Programming process architecture. IBM Systems Journal, 24(2).
Schmidt, R. et al. 2001. Identifying software project risks: an international Delphi study.
Journal of Management Information Systems 17 (4): 5-36.
Shuja, A.; Krebs, J. 2008. IBM rational unified process reference and certification
guide: solution designer. Pearson Prentice Hall, New Jersey, NJ, USA.
Anexos
Anexo 1. Dimensões e Fontes de Riscos (continua)

Identificador Fonte do Risco, Detalhamento da Fonte do
Dimensão do Risco
Dimensão Risco
Ambiente: Mudanças no negócio (ambiente
Ambiente político) ou fraco alinhamento do sistema com
D1
corporativo a cultura organizacional.
Relação com o Comando: Falta de comando do gerente de

patrocinador / projeto para executar o plano de projeto. Falta
D2
proprietário do de confiança com os proprietários do sistema.
sistema
20
Relacionamento com os Usuários: Falta de

confiança e envolvimento inadequado do
Gerenciamento das usuário. Papéis e expectativas não claras
D3
Relações entre os usuários ou outras partes
interessadas.
Gestão: Má gestão da estratégia e execução

Gerenciamento de
D4 do projeto.
Projeto
Escopo do Sistema: Compreensão parcial do
escopo ou missão do sistema. Descrição vaga,
D5 Escopo
não clara, ambígua.
Requisitos: Gestão inadequada de requisitos

D6 Requisitos do sistema. Validação fraca, ineficiente.
Gerenciamento de Recursos: Orçamento

pequeno ou estimado de forma incorreta para
D7 Financiamento
o desenvolvimento de software.
Controle de Recursos: Má gestão do consumo

de recursos e necessidades. Prazos e tempos
D8 Cronograma
de tarefas mal estimados.
Anexo 1. Dimensões e Fontes de Riscos (conclusão)
Identificador Fonte do Riscos, Detalhamento da Fonte do

Dimensão do Riscos
Dimensão Risco
Habilidades: Habilidades de integrantes da
Integrantes da equipe inadequadas para o desenvolvimento e
D10
Equipe gerenciamento de processo.
Equipe: Mudanças de integrantes da equipe

ou nos cargos que ocupam. Indisponibilidade
D11 Equipe de pessoas para desempenhar determinada
função.
Tecnologia: Compreensão inadequada da

D12 Tecnologia tecnologia escolhida.
Ambiente de Desenvolvimento: Má gestão ou

Dependências controle sobre as dependências com agentes
D13
Externas externos.
Planejamento: Falta de interesse ou

D14 Planejamento habilidades inadequadas para planejar o
projeto.
Fonte: Elaborado pelo autor com base em Schmidt et al. (2001)
21
Anexo 2. Etapas de desenvolvimento de software e descrição de suas finalidades

(continua)
Etapa Finalidades
 Entender a estrutura e a dinâmica da organização na qual o
sistema deve ser implantado (a organização-alvo);
 Entender os problemas da organização-alvo e identificar
1. Modelagem de melhorias;
Negócios  Assegurar que os clientes, usuários e desenvolvedores tenham
um entendimento comum da organização-alvo; e
 Derivar os requisitos de sistema necessários para sustentar a
organização-alvo.
 Estabelecer e manter concordância com os clientes e outros
envolvidos sobre o que o sistema deve propiciar;
 Oferecer aos desenvolvedores do sistema uma compreensão
dos requisitos do sistema;
 Definir as fronteiras do sistema (ou delimitar o sistema);
 Fornecer uma base para planejar o conteúdo técnico das
2. Requisitos
iterações;
 Fornecer uma base para estimar o custo e o tempo de
desenvolvimento do sistema; e
 Definir uma interface de usuário para o sistema, focando nas
necessidades e metas dos usuários.
Anexo 2. Etapas de desenvolvimento de software e descrição de suas finalidades

(conclusão)
Etapa Finalidades
 Transformar os requisitos em um design do sistema a ser
criado;
3. Análise e
 Desenvolver uma arquitetura para o sistema; e
Design
 Adaptar o design para que corresponda ao ambiente de
implementação, projetando-o para fins de desempenho.
 Definir a organização do código em termos de subsistemas de
implementação organizados em camadas;
 Implementar classes e objetos em termos de componentes
4. Implementação (arquivos-fonte, binários, executáveis e outros); e
 Testar os componentes desenvolvidos como unidades e
integrar os resultados produzidos por desenvolvedores
individuais (ou equipes) ao sistema executável.
 Localizar e documentar defeitos na qualidade do software;
 Avisar de forma geral sobre a qualidade observada no software;
 Validar as suposições feitas nas especificações de design e
5. Teste requisito através de demonstração concreta;
 Validar as funções do software conforme projetadas; e
 Verificar se os requisitos foram implementados de forma
adequada.
 Descreve as atividades que garantem que o produto de
6. Implantação
software será disponibilizado a seus usuários finais.
7. Gerenciamento  O controle ajuda a evitar confusões dispendiosas e garante que
22
de os artefatos resultantes não entrem em conflito devido a algum

Configuração e dos seguintes problemas:
Mudança  Atualização Simultânea, Notificação Limitada e Várias Versões.
 Fornecer um framework para gerenciar projetos intensivos de
software;
 Fornecer diretrizes para planejar, montar a equipe, executar e
8. Gerenciamento monitorar os projetos;
de Projeto  Fornecer um framework de gerenciamento de risco;
 Planejamento de um projeto iterativo, por meio do ciclo de vida
e de uma iteração; e
 Monitoramento do progresso de um projeto iterativo.
 Descreve as atividades para o desenvolvimento das diretrizes
de suporte de um projeto. A meta das atividades desta etapa é
9. Ambiente
oferecer à organização o ambiente de desenvolvimento de
software, processos e ferramentas, que propiciará suporte à
equipe de desenvolvimento.
Fonte: Elaborado pelo autor com base em Shuja e Krebs (2008)
23
Apêndice
Apêndice 1. Dados oriundos da operacionalização Framework (1/3) (continua)

Etapa de Desenvolvimento
Gerência de Projeto
Dimensão do Risco
Análise e Projeto
Implementação
Modelagem de
Configuração
Gerência de
Implantação
Ambiente
Requisito
Negócio
Id Risco
Teste
Risco
Um clima de mudança no ambiente empresarial e organizacional que cria instabilidade no

1.1 D1 X X
projeto.
2.1 Incompatibilidade entre a cultura corporativa e as mudanças exigidas pelo novo sistema. D1 X X
Ambiente corporativo instável: As pressões competitivas alteram radicalmente os requisitos do

3.1 D1 X
stakeholder.
Mudança de propriedade ou gerência sênior: Novos proprietários e / ou gerentes definem novas
4.1 direções para os negócios, que provoca descompasso entre as necessidades empresariais e D1 X
os objetivos do projeto.
Falta de comprometimento da alta direção com o projeto. Isto inclui a supervisão de executivos
1.2 e visibilidade de seu compromisso, comprometendo recursos necessários, mudar as políticas D2 X
conforme necessário.
Conflito entre departamentos do stakeholder: diferenças graves em metas de projeto, produtos,

2.2 D2 X
design, etc, põe em questão conceito de propriedade compartilhada.
Falha em obter a aprovação do plano do projeto de todas as partes (cliente, partes

3.2 D2 X
interessadas, partes interessadas relevantes).
24
Apêndice 1. Dados oriundos da operacionalização Framework (continuação)

Implementação
Configuração
Dimensão do
Gerência de
Gerência de
Implantação
Modelagem
de Negócio
Ambiente
Requisito
Análise e
Id Risco
Projeto
Projeto
Risco
Teste
Risco
Incapacidade de gerir expectativas do cliente: Podem determinar o sucesso ou fracasso

1.3 D3 X X
do projeto.
Falta de cooperação dos clientes: os clientes se recusam a fornecer os requisitos e / ou
2.3 D3 X X X
recusar a fazer teste de aceitação.
3.3 Incapacidade de identificar todos os stakeholders. D3 X X
Gerenciar múltiplas relações com os stakeholders: Alguns "clientes" também são
4.3 "parceiros" na produção de resultados em outros projetos. Leva à confusão de papéis e D3 X X
responsabilidades.
Gerenciamento inadequado de mudanças: Cada projeto necessita de um processo
1.4 D4 X
para gerir a mudança, de forma de que o escopo e orçamento sejam controlados.
2.4 Falta de uma metodologia efetiva para o gerenciamento de projetos. D4 X

Definição inadequada de papéis e responsabilidades: Indefinição dos membros da
3.4 equipe quanto aos seus papéis e responsabilidades. Isto inclui empresas de D4 X X
terceirização e consultores.
Controle deficiente ou inexistente: Nenhuma metodologia de acompanhamento de
4.4 D4 X
projetos.
5.4 Má gestão do risco: Combater os riscos errados. D4 X X
1.5 Escopo ou objetivos pouco claros ou mal interpretados. D5 X X

2.5 Mudança de escopo/objetivos. D5 X X X X
1.6 Constantes mudanças nos requisitos. D6 X X X X
2.6 Requisitos mal interpretados e/ou mal definidos no início do desenvolvimento. D6 X X X X

3.6 Assunto novo ou não familiar para os stakeholders. D6 X X X X
1.7 Custos mal estimados. D7 X
25
Apêndice 1. Dados oriundos da operacionalização do Framework (conclusão)

Análise e Projeto
Implementação
Modelagem de
Configuração
Dimensão do
Gerência de
Gerência de
Implantação
Ambiente
Requisito
Negócio
Id Risco
Projeto
Risco
Teste
Risco
1.8 Prazos e tempos de execução de tarefas mal estimados. D8 X

Falta de metodologia ou processo efetivo de desenvolvimento: levando a problemas
1.9 D9 X
de documentação, de qualidade, testes.
Falta de conhecimento necessário / competências no pessoal do projeto: por
1.10 D10 X
exemplo, tecnologia, conhecimento do negócio, e experiência.
Falta de "habilidades pessoais" na liderança do projeto: Gestor tenta "gerenciar"
2.10 horários, tecnologia, requisitos, etc, ignorando que a administração está lidando com D10 X
pessoas da equipe.
1.11 Pessoal envolvido insuficiente / inadequado. D11 X
Volatilidade de pessoal: Em algum ponto do projeto, perdendo o gerente de projeto-
2.11 D11 X
chave, analistas ou técnicos (especialmente em novas tecnologias).
Uso excessivo de consultores externos: Pode levar a um conflito de interesses, ou no
3.11 D11 X
não envolvimento significativo da equipe interna.
Falta de pessoal qualificado disponível: as pessoas com as habilidades certas não
4.11 D11 X
estão disponíveis quando você precisar deles.
1.12 Introdução de novas tecnologias. D12 X X X X X X X X

1.13 Dependências externas não atendidas. D13 X
Falta de controle sobre os consultores, fornecedores e subcontratados: Cronograma

2.13 D13 X
ou problemas de qualidade além do controle do gerente de projeto.
1.14 Ausência de planejamento ou planejamento inadequado. D14 X
26
Apêndice 2. Parâmetros de riscos oriundos da operacionalização do Framework
Probabilidad (continua)
Exposição
Fator de
Id Risco
Impacto
Prioridade Opções de Pessoa ou Equipe
Status
e
do Risco Tratamento Responsável
Risco
Prioritário: Controlar Analista de negócios
1.1 0.9 0.8 0.72 Acionar ou Mitigar (Coordenador) e Gerente Risco Alto
Plano de o Risco de Projetos.
Mitigação
Analista (Desenvolvedores)
/ Técnicos
Risco não Aceitar o
2.1 0.1 0.2 0.02 (Programadores) / Analista Risco Baixo
Prioritário Risco
de Requisitos / Analista de
Configuração e Mudança.
Líder ou Gerente de
Projetos / Analista
(Desenvolvedores) /
3.1 0.1 0.2 0.02 Técnicos (Programadores) Risco Baixo
Prioritário Risco
/ Analista de Requisitos e
Analista de Configuração e
Mudança.
Analista de negócios
Risco não Monitorar o (Coordenador) e
4.1 0.1 0.8 0.08 Risco Médio
Prioritário Risco Líder ou Gerente de
Projetos
Risco não Aceitar o Líder ou Gerente de
1.2 0.1 0.4 0.04 Risco Baixo
Prioritário Risco Projetos
Risco não Monitorar o (Coordenador) e
2.2 0.5 0.2 0.1 Risco Médio
Projetos.
Risco não Aceitar o (Coordenador) e
3.2 0.1 0.4 0.04 Risco Baixo
Projetos.
Risco Analista de negócios
Prioritário: Controlar (Coordenador)
1.3 0.9 0.8 0.72 Acionar ou Mitigar Líder ou Gerente de Risco Alto
Plano de o Risco Projetos e
Mitigação Analista de Requisitos.
Risco não Aceitar o Analista de negócios
2.3 0.1 0.2 0.02 Risco Baixo
Prioritário Risco (Coordenador).
27

(continuação)
Probabilidade
Exposição
Fator de
Id Risco
Impacto
Prioridade Opções de Pessoa ou Equipe
Status
do Risco Tratamento Responsável

3.3 0.1 0.2 0.02 Risco Baixo
4.3 0.1 0.2 0.02 Risco Baixo
Risco não Monitorar o Líder ou Gerente de
1.4 0.3 0.4 0.12 Risco Médio
Prioritário Risco Projetos.
2.4 0.3 0.4 0.12 Risco Médio
Risco não Aceitar o Líder ou Gerente de

3.4 0.1 0.4 0.04 Risco Baixo

4.4 0.3 0.4 0.12 Risco Médio
Risco
Prioritário: Controlar
5.4 0.7 0.4 0.28 Acionar ou Mitigar Risco Alto
Projetos.
Plano de o Risco
Mitigação
Risco não Monitorar o
1.5 0.3 0.4 0.12 Analista de Requisitos. Risco Médio
Prioritário Risco

2.5 0.1 0.4 0.04 Analista de Requisitos. Risco Baixo
Prioritário Risco
Risco não Monitorar o

1.6 0.3 0.4 0.12 Analista de Requisitos. Risco Médio
Prioritário Risco
Risco
2.6 0.5 0.4 0.2 Acionar ou Mitigar Analista de Requisitos. Risco Alto
Plano de o Risco
Mitigação
Risco
3.6 0.5 0.4 0.2 Acionar ou Mitigar Analista de Requisitos. Risco Alto
Plano de o Risco
Mitigação
28

(continuação)
Probabilidade
Exposição
Fator de
Id Risco
Impacto Prioridade
Opções de
Pessoa ou Equipe
Tratament Status
do Risco Responsável
o
0. 0. 0.0 Risco não Monitorar o Líder ou Gerente de Risco

1.7
3 2 6 Prioritário Risco Projetos. Médio
Risco
0. 0. 0.3
1.8 Acionar ou Mitigar Gerente de Projeto. Risco Alto
9 4 6
Plano de o Risco
Mitigação
0. 0. 0.0 Risco não Aceitar o Analista de Sistemas e Risco

1.9
1 4 4 Prioritário Risco Programadores. Baixo
Analista
(Desenvolvedores) /
Técnicos
1.1 0. 0. 0.1 Risco não Monitorar o (Programadores) / Risco
0 3 4 2 Prioritário Risco Analista de Requisitos e Médio
Analista de
Configuração e
Mudança.
2.1 0. 0. 0.1 Risco não Monitorar o Líder ou Gerente de Risco
0 3 4 2 Prioritário Risco Projetos. Médio
Risco
1.1 0. 0. Líder ou Gerente de
0.2 Acionar ou Mitigar Risco Alto
1 5 4 Projetos.
Plano de o Risco
Mitigação
Projetos / Analista
Risco (Desenvolvedores) /
Prioritário: Controlar Técnicos
2.1 0. 0.
0.2 Acionar ou Mitigar (Programadores) / Risco Alto
1 5 4
Plano de o Risco Analista de Requisitos e
Mitigação Analista de
Configuração e
Mudança.
3.1 0. 0. 0.1 Risco não Monitorar o Risco
Consultor.
1 3 4 2 Prioritário Risco Médio
29

(conclusão)
Probabilidad
Exposição
Fator de
Id Risco
Impacto Prioridade
Opções de
Pessoa ou Equipe
Tratament Status
e
do Risco Responsável
o
Analista
(Desenvolvedores) /
Técnicos
(Programadores) /
4.1 0. 0. 0.1 Risco não Monitorar o Analista de Requisitos Risco
1 3 4 2 Prioritário Risco Analista de Médio
Configuração e
Mudança e
Testadores (Deficientes
Visuais).
Analista
1.1 0. 0. 0.0 Risco não Aceitar o (Desenvolvedores) / Risco
2 1 4 4 Prioritário Risco Técnicos Baixo
(Programadores).
1.1 0. 0. 0.0 Risco não Aceitar o Risco
Gerente de Projeto.
3 1 4 4 Prioritário Risco Baixo
2.1 0. 0. 0.0 Risco não Aceitar o Risco
Gerente de Projeto.
3 3 1 3 Prioritário Risco Baixo
1.1 0. 0. 0.1 Risco não Monitorar o Risco
Gerente de Projeto.
4 3 4 2 Prioritário Risco Médio
Apêndice 3. Plano de mitigação para os riscos altos identificados (continua)

Exposição
Fator de
Id Risco
Plano de Mitigação: Ações que visam reduzir o impacto de ocorrência

Status
do risco prioritário
Assegurar que os requisitos funcionais e não funcionais foram

previamente definidos pelos stakeholders relevantes para a
elaboração do projeto. Elaborar uma análise prévia do ambiente, das
1.1 0.72 condições nas quais o projeto deverá operar (tecnologia, cronograma, Risco Alto
recursos humanos, cenário político) e documentá-las com a respectiva
anuência de todos os stakeholders relevantes. Contrato assinado por
todos os stakeholders relevantes.
Validação junto ao cliente dos requisitos definidos (CMMI PRODUCT
TEAM, 2010); Desenvolvimento iterativo e incremental [16];
Elaboração de protótipos para validação junto ao usuário
1.3 0.72 Risco Alto
(PRESSMANN, 2006); Gerenciar as alterações (mudanças) de
requisitos utilizando um procedimento documentado (CMMI
PRODUCT TEAM, 2010; SHUJA; KREBS, 2008).
30
Apêndice 3. Plano de mitigação para os riscos altos identificados (conclusão)
Exposição
Fator de
Id Risco
Plano de Mitigação: Ações que visam reduzir o impacto de ocorrência

do risco prioritário
Propiciar ao Líder / Gestor de Projetos um Modelo que propicie

suporte para a gestão de riscos de projeto de software. Envolver a
equipe na elicitação que pontos que possam impactar negativamente
nos objetivos previamente estabelecidos para o projeto, para que os
mesmos sejam gerenciados e controlados. Munido dos riscos
5.4 0.28 Risco Alto
definidos para o projeto classificá-los quanto a sua severidade,
baseado em parâmetros sugeridos pelo MCF proposto, ou em
parâmetros próprios da organização. Ter ciência de maneira pró-ativa
de uma visão holística dos riscos que possam impactar em fases
futuras do projeto.
Desenvolvimento iterativo e incremental (SHUJA; KREBS, 2008); Ao
final de cada iteração é entregue uma versão do software ao cliente.
Com base nos riscos de requisitos, é possível adotar iterações mais
longas (requisitos estáveis) ou mais curtas (requisitos mudando
rapidamente); Validação junto ao cliente dos requisitos definidos
2.6 0.2 Risco Alto
(CMMI PRODUCT TEAM, 2010); Elaboração de protótipos para
validação junto ao usuário (PRESSMANN, 2006); Gerenciar as
alterações (mudanças) de requisitos utilizando um procedimento
documentado (CMMI PRODUCT TEAM, 2010; SHUJA; KREBS,
2008).
Desenvolvimento iterativo e incremental (SHUJA; KREBS, 2008); ao
final de cada iteração é entregue uma versão do software ao cliente.
Com base nos riscos de requisitos, é possível adotar iterações mais
longas (requisitos estáveis) ou mais curtas (requisitos mudando
rapidamente); Validação junto ao cliente dos requisitos definidos
3.6 0.2 (CMMI PRODUCT TEAM, 2010). Essa prática é bastante importante Risco Alto
nos casos em que o preço é fixo por contrato (CMMI PRODUCT
TEAM, 2010); Elaboração de protótipos para validação junto ao
usuário (PRESSMANN, 2006); Gerenciar as alterações (mudanças) de
requisitos utilizando um procedimento documentado (CMMI
PRODUCT TEAM, 2010; SHUJA; KREBS, 2008).
Estabelecer um procedimento para estimar prazo dos projetos
(PMBoK, 2008);
1.8 0.36 Risco Alto
Manter uma base histórica de medidas de projetos anteriores, para ser
usada nas estimativas (PMBoK, 2008).
Atribuir papéis e responsabilidades para os membros da equipe
(PMBoK, 2008);
1.11 0.2 Assegurar que as pessoas estão aptas para desempenhar seu papel, Risco Alto
seja porque a pessoa já possui a habilidade ou porque foi treinada
para tal (CMMI PRODUCT TEAM, 2010).
31

Felipe Rafael Motta Cardoso PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Felipe Rafael Motta Cardoso PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Felipe Rafael Motta Cardoso PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Trabalho apresentado para obtenção do título de especialista

em Gestão de Negócios - 2016

Um framework para o gerenciamento de riscos de projetos: estudo aplicado à

Felipe Rafael Motta Cardoso¹; Cassia Renata Pinheiro2

445 – Piracicaba (SP), Brasil

Um framework para o gerenciamento de riscos de projetos: estudo aplicado à

Diante da pluralidade das variáveis que devem ser administradas no contexto

A framework for project risk management: study applied to software project

Desde a década de 60, a complexidade essencial dos sistemas de software de

O estudos do Framework foi aplicado a uma unidade organizacional de um

auxilia às organizações na melhoria de seus processos por meio de diretrizes de

de Projeto “Project Monitoring and Control” [PMC] e Gerenciamento de Riscos “Risk

Tabela 1. Categorias de Processos do CMMI

Na PA Planejamento de Projeto os riscos são identificados e analisados. A

possam ser planejadas e realizadas quando necessárias ao longo do ciclo de vida do

Figura 1. Redução de escopo do CMMI para o Framework proposto

Os Processos 8 e 9 trataram da Mitigação de Riscos, Nível 3 [N3] do CMMI-

Tabela 2. Exemplo de um fragmento do Framework inerente ao Processo 1

Fonte: Dados originais da pesquisa

As definições para a escala de probabilidade e impacto agregadas à taxonomia

Tabela 3. Exemplo de um fragmento do Framework inerente ao Processo 2

Fonte: Dados originais da pesquisa

Os parâmetros para riscos fornecem critérios para comparação dos vários

Tabela 4. Níveis de Probabilidade e Impacto dos Riscos nos Objetivos do Projeto

O nível de impacto e probabilidade foi definido pelos especialistas para cada

A análise qualitativa estabelece os riscos prioritários, obtidos pela análise da

Tabela 5. Matriz de Probabilidade e Impacto

As Tabela 4 e Tabela 5 apresentaram os Níveis de Probabilidade e Impacto

Tabela 6. Exemplo de um fragmento do Framework inerente ao Processo 6

Fonte: Dados originais da pesquisa

O Processo 7 avalia, dimensiona e prioriza os riscos. A Tabela 7 apresenta um

Tabela 7. Exemplo de um fragmento do Framework inerente ao Processo 7

Fonte: Dados originais da pesquisa

Tabela 8. Opções de Tratamento de Riscos

O Processo 9 - Implementar Planos de Mitigação de Riscos, monitora

Tabela 9. Exemplo de um fragmento do Framework inerente ao Processo 9

Fonte: Dados originais da pesquisa

De maneira simplificada foi apresentada a descrição funcional do Framework

Figura 2. Arquitetura simplificada das tecnologias utilizadas no RIMAE

A ferramenta RIMAE, foi concebida para encapsular os elementos presentes no

(10) Etapa de Desenvolvimento: Aspecto temporal no qual a Gestão de Riscos atuou

Figura 3. Cenário referente a 1 (um) risco avaliado

O Framework foi aplicado a uma unidade organizacional de uma Fábrica de

Figura 4. Classificação dos riscos associado às dimensões do projeto avaliado

A análise qualitativa efetuada possibilitou estabelecer os riscos prioritários para

Figura 5. Classificação dos riscos associado às dimensões do projeto avaliado (após

Figura 6. Classificação dos riscos associado às etapas desenvolvimento do projeto

A Figura 6 propiciou ao Gestor de Projetos uma visão holística e temporal das

Esta pesquisa teve como principal objetivo conceber e desenvolver um

Aos meus pais que abdicaram de muitas realizações pessoais em benefício de

Laundon, K. C.; Laundon, J. P. 2011. Sistemas de informação gerenciais. 9ed.

Pressmann, R. S. 2006. Engenharia de software. 6ed. McGrawHill, New York, NY,

Anexo 1. Dimensões e Fontes de Riscos (continua)

Relação com o Comando: Falta de comando do gerente de

Relacionamento com os Usuários: Falta de

Gestão: Má gestão da estratégia e execução

Requisitos: Gestão inadequada de requisitos

Gerenciamento de Recursos: Orçamento

Controle de Recursos: Má gestão do consumo