Gerenciamento de Riscos em Projetos

PUC
ISSN 0103-9741
Monografias em Cincia da Computao
n 18/10
Anlise de Riscos em Projetos: uma abordagem

por reflexo computacional baseada em lgica
Drlinton Barbosa Feres Carvalho
Edward Hermann Haeusler
Clarisse Sieckenius de Souza
Carlos Jos Pereira de Lucena
Departamento de Informtica
PONTIFCIA UNIVERSIDADE CATLICA DO RIO DE JANEIRO

RUA MARQUS DE SO VICENTE, 225 - CEP 22453-900
RIO DE JANEIRO - BRASIL
Monograas em Cincia da Computao, No. 18/10
ISSN: 0103-9741
Editor: Prof. Carlos Jos Pereira de Lucena
Dezembro, 2010
Anlise de Riscos em Projetos: uma abordagem por

reexo computacional baseada em lgica 1
Drlinton Barbosa Feres Carvalho, Edward Hermann Haeusler, Clarisse
Sieckenius de Souza, Carlos Jos Pereira de Lucena
{dcarvalho,hermann,clarisse,lucena}@inf.puc-rio.br
Resumo.
Gerenciamento de risco uma disciplina de gerncia de projetos que possui
como meta identicar, analisar e tratar fatores de risco, e com isso aumentar a chance
de sucesso de seus projetos.
Mesmo com objetivos to nobres, esta a disciplina com
menor grau de maturidade nas empresas.
75% dos gerentes de projeto no praticam
qualquer forma detalhada de gerncia de riscos e entendem apenas vagamente os conceitos

relacionados a essa disciplina, bem como suas consequncias.
Para auxiliar os gerentes
de projetos a analisar os fatores de risco em um projeto, proposto neste trabalho um

modelo para reexo computacional baseado em lgica.
A epistemologia utilizada na
construo do modelo, projetado para ser vericado por um vericador de modelos baseado
em lgica, apresentada junto a um exemplo. O modelo proposto avaliado por entrevistas
e experimentos com usurios potenciais do mtodo.
Palavras-chave: Anlise de Riscos, Categorizao de Fatores Chave de Risco, Vericador
de Modelos, Reexo Computacional.
Abstract. Risk management is a discipline of project management that aims to identify,
analyze and handle project risks, to increase the probability of success.
Even with so
noble objectives in the project management eld, this area has the lowest maturity level
in companies.
75% of the project managers do not apply any kind of systematic risk
management tactics and vaguely understand the concepts related to this discipline, not to
mention the consequences. This work proposes a tool to help project managers to do risk
analysis. This tool is a model based on logic used for computational reection about risks
in projects. The epistemology used to build this model, taking advantage of a logic-based
model checker to verify its properties, is presented together with an example. Potential
users for this methodology evaluate the proposed model with interview and experiment.
Keywords: Risk Analysis, Categorizing Key Drivers of Risk, Model Checker, Computa-
tional Reection.
Trabalho patrocinado pelo Ministrio de Cincia e Tecnologia da Presidncia da Repblica Federativa
do Brasil atravs da Bolsa de Doutorado CNPq 142620/2009-2.
In charge of publications:
Rosane Teles Lins Castilho

Assessoria de Biblioteca, Documentao e Informao
PUC-Rio Departamento de Informtica
Rua Marqus de So Vicente, 225 - Gvea
22451-900 Rio de Janeiro RJ Brasil
Tel. +55 21 3527-1516 Fax: +55 21 3527-1530
E-mail: bib-di@inf.puc-rio.br
Web site: http://bib-di.inf.puc-rio.br/techreports/
ii
Sumrio
1
Introduo
Metodologia
1
2
2.1
Anlise de Risco
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Vericador de Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avaliao
11
Concluso
13
References
13
A Termo de Consentimento
15
Formulrio da entrevista
17
Lminas utilizadas para explicar a nova metodologia
23
Checklist
28
de fatores de risco chave utilizada no experimento
iii
Introduo
Gerenciamento de risco uma disciplina de gerncia de projetos que possui como meta
identicar, analisar e tratar fatores de risco (Committee 2008). Para realizar esta tarefa,
os gerentes de projeto utilizam um conjunto de princpios e prticas para aumentar a
chance de sucesso de seus projetos. Mesmo possuindo objetivos to nobres na gesto de
projetos, esta a disciplina com menor grau de maturidade nas empresas, sendo que 75%
dos gerentes de projeto no praticam qualquer forma detalhada de gerncia de riscos e
entendem apenas vagamente os conceitos relacionados a essa disciplina, bem como suas
consequncias (Bakker, Boonstra & Wortmann 2009).
Na literatura, encontram-se diversas metodologias para realizar anlise de risco.
Os
artigos so bem diversos e vo de uma simples
checklist
minuto (Tiwana & Keil 2004), a
para criao de mtodos adaptados a cada
frameworks
para avaliaes de projetos em um
projeto (Keil, Cule, Lyytinen & Schmidt 1998, Varnell-Sarjeant 2008, Warkentin, Moore,
Bekkering & Johnston 2009, Alberts & Dorofee 2009). Tambm se encontra trabalhos que
buscam padres em documentao de projetos para serem generalizados e utilizados na
criao de novos mtodos (Wallace, Keil & Rai 2004), ou at mesmo trabalhos mais recentes
discutindo a forma e a eccia dos mtodos para anlise de risco (Bannerman 2008, Bakker
et al. 2009). Como a literatura extensa, neste trabalho so considerados principalmente
artigos relacionados com o gerenciamento de projetos para desenvolvimento de software.
Com o objetivo de auxiliar os gerentes de projeto a realizar anlise de risco, proposto
neste trabalho um
framework
analtico baseado em lgica, atravs da especicao formal
de um modelo para anlise de risco.
Para isso, apresentada a epistemologia utilizada
na construo desse modelo, que composta principalmente do conceito de risco, viso de

risco sistmico, a utilizao de fatores chave de risco, categorias desses fatores, a relao
entre as categorias e o sistema de qualicao desses fatores. A proposta deste trabalho
uma extenso do
framework
para a categorizao de fatores chave de risco criado por
Alberts & Dorofee (Alberts & Dorofee 2009), com a denio de um modelo analtico de
fatores de risco em um projeto.
A anlise de risco realizada atravs de um modelo com os fatores de riscos e as relaes
lgicas entre eles. As relaes entre os fatores de riscos permite criar um sistema em que
um risco inuencia diretamente em outro, e por consequncia de sucessivas inuncias
pode afetar o resultado global do projeto. A vericao do modelo realizada atravs da
enumerao exaustiva de todas as possibilidades de interao denidas entre os elementos
que compe o modelo.
A ferramenta utilizada para realizar essa tarefa chamada de
vericador de modelos. O usurio pode especicar assertivas lgicas e utilizar o vericador

de modelos para certicar-se de propriedades do projeto, sendo tambm possvel realizar
alteraes no modelo para simular outros cenrios hipotticos.
O modelo para anlise de risco avaliado atravs de entrevistas com usurios potenciais
do mtodo proposto. Cada usurio utilizou o mtodo para analisar os riscos de um projeto
de seu interesse.
Ao nal do experimento, avaliou-se a pontos fortes, fracos e possveis
melhorias. Quase todos os entrevistados disseram que utilizariam o mtodo proposto em

seus projetos, mas com as devidas adaptaes a realidade de seus projetos.
O restante deste artigo est organizado como segue. Na Seo 2, detalha-se a metodologia proposta para realizar anlise de risco em projetos. A Seo 3 apresenta uma avaliao
do mtodo proposto realizada por experimento e entrevista com usurios. Por m, o artigo
concludo na Seo 4.
Metodologia
Para realizar anlise de risco de projetos, proposto um
framework
analtico atravs de
uma especicao formal baseada em lgica dos fatores de risco de um projeto. Esse modelo
uma extenso de uma metodologia denida para anlise de risco em projetos de software,
apresentada na Seo 2.1. A extenso realizada atravs da criao de uma especicao
formal que pode ter propriedades validadas atravs de um vericador de modelos, que
apresentado na Seo 2.2. Com este novo mtodo possvel a avaliao das consequncias
de um fator de risco em outro, bem como a simulao de diversos cenrios hipotticos para
anlise de risco. Na Seo 2.3 est a especicao do modelo proposto em uma linguagem
formal, com as relaes entre as entidades do modelo.
2.1 Anlise de Risco

Gerenciamento de risco uma disciplina de gerncia de projetos que possui como meta
identicar, analisar e tratar fatores de risco. Para isto, utilizado um conjunto de princpios
e prticas para aumentar a chance de se ter como resultado um projeto bem sucedido. Esta
a disciplina com menor grau de maturidade nas empresas das quatro reas denidas pelo
Instituto de Gerenciamento de Projetos (Committee 2008). 75% dos gerentes de projeto
no praticam qualquer forma detalhada de gerncia de riscos e entendem apenas vagamente
os conceitos relacionados a essa disciplina, bem como suas conseqncias (Bakker et al.
2009).
Para responder o questionamento de que se realizar anlise de risco em projetos de
et al.
software aumenta de fato o sucesso dos projetos, Bakker
(Bakker et al. 2009) reali-
zaram uma reviso da literatura. O primeiro problema atacado nesta pesquisa foi denir
o que o sucesso na execuo de um projeto de software. A denio clssica de sucesso
em projetos consiste em uma simples comparao entre o que foi planejado, considerando
cronograma, oramento e requisitos, e o que foi entregue.
Considerando esta avaliao,
estima-se que pouco mais de 10% de todos os projetos so considerados bem sucedidos.
A pesquisa tambm descobriu que projetos com a utilizao de mtodos para a anlise de
stakeholders ) no processo, conse-
risco que consideram a participao de diversas pessoas (
guiram aumentar a percepo de sucesso. Percepo de sucesso uma medida em que os

participantes do projeto dizem se consideram o projeto bem sucedido ou no. Pequenos
desvios das metas planejadas so compensados pelo conhecimento das diculdades enfrentadas, e mesmo que no completamente satisfeitas o projeto considerado um sucesso. Na
literatura reportado que cerca de 55% de projetos passaram por diculdades, tiveram
que se adaptar, e nalizaram com uma avaliao de sucesso. Portanto, a realizao de anlise de risco colabora para o sucesso no desenvolvimento de um projeto, e a participao
dos envolvidos no projeto (
stakeholders ) nessa anlise aumenta a percepo de sucesso do
projeto como um todo.

Na literatura, encontram-se diversas maneiras para realizar anlise de risco. possvel
agrupar essas diversas formas em quatro classes (Bannerman 2008):
checklists, frameworks
analticos, modelos de processo, estratgias de resposta a risco. Listas dos maiores fatores
de risco ou para sucesso em projetos de software so os mais comuns na literatura e na
prtica. Essas listas geralmente so construdas a partir da experincia de participantes
em projetos e do estudo sobre histrico de projetos. Um exemplo dessas
checklist
a cls-
sica avaliao de qualquer projeto proposta a ser realizada em apenas um minuto (Tiwana
& Keil 2004).
Modelos para moldar o raciocnio de avaliadores sobre a anlise de risco
frameworks analticos ou modelos de processo. Ambos so muito

parecidos e baseados em checklists, mas possuem um modelo mais elaborado para agrupar
fatores de risco e lidar com eles. A diferena entre os frameworks analticos e os modelos
so conhecidos como
de processos est no fato dos primeiros serem apenas molduras para o raciocnio dos avaliadores e os outros condicionarem a anlise em um processo com passos bem denidos para
realizar anlise de risco. A ltima categoria sobre os outros mtodos de gerenciamento
do risco, que so voltados para estratgias de resposta a risco. Essas estratgias podem
ser divididas em quatro categorias:
estratgias que evitam o risco (prev alteraes no
projeto diante certas situaes), transferncia de risco (em situaes de alto risco transfere a responsabilidade do projeto a gerncias mais competentes a resolver os problemas),
eliminao por antecipao (busca identicar sinais de problema e adotar prticas para
evitar que se tornem uma ameaa real) e aceitao (dene uma srie de aes passivas ou
ativas em resposta a eventos de risco).
Neste trabalho, prope-se um
framework
um modelo para anlise de risco.
analtico atravs da especicao formal de
A seguir, apresentada a epistemologia utilizada na
construo desse modelo, que composta principalmente do conceito de risco, a viso de

risco sistmico, a utilizao de fatores chave de risco, as categorias desses fatores, a relao
entre as categorias e o sistema de qualicao desses fatores chave.
Da teoria clssica de deciso, risco denido por trs variveis relacionadas segundo
apresentado pela frmula
um fator de risco especco.

se realizar.
a probabilidade de um evento relacionado ao fator de risco
I.
Nessa frmula,
a exposio de risco atribuda a
o impacto, ou magnitude do evento. Na teoria clssica, o impacto pode ser
positivo ou negativo, sendo que uma viso mais moderna desta denio entende que se o
impacto for positivo ento se trata de uma oportunidade e no de um risco, portanto deve
ser tratado pela gerncia de oportunidades (Committee 2008, Bannerman 2008).
Neste
trabalho, consideramos apenas impactos negativos, que representam ameaas a projetos.

Em um projeto real, o nmero de ameaas elevado para ser analisado manualmente
pelos gerentes de projetos. Esta limitao no processamento levou os gerentes de projetos
a adaptarem a metodologia clssica (Bannerman 2008). A primeira adaptao que ao
invs de denir o regerenciamento dos riscos a partir de uma ordenao pelo valor de
R,
os gerentes se importam mais com a magnitude da perda potencial, mesmo que com
baixa probabilidade.
Para os gerentes,
mais importante do que
P.
Esta avaliao
tambm deve estar relacionada ao fato de que eles preferem caracterizar verbalmente um
risco a sua representao probabilstica, porque eles, em geral, so cticos sobre a reduo
da larga dimensionalidade do risco a um nico nmero.
Por m, os gerentes tendem
a no aceitar estimativas de risco dadas a eles, pois eles veem o risco como objeto a
ser controlado.
Gerenciar riscos faz parte das funes do gerente de projeto.
S que
estas adaptaes levam os gerentes a ignorarem um grande nmero de ameaas, mesmo

as com alta probabilidade de acontecer, j que na prtica eles conseguem gerenciar de 3
a 5 fatores de riscos, geralmente escolhidos pela magnitude do impacto mesmo com baixa
probabilidade de acontecer.
Para melhorar a representao dos fatores de riscos, utilizada a metodologia proposta
em (Alberts & Dorofee 2009). Nesta metodologia, o risco entendido como uma relao
de causa e efeito expressa pela probabilidade de acontecer uma ameaa que leva a uma
consequncia, que por sua vez possui um impacto no projeto. H diversos riscos relacio-
nados a um mesmo fator de risco. Para lidar com o grande nmero de riscos associados ao
projeto como um todo, escolhido apenas alguns fatores chave de riscos para agrupar os
riscos individuais. Neste modelo, o impacto de um risco inuencia diretamente seu fator
chave associado, mas tambm pode inuenciar outros fatores chave de risco, ou seja, um
modelo que possui uma viso sistmica do risco. Para isso, utilizada uma denio de
risco em que um evento potencial gera consequncias sob determinadas condies. Essas
consequncias por sua vez podem ser parte de condies do fator de risco chave ao qual o
risco est associado, ou at mesmo ser um evento potencial de outro fator de risco. Ento,
um fator chave de risco possui diversas condies que favorecem positivamente ou negativamente para ocorrncia de um evento futuro. Um fator de risco chave pode inuenciar
outros fatores de risco chave.
Um projeto possui diversos objetivos, sendo que cada objetivo possui fatores de risco,
que por sua vez possuem condies e eventos tanto positivos quanto negativos.
Para
facilitar a organizao nas denies das relaes entre os fatores de risco, so denidas
seis categorias dos fatores de risco.
As categorias, bem como as relaes de inuncia
entre elas so apresentadas na Figura 1. As categorias so representadas pelas caixas, e as

setas entre as caixas indicam a inuncia entre as categorias. Por exemplo, um fator de
Objectives ) pode exercer inuncia sobre fatores de risco das

(Preparation ) e Resilincia (Resilience ). Uma denio completa
risco da categoria Objetivos (

categorias Preparao
das categorias est disponvel em (Alberts & Dorofee 2009).
Figura 1: Relao entre as categorias dos fatores de risco

Para analisar um projeto, portanto, devem-se analisar os fatores chave de risco, relacionados com os objetivos do projeto. A avaliao de um fator de risco realizada atravs
de uma qualicao em escala de
Likert,
que est relacionada com a probabilidade em se
rationale ) da escolha descritas textualmente.
alcanar sucesso ou insucesso, e as razes (
Um exemplo de resposta a um fator de risco apresentado na Figura 2. O fator chave

de risco avaliado o processo utilizado no desenvolvimento do projeto.
Apesar de no
estar explcito na gura, vale dizer que este fator chave de risco pertencente categoria
Preparao.
Yes ),
A pergunta direciona o avaliador a responder Sim (
se as condies
relacionadas a este fator chave de risco sinalizarem baixssimo risco, seguindo um contnuo
No ),
at No (
que representa risco altssimo. Nas razes (
Rationale )
o avaliador descreve
textual o que foi considerado na avaliao, sinalizando os elementos que contriburam

positivamente, e os que contriburam negativamente.
Figura 2: Exemplo de avaliao de um fator de risco

Na metodologia apresentada em (Alberts & Dorofee 2009), no proposta nenhum
mtodo para anlise de risco, mas so apresentadas diversas possibilidades para analisar
os fatores de risco. A anlise mais trivial seria montar um grco relacionando todos os
fatores de risco e suas avaliaes. Variando um pouco mais este grco, podem-se agrupar
os fatores de risco de acordo com suas categorias, mas no apresentada nenhuma forma
de simular conguraes alternativas da avaliao dos fatores de risco, ou do impacto de
um fator de risco em outro.
2.2 Vericador de Modelos

A anlise de risco realizada atravs da vericao de um modelo, que denido a partir
dos fatores de riscos e as relaes lgicas entre eles. A vericao de modelos realizada
atravs da enumerao exaustiva de todos os estados possveis.
A ferramenta utilizada
para realizar essa vericao de modelos chamada de Vericador de Modelos.

Vericao de modelos um mtodo para vericar formalmente sistemas concorrentes
modelados por estados nitos (Clarke, Emerson & Sistla 1986). Uma especicao sobre
o sistema expressa por frmulas de lgica temporal, e ecientes algoritmos simblicos
so usado para percorrer o modelo denido pelo sistema e vericar se a especicao
consistente ou no.
A vericao de modelos, em que se verica automaticamente a
validade de propriedades, utilizada baseada em sistemas reativos. Sistemas reativos so

denidos basicamente por estados e transies. Estado a descrio do sistema em um
instante de tempo, ou seja, os valores associados as suas variveis naquele instante. J uma
transio a relao entre dois estados. A computao representada por uma sequencia
innita de estados, sendo que cada estado obtido a partir de um estado anterior atravs
de uma transio entre eles.
Vale ressaltar que mesmo utilizando vericao de modelos no h como garantir a
equivalncia dos modelos com a realidade do projeto, mas j se consegue vericar propriedades relacionadas aos fatores de riscos que estejam especicadas no modelo. As relaes
entre os fatores de riscos permite criar um sistema em que um risco inuencia diretamente
outro risco, e por consequncia de sucessivas inuncias pode afetar o resultado global do
projeto. Dessa forma, possibilita-se descobrir consequncias relevantes sobre os cenrios
avaliados para os projetos, ou mesmo ter garantias em relao ao que se est modelado.
Existem duas abordagens para implementar vericao de modelos: a abordagem lgica
e a abordagem baseada em teoria dos autmatos. Neste trabalho, utiliza-se a abordagem
lgica e o vericador de modelos
Symbolc Model Verier
(SMV) (Mcmillan 1992). Nesta
abordagem, um sistema reativo descrito atravs de um tipo de grafo de transio de

estados, chamado de
estrutura de Kripke.
A ferramenta SMV possui uma linguagem para
especicao de modelos que utilizada para descrever os sistemas de estados nitos. Essa
linguagem possui sintaxe baseada em lgica temporal do tipo
Computation Tree Logic
(CTL) (Emerson 1990) para expressar as propriedades a serem vericadas.
2
SMV est disponvel para download na Internet .
O sistema
O usurio pode especicar assertivas lgicas e utilizar o vericador de modelos para

certicar-se de propriedades do projeto, sendo tambm possvel realizar alteraes no modelo para simular outros cenrios.
Um exemplo de propriedade que pode ser avaliada
se algum fator de risco (varivel) pode alcanar um determinado nvel de risco (valor).
Variaes nos valores iniciais das variveis (avaliao dos fatores de risco) e nas relaes
ente elas possibilitam criar diferentes cenrios a serem vericados.
Na prxima seo, so apresentados detalhes da especicao do modelo e as possibilidades de adaptao deste mtodo para projetos especcos.
2.3 Proposta
As respostas dadas pelos gerentes de projetos a uma
checklist
de fatores de risco so
utilizadas para analisar os riscos de um projeto. Os elementos principais nesta anlise so
http://www.cs.cmu.edu/~modelcheck/smv.html
6
as avaliaes dos fatores chave de risco e as relaes entre eles.
Os riscos potenciais do
projeto so anotados textualmente e agrupados em seus respectivos fatores chave de risco.

A avaliao sistmica de todos os fatores chave de riscos, bem como dos relacionamentos
entre eles, determina uma anlise de risco do projeto como um todo.
Essa anlise
realizada atravs da vericao de um modelo de inuncias de fatores chave de riscos

conforme apresentado a seguir.
proposto um modelo que descreve um sistema em que um fator chave de risco pode
inuenciar na avaliao de outro fator, tendo essa relao denida pela categoria do fator
chave de risco. Os riscos so descritos como eventos que causam uma mudana da avaliao
de risco em um fator. Portanto, os riscos de um fator chave de risco so os eventos que
causam mudana na avaliao do risco.
A partir de uma avaliao inicial, a ocorrncia
do evento (risco) leva a avaliao para outro valor (nal). Um risco pode afetar um fator
chave de risco, que por sua vez pode afetar outros fatores de risco.
A relao entre os
fatores de risco determina pelas categorias, lembrando que cada fator de risco pertence
a uma categoria.
Para exemplicar a relao entre os fatores de risco, apresentado na Figura 3 um
conjunto de 10 fatores de risco e o relacionamento entre eles, conforme sugesto de fatores
denido pelo framework (Alberts & Dorofee 2009). Os fatores chave de risco so representados por retngulos nomeados e a categoria apresentada entre parnteses aps o nome
do fator de risco.
As setas indicam que a avaliao de um fator de risco inuencia na
avaliao do fator de risco na outra ponta, no sentido da seta.
Figura 3: Modelo do sistema de inuncia entre os fatores chave de risco

O modelo foi implementado na linguagem do vericador de modelos
SMV. Dessa forma,
o modelo proposto suporta a ocorrncia de uma srie innita de eventos e de inuncias

entre os fatores de risco. Propriedades lgicas denidas em TCL so vericadas pelo
SMV.
A avaliao dos fatores de risco considerada de trs nveis de risco: alto, mdio e baixo.
A seguir so apresentador alguns detalhes de implementao.
Cada fator chave de risco programado como um mdulo que possui como variveis
o estado, que representa a avaliao desse fator, e os eventos (riscos) que inuenciam
na avaliao.
Cada mdulo tambm dene as transies da avaliao do fator de risco,
de acordo com os eventos denidos pelo usurio.
A seguir apresentado o cdigo da
implementao de um fator de risco com trs eventos do usurio.
MODULE d10_environment_organization_conditions
VAR
state : {h,m,l};
-- user events
ev1 : {1,0};
ev2 : {1,0};
ev3 : {1,0};
ASSIGN
next(state) := case
-- user events
state = m & ev1 : h;
state = m & ev2 : h;
state = m & ev3 : l;
1 : state;
esac;
Os fatores chave de risco que podem ser inuenciados por outros fatores so denidos
como mdulos parametrizados. A inuncia programada como uma transio, noticada
pelo parmetro. No modelo proposto, um fator de risco avaliado como alto pode fazer com
que a avaliao de outros fatores de riscos sob sua inuncia tambm sejam avaliados com
risco alto. Tambm denido que se todos os fatores chave de risco que inuenciam um
determinado fator so avaliados com risco mdio ento esse fator avaliado como risco alto.
Outra transio denida que se o fator chave de risco tiver avaliao baixa e algum dos
fatores de risco que inuenciam esse fator tiver com nvel mdio ento a avaliao aumenta
para mdio.
MODULE d20_result_certification_and_accreditation (d10_env_state,d2_prep_state,

d4_exec_state,d5_exec_state,d6_exec_state,d9_exec_state)
VAR
state : {h,m,l};
-- user events
ev1 : {1,0};
ev2 : {1,0};
ev3 : {1,0};
ASSIGN
next(state) := case
-- user events
state = l & ev1 : m;
state = l & ev2 : h;
state = l & ev3 : m;
-- transitions from relationships among the driver categories
d10_env_state = h : h;
8
esac;
d2_prep_state = h : h;
d4_exec_state = h : h;
d10_env_state = m & d2_prep_state = m & d4_exec_state = m
& d5_exec_state = m & d6_exec_state = m & d9_exec_state = m : h;
state = l & (d10_env_state = m | d2_prep_state = m | d4_exec_state = m
| d5_exec_state = m | d6_exec_state = m | d9_exec_state = m) : m;
1 : state;
O risco global do projeto denido a partir da avaliao dos fatores de risco chave da
result ).
categoria resultado (
Se algum fator de risco da categoria resultado tiver avaliao
de alto nvel de risco ento o resultado global algo. Se os fatores de risco que inuenciam
o resultado global do projeto tiverem avaliao de nvel mdio ento o resultado pode ser
mdio ou alto. Vale lembrar, que o modelo deve ser adaptado a realidade de cada projeto
a ser avaliado e aqui apresentado apenas um exemplo de modelo.
MODULE global_risk (d13_result_state,d20_result_state)

VAR
state : {h,m,l};
ASSIGN
next(state) := case
-- transitions from relationships among the driver categories
d13_result_state = h | d20_result_state = h : h;
d13_result_state = m & d20_result_state = m : {m,h};
1 : state;
esac;
O mdulo principal do modelo consiste da denio de uma varivel para cada fator
de risco. Nestas denies, o relacionamento entre os fatores de risco estabelecido pelos
parmetros dos mdulos.
MODULE main
VAR
d10 : process
d1 : process
d2 : process
d12 : process
d4 : process
d5 : process
d6 : process
d9 : process
d10_environment_organization_conditions;
d1_objectives_program_objectives (d10.state);
d2_preparation_plan (d10.state,d1.state);
d12_resilience_event_management (d10.state,
d1.state,d2.state);
d4_execution_task_execution (d10.state,d2.state,d12.state);
d5_execution_coordination (d10.state,d2.state,d12.state);
d6_execution_external_interfaces (d10.state,
d2.state,d12.state);
d9_execution_facilities_and_equipment (d10.state,
d2.state,d12.state);
9
d13 : process d13_result_requirements (d10.state,d2.state,d4.state,

d5.state,d6.state,d9.state);
d20 : process d20_result_certification_and_accreditation (d10.state,
d2.state,d4.state,d5.state,d6.state,d9.state);
g : process global_risk (d13.state,d20.state);
O estado inicial de cada mdulo denido conforme a avaliao de cada fator de risco
na
checklist.
Caso algum fator de risco no tenha resposta na
checklist,
o modelo suporta
a denio de todos os nveis para serem considerados na vericao do modelo. Esse caso
exemplicado na linha que est comentada em relao ao fator
d2.
ASSIGN
init(d10.state) := m;
--init(d2.state) := {l,m,h};
init(d4.state) := l;
init(g.state) := l;
As assertivas lgicas a serem vericadas pelo vericador de modelos so denidas na
seo
SPEC.
Neste caso, para determinar se o risco global do projeto pode chegar ao nvel
alto a assertiva em lgica TCL a ser vericada pelo analisador de modelos ca expressa em
linguagem natural: no existe algum estado em que o nvel do risco global (representado
pela varivel
g.state)
alto. Se existir algum estado que por consequncia da sucesso
da ocorrncia de eventos e inuncia dos fatores de risco o risco global do projeto (varivel
g.state)
for alto, ento os valores das variveis ao longo da computao dos estados so
apresentados como prova de que a propriedade falsa. Caso a propriedade for verdadeira, o
analisador de modelos simplesmente conrma que propriedade verdadeira. A garantia da
avaliao completa de todos os estados possveis expressa pela diretiva
FAIRNESS. A ava-
liao de propriedades, como a avaliao de um fator de risco especco, est exemplicado

como a avaliao do fator de risco
d2
na linha comentada.
SPEC
!EF(g.state = h)
--!EF(d2.state = h)
FAIRNESS
running
10
Avaliao
A avaliao do mtodo proposto foi realizada atravs de entrevistas e experimentos com

usurios. O objetivo foi avaliar o novo mtodo para anlise de riscos, identicando pontos
positivos e negativos, possveis melhorias e viabilidade de uso. Os participantes so gerentes
stakeholders ) no desenvolvimento de projetos de software.

chat, utilizando o
4
alm de formulrios eletrnicos disponbilizados pelo Google Docs .
de projeto ou envolvidos (
A entrevista foi realizada atravs de ligao de voz na Internet e

programa
3
c ,
Skype
A aceitao do termo de consentimento de participao no experimento, disponvel no

Apndice A, foi realizada por uma mensagem de conrmao por e-mail.
O udio das
conversas foi gravado para permitir anlise mais detalhada da entrevista. As respostas dos
questionrios esto disponveis no prprio sistema do
Google Docs.
O tempo total estimado para o experimento foi de 55 minutos, embora nenhuma entrevista tenha sido interrompida por causa do tempo. O experimento mais demorado teve
durao de 01h45min e na mdia eles levaram cerca de 01h30min, excesso que foi motivado
principalmente pelo interesse dos entrevistados em conhecer detalhes sobre a metodologia.
Foram realizadas quatro entrevistas. Cada entrevista consistiu de trs partes, mais um
prembulo. O prembulo contm informaes gerais sobre o entrevistado. A primeira parte
composta de trs perguntas a respeito da disciplina de anlise de riscos. O experimento
realizado na segunda parte, composto de uma breve descrio da metodologia e simulao
de uso. Por m, so realizadas mais trs perguntas na terceira parte em que o entrevistado
pode expressas opinies a respeito do mtodo experimentado. Os documentos utilizados
na entrevista esto disponveis como apndice deste trabalho.
No Apndice B est o
questionrio utilizado na entrevista. As lminas utilizadas na explicao do mtodo e a
checklist
utilizada no experimento esto nos Apndices C e D, respectivamente.
O perl dos entrevistados bastante variado, o que possibilitou ter uma diversidade de
opinies e enriquecendo a avaliao, de acordo com os objetivos do experimento. A seguir,
so relatados resumos das entrevistas.
O primeiro entrevistado possui formao na rea de humanas e coordena projetos de
software para minerao de dados em redes sociais na Internet. Mesmo no tendo formao
principal na rea tecnolgica, o entrevistado no teve diculdades em entender o mtodo
proposto ou em realizar o experimento.
A maior diculdade encontrada foi a falta de
denies precisas das metas dos projetos em que trabalha, pois utiliza-se um desenvolvimento baseado em mtodos geis de desenvolvimento com alta volatilidade dos requisitos.
Esta instabilidade nas denies do projeto e das tecnologias relacionadas, motivado prin-
start-up ), levou a
cipalmente por se tratar de projetos de uma empresa de pequeno porte (
avaliaes de alto risco dos projetos, o que j era sabido. Para este entrevistado a metodologia no traz benefcios em curto prazo, pois ele precisa de uma melhor organizao dos
projetos de tal sorte a no ter nenhum risco alto associado aos fatores de risco chave. A
criatividade deste entrevistado se destaca dos demais na resposta para a pergunta sobre o
que ele gostaria de saber do analisador de modelos. A resposta foi: estado atual, futuro,
comparaes com outras empresas do meu segmento. A partir das informaes que ele
forneceu ao sistema, ele esperava que fosse possvel saber o estado de risco atual, permitir
simulaes sobre o futuro e at comparaes do estado de risco com projetos de concorren-
3
4
http://skype.com
http://docs.google.com
11
tes. Essas expectativas so genunas e vlidas, mas vo muito alm do que possvel fazer
por enquanto. Fica registrado como ideia para trabalhos futuros na metodologia. Sobre
o questionrio o entrevistado ainda disse que o questionrio no intuitivo e difcil de
entender, com diversas perguntas que no se adquam a sua realidade.
O segundo entrevistado um desenvolvedor de sistemas snior, com doutorado em
tecnologia, que atua em projetos de grande porte, mas sem processo bem denido.
metodologia foi facilmente entendida e a
checklist
preenchida. Uma diculdade comparti-
lhada por todos os entrevistados foi comear a preencher o questionrio, o que demonstra
que h um esforo signicativo para aprender como responder a
checklist.
Para contor-
nar essa diculdade foram apresentados exemplos de respostas. As respostas da
checklist
foram bem elaboradas, com a denio de diversas propriedades a serem avaliadas pelo
analisador de modelos. A traduo das perguntas em assertivas lgicas foi realizada pelo
entrevistador, mas futuramente necessrio que haja um sistema para auxiliar o usurio
a criar expresses lgicas. O entrevistado gostou da metodologia proposta e at usaria em
seus projetos, mas sente uma urgncia maior em relao a um processo a ser seguido no
desenvolvimento do projeto.
O terceiro entrevistado um gerente de projetos de pesquisa que j atuou mais de ano
como analista de sistemas snior de uma grande empresa de software, e tambm possui
doutorado em tecnologia. Sua experincia como analista de sistemas foi bastante rica em
relao a processos e metodologias em projetos. Possui aprofundado conhecimento de metodologias geis, especialmente o
SCRUM.
Demonstrou-se muito interessado em aprender
sobre a disciplina de anlise de risco, a qual tinha apenas vaga noo a respeito, apesar de
fazer intuitivamente anlise de risco de seus projetos. A todo o momento perguntava se
poderia utilizar a metodologia proposta para realizar a avaliao de seus projetos de pesquisa. O experimento foi rico na ilustrao de situaes em que o projeto avaliado alcana
risco alto, corroborando exatamente o maior medo do entrevistado (ocorrncia de um determinado evento). Por se tratar de um experimento feito rapidamente, foi recorrente em
todos os experimentos que os resultados obtidos pelo analisador de modelos foram triviais,
sem ocorrncias de muitos eventos para que o risco geral do projeto fosse alto.
Mesmo
assim, o entrevistado se demonstrou conante na metodologia desenvolvida. Ele tambm

solicitou que se criassem perguntas direcionadas a projetos de pesquisa, pois as perguntas
do questionrio no estavam aderentes a sua realidade. O entrevistado tambm encontrou
muita diculdade em entender as perguntas da
checklist.
Alm disso, tambm citou a escala
de apenas trs valores, pois na dvida ele marcou a resposta com risco mdio, a qual ele
chamou de resposta em cima do muro (tambm observado pelo segundo entrevistado).
Apesar das crticas, a avaliao geral da metodologia foi bem positiva e o entrevistado
ainda ressaltou que gostaria que o questionrio fosse adaptado a sua realidade para ser
utilizado de fato em seus projetos.
O quarto entrevistado professor ps-graduado em engenharia de software e que eventualmente desenvolve projetos para o mercado, desempenhando o papel de gerente de
projetos. Como possui formao na rea, j estava familiarizado com conceitos de risco e
anlise de risco, apesar de aps a explicao da proposta deste trabalho reconhecer que seu
conhecimento estava desatualizado. A denio de anlise de risco fornecida inicialmente
na entrevista foi em relao a processos de desenvolvimento de softwares mais antigos,
rigorosos e longe da sua realidade. Por esse motivo, o entrevistado tambm disse que no
pratica anlise de risco em seus projetos, pois prefere utilizar sua intuio. O experimento
12
com o mtodo proposto permitiu revelar a diculdade que gerentes de software podero
enfrentar ao identicar eventos signicativos que representem o risco em seus projetos. No
nal do teste, o entrevistado gostou de ter participado do experimento por ter atualizado
seus conhecimentos em relao disciplina de anlise de risco e ter conseguido usar a
ferramenta, apesar de ainda preferir utilizar sua intuio no gerenciamento de seus projetos, que so de pequeno porte. Para projetos de maior porte, ele disse que usaria esta
nova metodologia sim, pois considera til tambm para documentar os riscos do projeto e
compartilhar este conhecimento com a equipe.
A maioria dos entrevistados ressaltou a necessidade de adaptar a
de cada projeto.
checklist realidade
framework e cada
Isto j era esperado, pois o mtodo proposto um
modelo representa a realidade de um projeto. O experimento foi realizado com um mesmo

modelo por causa da complexidade de se adaptar o modelo apresentado como exemplo.
Embora, o experimento tenha sido comprometido pela falta de aderncia ao projeto que
estava sendo avaliado cou claro que em um experimento de curta durao no possvel
realizar uma avaliao se tiver que tambm criar o modelo.
Contudo, considerando o
fato de os entrevistados usarem projetos com que trabalha diariamente, a identicao dos
fatores de risco usados na anlise de risco foi facilitada com o modelo utilizado na avaliao
e tambm foi possvel perceber com maior realidade as necessidades dos entrevistados.
Concluso
Este trabalho prope um novo mtodo para realizar anlise de risco no desenvolvimento
de projetos de software.
Foi apresentado um modelo para reexo computacional sobre
anlise de risco, que baseado em uma mquina de estados nitos e permite a validao de
propriedades denidas por lgica temporal
TCL.
A epistemologia utilizada na construo
do mtodo foi detalhada, bem como foi mostrada a implementao de um mtodo para
anlise de risco na linguagem de especicao formal utilizada pelo vericador de modelos
SMV.
sta-
Foram realizadas entrevistas e experimentos com gerentes de projeto ou envolvidos (
keholders ) no desenvolvimento de projetos.
O objetivo foi avaliar o mtodo proposto para
anlise de riscos, identicando pontos positivos e negativos, possveis melhorias e viabilidade de uso. Os entrevistados avaliaram positivamente o mtodo proposto e ressaltaram
a necessidade de adaptar a
checklist
(modelo) realidade de cada projeto.
Um dos entrevistados disse que usaria a metodologia proposta neste trabalho se j

houvesse catalogado fatores de risco chave para projetos de pesquisa. Portanto, este um
desdobramento factvel desta pesquisa. Outra melhoria que pode ser agregada ao trabalho
considerar mltiplos
stakeholders
respondendo o questionrio para um mesmo projeto
com unicao automatizada de eventos.
Referncias
Alberts, C. J. & Dorofee, A. J. (2009), A framework for categorizing key drivers of risk, Technical Report CMU/SEI-2009-TR-007, Software Engineering Institute, Pittsburgh,
PA.
13
Bakker, K., Boonstra, A. & Wortmann, H. (2009), `Does risk management contribute to
it project success?
a meta-analysis of empirical evidence',
Project Management .
International Journal of
Bannerman, P. L. (2008), `Risk and risk management in software projects: A reassessment',
J. Syst. Softw. 81(12), 21182133.
Clarke, E. M., Emerson, E. A. & Sistla, A. P. (1986), Àutomatic verication of nite-state

concurrent systems using temporal logic specications',
Syst. 8(2), 244263.
ACM Trans. Program. Lang.
A guide to the project management body of knowledge (PMBOK

Guide) (4th ed.), Project Management Institute (PMI), Newtown Square, PA.
Committee, P. S. (2008),
Emerson, E. A. (1990), Temporal and modal logic,
in
J. van Leeuwen, ed., `Handbook of
Theoretical Computer Science', Elsevier, pp. 9961072.

Keil, M., Cule, P. E., Lyytinen, K. & Schmidt, R. C. (1998), À framework for identifying
software project risks',
Commun. ACM 41(11), 7683.
Mcmillan, K. L. (1992), `The SMV system'.

Tiwana, A. & Keil, M. (2004), `The one-minute risk assessment tool',
Commun. ACM
47(11), 7377.
Varnell-Sarjeant, J. F. (2008), `Managing a man-rated software development program via

risk mitigation',
SIGSOFT Softw. Eng. Notes 33(4), 18.
Wallace, L., Keil, M. & Rai, A. (2004), Ùnderstanding software project risk: a cluster
analysis',
Inf. Manage. 42(1), 115125.
Warkentin, M., Moore, R. S., Bekkering, E. & Johnston, A. C. (2009), Ànalysis of systems
development project risks: an integrative framework',
14
SIGMIS Database 40(2), 827.
Termo de Consentimento
15
Departamento de Informtica, PUC-Rio

Rua Marqus de So Vicente, 225
Gvea Rio de Janeiro RJ 22451-900
Tel. (21) 3114-1500 r. 3323
Termo de Consentimento
Reflexo computacional a habilidade do sistema computacional raciocinar sobre seu comportamento,
podendo ou no modific-lo. Tal reflexo extremamente til para entender e solucionar problemas
em sistemas computacionais. Esta pesquisa faz parte de um estudo multidisciplinar sobre linguagens
de representao para reflexo computacional, particularmente, estamos interessados em avaliar um
nova metodologia para anlise de riscos. O objetivo desse experimento identificar pontos positivos e
negativos, possveis melhorias e viabilidade de uso do mtodo proposto.
Por isto, convidamos voc a colaborar com nossa pesquisa, composta de trs etapas, mais
prembulo:
1. Prembulo.
2. Introduo.
3. Experimento.
4. Concluso.
Para decidir sobre sua participao, importante que voc tenha algumas informaes adicionais:
1. Os dados coletados sero acessados somente pela equipe desta pesquisa. A entrevista ser gravada,
apenas para que possamos analisar com cuidado os dados coletados.
2. A divulgao dos resultados de nossa pesquisa exclusivamente para fins acadmicos pauta-se no
respeito privacidade, e o anonimato dos participantes preservado em quaisquer documentos que
elaborarmos.
3. O consentimento para participao uma escolha livre, e esta participao pode ser interrompida a
qualquer momento, caso voc precise ou deseje.
De posse das informaes acima, voc:
Consinto em participar.
Participante: ____________________________________________
Assinatura: _____________________________________________
Rio de Janeiro, 07 de dezembro de 2009.
Formulrio da entrevista
17
12/9/2009
Experimento sobre Nova Metodologia
Experimento sobre Nova Metodologia para Anlise

de Riscos em Projetos
Objetivo: Avaliar nova metodologia para anlise de riscos, identificando pontos positivos e
negativos, possveis melhorias e viabilidade.
Perfil dos participantes: Gerente de projeto, e stakeholders em projetos de software.
Resumo: Entrevista consiste de 3 partes, mais um prembulo. A primeira parte composta de
trs perguntas gerais sobre a disciplina de anlise de riscos. O experimento realizado na
segunda parte, composto de uma breve descrio da metodologia e simulao de uso. Por fim,
so realizadas mais trs perguntas na terceira parte em que o entrevistado pode expressas
opinies a respeito da ferramenta. O prembulo contm informaes sobre o entrevistado.
Tempo total estimado: 55 minutos.
Continue
Powered by Google Docs
Report Abuse - Terms of Service - Additional Terms
google.com/formResponse?formkey
1/1
12/9/2009

* Required
Prembulo
O objetivo deste questionrio saber mais sobre a formao e experincia geral do participante.
Tempo estimado: 6 minutos.
Nome
(opcional)
Escolaridade *
Profisso *
Certificaes *
Indstria da empresa em que trabalha *
Experincia com gerncia de projetos (anos, meses) *
Outras informaes que julgar relevante
Back
Continue

1/2
12/9/2009

* Required
Introduo
O objetivo deste questionrio saber mais sobre o nvel de conhecimento e experincia do
participante em relao a disciplina de anlise de risco. Tempo estimado: 9 minutos.
Voc sabe o que anlise de riscos em projetos? Explique. *
Voc realiza anlise de riscos nos seus projetos? Se sim, explique. *
Voc gostaria de alguma metodologia que lhe ajudasse a realizar anlise de risco em
projetos? *
Back
Continue

1/1
12/9/2009

Experimento
Realizar simulao de anlise de risco do projeto que est trabalhando no momento, utilizando a
nova metodologia proposta. Tempo estimado: 30 minutos.
Apresentar nova metodologia para anlise de risco
Descreva brevemente sobre o projeto em questo.

Se no for possvel por questes de confidencialidade industrial, relate um caso hipottico similar
ao que ser realizado a anlise.
Responder o questionrio de anlise de risco.

Responder no questionrio apropriado.
Back
Continue

1/1
12/9/2009

* Required
Concluso
Tempo estimado: 10 minutos.
O que voc achou da nova metodologia? Pontos positivos e negativos. *
Voc considera que esta ferramenta pode melhorar o seu trabalho? *
Outros comentrio.
Back
Submit

1/1
Lminas utilizadas para explicar a nova metodologia
23
Project
Creation of a tool to help users in the risk analysis of software development

project, using a novel representation for computational reflection.
Risk Analysis in Projects: an approach for

computational reflection based on logic
Domain
Software development
Task
Risk Analysis
Development
Darlinton Carvalho
Tool
darlinton@gmail.com
Darlinton Carvallho @ LES/PUC-Rio
10/12/2009
Risk Analysis
Risk Analysis
What is risk?
What is risk?
R=PxI
What is risk management?

Improving software projects
Does risk management contribute to IT project success?
R is risk exposure attributable to a particular risk factor

P is the probability the event will be realized
I is the impact or magnitude of the event

Bannerman, P. L. 2008. Risk and risk management in software projects: A reassessment. J. Syst.
Softw. 81, 12 (Dec. 2008), 2118-2133. DOI= http://dx.doi.org/10.1016/j.jss.2008.03.059
Classical decision theory X a modern view
De Bakker, K et al. Does risk management contribute to IT project success? A meta-analysis of

empirical evidence. Int J Project Manage (2009), doi:10.1016/j.ijproman.2009.07.002
80% of managers consider only negative outcomes as risk

(March and Shapira (1987))
In Software Projects I is only negative
10/12/2009
Risk Analysis
10/12/2009
Risk Analysis
What is risk management?
Improving software projects
Set of principles and practices aimed at identifying, analyzing

and handling risk factors
Literature reports that risk management can significantly

improve software projects outcomes.
To improve the chances of achieving a successful project outcome

and/or avoid project failure (Boehm 1989, 1991; Charette, 1989;
Kerzner, 2003)
It also reports that risk management is not always wellapplied in practice.

Study of project management maturity based on PMIs knowledge
areas found that the risk knowledge area had the lowest
maturity of all knowledge areas in the IS industry, and the IS

Checklists, analytical frameworks, process models, risk response
strategies.
10/12/2009
industry was the lowest of the four in the study.

75% of project managers did no follow any detailed risk
management approach, and only vaguely understood the software
risk concept and its managerial implications.
10/12/2009
Risk Analysis
Novel approach
Does risk management contribute to IT project success?
A Framework for Logic Analysis

of Key Drivers of Risk
Based on the work:

10/12/2009
Risk Analysis Theory
Alberts, C.J. & Dorofee, A.J. A Framework for Categorizing Key Drivers of Risk.
TECHNICAL REPORT, ESC-TR-2009-007, CMU/SEI-2009-TR-007, 2009
10/12/2009
10/12/2009
10
Alberts, C.J. & Dorofee, A.J. A Framework for Categorizing Key Drivers of Risk.
TECHNICAL REPORT, ESC-TR-2009-007, CMU/SEI-2009-TR-007, 2009
10/12/2009
11
10/12/2009
12
10/12/2009
13
10/12/2009
14
15
10/12/2009
10/12/2009
10/12/2009
16
17
10/12/2009
18
Extension
Extension
Multiple users answer the questionnaire

Answer rationale is defined by events
changes over the answers
Analysis is made over the composition of users answers.

?
Creation of a logic model to represent the questionnaire answers

Allow logic queries.
Risk analysis is done by Model Checker assertive.

Is there any way to have Answer No (high risk)?
The answer is true if there isnt a case.
The answer is false and an instance is given as result. The result explains a
scenario where the risk can be high.
10/12/2009
19
10/12/2009
Rationale
Rationale
event1
event4
event2
event5
event3
event6
20
22
Backup
Model Checking: O que ?
- Especificar
- O sistema como um sistema de transio (finito em geral).
- Uma propriedade como uma sentena em uma linguagem
de consulta.
- Estabelecer que o sistema um modelo da sentena
sistema |= sentena
Obs: Tarefa realizada por varredura no espao de busca
- Usualmente no h necessidade de teorias auxiliares
- Normalmente, as nicas suposies dizem respeito s propriedades
dinmicas do sistema (branching vs. linear time, fairness, liveness)
- Funciona melhor com sistemas voltados ao controle e com um

pequeno espao de estados
Profs Clarisse, Renato
e Hermann
TECMF
10/12/2009
21
Risk Analysis
Mtodos Formais em
Reflex. Comput.
Risk Analysis new approaches
Risk and Managers

Managers:
concern with the magnitude of the potential loss than the
probability it will occur.
I is more important than P
Prefer verbal characterizations of risk than probabilistic

representation because they are skeptical that the broad
dimensionality of risk can be reduced to a single number
Managers dont like P
Tend no to accept risk estimates given to them because they

see risk as subject to control.
They manage R

10/12/2009
23
Masticola, S. P. 2007. Lightweight Risk Mitigation for Software Development Projects Using
Repository Mining. InProceedings of the Fourth international Workshop on Mining Software
Repositories (May 20 - 26, 2007). International Conference on Software Engineering. IEEE
Computer Society, Washington, DC, 13. DOI= http://dx.doi.org/10.1109/MSR.2007.16
10/12/2009
24
Checklist
de fatores de risco chave utilizada no experi-
mento
28
12/9/2009
Gmail - Key drivers risk evaluation
Darlinton Carvalho <darlinton@gmail.com>
Key drivers risk evaluation

1 message
darlinton@gmail.com <darlinton@gmail.com>
To: darlinton@gmail.com
Wed, Dec 9, 2009 at 9:21 AM
If you have trouble viewing or submitting this form, you can fill it out online:
https://spreadsheets.google.com/viewform?formkey=dFp1SF9RZWltbUlfaFNTcmdXZ082U0E6MA
Key drivers risk evaluation

All responses will be anonymous or you can type your name here. Thank you for your time!
Name and role

Example: John (manager), Joe (developer)
1. Program Objectives (Objectives) *

Program objectives (product, cost, schedule) are realistic and achievable.
low
rationale 1
describe the event which must happen to change the answer - mask: actual state; next state;
description
2. Plan (Preparation) *
The plan for developing and deploying the system is sufficient.
low
rationale 2
description
https://mail.google.com/mail/?ui=2&ik
1/5
12/9/2009
4. Task Execution (Execution) *

Tasks and activities are performed effectively and efficiently.
low
rationale 4
description
5. Coordination (Execution) *
Activities within each team and across teams are coordinated appropriately.
low
rationale 5
description
6. External Interfaces (Execution) *

Work products from suppliers, partners, or collaborators will meet the programs quality and
timeliness requirements.
low
rationale 6
description
2/5
12/9/2009
9. Facilities and Equipment (Execution) *

Facilities and equipment are sufficient to support the program.
low
rationale 9
description
10. Organization Conditions (Environment) *

Enterprise, organizational, and political conditions are facilitating completion of program activities.
low
rationale 10
description
12. Event Management (Resilience) *

The program has sufficient capacity and capability to identify and manage potential events and
changing circumstances.
low
rationale 12
description
3/5
12/9/2009
13. Requirements (Result) *

System requirements are well understood.
low
rationale 13
description
20. Certification and Accreditation (Result) *

The system will be appropriately certified and accredited for operational use.
low
rationale 20
description
questions
logic questions that you would like to do about this questionaire. e.g.: risk states possible states
4/5
12/9/2009
Submit
5/5

Gerenciamento de Riscos em Projetos

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

Gerenciamento de Riscos em Projetos

Enviado por

Direitos autorais:

Formatos disponíveis

PUC

Anlise de Riscos em Projetos: uma abordagem

PONTIFCIA UNIVERSIDADE CATLICA DO RIO DE JANEIRO

Monograas em Cincia da Computao, No. 18/10

Editor: Prof. Carlos Jos Pereira de Lucena

Anlise de Riscos em Projetos: uma abordagem por

Gerenciamento de risco uma disciplina de gerncia de projetos que possui

Mesmo com objetivos to nobres, esta a disciplina com

menor grau de maturidade nas empresas.

75% dos gerentes de projeto no praticam

qualquer forma detalhada de gerncia de riscos e entendem apenas vagamente os conceitos

Para auxiliar os gerentes

de projetos a analisar os fatores de risco em um projeto, proposto neste trabalho um

de Modelos, Reexo Computacional.

Abstract. Risk management is a discipline of project management that aims to identify,

analyze and handle project risks, to increase the probability of success.

Trabalho patrocinado pelo Ministrio de Cincia e Tecnologia da Presidncia da Repblica Federativa

do Brasil atravs da Bolsa de Doutorado CNPq 142620/2009-2.

Rosane Teles Lins Castilho

Lminas utilizadas para explicar a nova metodologia

de fatores de risco chave utilizada no experimento

artigos so bem diversos e vo de uma simples

minuto (Tiwana & Keil 2004), a

para criao de mtodos adaptados a cada

para avaliaes de projetos em um

analtico baseado em lgica, atravs da especicao formal

de um modelo para anlise de risco.

Para isso, apresentada a epistemologia utilizada

na construo desse modelo, que composta principalmente do conceito de risco, viso de

para a categorizao de fatores chave de risco criado por

A ferramenta utilizada para realizar essa tarefa chamada de

vericador de modelos. O usurio pode especicar assertivas lgicas e utilizar o vericador

Ao nal do experimento, avaliou-se a pontos fortes, fracos e possveis

melhorias. Quase todos os entrevistados disseram que utilizariam o mtodo proposto em

Para realizar anlise de risco de projetos, proposto um

2.1 Anlise de Risco

software aumenta de fato o sucesso dos projetos, Bakker

(Bakker et al. 2009) reali-

Considerando esta avaliao,

stakeholders ) no processo, conse-

risco que consideram a participao de diversas pessoas (

guiram aumentar a percepo de sucesso. Percepo de sucesso uma medida em que os

stakeholders ) nessa anlise aumenta a percepo de sucesso do

projeto como um todo.

& Keil 2004).

Modelos para moldar o raciocnio de avaliadores sobre a anlise de risco

frameworks analticos ou modelos de processo. Ambos so muito

estratgias que evitam o risco (prev alteraes no

um modelo para anlise de risco.

analtico atravs da especicao formal de

A seguir, apresentada a epistemologia utilizada na

construo desse modelo, que composta principalmente do conceito de risco, a viso de

um fator de risco especco.

a probabilidade de um evento relacionado ao fator de risco

a exposio de risco atribuda a

o impacto, ou magnitude do evento. Na teoria clssica, o impacto pode ser

trabalho, consideramos apenas impactos negativos, que representam ameaas a projetos.

mais importante do que

Por m, os gerentes tendem

Gerenciar riscos faz parte das funes do gerente de projeto.

estas adaptaes levam os gerentes a ignorarem um grande nmero de ameaas, mesmo

As categorias, bem como as relaes de inuncia

entre elas so apresentadas na Figura 1. As categorias so representadas pelas caixas, e as

Monograas em Cincia da Computao, No. 18/10

de Modelos, Reexo Computacional.

analtico baseado em lgica, atravs da especicao formal

vericador de modelos. O usurio pode especicar assertivas lgicas e utilizar o vericador

Ao nal do experimento, avaliou-se a pontos fortes, fracos e possveis

analtico atravs da especicao formal de

um fator de risco especco.

Por m, os gerentes tendem

As categorias, bem como as relaes de inuncia

Objectives ) pode exercer inuncia sobre fatores de risco das

2.2 Vericador de Modelos

para realizar essa vericao de modelos chamada de Vericador de Modelos.

A vericao de modelos, em que se verica automaticamente a

Symbolc Model Verier

(CTL) (Emerson 1990) para expressar as propriedades a serem vericadas.

O usurio pode especicar assertivas lgicas e utilizar o vericador de modelos para

realizada atravs da vericao de um modelo de inuncias de fatores chave de riscos

As setas indicam que a avaliao de um fator de risco inuencia na

Figura 3: Modelo do sistema de inuncia entre os fatores chave de risco

o modelo proposto suporta a ocorrncia de uma srie innita de eventos e de inuncias

Cada mdulo tambm dene as transies da avaliao do fator de risco,

de acordo com os eventos denidos pelo usurio.

liao de propriedades, como a avaliao de um fator de risco especco, est exemplicado

A maior diculdade encontrada foi a falta de

preenchida. Uma diculdade comparti-

nar essa diculdade foram apresentados exemplos de respostas. As respostas da

assim, o entrevistado se demonstrou conante na metodologia desenvolvida. Ele tambm

Foi apresentado um modelo para reexo computacional sobre

com unicao automatizada de eventos.