Você está na página 1de 37

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;
d5_exec_state = h : h;
d6_exec_state = h : h;
d9_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(d1.state) := m;
init(d2.state) := m;
--init(d2.state) := {l,m,h};
init(d12.state) := m;
init(d4.state) := l;
init(d5.state) := m;
init(d6.state) := m;
init(d9.state) := l;
init(d13.state) := m;
init(d20.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), `Automatic 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), `A 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), `Understanding software project risk: a cluster
analysis',

Inf. Manage. 42(1), 115125.

Warkentin, M., Moore, R. S., Bekkering, E. & Johnston, A. C. (2009), `Analysis 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

Experimento sobre Nova Metodologia

Experimento sobre Nova Metodologia para Anlise


de Riscos em Projetos
* 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

Powered by Google Docs


Report Abuse - Terms of Service - Additional Terms

google.com/formResponse?formkey

1/2

12/9/2009

Experimento sobre Nova Metodologia

Experimento sobre Nova Metodologia para Anlise


de Riscos em Projetos
* 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

Powered by Google Docs


Report Abuse - Terms of Service - Additional Terms

google.com/formResponse?formkey

1/1

12/9/2009

Experimento sobre Nova Metodologia

Experimento sobre Nova Metodologia para Anlise


de Riscos em Projetos
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

Powered by Google Docs


Report Abuse - Terms of Service - Additional Terms

google.com/formResponse?formkey

1/1

12/9/2009

Experimento sobre Nova Metodologia

Experimento sobre Nova Metodologia para Anlise


de Riscos em Projetos
* 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

Powered by Google Docs


Report Abuse - Terms of Service - Additional Terms

google.com/formResponse?formkey

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

Darlinton Carvallho @ LES/PUC-Rio

10/12/2009

Risk Analysis

Darlinton Carvallho @ LES/PUC-Rio

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

Darlinton Carvallho @ LES/PUC-Rio

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

Darlinton Carvallho @ LES/PUC-Rio

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

Darlinton Carvallho @ LES/PUC-Rio

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

Risk Analysis Theory

10/12/2009

Risk Analysis Theory

Darlinton Carvallho @ LES/PUC-Rio

Darlinton Carvallho @ LES/PUC-Rio

10

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

Darlinton Carvallho @ LES/PUC-Rio

11

10/12/2009

Darlinton Carvallho @ LES/PUC-Rio

12

Risk Analysis Theory

10/12/2009

Darlinton Carvallho @ LES/PUC-Rio

Risk Analysis Theory

13

Risk Analysis Theory

10/12/2009

Darlinton Carvallho @ LES/PUC-Rio

Darlinton Carvallho @ LES/PUC-Rio

Darlinton Carvallho @ LES/PUC-Rio

14

Risk Analysis Theory

15

Risk Analysis Theory

10/12/2009

10/12/2009

10/12/2009

Darlinton Carvallho @ LES/PUC-Rio

16

Risk Analysis Theory

17

10/12/2009

Darlinton Carvallho @ LES/PUC-Rio

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.

Darlinton Carvallho @ LES/PUC-Rio

10/12/2009

19

10/12/2009

Rationale

Rationale

event1

event4

event2

event5

event3

event6

Darlinton Carvallho @ LES/PUC-Rio

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
Darlinton Carvallho @ LES/PUC-Rio

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

Darlinton Carvallho @ LES/PUC-Rio

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

Darlinton Carvallho @ LES/PUC-Rio

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
describe the event which must happen to change the answer - mask: actual state; next state;
description

https://mail.google.com/mail/?ui=2&ik

1/5

12/9/2009

Gmail - Key drivers risk evaluation

4. Task Execution (Execution) *


Tasks and activities are performed effectively and efficiently.
low

rationale 4
describe the event which must happen to change the answer - mask: actual state; next state;
description

5. Coordination (Execution) *
Activities within each team and across teams are coordinated appropriately.
low

rationale 5
describe the event which must happen to change the answer - mask: actual state; next state;
description

6. External Interfaces (Execution) *


Work products from suppliers, partners, or collaborators will meet the programs quality and
timeliness requirements.
low

rationale 6
describe the event which must happen to change the answer - mask: actual state; next state;
description
https://mail.google.com/mail/?ui=2&ik

2/5

12/9/2009

Gmail - Key drivers risk evaluation

9. Facilities and Equipment (Execution) *


Facilities and equipment are sufficient to support the program.
low

rationale 9
describe the event which must happen to change the answer - mask: actual state; next state;
description

10. Organization Conditions (Environment) *


Enterprise, organizational, and political conditions are facilitating completion of program activities.
low

rationale 10
describe the event which must happen to change the answer - mask: actual state; next state;
description

12. Event Management (Resilience) *


The program has sufficient capacity and capability to identify and manage potential events and
changing circumstances.
low

rationale 12
describe the event which must happen to change the answer - mask: actual state; next state;
description
https://mail.google.com/mail/?ui=2&ik

3/5

12/9/2009

Gmail - Key drivers risk evaluation

13. Requirements (Result) *


System requirements are well understood.
low

rationale 13
describe the event which must happen to change the answer - mask: actual state; next state;
description

20. Certification and Accreditation (Result) *


The system will be appropriately certified and accredited for operational use.
low

rationale 20
describe the event which must happen to change the answer - mask: actual state; next state;
description

questions
logic questions that you would like to do about this questionaire. e.g.: risk states possible states

https://mail.google.com/mail/?ui=2&ik

4/5

12/9/2009

Gmail - Key drivers risk evaluation

Submit
Powered by Google Docs
Report Abuse - Terms of Service - Additional Terms

https://mail.google.com/mail/?ui=2&ik

5/5