Dissertacao Glauber PDF

FUNDAO EDSON QUEIROZ
UNIVERSIDADE DE FORTALEZA
CENTRO DE CINCIAS TECNOLGICAS
MESTRADO EM INFORMTICA APLICADA

GLUBER DE TARSO VIEIRA BEZERRA

UM PROCESSO PARA A GESTO DE INCIDENTES, APOIADO POR RBC E PLN
E ADERENTE AO CMMI PARASERVIOS (CMMI-SVC)

FORTALEZA
2014

GLUBER DE TARSO VIEIRA BEZERRA

UM PROCESSO PARA A GESTO DE INCIDENTES, APOIADO POR RBC E PLN
E ADERENTE AO CMMI PARASERVIOS (CMMI-SVC)

Dissertao submetida Coordenao do
Programa de Ps-Graduao em
Informtica Aplicada da Universidade de
Fortaleza, como requisito parcial para
obteno do Ttulo de Mestre em
Informtica Aplicada.

Orientador: Prof. Adriano Bessa
Albuquerque
Dr.
Coorientadora: Prof. Vldia Clia
Monteiro Pinheiro
Dr.

FORTALEZA
2014

___________________________________________________________________________

B574p Bezerra, Gluber de Tarso Vieira.
Um processo para a gesto de incidentes, apoiado por RBC e PLN e
aderente ao CMMI para servios (CMMI-SVC) / Gluber de Tarso Vieira
Bezerra. - 2014.
129 f.

Dissertao (mestrado) Universidade de Fortaleza, 2014.
Orientao: Prof. Dr. Adriano Bessa Albuquerque.
Coorientao: Profa. Dra. Vldia Clia Monteiro Pinheiro.

1. Tecnologia da informao. 2. Linguagem natural. 3. Inteligncia artificial.
I. Albuquerque, Adriano Bessa. II. Pinheiro, Vldia Clia Monteiro. III. Ttulo.

CDU 681.5

___________________________________________________________________________

A Deus

minha famlia

AGRADECIMENTOS

Agradeo a Deus por ter me dado fora em todos os momentos,
permitindo que eu conclusse esta etapa importante da minha vida.
minha me Francisca, pelo seu amor incondicional, pelos ensinamentos
de vida e por ter proporcionado todo o apoio necessrio durante esta e outras
jornadas ao longo desta vida.
Ao meu pai Joaquim, pelo seu incondicional apoio aos meus estudos,
sempre me motivando a estudar e ultrapassar barreiras, por ser o exemplo de
dedicao ao trabalho e por todo o carter de homem que herdei.
minha esposa Raphaele, por todo o amor e carinho, por ser uma
pessoa especial e sempre presente no meu cotidiano, por toda sua pacincia nos
meus momentos difceis e por acreditar incondicionalmente em mim.
Ao meu av materno Argemiro (in memoriam), pelo exemplo de amor e
famlia.
Aos meus outros avs, por todo o exemplo de unio conjugal e exemplo
de f a seguir.
A minha irm lida, pela pessoa maravilhosa que sempre foi.
Aos professores Adriano Bessa e Vldia Pinheiro, por terem aceitado
fazer parte deste trabalho, pela amizade, disponibilidade, pacincia, palavras de
incentivo nos momentos difceis e pelos ensinamentos acadmicos que muito
contriburam.
Aos professores Raimir e Mariela, por aceitarem contribuir com este
trabalho, participando da banca.
Aos demais professores do Mestrado em Informtica Aplicada (MIA),
pelos conhecimentos compartilhados durante as disciplinas.
Aos meus colegas de mestrado, pelos momentos de distrao e por
compartilharem o mesmo desafio.
Aos funcionrios do MIA, em especial Edmilson e Taciana, pelo apoio e
disponibilidade de sempre.
A todos os meus amigos e familiares, pela presena constante em minha
vida.

A educao a arma mais poderosa que voc
pode usar para mudar o mundo.
Nelson Mandela

RESUMO

A Governana de Tecnologia da Informao (TI) tem como objetivo ajudar a
melhorar o planejamento e execuo dos servios, diminuindo os problemas durante
a execuo das tarefas e elevando o nvel de maturidade da empresa. Diante dos
diversos problemas apresentados nas reas de TI, principalmente no que diz
respeito disponibilidade de servios, ser apresentado neste trabalho um processo
para Gesto de Incidentes aderente ao CMMI para Servios (CMMI-SVC), que
busca tratar e solucionar incidentes na rea de TI. O processo proposto apoiado
por tcnicas de Inteligncia Artificial - Raciocnio Baseado em Casos (RBC) e
Processamento de Linguagem Natural (PLN) - utilizadas na atividade de
recuperao de incidentes similares em uma base de conhecimento.
Especificamente, detalhamos atividades de planejamento para utilizao de RBC e
PLN na gesto de incidentes.A hiptese de pesquisa que a utilizao destas
tcnicas, em conjunto com um processo de gesto de incidentes, otimiza o tempo de
resoluo dos incidentes. Para validar a proposta, foi realizado um estudo de caso
em uma empresa.

Palavras-chave: Processo. Raciocnio baseado em casos. Processamento de
linguagem natural. Base de conhecimento.Reuso de experincias.Gerenciamento de
incidentes.

ABSTRACT

The Governance of Information Technology (IT) aims to help improve the planning
and implementation of services diminishes the problems during the execution of
tasks and by raising the level of maturity of the company. Given the many problems
presented in the areas of IT, particularly with regard to the availability of services, will
be presented in this paper a process for Incident Management adhering to CMMI for
Services (CMMI-SVC) which aims to treat and resolve incidents in IT. The proposed
process is supported by artificial intelligence techniques - Case Based Reasoning
(CBR) and Natural Language Processing (PLN) - used in the activity recovery of
similar incidents in a knowledge base. Specifically, we detail planning activities for
use in RBC and PLN management incidents. A research hypothesis is that the use of
these techniques, together with a process for managing incidents, optimizes the
resolution time of the incidents. To validate the proposal, a case study was
conducted in a company.

Keywords: Process. Case-based reasoning. Natural language processing.
Knowledge base. Experience reuse. Incident management

9

LISTA DE FIGURAS

Figura 1 - Publicaes ITIL V3 .......................................................................... 32
Figura 2 - Princpios do COBIT ........................................................................ 33
Figura 3 - Processos CMMI .............................................................................. 38
Figura 4 - Componentes do MPS .................................................................... 40
Figura 5 - Ciclo Bsico de um Sistema de RBC ............................................. 42
Figura 6 - Viso Geral dos Diferentes Nveis de Processamento Lingustico
em PLN ............................................................................................................... 48
Figura 7 - Arquitetura do Processo de Apoio ao Reuso de Experincias
na Engenharia de Requisitos (eRbc) .............................................................. 53
Figura 8 - Processo Proposto .......................................................................... 62
Figura 9 - Subprocesso Proposto ................................................................... 64
Figura 1A - Base de Incidentes ....................................................................... 129

10

LISTA DE GRFICO

Grfico 1 - Representao da Medida Global Nearest
Neighboure ....................................................................................................... 44

11

LISTA DE QUADROS

Quadro 1 - reas de Processo x Nvel de Maturidade ................................... 37
Quadro 2 - Comparao entre os Trabalhos .................................................. 57
Quadro 3 - Representao da Atividade 1 - Analisar Base de Dados,
Selecionar e Validaros Campos ..................................................................... 66
Quadro 4 - Representao da Atividade 3 - Modelar Caso ............................ 68
Quadro 5 - Medida de Desempenho F
1
-Score ............................................... 72
Quadro 6 - Representao da Atividade 4 - Definir ndices e Pesos ............. 73
Quadro 7 - Representao da Atividade 1.1 - Definir Terminologia do
Domnio .............................................................................................................. 75
Quadro 8 - Representao da Atividade 1.2 - Definir Abordagem
Similaridade Textual ......................................................................................... 79
Quadro 9 - Representao da Atividade 1.3 - Analisar e Validar Campo
Textual ................................................................................................................. 80
Quadro 10 - Representao da Atividade Registrar incidente .................. 82
Quadro 11 - Representao da Atividade Categorizar Incidente ............. 83
Quadro 12 - Representao da Atividade Priorizar Incidente ..................... 85
Quadro 13 - Semelhanas entre as Metodologias ........................................... 86
Quadro 14 - Representao da Atividade Analisar Incidente ................... 87
Quadro 15 - Representao das Atividades Resolver Incidente (Service Desk)
e Resolver Incidente (Nvel 2) ...................................................................... 88
Quadro 16 - Representao da Atividade Implementar Soluo de
Contorno ........................................................................................................... 89
Quadro 17 - Representao da Atividade Analisar Impactos e Causas
do Incidente .................................................................................................... 90
Quadro 18- Representao da Atividade Encerrar Incidente ................... 92
Quadro 19- Atividades do Processo .............................................................. 92
Quadro 20- Anlise da Base de Dados ........................................................... 97
Quadro 21- Modelagem do Caso ................................................................... 98
Quadro 22- ndices e Pesos ............................................................................. 99

12

Quadro 23- Terminologia do Domnio ............................................................. 100
Quadro 24- Abordagem de Similaridade Textual.......................................... 101
Quadro 25- Anlise do Campo Textual ............................................................ 102
Quadro 26- Registro do Incidente .................................................................. 103
Quadro 27- Categorizao do Incidente ........................................................ 104
Quadro 28- Priorizao do Incidente ............................................................. 105
Quadro 29- Anlise do Incidente ..................................................................... 106
Quadro 30- Resolver Incidente ........................................................................ 107
Quadro 31- Soluo de Contorno .................................................................... 108
Quadro 32- Anlise dos Impactos Causados pelo Incidente ........................ 109
Quadro 33- Encerramento do Incidente ........................................................ 110
Quadro 34- Resultado Compilado da Pesquisa ............................................ 111

13

LISTA DE TABELAS

Tabela 1 - Similaridade para Smbolos No-Ordenados ............................... 45
Tabela 2 - Casos Fictcios e seus Atributos ................................................... 69
Tabela 3 - Valores de Semelhanas do Atributo a1 ....................................... 70
Tabela 4 - Valores de Semelhanas do Atributo a2 ....................................... 70
Tabela 5 - Valores de Similaridades Semnticas entre Termos
Definidos Arbitrariamente ................................................................................ 77
Tabela 6 - Sistema de Priorizao de Incidentes ........................................... 84
Tabela 1A - Valores de Semelhanas do Atributo a1 (Campo) .................... 125
Tabela 2A - Valores de Semelhanas do Atributo a2 (Priorizao) ............ 125

14

SUMRIO

1 INTRODUO .................................................................................................. 16
1.1 Motivao ...................................................................................................... 16
1.2 Contexto ........................................................................................................ 17
1.3 Relevncia do Problema .............................................................................. 19
1.4 Objetivos ...................................................................................................... 19
1.5Metodologia de Trabalho .......................................................................... 21
1.6 Estrutura da Dissertao ............................................................................ 21
2 REFERENCIAL TERICO ............................................................................. 23
2.1 Gesto de Servios de TI ............................................................................ 23
2.2 Normas, Modelos de Maturidade e Guias ................................................ 28
2.2.1 ABNT NBR ISO/IEC 20000 ....................................................................... 28
2.2.2 ITIL V3........................................................................................................... 29
2.2.2.1 Estratgia de servio ............................................................................. 30
2.2.2.2 Desenho de servio ............................................................................... 30
2.2.2.3 Transio de servio ............................................................................. 30
2.2.2.4 Operao de servio .............................................................................. 31
2.2.2.5 Melhoria contnua de servio ................................................................ 31
2.2.3 COBIT ....................................................................................................... 32
2.2.4 CMMI-SVC .................................................................................................... 34
2.2.5 MPS.BR ....................................................................................................... 38
2.3 Raciocnio Baseado em Casos (RBC) Usando Processamento de
Linguagem Natural ............................................................................................ 40
2.3.1 Raciocnio Baseado em Casos (RBC) ...................................................... 40
2.3.2 Processamento de linguagem natural .................................................... 46
2.3.3 RBC usando PLN ...................................................................................... 52
2.4 Trabalhos Relacionados ............................................................................. 55
2.5 Discusso ..................................................................................................... 57
2.6 Concluso do Captulo ................................................................................ 58

15

3 UMA ABORDAGEM PARA IMPLEMENTAO DE UM PROCESSO
PARA GERENCIAMENTO DE INCIDENTES .................................................... 59
3.1 Introduo ..................................................................................................... 59
3.2 O Processo .................................................................................................... 60
3.2.1 Subprocesso: Planejar RBC e PLN ........................................................ 62
3.2.1.1 Analisar base de dados, selecionar e validar os campos ................... 65
3.2.1.2 Modelar caso ........................................................................................... 66
3.2.1.3 Definir ndices e pesos ........................................................................... 68
3.2.1.4 Definir terminologia do domnio ............................................................ 73
3.2.1.5 Definir abordagem similaridade textual ................................................ 75
3.2.1.6 Analisar e validar campo textual ........................................................... 79
3.2.1.7 Higienizar base de dados ....................................................................... 80
3.2.2 Atividade: registrar incidente .................................................................. 81
3.2.3 Atividade: categorizar incidente .............................................................. 82
3.2.4 Atividade: priorizar incidente................................................................... 84
3.2.5 Atividade: analisar incidente.................................................................... 85
3.2.6 Atividades: resolver incidente (service desk) e resolver incidente
(nvel 2) ............................................................................................................... 87
3.2.7 Atividade: implementar soluo de contorno........................................ 88
3.2.8 Atividade: analisar impactos e causas do incidente ............................. 89
3.2.9 Atividade: encerrar incidente ................................................................. 91
3.3 Aderncia das Atividades do Processo ..................................................... 92
3.4 Concluso do Captulo ................................................................................ 93
4 ESTUDO DE CASO .......................................................................................... 94
4.1 Metodologia de Avaliao ........................................................................... 94
4.2 Planejamento do Estudo de Caso ............................................................... 95
4.3 Execuo do Estudo de Caso ..................................................................... 96
4.3.1 Atividade planejar RBC e PLN ................................................................. 96
4.3.1.1 Tarefa: planejar RBC ............................................................................. 96
4.3.1.2 Tarefa: planejar PLN .............................................................................. 99
4.3.2 Atividade: registrar incidente .................................................................. 102

16

4.3.3 Atividade: categorizar incidente ............................................................. 103
4.3.4 Atividade: priorizar incidente .................................................................. 104
4.3.5 Atividade: analisar incidente ................................................................... 105
4.3.6 Atividade: resolver incidente (N1) ........................................................... 106
4.3.7 Atividade: resolver incidente (N2) ........................................................... 107
4.3.8 Atividade: implementar soluo de contorno ........................................ 108
4.3.9 Subprocesso: gerenciamento de problemas ......................................... 108
4.3.10 Atividade: analisar impacto e causas do incidente ............................. 108
4.3.11Atividade: encerrar incidente ................................................................. 109
4.4 Anlise dos Resultados ............................................................................... 110
4.5 Lies Aprendidas ....................................................................................... 112
4.6 Concluso do Captulo ............................................................................... 113
5 CONCLUSES E TRABALHOS FUTUROS .................................................. 114
5.1 Consideraes Finais ................................................................................... 114
5.2 Principais Contribuies .............................................................................. 115
5.3 Limitaes ...................................................................................................... 115
5.4 Trabalhos Futuros ......................................................................................... 116
REFERNCIAS ..................................................................................................... 117
APNDICE A - Plano de RBC .............................................................................. 123
APNDICE B - Plano de PLN ............................................................................... 127
APNDICEC - Base de Incidentes e Parecer ..................................................... 129

16

1 INTRODUO

Este captulo apresenta uma introduo para este trabalho, definindo a
motivao, o objetivo da dissertao, a metodologia e a sua organizao.

1.1 Motivao

difcil imaginar uma empresa organizao sem uma rea de Tecnologia da
Informao (TI) forte suficientemente para gerir dados e informaes essenciais para a
tomada de decises. Na maioria dos casos, a TI no vista como setor estratgico e
no recebe os investimentos necessrios para fornecer uma boa estrutura. Os gestores
de TI precisam de conhecimentos slidos para conseguir convencer a alta direo que
so necessrios investimentos para que a TI desenvolva bem o seu papel estratgico.
Para contornar esses problemas, surgem processos exclusivos para controle e
gerenciamento das atividades de TI, garantindo investimentos e melhorias nos
processos internos.
Estes processos so conhecidos como Governana de TI, do ingls IT
Governance e buscam melhorar o planejamento dos servios, diminuindo os problemas
durante a execuo de suas tarefas e elevando o nvel de maturidade da organizao.
Existem algumas metodologias voltadas para evoluo de processos e melhores
prticas na gesto de servios de TI, merecem destaque: ABNT NBR ISO/IEC 20000
ISO (2011); ITIL V3 (2011); IT Governance Institute (2007) e por fim o ABNT (2012) e
Costa (2012).
A principal motivao deste trabalho desenvolver uma abordagem de apoio
resoluo de incidentes. Optamos por desenvolver um processo tendo em vista a
necessidade de utilizarmos as melhores prticas de cada metodologia existente,
tornando nosso processo mais aderente s necessidades das organizaes. Outras
questes tambm devero ser respondidas e serviro de apoio motivao principal
deste trabalho:
17

Como definir um processo, baseado em tcnicas, capaz de prover um
servio de alta qualidade que seja contnuo e ininterrupto para os
clientes?
Quais os processos j foram definidos?
Quais tipos de melhorias esto sendo propostas?
Esse modelo foi proposto com base em outras metodologias
existentes?
Como foi realizada a abordagem?
Que tcnicas foram utilizadas durante a abordagem? As prticas
sugeridas pelo modelo so mensurveis?
Os insumos iniciais so suficientes para garantir a qualidade dos
servios?
As respostas das perguntas acima serviro de apoio na elaborao do
processo e da abordagem a ser utilizada durante a resoluo de um incidente.

1.2 Contexto

Atualmente podemos elencar diversos fatores de grande importncia para o
cotidiano das organizaes, entre os principais podemos citar: softwares, tecnologias,
pessoas e processos. Segundo Mafra (2004), os sistemas de software tm exercido um
papel essencial e crtico em nossa sociedade. Podemos afirmar que dependemos
fortemente do uso de tecnologias e softwares. No entanto, para obtermos resultados
que influenciem positivamente o uso de novas tecnologias, devemos nos basear em
estudos e abordagens baseadas em evidncias. De acordo com Kitchenham (2004
apud MAFRA; TRAVASSOS, 2006), a pesquisa em Medicina avanou
consideravelmente durante a ltima dcada, como resultado da adoo de abordagens
baseadas em evidncia.
Embora muitas organizaes tenham conhecimento da importncia da rea
de TI como setor estratgico, observamos uma relao de complementaridade com os
demais recursos presentes nos projetos das organizaes. (DORNELAS et al., 2014).
Geralmente esta relao dificulta a percepo da TI frente aos negcios da
18

organizaoe temos visto diversas organizaes preocupadas em manter seus servios
no ar, ou seja, servios disponveis para seus clientes, apenas com pequenos
investimentos em TI. Claramente essa no uma boa prtica, principalmente olhando
para o futuro destas organizaes. Nos dias de hoje, a TI necessitatrabalhar alinhada
com o planejamento estratgico, pois permitir um melhor acompanhamento dos
investimentos e do desempenho da rea, justificando facilmente possveis
investimentos necessrios para suprir lacunas no fornecimento de servios.
Diversas organizaes buscam melhorar o fornecimento dos seus servios
atravs da adoo de melhores prticas de normas, modelos de maturidade e/ou guias,
ampliando sua capacidade de atendimento e melhoria contnua nos processos. Neste
trabalho, propomos um processo paragesto de incidentes baseado em melhores
prticas difundidas no mercado. Dentre as diversas definies para incidentes, o ITIL
V3 define que um incidente Uma interrupo no planejada ou reduo na qualidade
de um servio de TI.As organizaes devem agir tambmvisando preveno de
incidentes, com o intuito de reduzir cada vez mais a possibilidade de problemas. Em
nosso processo temos um subprocesso Gerenciamento de Problemas que foca a
preveno e eliminao da causa raiz do incidente, enquanto o processo no geral visa a
restaurao do servio e gesto de incidentes.
Para melhor diferenciara preveno do tratamento de incidentes, utilizaremos
um exemplo. Considere a existncia de um vazamento em uma sala. A equipe
responsvel pela manuteno foi acionada e agiu colocando um vasilhame para conter
a gua para que os equipamentos e mveis no fossem danificados. At este
momento, apenas o incidente foi tratado. A equipe de manuteno deve identificar a
causa raiz do vazamento e corrigi-lo, tomando medidas para que o mesmo incidente
(vazamento na sala) no ocorra novamente.
O diferencial do processo em relao ao estado da arte o uso de tcnicas
da rea de Inteligncia Artificial (IA), especificamente Raciocnio Baseado em Casos
(RBC) e Processamento de Linguagem Natural (PLN),com o intuito deimpulsionar o
reuso de experincias na anlise e tratamento de incidentes. Especialmente, tcnicas
de PLN so aplicadas na fase de recuperao de casos em um sistema de RBC atravs
do uso de uma medida de similaridade semntica entre textos descritivos de incidentes.
19

Estas tcnicas consistem em buscar incidentes similares em uma base de
conhecimento, melhorando o tempo de atendimento do incidente.

1.3 Relevncia do Problema

Com base no que foi abordado na seo anterior e nos diversos problemas
apresentados nas reas de TI, principalmente no que diz respeito disponibilidade de
servios, ser elaborado neste trabalho um processo abordando o modelo Preveno e
Resoluo de Incidentes, do ingls Incident Resolution and Prevention (IRP) aderente
ao CMMI for Services (CMMI-SVC) e utilizando-se de um conjunto de melhores prticas
do ITIL V3, utilizando-se de tcnicas da rea de conhecimento de Inteligncia Artificial
(IA). Vale ressaltar que este processo tambm aderente ao processo Gerncia de
Incidentes (GIN) do Nvel G do modelo de maturidade brasileiro, Modelo de Referncia
MPS.BR de Servios (MR-MPS-SV), que busca tratar, prevenir e solucionar incidentes
na rea de TI.

1.4 Objetivos

O objetivo deste trabalho propor um processo para tratamento e soluo de
incidentes na rea de TI. O diferencial do processo, aqui proposto, o uso de tcnicas
RBC e PLN na recuperao de casos similares. Estas tcnicas sero utilizadas na
soluo do incidente, ou seja, existir uma base de conhecimento permitindo consultas
s solues j adotadas e insero de novas solues verificando a existncia de
algum caso similar, retornando uma provvel soluo. A vantagem de utilizao destas
tcnicas melhorar o tempo de resoluo do incidente, alm de buscar uma maior
assertividade na soluo, pois em casos onde incidentes similares j tenham ocorrido
outras vezes, a soluo dos mesmos est registrada na base e possibilitam o reuso de
conhecimento.
Decidimos trabalhar com o processo citado, considerando ser um processo
de suma importncia para as reas de TI que devem possuir prticas para prevenir e
solucionar incidentes de forma proativa.
20

Os objetivos especficos desse trabalho so:

Desenvolver um processo de gesto de incidentes de acordo com as
melhores prticas das metodologias, normas e modelos de maturidade
mais conceituados no mercado;
Definir uma abordagem de anlise e resoluo de incidentes,
utilizando RBC e PLN, com elaborao de procedimentos genricos
que podem ser utilizados por qualquer organizao que manifeste
interesse;
Aplicar a abordagem proposta em uma base de incidentes de uma
organizao e analisar os resultados obtidos.
21

1.5 Metodologia de Trabalho

A metodologia aplicada na realizao deste trabalho seguiu as seguintes
etapas:

Reviso bibliogrfica onde buscamos conhecer o referencial terico e
identificar na literatura processos existentes, abordagens propostas e resolues de
incidentes que usam as tcnicas RBC e PLN;
Planejamento e elaborao de um processo para resoluo de incidentes,
utilizando-se das melhores prticas das principais normas, modelos de maturidade e
guias existentes no mercado;
Procedimento descrevendo os passos necessrios para planejar e aplicar
RBC e PLN;
Planejamento e execuo de um estudo de caso em uma organizao
cearense, analisando os resultados obtidos;

1.6 Estrutura da Dissertao

Esta dissertao composta por cinco captulos. Este primeiro captulo
apresentou a motivao do nosso trabalho, contexto, objetivos da pesquisa, a
metodologia utilizada e a organizao do trabalho.
No captulo 2, Referencial Terico, apresentamos uma breve reviso
bibliogrfica sobre Gesto de Servios de TI; Normas, Modelos de Maturidade e Guias;
uma viso sobre RBC e PLN e trabalhos relacionados.
No captulo 3, apresentamos o processo e subprocesso propostos, suas
atividades, relacionamentos e passos para a concluso de cada etapa.
No captulo 4apresentamos o estudo de caso, onde aplicamos o processo
em uma organizao, com o intuito de avalia-lo e valid-lo.
22

Por fim, no captulo 5, Concluses e Trabalhos futuros, apresentamos as
consideraes finais e os resultados obtidos ao longo deste trabalho, suas principais
contribuies e limitaes, bem como tambm os prximos passos a serem realizados
para extenso desse trabalho.
23

2 REFERENCIAL TERICO

Este captulo apresenta uma breve reviso bibliogrfica, definindo conceitos,
metodologias e melhores prticas em Gesto de TI, RBC, PLN, bem como os trabalhos
relacionados.

2.1 Gesto de Servios de TI

Atualmente estamos presenciando um rpido crescimento da rea de TI e
com isso uma mudana contnua nos processos da organizao, que a cada dia que
passa devem se adequar as rotinas sistmicas. Na busca de aumentar sua capacidade
de negcio, vrias organizaes tm investido em novos softwares, como por exemplo,
ferramentas de Customer Relationship Management(CRM) ou Enterprise Resource
Planning (ERP) (GUO; WANG, 2009), mas de nada adianta este investimento se no
houver mudanas nos processos internos. Uma boa gesto de TI ajudar diretamente
nestas mudanas de processos, tendo em vista que impactaro diretamente no negcio
de cada rea.
Podemos citar como exemplo, a implantao de um sistema ERP, onde ser
necessrio adequar alguns processos internos das reas aos processos modelados na
ferramenta, ou seja, as principais ferramentas de mercado j possuem suas rotinas
adequadas visando o melhor funcionamento do processo e cabe a organizao buscar
adequar-se a estes processos. Estas adequaes so importantes para garantir que
no existiro gaps entre o processo interno e a ferramenta. Isto pode ser garantido
atravs de uma Gesto de TI apoiando fortemente as mudanas dos processos, este
apoio fundamental na explanao da rotina (ou funcionalidade) do sistema.
A falta de ferramentas ou melhores prticas de gesto de servios de TI na
maioria das vezes impacta diretamente no negcio da organizao. Para utilizar
eficazmente estas ferramentas, as organizaes devero possuir medies nos seus
processos internos e muitas delas citam que uma tarefa difcil de ser realizadapor
quatro motivos: (i) normalmente a rea de TI da organizao no possui uma estrutura
apropriada que permitir esta medio; (ii) as ferramentas utilizadas pela equipe no
24

realizam medies eficientes; (iii) os padres e frameworks de gerenciamento de
servios de TI no preveem exemplos prticos como por exemplo, medies de
processos de suporte; (iv) existem muitas opes de como realizar medies de
servios, ou seja, diferentes perspectivas.(LATHELA; JANTTI; KAUKOLA, 2010).
As metodologias voltadas para evoluo de processos e melhores prticas
na gesto de servios de TI so fortes aliadas do Gestor, pois atravs destas, ele ser
capaz de ampliar sua capacidade de gerenciamento, sendo capaz, por exemplo, de
tratar incidentes e procurar resolver, proativamente, os problemas.
Governana de TI surgiu pela primeira vez em 1993 como sendo um
subconjunto da disciplina de Governana Corporativa com foco em TI com ligaes
entre os objetivos estratgicos e a gesto de TI da organizao. Um tema caracterstico
de discusses de governana de TI que a capacidade de TI est diretamente
relacionada s escolhas de investimentos tomadas pela alta direo que tm
consequncias em longo prazo para os vrios envolvidos. (RADOVANOVIC et al.,
2011).
De acordo com Radovanovic et al. (2011) as metas da Governana de TI so
duas: (i) assegurar que os investimentos de TI esto gerando valor ao negcio; (ii)
mitigar os riscos associados com a TI. Alm de implementar uma estrutura
organizacional com papeis e responsabilidades bem definidas para o gerenciamento da
informao, dos processos de negcios, da infraestrutura, entre outros.
Existem diversas definies sobre Governana de TI, abaixo esto
apresentadas algumas delas:

O COBIT 4 define como sendo a responsabilidade dos executivos e
corpo de diretores garantirem que a TI consegue estender as
estratgias e os objetivos da organizao (IT GOVERNANCE
INSTITUTE, 20--);
De acordo com Webb; Pollard e Ridley (2006 apud RADOVANOVIC et
al., 2011), a governana de TI o alinhamento estratgico da TI com
o negcio da organizao de tal maneira que o negcio gere valor
atravs do desenvolvimento e controle eficiente da TI;
25

De Haes e Van Grembergen (2009 apud RADOVANOVIC et al., 2011)
definem como parte da governana corporativa, abordando definio e
implementao de processos, estruturas e mecanismos que permitiro
tanto o negcio quanto a TI executar suas responsabilidades criando
valor ao seu negcio.

Durante muito tempo diversos frameworks para apoio a Governana de TI
foram criados, por exemplo, Cobit 4 e ITIL V3. Todos com um propsito em comum,
gerenciar riscos de TI, buscando eliminar conflito de interesses.
Quando falamos de Governana de TI, pensamos logo em gerenciamento de
servios de TI, talvez pelo simples fato de sempre buscarmos eficincia e eficcia
dentro desta rea. Gerenciamento de Servios de TI (GSTI), do ingls Information
Technology Service Management (ITSM), tem a finalidade de atender s necessidades
de negcio da organizao. O gerenciamento de servios de TI feito atravs de uma
combinao adequada de pessoas, processos e tecnologia da informao. (ITIL, 2013).
Para que a Governana de TI seja efetiva, ou seja, para que possamos medir
se os investimentos de TI esto gerando valor, se os riscos esto sendo mitigados, se
existem melhoras perceptivas na qualidade dos servios ou ainda para evitarmos falhas
nas diversas reas de TI, torna-se necessrio um bom plano para gerenciamento de
incidentes.
Gerenciar incidentes tratar todos os eventos ocorridos, desde uma falha
no sistema at consultas reportadas pelos usurios (Service Desk). Um bom
gerenciamento de incidentes altamente visvel ao negcio, por esta razo este um
dos primeiros processos que as organizaes buscam implantar. A seguir esto listados
alguns dosvalores agregados ao negcio:

Capacidade de detectar e resolver incidentes: Resulta em um menor
tempo de inatividade para o negcio, que por sua vez, significa maior
disponibilidade do servio. Logo, a organizao capaz de explorar
ao mximo a funcionalidade do servio.
26

Possibilidade de alinhar a atividade de TI em tempo real: O
Gerenciamento de Incidentes permite identificar as prioridades de
negcios e, se for necessrio, pode alocar recursos dinamicamente.
Identificar melhorias para servios: Isto acontece como resultado do
entendimento do que constitui um incidente e tambm do contato da
equipe operacional com as atividades do negcio.
A central de atendimento (Service Desk) pode, durante o seu
tratamento de incidentes, identificar servios adicionais quesejam de
TI ou do prprio negcio. (ITIL, 2011).

Para que o gerenciamento de incidentes seja eficiente, o primeiro passo
identificar os incidentes para que medidas corretivas sejam tomadas. De acordo com o
CMMI-SVC, para identificar incidentes necessrio utilizar critrios que definiro se o
evento ou no um incidente. O uso destes critrios facilitar na resoluo do
incidente, permitindo categorizao, priorizao e alocao de recursos de forma rpida
e eficiente. O ITIL V3 define incidente como Uma interrupo no planejada ou
reduo na qualidade de um servio de TI, segundo a ABNT NBR ISO/IEC TR 20000
incidente Qualquer evento que no faz parte da operao padro de um servio e
que cause ou possa causar uma interrupo ou reduo, qualidade desse servio.
(ABNT, 2011).
importante diferenciar incidente de problema. Segundo o Modelo de
Referncia MPS.BR para Servios (MR-MPS-SV) um incidente uma interferncia
atual ou potencial na execuo de um servio. O ITIL V3 (2007) define incidente como
Uma interrupo no planejada ou reduo na qualidade de um servio de TI. De
acordo com a ABNT NBR ISO/IEC TR 20000 incidente Qualquer evento que no faz
parte da operao padro de um servio e que cause ou possa causar uma interrupo
ou reduo, a qualidade desse servio.(ABNT, 2011).
Problema definido pela ABNT NBR ISO/IEC TR 20000 como Causa
subjacente desconhecida de um ou mais incidentes. (ABNT, 2011).O ITIL V3 diz que
problema a causa desconhecida de um ou mais incidentes. Ainda no ITIL V3, vale
ressaltar que um incidente (mesmo que seja grave) no se transforma em problema, ou
27

seja, o Gerenciamento de Incidentes foca a restaurao do servio, enquanto o
Gerenciamento de Problemas foca a preveno e eliminao da causa raiz do
incidente.Assim, a partir do momento em que um ou mais incidentes tornam-se
reincidentes podemos concluir que temos um problema, visto que sua causa raiz
desconhecida.
Para tornar mais clara a definio de incidentes e a sua diferena de
problemas, podemos apresentar o seguinte exemplo: Durante o perodo do inverno um
vazamento foi identificado na sala dos servidores de uma organizao (isto seria um
incidente) e o departamento registrou o ocorrido junto ao setor responsvel.Como
soluo de contorno o setor responsvel coloca um vasilhame para conter a gua, mas
no identifica a origem do vazamento. Neste caso, se o incidente ocorrer outras vezes
podemos dizer que temos um problema, pois a causa do incidente no foi identificada e
tratada.
Nesta etapa interessante que tenhamos processos separados, um para
tratar incidente e outro para tratar problemas e que exista um relacionamento entre os
dois processos,que permitir identificar quantos e quais incidentes esto relacionados
aque problema, auxiliando na definio de prioridades para resoluo dos problemas.
Quando utilizamos processos separados, podemos encerrar um incidente e permanecer
com a verificao do problema, no caso de no existir esta separao o incidente no
pode ser encerrado at a concluso do problema, isto interfere diretamente na tomada
de deciso, pois no teremos ideia de quantos incidentes esto sendo tratados, visto
que em alguns casos podemos ter incidentes em aberto, mas a equipe pode estar
tratando problemas, sem levar em considerao ainda que o tempo mdio de
atendimento pode ficar bem distorcido do que foi gasto.
Diante de tudo isso, cabe a TI buscar metodologias para manter um alto nvel
de servios aos clientes, aliando planejamento e prticas proativas de trabalho,
aumentando o desempenho da organizao frente a existncia de uma grande
dependncia tecnolgica nos dias atuais.
28

2.2 Normas, Modelos de Maturidade e Guias

2.2.1 ABNT NBR ISO/IEC 20000

A ABNT NBR ISO/IEC 20000 tem a finalidade de promover e adotar uma
abordagem de processo integrado para entregar efetivamente servios gerenciados que
atendam aos requisitos de clientes e da organizao. (ISO, 2011).Esta Norma foi
elaborada pela Comisso de Estudo de Operao de Tecnologia da Informao, com
base na ISO/IEC 20000-1:2005 elaborada pelo Technical Committee Information
Technology (ISO/IEC JTC 1)
1
e substituda em 2011 pela publicao do mesmo ano,
que por sua vez j foi substituda pela publicao deste ano (2013). (ABNT, 2012). De
acordo com o Guia Geral MPS.BR de Software (SOFTEX.BR, 2012), a ABNT NBR
ISO/IEC 20000alinha-se com as melhores prticas do ITIL V3 para entrega e suporte
de servios. Esta Norma, sob o ttulo geral Tecnologia da Informao - Gerenciamento
de Servio formado por cinco partes descritas abaixo de acordo com a ABNT (2012).
Parte 1: Requisitos do sistema de gesto de servios. Esta parte possui
regras utilizadas no Sistema de Gesto de Servios (SGS). Conforme cita a prpria
ABNT:

Esta parte da ABNT NBR ISO/IEC 20000 uma norma de sistema de gesto de
servios (SGS). Ela especifica os requisitos para o provedor de servio planejar,
estabelecer, implementar, operar, monitorar, analisar criticamente, manter e
melhorar um SGS. Os requisitos incluem o desenho, transio, entrega e
melhoria dos servios para cumprir os requisitos do servio. (ABNT, 2011 ).

Parte 2: Cdigo de prtica. Esta parte possui o intuito de padronizar a
qualidade dos processos de gerenciamento de servios de TI.

Esta parte da ABNT NBR ISO/IEC 20000 representa um consenso do setor
sobre padres de qualidade em processos de gerenciamento de servios de TI.
Estes processos de servios propiciam o melhor servio possvel que vai ao
encontro das necessidades de negcios dos clientes, dentro de um nvel de
recursos acordado. (ABNT, 2011).

1
Existem diversos comits tcnicos. Mais informaes:ISO. Technical committees. [S.l.], [20--].
Disponvel em: <http://www.iso.org/iso/home/standards_development/list_of_iso_technical_committees>.
29

Parte 3: Direcionamento para a definio de escopo e aplicabilidade da
ABNT NBR ISO/IEC 20000-1. A parte 1 especfica as regras que devem ser utilizadas
pelo sistema de gesto de servios (SGS), enquanto a parte 3 tem a finalidade de
auxiliar nos preenchimentos dos requisitos da organizao de acordo com a parte 1.

A ABNT NBR ISO/IEC 20000 - 1 especfica um nmero de processos
relacionados de gerenciamento. Esta parte da ABNT ISO/IEC TR 20000 fornece
direcionamento e comentrios na definio de escopo e aplicabilidade da ABNT
NBR/IEC 20000 - 1 para habilitar o provedor de servios a preencher os
requisitos especificados na ABNT NBR ISO/IEC 20000 -1. (ABNT, 2011).

Parte 4: Modelo de Processo. Esta parte no foi publicada at a data de
defesa desta qualificao, mas tem o intuito de conceituar um modelo de referncia de
processo.
[...] ser conceituado o que um modelo de referncia de processo com
base na definio da norma - ABNT NBR ISO/IEC 15504 - Tecnologia da informao -
Avaliao de processo. (ABNT, 2011).
Parte 5: Exemplo de um plano de implementao da ABNT NBR ISO/IEC
20000-1. Tem a finalidade de auxiliar na implementao, por fases, das atividades.

Esta parte da ABNT ISO/IEC 20000 fornece orientaes sobre uma abordagem
por fases para implementar um SGS que cumpra com os requisitos
especificados na ABNT NBR ISO/IEC 20000 - 1. Abordagem por fases fornece
um quadro estruturado para acordar as prioridades e gerenciar as atividades de
implementao. (ABNT, 2011).

2.2.2 ITIL

O Information Technology Infrastructure Library (ITIL)(ITIL, 2011) foi
desenvolvido no final da dcada de 1980 pelo governo britnico e tem como foco
principal a gesto da infraestrutura de TI e a garantia da continuidade dos servios. De
acordo com a publicao de Introduo do ITIL V3 (2007), ele est dividido em cinco
publicaes, conforme descrito a seguir.
30

2.2.2.1 Estratgia de servio

De acordo com a publicao de Introduo do ITIL V3 (2007) a estratgia de
Servio o corao do servio. Esta publicao prev princpios e prticas comumente
utilizadas por organizaes com o intuito de prev que tipos de servios sero
necessrios pra atender a estratgia do negocio, como sero desenhados,
desenvolvidos e implementados. Nesta etapa as organizaes devem identificar metas
e objetivos a serem atingidos atravs dos servios, com o intuito de auxiliar durante a
escolha e seleo dos projetos que iro apoiar o desenvolvimento dos servios,
buscando sempre garantir que a organizao possa alinhar seus servios com suas
estratgias de negcios.

2.2.2.2 Desenho de servio

Atravs de princpios e mtodos, esta publicao mostra como desenhar e
desenvolver servios atravs das metas e objetivos definidos anteriormente, ou seja, a
transformao da Estratgia de Servio em servios propriamente ditos. Segundo a ITIL
V3 (2007), para que o um servio oferea valor para o negcio ele deve ser desenhado
refletindo as necessidades do negcio da organizao. Esta etapa prev no apenas o
desenho de novos servios, mas as mudanas e melhorias necessrias para que os
servios permaneam em alinhamento com a estratgia do negcio, mantendo o valor
dos servios.

2.2.2.3 Transio de servio

Esta publicao serve de guia para que os servios projetados ou que
sofreram mudanas possam entrar em operao de maneira segura, evitando riscos de
falhas e interrupes no planejadas. Nesta etapa um sistema de Gerenciamento do
Conhecimento do Servio pode ser utilizado com informaes sobre o servio, como
por exemplo, suas configuraes, capacidades, erros conhecidos, armazenamento,
entre outros, para que possa ser utilizado em caso de falhas ou manutenes.
31

2.2.2.4 Operao de servio

Esta publicao orienta como o gerenciamento da operao do servio no
dia a dia deve ser conduzida, de forma a garantir a eficincia e eficcia dos servios, ou
seja, monitorar e adequar as atividades buscando garantir que, o que foi planejado e
desenhado seja mantido. Alm disso, a publicao de Introduo do ITIL V3 (2007) cita
a necessidade de prover suporte operao para garantir a disponibilidade, demanda e
otimizao do servio, corrigindo falhas quando houver.

2.2.2.5 Melhoria contnua de servio

Nesta etapa a publicao orienta que os servios devem ser continuamente
analisados para garantir que os serviosesto entregando valor ao cliente, buscando
melhorar o design, a transio e a operao do servio, combinando princpios, prticas
e mtodos para melhorar o gerenciamento da qualidade dos servios. Nesta etapa
visamos identificar lacunas que precisam ser preenchidas e as melhorias podem ser
implementadas com apoio do mtodo PDCA (do ingls Plan-Do-Check-Act). (ITIL,
2007).
Todas as publicaes possuem a mesma estrutura (fundamentos, princpios,
ciclo de vida dos processos e atividades, implementao, entre outros) com o intuito de
auxiliarcada fase do modelo. A Figura 1 ilustra o ciclo entre as publicaes.
32

Figura 1 - Publicaes ITIL V3

Fonte: Adaptado de Von Wangenheim (2003).

2.2.3 COBIT

O Control Objectives for Informationand Related Technology (COBIT) (IT
GOVERNANCE INSTITUTE, 20--), criado pela Information Systems Auditand Control
Association (ISACA), um guia que estabelece mtodos documentados com foco em
boas prticas de TI para os gerentes e auditores, visando mais o controle do processo
ao invs da execuo. Atualmente o COBIT est na verso 5 e est dividido em 5
domnios e 37 processos. O COBIT 5 difere bem os processo de governana dos
processos de gesto. O domnio Evaluate, Directand Monitor (EDM) (Avaliar, dirigir e
acompanhar) possui 5 processos de governana, e os domnios Align, Planand
Organize (APO) - Alinhar, Planejar e organizar, Build, Acquire and Implement (BAI)-

Construir, Adquirir e Implementar
e Suportar, e Monitor, Evaluate
dividem os demais processos de gesto.
De acordo com
foco no negcio, no abrangendo apenas os servios de TI, mas servindo de orientao
para executivos e donos de processos nas tomadas de decises. Com o intuito de
prover informaes suficientes
alguns princpios, ver Figura

Fonte:Adaptado de

Ainda de acordo com o COBIT 4, os processos precisam de
mesmo define controle como:

Controle definido como polticas, procedimentos, prticas e estruturas
organizacionais criadas para prover uma razovel garantia de que os objetivos
de negcios sero atingidos e que eventos indesejveis sero
detectados e corrigidos
5. Separar
Governana de
Gerenciamento
nstruir, Adquirir e Implementar, Deliver, Service andSupport (DSS
Monitor, Evaluate and Assess (MEA) - Monitorar, Avaliar e Analisar
dividem os demais processos de gesto.
De acordo com o guia IT Governance Institute (20--), o COBIT foi criado com
prover informaes suficientes para auxiliar a organizao, o COBIT foi baseado em
alguns princpios, ver Figura 2.
Figura 2 - Princpios do COBIT

Adaptado de ISACA - Information Systems AuditandControlAssociation
Ainda de acordo com o COBIT 4, os processos precisam de
mesmo define controle como:
de negcios sero atingidos e que eventos indesejveis sero
detectados e corrigidos. (IT GOVERNANCE INSTITUTE, 20
Princpios
COBIT 5
1. Satisfazer as
necessidades
das partes
interessadas
2. Cobrir a
oraniza!o de
ponta"a"ponta
#. $p%icar &m
frame'or(
interado e
)nico
*. Possibi%itar
&ma vis!o
+o%stica
5. Separar
Governana de
Gerenciamento
33

DSS) - Entregar, Servir
Monitorar, Avaliar e Analisar
, o COBIT foi criado com
para auxiliar a organizao, o COBIT foi baseado em

Information Systems AuditandControlAssociation.
Ainda de acordo com o COBIT 4, os processos precisam de controle. O
de negcios sero atingidos e que eventos indesejveis sero evitados ou
(IT GOVERNANCE INSTITUTE, 20--, p. ).
oraniza!o de
ponta
34

2.2.4 CMMI-SVC

Segundo o SEI, Instituto de Engenharia de Software, do ingls Software
Engineering Institute (CARNEGEIN MELLON UNIVERSITY, 2011), Capability Maturity
Model Integration (CMMI) consiste em uma melhoria nos processos de uma
organizao, buscando identificar pontos fortes e fracos, de forma que os pontos fracos
sejam melhorados e transformados em fortes. O CMMI formado por modelos que
podem ser aplicados a equipes, grupos de trabalho, projetos, divises e organizaes
inteiras. Estes modelos so formados por conjuntos de melhores prticas e metas de
melhoria de processos que as organizaes utilizam para avaliar e melhorar a eficcia,
eficincia e qualidade de seus processos.
Todos os modelos CMMI so desenvolvidos a partir de um framework CMMI.
Este framework possui metas e prticas a serem utilizadas pelos modelos que
compartilham alguns processos, sendo que alguns podem ser ajustados de acordo com
a rea especfica. As reas de processos cobrem conceitos bsicos que so
fundamentais para o processo de melhoria em qualquer rea de interesse (aquisio,
desenvolvimento e/ou servios).
Alm do mais, todos os modelos devem estar associados aos nveis de
capacidade (representao contnua) e maturidade (representao por estgios) para
descrever um caminho evolutivo recomendado para uma organizao que quer
melhorar seus processos.
Os modelos CMMI so divididos em trs (03) categorias de componentes:
requeridos, esperados e informativos. Estas categorias abordam a rea de processo,
objetivos (genricos e especficos), prticas (genricas e especficas), entre outras.
Estes modelos so organizados em grupos, mais conhecidos por modelos
de processos, cabendo a organizao escolher qual modelo est mais alinhado ao seu
objetivo de negcio. Os modelos so:
CMMI para Aquisio (CMMI-ACQ): fornece orientao para as organizaes
que gerenciam uma cadeia de abastecimento para adquirir e integrar produtos e
servios;
35

CMMI para Desenvolvimento (CMMI-DEV): melhoria de processos em
organizaes que desenvolvem produtos e servios;
CMMI para Servios (CMMI-SVC): fornece orientao para as organizaes
que necessitam estabelecer, gerir e prestar servios que atenda mais as necessidades
dos clientes e usurios finais. Este modelo surgiu da necessidade de melhoria nos
processos de servios, visto que vrias organizaes estavam utilizando o CMMI-DEV
em combinao com o Information Technology Infrastructure Library (ITIL)(ITIL, 2011),
que trata de um conjunto de boas prticas para servios de TI (infraestrutura, operao
e servios).
O modelo CMMI-SVC, atualmente na verso 1.3 (SOFTWARE
ENGINEERING INSTITUTE, 2012), pode ser utilizado por qualquer organizao
envolvida com a prestao de servios, incluindo organizaes pblicas, tecnologia da
informao (TI), sade, financeiras e de transporte.
Este modelo busca expandir a atuao do CMMI cobrindo tambm os
processos de servios das organizaes, mais voltado para aquelas que realizam
gerenciamento de aplicaes, sustentao de servios, entre outros. Segundo o
SEI/CMMI um servio deve ser algo simples, intangvel e no armazenvel. (CARNIGIE
MELLON UNIVERSITY, 2011).
O CMMI-SVC possui prticas que atuam na gesto de processos, prestao
de servios e suporte, e processos de apoio. Esta rea baseia-se em conceitos e
prticas do CMMI e padres de outros servios e modelos, como o ITIL V3 (2011), ISO
(2011) e COBIT 4 (IT GOVERNANCE INSTITUTE, 20--). O CMMI-SVC mais
recomendado para organizaes que j utilizam o CMMI-DEV, no entanto o modelo
fornece alternativas para uma abordagem simplificada que pode ser mais apropriada
em determinados contextos.
Como citado anteriormente, os modelos CMMI possuem representaes por
estgios, o CMMI-SVC estabelece 5 nveis de maturidade pelos quais a organizao
dever evoluir a partir da melhoria continua dos seus processos. So eles:

Nvel 1 Inicial: A organizao possui processos executados de forma
no padronizada e sem nenhuma estrutura definida, dificultando a
36

identificao e resoluo de problemas. Organizaes nesse nvel tm
diversos problemas, como: (i) atraso nas entregas dos servios; (ii)
no tm conhecimento do prazo necessrio para entrega dos servios;
(iii) diversas reclamaes. Nestas organizaes tudo acontece de
forma desorganizada e, caso a organizao no busque mudanas,
estes problemas s tendem a aumentar.
Nvel 2 Gerenciado: As organizaes nesse nvel j conseguem ter
conhecimento dos prazos e j conseguem identificar melhorias e
repetir prticas.
Nvel 3 Definido: As organizaes j possuem processos
padronizados para seus servios e os contratos so cumpridos dentro
do prazo acordado. Possui tambm um planejamento para definir seus
servios.
Nvel 4 Gerenciado quantitativamente: Os processos da organizao
nesse nvel so gerenciados de forma quantitativa atravs de
estatsticas do processo. No caso do no cumprimento da entrega do
servio de acordo com o acordado, medidas so tomadas para
resolver os problemas e retornar o processo para o seu nvel de
desempenho correto.
Nvel 5 Em otimizao: Nesse nvel as organizaes j trabalham
evolues planejadas nos processos, buscando a melhoria continua
dos servios.

O Quadro 1 mostra as reas de processo e sua associao com os nveis de
maturidade.

Quadro 1 - reas de Processo x Nvel de Maturidade
Fonte: Adaptado pelo Autor a partir de Carnegie Mellon University (2011

Alguns dos processos citados no Quadro 1
modelos do CMMI (ACQ, DEV e SVC) e outros so especficos de cada modelo. A
Figura 3mostra esse compartilhamento de processos, bem como a rea de
conhecimento de cada processo e sua respectiva associao com os modelos do
CMMI.
,-ntrea de Servio .S/0
,Gerenciamento da Confi&ra!o .C10
,Garantia da 2&a%idade de Processo e Prod&to .PP2$0
,Gerenciamento de $cordo de 3ornecedores .S$10
,Gerenciamento de 4e5&isitos .4-210
,1edi!o e $n6%ise .1$0
,1onitoramento e Contro%e de Pro7eto
,P%ane7amento de Pro7eto .8P0
9ve% 2 " Gerenciado
,$n6%ise e 4eso%&!o de Ca&sas .C$40
,Contin&idade de Servios .SCO90
,/efini!o do Processo Oranizaciona% .OP/0
,/esenvo%vimento do Sistema de Servio .SS/0
,3oco no Processo Oranizaciona% .OP30
,Gerenciamento de Capacidade e /isponibi%idade .C$10
,Gerenciamento Interado de Pro7eto .I810
,Gerenciamento de 4iscos .4S:10
,Gerenciamento de Servio -strat;ico .STS10
,Preven!o e 4eso%&!o de Incidentes .I4P0
,Transi!o do Sistema de Servio .SST0
,Treinamento Oranizaciona% .OT0
9ve% # " /efinido
,/esempen+o do Processo Oranizaciona% .OPP0
,Gerenciamento 2&antitativo de Pro7eto .2810
9ve% * " Gerenciado 2&antitativamente
,$n6%ise e 4eso%&!o de Ca&sas .C$40
,Gerenciamento de Performance Oranizaciona% .OP10
9ve% 5 " Otimizado
reas de Processo x Nvel de Maturidade
Adaptado pelo Autor a partir de Carnegie Mellon University (2011).
Alguns dos processos citados no Quadro 1 so compartilhados entre os
mostra esse compartilhamento de processos, bem como a rea de
Gerenciamento da Confi&ra!o .C10
Garantia da 2&a%idade de Processo e Prod&to .PP2$0
Gerenciamento de $cordo de 3ornecedores .S$10
Gerenciamento de 4e5&isitos .4-210
1onitoramento e Contro%e de Pro7eto
P%ane7amento de Pro7eto .8P0
$n6%ise e 4eso%&!o de Ca&sas .C$40
Contin&idade de Servios .SCO90
/efini!o do Processo Oranizaciona% .OP/0
/esenvo%vimento do Sistema de Servio .SS/0
3oco no Processo Oranizaciona% .OP30
Gerenciamento de Capacidade e /isponibi%idade .C$10
Gerenciamento Interado de Pro7eto .I810
Gerenciamento de 4iscos .4S:10
Gerenciamento de Servio -strat;ico .STS10
Preven!o e 4eso%&!o de Incidentes .I4P0
Transi!o do Sistema de Servio .SST0
Treinamento Oranizaciona% .OT0
/esempen+o do Processo Oranizaciona% .OPP0
Gerenciamento 2&antitativo de Pro7eto .2810
Gerenciado 2&antitativamente
$n6%ise e 4eso%&!o de Ca&sas .C$40
Gerenciamento de Performance Oranizaciona% .OP10
37

so compartilhados entre os
mostra esse compartilhamento de processos, bem como a rea de

Figura 3 - Processos CMMI

Fonte: Blog da Teclgica (20--

Nosso trabalho tem foco no CMMI
(Preveno e Resoluo de Incidentes), portanto, no abordaremos os demais
processos.

2.2.5 MPS.BR

O Guia Melhoria de Processo do
2003 pela Associao para Promoo da Excelncia do
O objetivo do programa a melhoria do processo de software e servios, estando
dividido em duas metas: Tcnica e de Negcio. A meta Tcnica visa aprimorar o Guia,
Processos CMMI
--).
Nosso trabalho tem foco no CMMI-SVC, mais precisamente no processo IRP
Melhoria de Processo do Software Brasileiro (MPS.BR
2003 pela Associao para Promoo da Excelncia do Software
38

SVC, mais precisamente no processo IRP
MPS.BR), foi criado em
Software Brasileiro (SOFTEX).
39

credenciar instituies implementadoras e avaliadoras. J a meta de Negcio visa
disseminao e adoo do Guia para micro, pequenas e mdias empresas em todo o
Brasil.
Atualmente o MPS est dividido em quatro componentes: Modelo de
Referncia MPS para Software (MR-MPS-SW, mais conhecido por MR-MPS), Modelo
de Referncia MPS para Servios (MR-MPS-SV), Mtodo de Avaliao (MA-MPS) e
Modelo de Negcio (MN-MPS). Estes modelos so compostos por documentos em
formato de Guias (veja Figura 4). So elas:

Guia Geral MPS de Software: contm a descrio geral do modelo MPS
e detalha o Modelo de Referncia MPS para Software (MR-MPS-SW);
Guia Geral MPS de Servios: contm a descrio geral do modelo MPS
e detalha o Modelo de Referncia MPS para Servios (MR-MPS-SV);
Guia de Aquisio: descreve um processo de aquisio de software e
servios correlatos;
Guia de Avaliao: descreve o processo e o mtodo de avaliao MA-
MPS;
Guia de Implementao: conjunto de documentos que fornecem
orientaes para implementao dos modelos.

Como nosso trabalho possui foco principal em servios, abordaremos apenas
o Modelo MPS de Servio (MR-MPS-SV). O modelo MR-MPS-SV utiliza os conceitos
presentes no MR-MPS-SW, ou seja, est dividido em Nveis de Maturidade (7 nveis, de
A a G), Resultados de Processos (REPs), Atributos de Processos (APs) e Resultados
de Atributos de Processos (RAPs), sempre fazendo uso dos mesmos processos, sendo
quealguns foram criados, excludos, mantidos ou adaptados. Os REPs, APs e RAPs
so utilizados para medir a capacidade do processo, ou seja, saber se o propsito foi
atingido.

40

Figura 4 - Componentes do MPS

Fonte: Costa (2012).

2.3 Raciocnio Baseado em Casos (RBC)Usando Processamento de Linguagem
Natural

2.3.1 Raciocnio Baseado em Casos (RBC)

Raciocnio Baseado em Casos (RBC) uma das tcnicas da rea de
Inteligncia Artificial (IA) que tem como motivao e vantagem o reuso de experincias.
De acordo com Carvalho (2012aapud VON WANGEHHEIM; VON WANGEHHEIM,
2003), RBC resolve problemas ao recuperar e adaptar experincias passadas
chamadas casos armazenadas em uma base.
Diversos sistemas, em diferentes reas de conhecimento, tais como
engenharia, direito, administrao, sade e tecnologia da informao e comunicao
(TIC), aplicam a tcnica de RBC com o intuito de alavancar o reuso de
41

solues.Podemos citar aplicaes de help desk, relacionamento com cliente (CRM),
apoio a processos de gerenciamento (como o ITIL V3), dentre outros.
Segundo Carvalho (2012a apud VONWANGEHHEIM; VON WANGEHHEIM,
2003), o ciclo bsico de um sistema baseado em RBC formado por 4 etapas
(Recuperao, Reuso, Reviso e Reteno) A Figura 5 ilustra o ciclo de realizao das
etapas.

Recuperao busca casos similares na base de dados, atravs de
tcnicas que permitem obter a similaridade entre os casos. Podemos
citar: indexao (com ou sem peso), mdias aritmticas, entre outros;
Reuso define um critrio para reuso de um ou mais casos similares,
e o caso recuperado ser aplicado na situao atual;
Reviso revisa e adapta os casos similares durante o reuso. Em
muitos casos necessrio realizar a adaptao manualmente;
Reteno aps o reuso, o novo caso (se tiver sofrido adaptaes)
deve ser registrado na base de casos.
42

Figura 5 - Ciclo Bsico de um Sistema de RBC

Fonte: Carvalho (2012a, p. 32).

Para a etapa de recuperao de um RBC, necessrio definir uma medida
de similaridade entre os casos avaliados. De acordo com Von Wangehheim (2003 apud
CARVALHO, 2012a), uma medida de similaridade usada, atravs de um modelo
matemtico, para quantificar uma semelhana. Podemos dizer que existem dois tipos
de similaridade, a global e a local. A global utilizada para calcular a similaridade no
nvel de casos enquanto que medidas de similaridades locais calculama semelhana
em relao ao tipo especfico do atributo e no contexto de aplicao. A similaridade
global permite combinar medidas de similaridade locais e considera a importncia dos
pesos atribudos a cada atributo. A similaridade local permite a integrao entre os
diferentes tipos de atributos durante o clculo da similaridade global. A seguir
descrevemos duas medidas de similaridade globais citadas por Van Wangehheim
(2003).
43

Nearest Neighbour (Vizinho mais Prximo): esta similaridade baseada
em pontos geomtricos, dessa forma quanto menor for a distncia entre a
representao geomtrica dos casos, maior ser a similaridade entre eles. O
Grfico 1 ilustra o exemplo citado por Van Wangehheim (2003), onde existem
2 casos similares na base (c1 e c2) e o caso Q (situao atual). O c1
escolhido por ser o vizinho geometricamente mais prximo do caso Q. Segue
abaixo a descrio de cada caso
e o clculo usado para determinar a similaridade.

Frmula genrica
d
i
= |X
q
X
i
| + |Y
q
- Y
i
|

Onde,
o d
i
a distncia entre os casos;
o X
q
e Y
q
so os pontos do caso atual;
o X
i
e Y
i
so os pontos do caso que encontra-se na base.

Caso 1
Modelo: Robotron Matrix 600
Luz da tinta: vermelha (...)

Caso 2
Modelo: Robotron 400
Luz da tinta: verde (...)

Caso Q
Modelo: Robotron 200
Luz da tina: vermelha (...)

Clculo
Distncia do caso Q ao caso 1: |3-6| + |2-2| = 3
44

Distncia do caso Q ao caso 2: |3-4| + |2-5| = 4

Grfico 1 - Representao da Medida Global Nearest Neighboure

Fonte: Van Wangehheim (2003).

Nearest Neighbour Ponderado: semelhante ao anterior, porm com
definio de um Peso maior para os ndices mais importantes.
Utilizando o mesmo exemplo anterior, foram definidos os seguintes
pesos: 2 para o ndice do modelo da impressora; e 1 para o ndice da
tinta. Abaixo o clculo considerando os pesos informados. Por esta
medida ponderada, o caso 2 mais similar ao novo caso (para os
mesmos casos apresentados no exemplo da medida anterior (Nearest
Neighbour))

Frmula genrica
d
i
= |X
q
X
i
|*P
x
+ |Y
q
- Y
i
|*P
y

Onde,
o d
i
a distncia entre os casos;
o X
q
e Y
q
so os pontos do caso atual;
o X
i
e Y
i
so os pontos do caso que encontra-se na base;
o P
x
o peso adotado para o atributo no eixo x;
45

o P
y
o peso adotado para o atributo no eixo y.

Clculo
Distncia do caso Q ao caso 1: |3-6| *2 + |2-2| *1 = 6
Distncia do caso Q ao caso 2: |3-4| *2 + |2-5| *1 = 5
Como similaridades locais, podemos citar:
Smbolo ordenado: representao dos valores simblicos em uma
determinada ordem. A seguir um exemplo.
Febre
o Baixa: temperatura entre 36 e 37C
o Mdia: temperatura entre 37 e 38,5C
o Alta: temperatura acima de 38,5C
Desta forma deve ser atribuda uma ordem crescente para as faixas
acima. No caso Baixa=1, Mdia=2 e Alta=3. Assim, a similaridade
calculada atravs do uso destes valores ordenados.
Smbolo no-ordenado: representao dos valores em qualquer
ordem em uma matriz de similaridade. A Tabela 1 apresenta um
exemplo, onde a similaridade entre os valores v1 e v2 0.7.

Tabela 1 - Similaridade para Smbolos No-Ordenados
v1 v2
v1 1 0.7
v2 0.7 1
Fonte:

Existem outras medidas de similaridades (globais e locais) que no foram
apresentadas neste estudo, e que podem ser consultadas em Carvalho (2012a):
Similaridade Global:

Distncia Euclidiana;
Mtrica do Quarteiro ou Distncia de Manhattam;
Similaridade Local:
46

Nmero;
Smbolo binrio;
Smbolo taxonmico;
String

Em suma, a etapa de recuperao de casos em um RBC realizada com
base na aplicao de medidas de similaridades que, em geral, so calculadas por
frmulas matemticas que usam os valores dos atributos do caso. No entanto, a maioria
dos sistemas se limita ao uso de tcnicas de recuperao baseada em comparaes
sintticas entre valores de atributos e textos, tais como palavras-chave, textos fixos,
dentre outras, as quais so imprecisas na recuperao dos reais casos similares,
simplificando e abstraindo detalhes importantes do caso.

2.3.2 Processamento de linguagem natural

Uma subrea de pesquisa em Inteligncia Artificial o Processamento de
Linguagem Natural (PLN) que busca soluo para os problemas de gerao e
compreenso de lnguas naturais (linguagens utilizadas pelo homem em seus
processos de comunicao), visando a converso de/para representaes entendidas
computacionalmente.
Kay (2003 apud CARVALHO, 2012a) cita que:

O campo do Processamento de Linguagem Natural (PLN) representa o vis de
engenharia da Lingustica Computacional. uma rea multidisciplinar que
aproveita pesquisas de reas como Inteligncia Artificial, Lingustica, Cincias
Cognitivas, etc.

De acordo com a Sociedade Brasileira de Computao (SBC), PLN

lida com problemas relacionados automao da interpretao e da gerao
da lngua humana em aplicaes como Traduo Automtica, Sumarizao
Automtica de Textos, Ferramentas de Auxlio Escrita, Perguntas e
Respostas, Categorizao Textual, Recuperao e Extrao de Informao,
entre muitas outras, alm das tarefas relacionadas de criao e disponibilizao
de dicionrios/lxicos e corpus eletrnicos, desenvolvimento de taxonomias e
ontologias, investigaes em lingustica de corpus, desenvolvimento de
47

esquemas de marcao e anotao de conhecimento lingstico-computacional,
resoluo anafrica, anlise morfossinttica automtica, anlise semntico-
discursiva automtica, etc. (SOCIEDADE BRASILEIRA DE COMPUTAO,
2013).

Ainda segundo a SBC O cenrio gerado com a Internet e a demanda por
servios e produtos de Tecnologia da Informao tem ampliado ainda mais o campo de
atuao do pesquisador desta rea e impulsionado o mercado de trabalho.
(SOCIEDADE BRASILEIRA DE COMPUTAO, 2013).
Existem diversos trabalhos das reas de LC e PLN com resultados eficientes,
o que demonstra a importncia e o crescimento destas reas. Podemos citar
processadores dos nveis morfolgico e sinttico das lnguas naturais como POS
Taggers que chega a um nvel de acurcia em torno de 97%. Padr e Stanilovsky (2012
apud SILVA, 2013). Nos nveis semntico e pragmtico das lnguas naturais, um dos
desafios do PLN est relacionado com a falta de recursos semnticos que suportem o
entendimento de linguagem natural por computadores, visando tarefas como extrao
de informaes, recuperao de informao, anlise de sentimentos, resposta
automtica a perguntas, dentre outras. Essa dificuldade ainda mais desafiadora
quando consideramos a lngua portuguesa. (PARDO; CASELI; NUNES, 2009).
Os processadores computacionais de lngua natural podem ser divididos nos
nveis de processamento lingusticos: Morfologia, Sintaxe, Semntica e Pragmtica. A
Figura 6 ilustra a distribuio destes processadores nos diferentes nveis e os principais
recursos de conhecimento lingusticos e conhecimento de mundo utilizados no PLN.
48

Figura 6 - Viso Geral dos Diferentes Nveis de Processamento Lingustico em PLN

Fonte: Silva (2013).

A seguir apresentamos uma descrio dos nveis de PLN, de acordo com
Silva (2013):

Morfologia e Morfossintaxe - o nvel mais bsico do processamento
lingustico e busca identificar as palavras ou tokens de um texto,
atravs de processo que se preocupa com a formao das palavras
(morfemas) e suas flexes. Neste processo, os componentes
significativos de uma sentena em anlise so identificados - tokens.
O principal recurso de conhecimento utilizado uma base lexical ou o
Lxico de uma lngua. O Lxico prov as palavras (lua, mel, casa,
futebol) ou composio de palavras - Multi-Word Expresions (MWE)
49

(lua de mel, casa de cultura, time de futebol, banco de dados) de uma
lngua natural que possuam um valor semntico especfico. Alm
disso, o lxico expresso um conjunto de propriedades associados aos
itens lexicais: forma cannica ou original (lema), classe gramatical e
variaes para gnero, nmero, grau, pessoa, tempo e modo verbal,
dentre outras. Silva (2013) cita alguns processadores deste nvel:
Detector de Sentenas, responsvel por dividir o texto em sentenas;
Tokenizador, responsvel por identificar as sentenas em unidades
menores, aqui chamadas de tokens ou Part Of Speech (POS); POS-
Tagger, que classifica cada token de acordo com sua classe
gramatical e variaes presentes; e Lemmatizer, cujo objetivo
retornar o lema de uma palavra, ou seja, sua forma cannica. A
seguir, apresentamos um exemplo da sada dos processadores deste
no nvel morfolgico e morfossinttico:

o Para a sentena Roberto gosta de correr.
Tokenizador identifica os seguintes tokens a partir do
Lxico - Roberto, gosta, de, correr e .
POS-Tagger classifica os tokens de acordo com a classe
gramatical e variaes -
Roberto Substantivo prprio; lema Roberto
gosta Verbo, Presente do indicativo, 3
a
P,
Singular, etc; lema gostar
de Preposio; lema de
correr Verbo, infinitivo; lema correr
Sintaxe - neste segundo nvel o foco em como as sentenas so
formadas e em como as palavras podem se combinar. Neste nvel, os
processadores identificam partes da sentena (sintagmas),
classificam-nas quanto funo sinttica (sujeito, predicado, objetos,
predicativos, etc.) e geram a estrutura de dependncia entre os
sintagmas. Os recursos lingusticos utilizados so a Gramtica e o
50

Lxico da lngua natural. Silva (2013) cita como exemplos os
seguintes processadores deste nvel:
o Chunker - agrupa, identifica e classifica os sintagmas de uma
sentena. Por exemplo, na sentena Maria vai entregar os
documentos a Pedro, tem-se os seguintes sintagmas:
Maria - Sintagma Nominal (SN)
vai entregar - Sintagma Verbal (SV)
os documentos - Sintagma Nominal (SN)
a Pedro - Sintagma Preposicional (SP)
o Dependence Parser- retorna a rvore de dependncia sinttica
de uma sentena, onde os ns-folha so os tokens
hierarquizados em sintagmas e relacionados por sua funo
sinttica. O parser busca identificar quais funes gramaticais
que os sintagmas exercem na sentena. Por exemplo, na
sentena acima Maria vai entregar os documentos a
Pedro,temos que:
Maria (SN) - sujeito
vai entregar (SV) - predicado
os documentos (SN) objeto direto
a Pedro (SP) - objeto indireto
Semntica - este nvel tem como objetivo identificar o significado das
palavras ou tokens, sentenas, e textos, referenciando-os a objetos,
conceitos ou estado de coisas do mundo. Neste caso, so
necessrias referncias a bases de conhecimento de mundo, bases
de conceitos, taxonomias, ontologias, enciclopdias, etc. Citamos
alguns processadores importantes para este nvel:
o Word Sense Disambiguation (WSD) (STEVENSON; WILKS,
2001), cuja funo identificar o sentido correto de uma
palavra ambgua, quando usada em uma sentena em
particular. Por exemplo, na sentena Joo gosta de manga a
palavra manga usada no sentido de um objeto comestvel.
51

o Semantic Role Labeling (SRL) (GILDEA; JURAFSKY,2002) tem
a funo de extrair automaticamente estruturas de papis
semnticos que permitem a anlise do significado das
sentenas. Por exemplo, na sentena Joo quebrou o vaso,
Joo assume o papel de Agente, ou seja, causador voluntrio
de uma ao, e o vaso o papel de Paciente, ou seja, quem ou
o qu sofre a ao.
Pragmtica/Discurso -em textos, a fora expressiva das palavras
remete identificao dos objetos do mundo em termos do seu
contexto de enunciao e condies de produo discursiva,
permitindo obter uma representao do significado da mensagem
original, levando em conta aspectos pragmticos da comunicao. Por
exemplo, nem sempre o carter interrogativo de uma sentena
expressa exatamente o carter de solicitao de uma resposta. A
sentena Voc sabe que horas so? pode ser interpretada como
uma solicitao para que as horas sejam informadas ou como uma
repreenso por um atraso ocorrido. No primeiro caso, a pergunta
informa ao ouvinte que o falante deseja obter uma informao e,
portanto, expressa exatamente o carter interrogativo. Entretanto, no
segundo caso, o falante utiliza o artifcio interrogativo como forma de
impor sua autoridade. Estas diferentes interpretaes so claramente
relacionadas com a prtica da lngua no dia-a-dia e com as relaes
sociais presentes no contexto discursivo. Para apreender essa prtica,
os processadores recorrem a bases de conhecimento de mundo,
especificamente, a bases de senso comum. A seguir alguns
processadores desse nvel:
o Coreference Resolution (CR) (SOON; NG; LIM, 2001) - tem
como principal funo identificar cadeias de correferncia, ou
seja, um grupo de palavras ou expresses que se referem a
uma mesma entidade. Por exemplo: Joo viajou. Ele estava na
52

Jordania., a cadeia {Ele, Joo} refere-se a mesma entidade
- uma pessoa chamada Joo.
o Question & Answering (LEE et al., 2001) - tem como principal
funo responder uma pergunta feita por um usurio. Por
exemplo, Onde nasceu Pel? o sistema deve procurar uma
fonte confivel responderEm Trs Coraes, Minas Gerais.
o Sentiment Analyzer (TABOADA; ANTHONY; VOLL,2006;
BONTCHEVA et al., 2013) - tem a funo de identificar e extrair
informaes subjetivas de textos como (tristeza, alegria,
polaridade positiva ou negativa, etc.).
Vale ressaltar que os processadores dos nveis semntico e
pragmtico/discursivo necessitam de conhecimento de mundo (domnio) para
realizarem suas tarefas.

2.3.3 RBC usando PLN

O trabalho de Carvalho (2012a) apresentou contribuies importantes para
sistemas de RBC. Basicamente, a proposta consiste em utilizar tcnicas de
Processamento de Linguagem Natural (PLN) na etapa de recuperao de casos de um
sistema baseado em RBC. Foram definidas medidas de similaridade, as quais usam os
atributos selecionveis para realizar comparaes sintticas e a descrio textual para
realizar comparaes semnticas. Para a medida sinttica, tcnicas de recuperao de
RBC tradicionais foram utilizadas, as quais so baseadas em comparaes entre
atributos. J na medida de similaridade semntica, tcnicas de PLN foram utilizadas, as
quais se baseiam na anlise de semelhana conceitual entre palavras. Este processo
de recuperao automatizado, pois utiliza as medidas propostas para inferir quais dos
problemas de uma base de conhecimento podem ou no ser reusados para solucionar
um problema de entrada.
Uma contribuio da pesquisa de Carvalho (2012a) foi um processo de
reutilizao de experincias para problemas ocorridos na fase de requisitos da
Engenharia de Requisitos (ER) Engenharia de Requisitos com Raciocnio Baseado
53

em Casos (ERBC). (PINHEIRO; ALBUQUERQUE; CARVALHO, 2012). Trata-se de um
processo que mescla RBC e PLN com a ideia de reduzir o tempo e custo na soluo de
problemas repetidos. A tcnica de RBC realiza uma recuperao inicial, utilizando uma
medida de similaridade entre os casos e aplica tcnicas de PLN sobre um campo
textual que descreve o problema, para identificar a similaridade semntica entre dois
casos. A Figura 7 ilustra a arquitetura do processo eRbc.

Figura 7 - Arquitetura do Processo de Apoio ao Reuso de Experincias na Engenharia de
Requisitos (eRbc)

Fonte: Carvalho (2012a).
54

Passo (1): Trata-se do incio do processo de reuso de experincias, onde
haver o registro de um novo problema a ser resolvido;
Passo (2): Atravs de uma pesquisa na base de dados, o componente RBC
responsvel por obter uma seleo de casos similares, diminuindo o universo de
possibilidades e facilitando o reuso de experincias. Para isso, os ndices do caso,
definidos como os atributos mais importantes, sero usados para o clculo de
similaridades entre atributos.
Passo (3): Caso no seja possvel obter nenhum caso similar, ento se trata
de um caso indito e dever ser registrado na base, onde ficar disponvel para futuras
consultas.
Passo (4): Utilizado quando se tem casos inicialmente similares e o
componente PLN faz um refinamento levando em conta a semntica da descrio
textual dos casos. Neste passo deve-se fazer uso de clculos de similaridade semntica
(proposto no incio desta seo).
Passo (5): Neste passo so realizadas, se necessrias, alteraes nas
solues similares disponibilizadas e um novo caso adaptado registrado na Base de
Casos, para reuso posterior (Passo (6)).
Foram realizados testes experimentais para avaliar o quanto o uso de PLN
melhora a qualidade da recuperao de casos similares. Os testes consistiram na
criao de uma base de casos a partir de relatos de problemas reais ocorridos em
projetos de software e em testes comparativos com abordagens clssicas de RBC. Os
resultados e anlises estatsticas que o uso de tcnicas de PLN e de uma medida de
similaridade semntica melhorou a preciso e cobertura da recuperao dos casos
similares, justamente pelo fato de fazer uso do conhecimento armazenado dentro do
campo textual. O cenrio que aplicou apenas a medida de similaridade tradicional em
sistemas RBC (similaridade entre valores de atributos ou ndices dos casos) apresentou
uma preciso de 11% e cobertura de 68%, enquanto que o cenrio que utilizou tcnicas
de PLN e similaridade entre textos apresentou preciso de 50.6% e cobertura de 60%
na recuperao de casos similares. Embora a cobertura do primeiro cenrio tenha sido
um pouco maior que a do segundo cenrio (68% contra 60%, respectivamente),
observou que a preciso do cenrio que utilizou tcnica de PLN foi bem superior.
55

2.4 Trabalhos Relacionados

Os principais trabalhos aqui apresentados foram obtidos em uma reviso
bibliogrfica seguindo alguns passos do protocolo de reviso sistemtica. A inteno
deste protocolo sistematizar a pesquisa, guiando na escolha de contedos e
baseando-se em evidncias.
Guo e Wang (2009) definiram um modelo de processo adotando a tcnica
Software as a Service (SaaS)
2
com a proposta de organizar a operao e manuteno
do modelo de processo, otimizando o processo de incidente.
James e Gary (2010) definiram uma abordagem para melhorar as respostas
durante um incidente, visando melhorar e refinar o tratamento ao incidente atravs da
implantao do ITIL V3 e uso de ferramentas adequadas.A abordagem foi realizada em
uma diviso Corporate Legal Services(CLS) de uma publicao internacional chamada
Wolters Kluwer (WK). Com o resultado, concluram que a abordagem, totalmente ligada
ao ITIL V3, mostrou-se bastante eficiente, bem como viram a necessidade de aplicar
esta abordagem em outras prticas e mtodos.
Jntti (2009) analisou os requisitos necessrios para desenvolvimento de um
sistema de gerenciamento de incidentes em conformidade com os processos do ITIL
V3. Entre os requisitos, podemos citar: Requisio; Checar status da requisio; Base
de conhecimentos; Ponto nico de contato; Manter registros dentro dos prazos
definidos no SLA (do ingls Service Level Agreements, Nvel de Acordo de Servio). O
estudo possui certa limitao e verdade que no seria possvel generalizar, pois foi
coletado em uma nica organizao, mas obtiveram um bom retorno devido utilizao
de diversos mtodos e perspectiva de diferentes pessoas. Jntti (2009) ainda afirma
que o gerenciamento de incidente uma nova e interessante rea de pesquisa
acadmica.
Cao e Zhan (2011) definiram um processo para gerenciamento de incidentes
em aplicaes dentro de um ambiente de computao em nuvem. Observaram que os
processos tradicionais do ITIL V3 no so totalmente aplicados para ambientes em
nuvens e definiram duas caractersticas chaves, so elas: Larga escala e virtualizao.

2
Trata-se de uma forma de comercializao do software.
56

Segundo Cao e Zhan (2011), estas caractersticas podem complicar o gerenciamento
de incidentes deste tipo de infraestrutura. Em seguida, propuseram uma melhoria
incluindo dois novos processos: Priorizao e Afirmao da ocorrncia do Incidente.
Esta segunda atividade funciona com base nos alarmes gerados e tem a finalidade de
detectar ou afirmar a ocorrncia de um incidente.Por fim, realizaram um experimento
executando os dois processos (tradicional e o proposto) e concluram que o novo
processo estava 100% alinhado com o negcio da organizao (antes 51%) e
obtiveram um tempo mdio de resposta mais rpido. Apesar de o novo processo ter um
custo adicional de implementao, o mesmo ainda conseguiu ser mais vantajoso, pois
as penalidades do Acordo de Servio foram menores, tendo em vista o tempo mdio de
resposta ter sido mais rpido. Ao final do experimento concluram a efetividade do
processo proposto.
Tehrani e Mohamed (2011) consideram importantes as organizaes
adotarem a Gesto do Conhecimento em suas ferramentas de Service Desk, visto que
essa necessidade vem crescendo fortemente nos ltimos anos. Com base nesse
crescimento eles desenvolveram uma ferramenta, baseada em ITIL V3, para auxiliar o
gerenciamento de incidentes. Para aplicar o conceito de Gesto do Conhecimento,
fizeram uso deuma tcnica da rea de Inteligncia Artificial (IA) com base no reuso de
experincias, o Raciocnio Baseado em Caso (RBC). O RBC foi aplicado visando
reutilizar uma soluo em futuros incidentes, desde que atenda um conjunto de regras -
Rule Library pr-estabelecidas. Ao final observaram uma melhoria significativa na
soluo de novos incidentes e que quanto mais detalhado o conjunto de regras, maior
ser a compatibilidade das solues em novos incidentes. Vale ressaltar que o trabalho
deles no fez uso de PLN e tambm no detalhou as etapas necessrias para
utilizao de RBC e PLN em uma base de dados.
57

Quadro 2 - Comparao entre os Trabalhos
Caractersticas do nosso
trabalho /
Principais Trabalhos
Relacionados
Processo
para
incidentes
Abordagem
com ITIL V3
ou CMMI para
Servios
Utiliza
RBC
Utiliza
PLN
Totalmente
aderente ao
CMMI para
Servios
Guo e Wang (2009) x
James e Gary (2010) x x
Jntti (2009) x x
Cao e Zhan (2011) x x
Tehrani e Mohamed (2011) x x x
Fonte: Elaborao Prpria do Autor.
2.5 Discusso

A partir do Quadro 2, chegamos s seguintes concluses:

Os trabalhos que utilizaram RBC, o fazem da maneira mais tradicional,
ou seja, atravs de atributo-valor, o que leva a certa limitao, pois a
recuperao no tratada em nvel de texto, ou seja, no utilizam
PLN;
Apenas um trabalho props utilizar RBC com um conjunto de regras e
em uma base de incidentes. Porm, o trabalho no funciona para
novos incidentes, ou seja, o mesmo foi aplicado em uma base esttica
o que no comprova sua eficcia diante de uma aplicao dinmica.
Nenhum dos trabalhos apresentou as atividades necessrias para
implementar RBC e/ou PLN.
Nenhum dos trabalhos est totalmente aderente ao CMMI para
Servios.

Identificamos na literatura trabalhos que utilizam RBC, mas apenas a
utilizao de RBC no garante uma recuperao precisa de casos similares, pois
tradicionalmente aplicam apenas medidas que comparam os atributos estruturados de
um caso (aqui chamada de medida de similaridade sinttica).Argumentamos que, o uso
combinado de tcnicas de RBC e PLN possibilita melhorias na recuperao de
incidentes similares, otimizando e sistematizando o reuso de solues j aplicadas e
58

testadas.Alm disto, identificamos que nenhum dos trabalhos est totalmente aderente
ao CMMI para Servios.
Diante das lacunas apresentadas,o trabalho de pesquisa buscou identificar
as atividades necessrias para implementar RBC e/ou PLN em um processo para tratar,
prevenir e solucionar incidentes, alm de buscar respostas para as questes:
- Quais as vantagens de se utilizar RBC e PLN em um processo de
preveno e resoluo de incidentes?
- Qual a vantagem do processo estar aderente ao CMMI para Servios?
Estas e outras questes sero respondidas ao longo deste trabalho. Alm
disto, o processo ir prever a recuperao de casos em uma base de conhecimento,
permitindo consultas s solues j adotadas e insero de novas solues.

2.6 Concluso do Captulo

Neste captulo apresentamos um resumo sobre Gesto de Servios de TI.
Falamos sobre Governana de TI, importncia de ferramentas de apoio a estes
processos, definimos metodologias e apresentamos diversos conceitos neste domnio,
visando apoiar o desenvolvimento deste trabalho.Alm disto, apresentamos conceitos
relacionados RBC e PLN e trabalhos relacionados. No prximo captulo ser
apresentada nossa proposta para implementao de um processo de gerenciamento de
incidentes.
59

3 UMA ABORDAGEM PARA IMPLEMENTAO DE UM PROCESSO PARA
GERENCIAMENTO DE INCIDENTES

Esse captulo apresenta uma abordagem para implementao de um
processo de gerenciamento de incidentes baseado no CMMI para Servios (CMMI-
SVC) e ITIL V3. So descritas as atividades e apresentadas as tarefas que compem
as atividades do processo proposto. Apresenta tambm um mapeamento entre as
prticas especficas do CMMI para Servios juntamente com as melhores prticas do
ITIL V3 e as tarefas definidas para o Processo Proposto.

3.1 Introduo

Durante o ano de 2012 realizamos uma pesquisa sobre as melhores prticas
no tratamento a preveno e resoluo de incidentes. A pesquisa foi respondida em
sua maioria por organizaes do setor privado e foi as questes foram elaboradas com
base nas prticas especficas da rea de processo do CMMI para Servios, Preveno
e Resoluo de Incidentes, do ingls Incident Resolution and Prevention (IRP), visando
identificar as atividades que as organizaes cearenses tm implementadas e que
esto relacionadas rea de processo citado.
A pesquisa foi dividida em trs (03) blocos, um para cada objetivo especfico
do processo IRP, e para cada bloco foram atribudas perguntas referentes a um objetivo
especfico e suas prticas especficas. Questionamos tambm qual (is) a (s) dificuldade
(s) de implementar e/ou manter as atividades, aes ou recursos necessrios para
garantir a aderncia ao objetivo especfico em questo.
As principais dificuldades identificadas foram:

Falta de categorizao do incidente;
No utilizao de ferramenta adequada para acompanhar o incidente;
Manuteno de uma base de conhecimento atualizada;
Identificao de incidentes recorrentes;
Priorizao de incidentes;
60

Mensurao para ver se o incidente foi resolvido dentro do prazo;
Ausncia de acordos de nvel de servios (SLA).

De posse destas dificuldades, decidimos montar um processo com base nas
melhores prticas do CMMI para Servios e ITIL V3 com o intuito de apoiar as
organizaes no tratamento de incidentes. Do ITIL V3 foram utilizados os conceitos de
suporte atravs de um ponto nico de contato (Service Desk), identificao e registro de
incidentes, encerramento formal do incidente e equipes de suporte em nveis. Para a
resoluo do incidente e anlise de solues futuras tratamos internamente com as
atividades do CMMI-SVC combinando com as tcnicas de RBC e PLN. A seguir
detalharemos como estas tcnicas sero utilizadas no processo, bem como todas as
atividades do processo.

3.2 O Processo

O processo est sendo representado utilizando o padro Business Process
Modeling Notation (BPMN). (OBJECT MANAGEMENT GROUP, 2013). Atualmente este
padro mantido pela Object Management Group(OMG) e est na verso 2.0. De
acordo com a OMG, o BPMN uma notao grfica que descreve as etapas de um
processo de negcio. A notao foi projetada especificamente para coordenar a
sequncia de processos e mensagens que fluem entre os participantes do processo,
mesmo que estejam em diferentes conjuntos de aes. O objetivo do BPMN fornecer
s organizaes a capacidade de compreender seus procedimentos internos em uma
notao grfica, oferecendo s organizaes a capacidade de comunicar-se atravs
destes procedimentos. Abaixo os principais componentes utilizados na elaborao do
processo.
1. Evento: representado por um crculo
2. Atividades: representada por uma caixa de texto
3. Deciso: representada pelo losango, indicando dois possveis caminhos.
4. Raia: representada em forma de raias de uma piscina, com o intuito de
organizar e classificar as atividades do processo, baseado em papis e
61

responsabilidade.
O principal objetivo do processo auxiliar a resoluo de incidentes, atravs
da recuperao de casos similares. As atividades referente as tcnicas de RBC e PLN
so opcionais e o processo pode ser utilizado na Gesto de Incidentes em sua forma
tradicional, ou seja, sem recuperao de casos similares. A Figura 8 apresenta o
processo proposto, que formado pelas seguintes atividades, que esto detalhas nas
prximas sees deste captulo.
Planejar RBC e PLN
Registrar Incidente
Categorizar Incidente
Priorizar Incidente
Analisar Incidente
Resolver Incidente (Service Desk)
Resolver Incidente (Nvel 2)
Implementar Soluo de Contorno
Subprocesso Gerenciamento de Problemas
Analisar impactos e causas do incidente
Encerrar Incidente

Figura 8 - Processo Proposto
Fonte: Elaborao Prpria do A

3.2.1 Subprocesso: Planejar RBC e PLN

Este subprocesso tem o propsito de apresentar as etapas
utilizao de tcnicas de Raciocnio Baseado em Casos (RBC)
Linguagem Natural (PLN
uso destas tcnicas possibilita
visto que utiliza medidas de similaridades entre as descries textuais de incidentes.
Aofinal deste subprocesso
ferramentas eRbc em sua gesto de incidentes
Processo Proposto
Elaborao Prpria do Autor.
3.2.1 Subprocesso: Planejar RBC e PLN
Este subprocesso tem o propsito de apresentar as etapas
tcnicas de Raciocnio Baseado em Casos (RBC)
PLN) na gesto de incidentes.De acordo com
uso destas tcnicas possibilita maior preciso na recuperao de incidentes similares,
final deste subprocesso, o ambiente da organizao estar apto a se utilizar de
ferramentas eRbc em sua gesto de incidentes. O subprocesso
62

Este subprocesso tem o propsito de apresentar as etapas para planejar a
tcnicas de Raciocnio Baseado em Casos (RBC) e Processamento de
De acordo comCarvalho (2012a), o
na recuperao de incidentes similares,
, o ambiente da organizao estar apto a se utilizar de
. O subprocesso formado por duas
63

etapas, a seguir detalhadas. Importante salientar que a aplicao de PLN necessita de
um campo textual que descreva o incidente. A Figura 9 apresenta o subprocesso.
Primeira Parte - RBC
Analisar base de dados, selecionar e validar os campos
Modelar Caso
Definir ndices e pesos
Segunda Parte PLN
Definir terminologia do domnio
Definir abordagem similaridade textual
Analisar e validar campo textual
Subprocesso: Higienizar base de dados

Figura 9 - Subprocesso Proposto

Fonte: Elaborao Prpria do A
Subprocesso Proposto
Elaborao Prpria do Autor.
64

65

3.2.1.1 Analisar base de dados, selecionar e validar os campos

Esta atividade tem como propsito realizar uma anlise na base de dados
sobre incidentes, existente na organizao, com o objetivo de avaliar se os atributos
que qualificam um incidente so suficientes para uso de tcnicas de RBC e PLN.
Durante a anlise, os campos devem ser selecionados e validados. Exemplos de
campos que podem ser utilizados: caixas de seleo ou verificao (do ingls
checkbox), caixa de combinao (do ingls Combo box), campo textual, entre outros. A
validao feita atravs de uma anlise no contedo destes campos, por exemplo, se o
contedo inteligvel, ntegro e est no formato correto.
Para uma completa e correta execuo desta atividade, a equipe
responsvel deve seguir os passos descritos abaixo:

1. Verificar a existncia de campos suficientes para a aplicao de RBC e/ou
PLN. Para utilizao de RBC necessrio, pelo menos, um campo do tipo
atributo-valor, caso contrrio no ser possvel realizar as comparaes de
valores.Na aplicao de PLN torna-se necessrio, pelo menos, um campo
textual para realizar a busca por contedo similar.
2. Validar se os campos selecionados anteriormente atendem aos requisitos
para utilizao de RBC e/ou PLN. Os principais requisitos so: existncia de
palavras-chaves; campo textual inteligvel, atributos de fcil comparao,
etc. Para o campo textual, a validao pode ser realizada atravs do PLN,
como por exemplo, atravs de processadores POS-Taggers e Dependency
parsers, para verificar a corretude da estrutura gramatical das sentenas do
texto (frases bem formadas), e a existncia de verbos.
66

Quadro 3 - Representao da Atividade 1 - Analisar Base de Dados, Selecionar e Validar
os Campos
Objetivos: Analisar base de dados, selecionando e validando os campos aptos para utilizao de RBC
e/ou PLN
Papis Principais:
Equipe responsvel pelo processo;
Papis Adicionais:
DBA
Entrada:
Base de dados
Sada:
Base de dados analisada com campos selecionados e
validados
Passos:
1. Verificar a existncia de campos suficientes para a aplicao de RBC e/ou PLN.
2. Validar se os campos selecionados anteriormente atendem aos requisitos para utilizao de RBC
e/ou PLN.
Fonte:Elaborao Prpria do Autor.

3.2.1.2 Modelar caso

Esta atividade tem como propsito modelar um caso. No contexto da gesto
de incidentes, um caso definido por um incidente e uma ou mais solues aplicadas
na resoluo do mesmo. Para ilustrar o que falamos, podemos citar como exemplo um
incidente onde um determinado computador no consegue acessar o sistema ERP.
Este incidente pode ter mais de uma soluo, por exemplo, uma soluo local como a
correo de uma falha no cabo de rede ou de acesso ao computador, ou outras
solues externas como correo de conexo com o servidor do sistema, e retorno da
disponibilidade do mdulo.
A modelagem do caso pode ser realizada usando um diagrama de classe,
exibindo suas dependncias e associaes de aridade (1 N, N N, 1 1).O modelo
de um caso ou incidente serve no somente para o reuso de incidentes, mas tambm a
todo o tratamento dos incidentes, desde a etapa de registro do incidente at o
encerramento do mesmo.
Para uma completa e correta execuo desta atividade, devemos seguir os
passos descritos abaixo:

1. Definir as classes necessrias
a. A modelagem de classes uma representao da estrutura e relaes
das classes que servem de modelo para os objetos (incidentes). Esta
67

modelagem define as entidades necessrias para representar incidentes e
suas solues (caso). Esta definio consiste em identificar as entidades,
seus atributos e mtodos, os quais representam as caractersticas e
operaes das classes.
2. Definir ferramentas de modelagem
a. Definir qual a linguagem e ferramenta sero utilizadas para a modelagem
do caso. Atualmente a linguagem amplamente utilizada para modelagem
de casos a UML, esta linguagem auxilia a visualizao do produto de
seu trabalho em diagramas padronizados (notao grfica). Como
exemplo de ferramentas podemos citar: ArgoUML, IBM Rational, Astah,
entre outras.
3. Definir relacionamentos (dependncias e/ou associaes)
a. Dependncias so relacionamentos de utilizao no qual uma mudana
na especificao de um elemento pode alterar a especificao do
elemento dependente. A dependncia entre classes indica que os objetos
de uma classe usam servios dos objetos de outra classe. Associaes
so relacionamentos estruturais entre instncias e especificam quais
objetos de uma classe esto ligados a objetos de outras classes. A
associao pode existir entre classes ou entre objetos. Neste passo voc
deve definir os relacionamentos (dependncias e/ou associaes) entre as
classes definidas anteriormente.
4. Adaptar a modelagem conforme a necessidade e a base de dados
a. Dependendo da situao talvez seja necessrio adaptar a modelagem
realizada do caso conforme a base de dados, ou seja, modificar alguma
classe para a realidade da organizao. Exemplo: Uma determinada
estrutura de um sistema de gerenciamento de incidentes formada por
duas classes, onde a primeira responsvel pelo armazenamento da
descrio do incidente e a segunda armazena a soluo. Se pegarmos
esta mesma estrutura e tentarmos aplicar em outra organizao, onde seu
sistema atual de incidentes no possui uma classe especfica para
armazenamento da soluo, torna-se necessrio adaptar a estrutura em
68

questo para que a mesma permita trabalhar apenas com a classe que
contm a descrio, buscando a soluo dentro desta mesma classe.

Quadro 4 - Representao da Atividade3 - Modelar Caso
Objetivos: Definir a estrutura do caso
Papis Principais:
Papis Adicionais:
Entrada:
Base de dados com campos selecionados e
validados
Sada:
Caso modelado
Passos:
1. Definir as classes necessrias;
2. Definir ferramentas de modelagem;
3. Definir relacionamentos (dependncias e/ou associaes);
4. Adaptar a modelagem conforme a necessidade e a base de dados.

3.2.1.3 Definir ndices e pesos

O objetivo desta atividade definir os ndices de um caso e seus respectivos
pesos, os quais sero utilizados durante o reuso dos casos, obtendo uma seleo inicial
de casos similares e diminuindo a quantidade de casos a serem analisados pela
ferramenta de PLN. importante destacar que nem todos os atributos de um caso so
ndices, ou seja, apenas aqueles que melhor discriminam o caso devem ser utilizados.
Para exemplificar, consideremos uma modelagem de caso com trs campos: rea;
subrea e mdulo. A rea identifica o local de atendimento, como Tecnologia da
Informao. A subrea descreve o subgrupo do atendimento, como Banco de Dados,
Infraestrutura, Suporte, entre outros. O atributo mdulo define as atividades, como
Execuo de Script, Backup de unidade de rede, Instalao de um novo software, etc.
Neste exemplo, o campo rea no seria um ndice, pois o mesmo no discrimina
suficientemente o caso, diferente do campo mdulo que aponta a atividade que est
sendo realizada.
Baseado em uma medida sugerida por Wangehheim (2003, p. 22), Carvalho
(2012a) props uma medida de similaridade para calcular a similaridade entre os
atributos de dois casos c
1
e c
2
conforme Frmula (1), a qual define a similaridade pela
mdia ponderada da semelhana entre os valores de cada ndice de c
1
e c
2
.
69

Sim
A
(c
1
,c
2
) =
(VsI x PI)
n
= 1
PI
n
= 1
(1)

Onde,
Vs
i
: valor de semelhana entre os valores do ndice i de c
1
e c
2
. Esses valores
de semelhanas entre ndices so definidos por parmetros;
Pi: peso do ndice i, atribudo por parmetro, que define a importncia do
ndice no clculo da similaridade entre atributos;
n: quantidade de ndices do caso

O valor dos pesos de cada ndice pode ser definido atravs de testes de
calibrao, resultados de aplicao de ferramentas/questionrios e/ou opinio de
especialista na rea. Dependo da forma de clculo da similaridade um peso maior pode
ser atribudo para os ndices mais importantes, os quais provavelmente devem
representar melhor o caso. No nosso exemplo acima, o campo mdulo receberia um
peso maior que os demais (rea, subrea). A definio dos pesos pode interferir no
resultado do clculo de similaridade, desta forma essa definio deve ser realizada por
profissionais que possuam conhecimento especfico no domnio da aplicao, alm de
outros envolvidos no processo. necessrio ainda definir o valor de semelhana entre
os ndices utilizados, garantindo que a comparao entre eles possa ser realizada.
Para exemplificar a utilizao da frmula (1), Carvalho (2012a) fez uso de
dois casos fictcios (c
1
e c
2
), onde existem dois atributos para cada caso. O caso 1
possui peso 3 (P
2
= 3) e o caso 2 peso 2 (P
1
= 2), ver Tabela 2. Estes atributos foram
usados como ndice dos casos e a similaridade entre eles definida pelas matrizes
apresentadas nas Tabelas 3 e 4.

Tabela 2 - Casos Fictcios e seus Atributos
Caso 1 (c
1
) Caso 2 (c
2
)
c
1
.a
1
= v
1
c
2
.a
1
= v
2

c
1
.a
2
= v
3
c
2
.a
2
= v
4

70

Tabela 3 - Valores de Semelhanas do Atributo a1
v1 v2
v1 1 0.7
v2 0.7 1

Tabela 4 - Valores de Semelhanas do Atributo a2
v3 v4
v3 1 0.3
v4 0.3 1

Aplicando a frmula (1), a similaridade encontrada entre os dois casos foi de
0.54. Para definir se podemos considerar os casos similares, devemos observar se o
valor obtido maior que o valor de corte. No exemplo no foi definida a nota de corte,
mas suponhamos que fossem 0.7, nossos casos no seriam similares, pois a
similaridade obtida atravs da frmula menor que a nota de corte e a similaridade
deve ser maior ou igual ao valor de corte (Sim
A
V
c
).
Os valores de semelhana exemplificados nas Tabelas3 e 4podem ser
definidos por profissionais do domnio da aplicao (base de dados) e devem ser
ajustados de acordo com a necessidade e com base nas comparaes j realizadas.

1. Definir ndices do caso.
a. Definir os ndices de um caso e seus respectivos pesos, os quais sero
utilizados para calcular a similaridade entre os atributos de dois casos.
2. Definir o valor de semelhana entre os ndices
a. Necessrio definir o valor de semelhana entre os ndices, ou seja, um
valor em percentual que expresse a semelhana de um ndice em relao
a outro ndice. As Tabelas 3 e 4 apresentam exemplos do valor de
semelhana entre os ndices a1 e a2.
3. Avaliar desempenho
a. Neste passo necessrio verificar se os valores dos pesos e semelhana
apresentam boa preciso e cobertura em selecionar casos similares. Esta
71

verificao consiste em calcular para uma amostra de casos a medida de
similaridade proposta e avaliar os resultados em relao a um padro de
ouro. Padro de ouro, do ingls Gold Standard, refere-se a um teste mais
preciso possvel da melhor condio de um caso. Este padro pode ser
definido, por especialistas, analisando caso a caso e definindo a
semelhana entre eles, com isso definem-se os casos que devem ser
retornados como proposta de reuso. Para avaliao dos resultados, pode-
se utilizar a medida de desempenho F
1
-Score que calcula a mdia
harmnica de duas importantes medidas de avaliao preciso e
cobertura. A medida Preciso indica o quanto os casos retornados como
positivos pelo sistema avaliado eram de fato positivos no padro de
ouro. A medida Cobertura (ou Sensibilidade), por sua vez, indica o quanto
dos casos positivos do padro de ouro foram assim classificados pelo
sistema avaliado. No nosso cenrio, o sistema em teste a medida de
similaridade entre atributos, com os ndices, pesos e valores de
semelhana definidos nos passos anteriores. O Quadro 5 apresenta um
esquema que relaciona os casos do padro de ouro com os casos do
sistema sob teste, em quatro situaes:
i. Verdadeiros positivos: a medida de similaridade retornou um caso
como similar e realmente era similar no padro de ouro;
ii. Verdadeiros negativos: a medida de similaridade no retornou um
caso como similar e realmente o caso no era similar no padro de
ouro;
iii. Falsos positivos: a medida de similaridade retorna uma falsa
similaridade, ou seja, retorna um caso como similar, mas o mesmo
no era similar no padro de ouro;
iv. Falsos negativos: a medida de similaridade retornou um caso como
no similar e o mesmo era similar no padro de ouro.

72

Quadro 5 - Medida de Desempenho F
1
-Score


Para a amostra de casos, deve ser calculado o valor de similaridade entre
pares de casos, conforme formula (1), e a partir de um valor de corte, definir se os
casos so similares (teste de resultado positivo) ou no so similares (teste de
resultado negativo). Conforme Quadro 5, Condio referencia a situao ideal
classificada como condio positiva e condio negativa nopadro de ouro (para a
amostra). Os resultados da classificao aferida pela medida de similaridade so
comparados com os resultados do Padro de Ouro e classificados em verdadeiro
positivo,falso positivo, falso negativo e verdadeiro negativo. A medida Preciso
calculada pela razo entre a quantidade de casos verdadeiro positivo e a quantidade
de casos do teste com resultado positivo. A medida de Cobertura, por sua vez,
calculada pela razo entre a quantidade de casos verdadeiro positivo e a quantidade
de casos condio positiva no padro de ouro.

4. Revisar parmetros
Caso necessrio, redefinir ndices e/ou refinar os valores dos pesos e de
semelhana entre ndices. O refinamento dos valores deve ser executado por equipe de
especialistas, atravs da anlise dos resultados da avaliao de desempenho por
amostragem, realizada no passo anterior. No existe uma receita sobre como realizar
73

os ajustes, mas uma estratgia interessante que os especialistas analisem os casos
de falso negativo e falso positivo, e utilizem sua experincia. Este passo deve ser
executado iterativamente em conjunto com o passo anterior at que se tenha adquirido
bons nveis de desempenho em termos de Preciso e Cobertura.

Quadro 6 - Representao da Atividade 4 - Definir ndices e Pesos
Objetivos: Definir os ndices e pesos de cada campo
Papis Principais:
Papis Adicionais:
Entrada:
Base de dados com campos validados
Sada:
Base de dados com campos validados + ndices e
pesos
Passos:
1. Definir ndices do caso

3.2.1.4 Definir terminologia do domnio

Esta atividade tem como objetivo definir uma terminologia do domnio das
aplicaes. De acordo com o dicionrio Michaellis, terminologia um tratado acerca dos
termos tcnicos de uma cincia ou arte. Na rea da computao podemos definir
terminologia como o uso de um conjunto de termos (palavras ou expresses) que
representam conceitos de domnios especficos, ou seja, busca explicitar os termos em
um determinado contexto ou domnio.Esta atividade necessria para que, aps
definidos os termos, possamos representar o conhecimento tcnico-cientfico de forma
organizada (ex.: por meio de um glossrio), associando os termos aos conceitos.
A definio de uma terminologia servir como suporte ao registro e
recuperao de casos, bem como para avaliar a qualidade das descries de incidentes
relatadas.
74

1. Definir os termos do domnio deve ser montada uma lista de termos como
um ndice, onde deve constar o termo e seu significado dentro do domnio em
uso. Abaixo um exemplo de uma lista de termos tcnicos dentro do domnio
de resoluo de incidentes. No Apndice B apresentamos a lista de termos
completa.

Backup: cpia de segurana;
Banco de Dados (Data Base): conjunto de dados sobre um assunto
especfico permitindo fcil consulta;
Service Level Agreement (SLA): nvel de servio normalmente
acordado entre cliente e fornecedor;
Incidente: Segundo o ITIL V3 uma interrupo no planejada ou
reduo na qualidade de um servio de TI;
a. A lista de termos pode ser definida de forma automtica ou manual, a
saber:
i. Automtica atravs de tcnicas de text mining, uma subrea da
minerao de dados (do ingls data mining) chamada minerao de
texto, que se refere ao processo de obteno de informao de
qualidade e estruturada a partir de texto em lngua
natural..Podemos citar como exemplo a ferramenta Text Analyst
fabricada pela Megaputer
3
. Esta ferramenta realiza a minerao do
texto nos documentos armazenados, com o intuito de identificar os
principais conceitos destes documentos e suas relaes
semnticas. Em seguida cria-se uma base de conhecimento, onde
a busca rpida e eficiente.
ii. Manual - onde especialistas criam um glossrio de termos e sua
conceitualizao no domnio da aplicao.
2. Associar os termos de acordo com seus relacionamentos
a. Aps definir os termos referentes ao domnio em questo necessrio
associar estes termos com seus significados. Esta associao garantir a

3
Disponvel em: <http://www.megaputer.com>.
75

representao do conhecimento tcnico-cientfico de forma organizada,
garantindo a criao de um glossrio onde a relao de termos est
associada a seu significado no domnio em questo.

Quadro 7- Representao da Atividade 1.1 - Definir Terminologia do Domnio
Objetivos: Definir a terminologia do domnio a ser utilizada durante a segunda parte do processo
Papis Principais:
Papis Adicionais:
Entrada:
Campo validado para uso de RBC
Sada:
Terminologia definida
Passos:
1. Definir os termos do domnio;
2. Associar os termos de acordo com seus relacionamentos;

3.2.1.5 Definir abordagem similaridade textual

Esta atividade tem como objetivo principal definir os parmetros para a
medida de similaridade textual que ser utilizada na recuperao dos casos. De acordo
com Carvalho (2012a), as medidas de similaridades utilizam atributos selecionveis
para realizar as comparaes. No caso da similaridade sinttica utilizam atributos
selecionveis e para a similaridade textual se baseiam na anlise de semelhana
conceitual entre os termos usados em dois textos.
Neste trabalho, utilizamos a medida de similaridade textual proposta por
Carvalho (2012a) a qual define que, quanto mais os conceitos representados pelos
termos (palavras ou expresses) articulados nos textos so similares entre si, mais os
textos se assemelharo. Nesse trabalho, fazemos uso desta medida de similaridade
textual a qual define a similaridade entre as descries textuais de dois casos c1 e c2
pela mdia ponderada do somatrio das similaridades semnticas entre os termos do
caso c1 e c2. A Frmula (2) apresenta o clculo desta similaridade.
Sim
D
(c
1
, c
2
) =
( 0t
]
qi
] =1
) P
i
n
i =1
q
i
P
i
n
i =1
(2)

Onde,
76

c1 o caso de entrada;
c2 o caso da base;
0t
]
o valor da similaridade semnticaentre os conceitos
representados pelos termos t
1
e t
2
, tal que tj = (t1,t2) T
1
x T
2
, ondet
1
T
1
(conjunto dos termos da descrio textual do caso c
1
) e t
2
T
2

(conjunto dos termos da descrio textual do caso c
2
). O conjunto
T
1
xT
2
subconjunto do produto cartesiano entre T
1
e T
2
e pode ser
gerado atravs de duas abordagens: A primeira associa termos da
mesma classe gramatical (substantivo x substantivo; verbo x verbo;
adjetivo x adjetivo; entre outras) e a segunda associa termos da
mesma funo sinttica (sujeito x sujeito; predicado x predicado;
complemento x complemento). A esta abordagem de gerao do
conjunto T
1
xT
2
denominamos de tipo gramatical. Podem ser usadas
medidas de similaridade de palavras definidas em WordNet
(PRINCETON UNIVERSITY, 2014), InferenceNet (PINHEIRO;
PEQUENO; FURTADO, 2010) e ConceptNet (2014);
q
i
a quantidade de elementos do tipo gramatical i em T1 x T2, ou
seja, a quantidade de comparaes a serem realizadas;
P
i
o peso do"tipo gramatical" i;
n a quantidade de "tipos gramaticais" dos termos t
j
em T1 x T2;
Para exemplificar a aplicao da medida de similaridade textual, sejam os
seguintes casos:
c1 = O sistema emitiu o relatrio
c2 = O programa gerou aplanilha
Aps eliminarmos as stop-words (artigos, conjunes, preposies, etc.) dos
textos acima temos os seguintes conjuntos de termos:
T1 = {sistema, emitir, relatrio}
T2 = {programa, gerou, planilha}
n igual a 1
q igual a 4
77

P, a ttulo de exemplo, vamos supor ser igual a 3.
Conforme preconizado pela medida SIM
D
, a similaridade entre textos
funo da similaridade semntica entre os termos articulados nos textos. A ttulo de
ilustrao, a Tabela 8 apresenta os valores de similaridades t
j
arbitrados para o
exemplo em questo.

Tabela 5 - Valores de Similaridades Semnticas entre Termos Definidos Arbitrariamente
Sistema Emitir Relatrio
Programa 0.9 0.5 0.8
Planilha 0.5 0.7 0.9
Gerar 0.6 1.0 0.7

Neste ponto, deve-se definir a abordagem para gerao do conjunto T1xT2.
ttulo de entendimento, aplicaremos os dois tipos de abordagens no exemplo.
1 Abordagem (Classe Gramatical)
T
1
x T
2
= {(sistema, programa), (sistema, planilha), (relatrio,
programa), (relatrio, planilha), (emitir, gerar)};
Os valores de similaridades semnticas (t
j
) dos elementos tj T
1
x T
2

so, respectivamente, 0.9, 0.5 ,0.8, 0.9, 1.0 (conforme definido no
Quadro 7);
n igual a 2, pois temos duas classes gramaticais ou tipos
gramaticais em T
1
x T
2
substantivo e verbo
q
1
igual a 4 (para tipo gramatical substantivo) e q
2
igual a 1 (para
tipo gramatical verbo)
P, a ttulo de exemplo, vamos supor ser igual a 3
( 0t
]
q
] =1
) P
n
=1
= (0.9 + 0.5 + 0.8 + 0.9)*3 + (1.0)*5 = 14,3
q
n
=1
= 4*3 + 1*5 = 17;
Por fim, o valor da similaridade textual pela abordagem classe
gramatical Sim
D
= 14.3 / 17 = 0,8411, ou seja, o caso c1 84,11%
similar ao caso c2.
2 Abordagem (Funo sinttica)
T1 x T2 = {(sistema, programa), (emitir, gerar), (relatrio, planilha)};
78

Os valores de similaridades semnticas (t
j
) dos elementos tj T
1
x T
2

so, respectivamente, 0.9, 1.0, 0.9 (conforme definido no Quadro 7);
n igual a 1, pois temos uma classe gramaticais ou tipo gramatical
em T
1
x T
2
verbo
q
1
igual a 3 (para tipo gramatical verbo)
P, a ttulo de exemplo, vamos supor ser igual a 3
( 0t
]
q
] =1
) P
n
=1
= (0.9 + 1.0 + 0.9)*3 = 8,4
q
n
=1
= 3*3 = 9;
Por fim, o valor da similaridade textual pela abordagem classe
sinttica Sim
D
= 8,4 / 9 = 0,93, ou seja, o caso c1 93% similar ao
caso c2.
Aps obter o valor da similaridade textual, deve-se observar se o mesmo
est dentro do valor de corte definido. O valor de corte tem como finalidade definir um
valor mnimo para se considerar dois casos como similares. Se o caso da base tiver
uma similaridade igual ou superior a esse valor de corte, este selecionado como
similar e ser utilizado no apoio a resoluo do incidente.
A definio deste valor de corte deve ser feito por amostragem, ou seja,
devem ser selecionados aleatoriamente alguns casos e verificar manualmente se o
resultado retornado condiz com o esperado. Tambm se pode fazer uso da tcnica F
1
-
Score apresentada anteriormente.
1. Definir a medida de similaridade semntica a ser utilizada
a. Escolher qualquer medida de similaridade textual, como por exemplo
WordNet, InferenceNet, ConceptNet, entre outros.
2. Definir a abordagem do tipo gramatical a ser utilizada
a. Escolher entre a abordagem Classe Gramatical ou Funo sinttica.
a. Checar se o resultado da abordagem escolhida esta dentro do valor de
corte, alm de checar tambm, por amostragem ou utilizando a tcnica F
1
-
79

Score, se o resultado apresentado condiz com a realidade. Caso no
esteja voc deve retornar e selecionar a outra abordagem e, caso
necessrio, ajustar valores dos Pesos at encontrar o equilbrio entre o
caso da base com o caso real.

Quadro 8 - Representao da Atividade 1.2 - Definir Abordagem Similaridade Textual
Objetivos: Definir o tipo de abordagem de similaridade textualutilizada na recuperao dos casos
Papis Principais:
Papis Adicionais:
Entrada:
Sada:
Abordagem de similaridade definida
Passos:
1. Definir a medida de similaridade semntica a ser utilizada;
2. Definir a abordagem do tipo gramatical a ser utilizada;
3. Avaliar desempenho.

3.2.1.6 Analisar e validar campo textual

A ideia principal desta atividade analisar e validar o(s) campo(s) textual(is)
existente(s) e checar se existem frases bem formadas, verbos suficientes, entre
outros.Esta anlise pode ser realizada atravs da utilizao de processadores textuais
com o intuito de analisar qualitativamente o contedo do campo textual.
Para esta atividade, so necessrias ferramentas de PLN tais como: Detector
de Sentenas, responsvel por dividir o texto em sentenas; Tokenizador, que identifica
os tokens ou part of speech (POS); e POS-Tagger, que classifica cada token de acordo
com sua classe gramatical e modificadores de gnero, nmero, grau, tempo e modo
verbal, etc.; e parsers sintticos, que definem a estrutura gramatical e dependncia
sintticas entre os sintagmas da sentena. Existem diversas ferramentas para apoiar
esta atividade, destaque para algumas que fazem uso da lngua portuguesa, como
FreeLing (2014), TreeTagger (2014) e MaltParser (2014), entre outros.
Para validao do contedo do campo textual, os seguintes critrios devem
ser atendidos minimamente:
80

I1 Frase bem formada as sentenas do texto devem ser bem formadas
de acordo com a gramtica da lngua;
I2 Quantidade de verbos na sentena cada sentena deve possuir pelo
menos um verbo como raiz da sentena;
I3 Tokens existentes no domnio definido 50% dos termos articulados nas
sentenas devem pertencer terminologia do domnio da aplicao.
Para o campo ser considerado vlido o mesmo dever atender aos trs
critrios citados acima, ou seja, atender plenamente ao indicador 1 (I1), possuir pelo
menos um verbo por sentena no texto e, finalmente, apresentar pelo menos 50% dos
seus tokens no domnio definido.
1. Analisar o(s) campo(s) textual(is) atravs das ferramentas separadoras;
2. Validar o(s) campo(s) textual(is) atravs dos indicadores definidos;

Quadro 9 - Representao da Atividade1.3- Analisar e Validar Campo Textual
Objetivos: Analisar o(s) campo(s) textual(is) existente(s) de acordo com o domnio da aplicao
Papis Principais:
Papis Adicionais:
Entrada:
Campo validado para uso de RBC + terminologia
Sada:
Campo(s) textual(is) selecionado(s) e validado(s)
Passos:

3.2.1.7 Higienizar base de dados

Este subprocesso no pertence ao fluxo do processo principal, mas est
previsto com o intuito de permitir um subfluxo para melhoria dos contedos textuais da
base de dados. Caso os campos textuais no atendam ao critrio de validao definido
na atividade anterior, a equipe responsvel pela implantao deve realizar uma
81

higienizao da base de dados e, em seguida, retornar ao fluxo principal para nova
Anlise e Validao do campo textual.
Esta higienizao tem o intuito de padronizar as informaes do campo
textual, atravs da correo gramatical de sentenas, adequao dos termos utilizados
terminologia definida, eliminao de caracteres especiais desnecessrios, etc.A
principal vantagem dessa higienizao melhorar a qualidade do contedo textual para
um melhor desempenho do RBC baseado em PLN. Exemplo de um texto mal formado:
Sistema sem permitir novo ttulo. Aps a higienizao dos dados o texto deve ser
corrigido: O sistema no permite incluir um ttulo.

3.2.2 Atividade: registrar incidente

Esta atividade, apresentada no Quadro 10, tem como propsito realizar o
registro do incidente, atravs de um evento, uma mensagem, processo automatizado
ou mesmo atravs do prprio solicitante. O interessante que o atendente possa inserir
outras informaes que no foram informadas inicialmente, seja por falta de
conhecimento ou por limitao do agente solicitador. O CMMI-SVC cita que no registro
devem existir informaes relevantes para o atendente, bem como para a resoluo da
requisio.O ITIL V3 cita algumas dessas informaes:
Nmero de identificao nico
Data/hora do registro
Nome/departamento/telefone/localizao do usurio
Mtodo de retorno (e-mail, telefone, sms, etc.)
Descrio do problema
Categoria (pode ser alterada depois, desde que seja mantido um
histrico)
Mtodo de notificao (telefone, e-mail, ferramenta, pessoalmente, etc.)
Responsvel pelo atendimento (pode ser uma equipe)
Atividades realizadas para resoluo do incidente
Data e hora da resoluo
Data e hora do encerramento
82

Entre outras
passos conforme descrito abaixo:
1. Registrar o incidente
a. Realizar o registro do incidente, atravs de um evento, uma
mensagem, processo automatizado ou mesmo atravs do prprio
solicitante
2. Revisar e validar, e quando necessrio atualizar, as informaes da
requisio.
a. O responsvel ou a equipe de suporte a incidentes deve, diariamente,
revisar as informaes inseridas nas novas requisies e checar se a
situao descrita realmente condiz com a realidade. Caso as
informaes no estejam corretas, a equipe deve solicitar maiores
informaes ao requisitante ou checar manualmente (no caso da
requisio ter sido aberta por um processo automatizado). Em caso
afirmativo, a equipe dever passar para a prxima atividade,
Categorizar Incidente.

Quadro 10- Representao da Atividade Registrar incidente
Objetivos: Registrar o incidente
Papis Principais:
Solicitante
Papis Adicionais:
Atendente Nvel 1
Entrada:
Evento;
Mensagem;
Processo automatizado;
Realizada pelo prprio solicitante
Sada:
Informaes, referenteao incidente registrado,
validadas pelo atendente;
Passos:
1. Registro do incidente
2. Validao das informaes do incidente pelo atendente

3.2.3 Atividade: categorizar incidente

Esta atividade, apresentada no Quadro 11, tem como propsito categorizar o
incidente, ou seja, diferenci-lo e classific-lo de acordo com um grupo especfico. O
83

CMMI-SVC sugere a utilizao das categorias aprovadas no plano de preveno e
resoluo de incidentes. Estas categorias podem ser definidas em multinveis, como
sugerido no ITIL V3. Caso a organizao esteja com dificuldades de definir estas
categorias, o ITIL V3 sugere alguns mtodos, sendo os mais relevantes:

Sesso de Brainstorming
4

Utilizao de categorias por um perodo experimental
Anlise dos incidentes registrados

Vale lembrar que o fato de associarmos, inicialmente, uma categoria ao
incidente no quer dizer que no podemos alter-la, desde que toda alterao seja
registrada e mantida em histrico.
1. Verificar veracidade das informaes do incidente
a. O responsvel ou a equipe de suporte deve verificar a veracidade das
informaes fornecidas para que o incidente seja alocado corretamente na
sua categoria.
2. Verificar, e quando necessrio, atualizar a categoria da requisio.
a. O responsvel ou a equipe de suporte a incidentes deve verificar a
requisio e, caso no esteja correta, aloca-la em sua devida categoria.

Quadro 11 - Representao da Atividade Categorizar Incidente
Objetivos:Categorizar incidente
Papis Principais:
Atendente Nvel 1;
Papis Adicionais:
Entrada:
Registro do Incidente
Sada:
Incidente categorizado;
Passos:
1. Verificar veracidade das informaes do incidente;
2. Categorizar o incidente conforme plano de categorias definido

4
uma tcnica para gerao de conceitos em um ambiente livre de crticas e restries imaginao.
84

3.2.4 Atividade: priorizar incidente

Esta atividade, apresentada no Quadro 11, tem como propsito priorizar o
incidente perante os demais. O Guia do ITIL V3 sugere priorizar os incidentes com base
na urgncia e no impacto causado aos negcios da organizao. Estas prioridades
devem ser acordadas no plano de resoluo de incidentes e devem ser definidas
juntamente com a equipe de apoio da atividade. Ainda pode existir uma lista (VIP) com
determinados usurios, onde a prioridade ser diferente do normal. Na Tabela 6temos
algumas sugestes de prioridades retiradas do ITIL V3.
Tabela 6 - Sistema de Priorizao de Incidentes
Impacto
Alto Mdio Baixo
Alto 1 2 3
Urgncia Mdio 2 3 4
Baixo 3 4 5

Cdigo da Prioridade Descrio Tempo de atendimento
1 Crtica 1 hora
2 Alta 8 horas
3 Mdia 24 horas
4 Baixa 48 horas
5 Planejada Acordada
Fonte: Adaptado de ITIL V3 (2011).

1. Verificar urgncia e os impactos causados aos negcios da organizao.
a. O responsvel ou a equipe de suporte a incidentes deve verificar a
urgncia e os impactos causados aos negcios da organizao
relacionados com a ocorrncia do incidente.
2. Priorizar o incidente de acordo com o sistema de priorizao de incidentes
a. Os responsveis devero definir a prioridade do incidente utilizando como
base um sistema de priorizao de incidentes pr-definidos.
85

Quadro 12 - Representao da Atividade Priorizar Incidente
Objetivos: Priorizar o incidente
Papis Principais:
Atendente Nvel 1;
Papis Adicionais:
Entrada:
Incidente categorizado
Sada:
Incidente categorizado e priorizado
Passos:
1. Verificar urgncia e os impactos causados aos negcios da organizao;

3.2.5 Atividade: analisar incidente

Esta atividade, apresentada no Quadro 13, tem como propsito analisar a
requisio, ou seja, realizar uma anlise mais detalhada, verificando se a situao
informada ainda persiste e se as informaes descritas esto corretas e consistentes,
determinando as aes a serem tomadas. Este diagnstico dever focar nas melhores
prticas, que ser capaz de resolver o incidente da maneira mais efetiva. Quanto
melhor for o diagnstico por parte da equipe, maior a probabilidade de mitigar futuros
incidentes. Durante esta anlise devem ser utilizadas tcnicas e ferramentas oriundas
do RBC que consistem em reutilizar solues de outros incidentes registrados na base
de conhecimento. Vale lembrar que a utilizao das tcnicas RBC e PLN opcional e,
caso no deseje utiliz-las, o processo pode ser aplicado sem fazer uso de recuperao
de casos similares na base, ou seja, em sua forma tradicional. Caso seja escolhido
utilizar estas tcnicas, deve ser definido um conjunto de regras, onde quanto mais
detalhado este conjunto, maior ser a compatibilidade das solues da base com o
novo incidente.
A ferramenta a ser utilizada no passo 1, Buscar soluo na base de
conhecimento, ser o prottipo desenvolvido por Carvalho (2012a). Este prottipo,
chamado de eRbc, foi avaliado em uma base de casos construda a partir de problemas
(falhas) relatados em projetos de software de uma organizao do Governo Federal do
Brasil. Devido as semelhanas entre as metodologias adotadas, decidimos por no
executar a ferramenta em nossa base de casos, tendo em vista a mesma ter sido
86

avaliada no mbito de Engenharia de Requisitos (ER). A tabela 13 apresenta um
resumo destas semelhanas.

Quadro 13 - Semelhanas entre as Metodologias
Tpicos Semelhanas
Modelagem do Caso
Semelhante, pois utilizamos a mesma estrutura, sendo
necessrio apenas adequar s nomenclaturas. Exemplo:
Onde tnhamos Fase, Subfase e Artefato, chamamos,
respectivamente, de rea, Subrea e Mdulo; Problema e
soluo permaneceram com a mesma descrio.
Atividade Solucionar Caso
Semelhante a nossa atividade Analisar Incidente onde
instanciamos tarefas de recuperao, armazenamento e
adaptao.
RBC Utilizado para recuperar casos similares
PLN
Utilizado para calcular a similaridade entre as descries dos
casos
Similaridade entre os atributos
Utilizamos a mesma medida adotada por Carvalho (2012a) e
sugerida por Von Wangehheim e Von Wangehheim (2003).
Medida de similaridade textual
Fizemos uso da medida de similaridade textual proposta por
Carvalho (2012a) e implementada no prottipo.


1. Buscar soluo na base de conhecimento.
a. O responsvel ou a equipe de suporte a incidentes deve verificar se existe
algum incidente, similar, na base de conhecimento. Esta consulta deve ser
realizar atravs do prottipo proposto por Carvalho (2012a),
automatizando a busca e garantindo o retorno da informao o mais
rpido possvel.
2. Analisar os incidentes similares e verificar a compatibilidade com o incidente
atual
a. Caso exista alguma soluo similar ao incidente atual, a mesma dever
ser analisada e verificada a compatibilidade com a ocorrncia.
3. Encaminhar os incidentes similares para a prxima atividade
a. Caso a soluo encontrada seja compatvel com o incidente atual, a
mesma dever ser informada para a equipe responsvel na prxima
atividade (Solucionar o Incidente).
87

Quadro 14 - Representao da AtividadeAnalisar Incidente
Objetivos: Analisar o incidente
Papis Principais:
Atendente Nvel 1;
Papis Adicionais:
Entrada:
Incidente categorizado e priorizado;
Sada:
Existncia de incidentes similares na base de
conhecimento.
Passos:
1. Buscar soluo na base de conhecimento;
2. Analisar os incidentes similares e verificar a compatibilidade com o incidente atual;
3. Encaminhar os incidentes similares para a prxima atividade.

3.2.6 Atividades: resolver incidente (service desk) e resolver incidente (nvel 2)

Estas atividades, apresentadas no Quadro 15, tem como propsito a
completa e correta soluo do incidente. O Service Deskou equipe de suporte a
incidentes deve tentar solucionar o incidente com base nas solues similares
determinadas na atividade Analisar Incidente. Caso a equipe no tenha conhecimento
tcnico suficiente para resoluo do incidente, o mesmo dever ser alocado para a
equipe de 2 nvel (Atividade Resolver Incidente Nvel 2). Todas as aes tomadas e os
seus respectivos resultados devem ser registrados com o intuito de manter um histrico
das aes realizadas, facilitando sua reviso e a anlise de aes futuras necessrias.
Durante a resoluo do incidente podero ser utilizados incidentes similares
identificados na atividade anterior, usandoas tcnicas de RBC e PLN.
Para uma completa e correta execuo destas atividades, devemos seguir os

1. Verificar se os incidentes similares so realmente compatveis com o caso
em anlise.
a. O responsvel ou a equipe de Service Desk deve verificar se foi informado
algum incidente similar na base de conhecimento (atividade anterior) e
buscar analisar o resultado caso esta soluo seja aplicada.
2. Solucionar o incidente.
a. De posse das requisies similares, o responsvel ou a equipe de Service
88

Desk dever aplicar a soluo previamente informada e checar se o
incidente foi concludo. Nesta etapa pode ser necessrio escalonar a
resoluo para o 2 nvel, que pode ser outra equipe ou uma empresa
terceirizada.
3. Registro de uma nova soluo na base de conhecimento
a. Caso a soluo utilizada no incidente no seja nenhuma utilizada nos
incidentes similares, a equipe dever inserir o novo procedimento na base
de conhecimento.

Quadro 15 - Representao das Atividades Resolver Incidente (Service Desk) e Resolver
Incidente (Nvel 2)
Objetivos:Resolver incidente
Papis Principais:
Atendente Nvel 1;
Atendente Nvel 2;
Papis Adicionais:
Solicitante;
Equipe de Suporte
Entrada:
conhecimento.
Sada:
Incidente resolvido;
Escalonamento para a equipe de Nvel 2;
Possvel problema.
Passos:
1. Verificar se os incidentes similares so realmente compatveis com o caso em anlise;
2. Solucionar o incidente;
3. Registro de uma nova soluo na base de conhecimento.

3.2.7 Atividade: implementar soluo de contorno

Esta atividade, apresentada no Quadro 16, tem como propsito disponibilizar
uma soluo de contorno, ou seja, uma soluo alternativa. O ITIL V3 sugere buscar
uma soluo alternativa para os incidentes gerados aps um problema, ou seja, uma
maneira temporria de permitir que aquela atividade possa ser realizada (Exemplos:
insero de um registro via banco de dados, excluso de uma condio do sistema,
entre outros). Vale ressaltar que essa soluo realmente deve ser temporria, ou seja,
as equipes devem continuar trabalhando em busca de uma soluo permanente.

89

1. Checar se existe soluo alternativa.
a. A equipe dever verificar se existe alguma soluo que possa ser
implementada para que o negcio no pare completamente, ou seja, algo
que o mantenha funcionando, mesmo que no seja da melhor maneira
possvel.
2. Implementarsoluo de contorno.
a. Caso a equipe identifique alguma soluo de contorno, a mesma dever,
o mais breve possvel, implement-la, ou seja, disponibiliz-la ao
solicitante para que o negcio da organizao no seja muito impactado.

Quadro 16 - Representao da Atividade Implementar Soluo de Contorno
Objetivos: Implementar uma soluo de contorno (caso exista)
Papis Principais:
Atendente Nvel 1;
Atendente Nvel 2;
Papis Adicionais:
Solicitante;
Equipe de Suporte
Entrada:
Problema
Sada:
Execuo da soluo de contorno
Passos:
1. Checar se existe soluo alternativa, ou seja, uma soluo que mantenha o funcionamento do
negcio da organizao;
2. Implementar a soluo de contorno;

3.2.8 Atividade: analisar impactos e causas do incidente

Esta atividade, apresentada no Quadro 17, tem como propsito analisar os
possveis impactos no negcio e as causas que originaram o incidente. Segundo o
CMMI-SVC, nesta atividade, deve-se determinar a melhor ao para direcionar ao
incidente, minimizando o impacto e conduzindo uma anlise causal
5
do incidente. Neste
momento um repositrio essencial, podendo ser usado para determinar, rapidamente,
aes a serem tomadas.

5
Anlise causal feita estabelecendo uma relao entre um comportamento e uma condio
antecedente.
90

1. Analisar possveis impactos no negcio e determinar aes a serem
tomadas sobre os incidentes
a. A equipe dever analisar os possveis impactos no negcio e determinar a
melhor ao a direcionar ao incidente, procurando minimizar o impacto ao
negcio.
2. Identificar possveis causas que geraram o incidente e determinar aes que
devem ser tomadas para evitar que o incidente ocorra novamente
a. A equipe dever realizar um levantamento das possveis causas que
geraram o incidente e dever conduzir uma anlise causal do incidente,
ou seja, identificar fatores que resultaram na natureza do incidente,
procurando identificar comportamentos, aes ou condies que devem
ser modificadas para evitar que o incidente ocorra novamente.

Quadro 17 - Representao da Atividade Analisar Impactos e Causas do Incidente
Objetivos:Analisar os impactos causados e o motivo do acontecimento do incidente
Papis Principais:
Equipe de Suporte a incidentes.
Papis Adicionais:
Atendente Nvel 1;
Atendente Nvel 2.
Entrada:
Incidente resolvido.
Sada:
- Impactos causados e o provvel motivo que levou ao
acontecimento do incidente;
- Aes a serem tomadas
Passos:
1. Analisar possveis impactos no negcio e determinar aes a serem tomadas sobre os incidentes;
2. Identificar possveis causas que geraram o incidente e determinar aes que devem serem
tomadas para evitar que o incidente ocorra novamente.

91

3.2.9 Atividade: encerrar incidente

Esta atividade, apresentada no Quadro 18, tem como propsito realizar o
encerramento formal do incidente. De acordo com o ITIL V3, o Service Desk deve
verificar se o incidente est resolvido e se os usurios esto satisfeitos e se aceitam o
encerramento do incidente. Alm destas informaes a equipe tambm dever verificar
outros pontos, como por exemplo:
Categorizao do encerramento: Verificar se a categorizao inicial do
incidente foi informada correta, ou se a mesma foi corrigida ao longo da atividade;
Pesquisa de satisfao: realizar uma rpida pesquisa de satisfao com o
intuito de saber se a resoluo foi oferecida da melhor maneira possvel. A pesquisa
pode ser realizada por telefone ou atravs de um questionrio web;
Documentao dos incidentes: Garantir que todos os detalhes da
resoluo tenham sido informados corretamente pela equipe de incidentes durante o
atendimento da requisio, garantindo um histrico completo e com um bom nvel de
detalhamento.
Para uma completa e correta execuo destas atividades, devemos seguir os
1. Analisar informaes do incidente (categoria, priorizao, documentao,
entre outros)
a. A equipe deve checar se as informaes do incidente esto corretas e
bem documentas. Algumas informaes que devem ser verificas: correta
categorizao; documentao gerada consistente e aplicao de uma
pesquisa de satisfao
2. Formalizao do encerramento do incidente.
a. A equipe dever entrar em contato com o solicitante e checar se o
incidente foi solucionado de forma satisfatria e questionando se o mesmo
pode ser encerrado formalmente.
3. Comunicar as partes envolvidas
a. A equipe dever comunicar as partes envolvidas a concluso do incidente
92

Quadro 18- Representao da Atividade Encerrar Incidente
Objetivos: Realizar o encerramento formal do incidente, comunicando as partes envolvidas.
Papis Principais:
Atendente Nvel 1.

Papis Adicionais:
Equipe de Suporte a incidentes;
Atendente Nvel 2.
Entrada:
- Incidentes resolvidos;
- Aes executadas.
Sada:
- Formalizao do encerramento do incidente;
- Comunicar as partes envolvidas.
Passos:
1. Analisar informaes do incidente (categoria, priorizao, documentao, entre outros);
2. Formalizao do encerramento do incidente;

3.3 Aderncia das Atividades do Processo

Como dito anteriormente, o processo proposto foi definido com base nas
atividades presentes nas principais metodologias. O Quadro 19 apresenta as atividades
do processo proposto e suas correlaes com as metodologias ou guias utilizados na
elaborao do processo. Ressaltamos que nosso processo totalmente aderente ao
Modelo de Maturidade CMMI-SVC, no querendo dizer que no tenhamos utilizado
definies oriundas de outros Guias ou Normas, como por exemplo o ITIL V3.

Quadro 19- Atividades do Processo
Atividade do Processo Proposto Modelo de Maturidade ou Guia
Planejar RBC e PLN IA
Registrar Incidente CMMI-SVC/ITIL V3
Categorizar Incidente CMMI-SVC/ITIL V3
Priorizar Incidente CMMI-SVC/ITIL V3
Analisar Incidente CMMI-SVC V3
Resolver Incidente (Service Desk) CMMI-SVC V3
Resolver Incidente (Nvel 2) CMMI-SVC
Implementar Soluo de Contorno CMMI-SVC/ITIL V3
Analisar Impactos e Causas do Incidente CMMI-SVC
Encerrar Incidente CMMI-SVC/ITIL V3
93


Este captulo apresentou o processo proposto de Gesto de Incidentes.
Foram mostradas e detalhadas as atividades desse processo, bem como o produto
requerido e gerado por cada atividade. O captulo seguinte ir apresentar o estudo de
caso realizado em uma organizao de economia mista com sede na cidade de
Fortaleza, estado do Cear.
94

4 ESTUDO DE CASO

Este captulo apresenta um estudo de caso realizado em uma
organizao de economia mista, com o intuito de validar o processo definido e
apresentar os resultados e contribuies do trabalho.

4.1 Metodologia de Avaliao

Para realizar o estudo de caso construmos uma base de dados a partir de
relatos de incidentes de atendimento ps-implantao de um sistema ERP em uma
organizao de economia mista (pblica e privada) no estado do Cear. Esta
organizao possui em seu quadro de funcionrios, aproximadamente, 2.800
colaboradores, onde cerca de 450 so usurios diretos do sistema. O objetivo do
estudo de caso foi demonstrar que o processo proposto contribuiu no atendimento ps-
implantao do sistema ERP.
De acordo com Yin (2003 apud PAIVA, 2011), o estudo de caso mais
indicado quando:
i. Questes de como e por que so necessrias;
ii. O investigador tem pouco controle sobre os eventos;
iii. O foco sobre um fenmeno contemporneo dentro de um contexto da
vida real.
Nosso estudo atende os requisitos acima, visto que existem questes de
como um processo de resoluo de incidente pode ajudar as equipes que tratam
incidentes e por que necessrio definir uma sistemtica de atendimento com foco
em reuso de casos. Alm disso, podemos dizer que temos pouco controle sobre os
eventos que podem ocorrer (incidentes) e que possumos foco em um contexto da vida
real.
95

4.2 Planejamento do Estudo de Caso

Para elaborar nosso estudo de caso foi necessrio definir 3 artefatos para
auxiliar durante a execuo do processo. Nos Apndices A e B, apresentamos os dois
primeiros artefatos, criados com a finalidade de auxiliar a atividade Planejar RBC e
PLN. No Apndice C, o terceiro artefato contm a base de casos utilizada no estudo de
caso, gerada a partir de incidentes de atendimento ps-implantao de um sistema
ERP em um intervalo de 15 dias.
O objetivo deste trabalho melhorar a produtividade do atendimento aos
usurios do sistema ERP da organizao, e para isso, foi desenvolvido um processo
que, a partir do uso de melhores prticas, poderemos diminuir esse tempo de
atendimento. As principais hipteses para este trabalho so:
H1: O processo proposto eficaz
H2: RBC e PLN melhoram o reuso de experincias
A hiptese H1 de carter subjetivo, e os dados para anlise sero
coletados durante a execuo do processo. J a hiptese H2 ser baseada na
comparao do planejamento de RBC e PLN para este contexto e o que foi
implementado e obtido, enquanto eficincia de retorno, em Carvalho (2012a).
Para cada hiptese definida, necessrio definir indicadores que suportaro
anlises comparativas e qualitativas. Os indicadores definidos so:
I1: Nvel de Eficcia do Processo(coletado a partir de uma pesquisa com um
dos usurios do processo).
I2: Preciso de recuperao de casos similares.
A anlise dos dados foi realizada utilizando a estratgia analtica de Yin
(2003), onde so descritos todos os eventos observados durante a coleta de dados e,
no final, os resultados das hipteses previstas sero avaliados.
96

4.3 Execuo do Estudo de Caso
Nesse estudo de caso, a base de incidentes foi gerada utilizando o processo
proposto, onde a equipe de suporte do sistema ERP era responsvel pela construo
da planilha, tendo em vista que no foi implantada nenhuma ferramenta para apoiar
esta atividade. A equipe registrava o incidente em uma planilha e seguia o fluxo do
processo at a anlise e resoluo do incidente, seguindo as categorias e prioridades
definidas nas atividades de planejamento do estudo de caso e com o apoio de
especialistas da rea.

4.3.1 Atividade planejar RBC e PLN

Nesta etapa foram definidos os passos necessrios para planejar a aplicao
da tcnica de RBC e PLN. Os passos envolvem seleo e validao de campos,
modelagem do caso, abordagem selecionada, entre outros.
Como citado anteriormente foram criados dois artefatos, um para apoiar
tcnica RBC e outro tcnica PLN. Os prximos itens detalham as tarefas de Planejar
RBC e Planejar PLN e nos Apndices A e B deste trabalho encontramos os artefatos
criados e preenchidos.

4.3.1.1 Tarefa: planejar RBC

Com o intuito de apoiar a execuo desta tarefa, seguiremos a sequncia de
atividades definidas na seo 3.2.1 (Subprocesso: Planejar RBC e PLN). Nesta tarefa
faremos uso das atividades de planejamento de RBC:
Analisar base de dados, selecionar e validar os campos

97

Quadro 20- Anlise da Base de Dados
Objetivos: Analisar base de dados, selecionando e validando os campos aptos para utilizao de RBC
e/ou PLN
Papis Principais:
Analista I;
Papis Adicionais:
Entrada:
Planilha
Sada:
Planilha analisada com campos selecionados e
validados
Passos:
1. Verificar a existncia de campos suficientes para a aplicao de RBC e/ou PLN.
2. Validar se os campos selecionados anteriormente atendem aos requisitos para utilizao de RBC
e/ou PLN.
Detalhamento da execuo: Em um primeiro momento foram selecionados 3 campos (Categoria,
Priorizao e Soluo de Contorno), porm, aps a validao, um dos campos (Soluo de Contorno)
no se mostrou til, tendo em vista que o mesmo era um Flag (sim ou no) e no existia atributos para
comparaoe foi retirado do planejamento. Desta forma a base selecionada estava apta para utilizao
de RBC, tendo em vista que a mesma possua campos suficientes e do tipo atributo-valor.
98

Modelar Caso

Quadro 21- Modelagem do Caso
Objetivos: Definir a estrutura do caso
Papis Principais:
Analista I;
Analista II;
Papis Adicionais:
Entrada:
validados
Sada:
Caso modelado
Passos:
1. Definir as classes necessrias;
2. Ferramenta para modelar o caso;
3. Definir relacionamentos (dependncias e/ou associaes);

Detalhamento da execuo: Realizamos o levantamento das classes necessrias para a modelagem
do caso. Em nosso caso utilizamos quatro (04) classes (problema, soluo, atendente e causa), onde a
classe problema armazena o incidente, a classe soluo com os passos para sanar o incidente, a
classe atendente informaes referentes ao analista responsvel pela resoluo do incidente e a classe
causa, onde armazenamos a causa daquele incidente. Esta ltima classe apoiou a atividade de buscar
solues para evitar incidentes futuros. Utilizamos a ferramenta ArgoUML na criao desta modelagem.

4. Adaptar a modelagem conforme a necessidade e a base de dados.

Detalhamento da execuo: No foi necessrio adaptar a modelagem a planilha, tendo em vista que a
mesma encontrava-se compatvel com a planilha. Esta modelagem servir de base para, no futuro, ser
desenvolvido um aplicativo, utilizando-se do prottipo de Carvalho (2012a), para recuperao de casos
similares. No nosso caso, o aplicativo pode levar em considerao o campo Problema como sendo a
descrio do nosso caso, as informaes tambm podem ser consultadas no campo Soluo e o
campo Causa pode ser utilizado como filtro dos casos que esto na base e possuem a mesma causa
de problema. No apndice A podemos encontrar essa modelagem.
99

Definir ndices e pesos

Quadro 22- ndices e Pesos
Objetivos: Definir os ndices e pesos de cada campo
Papis Principais:
Analista I;
Papis Adicionais:
Especialista da rea de infraestrutura
Entrada:
validados
Sada:
validados + ndices e pesos
Passos:
1. Definir ndices do caso

Detalhamento da execuo:Em nosso estudo de caso atribumos, atravs de opinio de especialista
na rea, peso 3 ao campo Categoria e peso 2 ao campo Priorizao.Os valores de semelhanas foram
definidos com base na opinio do especialista e podem ser visualizados no Apndice A.


Detalhamento da execuo: Analisamos, por amostragem, se os resultados encontrados com os
ndices e valores de semelhanas definidos, estavam dentro do esperado.Em nosso caso os valores
definidos estavam satisfatrios e no foinecessrio revisar os parmetros.

4.3.1.2 Tarefa: planejar PLN

Dando sequencia a execuo do estudo de caso, nesta tarefa faremos uso
das atividades de planejamento de PLN. So elas:
100

Definir terminologia do domnio

Quadro 23- Terminologia do Domnio
Objetivos: Definir a terminologia do domnio a ser utilizada durante a segunda parte do processo
Papis Principais:
Analista I;
Analista II;
Analista III.
Papis Adicionais:

Entrada:
Sada:
Terminologia definida
Passos:
1. Definir os termos a serem utilizados;
2. Associar os termos de acordo com seus relacionamentos;

Detalhamento da execuo: Em nosso estudo de caso geramos uma amostragem dos termos
manualmente. A terminologia pode ser encontrada no Apndice B.Como definimos apenas uma
amostragem dos termos para ilustrar o uso da tcnica no criamos uma representao estruturada de
um domnio, mas de grande valia a existncia destarepresentao, tornando possvel no apenas o
armazenamento dos dados, mas tambm seus relacionamentos e atributos, solucionando algumas
deficincias encontradas na representao do conhecimento de um domnio.
101

Definir abordagem similaridade textual

Quadro 24- Abordagem de Similaridade Textual
Objetivos: Definir o tipo de abordagem de similaridade textual utilizada na recuperao dos casos
Papis Principais:
Analista I;
Analista II.
Papis Adicionais:
Entrada:
Sada:
Abordagem de similaridade definida
Passos:
1. Definir a medida de similaridade semntica a ser utilizada;

Detalhamento da execuo: Em nosso estudo de caso, tendo em vista que no executamos esta
atividade, levamos em considerao a abordagem semntica (Sim
D
) proposta por Carvalho (2012). Esta
similaridade utiliza uma tcnica para extrao das palavras e eliminao de palavras no significativas,
as chamadas stop-words, que so palavras comuns, encontradas em grande quantidade em um
arquivo textual e no carregam significado em si prprio. Em geral, pertencem s seguintes classes
gramaticais: artigos, conjunes, preposies, pronomes e advrbios. Aps a extrao, o clculo
realizado usando quantidade de palavras, pesos, ndices.

2. Definir a abordagem do tipo gramatical a ser utilizada;
3. Avaliar desempenho.

Detalhamento da execuo: Utilizamos a abordagem por Classe Gramatical e realizamos uma
avaliao, por amostragem, nos resultados dos indicadores gerados nos campos utilizados
anteriormente e atravs de uma nota de corte definimos os campos aptos para uso.
102

Analisar e validar campo textual

Quadro 25- Anlise do Campo Textual
Objetivos: Analisar o(s) campo(s) textual(is) existente(s) de acordo com o domnio da aplicao
Papis Principais:
Analista I;
Papis Adicionais:
Entrada:
Campo validado para uso de RBC + terminologia
Sada:
Campo(s) textual(is) selecionado(s) e validado(s)
Passos:

Detalhamento da execuo: Realizamos uma anlise manual nos campos, observando se o contedo
do campo textual possua dois indicadores: (i) uma frase bem formada e se a (ii) quantidade de verbos
na sentena era suficiente para a compreenso do texto.


Detalhamento da execuo: Com base nos indicadores anteriores (i e ii), observamos que o campo
est apto, tendo em vista a existncia de frases bem formadas e a existncia de pelo menos um verbo
na sentena.

Aps seguir as etapas informadas, a base est apta para utilizao de PLN e
pode seguir o fluxo do restante do processo. Maiores detalhes desta etapa em nosso
estudo de caso podem ser obtidas no Apndice B deste trabalho.

4.3.2 Atividade: registrar incidente

A base de incidentes foi registrada em uma Planilha do tipo Excel, como
pode ser visualizada na Figura 1A do Apndice C. O incidente era reportado via e-mail
ou telefone e a equipe de atendimento ficava responsvel por registrar a informao na
planilha. O Quadro 26 detalha esta atividade.
103

Quadro 26- Registro do Incidente
Objetivos: Registrar o incidente
Papis Principais:
Solicitante
Papis Adicionais:
Analista I
Entrada:
Realizada pelo prprio solicitante
Sada:
Informaes, referente ao incidente registrado,
validadas pelo atendente;
Passos:
1. Registro do incidente
2. Validao das informaes do incidente pelo atendente

Detalhamento da execuo: Os incidentes foram registrados em uma planilha que era alimentada
pelos incidentes reportados pelos solicitantes via e-mail.Estes incidentes eram inicialmente validados
via telefone. A inteno desta validao era confirmar o incidente e colher maiores informaes.

4.3.3 Atividade: categorizar incidente

Aps a insero do incidente na planilha, o especialista era responsvel por
categorizar o incidente relatado. Foram definidos 3 tipos de categorias: Cadastro,
Dvida e Erro, com as seguintes finalidades:
Cadastro: categoria que visa abordar a realizao de cadastro de novos
usurios, alteraes de permisses, cadastro de fornecedores, entre outros tipos de
cadastros do sistema.
Dvida: categoria com a finalidade de agrupar as dvidas provenientes
da utilizao do sistema ou dvidas de processos.
Erro: categoria que agrupa erros do sistema em geral. Nesta categoria
so considerados erros do aplicativo, como travamentos ou fechamento indevido, entre
outros tipos de erros que no so enquadrados na categoria Dvida.
O Quadro 27apresenta as etapas seguidas nesta atividade.
104

Quadro 27- Categorizao do Incidente
Objetivos: Categorizar o incidente
Papis Principais:
Analista I;
Papis Adicionais:
Entrada:
Registro do Incidente
Sada:
Incidente categorizado;
Passos:
1. Verificar veracidade das informaes do incidente;
2. Categorizar o incidente conforme plano de categorias definido

Detalhamento da execuo: Neste passo, era realizado outro contato com o solicitante para obter
detalhes mais tcnicos para uma correta categorizao. Aps o recebimento das informaes acima, a
categorizao era realizada conforme tipos definidos anteriormente.

4.3.4 Atividade: priorizar incidente

Aps a categorizao, o especialista realizava a priorizao do incidente, ou
seja, ele o alocava de acordo com sua a criticidade. Foram definidos 5 tipos de
priorizao, onde o primeiro tem a criticidade baixa e o ltimo criticidade alta. Abaixo a
descrio das prioridades:
1 - No impede operao do sistema: esta prioridade possui criticidade
baixa, pois no impacta no negcio da organizao e no impede que o sistema seja
operado.
2 - Baixo Desempenho do sistema: Similar prioridade anterior, com a
diferena de reduzir o poder de desempenho do sistema. Como exemplo, podemos
citar a lentido na gerao de um relatrio ou de uma rotina especfica.
3 - Documentao insuficiente: esta prioridade mostra a falta de informao
ou ausncia de documentos de apoio. Solicitaes enquadradas nesta prioridade visam
a necessidade de melhorar a documentao (on-line) da rotina e de seus tutoriais.
4 - Impede operao com sada de contorno: solicitaes enquadradas nesta
categoria impactam no negcio da organizao, pois impedem a utilizao plena do
sistema, mas por outro lado oferecem uma sada de contorno. Um exemplo: um
105

determinado notebook no consegue acessar o ERP, a equipe esteve no local e
identificou que o cabo de rede estava com problemas. A partir disso, eles iriam acionar
a rea responsvel para reparo, porm existe a possibilidade do notebook acessar a
rede Wi-fi (sem fio) e o usurio poder utilizar o sistema. Nesse caso considerado
soluo de contorno, pois a rede Wi-fi no oferece a mesma velocidade e instabilidade
da rede cabeada.
5 - Impede operao sem sada de contorno: situao semelhante a
prioridade anterior, diferindo apenas da no existncia de uma soluo de contorno.
Tomando como base o exemplo anterior, o nosso notebook no teria uma rede Wi-fi
disponvel, desta forma ficaria aguardando o reparo do cabo de rede. O Quadro 29
apresenta os passos desta atividade.

Quadro 28 - Priorizao do Incidente
Objetivos: Priorizar o incidente
Papis Principais:
Analista I;
Papis Adicionais:
Entrada:
Incidente categorizado
Sada:
Incidente categorizado e priorizado
Passos:
1. Verificar urgncia e os impactos causados aos negcios da organizao;

Detalhamento da execuo: As urgncias e impactos foram definidas juntamente com a equipe de
apoio da atividade, com base na Tabela 6 - Sistema de priorizao de incidentes, onde buscamos um
cruzamento entre Impacto e urgncia. Alm destas urgncias existia uma lista VIP com usurios chave,
onde a prioridade era diferente da normal.


Detalhamento da execuo: Os incidentes foram priorizados de 1 a 5, onde 1 significa baixa
prioridade e 5 prioridade mxima. Esta priorizao considerava a urgncia e impactos que os incidentes
causavam aos negcios da organizao.

4.3.5 Atividade: analisar incidente

Nesta atividade a equipe de incidentes deveria buscar solues similares
existentes na base, atravs de RBC e PLN. No nosso estudo de caso esta atividade foi
realizada de forma manual. No buscamos automatizar com o uso de nenhuma
106

ferramenta, pois este no o foco do nosso trabalho e esta automatizao j havia sido
realizada em outro trabalho (CARVALHO, 2012a), aonde foi comprovada sua eficcia e
eficincia.
Aps anlise inicial, o especialista informava em um campo textual da
planilha qual(is) incidente(s) eram similares, para que na prxima atividade a equipe
fizesse uso destas informaes. No Quadro 29 apresentamos os passos seguidos.

Quadro 29- Anlise do Incidente
Objetivos: Analisar o incidente
Papis Principais:
Analista I;
Papis Adicionais:
Entrada:
Sada:
conhecimento.
Passos:
1. Buscar soluo na base de conhecimento;

Detalhamento da execuo: A busca foi realizada manualmente, pois no automatizamos o uso de
ferramenta, pois este no o foco do nosso trabalho e esta automatizao j havia sido realizada em
outro trabalho (CARVALHO, 2012), aonde foi comprovada sua eficcia e eficincia.

2. Analisar os incidentes similares e verificar a compatibilidade com o incidente atual;
3. Encaminhar os incidentes similares para a prxima atividade.

Detalhamento da execuo: Neste passo verificvamos a compatibilidade entre os incidentes (na
base e atual) separando os similares.Os incidentes similares separados no passo anterior eram
encaminhados para o analista responsvel pela prxima atividade (Resolver Incidente).

4.3.6 Atividade: resolver incidente (N1)

Com base nas informaes recebidas da atividade anterior a equipe
analisava se os casos recuperados eram similares e se possuam informaes que
pudessem ser reutilizadas na soluo do incidente atual. Caso esse nvel de
atendimento conseguisse solucionar o incidente, o chamado era repassado direto para
a atividade Analisar impactos e causas do incidente, para que outra equipe verificasse
os impactos que aquele incidente ocasionou e buscasse, na outra atividade, uma
soluo para reduzir a ocorrncia do incidente.
107

Caso as informaes no fossem suficientes ou no se enquadrassem no
incidente atual, ou a soluo no fosse responsabilidade desse Nvel de atendimento, o
incidente era repassado para o segundo nvel de atendimento. O Quadro 30 apresenta
os passos para esta e para a prxima atividade (Resolver Incidente N2).

Quadro 30- Resolver Incidente
Objetivos: Resolver incidente
Papis Principais:
Analista I;
Analista II;
Papis Adicionais:
Solicitante;
Entrada:
conhecimento.
Sada:
Incidente resolvido;
Escalonamento para a equipe de Nvel 2;
Possvel problema.
Passos:
1. Verificar se os incidentes similares so realmente compatveis com o caso em anlise;
2. Solucionar o incidente;
3. Registro de uma nova soluo na base de conhecimento.
Detalhamento da execuo: Verificvamos se os incidentes sinalizados eram similares ao ocorrido.Se
os casos fossem similares, as solues adotadas eram utilizadas para este incidente. Caso contrrio,
se as solues utilizadas anteriormente no fossem suficientes para a resoluo do incidente, o analista
buscava uma soluo e, ao conseguir, documentava a nova soluo na base.

4.3.7 Atividade: resolver incidente (N2)

A equipe deste nvel recebia as informaes da outra equipe (N1) e
verificava se tratava-se de um incidente ou de um problema. No caso de um problema a
equipe encaminhava para a atividade Implementar Soluo de Contorno, para que uma
soluo definitiva fosse implementada at a resoluo do incidente. No caso de no
haver um problema, a equipe N2 dava prosseguimento ao atendimento.
Caso no existissem incidentes similares, a equipe N2 resolvia o incidente e
em seguida registrava, detalhadamente, a soluo na planilha. O intuito de realizar esse
detalhamento era auxiliar os prximos atendimentos que classificassem esse incidente
como similar. Esta recomendao tambm era vlida para os casos onde fossem
necessrios ajustes nas solues existentes. Aps solucionar o incidente a equipe
encaminhava para a atividade Analisar impactos e causas do incidente.

108

4.3.8 Atividade: implementar soluo de contorno

Se o incidente fosse recorrente, poderamos suspeitar de um problema e,
caso existisse, implementvamos uma soluo de contorno. Esta soluo era vista
como temporria, devendo durar at a resoluo do incidente. Dando sequncia ao
nosso exemplo do notebook, o mesmo s deveria permanecer conectado na rede Wi-fi
at o momento que o reparo do cabo de rede fosse realizado. importante que a
soluo de contorno no seja utilizada repetidamente e que no seja vista como
soluo definitiva. O Quadro 31 apresenta os passos seguidos.

Quadro 31- Soluo de Contorno
Objetivos: Implementar uma soluo de contorno (caso exista)
Papis Principais:
Analista I;
Papis Adicionais:
Solicitante;
Entrada:
Problema
Sada:
Execuo da soluo de contorno
Passos:
1. Checar se existe soluo alternativa, ou seja, uma soluo que mantenha o funcionamento do
negcio da organizao;
2. Implementar a soluo de contorno;

Detalhamento da execuo: Verificvamos a existncia de uma soluo alternativa para o incidente
em anlise. Caso existisse uma soluo alternativa a mesma era implementada.

4.3.9 Subprocesso: gerenciamento de problemas

Este subprocesso no foi escopo do nosso trabalho, mas o mesmo tem a
finalidade de resolver possveis problemas, que por ventura venham ocorrer no caso de
incidentes recorrentes.

4.3.10 Atividade: analisar impacto e causas do incidente

Os impactos e causas que o incidente provocava na organizao eram
registrados na base, conforme pode ser visto no Apndice C. Isto ajudou na
109

visualizao de possveis impactos no momento que o caso similar foi recuperado.
Desta forma, a equipe pde se antecipar e analisar a necessidade de alocar ou no
mais recursos na soluo do incidente, tendo em vista o tamanho do impacto que o
incidente poderia causar. O Quadro 32 apresenta os passos seguidos para uma
completa execuo desta atividade.

Quadro 32- Anlise dos Impactos Causados pelo Incidente
Objetivos: Analisar os impactos causados e o motivo do acontecimento do incidente
Papis Principais:
Analisa I.
Papis Adicionais:
Entrada:
Incidente resolvido.
Sada:
- Impactos causados e o provvel motivo que levou ao
acontecimento do incidente;
- Aes a serem tomadas
Passos:
1. Analisar possveis impactos no negcio e determinar aes a serem tomadas sobre os incidentes;
2. Identificar possveis causas que geraram o incidente e determinar aes que devem serem
tomadas para evitar que o incidente ocorra novamente.

Detalhamento da execuo: Os impactos eram analisados o que permitia a equipe antecipar-se a
determinados incidentes e aes eram tomadas para evitar que o incidente ocorresse novamente.

4.3.11 Atividade: encerrar incidente

Aps concluso do atendimento, o especialista entrava em contato (e-mail ou
telefone) com o solicitante e validava as solues adotadas. O contato poderia at ser
realizado pessoalmente, mas a validao do encerramento era realizada via e-mail ou
telefone. Os incidentes s foram encerrados quando o solicitante ficou de acordo com a
soluo adotada.O Quadro 33 apresenta os passo seguidos nesta atividade.
110

Quadro 33- Encerramento do Incidente
Objetivos: Realizar o encerramento formal do incidente, comunicando as partes envolvidas.
Papis Principais:
Analista I
Papis Adicionais:
Solicitante
Entrada:
- Incidentes resolvidos;
- Aes executadas.
Sada:
- Formalizao do encerramento do incidente;
- Comunicar as partes envolvidas.
Passos:
1. Analisar informaes do incidente (categoria, priorizao, documentao, entre outros);

Detalhamento da execuo: Neste passo as informaes eram conferidas, via telefone ou
pessoalmente ou e-mail, e verificvamos se o incidente ainda ocorria.

2. Formalizao do encerramento do incidente;

Detalhamento da execuo: Caso o incidente houvesse sido solucionado formalizvamos o
encerramento do incidente por e-mail. Caso no estivesse solucionado o chamado deveria ser
devolvido para a equipe de resoluo.


Detalhamento da execuo: Aps o aceite (positivo) do solicitante o incidente era encerrado e o
solicitante comunicado via e-mail da normalizao do servio.

4.4 Anlise dos Resultados

Aps a execuo do estudo de caso, podemos concluir que as hipteses H1
e H2 foram confirmadas. Na hiptese H1 (O processo proposto eficaz) podemos
concluir que o indicador definido foi alcanado devido ao resultado da pesquisa
aplicada com um dos usurios do processo.
O Processo foi validado em uma organizao de economia mista, com sede
em Fortaleza. Ns construmos uma base de dados com aproximadamente 100
incidentes coletados aps a implantao de um sistema ERP. Nossa hiptese de
pesquisa foi: o uso de componentes de RBC e PNL em um Processo de Gerenciamento
de Incidentes otimiza o tratamento de incidentes. A validao desta hiptese foi
qualitativa, atravs de uma pesquisa com os usurios do processo, aonde as questes
e o resultado esto apresentados no Quadro 34. O questionrio era formado pelas
questes:
111

Quadro 34-Resultado Compilado da Pesquisa
Questo Avaliao
O Processo Proposto possui atividades suficientes para
o Gerenciamento de Incidentes
Concordo
O Processo Proposto eficaz, ou seja, faz aquilo que
dever ser feito, realizando o que foi proposto
Concordo Fortemente
O registro e categorizao dos incidentes em uma
planilha auxiliaram durante o planejamento da soluo
dos incidentes
Concordo
A atividade do Processo proposto, Priorizar Incidente,
contribuiu para um melhor planejamento durante os
atendimentos dos incidentes
Concordo
A utilizao de uma base de conhecimentos auxiliou
durante a execuo das atividades de Anlise e
Resoluo do Incidente
Concordo
A atividade Implementar Soluo de Contorno, quando
necessria, mostrou-se eficiente, amenizando os
impactos gerados pelo incidente e restaurando os
servios mesmo que provisoriamente
Concordo fortemente
A atividade do processo proposto, Encerrar Incidente,
ao retornar para o solicitante a soluo implementada,
melhorou a comunicao entre a rea demandante e a
rea responsvel pelo atendimento
Concordo

Alm das perguntas tambm foram avaliados pontos fortes e oportunidades
de melhoria. Em relao aos pontos fortes destacou-se a possibilidade de utilizao de
uma ferramenta de apoio baseada em RBC com PLN. E em relao s Oportunidades
de Melhoria, identificamos a necessidade de melhorar consideravelmente a descrio
dos incidentes, bem como a sua categorizao, de forma que as tcnicas de IA possam
agregar mais valor abordagem proposta.
Na hiptese H2 (RBC e PLN melhoram o reuso de experincias), Carvalho
(2012a) realizou testes experimentais para avaliar o quanto as medidas de
similaridades propostas aumentam a preciso na recuperao de casos similares,
consequentemente melhoram o tempo de analise de incidentes. O teste realizado por
Carvalho (2012a) consistiu em diversas baterias de testes em dois Cenrios, onde o
Cenrio 1 (C1) fez uso apenas de clculos sobre atributos e o Cenrio 2 (C2) fez uso
do processo proposto eRbc. Ao analisar cada cenrio,Carvalho (2012a) verificou que o
C2, que usou o processo eRbc, trouxe um ganho de 35.8% em relao ao C1, o qual
usou apenas clculos sobre os atributos do caso. Desta forma, constatou que o uso de
um campo descritivo na recuperao de casos similares trouxe ganhos significativos em
112

relao a apenas uma abordagem de similaridade sinttica, pois, ao analisar o
conhecimento armazenado dentro da descrio, possvel determinar com mais
exatido a semelhana entre textos.
Desta forma, como o planejamento desta atividade foi similar ao trabalho de
Carvalho (2012a) (tipos e caractersticas dos campos utilizados, algoritmo de
similaridade, pesos e ndices, entre outros) optamos por no desenvolv-la tendo em
vista que os resultados do indicador seguiriam pela mesma tendncia.

4.5 Lies Aprendidas

Apesar de o processo ter sido aplicado de forma eficaz, foram identificadas
algumas dificuldades e lies aprendidas:

Na atividade Categorizar Incidente houve um pouco de dificuldades
para definir que tipos de incidentes se enquadravam em um
determinado tipo de categoria.
A priorizao do incidente foi fundamental, auxiliando durante a
gerao da fila de atendimento.
Para a Anlise do Incidente, a abordagem foi bem estruturada, no
entanto, um sistema de recuperao de casos auxilia bastante esta
etapa.
O processo de Gerenciamento de Problemas, que no foi objeto deste
trabalho, poderia ser beneficiado, tambm, com a aplicao de RBC e
PLN.
Uma boa anlise de impactos e causas do incidente auxilia bastante
na identificao de solues para reduzir a sua recorrncia.

113


Nesse captulo foi apresentado o estudo de caso utilizando o processo
proposto em uma base de incidentes em uma organizao de economia mista, bem
como, foram detalhados os artefatos utilizados durante o estudo. Finalmente, foram
apresentadas as principais lies aprendidas oriundas da execuo do referido
processo. O captulo seguinte apresenta a concluso deste trabalho bem como
perspectivas de trabalhos futuros.
114

5 CONCLUSES E TRABALHOS FUTUROS

Neste captulo so apresentadas as concluses finais do trabalho, focando
nas contribuies, limitaes e trabalhos futuros.

5.1 Consideraes Finais

Com este trabalho podemos evidenciar a relevncia de sistematizar a
gerncia de incidentes em qualquer organizao de TI, alm de compreender a
relevncia do apoio de ferramentas automatizadas, utilizando-se de abordagens da
Engenharia do Conhecimento, como o caso do Raciocnio Baseado em Casos e
Processamento de Linguagem Natural. Outro ponto importante a ser destacado a
relevncia de se definir e implantar processos de servio baseados nas principais
normas, guias e modelos de maturidade relacionados a servios, como o caso do
CMMI para Servios.
O tema incidente tem se mostrado bastante relevante no meio empresarial
e cada vez mais, pesquisas so realizadas com o intuito de conseguir melhores prticas
para trat-los.
Em nosso trabalho, verificou-se que a aplicao do processo proposto na
organizao possibilitou uma melhoria no tempo de atendimento dos incidentes, alm
de propiciar a percepo de como importante registrar e gerenciar os incidentes,
eliminando ou reduzindo o impacto que estes podem causar. O processo aqui
apresentado e seus artefatos podero ser de grande utilidade para as organizaes que
desejem iniciar o tratamento de incidentes ou que j possuem e querem melhor-lo.
Estes artefatos apresentam as etapas que as organizaes podem seguir, no intuito de
preparar ou aperfeioar o ambiente para utilizao de RBC com PLN, as etapas so
sugestivas e, caso necessrio, pode-se optar por no realizar todas ou providenciar
alteraes em etapas que no tero serventia nenhuma em sua estrutura.
115

Finalmente, observamos que as organizaes devem manter um
gerenciamento contnuo sobre os incidentes, buscando novos processos com o intuito
de diminuir a ocorrncia destes incidentes.

5.2 Principais Contribuies

Como principais contribuies do trabalho, podemos destacar:
Definio do Processo Gesto de Incidentes para o tratamento de
incidentes, aderente ao CMMI for Services (CMMI-SVC). Este
processo pode ser utilizado em conjunto com as tcnicas de RBC e
PLN ou apenas o processo para gesto de incidentes tradicional;
Definio detalhada dos passos necessrios para que qualquer
organizao possa planejar e implementar solues que envolvam a
combinao da abordagem RBC com PLN.
Desenvolvimento de dois artefatos: Plano de RBC e Plano de PLN,
com o intuito de apoiar as organizaes que desejem tratar os
incidentes com o apoio de RBC e PLN durante a Resoluo do
Incidente, objetivando melhorar o tempo de atendimento dos
incidentes;
Uma base de incidentes registrados, categorizados e priorizados, com
o intuito de auxiliar as organizaes a montarem suas prprias bases
para registro e tratamento dos incidentes.

5.3 Limitaes

O processo proposto foi executado em apenas uma organizao, o
que pode ser considerada uma limitao na avaliao da eficcia do
processo. Porm, uma das contribuies deste trabalho
disponibilizar os procedimentos necessrios para que outras
organizaes possam fazer uso do processo, de forma a sanar essa
limitao. Qualquer organizao pode fazer uso dos procedimentos
116

aqui apresentados, mas importante que as organizaes tenham
conhecimentos prvios no Gerenciamento de Incidentes, garantindo
as adaptaes do processo que se fizerem necessrias.
A avaliao da eficcia do processo foi realizada apenas por um
profissional.
A ferramenta para recuperao de casos similares, utilizando RBC e
PLN, no foi desenvolvida para ser utilizada no estudo de caso.

5.4 Trabalhos Futuros

Algumas possibilidades de trabalhos futuros foram identificadas:
Executar o processo em uma grande base de incidentes;
Adaptar o Processo Gerenciamento de Problemas para fazer uso
das tcnicas RBC e PLN;
Desenvolver uma ferramenta para apoiar todo o processo,
principalmente para automatizar a atividade Analisar Incidente, com o
intuito de avaliar o uso das tcnicas de Inteligncia Artificial:
Raciocnio Baseado em Casos e Processamento de Linguagem
Natural na anlise e resoluo de incidentes;
Aplicar o processo em outras organizaes, de forma a poder avaliar
melhor a eficcia do processo proposto;
117

REFERNCIAS

ABNT. Associao Brasileira de Normas Tcnicas. [S.l.], [20--]. Disponvel em:
<http://www.abnt.org.br>. Acesso em: 13 set. 2012.

AHTELA, A.; JNTTI, M.; KAUKOLA, J. Implementing an ITIL-based IT service
management measurement system. In: CONFERENCE INTERNATIONAL ON DIGITAL
SOCIETY, 4., 2010, St. Maarten. Proceedings St. Maarten: [s.n.], 2010.

BLOG DA TECLGICA.Semelhanas e diferenas entre ITIL e CMMI para servios.
[S.l.], [20--].

BONTCHEVA, K. et al. Twitie: An open-source information extraction pipeline for
microblog text. In: Proceedings of the International Conference on Recent Advances in
Natural Language Processing. Association for Computational Linguistics. [S.l.: s.n.],
2013.

BRANDOM, R. B.Articulating reasons: an introduction to inferentialism. Harvard:
Harvard University Press, 2000. Disponvel em:
<http://www.worldcat.org/isbn/0674001583>. Acesso em: 2014.

CAO, Chaojie; ZHAN, Zhiqiang. Incident management process for the cloud computing
environments. In: IEEE CCIS, 2011, [S.l.].Proceedings[S.l.]: IEEE,2011.

CARNEGIE MELLON UNIVERSITY. CMMI. [S.l.], 2014. Disponvel em:
<http://www.sei.cmu.edu/cmmi/>. Acesso em: 21 set. 2011.

CARVALHO, Thiago Leite e. ERbc: um processo para apoiar a engenharia de
requisitos atravs do reuso de experincias.Fortaleza: [s.n.], 2012a. 125 p.

CARVALHO, Thiago Leite e. Um processo de recuperao de casos usando
processamento de linguagem natural: uma aplicao na engenharia de
requisitos.Fortaleza: [s.n.], 2012b.

CONCEPTNET. [S.l.: s.n.], [20--]. Disponvel em: <http://conceptnet5.media.mit.edu/>.
Acesso em: 2014.
118

COSTA, Thiago Moreira da. Melhoria contnua de processos de software utilizando
a teoria das restries. Rio de Janeiro: UFRJ, 2012.

CUSICK James J.; MA, Gary. Creating an ITIL inspired incident management approach:
roots, response, and results. In: NETWORK OPERATIONS AND MANAGEMENT
SYMPOSIUM WORKSHOPS, 2010, [S.l.]. Proceedings [S.l.]: IEEE, 2010.

DE HAES, Steven; VAN GREMBERGEN, Wim. An exploratory study into IT governance
implementations and its impact on business: IT alignment. Information Systems
Management, v. 26, p. 123-137, 2009. Disponvel em:
<http://www.teclogica.com.br/blog/?p=508>. Acesso em: 24 set. 2013.

DORNELAS, Francisco Coutinho et al. Alinhamento estratgico de Tecnologia da
Informao (TI): um estudo da prtica de empresa do setor siderrgico brasileiro. In:
ENCONTRO DA ANPAD, 34., 2010, Rio de Janeiro. Anais... Rio de Janeiro: [s.n.],
2010. Disponvel em: <http://www.fucape.br/_public/producao_cientifica/2/Dornelas%20-
%20Alinhamento%20Estrategico.pdf>. Acesso em: 2014.

FREELING 3.1.[S.l.: s.n.], [20--]. Disponvel em: <http://nlp.lsi.upc.edu/freeling/>. Acesso
em: 2014.

GENTIL, Frederico. Novidades do COBIT 5. [S.l.: s.n.], [20--]. Disponvel em:
<http://fredgentil.com.br/artigos/novidades-do-cobit-5/>. Acesso em: 17 jan. 2014.

GILDEA,Daniel; JURAFSKY, Daniel.Automatic labeling of semantic
roles.Computational Linguistics, v. 28, n. 3, p. 245-288,2002.

GUO, Wei; WANG, Ying.An incident management model for SaaS application in the IT
organization. In: INTERNATIONAL CONFERENCE ON RESEARCH CHALLENGES IN
COMPUTER SCIENCE, 2009, [S.l.]. Proceedings [S.l.]: IEEE, 2009.

HALL, Johan; NILSSON, Jens; NIVRE,Joakim. MaltParser. [S.l.: s.n.], [20--]. Disponvel
em: <http://www.maltparser.org/>. Acesso em: 2014.

ISO. Tecnologia da informao: gesto de servios: parte 1: requisitos do sistema de
gesto de servios. Rio de Janeiro, 2011. 30 p.
119

IT GOVERNANCE INSTITUTE. COBIT 4.1: modelo, objetivos de controle, diretrizes de
gerenciamento, modelos de maturidade. [S.l.], [2007]. 200 p.

ITIL. Glossrio e abreviaes ITIL. [S.l.], [20--]. Disponvel em: <http://www.itil-
officialsite.com/InternationalActivities/ITILGlossaries_2.aspx>. Acesso em: 17 set. 2013.

TSO. The official introduction to the ITIL service lifecycle.Norwich, 2007.

ITIL. Welcome to the official ITIL. [S.l.], [20--]. Disponvel em: <http://www.itil-
officialsite.com/>. Acesso em: 24 set. 2011.

JNTTI, Marko. Defining requirements for an incident management system: a case
study. In: INTERNATIONAL CONFERENCE ON SYSTEMS, 4., 2009, [S.l.].
Proceedings [S.l.]: IEEE, 2009.

KAY, M. Introduction to computational linguistics. In: MITKOV, R. (Ed.). Handbook of
computational linguistics. Oxford: Oxford University Press, 2003. p. 17-20.

KITCHENHAM, B. Procedures for performing systematic reviews. [S.l.]: Keele
University and NICTA, 2004.(Joint Technical Report Keele University TR/SE-0401 and
NICTA Technical Report 0400011T.1).

LAHTELA, Antti; JNTTI, Marko. Challenges and problems in release management
process: a case study. [S.l.]: IEEE, 2011.

LEAKE, David B. Case-based reasoning: experiences, lessons, and future directions.
Menlo Park: AAAI Press, 1996.

LEE, G. G. et al. Siteq: engineering high performance QA system using lexico-
semantic pattern matching and shallow NLP. In: TREC.[S.l.: s.n.], 2001.

MAFRA, S. N. Infraestrutura para automatizao de processos de software. 2004.
Monografia de Projeto Final de Curso, DCC/IM, UFRJ, - Universidade Federal do Rio
de Janeiro, Rio de Janeiro, 2004.
120

MAFRA, S. N.; TRAVASSOS, G. H.Estudos primrios e secundrios apoiando a
busca por evidncia em engenharia de software. Rio de Janeiro: UFRJ, 2006.
(Relatrio Tcnico RT-ES, 687).

OBJECT MANAGEMENT GROUP. Business process model and notation.[S.l.],
[2012?]. Disponvel em: <http://www.bpmn.org>. Acesso em: 14 fev. 2013.
MALTPARSER. [S.l.: s.n.], [20--]. Disponvel em: <http://www.maltparser.org/>. Acesso
em: 2014.

PADR, L.; STANILOVSKY, E. Freeling 3.0: towards wider multilinguality. In:
EUROPEAN LANGUAGE RESOURCES ASSOCIATION, 2012,[S.l.].
Proceedings[S.l.: s.n.], 2012.

PAIVA, Edgy Eduardo Enas de Arruda. Uma abordagem de apoio avaliao e
melhoria da produtividade de desenvolvedores de software. 2011. f.170.
Dissertao (Mestrado em Informtica) Universidade de Fortaleza, Fortaleza, 2011.

PARDO,T.A. S.; CASELI,H.M.; NUNES,M.G.V. Mapeamento da comunidade brasileira
de processamento de lnguas naturais. In: BRAZILIAN SYMPOSIUM IN INFORMATION
AND HUMAN LANGUAGE TECHNOLOGY, 7., [20--], [S.l.]. Proceedings [S.l.: s.n.],
[20--].

PINHEIRO, V. et al. Inferencenet.br: expression of inferentialist semantic content of the
Portuguese language. In: PARDO, T.A.S. et al. (Ed.).PROPOR 2010, LNAI 6001.[S.l.]:
Springer, [20--]. p.90-99.

PINHEIRO, V. et al. Towards a common sense base in Portuguese for the linked open
data cloud. PROPOR, p. 128-138, Springer 2012.

PRINCETON UNIVERSITY. What is wordnet?.[S.l.], [20--].Disponvel em:
<http://wordnet.princeton.edu/>. Acesso em: 2014.

RADOVANOVIC, D. et al. Necessity of IT service management and IT governance. In:
INTERNATIONAL CONVENTION ON INFORMATION AND COMMUNICATION
TECHNOLOGY, ELECTRONICS AND MICROELECTRONICS, 34., 2011, [S.l.].
Proceedings [S.l.: s.n.], 2011.

121

SILVA, B. C. D. da et al. Introduo ao processamento das lnguas naturais e
algumas aplicaes. [S.l.: s.n.], 2007.

SILVA, Jos Wellington Franco da.Aquisio de conhecimento de mundo para
sistemas de processamento de linguagem natural. [S.l.: s.n.], [2013].

SOCIEDADE BRASILEIRA DE COMPUTAO. [S.l.], [20--]. Disponvel em:
<http://www.sbc.org.br/>. Acesso em: 12 nov. 2013.

SOFTEX.BR. Guia geral MPS de servio. [S.l.], [20--]. Disponvel em:
<http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_Servicos_2012.pdf>.
Acesso em: 13 set. 2012.

SOFTWARE ENGINEERING INSTITUTE. CMMI for services: version 1.3: improving
processes for providing better services. [S.l.], 2010. (Technical Report). Disponvel em:
<http://www.sei.cmu.edu/reports/10tr034.pdf>. Acesso em: 5 jan. 2012.

SOON, W. M.; NG, H. T.; LIM, D. C. Y. A machine learning approach to coreference
resolution of noun phrases. Computational Linguistics, v. 27, n. 4, p. 521-544, 2001.

STEVENSON, M.; WILKS, Y.The Interaction of knowledge sources in word sense
disambiguation. Computational Linguistics, v. 27, n. 3, p. 321-349,2001.

TABOADA, M.; ANTHONY, C.; VOLL, K. Methods for creating semantic orientation
dictionaries. In: INTERNATIONAL CONFERENCE ON LANGUAGE RESOURCES AND
EVALUATION, 5., 2006, Genova. Proceedings[S.l.: s.n.], 2006.

TEHRANI, Abtin Refahi Farjadi; MOHAMED, Faras Zuheir Mustafa. A CBR-based
approach to ITIL-based service desk.Journal of Emerging Trends in Computing and
Information Sciences, v. 2, n. 10, 2011.

TREETAGGER: a language independent part-of-speech tagger. [S.l.: s.n.], [20--].
Disponvel em: <http://www.cis.uni-muenchen.de/~schmid/tools/TreeTagger/>. Acesso
em: 2014.

122

VON WANGENHEIN, Aldo. Similaridade de casos no raciocnio baseado em casos.
Raciocnio baseado em casos. [S.l.: s.n.], [20--]. Disponvel em:
<http://www.inf.ufsc.br/~casos/similaridade.html>. Acesso em: 26 dez. 2013.

VON WANGENHEIM, Aldo; VON WANGENHEIM, Christiane Gresse. Raciocnio
baseado em casos. [S.l.]: Manole, 2003.300 p.

WEBB, P.; POLLARD, C.; RIDLEY, G. Attempting to define IT governance: wisdom or
folly. In: HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES, 39.,
2006, [S.l.]. Proceedings [S.l.: s.n.], 2006.

YIN, Robert K. Case study research: design and methods. 3th ed. [S.l.: s.n.], 2003.
(Applied Social Research Methods Series, v. 5).
123

APNDICE A - Plano de RBC

1 Introduo
Este documento define o Plano de RBC, com o objetivo de apresentar a estrutura do
plano, facilitando o entendimento geral do mesmo.
1.1 Convenes, termos e abreviaes.
Esta subseo descreve as convenes, termos e abreviaes necessrios para
interpretar apropriadamente este documento.
RBC Raciocnio Baseado em Casos
Base Planilha em Excel
Campos Colunas da planilha utilizadas para preenchimento de informaes
Similaridade Informar se um caso similar a outro
2 Ttulo da Base
Planilha com o registro de incidentes.
3 Justificativa
Base apta para utilizar RBC.
4 Campos que podem ser utilizados
Categoria
Priorizao
Soluo de contorno

5 Validao dos campos

Campo Anlise
Categoria Este campo possui mais de uma opo e
pode ser utilizado na recuperao de
casos similares
Priorizao Este campo possui mais de uma opo e
casos similares
Soluo de
Contorno
Este campo possui atributo do tipo
Verdadeiro ou Falso. Este campo no
contribui para a recuperao de casos,
pois o mesmo apenas cita se o incidente
possui ou no soluo de contorno, o que
o torna vago olhando para as demais
informaes. Desta forma no ser
utilizado neste momento.

6 Modelos dos Casos

7 Definio de ndice e Pesos
Para um melhor resultado na utilizao de RBC, torna
os pesos e os ndices dos campos, podendo os valores definidos ser ajustados de
acordo com a necessidade de cada base. Em nosso estudo de caso
de opinio de especialista na rea, peso 3 ao campo Categoria e peso 2 ao campo
Priorizao. Alm do peso necessrios definirmos o valor de semelhana entre os
ndices (campos) utilizados. Conforme medida de similaridade (Sim
Validao dos campos
Tipo
Este campo possui mais de uma opo e
casos similares
Atributo-valor
Este campo possui mais de uma opo e
casos similares
Atributo-valor
Este campo possui atributo do tipo
Verdadeiro ou Falso. Este campo no
contribui para a recuperao de casos,
pois o mesmo apenas cita se o incidente
possui ou no soluo de contorno, o que
o torna vago olhando para as demais
informaes. Desta forma no ser
utilizado neste momento.
Atributo-valor
Modelos dos Casos
Definio de ndice e Pesos
Para um melhor resultado na utilizao de RBC, torna
acordo com a necessidade de cada base. Em nosso estudo de caso
124

Status Qtde
OK 1
OK 1
No 1

Para um melhor resultado na utilizao de RBC, torna-se obrigatrio definir
acordo com a necessidade de cada base. Em nosso estudo de caso atribumos, atravs
A
) proposta na seo
125

3.2.1.3 (Definir ndices e pesos) a similaridade deve ser calculada aps definio dos
valores de semelhanas entre os atributos.
Para ttulo de exemplificao definiremos a existncia de dois casos (c1 e c2)
e dois atributos Campo (a1) e Priorizao (a2). As Tabelas 1A e 2A apresentam estes
valores.

Tabela 1A - Valores de Semelhanas do Atributo a1 (Campo)
v1 v2
v1 1 0.6
v2 0.6 1
Fonte:Elaborao do Prprio Autor

Tabela 2A - Valores de Semelhanas do Atributo a2 (Priorizao)
v3 v4
v3 1 0.2
v4 0.2 1

Antes de calcular a medida de similaridade definimos que a nossa nota de
corte, ou seja, o valor que ser comparado para aceitar ou no um caso como similar
ser de 0.5. Em seguida aplicamos a medida de similaridade (Sim
A
) e encontramos o
valor de 0.44. Como nossa nota de corte havia sido definida como 0.5 estes casos no
so considerados similares.
Durante a execuo desta atividade no criticamos se os casos realmente
no eram similares. Para realizar esta verificao cabe uma anlise manual e criteriosa
dos casos, ou seja, voc dever checar, de forma aleatria, alguns casos para saber se
o resultado encontrado no clculo da medida de similaridade condiz com a realidade.
Para ajudar nesta etapa, sugerimos a utilizao de uma avaliao atravs de uma
medida de desempenho chamada F-score, tambm apresentada na seo 3.2.1.3.
No nosso estudo de caso, no foi necessrio a criao de um campo textual,
pois a base j possua um campo utilizado para descrever o incidente. Alm do campo
citado, a base possua tambm um campo onde o atendente informava a soluo do
incidente.
126

8 Campo textual criado
No foi necessria a criao deste campo
127

APNDICE B - Plano de PLN

1 Introduo
Este documento define o Plano de PLN, com o objetivo de apresentar a estrutura do
plano, facilitando o entendimento geral do mesmo.
1.1 Convenes, termos e abreviaes.
Esta subseo descreve as convenes, termos e abreviaes necessrios para
interpretar apropriadamente este documento.
Processamento de Linguagem Natural(PLN)
Ontologia Modelo de dados que representa um conjunto de dados de um
domnio
Similaridade Informar se um caso similar a outro
2 Terminologia do Domnio
Backup: cpia de segurana;
Banco de Dados (Data Base): conjunto de dados sobre um assunto especfico
permitindo fcil consulta;
Service Level Agreement (SLA): nvel de servio normalmente acordado entre
cliente e fornecedor;
Incidente: Segundo o ITIL uma interrupo no planejada ou reduo na
qualidade de um servio de TI;
Incident Resolution and Prevention (IRP): Preveno e Resoluo de Incidentes;
Problema: causa desconhecida de um ou mais incidentes;
Raciocnio Baseado em Casos (RBC).
3 Abordagem de Similaridade Textual
Similaridade Textual (Sim
D
) proposta por Carvalho (2012a).
4 Justificativa da escolha da Similaridade
Utilizamos a mesma similaridade, visto que esta etapa no foi executada em nosso
trabalho e seguimos a proposta de Carvalho (2012a).
128

5 Anlise e validao do campo textual
Em nosso estudo de caso temos dois campos textuais, o campo descrio e o campo
soluo, em ambos possvel fazer uso de PLN. Para validar os campos podemos
fazer uso de ferramentas que iro gerar indicadores de status dos campos, ou seja,
estes indicadores devem nortear a deciso de escolher ou no o campo para aplicar
PLN.
Em nosso estudo de caso, no utilizamos ferramentas para validao do campo textual,
mas na seo 3.2.1.6 (Analisar e validar campo textual) citamos exemplos de
ferramentas que apoiaro esta atividade. A primeira, Detector de Sentenas,
responsvel por dividir o texto em sentenas. J a segunda, Tokenizador, separa as
sentenas em tokens e a terceira, POS-Tagger, por sua vez classifica cada token de
acordo com sua classe gramatical. Aps aplicao destas ferramentas pode-se fazer
uso de indicadores, conforme sugerido na mesma seo, como exemplo: I1 Frase
bem formada e I2 Quantidade de verbos na sentena.
Para que um campo seja considerado vlido chegamos a concluso que o mesmo
dever apresentar um bom contedo textual, ou seja, atender plenamente ao indicador
1 (I1), alm de possuir pelo menos um verbo por sentena no texto e, finalmente,
apresentar pelo menos 50% dos seus tokens no domnio definido. Esta concluso pode
ser alterada de acordo com o contexto do domnio.
129

APNDICEC - Base de Incidentes e Parecer

Figura 1A - Base de Incidentes


Dissertacao Glauber PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Dissertacao Glauber PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

FUNDAO EDSON QUEIROZ

Anda mungkin juga menyukai