UNIVERSIDADE FEDERAL DE PERNAMBUCO

GRADUAO EM CINCIA DA COMPUTAO

CENTRO DE INFORMTICA

2005.2

ANLISE E DEFINIO DE MTRICAS PARA O PROCESSO DE

GERNCIA DE RISCOS PARA PROJETOS DE SOFTWARE

TRABALHO DE GRADUAO
EM
ENGENHARIA DE SOFTWARE

Aluno Saulo Lopes da Silva Oliveira, slso@cin.ufpe.br.

Orientador Hermano Perrelli de Moura, hermano@cin.ufpe.br.
Co-
Co-Orientadora Cristine Martins Gomes de Gusmo, cmgg@cin.ufpe.br
(Doutoranda).

06 de fevereiro de 2006.
 UNIVERSIDADE FEDERAL DE PERNAMBUCO

GRADUAO EM CINCIA DA COMPUTAO

CENTRO DE INFORMTICA

2005.2

SAULO LOPES DA SILVA OLIVEIRA

ANLISE E DEFINIO DE MTRICAS PARA O PROCESSO DE

GERNCIA DE RISCOS PARA PROJETOS DE SOFTWARE.

ESTE TRABALHO FOI APRESENTADO GRADUAO EM CINCIA DA

COMPUTAO DO CENTRO DE INFORMTICA DA UNIVERSIDADE
FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENO
DO GRAU DE BACHAREL EM CINCIA DA COMPUTAO.

ORIENTADOR: PROF. HERMANO PERRELLI DE MOURA

CO-ORIENTADORA: CRISTINE MARTINS GOMES DE GUSMO

06 de Fevereiro de 2006.

2
 Dedico,

Aos meus pais

Severino e Lenize

A minha irm
Lorena

Saulo Lopes da Silva Oliveira, 2006.

Todos os direitos reservados.

3
 AGRADECIMENTOS

Aos meus pais, Severino e Lenize, minha irm Lorena, minha

namorada Sarah e todos meus familiares pelo amor, carinho, apoio,
compreenso e permanente incentivo.

aluna de doutorado Cristine Gusmo pela sua amizade, co-

orientao e constante disponibilidade no decorrer deste trabalho.

Ao professor Hermano Perrelli pela orientao e validao de cada

etapa deste trabalho.

A Mrcio e Marcelo, integrantes do grupo de pesquisa RISCTEC, do

qual fao parte, pelas sugestes dadas na elaborao deste trabalho.

E, finalmente, a todos aqueles que contriburam direta ou

indiretamente para a realizao deste trabalho.

Saulo Lopes da Silva Oliveira

4
 RESUMO

A gerncia de riscos responsvel por descobrir que fatores

podem levar um projeto ao fracasso, para que se possa definir aes que

evitem o acontecimento desses fatores. Cada vez mais, as organizaes

vm percebendo a importncia da gesto de riscos. Entretanto, h ainda

uma lacuna quanto a informaes sobre o processo, principalmente

quanto definio de mtricas. Baseado nisso, este trabalho busca tentar

reduzir a falta de informaes sobre mtricas atravs da demonstrao

das j existentes, alm da tentativa de proposio de novas mtricas, a

fim de tornar a forma de gerir riscos de uma organizao mais eficiente.

5
 SUMRIO
UMRIO

1. INTRODUO ............................................................................................................... 9
1.1. Contexto do Trabalho .................................................................................. 9
1.2. Motivao ....................................................................................................... 11
1.3. Objetivos ........................................................................................................ 13
1.3.1. Objetivos Especficos..............................................................................
Especficos 13
1.4. Estrutura do
do Trabalho ................................................................................ 14
2. ESTUDO SOBRE MTRICAS .......................................................................................... 16
2.1. Introduo Mtricas.................................................................................
Mtricas 16
2.1.1. Classificao das Mtricas .................................................................... 17
2.2. Mtricas de Tamanho de Software.........................................................
Software 18
2.2.1. Pontos de Funo .................................................................................... 19
2.2.2. Pontos de Casos de Uso ........................................................................ 22
2.2.2.1. Casos de Uso ........................................................................................ 22
2.2.2.2. Clculo de Pontos
Pontos de Casos de Uso .............................................. 24
2.3. Mtricas em Gerncia de Risco ............................................................... 28
2.3.1. Classificao dos Riscos........................................................................
Riscos 29
2.3.2. Atividades da Gerncia de Risco.........................................................
Risco 31
2.3.3. Mtricas ...................................................................................................... 34
3. PONTOS DE RISCO ..................................................................................................... 36
3.1. Introduo......................................................................................................
Introduo 36
3.2. Clculo de Pontos de Risco ...................................................................... 37
3.3. Clculo de Pontos de Risco No Ajustados.........................................
Ajustados 37
3.4. Fatores Caracterizadores do Projeto ..................................................... 41
3.5. Frmula de Ajuste ....................................................................................... 44
3.6. Aplicaes......................................................................................................
Aplicaes 45
4. VALIDAO ................................................................................................................ 47
4.1. mPrime............................................................................................................
mPrime 47
4.1.1. Principais Funcionalidades ................................................................... 49
4.2. Implementao da Mtrica ....................................................................... 52
5. CONCLUSO............................................................................................................... 55
5.1. Trabalhos Futuros ....................................................................................... 56

6
LISTA DE FIGURAS

Figura 1 Exemplo de um modelo de Caso de Uso............................... 23

Figura 2 Figura Representando o Ciclo da Gesto de Riscos ............... 34
Figura 3 Mapeamento entre Casos de Uso e Riscos ............................ 38
Figura 4 Viso Geral do mPrime integrado ao ms-project .................. 48
Figura 5 Viso do Checklist do mPrime .............................................. 50
Figura 6 Exemplo de Riscos Retornados pelos Componentes de
Inteligncia Artificial ............................................................................ 51
Figura 7 Viso de Parte da Caracterio de Projeto............................. 53
Figura 8 Viso da Exposio dos Riscos atravs das cores.................. 53
Figura 9 Resultado da mtrica de Pontos de Risco Implementado no
mPrime................................................................................................ 54

7
 LISTA DE QUADROS
Quadro 1 Resultado da Pesquisa do Relatrio CHAOS................................. 10
Quadro 2 Exemplo de Clculo dos Pontos de Funo No Ajustados .... 20
Quadro 3 Fatores Tcnicos ................................................................................... 20
Quadro 4 Classificao dos Atores do Sistema .............................................. 25
Quadro 5 Classificao dos Casos de Uso do Sistema................................. 25
Quadro 6 Fatores de Complexidade Tcnica do Sistema............................ 26
Quadro 7 Fatores de Complexidade Ambiental do Sistema....................... 27
Quadro 8 Classificao dos Riscos do Sistema .............................................. 40
Quadro 9 Exemplo de Escala de Impacto ......................................................... 40
Quadro 10 Fatores Caracterizadores do Projeto............................................ 41

8
 1. INTRODUO

1.1. Contexto do Trabalho

A presena de softwares na realizao de uma atividade, desde a

mais simples a mais complexa, se torna cada vez mais necessrio, como

afirma Pressman [PRESSMAN 1995]:

Softwares se tornaram uma fora fundamental. o motor que direciona

a tomada de decises em negcios. Serve como base para o investimento

cientfico moderno e para a soluo de problemas da engenharia.

Encontra-se em todas as reas de atividade: transportes, mdicos,

telecomunicaes, militar, processos industriais, entretenimento,

produtos de escritrio.

Uma outra maneira de perceber o aumento da necessidade de

softwares atualmente, o notvel crescimento da participao da

indstria de software na economia global, tornando-se verdadeiramente

um grande segmento. Por exemplo, estima-se que o mercado de

comunicao e software movimentou em torno de 320 bilhes de euros

[ANON 1998b]. Enquanto nos Estados Unidos, o setor de tecnologia da

informao responde por um quarto do crescimento economia [ANON

1998a].

9
 Entretanto, o desenvolvimento de software bastante complexo,

um dos motivos para que a indstria de software tenha dificuldades em

suprir a demanda existente. Os softwares so produzidos fora do custo

planejado, normalmente entregues com atraso e muitas vezes sem as

funcionalidades esperadas. Estas dificuldades enfrentadas pelas

organizaes caracterizam a chamada Crise do Software (Software

Crisis).

A Engenharia de Software responsvel por propor melhores

processos, ferramentas e tcnicas para um desenvolvimento mais

eficiente, uma rea de estudo bastante jovem, possui um pouco mais

de quarenta anos, no havendo ainda o acmulo necessrio de

informaes o desenvolvimento ter atingido a maturidade. E este pode

ser apontado como um dos principais motivos para a Crise do Software.

Para demonstrar o tamanho do impacto causado pela Crise do

Software, pode-se citar o relatrio CHAOS [STANDISH 1994], possui este

nome devido ao resultado apresentado. Segundo este relatrio, 31.1%

dos projetos de software falham, 52.7% so modificados e apenas 16.2%

so executados com sucesso.

Quadro 1 Resultado da Pesquisa do Relatrio CHAOS

Resultado do Projeto %

Falha 31.1

Modificado 52.7

Sucesso 16.2

10
 Portanto, o desafio da Engenharia de Software buscar alternativas

que visem solucionar estes problemas de custo, prazo e qualidade

esperada de um produto.

1.2. Motivao

A Engenharia de Software por ser uma rea de estudo to jovem

sofre pela falta de informaes acumuladas para validao de prticas

eficazes no desenvolvimento. Logo, uma das preocupaes atuais com

a coleta de dados, ou em outras palavras, mtricas.

Mtricas atuam tanto no nvel estratgico como ttico da

organizao. eficaz para a otimizao de processos, como tambm

auxiliam em decises da gerncia de um projeto de desenvolvimento de

software. Por exemplo, podem ser utilizadas para estimar o tamanho de

um projeto, ou medir a qualidade do mesmo.

Mesmo assim, poucas organizaes possuem um programa de

mtricas, ou mesmo as que o possuem no o fazem de maneira eficaz.

Isto ocorre principalmente por que um programa efetivo de mtricas

requer uma mudana na cultura organizacional que deve ser iniciada na

alta gerncia, alm disso, implementar mtricas um trabalho rduo e

em que os resultados apenas aparecem em longo prazo, diferente da

cultura atual de desenvolvimento de software, de resultados imediatos.

Outro campo de estudo que sofre com essa cultura de

desenvolvimento de software de resultados imediatos a Gerncia de

11
Riscos. Como se trata de uma rea bastante subjetiva, normalmente

acaba esquecida por no trazer nenhum aparente resultado prtico de

imediato. Outro problema encontrado que inibe a da gesto de riscos

que se trata de uma rea de estudo bastante recente em software que

alm de possuir pouca literatura, suas praticas no atingiram uma

maturidade a ponto de descobrir o que realmente funciona ou no.

Diferentemente, no mercado financeiro a Gesto de Riscos

amplamente usada, mais alm uma necessidade das empresas que

operam neste ramo. Alm disso, no mercado financeiro, riscos j

atingiram um bom nvel de maturidade com vasta literatura e prticas.

Resumidamente, esta maturidade s foi atingida quando comeou-se a

mensurar o que aparentemente totalmente subjetivo, incerto.

Portanto, este exemplo do mercado financeiro deve ser tomado

como incentivo para a aplicao da gesto de riscos em projetos de

software. H uma necessidade de mtricas para gesto de riscos, para

que a longo prazo a taxa de falha no desenvolvimento seja cada vez

menor.

Desta maneira, pode-se melhorar a tomada de decises por parte

da gerncia de projetos, descobrir quais prticas realmente funcionam

em gerncia de risco e dessa maneira otimizar todo o processo e

finalmente mensurar o benefcio para a organizao de aplicar uma

gesto de riscos eficiente, como motivao para um contnuo

aprimoramento.

12
 1.3. Objetivos

O objetivo deste trabalho reduzir a deficincia de informao

sobre a gesto de riscos atravs da proposio de mtricas. Ou seja,

tentar tornar a gesto de riscos algo menos subjetivo para o gerente de

projetos.

Essas mtricas que venham a ser definida devem ter como princpio

a literatura j existente, para que seja proposto algo vlido e que venha a

ser realmente aplicado em alguma organizao.

Finalmente, para que se atinja um resultado realmente concreto

necessrio validar as mtricas propostas, e isso ser feito atravs da

incorporao dessas mtricas na ferramenta mPRIME (Multiple Project

Risk Management).

O mPRIME uma ferramenta de gesto de riscos para ambientes

de mltiplos projetos de desenvolvimento de software, desenvolvida

como add-in para o Microsoft Project [LOPES e SOUTO 2005], produzida

no Centro de Informtica da Universidade Federal de Pernambuco.

1.3.1. Objetivos Especficos

Para atender ao objetivo geral, alguns objetivos especficos devem ser

alcanados:

13
 Definir quais as principais deficincias da gesto de riscos, a fim de

se possuir alguma alternativas para definio de mtricas.

Investigar mtricas na literatura que possam servir como ponto de

partida para resolver algumas das deficincias descobertas no item

anterior.

Adequar as mtricas selecionadas no item anterior para o contexto

de gerenciamento de riscos.

Implementao dessas mtricas na ferramenta mPRIME, como

forma de validao do trabalho.

1.4. Estrutura
Estrutura do Trabalho

Alm deste captulo inicial que explanou sobre o contexto,

motivao e objetivos do trabalho, este composto por mais quatro

captulos:

O captulo 2 Estudo sobre Mtricas - faz uma discusso sobre

mtricas em engenharia de software, conceitua mtricas, as classificaes

existentes, tambm traz informaes sobre Anlise de Pontos por Caso

de Uso e mtricas existentes na Gerncia de Risco.

O captulo 3 Proposta de Trabalho - prope algumas novas

mtricas para o processo de gerenciamento de riscos e aborda como ser

realizado este trabalho.

O captulo 4 Resultados Obtidos - valida e mostra resultados

obtidos com as mtricas apresentadas no captulo anterior.

14
 O captulo 5 Consideraes Finais e Trabalhos Futuros - traz a

concluso do trabalho, ser realizado um resumo do trabalho e tambm

mostrando ainda os trabalhos relacionados com este e futuros trabalhos

que venham estender este.

15
 2. ESTUDO SOBRE MTRICAS

2.1. Introduo Mtricas

Uma diferena fundamental entre uma cincia bem desenvolvida

como fsica e alguma outra menos desenvolvida o grau em que as

coisas so medidas [ROBERTS 1979]. A Engenharia de Software no

diferente como afirma Pressman [PRESSMAN 1995], Mtricas so

fundamentais para qualquer engenharia, e engenharia de software no

uma exceo.

Essencialmente, mtricas de software tem haver com mensurar o

produto software e o processo pelo qual desenvolvido [MILLS ET AL

1988].

Mensurar pode ser aplicado em processo de software com a

inteno de melhor-lo continuamente, ou dentro de um projeto para

auxiliar as estimativas, o controle de qualidade, avaliar a produtividade e

controlar o projeto. Finalmente, medidas podem ser usadas pelos

engenheiros de software para ajudar a avaliar a qualidade tcnica dos

produtos e auxiliar em tomadas de decises tticas enquanto o projeto

procede [PRESSMAN 1995]

16
 Apesar de todos os fatores positivos apresentados, mtricas ainda

no so amplamente usadas em organizaes que desenvolvem software.

Isto se deve principalmente por que os resultados de um programa de

mtricas aparece em longo prazo e muitas organizaes no esto

dispostas a esperar, principalmente quando envolve a aplicao de algum

capital. Alm do que, exigem uma grande mudana na cultura

organizacional para se iniciar a coleta de dados

Uma maneira de se amenizar a ocorrncia de falhas nos programas

de mtricas a utilizao de boas mtricas. Os pontos fortes de uma

mtrica so os seguintes:

Simples, de fcil definio.

Fcil obteno, ou seja, no vivel uma mtrica que necessite de

muito esforo ou capital para ser obtida.

Vlida, a mtrica deve conseguir medir o que se prope a medir.

2.1.1. Classificao das Mtricas

Mtricas de software podem ser categorizadas de diversas

maneiras. A primeira delas a diviso em mtricas de processo e de

produto. Mtricas de Produto so medidas do software em qualquer

estgio de desenvolvimento, desde a instalao ao sistema instalado.

Podem medir a complexidade de um design, o tamanho final de um

17
programa ou nmero de pginas de documentao produzidas. Mtricas

de Processo, ao contrrio, so medidas do processo de desenvolvimento

de software como tempo de desenvolvimento, tipo da metodologia

usada, ou a mdia de experincia de programao da equipe [apostila

sei].

Outra classificao a separao entre mtricas objetivas e

subjetivas. A primeira, independente de quem seja o observador, o

resultado vai ser o mesmo, por exemplo, Linhas de Cdigo. As subjetivas,

ao contrrio, o resultado pode variar de acordo com o observador, por

exemplo, a classificao de um ator de caso de uso em simples, mdio e

complexo, na mtrica de pontos por caso de uso.

Uma outra possibilidade de classificao de mtricas a separao

entre mtricas primitivas e computadorizadas. As primeiras, o resultado

da mtrica obtido diretamente, como Linhas de Cdigo. J as

computadorizadas exigem algum tipo de clculo para a obteno do

resultado, como por exemplo, a relao da quantidade de Linhas de

Cdigo por Pessoa a fim de mensurar a produtividade.

2.2. Mtricas de Tamanho de Software

Uma das principais aplicaes das mtricas de software a

mensurao da produtividade de uma organizao. A sada do

desenvolvimento de software como uma funo de esforo e tempo

aplicados [PRESSMAN 1995]. Este tipo de mtrica fundamental para o

18
sucesso de uma empresa de software, j que com essa dimenso

possvel aferir informaes como prever o tempo e custo de

desenvolvimento de um projeto, controlar as atividades que so

executadas no projeto.

Neste sentido, a comunidade de Engenharia de Software vem

propondo vrias possibilidades de mtricas, como: Linhas de Cdigo,

Anlise por Pontos de Funo e mais recentemente com a evoluo do

paradigma orientado a objeto, Anlise de Pontos por Caso de Uso.

2.2.1. Pontos de Funo

Este modelo foi proposto em 1979, por Albrecth, sua estratgia

para determinar o tamanho de um sistema de acordo com a quantidade

de requisitos funcionais, considerando a complexidade de cada um deles.

Para se determinar a quantidade de pontos de funo de um

projeto, primeiramente so calculados os Pontos de Funes No

Ajustados e em seguida aplicada uma frmula de ajuste, que

influenciada pelos Fatores Tcnicos do projeto, para finalmente

determinar o resultado.

Os Pontos de Funes No Ajustados so calculados a partir da

diviso do sistema em entrada externas, sadas externas e consultas

externas e cada entrada, sada ou consulta recebe um peso de acordo

com a sua complexidade. Em seguida, os recursos de dados so

classificados em Arquivos Lgicos Internos, pertencentes ao sistema, e

19
 Interfaces Externas, externos ao sistema, e, da mesma maneira, cada

Arquivos Lgicos Internos ou Interfaces Externas recebe um peso.

Finalmente, todos os pontos de cada classificao so somados, como o

exemplo mostrado no Quadro 2.

Quadro 2 Exemplo de Clculo dos Pontos de Funo No Ajustados

SIMPLES MDIO COMPLEXO
Classificao TOTAL
Nmero Peso Total Nmero Peso Total
Nmero Peso Total
5 5 25 5 7 35 68
Sadas 2 4 8
6 5 30 6 7 42 92
Consultas 5 4 20
Entradas 7 3 21 4 4 16 3 6 18 55

Arquivos Internos 4 7 28 1 10 10 8 15 120 158

Interfaces Externas 2 5 10 3 7 21 7 10 70 101

Total de Pontos de Funo No Ajustados 474

O prximo passo determinar a influncia dos Fatores Tcnicos

para se determinar o resultado da estimativa. Um pequeno questionrio

deve ser respondido com valores no intervalo de zero a cinco, em que

zero significa sem influncia no projeto e cinco, essencial. O questionrio

a ser respondido mostrado no Quadro 3.

Quadro 3 Fatores Tcnicos

Fatores Tcnicos

Comunicao de Dados Atualizao On-Line

Processamento de Dados Processamento Complexo

Distribudos

Desempenho Reusabilidade

20
 Utilizao de Equipamento Facilidade de Implantao

Volume de Transaes Facilidade Operacional

Entrada de Dados On-Line Mltiplos Locais e

Organizaes do Usurio

Usabilidade Manutenibilidade

Para a finalizao do clculo dos pontos, a frmula de ajuste que

se utiliza do valor dos Pontos de Funo No Ajustados e das respostas

do questionrio de Fatores Tcnicos do projeto.

A equao da formula de ajuste mostrada a seguir:

PF = PFNA [( 14
1
FTi 0.01 + 0.65 ) ]
Onde, PF a quantidade de pontos de funo, PFNA quantidade

de Pontos de Funo No Ajustados e FT a resposta de um dos fatores

tcnicos, ou seja todas as respostas do questionrio so somadas.

Entretanto, este modelo vem sendo criticado e alguma fraquezas

so notadas. Algumas desvantagens so que Pontos de Funo no

podem ser calculados automaticamente. No objetivo j que

necessrio fazer vrias decises subjetivas. Isto toda entrada, sada e

interface devem ser classificadas como simples, mdia ou complexa e os

Fatores Tcnicos tambm devem ser classificados por humanos tambm.

Alm de no levar em conta qualquer influncia de fatores associados a

recursos humanos [KARNER 1993].

21
 2.2.2. Pontos de Casos de Uso

2.2.2.1. Casos de Uso

Casos de Uso no foi definido de uma nica vez e sim passou por

um processo de evoluo, at se tornar da forma conhecida hoje. Este

processo iniciou-se no fim da dcada de 60, quando Ivar Jacobson

trabalhava para Ericsson e finalizou-se em 1994 com Alistair Cockburn.

Um caso de uso uma narrativa documentada que descreve uma

seqncia de eventos de um ator usando um sistema para completar um

processo [JACOBSON 1992]. Os atores so uma entidade externa ao

sistema que interage com os casos de uso, podem ser tanto pessoas

como outros sistemas.

A maneira mais comum de se representar casos de uso de um

sistema atravs de um modelo UML (Unified Modeling Language). Neste

modelo, todas as funcionalidades de um sistema so representadas

atravs dos vrios casos de uso onde tambm so mostradas as relaes

desses com seus respectivos atores. Um exemplo pode ser visto na

Figura 1, onde a representao grfica dos atores so pequenos bonecos

e a dos casos de uso so elipses.

22
 Figura 1 Exemplo de um modelo de Caso de Uso

Casos de uso tambm podem possuir relacionamentos uns com os

outros. Existem duas formas: incluso e extenso. A incluso de um caso

de uso em outro, significa que o ltimo deve incluir toda a funcionalidade

existente no primeiro. Na Figura 1, h um relacionamento de include. J

na relao de extenso, a diferena entre a incluso resume-se que na

incluso a relao de obrigao de incluir toda a funcionalidade,

enquanto na extenso, opcional.

23
 2.2.2.2. Clculo de Pontos de Casos de Uso

A tcnica de estimativa por Pontos de Caso de Uso foi proposta em

1993 por Gustav Karner, da Objectory (hoje, Rational Software). Ela

baseia-se em dois mtodos bastante utilizados - o mecanismo de Pontos

de Funo e uma metodologia conhecida como Mk II, uma adaptao da

tcnica de Pontos de Funo, bastante utilizada na Inglaterra [FREIRE

2006].

O processo de estimativa inicia-se medindo a funcionalidade do

sistema baseado no modelo de caso de uso em uma conta chamada

Pontos de Casos de Uso No Ajustados. Fatores Tcnicos envolvidos no

desenvolvimento destas funcionalidades so avaliados similarmente a

Pontos de Funo. O ltimo passo na estimativa no entretanto de

Pontos de Funes e um novo fator chamado Fatores de Ambiente

[KARNER 1993].

As principais vantagens dessa abordagem sobre pontos de funo

que primeiramente, leva em conta fatores humanos na sua estimativa e

outro ponto que o nvel de abstrao para se obter uma estimativa

muito maior.

O mtodo de clculo dos Pontos de Caso de Uso funciona da

seguinte maneira:

24
 Primeiramente, so classificados os atores do sistema em Simples,

Mdio e Complexo e atribuindo pesos 1, 2, 3 para cada classificao,

respectivamente. Esta classificao melhor visualisada no Quadro 4. Em

seguida obtido o Total de Pesos no Ajustados dos Atores somando os

produtos das quantidades de atores pelo seu respectivo peso.

Quadro 4 Classificao dos Atores do Sistema

Classificao dos Atores Peso

Simples 1
Mdio 2

Complexo 3

O segundo passo, a classificao dos casos de uso em Simples,

Mdio e Complexo e atribuindo pesos 1, 2, 3 para cada classificao

respectivamente. Existem vrias abordagens para determinar a

complexidade do caso de uso, duas delas so pelo nmero de transaes

envolvidas e outra pelo nmero de classes envolvidas. No final deste

passo, obtm-se o Total de Pesos no Ajustados dos Casos de Uso

somando os produtos das quantidades de casos de uso pelo seu

respectivo peso.

Quadro 5 Classificao dos Casos de Uso do Sistema

Classificao dos Atores Peso

Simples 1
Mdio 2

Complexo 3

25
 Pode-se ento obter o total de Pontos de Casos de Uso No

Ajustados atravs do somatrio do Total de Pesos No Ajustados dos

Atores e dos Casos de Uso.

O prximo passo determinar o Fator de Complexidade Tcnica.

Inicialmente, deve-se responder um pequeno questionrio com valores

de 0 a 5, onde 0 a 5, onde 0 sem influncia e 5 um fator

determinante. Aps determinar os valores de resposta dos questionrios,

estes devem ser multiplicados pelos seus respectivos pesos, como

mostrado no Quadro 6.

Quadro 6 Fatores de Complexidade Tcnica do Sistema

Fator Tcnico Peso

Sistema Distribudo 2
Desempenho da Aplicao 1

Eficincia do Usurio Final (On-Line) 1

Cdigo Reusvel em Outras Aplicaes 1

Complexidade de Processamento 1

Facilidade de Instalao 0.5

Facilidade de Uso 0.5

Portabilidade 2

Facilidade de Alteraes 1

Concorrncia 1

Segurana 1

Acesso Direto a Terceiros 1

Necessidade de Facilidades Especiais de Treinamento para 1

Usurios

O total deve ser somado e em seguida ser aplicada a seguinte

formula:

26
 FCT = 0 . 6 + (0 . 01 SFT )
Onde, FCT o fator de complexidade tcnica do projeto e SFT o

somatrio dos fator tcnico do projeto.

Em seguida, deve-se determinar o Fator de Complexidade

Ambiental, seu clculo semelhante ao Fator de Complexidade

Tcnica. Inicialmente, deve-se responder um pequeno questionrio com

valores de 0 a 5, onde 0 a 5, onde 0 sem influncia e 5 um fator

determinante. Aps determinar os valores de resposta dos questionrios,

estes devem ser multiplicados pelos seus respectivos pesos, como

mostrado no Quadro 7.

Quadro 7 Fatores de Complexidade Ambiental do Sistema

Fator Ambiental Peso

Familiaridade da Equipe com RUP 1.5

Experincia da Equipe 0.5

Experincia da Equipe em Orientao a Objeto 1

Capacidade dos Analistas da Equipe 0.5

Motivao 1

Estabilidade dos Requisitos 2

Estagirios ou Funcionrios em Tempo Parcial -1

Domnio da Tecnologia ou da Configurao do Ambiente -1.5

O total deve ser somado e em seguida ser aplicada a seguinte

formula:

27
 FCA = 1 . 4 + ( 0 . 03 SFA )

Onde, FCA o fator de complexidade ambiental do projeto e SFA

o somatrio do fator ambiental do projeto.

Finalmente, determinado a quantidade de Pontos de Casos de

Uso, atravs da equao:

PCUA = PCUNA FCT FCA

Onde, PCUA so os Pontos de Casos de Uso do Projeto; PCUNA,

Pontos de Casos de Uso No Ajustados; FCT, Fator de Complexidade

Tcnica e FCA, Fator de Complexidade Ambiental.

2.3. Mtricas em Gerncia

Gerncia de Risco

Das muitas disciplinas da engenharia, engenharia de software

mais suscetvel aos riscos que muitas outras reas. Embora projetos,

processo e requisitos de software evoluam, ainda sim a complexidade

dos produtos maior, e h um nmero maior de potenciais fatores de

risco que em muitas outras disciplinas [FAIRLEY 1989].

O termo gerenciamento de risco tem sido usado de duas maneiras

na literatura de gerncia de projetos. De um lado tem sido referida como

a disciplina que estuda como identificar, delegar e eliminar riscos

28
[BOEHM 1989]. Por outro lado referido como atividade ou processo que

tenta identificar o que pode ir errado em um projeto e praticar aes a

fim de evitar problemas no futuro [CHARETTE 1989; HALL 1998].

Atravs de perspectivas globais de negcios muitas organizaes

esto tornando-se cada vez mais dependentes do sucesso ou do fracasso

dos softwares que desenvolvem. Neste contexto, a gerncia de riscos no

apenas baseada em boas prticas para o desenvolvimento de software,

mas sim, boas prticas para gerir negcios [GUSMAO e MOURA 2005].

Um ponto fundamental a definio do que risco. Entretanto,

existem vrias definies e usos para o termo risco, conforme visto nas

subsees anteriores. Ainda que o conceito de risco esteja bastante

associado a perigos e impactos negativos, j vem sendo utilizado como

"exposio a conseqncias da incerteza", sendo cada vez mais aplicado

tanto no gerenciamento de perdas como no de ganhos potenciais.

2.3.1. Classificao dos Riscos

Vrias categorizaes de riscos so possveis, uma delas baseada

na rea do projeto que foi atingida.

Riscos de Projeto de Software.

Software Define os parmetros operacionais,

organizacionais e contratuais do desenvolvimento de software. O risco de

projeto primeiramente uma responsabilidade da gerncia. Risco de

projeto inclui limites de recursos, interfaces, relacionamentos com

fornecedores ou restries de contratos.

29
 Riscos de Processo de Software.
Software Neste tipo de risco esto includos

os problemas tcnicos e de gerncia. Nos procedimentos de gerncia

pode-se encontrar riscos em atividades como: planejamento, definio e

contratao de equipe de trabalho, garantia de segurana e configurao

de gerncia. Nos procedimentos tcnicos, podem-se encontrar riscos nas

atividades: anlise de requisitos, projeto, codificao e testes.

Riscos de Produto de Software.

Software Contm as caractersticas

intermedirias e finais do produto. Estes tipos de riscos tm origens nos

requisitos de estabilidade do produto, performance, complexidade de

codificao e especificao de testes.

Uma outra abordagem foi proposta pelo SEI (Software Engineering

Institute), a sua taxonomia de riscos [CARR ET AL. 1993] sugeriu

classificar os riscos em trs categorias: Engenharia do Produto, Ambiente

de Desenvolvimento e Restries do Produto.

Engenharia de Produto composta pelas atividades da Engenharia

de Sistema e da Engenharia de Software envolvidas na criao de um

sistema que satisfaa requisitos especficos e expectativas do cliente. As

atividades incluem a anlise e especificao dos requisitos de sistema e

de software; a modelagem de software e implementao; a integrao de

componentes de hardware e de software; e os testes de software e

sistema.

Ambiente de Desenvolvimento enderea o ambiente do projeto

em desenvolvimento e o processo utilizado. Incluem processo de

30
desenvolvimento e sistema, mtodos de gerenciamento e ambiente de

trabalho.

Restries de Programa faz referncia aos fatores externos ao

projeto. Fatores que normalmente esto fora do controle do projeto e

mesmo assim influenciam o sucesso ou constituem fonte de riscos

substanciais.

Embora estas atividades sejam tipicamente realizadas na fase de

planejamento do projeto, ao longo do projeto sero identificados novos

riscos no identificados anteriormente. Esses novos riscos devem ser

tratados da mesma forma, isto , uma vez identificados, sero analisados

e deve ser feito o planejamento necessrio. Novamente, isto supe uma

poltica de ampla comunicao entre todas as pessoas que tm algum

tipo de relao com o projeto.

2.3.2. Atividades da Gerncia de Risco

Diferentemente da definio de riscos em software, as atividades

que devem ser executadas para uma gesto de riscos eficiente parecem

j ter entrado em um consenso, no s na literatura, como guias e

modelos de qualidade existentes.

As atividades so as seguintes:

Planejar a Gerncia de Risco. Esta atividade tem a finalidade de

definir a estratgia da gesto de riscos, dos recursos necessrios para a

31
realizao do processo e por fim, da efetivao das aes consideradas

necessrias no plano de Gerncia de Riscos.

Identificar Riscos.
Riscos A identificao dos riscos a atividade inicial de

um projeto de software. Objetiva um levantamento preliminar de todas as

possibilidades de riscos existentes no projeto. O aspecto mais importante

da atividade de identificao de riscos compor uma documentao

formalizando os dados coletados.

Analisar Riscos.
Riscos Nesta atividade so caracterizados os aspectos

mais importantes de cada risco, com a finalidade de explorar as melhores

estratgias de mitigao (eliminao). De forma geral, os riscos so

categorizados e priorizados, segundo algum critrio especfico

estabelecido, para tornar a gerncia concentrada nos riscos considerados

prioritrios.

Planejar Respostas aos Riscos

Riscos.
iscos O planejamento uma atividade, da

Gerncia de Riscos, que envolve, em geral, a determinao dos riscos a

serem gerenciados, dos planos de ao para os riscos sob controle da

gerncia e dos planos de contingncia para os riscos que se encontram

alm das capacidades de mitigao.

Monitorar Riscos.
Riscos O monitoramento dos riscos a observao da

efetividade dos planos de ao na execuo do desenvolvimento do

projeto de software. O objetivo prover informaes precisas e contnuas

para habilitar a gerncia de risco a atuar de forma preventiva e no

reativa aos eventos adversos. Como benefcio desta atividade, tem-se a

melhor compreenso do andamento do projeto por parte dos membros

32
das equipes de desenvolvimento. Cada risco monitorado, possui um ciclo

de atualizao prprio. A freqncia de atualizao depende dos recursos

disponveis e da rapidez com que o produto se desenvolve.

Controlar Riscos.
Riscos A atividade de controle dos riscos avalia a

situao corrente para determinar eventuais desvios do planejado. O

controle dos riscos envolve alterao das estratgias de mitigao,

quando se fizer necessrio; utilizao de aes previamente planejadas

de contingncia; encerramento de trabalhos relacionados a um

determinado risco, quando este deixar de existir, entre outras. A

utilizao de cronogramas essencial para a atividade de controle na

Gerncia de Riscos, pois o controle explcito de tarefas de mitigao de

riscos facilita o acompanhamento do progresso e da eficcia destes

planos.

Comunicar os Riscos.
Riscos A comunicao entre as equipes e membros

do projeto de software um dos fatores mais importantes para a

realizao bem sucedida da gerncia de riscos.

Deve-se ressaltar que todas as atividades so baseadas e centradas

na comunicao, devendo ser realizadas de forma cclica e contnua

dentro do processo de Gerncia de Riscos utilizado.

33
 Identificar

Controlar Analisar

Comunicar

Monitorar Planejar

Figura 2 Figura Representando o Ciclo da Gesto de Riscos

2.3.3. Mtricas

Atualmente, ainda existe pouca informao na literatura de

Engenharia de Software sobre a Gerncia de Riscos e principalmente de

mtricas para esta gerncia. Diferentemente do mercado financeiro, onde

a Gerncia de Riscos j est consolidada e existem vrias mtricas e

indicadores que auxiliam o processo.

Dentre algumas mtricas que foram propostas para software, duas

merecem destaque, foram propostas por Boehm, so elas: Exposio do

Risco e Influncia da Reduo de Risco. Ambas so utilizadas na anlise

do risco e sua priorizao [MYERSON].

A Exposio do Risco definida como:

ER = PROB IMP
34
 Onde, ER a exposio ao risco, PROB probabilidade de

acontecimento e IMP o valor do impacto associado ao risco.

J a Influncia da Reduo de Risco definida como;

IRR = (REa REd ) / CRR

Onde, IRR a Influncia da Reduo de Risco, REa a Exposio do

Risco antes da aplicao de ao aos riscos, e REd a exposio depois

da aplicao das aes e CRR o custo da reduo da probabilidade do

risco.

Essa medida tem como principal papel medir a relao

custo/benefcio de se efetuar aes para diminuir chances de

acontecimento do problema.

35
 3. PONTOS DE RISCO

3.1. Introduo

Neste captulo ser apresentada a real motivao desse trabalho, a

definio de uma mtrica que venha auxiliar o processo de Gerncia de

Riscos em ambientes de desenvolvimento de software.

Decidiu-se que a mtrica deveria abordar o problema de definir

quantitativamente o nvel de risco de um projeto como um todo. Dessa

maneira, seria possvel comparar dois projetos e definir qual deles mais

arriscado.

A partir de ento, iniciou-se uma pesquisa dentro da literatura de

Engenharia de Software para analisar mtricas, a fim de selecionar

algumas que pudessem servir como ponto de partida para a prover as

informaes desejadas na mtrica proposta neste trabalho.

Percebeu-se ento, uma certa similaridade entre as mtricas

existentes para mensurar o tamanho do software e o que se deseja

prover nesta mtrica. Da mesma maneira deseja-se medir o tamanho, ou

melhor definindo, um nmero que signifique o nvel de risco do projeto

como um todo, a fim de se possuir uma estimativa de riscos do projeto e

36
tambm da produtividade, ou melhor, da eficcia da gesto de riscos de

uma organizao.

A pesquisa a partir de ento partiu para o foco de se selecionar

qual a melhor mtrica de estimativa existente para se fazer uma analogia

com a gesto de riscos. A resposta que se prope nesse trabalho

Pontos de Casos de Uso, essa escolha foi baseada por ser uma das

mtricas mais comuns para Projetos Orientados Objetos, na atualidade,

o que facilitaria o uso da mtrica aqui proposta e tambm pela

adequao que conseguimos ser mais intuitiva que em com outras

mtricas.

Devido a essa inspirao na mtrica de Pontos de Casos de Uso,

resolveu-se intitular a mtrica aqui proposta por Pontos de Risco.

3.2. Clculo de Pontos de Risco

A partir de ento, buscaram-se adequaes entre casos de uso

para riscos, mas que essas adequaes no fossem apenas intuitivas mas

tambm que realmente trouxessem alguma melhoria ao processo de

gesto de riscos, ou seja resultasse em algo positivo para a organizao

que a utilizar.

Como mostrado anteriormente na seo 2.2.2.2, o clculo de

Pontos de Casos de Uso de um projeto efetuado de acordo com o

seguinte procedimento: Primeiramente, so calculados os Pontos de

Casos de Uso No Ajustados e em seguida aplicada uma formula de

37
ajuste que influenciada pelos Fatores de Complexidade Tcnica e

Fatores de Complexidade Ambiental que atuam no projeto.

Na analogia aqui proposta, o procedimento de clculo do Pontos de

Risco idntico. Inicialmente, deve ser calculado os Pontos de Riscos No

Ajustados do projeto, da mesma maneira que em casos de uso, e o

resultado final retornado pela a aplicao de uma formula de ajuste que

no nosso caso influenciado pelo que foi nomeado Fatores

Caracterizadores do Projeto, que um agrupamento dos Fatores

Tcnicos e Ambientais do projeto, isto no significa uma perca de

preciso j que os Fatores Caracterizadores do Projeto, incluem tanto

questes tcnicas quanto de recursos humanos.

Figura 3 Mapeamento entre Casos de Uso e Riscos

38
 3.3. Clculo do Pontos de Risco No Ajustados

Em Pontos de Casos de Uso, o clculo do Pontos de Casos de Uso

No Ajustados feito atravs da soma do Total de Pesos dos Atores e de

Casos de Uso No Ajustados. Na abordagem proposta por esse trabalho,

os Pontos de Risco No Ajustados so definidos pela soma do Total de

Pesos dos Responsveis pelo Risco, mapeando a classificao de Atores,

juntamente com a soma do Total de Pesos de Riscos No Ajustados, que

mapeado ao Total de Pesos de Casos de Uso No Ajustados.

O Total de Pesos de Responsveis por Risco No Ajustado,

determinada pela a classificao dos responsveis de acordo com seu

grau de habilidade em controlar os riscos. Infelizmente, dentro deste

trabalho no foi possvel determinar uma classificao clara dos

responsveis, no houve como determinar exatamente a influncia dos

responsveis na probabilidade de ocorrncia de um risco, esse estudo

poder ser feito como trabalho futuro, como ser discutido mais a frente.

Devido a esse imprevisto, inicialmente, os Pontos de Risco No Ajustados

ser igual ao valor do Total de Pesos de Risco No Ajustados.

Para calcular o Total de Pesos de Riscos No Ajustados,

primeiramente, os riscos so classificados de acordo com sua exposio

em: Muito Baixo, Baixo, Mdio, Alto, Muito Alto e atribuindo pesos 1, 2,

3, 4, 5; respectivamente. Em seguida chega-se ao resultado final atravs

do somatrio dos produtos das quantidades de riscos pelo seu respectivo

peso. Isso melhor demonstrado no Quadro 8.

39
 Quadro 8 Classificao dos Riscos do Sistema

Classificao Descrio Peso

Muito Baixo Exposio maior que 0.0 e 1

menor que 0.2
Baixo Exposio maior que 0.2 e 2

menor que 0.4

Mdio Exposio maior que 0.4 e 3

menor que 0.6

Alto Exposio maior que 0.6 e 4

menor que 0.8

Muito Alto Exposio maior que 0.8 e 5

menor que 1.0

Essa classificao em cinco nveis e os valores dos pesos foi

inspirada na forma de determinao do impacto mais comumente usado

pela comunidade de Engenharia de Software. Normalmente, o impacto

definido estaticamente geralmente em trs ou cinco nveis e com uma

diferena de 20% entre cada nvel. Por exemplo, a escala de impacto

mostrada, abaixo:

Quadro 9 Exemplo de Escala de Impacto

Classificao Peso

Muito Baixo 0.2

Baixo 0.4

Mdio 0.6

Alto 0.8

Muito Alto 1.0

40
 3.4. Fatores Caracterizadores do Projeto
Projeto

Na abordagem proposta neste trabalho, os fatores tcnicos e

ambientais foram aglutinados em uma nica categoria que foi nomeada

Fatores Caracterizadores do Projeto, uma vez que contm questes

tcnicas e humanas.

Quadro 10 Fatores Caracterizadores do Projeto

Classificao Respostas Peso

Tamanho da Equipe 0= Muito pequena (1 a 6 1.75

pessoas)

1=Pequena (7 a 20 pessoas)

2=Mdia (21 a 50 pessoas)

3=Grande (51 a 100 pessoas)

4=Muito grande (mais de 100

pessoas)
Distribuio Geogrfica da Equipe 1.28
0= Mesma sala

1=Mesmo prdio, salas

diferentes

2=Mesma cidade, mesma

empresa, prdios diferentes

3=Mesma cidade, empresas

diferentes
4=Cidades diferentes

Experincia da Equipe no Processo (em mdia) 1.13

0= Nenhum projeto

1=1 projeto

2=2 a 3 projetos

3=4 a 5 projetos
4=Mais de 5 projetos

Experincia da Equipe na Aplicao 1.20

0= Nenhum projeto

1=1 projeto

2=2 a 3 projetos

3=4 a 5 projetos

41
 4=Mais de 5 projetos
Experincia da Equipe com a tecnologia de 1.50
0= Nenhum projeto
desenvolvimento.
1=1 projeto

2=2 a 3 projetos

3=4 a 5 projetos

4=Mais de 5 projetos
Criticidade do Projeto (possvel conseqncia de 1.20
0= Perda de conforto
uma falha do sistema)
1=Prejuzos baixos, perdas
facilmente recuperveis

2=Prejuzos moderados,
perdas recuperveis

3=Prejuzos altos, perdas

irrecuperveis
4=Risco de Vida
Tamanho do Projeto (investimento no projeto) 0.68
0= Menos de R$ 50.000,00

1=Entre R$ 50.000,00 e R$
150.000,00

2=Entre R$ 150.000,00 e R$
1.000.000,00

3=Entre R$ 1.000.000,00 e R$
3.000.000,00
4=Mais de R$ 3.000.000,00

Prioridade (Qualidade x Tempo) 1.13

0= 10/90

1=30/70

2=50/50

3=70/30

4=90/10

O procedimento de clculo similar ao fator tcnico ou ambiental

na abordagem de caso de uso. Inicialmente, deve-se responder um

pequeno questionrio com valores de 0 a 4. Aps determinar os valores

de resposta dos questionrios, estes devem ser multiplicados pelos seus

respectivos pesos, como mostrado no quadro 10, o total deve ser

somado e em seguida ser aplicada a seguinte formula:

42
 FP = 1 . 05 + (0 . 015 SFP )
Onde, FP o Fator Caracterizador do Projeto e SFP somatrio

retornado a partir da resposta do questionrio.

O questionrio proposto foi retirado de um modelo de

caracterizao de projeto proposto por Coelho [COELHO 2003]. Este

composto por questes com cinco possveis respostas, por isso os

valores da resposta variam de zero a quatro, diferentemente de casos de

uso, entre zero e cinco. As respostas foram ordenadas de acordo com

elevao da criticidade, ou seja 0 o menor valor em criticidade e 4, o

valor mximo. Foram retiradas duas perguntas do modelo original, sobre

conograma e oramento, devido suas respostas serem subjetivas.

Os pesos propostos para cada questo foram definidos

empiricamente atravs de uma pesquisa com alunos da Qualiti que se

preparam para a certificao PMP (Project Manager Professional).

Resumidamente, a pesquisa consistiu de perguntar qual fatores

propostos pelo modelo de caracterizao do Projeto de Coelho [COELHO

2003] eram considerados mais crticos para a gerncia de riscos.

J a equao proposta para o clculo do fator caracterizador do

projeto, no possuiu nenhuma forma de validao para chegar a tal

resultado. Simplesmente, acho-se razovel que a influncia dos fatores

caracterizadores em um caso extremo, onde todos as questes obtiverem

43
respostas mximas em criticidade, poderia ser adicionado 50% mais

pontos ao resultado final da mtrica. preciso um estudo mais profundo

para a determinao dessa equao.

Um ponto crucial que deve ser considerado quando for proposta

uma nova equao que o Fator de Complexidade Tcnica deve ter seus

valores reduzidos gradativamente, caso o valor das probabilidades dos

riscos se encontrem muito altas. Uma vez que as probabilidades esto

muito altas, de certa maneira j h uma preocupao grande com os

riscos do projeto, ento no h motivo para acrescentar muitos mais

pontos aos projetos atravs dos fatores caracterizadores do projeto.

3.5. Frmula de Ajuste

Finalmente para se obter o resultado dos Pontos de Risco, similar

a Pontos Por Caso de Uso, utilizando se do resultado dos Pontos de Risco

No Ajustado e o valor dos Fatores Caracterizadores do Projeto, como na

equao:

PR = PRNA FCP

Onde, PR a quantidade de Pontos de Risco, PRNA so os Pontos

de Riscos No Ajustados e o FCP o Fator Caracterizador do Projeto.

44
 3.6. Aplicaes

Depois de demonstrado o procedimento de clculo, necessrio

mostrar as aplicaes que esta mtrica pode ter dentro de uma

organizao desenvolvedora de software.

A primeira aplicao, diz respeito a viabilidade de um projeto de

software. Se uma organizao possui o histrico da quantidade de Pontos

de Riscos dos projetos, ento possvel determinar um limite de pontos

de risco por projeto que organizao suporta. Alm de que caso seja

vivel, possvel ter uma previso de quanto atraso e custo ocorrer

devido a ocorrncia de problemas.

Uma segunda aplicao, possvel se determinar a eficincia da

gesto de riscos da organizao. Se a organizao mantiver um histrico

da variao dos Pontos de Risco de um projeto, antes e depois das

aplicaes de aes que visam reduzir a ocorrncia possvel definir uma

relao entre Pontos de Risco por Ao aplicada, ou por unidade

monetria do custo da aplicao das aes. Para tal, basta adaptar a

mtrica Influncia da Reduo de Risco, vista na seo 2.3.3, substituindo

a exposio pela aplicao de Pontos de Risco antes e depois das aes

da gesto de riscos.

Uma outra possibilidade, que em organizaes que executam

projetos paralelamente, possvel estabelecer um ranking de projetos de

45
acordo com riscos, utilizam-se da quantidade pontos de risco do projeto,

assim percebe-se quais projetos precisam de uma maior ateno.

Uma outra abordagem, em vez de ver os riscos de um projeto

como todo, calcular os pontos de risco de acordo com alguma

classificao, assim possvel perceber a quantidade de pontos que

provem de cada rea de projeto auxiliando na anlise de riscos. Por

exemplo, pode se calcular os pontos de um projeto de acordo com a

classificao de riscos de Produto, Projeto e Negocio ou utilizando a

categorizao do SEI (Software Engineering Institute) [CARR ET AL 1993],

Engenharia de Produto, Restries de Programa e Ambiente de

Desenvolvimento.

46
 4. VALIDAO

Neste captulo, ser apresentada a ferramenta mPrime (Multiple

Project Risk Management), onde foi implementada a mtrica de Pontos de

Risco como forma de validar a mtrica proposta no captulo anterior.

4.1. mPrime

O mPRIME uma ferramenta de gesto de riscos para ambientes de

mltiplos projetos de desenvolvimento de software, desenvolvida como

add-in para o MS Project [LOPES e SOUTO 2005]. Sua definio e

implementao tiveram por base estudos acadmicos, em nvel de

doutorado, mestrado e graduao, do Centro de Informtica da

Universidade Federal de Pernambuco CIn-UFPE.

Seu desenvolvimento ocorreu durante a disciplina de Projeto de

Desenvolvimento do Centro de Informtica UFPE, no primeiro semestre

letivo do ano de 2005.

A ferramenta trabalha com a taxonomia de riscos definida pelo SEI

(Software Engineeria Institute) [CARR ET AL 1993]. Alm disso, aderente

ao processo do CMMI (Capability Maturity Model Integration), oferecendo

suporte a todos os processos da gesto de riscos: Planejar a Gerncia de

47
Riscos, Identificao de Riscos, Anlise dos Riscos, Planejar Respostas

aos Riscos, Monitoramento e Controle.

O mPRIME utiliza componentes de inteligncia artificial que

auxiliam na execuo das atividades de identificao, monitorao e

controle dos riscos [GUSMO ET AL 2005]. O principal diferencial est na

disponibilidade de funes que levantam situaes de riscos, atravs de

listas de verificao, facilitando a identificao de riscos de projetos e

entre projetos [FERNANDES e BUARQUE 2005].

Alm destes componentes inteligentes, a ferramenta mPRIME

disponibiliza um conjunto de tcnicas de levantamento de riscos

baseadas em modelos consolidados na rea de gesto [PMI 2000].

Figura 4 Viso Geral do mPrime integrado ao ms-project

48
 4.1.1. Principais Funcionalidades
Funcionalidades

Atualmente, a ferramenta mPRIME encontra-se em uma verso

inicial, oferecendo suporte principalmente atividade de identificao de

riscos que se encontra bem mais desenvolvida, possuindo

funcionalidades envolvendo tcnicas de levantamento de riscos e alguns

componentes de inteligncia artificial.

Com relao das tcnicas de identificao de riscos inseridas na

ferramenta, resumem-se Lista de Verificao que se apresenta de duas

formas.

A primeira se trata de uma lista de verificao (checklist), veja

figura 5, que foi definida pelo Instituto de Engenharia de Software

(Software Enginnering Institute - SEI) [CARR ET AL 1993], depois de

respondida retornada uma lista de possveis riscos ao projeto, veja

Figura 6.

49
 Figura 5 Viso do Checklist do mPrime

A segunda forma bastante semelhante primeira, na verdade

uma derivao da primeira forma da lista de verificao. O principal

motivo dessa nova forma se deu principalmente pelo fato da lista

definida pelo SEI ser bastante extensa possuindo 194 questes, ento de

acordo com a disponibilidade de tempo para o usurio responder todo o

questionrio poderia ser invivel. A soluo encontrada, que a segunda

forma da lista de verificao, foi aliar componentes de Inteligncia

Artificial Lista, de forma que fossem selecionadas apenas as questes

mais relevantes. Esta seleo est baseada na Estrutura Analtica do

Projeto EAP (Work Breakdown Structure WBS) que est sendo

desenvolvido, dessa forma apenas as perguntas mais relevantes seriam

50
retornadas ao usurio, reduzindo a quantidade de questes da lista de

verificao.

Figura 6 Exemplo de Riscos Retornados pelos Componentes de Inteligncia Artificial

Os componentes existentes, hoje, de inteligncia artificial oferecem

duas funcionalidades para a identificao de riscos da ferramenta

mPRIME. A primeira se trata da leitura da Estrutura Analtica do Projeto,

que depois de analisada pela ontologia retorna possveis riscos do

projeto ao usurio. Uma outra possibilidade a comparao de projetos,

ou seja, a ferramenta retorna projetos semelhantes ao que se encontra

em desenvolvimento, em seguida o usurio pode selecionar riscos para o

51
projeto em execuo a partir das informaes dos riscos de projetos

semelhantes.

4.2. Implementao da Mtrica

A implementao da mtrica teve, resumidamente, duas

preocupaes, a primeira delas foi estender o mPRIME para que possusse

as informaes necessrias para o clculo da mtrica e um segundo

passo, a partir dos dados obtidos no primeiro passo calcular para o

usurio o resultado da mtrica.

Prover informaes para o mPRIME foi facilitado, uma vez que os

Pontos de Riscos No Ajustados so classificados a partir da exposio

dos Riscos, dado j presente no mPRIME.

Tambm j se encontrava implementado no mPRIME, o

questionrio de Fatores Caracterizadores do Projeto, este j servia para a

realizao da uma funcionalidade de levantamento de riscos atravs da

comparao de projetos.

Nesse primeiro passo, foi necessrio fazer uma alterao na parte

de lgica da ferramenta para prover o armazenamento das exposies

dos riscos, para se ter o acompanhamento dos Pontos de Risco do

Projeto ao longo do tempo para se prover informaes sobre a eficincia

da gesto de riscos.

52
 Figura 7 Viso de Parte da Caracterio de Projeto

Figura 8 Viso da Exposio dos Riscos atravs das cores

53
 J a segunda parte da implementao envolveu mudanas na

camada lgica da aplicao, para interpretar os dados armazenados a fim

de retornar o resultado dos Pontos de Riscos. Em seguida foi implementa

a interface grfica mostrada a seguir com a contagem de Pontos No

Ajustados, por rea do projeto, o total de pontos de risco e a relao

pontos por ao de resposta aos riscos.

Figura 9 Resultado da mtrica de Pontos de Risco Implementado no mPrime

54
 5. CONCLUSO

A gerncia de riscos vem ganhando cada vez mais espao dentro

das organizaes. Entretanto, por se tratar de uma gerncia muito

subjetiva, vital a definio de mtricas para auxiliar no processo.

Como a gesto de riscos bastante recente no desenvolvimento de

software existem poucas definies sobre mtricas, deixando uma lacuna

que muitas vezes pode ser determinante para o fracasso da gerncia de

riscos ou mesmo de um projeto.

Ento na tentativa de diminuir essa falta de mtricas, este trabalho

props uma mtrica para o processo de gerncia de riscos. Este trabalho

procurou definir uma maneira de como quantificar todo risco de um

projeto atravs de um nico valor, desta maneira o nvel de riscos entre

projetos podem ser comparados facilmente.

Logo, foi proposta a Mtrica de Pontos de Risco que teve como

ponto de partida e inspirao a mtrica de Pontos de Casos de Uso,

largamente usada em projetos orientados a objetos.

Finalmente, como forma de validao da mtrica, esta foi

implementada na ferramenta de gerenciamento de riscos, mPRIME.

55
 5.1. Trabalhos Futuros

Existem vrias possibilidades de trabalhos futuros a partir desse

trabalho. A primeira e mais importante aplicao da mtrica proposta

em um projeto real para se avaliar a efetividade dela. Isto se torna

bastante facilitado por j se encontrar implementado em uma ferramenta

de gerenciamento de riscos.

Outra possibilidade de trabalho determinar a influncia no valor

dos Pontos de Riscos No Ajustados dos Responsveis pelos Riscos, ou

seja, definir uma classificao e pesos que reflitam a influncia desse

fator de risco, no grau de risco do projeto.

Finalmente, uma outra proposta a definio de uma nova equao

para o Fator Caracterizador do Projeto e ento valid-la em uma srie de

projetos.

56
REFERNCIAS BIBLIOGRFICAS
IBLIOGRFICAS

[ANON 1998a] Emerging Digital Economy, U.S. Department of Commerce.

[ANON 1998b] European Information Technology Observatory 98,

European Information Technology Observatory, ISBN 0-94-7486-2.

[BOEHM 1989] BOEHM, B. W., Tutorial: Software Risk Management.

Management. IEEE

Computer Society Press, 1989.

[CARR ET AL 1993] CARR, M. ET AL, Based Risk Identification. Tecnical

report CMU/SEI-
CMU/SEI-93-
93-TR-
TR-6. Software Engineering Institute, Carnegie

Mellon University. USA. 1993.

[CHARETTE 1989] CHARETTE, R. N., Software Engineering

Engineering Risk Analysis

and Management. McGraw-Hill, New York, 1989.

[COELHO 2003] COELHO, C., MAPS: UM MODELO DE ADAPTAO DE

PROCESSOS DE SOFTWARE. Centro de Informtica, Universidade Federal

de Pernambuco. Recife. Brasil, 2003.

57
[FAIRLEY 1989] FAIRLEY, R. E., Risk Management: The Key to Successful

Software Projects. in Proceedings of the 3rd IFAC/IFIP Workshop, F. J.

Mowle & P. F. Elzer, eds., Pergamon, Oxford, pp. 45-50, 1989.

[FERNANDES e BUARQUE 2005] FERNANDES, T. e BUARQUE, T., Manual do

Usurio verso 2.0. In Suppera Solutions Relatrio Tcnico, Centro de

Informtica, Universidade Federal de Pernambuco. Recife. Brasil, 2005.

[FREIRE 2006] FREIRE, H., Calculando Estimativas: O Mtodo de Pontos de

Casos de Uso. Consultada em 05/02/2006, disponvel em <http://www

.cnnt.com.br>.

[GUSMAO e MOURA 2005] GUSMO, C.M.G, MOURA, H. Managing Risk:

Methods for Software Systems Development, Gesto de Riscos para

Ambientes de Mltiplos Projetos de Software: Teoria e Prtica. In Escola

Regional de Minas Gerais IV ERI MG 2005. Instituto de Informtica

Pontifcia Universidade Catlica de Minas Gerais PUCMinas.

[GUSMO ET AL 2005] GUSMO, C.M.G, ET AL, Ontologia de Domnio de

Riscos. In Suppera Solutions Relatrio Tcnico, Centro de Informtica,

Universidade Federal de Pernambuco. Recife. Brasil, 2005.

[HALL 1998] HALL, E. M., Managing Risk: Methods for Software Systems

Development, Addison-Wesley Pub Co., Reading, 1998.

58
[JACOBSON 1992] JACOBSON, I., et. al, Object-
Object-Oriented Software

Engineering: A Use Case Driven

Driven Approach . Addison-Wesley, Estados

Unidos, 1992.

[KARNER 1993] KARNER, GUSTAV, Resource Estimation for Objectory

Projects. Objective Systems SF AB, 1993, consultada em 05/02/2006,

disponvel em <http://www .bfpug.com.br>.

[LOPES e SOUTO 2005] LOPES, S. e SOUTO, S. Documento de

especificao de projeto verso 1.0. In Suppera Solutions Relatrio

Tcnico, Centro de Informtica, Universidade Federal de Pernambuco.

Recife. Brasil, 2005.

[MILLS ET AL 1988] MILLS, E. ET AL, SEI Curriculum Module SEI-

SEI-CM-
CM-12-
12-

1.1. Software Engineering Institute, Carnegie Mellon University. USA.

1988.

[MYERSON] MYERSON, M., Risk Management

Management Processes for Software

Engineering Models.
Models. Artech House, 1996.

[PMI 2000] PROJECT MANAGEMENT INSTITUTE, A Guide to the Project

Management Body of Knowledge. 2000, consultada em 05/02/2006,

disponvel em <http://www.pmi.org/pmi/publictn/pmboktoc.htm>.

59
[PRESSMAN 1995] PRESSMAN, ROGER S., Software Engineering A

practitioners aproach. McGraw Hill, Estados Unidos, 4 Edio, 1995.

[ROBERTS 1979] ROBERTS, FRED S., Measurement Theory with

Applications to Decision making, Utility, and the Social Sciences.

Encyclopedia of Mathematics and its Applications Addison Wesley

Publishing Company, 1979.

[STANDISH 1994] The CHAOS Report. Standish Group, Estados Unidos,

1994, consultada em 05/02/2006, disponvel em

<http://www.standishgroup.com>.

60
61