UNIVERSIDADE DO SUL DE SANTA CATARINA
JANDERSON COSTA
SISTEMA DE HELP DESK
UTILIZANDO RACIOCÍNIO BASEADO EM CASOS
Palhoça
2011
JANDERSON COSTA
SISTEMA DE HELP DESK
UTILIZANDO RACIOCÍNIO BASEADO EM CASOS
Trabalho de Conclusão de Curso apresentado ao Curso
de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina, como requisito
parcial à obtenção do título de Bacharel em Sistemas de
Informação.
Orientador: Prof. Saulo Popov Zambiasi, Msc.
Palhoça
2011
JANDERSON COSTA
SISTEMA DE HELP DESK
UTILIZANDO RACIOCÍNIO BASEADO EM CASOS
Este Trabalho de Conclusão de Curso foi julgado
adequado à obtenção do título de Bacharel em Sistemas
de Informação e aprovado em sua forma final pelo
Curso de Sistemas de Informação, da Universidade do
Sul de Santa Catarina.
Palhoça, 21 de novembro de 2011.
_____________________________________
Prof. e orientador Saulo Popov Zambiasi, Msc.
Universidade do Sul de Santa Catarina - UNISUL
_____________________________________
Prof. Theo Augustus Luz, Esp.
Universidade do Sul de Santa Catarina - UNISUL
_____________________________________
Prof. Jean Carlo Rossa Hauck, Dr.
Universidade do Sul de Santa Catarina - UNISUL
À minha mãe Elizete, a responsável pela
minha formação e que sempre esteve presente
nos momentos decisivos de minha vida.
AGRADECIMENTOS
Ao meu orientador Saulo Popov Zambiasi, por me guiar no caminho das pedras.
A todos os professores do Curso de Sistemas de Informação da Universidade do
Sul de Santa Catarina.
RESUMO
A rápida popularização do computador e das tecnologias da informação ocorridas nas últimas
décadas possibilitou às empresas a chance de se tornarem mais competitivas no mercado.
Com a busca pela implantação de novos recursos computacionais, que tornassem seus
processos mais produtivos, surge também a necessidade de manter tais recursos sob as
condições de uso esperadas. As empresas passam então a incorporar centrais de atendimento a
usuários em resposta ao crescente volume de incidentes e para isso utilizam softwares para
gestão de incidentes conhecidos também como sistemas de help desk. Neste sentido, este
trabalho apresenta uma solução que estende as funcionalidades básicas de um sistema de help
desk, implementando um recurso para autoatendimento, construído com base na tecnologia de
Raciocínio Baseado em Casos (RBC), visando com isso beneficiar o serviço de atendimento
das organizações. Modelado sob os princípios de RBC Textual, o protótipo desenvolvido
provê um motor de busca implementado em conformidade com o modelo de Recuperação de
Informação Vetorial, sendo capaz de retornar casos similares (problema/solução) a um
problema de entrada expresso em linguagem natural. Os casos são recuperados a partir de
uma base de conhecimento constituída por FAQs do domínio de informática. Submetido a
testes por usuários e avaliações, o sistema proposto têm sua eficiência comprovada também
por pesquisa realizada e com resultados apresentados.
Palavras-chave: Help Desk. FAQ. Recuperação de Informação. Raciocínio Baseado em
Casos. Sistema Especialista.
LISTA DE ILUSTRAÇÕES
Figura 1 - Engenharia do Conhecimento ..................................................................................... 28
Figura 2 - Componentes dos Sistemas Especialistas .................................................................. 30
Figura 3 - Exemplo simplificado de caso .................................................................................... 37
Figura 4 - Ciclo do Raciocínio Baseado em Casos ..................................................................... 38
Figura 5 - Recuperação de casos .................................................................................................. 40
Figura 6 - Fluxograma: Revisão do caso recuperado .................................................................. 43
Figura 7 - Fluxograma: Proposta da solução ............................................................................... 62
Figura 8 - Atores ........................................................................................................................... 70
Figura 9 - Diagrama de Casos de Uso (Solicitante) .................................................................... 73
Figura 10 - Diagrama de Casos de Uso (Suporte)....................................................................... 74
Figura 11 - Diagrama de Casos de Uso (Analista RBC) ............................................................ 75
Figura 12 - Diagrama de Casos de Uso (Administrador) ........................................................... 76
Figura 13 - Modelo conceitual da estrutura de classes do sistema ............................................ 78
Figura 14 - Diagrama de classes................................................................................................... 81
Figura 15 - Diagrama Entidade-Relacionamento ........................................................................ 83
Figura 16 - Tecnologias e ferramentas utilizadas........................................................................ 86
Figura 17 - Cadastro de conta de acesso ...................................................................................... 93
Figura 18 - Autoatendimento........................................................................................................ 94
Figura 19 - Resposta do caso similar ........................................................................................... 95
Figura 20 - Postar dúvida .............................................................................................................. 96
Figura 21 - Formulário para envio de dúvidas ............................................................................ 96
Figura 22 - Lista de questões ........................................................................................................ 97
Figura 23 - Formulário de edição de questões............................................................................. 98
Figura 24 - Salvando uma questão como FAQ ........................................................................... 99
Figura 25 - Retenção de caso...................................................................................................... 100
Figura 26 - Central de chamados................................................................................................ 101
Figura 27 - Formulário de edição de chamados ........................................................................ 102
Figura 28 - Histórico de interações do chamado ....................................................................... 103
Figura 29 - Lista de perguntas frequentes.................................................................................. 104
Figura 30 - Pesquisa avançada de chamados ............................................................................. 105
Figura 31 - Central de usuários .................................................................................................. 106
Figura 32 - Tela inicial da base de conhecimento ..................................................................... 107
Figura 33 - FAQ (Base de Conhecimento) ................................................................................ 108
Figura 34 - Formulário de edição de FAQs ............................................................................... 109
Figura 35 - Lista de questões (Base de Conhecimento)............................................................ 110
Figura 36 - Dicionário de sinônimos.......................................................................................... 111
Figura 37 - Lista de termos ignorados ....................................................................................... 112
Figura 38 - Campos globais ........................................................................................................ 113
Figura 39 - Teste de recuperação de casos similares ................................................................ 114
Figura 40 - Casos similares recuperados ................................................................................... 115
Figura 41 - Relatório para análise de casos similares ............................................................... 116
LISTA DE GRÁFICOS
Gráfico 1 - Resultado da pesquisa para a pergunta 1 do questionário ..................................... 121
Gráfico 2 - Resultado da pesquisa para a pergunta 2 do questionário ..................................... 121
Gráfico 3 - Resultado da pesquisa para a pergunta 3 do questionário ..................................... 122
Gráfico 4 - Resultado da pesquisa para a pergunta 4 do questionário ..................................... 123
Gráfico 5 - Resultado da pesquisa para a pergunta 5 do questionário ..................................... 123
Gráfico 6 - Resultado da pesquisa para a pergunta 6 do questionário ..................................... 124
Gráfico 7 - Análise dos resultados para as perguntas 1, 2, 3, 5 e 6 do questionário ............... 126
Gráfico 8 - Análise dos resultados para a pergunta 4 do questionário..................................... 126
LISTA DE TABELAS
Tabela 1 - Pesos dos termos da consulta...................................................................................... 53
Tabela 2 - Pesos dos termos dos documentos ............................................................................. 54
Tabela 3 - Relatório para análise de casos similares ................................................................. 117
LISTA DE QUADROS
Quadro 1 - Sistemas Convencionais x Sistemas Baseados em Conhecimento ......................... 34
Quadro 2 - Mapa das técnicas de RBC utilizadas ....................................................................... 57
Quadro 3 - Requisitos Funcionais ................................................................................................ 66
Quadro 4 - Requisitos Não Funcionais ........................................................................................ 67
Quadro 5 - Regras de Negócio ..................................................................................................... 68
Quadro 6 - Casos de Uso .............................................................................................................. 72
Quadro 7 - Perguntas do questionário da pesquisa ................................................................... 120
Quadro 8 - Lista de FAQs ........................................................................................................... 134
Quadro 9 - Requisitos Funcionais – Descrição ......................................................................... 144
Quadro 10 - Requisitos Não Funcionais – Descrição ............................................................... 145
Quadro 11 - Regras de Negócio – Descrição ............................................................................ 147
Quadro 12 - Casos de Uso – Descrição ..................................................................................... 149
LISTA DE SIGLAS
API - Application Programming Interface
ASP - Active Server Pages
BC - Base de Conhecimento
CI - Centro de Informação
CLR - Common Language Runtime
CTS - Common Type System
CU - Caso de Uso
DAL - Data Access Layer
DER - Diagrama Entidade-Relacionamento
FAQ - Frequently Asked Questions
HTML - HyperText Markup Language
HTTP - HyperText Transfer Protocol
IA - Inteligência Artificial
IDE - Integrated Development Environment
IIS - Internet Information Services
LAN - Local Area Network
MD - Modelo de Dados
OMG - Object Managment Group
POO - Programação Orientada a Objetos
RBC - Raciocínio Baseado em Casos
RF - Requisito Funcional
RI - Recuperação de Informação
RN - Regra de Negócio
RN - Regra de Negócio
SBC - Sistema Baseado em Conhecimento
SE - Sistema Especialista
SOAP - Simple Object Access Protocol
SPOC - Single Point of Contact
SQL - Structured Query Language
TI - Tecnologia da Informação
TIC - Tecnologia da Informação e Comunicação
UML - Unified Modeling Language
SUMÁRIO
1 INTRODUÇÃO ..................................................................................................................... 17
1.1 PROBLEMA ........................................................................................................................ 19
1.2 OBJETIVOS ......................................................................................................................... 20
2.2.1 Objetivo Geral.................................................................................................................. 20
2.2.2 Objetivos Específicos ...................................................................................................... 21
1.3 JUSTIFICATIVA ................................................................................................................. 21
1.4 ESTRUTURA DA MONOGRAFIA .................................................................................. 22
2 REVISÃO BIBLIOGRÁFICA ............................................................................................ 23
2.1 HELP DESK ......................................................................................................................... 23
2.1.1 Autoatendimento ............................................................................................................. 24
2.1.2 Importância da Base de Conhecimento ....................................................................... 25
2.1.3 O Software de Help Desk ............................................................................................... 26
2.2 SISTEMAS ESPECIALISTAS ........................................................................................... 27
2.2.1 Introdução ........................................................................................................................ 27
2.2.2 Componentes dos Sistemas Especialistas ..................................................................... 29
2.2.3 Arquitetura dos Sistemas Especialistas ....................................................................... 30
2.2.3.1 A Base de Conhecimento ............................................................................................... 30
2.2.3.2 O Motor de Inferência .................................................................................................... 32
2.2.3.3 A Interface com o Usuário ............................................................................................. 32
2.2.4 Sistemas Convencionais X Sistemas Baseados em Conhecimento ........................... 33
2.3 RACIOCÍNIO BASEADO EM CASOS ............................................................................ 34
2.3.1 Representação do Conhecimento .................................................................................. 36
2.3.2 Ciclo do RBC .................................................................................................................... 38
2.3.2.1 Recuperação .................................................................................................................... 39
2.3.2.2 Reutilização e Adaptação ............................................................................................... 40
2.3.2.2.1 Adaptação Nula ........................................................................................................... 41
2.3.2.3 Revisão ............................................................................................................................ 42
2.3.2.4 Retenção .......................................................................................................................... 43
2.3.3 Raciocínio Baseado em Casos Textual ......................................................................... 45
2.3.3.1 Recuperação em RBC Textual ....................................................................................... 47
2.3.3.2 Modelos de Recuperação de Informação ...................................................................... 49
2.3.3.2.1 Modelo Booleano ......................................................................................................... 49
2.3.3.2.2 Modelo Probabilístico ................................................................................................. 49
2.3.3.2.3 Modelo Vetorial ........................................................................................................... 50
2.3.4 Exemplos de Aplicações RBC ........................................................................................ 55
2.3.5 Mapa das Técnicas de RBC Utilizadas ........................................................................ 56
2.4 CONSIDERAÇÕES............................................................................................................. 57
3 MÉTODO ............................................................................................................................... 58
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA ............................................................ 58
3.2 ETAPAS ............................................................................................................................... 59
3.3 PROPOSTA DA SOLUÇÃO .............................................................................................. 59
3.4 DELIMITAÇÕES DO PROJETO ...................................................................................... 63
3.4.1 Requisitos do Sistema ..................................................................................................... 63
3.4.2 Base de Conhecimento .................................................................................................... 63
4 MODELAGEM...................................................................................................................... 64
4.1 INTRODUÇÃO.................................................................................................................... 64
4.2 UML ...................................................................................................................................... 65
4.3 ESPECIFICAÇÃO DO SISTEMA ..................................................................................... 65
4.3.1 Requisitos Funcionais ..................................................................................................... 66
4.3.2 Requisitos Não Funcionais ............................................................................................. 67
4.3.3 Regras de Negócio ........................................................................................................... 68
4.3.4 Atores................................................................................................................................. 69
4.3.5 Casos de Uso ..................................................................................................................... 70
4.3.5.1 Diagrama de Casos de Uso do Solicitante..................................................................... 72
4.3.5.2 Diagrama de Casos de Uso do Suporte ......................................................................... 74
4.3.5.3 Diagrama de Casos de Uso do Analista RBC ............................................................... 75
4.3.5.4 Diagrama de Casos de Uso do Administrador .............................................................. 76
4.3.6 Diagrama de Classes ....................................................................................................... 76
4.3.7 Modelagem de Dados ...................................................................................................... 82
4.3.7.1 Diagrama Entidade-Relacionamento ............................................................................. 82
5 DESENVOLVIMENTO ....................................................................................................... 85
5.1 TECNOLOGIAS E FERRAMENTAS UTILIZADAS ..................................................... 85
5.1.1 .NET Framework............................................................................................................. 86
5.1.2 ASP.NET ........................................................................................................................... 87
5.1.3 C# ....................................................................................................................................... 87
5.1.4 IIS (Internet Information Services) .............................................................................. 88
5.1.5 SQL Server ....................................................................................................................... 88
5.1.6 SQL Server Management Studio Express ................................................................... 89
5.1.7 Visual Studio .................................................................................................................... 89
5.1.8 jQuery................................................................................................................................ 89
5.2 HISTÓRICO DO DESENVOLVIMENTO........................................................................ 90
5.3 APRESENTAÇÃO DO SISTEMA .................................................................................... 92
5.3.1 Primeiro Acesso ............................................................................................................... 92
5.3.2 Busca da Solução e Retenção de Novos Casos ............................................................ 93
5.3.2.1 Autoatendimento ............................................................................................................. 94
5.3.2.2 Resposta ........................................................................................................................... 95
5.3.2.3 Postar Dúvida .................................................................................................................. 95
5.3.2.4 Lista de Questões ............................................................................................................ 97
5.3.2.5 Retenção de Casos .......................................................................................................... 98
5.3.3 Central de Chamados ................................................................................................... 100
5.3.4 FAQ.................................................................................................................................. 103
5.3.5 Pesquisa Avançada ........................................................................................................ 104
5.3.6 Central de Usuários ....................................................................................................... 105
5.3.7 Base de Conhecimento .................................................................................................. 107
5.3.7.1 FAQ ............................................................................................................................... 108
5.3.7.2 Questões ........................................................................................................................ 109
5.3.7.3 Dicionário de Sinônimos .............................................................................................. 110
5.3.7.4 Lista de Termos Ignorados ........................................................................................... 111
5.3.8 Campos Globais ............................................................................................................. 112
5.4 AVALIAÇÃO .................................................................................................................... 113
5.4.1 Avaliação do Processo de Recuperação de Casos Similares ................................... 114
5.4.2 Avaliação Geral do Recurso de Autoatendimento ................................................... 118
5.4.2.1 Coleta de Dados ............................................................................................................ 118
5.4.2.2 Resultados da Pesquisa ................................................................................................. 120
6 CONCLUSÕES E TRABALHOS FUTUROS ................................................................ 128
REFERÊNCIAS ........................................................................................................................ 130
APÊNDICE A - LISTA DE PERGUNTAS FREQUENTES ............................................. 134
APÊNDICE B - REQUISITOS FUNCIONAIS .................................................................... 135
APÊNDICE C - REQUISITOS NÃO FUNCIONAIS ......................................................... 145
APÊNDICE D - REGRAS DE NEGÓCIO ........................................................................... 146
APÊNDICE E - CASOS DE USO ........................................................................................... 148
APÊNDICE F - CLASSES DO MOTOR DE BUSCA ........................................................ 150
APÊNDICE G - QUESTIONÁRIO DA PESQUISA ........................................................... 156
17
1
INTRODUÇÃO
Nas últimas décadas os contínuos avanços da tecnologia no que diz respeito ao
uso da informação, transformaram a vida das organizações e seus negócios. Fatores como
concorrência e qualidade, obrigaram as empresas a rapidamente se reestruturar tanto
estratégica quanto taticamente fazendo com que recorressem a novos conhecimentos,
procedimentos de trabalho, técnicas e ferramentas que pudessem lhes oferecer melhor relação
com seus clientes, fornecedores, redução de custos, produtividade e vantagem competitiva.
Segundo Turban, Rainer e Potter (2005), Tecnologia da Informação (TI) pode ser
entendida como um conjunto de recursos tecnológicos e computacionais para geração e uso
da informação em alinhamento às estratégias de negócio da empresa.
Fazendo uma leitura do passado, recursos físicos anteriormente utilizados como o
papel e a carta, deram lugar ao arquivo digital e o e-mail. O computador se tornou a principal
ferramenta de trabalho das pessoas trazendo velocidade de produção, organização e
comunicação.
A utilização das redes de área local ou LAN (Local Area Network) com servidores
e computadores interligados, possibilitou às organizações a capacidade de expandir-se,
incorporando mais estações de trabalho em suprimento a novas demandas com extrema
facilidade (FOROUZAN, 2008).
Por outro lado, ao mesmo tempo em que a introdução da TI traz vários benefícios
aos negócios, existe um alto custo de investimento tanto para implantá-la como para mantê-la
sob as condições de utilização esperadas. Tomando como exemplo uma empresa de médio
porte que possua em sua estrutura de TI um determinado conjunto de equipamentos e
hardwares como, por exemplo, servidores, componentes de rede, computadores, periféricos e
softwares a exemplo de sistemas operacionais, sistemas de informação e aplicativos diversos,
é comum que no dia-a-dia, estes componentes apresentem falhas e problemas de
funcionamento que geram incidentes (TURBAN; RAINER; POTTER, 2005).
Incidentes são ocorrências anormais que geram interrupções nas tarefas diárias
dos usuários (STATDLOBER, 2006). O setor de TI tem a responsabilidade prover
mecanismos que conduzam ao tratamento e solução das contingências no menor tempo hábil
minimizando o impacto sobre o negócio. Para dar vazão aos eventuais problemas ou questões
18
que possam surgir, é importante que a área de TI possua um serviço de apoio a usuários com
equipe de suporte ou Help Desk (STATDLOBER, 2006).
Segundo Statdlober (2006), Help Desk pode ser entendido como uma central de
atendimento que presta serviço de apoio ou suporte aos usuários em uma organização.
Um software para gestão de incidentes, comumente chamado de sistema de help
desk, é a ferramenta mais indicada para o registro e controle dos incidentes (OGC, 2007).
Segundo Cohen (2008), os sistemas de help desk apresentam vantagens sobre o telefone e email, pois como são de acesso aos usuários, permitem a estes que acompanhem o andamento
dos chamados e façam uso de outros recursos de forma autônoma.
Um sistema de help desk tem a função primária de receber questões e fornecer
soluções. As questões são especificamente dúvidas, necessidades ou problemas relatados por
usuários através dos chamados registrados no sistema. As soluções são fornecidas pela área de
Help Desk de forma assíncrona em resposta a estes chamados.
Em sistemas de help desk mais evoluídos conhecidos também como Sistemas
Especialistas, a solução de um dado problema é fornecida pelo próprio software de forma
simultânea. Através de uma base de conhecimento e regras pré-definidas o sistema é capaz de
apresentar soluções mediante as características do problema que lhe são informadas
exercendo o papel de um especialista humano (REZENDE, 2005).
Um Sistema Especialista, que é um tipo de Sistema Baseado em Conhecimento,
usa o conhecimento para resolver problemas de forma inteligente manipulando o
conhecimento de um domínio específico e informação (REZENDE, 2005).
O Raciocínio Baseado em Casos que é uma abordagem para solução de problemas
com base na experiência passada estabeleceu-se nos últimos anos como uma das tecnologias
mais populares e disseminadas para o desenvolvimento de Sistemas Baseados em
Conhecimento (WANGENHEIM; WANGENHEIM, 2003).
Este trabalho tem por intuito percorrer os caminhos que a tecnologia de
Raciocínio Baseado em Casos oferece para construção de um sistema de help desk com
recursos que otimizem o processo de resolução de problemas.
19
1.1
PROBLEMA
Com base na realidade apresentada no cenário de TI de uma empresa do ramo de
Telecomunicações situada em Florianópolis, foi possível levantar alguns fatos e situações que
motivaram o autor na escolha de um tema que visa o desenvolvimento de uma solução para
help desk.
A empresa que possui matriz em Florianópolis tem em torno de 1000 usuários
distribuídos em 15 filiais do Brasil. Embora cada unidade da empresa possua um técnico de
suporte, grande parte dos incidentes é encaminhada e gerida pela matriz que possui
atualmente uma equipe de quatro analistas de suporte.
Do que foi observado em loco juntamente a equipe de suporte, o fluxo do
processo de atendimento de usuários acontece da seguinte forma: 1) o usuário registra um
chamado relativo a um problema ou necessidade através do sistema de help desk; 2) um
especialista da área de TI analisa o caso e verifica as ações possíveis podendo recorrer ou
direcionar o problema a outros especialistas; 3) no período em que o chamado estiver em
andamento, poderão ocorrer várias interações entre o usuário e o especialista através de
conversas e inclusões de novas informações que poderão ser registradas no próprio chamado
onde é mantido o histórico do caso; 4) durante o atendimento, um chamado poderá passar por
vários estágios (ou status) como, por exemplo: a iniciar, em andamento, aguardando
informações, cancelado até a sua conclusão propriamente dita; 5) quando o caso é finalmente
solucionado, o chamado é concluído e encerrado.
Considerando o número de usuários da organização e a equipe de suporte da
matriz, o volume de chamados mensal que gira em torno de 400 é um número bastante
representativo que torna ambiente de trabalho em determinados momentos caótico.
Os tipos e níveis de gravidade dos problemas são bastante variados, desde as
ocorrências mais simples como, por exemplo, troca de um mouse defeituoso como outras
mais difíceis de resolver em curto prazo como, por exemplo, a necessidade de reformulação
do modelo de segurança de um sistema de gestão empresarial que foi detectada por um
analista de suporte ao atender vários usuários que manifestaram dificuldades de acesso.
Outro fato é que parte considerável dos chamados que são abertos, principalmente
os de questões relacionadas a problemas simples de configuração e utilização de softwares ou
dispositivos, como por exemplo, configuração de conta de e-mail e acesso a internet,
20
instalação de impressora, travamentos de aplicativos, etc., estes por suas ocorrências ou
reincidências, consomem demasiadamente o tempo da equipe de analistas para o seu
tratamento que na maioria das vezes não são capazes de suprir a demanda devido ao
envolvimento em casos mais críticos e/ou prioritários, comprometendo assim os prazos
estabelecidos pelos usuários para os chamados de rápida resolução.
Partindo deste ponto, o que se avalia é que problemas simples de TI, ou seja,
problemas julgados pela área de Help Desk como resolvíveis por usuários comuns, poderiam
ser solucionados sem a necessidade de abertura de chamados. Embora esta independência já
ocorra na prática, devido a um maior conhecimento em informática que um usuário possua
em relação a outro, fazendo com que o mesmo busque a solução pelos seus meios sem ajuda
ou suporte, isso se verifica apenas em uma minoria.
Sobretudo, o possível enxugamento do montante de chamados de rápida
resolução, traria à área de Help Desk grandes benefícios como principalmente, maior
qualidade de trabalho visto que os especialistas teriam tempo disponível para dedicar-se em
casos mais complexos e prioritários além de possibilitar ao setor de TI a oportunidade de
reestruturar-se, investir em novas melhorias, etc.
1.2
2.2.1
OBJETIVOS
Objetivo Geral
O objetivo geral deste trabalho é desenvolver o protótipo de um Sistema de
Informação para gestão de Help Desk que ofereça não só os recursos principais de um
software deste domínio, mas também um instrumento para o autoatendimento através do qual
os usuários possam utilizá-lo como ferramenta de consulta e busca de soluções visando com
isso beneficiar o serviço de atendimento e suporte de TI nas organizações.
Para tanto, o sistema é modelado e construído em conformidade com o conceito
de RBC (Raciocínio Baseado em Casos).
21
2.2.2 Objetivos Específicos
São objetivos específicos deste trabalho:
1.3

Reunir embasamento teórico sobre Sistemas Especialistas;

Gerar o modelo de um sistema de RBC em conformidade com a proposta do trabalho;

Gerar um protótipo implementado a partir do modelo do sistema;

Gerar uma avaliação com testes efetuados sobre o protótipo.
JUSTIFICATIVA
A lista de aplicações para os SEs é bastante extensa, mas pode ser classificada em
três grandes categorias como: manufatura, finanças e serviços no que compreende as áreas de
engenharia, educação, meteorologia, medicina, militar, telecomunicações, etc. (BARONE,
2003).
Segundo Turban, Mcclean e Wetherbe (2004), “Os Sistemas Especialistas são
capazes de oferecer às empresas soluções inovadoras e baratas para problemas que exigem
experiência”.
Raciocínio Baseado em Casos é aplicável de forma simples e direta a um espectro
grande de problemas e situações reais, o que justifica o seu sucesso e rápida aceitação aos
desenvolvedores de sistemas especialistas. RBC possui muitas vantagens que permitem a um
sistema propor soluções para problemas de forma bastante rápida. Sistemas baseados em
casos atravessam um período de expansão onde se encontra um número crescente de
aplicações. A gama de aplicações é extensa no que inclui: análise financeira, manutenção de
equipamentos, controle de processos, controle de qualidade, diagnóstico médico, suporte a
sistemas de software, planejamento, projeto auxiliado por computador, suporte ao cliente, etc.
(WANGENHEIM; WANGENHEIM, 2003).
Com base no problema anteriormente exposto e conhecidas as oportunidades que
a tecnologia de RBC pode oferecer para o desenvolvimento de sistemas inteligentes, verificase então a necessidade de prover uma solução que possibilite aos usuários resolver problemas
22
ligados à informática de forma autônoma, ou seja, sem a intervenção da área de suporte.
Entretanto, nenhum usuário seria capaz de solucionar sozinho um determinado problema de
informática sem que tivesse instrução para isso. Geralmente, dúvidas e instruções são sanadas
e fornecidas por um especialista humano que detém o conhecimento e a experiência
necessária do domínio de TI. Na sua ausência, um sistema utilizando RBC faria esse papel.
1.4
ESTRUTURA DA MONOGRAFIA
A estrutura deste trabalho é composta por seis capítulos. O capítulo 1 traz uma
introdução sobre Help Desk, o problema, objetivos e a justificativa acerca do tema abordado.
No capítulo 2 tem-se a revisão bibliográfica que expõe os principais conceitos sobre Help
Desk, Sistemas Especialistas e Raciocínio Baseado em Casos, contemplando assim toda a
fundamentação teórica. O capítulo 3 apresenta os itens que constituem o método de pesquisa
adotado bem como etapas, a proposta da solução e as delimitações do trabalho. O capítulo 4
apresenta a modelagem do sistema de help desk proposto. O capítulo 5 contempla o
desenvolvimento e prototipação do sistema. O capítulo 6 encerra a monografia com as
conclusões e propostas futuras.
23
2
REVISÃO BIBLIOGRÁFICA
Este capítulo apresenta a fundamentação teórica dos seguintes assuntos: help desk,
sistemas especialistas e raciocínio baseado em casos.
2.1
HELP DESK
Help Desk pode ser entendido como uma central de atendimento que presta
serviço de apoio ou suporte aos usuários em uma organização tendo como foco a solução de
problemas ligados a Tecnologia da Informação e Comunicação (STATDLOBER, 2006).
O termo help desk surgiu na década de 80, logo que os computadores pessoais
popularizaram-se. A busca das organizações pela informatização e a crescente inclusão do
computador como ferramenta de trabalho diária, acarretou um aumento da demanda por
suporte aos usuários destes equipamentos. Deste modo, muitas empresas criaram os Centros
de Informação (CI) com o objetivo de auxiliar as pessoas no uso dos computadores. Os CIs
eram apoiados por um Sistema Especialista de Diagnósticos e o conjunto deste sistema,
acrescentado com as funções de auxílio, foi denominado de help desk. Help Desk refere-se ao
serviço de suporte acerca de problemas relacionados a questões técnicas que, de modo geral,
referem-se à Tecnologia da Informação (TI) e telecomunicações. Esse serviço age tal como
uma central de apoio a usuários e é estruturada por uma equipe de atendentes e especialistas
técnicos que realizam o atendimento das solicitações recebidas e procuram solucioná-las em
tempo hábil (MULLER, 2002 apud MACHADO, 2008).
Conforme Cohen (2008), help desk é formado por três componentes básicos:

Pessoas: São os profissionais do atendimento responsáveis pelo encaminhamento dos
chamados bem como o tratamento, resolução e gestão dos incidentes;

Processos: São os métodos e procedimentos adotados pelos profissionais do
atendimento no tratamento dos incidentes;
24

Infraestrutura: Constitui-se por softwares, hardware, espaço físico entre outros itens
que amparam o serviço.
Nesse contexto, com relação à organização, a central de atendimento poderá na
maioria das vezes estar dividida em níveis ascendentes de atendimento conforme também seja
menor ou maior a complexidade dos problemas e o grau de conhecimento dos especialistas
(GARTNER GROUP, 2004 apud MACHADO, 2008).
2.1.1 Autoatendimento
A área de Help Desk está sempre em busca de novos métodos que tornem os seus
processos mais eficientes, e um deles é fornecer ao usuário recursos que lhe dê a capacidade
de se auto ajudar através da busca de soluções e orientações por conta própria. A implantação
deste tipo de recurso envolve a elaboração de uma coleção variada de documentos. Um dos
meios mais utilizados é desenvolver uma lista de FAQ (Frequently Asked Questions Perguntas mais Frequentes) e disponibiliza-la na intranet através do sistema de help desk da
empresa a todos os colaboradores ou clientes externos dependendo do tipo de negócio. Uma
FAQ
contém
geralmente
as
dúvidas
cotidianas
relativas
ao
cenário
de
TI local, como por exemplo, “como criar uma conta de e-mail?” ou “como trocar o cartucho
de tinta da impressora x?” e informações especializadas. Existem também outras formas de
autoajuda como softwares para diagnóstico de problemas, manuais, arquivos para download,
etc. (COHEN, 2008).
A seguir alguns exemplos de opções de autoatendimento além de FAQ, geralmente utilizados
por empresas (COHEN, 2008):

Centros de aprendizado: Voltado para educação a distância do usuário. Contém
videos, artigos, tutoriais e outras ferramentas de aprendizado;

Fóruns de discursão: Espaço no qual os usuários e/ou técnicos debatem formas de
uso de produtos e serviços;
25

Blogs de suporte: Contem informações dirigidas aos usuários e compartilhadas pelos
profissionais de atendimento.
O sistema proposto utiliza FAQ como recurso de autoatendimento, sendo o seu
emprego na solução estudado com mais propriedade na seção Raciocínio Baseado em Casos.
2.1.2 Importância da Base de Conhecimento
É comum que no dia-a-dia a área de Help Desk se depare com problemas e
situações dos mais variados tipos. Inúmeras experiências e tentativas foram realizadas para o
desfecho de tais situações. O gerenciamento dessas experiências e conclusões visa capturar,
organizar e governar o conhecimento dos técnicos. É de fundamental importância transformar
o conhecimento tácito pessoal (implícito de cada indivíduo e que não se exprime
formalmente) em conhecimento explícito documentado (expresso de forma clara, precisa e
formal) para que se promova o seu compartilhamento visando a solução de problemas futuros
(COHEN, 2008).
Para o usuário final, uma Base de Conhecimento (BC) pode ser considerada uma
primeira estância de atendimento. Normalmente a BC pode ser disponibilizada ao usuário
para o autoatendimento. A disponibilização de uma base de conhecimento aos usuários
permite que estes tenham acesso rápido, eficiente e direto aos recursos que necessitam
(COHEN, 2008).
Segundo Cohen (2008), a disponibilização da base de conhecimento traz os seguintes
benefícios para o usuário:

O usuário fica apto a resolver problemas por conta própria sem a necessidade de
recorrer ao Help Desk;

Aumento do nível de satisfação do usuário ao encontrar a solução sem ter que registrar
um chamado no sistema;

Aumento do período de atendimento de suporte, pois o usuário pode obter sua resposta
a qualquer hora (considerando uma base de acesso web);
26

Reduz custos internos uma vez que o número de questões respondidas aumenta, o
volume de chamados registrados diminui ou se mantem, reduzindo a necessidade de
contratações de mais técnicos.
Além dos benefícios trazidos para o usuário, uma base de conhecimento tem grande
importância também para a área de Help Desk como são citados os benefícios a seguir
(COHEN, 2008):

Promove-se o compartilhamento do conhecimento;

Evita as chamadas ilhas de conhecimento;

Reduz o tempo de conversação entre usuário e analista na busca da solução;

Reduz a necessidade de transferência de um caso para técnicos mais experientes de
níveis superiores de atendimento;

O analista de suporte tem a oportunidade de atender um leque maior de questões sob
as orientações da BC;

A BC se torna uma ferramenta efetiva de treinamento;

Novos técnicos que são contratados podem ser rapidamente instruídos e produtivos;

O conhecimento captado se torna o recurso intelectual do setor de Help Desk e
permanece mesmo que um de seus autores deixe a empresa;

Permite que um analista se ausente sem que o conhecimento fique inacessível.
2.1.3 O Software de Help Desk
Um software de help desk é uma das ferramentas utilizadas pela equipe de
atendimento e o principal meio com que os incidentes podem ser registrados e controlados
(STATDLOBER, 2006).
Na terminologia da ITIL (Information Technology Infrastructure Library), uma
definição mais técnica para incidente seria: “qualquer evento que não faz parte do
funcionamento normal de um serviço e que causa ou pode causar, a sua interrupção ou a sua
redução da qualidade.” (ITSMF, 2006).
27
Nesse contexto, incidentes incluem não somente erros de hardware ou software,
mas também requisições de serviço (ITSMF, 2006).
A principal característica de um software de help desk, está no fato de ser um
facilitador da comunicação entre as partes envolvidas em um dado problema onde serve como
um ponto único de contato entre usuários e a equipe de atendimento relativo a uma ou mais
questões em aberto. A IBM estabeleceu um termo no mercado que se tornou padrão para
muitas empresas: SPOC (Single Point of Contact – Ponto único de contato) onde todas as
solicitações entram por um determinado ponto de acesso. Este ponto pode ser um ramal
telefônico que distribui as tarefas para equipe técnica, ou nos dias atuais, um formulário web
ou chat on-line (COHEN, 2008).
2.2
SISTEMAS ESPECIALISTAS
Esta seção apresenta os Sistemas Especialistas como parte essencial para o
entendimento de Raciocínio Baseado em Casos que é foco principal da construção do sistema
proposto.
Nesta seção, dos itens que serão abordados a seguir estão: introdução ao assunto
Sistemas Especialistas, seus principais componentes, sua arquitetura e um comparativo aos
sistemas convencionais.
2.2.1 Introdução
Em termos gerais, conceitos mais atuais definem a IA como um ramo da ciência
da computação que se propõe a estudar e compreender as faculdades do pensamento e
construir dispositivos e sistemas que simulam a capacidade humana de raciocinar, perceber,
tomar decisões e resolver problemas, ou melhor dizendo, a capacidade de agir de forma
inteligente (RUSSEL; NORVIG, 2004).
28
Os Sistemas Especialistas (SE) surgiram com o propósito de restringir o campo de
domínio dos sistemas baseados em IA visto que é muito difícil a construção de sistemas cujo
propósito de resolução de problemas atenda a qualquer área e nível de dificuldade (RUSSEL;
NORVIG, 2004).
A principal característica de um SE está no modelo em que se organiza quanto à
aquisição de conhecimento e obtenção de respostas em face de um dado problema,
assemelhando-se no modo como um especialista humano procede na mesma situação. Um
médico, por exemplo, para diagnosticar uma determinada patologia, utiliza seu conhecimento
e experiência em conjunto com regras específicas de análise para que seu processo de
descoberta da resposta ou solução se faça de forma mais objetiva e confiável. Desta forma um
SE é basicamente um sistema que necessita de uma base pré-definida de conhecimento para
trazer as respostas com base em parâmetros de entrada que traduzem o problema (BARONE,
2003).
Os SEs são fundamentalmente Sistemas Baseados em Conhecimento (SBC) que
usam o conhecimento para resolver problemas de forma inteligente manipulando o
conhecimento e informação. Um SBC é projetado para ser usado em problemas que requer
conhecimento humano e especialização. Entretanto é importante diferenciar os Sistemas
Especialistas dos Sistemas Baseados em Conhecimento, pois de forma geral os SBC são
sistemas capazes de resolver problemas usando conhecimento específico sobre o domínio da
aplicação, enquanto que os SEs são SBC que resolvem problemas geralmente de domínio dos
especialistas humanos (REZENDE, 2005).
Perguntas, Problemas
Respostas, Soluções
Engenheiro do
Conhecimento
Estratégias,
Regras do domínio
Sistema Especialista
Figura 1 - Engenharia do Conhecimento
Fonte: Elaboração do autor, 2011.
A Figura 1 ilustra o processo de construção de um SE, geralmente chamado de
Engenharia do Conhecimento que tipicamente envolve uma forma especial de interação entre
29
o construtor do SE, chamado Engenheiro do Conhecimento, e um ou mais especialistas em
alguma área. O Engenheiro do Conhecimento captura dos especialistas através de entrevista
seus procedimentos, estratégias e regras práticas para solução de problemas e os transfere para
o SE (REZENDE, 2005).
2.2.2 Componentes dos Sistemas Especialistas
Conforme Waterman (1986), o esquema de representação de um SE pode ser
apresentado através dos seguintes componentes: o Sistema Especialista propriamente dito, o
domínio especialista, o Engenheiro do Conhecimento e o usuário final.

O Sistema Especialista: É o sistema computacional responsável por prover todos os
recursos necessários que atendam ao domínio de aplicação proposto. Isto envolve não
só a capacidade de fornecer respostas ao usuário final, mas também de dispor meios
para se desenvolver e se aperfeiçoar;

O Domínio Especialista: Envolve o conhecimento dos especialistas sendo estes
capazes de produzir boas soluções para problemas em um campo específico. O
especialista utiliza estratégias para tornar a pesquisa de uma solução mais eficiente e o
SE incorpora e modela estas estratégias;

O Engenheiro do Conhecimento: É a pessoa com qualificação necessária,
geralmente com algum conhecimento em computação e IA que é responsável pela
construção do SE. O Engenheiro do Conhecimento realiza entrevistas com os
especialistas, organiza o conhecimento, decide como ele deve ser representado e pode
ajudar programadores na construção do sistema;

O Usuário: Aquele que utiliza o SE.
30
Entrevistas
Testa
Engenheiro do
Conhecimento
Usuário final
Sistema Especialista
Constrói,
Testa
Usa
Figura 2 - Componentes dos Sistemas Especialistas
Fonte: Elaboração do autor, 2011.
A Figura 2 ilustra o diagrama de componentes do SE que apresenta as interações
existentes entre cada um.
2.2.3 Arquitetura dos Sistemas Especialistas
Segundo Barone (2003), a arquitetura de um sistema especialista pode ser
apresentada através de três elementos fundamentais que são: a base de conhecimento, o motor
de inferência e a interface do usuário.
2.2.3.1 A Base de Conhecimento
A base do conhecimento não é uma simples coleção de informações. A tradicional
base de dados com dados, arquivos, registros e seus relacionamentos estáticos é aqui
substituída por uma base de regras e fatos e também heurísticas que correspondem ao
conhecimento do especialista, ou dos especialistas do domínio sobre o qual foi construído o
sistema (NILSON, 1982).
De acordo com a ANSI/IEEE STD 100_1984, o termo “heurística” em Ciência da
Computação, diz respeito aos métodos ou algoritmos exploratórios para solução de
31
problemas. As soluções são buscadas por aproximações sucessivas, avaliando-se os
progressos alcançados, até que o problema seja resolvido.
A base de conhecimento contém a descrição do conhecimento necessário para a
resolução do problema abordado na aplicação. Isto inclui asserções sobre o domínio
de conhecimento, regras que descrevem relações neste domínio e, em alguns casos,
heurísticas e métodos de resolução de problemas (REZENDE, 2005, p. 26).
A base de fatos e a base de regras são acessíveis e apresentadas ao usuário de
forma dinâmica através da interface gráfica do sistema e estas interagem com o motor de
inferência a todo o momento, permitindo identificar o problema a ser resolvido, as possíveis
soluções e o processo de raciocínio e inferência acerca do problema submetido ao sistema
(MENDES, 1997).
Nos SEs estruturados, os passos para o diagnóstico e solução do problema passam
por uma sequência de perguntas onde a quantidade pode variar dinamicamente dependendo
das respostas que são respondidas pelo usuário onde o espaço de busca da solução a ser
percorrido pelo sistema encurta-se a cada interação do usuário.
Os SEs podem também possuir mecanismos de aprendizagem capazes de analisar
e gerar novas regras na base conhecimento e/ou armazenar informações sobre novos fatos,
ampliando sua capacidade de resolver problemas, tudo isso de forma automática e
transparente ao usuário durante a utilização do SE (CHECLAND, 1981 apud MENDES,
1997).
Embora se espere que as respostas produzidas pela base de conhecimento sejam
consistentes e precisas, ocasionalmente poderá haver conhecimento que gere conclusões
alternativas e conflitantes. Nesse caso, é importante que o sistema possua mecanismos para
analisar e escolher a melhor resposta entre as conclusões geradas. Em outra situação, nem
sempre o conhecimento necessário para gerar a resposta se encontrará na base, e neste caso, é
esperado que o sistema encontre uma resposta razoável como meio para contornar esta falta
(REZENDE, 2005).
32
2.2.3.2 O Motor de Inferência
O motor de inferência pode ser considerado o componente principal da arquitetura
dos sistemas especialistas. É através dele que os fatos, regras e heurísticas que compõem a
base de conhecimento, são aplicados durante o processo de resolução do problema
(BARONE, 2003).
O motor de inferência determina a ordem com que serão processadas as
informações, manipulando os dados a fim de inferir novos fatos, chegar a conclusões ou
recomendar ações. O motor de inferência representa a forma de manipular o conhecimento, já
representado na base, a fim de resolver o problema. Este mecanismo determina qual parte do
conhecimento deve ser utilizada a cada momento da execução do sistema (BARONE, 2003).
2.2.3.3 A Interface com o Usuário
A interação entre o SE e o usuário conduz um processo de navegação eficiente, na
base de conhecimento durante o processamento das heurísticas. Os procedimentos heurísticos
são informais e um problema submetido a um sistema especialista é mapeado em memória
por estratégias de busca que se encaixam e desencadeiam outras estratégias, sempre marcando
o caminho percorrido. Para isto, é necessário que a interface gráfica do sistema seja bastante
dinâmica e flexível (MENDES, 1997).
Nos SEs estruturados, uma interface flexível permite que o usuário primeiramente
estabeleça o problema ou os objetivos que deseja alcançar e prossiga em uma navegação por
sucessivas telas que apresentam de forma dinâmica, as proposições encontradas de acordo
com o resultado das inferências. O usuário continua interagindo com o sistema por esta
navegação progressiva até que um resultado final ou as possíveis soluções sejam
apresentados.
Dependendo de como foi implementado o sistema especialista, a interface com o
usuário poderá assumir formas variadas. Contudo é interessante que sua usabilidade seja fácil
e agradável, tornando o mais transparente possível todas as complexidades (REZENDE,
2005).
33
2.2.4 Sistemas Convencionais X Sistemas Baseados em Conhecimento
Segundo Rezende (2005), a comunidade de IA tem atribuído algumas
características específicas que definem os Sistemas Baseados em Conhecimento para
podermos chamá-los assim. Em resumo, os SBC devem ser capazes de:

Questionar o usuário, fazendo uso de uma linguagem de fácil entendimento, para
reunir as informações de que necessita;

Desenvolver uma linha de raciocínio a partir dessas informações e do conhecimento e
do conhecimento nele embutido para encontrar soluções satisfatórias. Para isso, o
sistema necessita lidar com regras e informações incompletas, imprecisas e
conflitantes;

Explicar seu raciocínio caso seja questionado pelo usuário do por que necessita de
informações externas e como chegou a tais conclusões. Para tanto, o sistema deve
memorizar as inferências realizadas durante o processo de raciocínio, ser capaz de
interpretar este processo e apresenta-lo de forma compreensível para o usuário;

Conviver com seus erros, isto é, tal como um especialista humano, o SBC pode
cometer erros, mas deve possuir um desempenho satisfatório que compense seus
possíveis enganos.
Embora as características acima estejam presentes nos SBC, elas não se
confirmam como fundamentais diferenças entre os SBC e os sistemas convencionais, pois
também é possível construir sistemas convencionais com estas características (REZENDE,
2005).
Os SBC devem possuir propriedades que podem ser definidas de um modo mais operacional e
que estabelece melhor tais diferenças como segue (REZENDE, 2005):

Tudo que se sabe sobre o problema deve estar explicitamente representado na base de
conhecimento do sistema;

A base de conhecimento deve ser usada por um motor de inferência capaz de
interpretá-la;
34

Os problemas resolvidos por SBC são aqueles sobre os quais não é conhecido um
procedimento ideal que garanta uma resolução efetiva considerando a variabilidade
dos tipos de problema e a ausência de conhecimento preciso e completo sobre o
domínio.
Sistemas Convencionais
Sistemas Baseados em Conhecimento
Estrutura de dados
Representação do conhecimento
Dados e Relações entre dados
Conceitos, Relações entre conceitos e Regras
Tipicamente usa algoritmos determinísticos
Busca heurística
Conhecimento embutido no código do Conhecimento representado explicitamente e
programa
separado do programa que o manipula e
interpreta
Explicação do raciocínio é difícil
Podem e devem explicar seu raciocínio
Quadro 1 - Sistemas Convencionais x Sistemas Baseados em Conhecimento
Fonte: REZENDE (2005, p. 18).
O Quadro 1 traça um comparativo das principais diferenças entre os Sistemas Convencionais
e os Sistemas Baseados em Conhecimento.
2.3
RACIOCÍNIO BASEADO EM CASOS
Segundo Wangenheim e Wangenheim (2003, p. 1), Raciocínio Baseado em Casos
(RBC) pode ser entendido como uma tecnologia utilizada para o desenvolvimento de
Sistemas Baseados em Conhecimento, que de forma geral, tem como objetivo a resolução de
novos problemas a partir das soluções adotadas em problemas similares já resolvidos.
Um sistema RBC tem como princípio, resolver novos problemas reutilizando sua
experiência que é baseada em soluções anteriores. Uma solução encontrada pode ser aplicada
em sua totalidade ou de forma parcial, podendo ainda ser modificada ou adaptada aos
requisitos da nova situação (WANGENHEIM; WANGENHEIM, 2003).
35
[...] pode-se definir RBC como um enfoque para a solução de problemas e para o
aprendizado baseado em experiência passada. RBC resolve problemas ao recuperar
e adaptar experiências passadas - chamadas casos - armazenadas em uma base de
casos. Um novo problema é resolvido com base na adaptação de soluções de
problemas similares já conhecidas (WANGENHEIM; WANGENHEIM, 2003).
Os primeiros estudos do RBC começaram no início dos anos 80 através do
trabalho do grupo de Roger Schank, na Universidade de Yale, que criou as primeiras
aplicações baseadas neste modelo (BARONE, 2003).
A ideia de utilizar soluções antigas para resolver novos problemas surgiu a partir de
estudos cognitivos da memória, realizados por Schank. Segundo ele, a memória
humana se modifica com o resultado de experiências, e a compreensão de um
problema exige que experiências antigas sejam revistas (Schank, 1982).
Posteriormente, essas ideias foram elaboradas por Janet Kolodner, levando ao
desenvolvimento de sistemas especialistas que utilizavam medidas de similaridade e
técnicas de adaptação para reaplicar antigas soluções em novos problemas do
mesmo domínio (Kolodner, 1993). Kolodner desenvolveu o primeiro sistema RBC,
chamado CYURUS, que foi uma implementação do modelo de memória dinâmica de
Schank, servindo de base para outros sistemas RBC (BARONE, 2003, p. 210).
Embora seja inquestionável o sucesso dos SBC, estes apresentam problemas que
devem ser considerados tais como: a extração do conhecimento, implementação e
manutenção. Por outro lado, sistemas de RBC não apresentam tais problemas descritos, pois
conforme Barone (2003):

A extração do conhecimento limita-se a obter, reunir e analisar casos que
representam experiências ocorridas;

A implementação torna-se mais fácil, pois identificar características significantes dos
casos é mais fácil do que criar regras ou explicitar modelos;

Grandes volumes de dados podem ser administrados com aplicação de técnicas de
banco de dados;

O sistema pode aprender com a aquisição de novos conhecimentos.
Assim como o RBC é de fato uma técnica que simula o raciocínio humano, é
possível citar alguns exemplos de como os seres humanos utilizam casos conhecidos que
foram vivenciados como método de resolução de problemas atuais.
Conforme Wangenheim e Wangenheim (2003, p. 9), alguns casos cotidianos:
36

Durante o atendimento de um paciente após conhecer seus problemas, o médico
lembra-se do histórico de outro paciente que possui sintomas similares e lhe aplica
um tratamento semelhante;

Um técnico de aparelhos eletrônicos percebe que a TV que está tentando concertar
apresenta em seu problema, as mesmas características de outra que consertara
semana passada;

Um profissional jurídico reforça os seus argumentos com jurisprudências
semelhantes para decidir um caso com base em outros similares.
Raciocínio Baseado em Casos é antes de tudo, uma técnica de Inteligência
Artificial que se inspira neste modelo de cognição e comportamento humano. Desta forma, a
tecnologia de RBC pode ser vista como uma metodologia para modelar o raciocínio e o
pensamento humano e também como uma metodologia utilizada para construir sistemas
computacionais inteligentes (WANGENHEIM; WANGENHEIM, 2003).
2.3.1 Representação do Conhecimento
A principal forma de representação do conhecimento em sistemas de RBC é
através de casos. Um caso é uma unidade contextualizada de conhecimento que representa
uma experiência (KOLODNER, 1993 apud WANGENHEIM; WANGENHEIM, 2003).
Tipicamente, um caso reúne em seu contexto, o par problema/solução, no que
inclui: a descrição de uma situação (problema) e as experiências acerca da sua resolução
(solução) (WANGENHEIM; WANGENHEIM, 2003).
37
Figura 3 - Exemplo simplificado de caso
Fonte: Wangenheim e Wangenheim (2003, p. 11).
A Figura 3 apresenta um exemplo de caso que ilustra o modelo de representação do
conhecimento em RBC.
Para Kolodner (1993 apud WANGENHEIM; WANGENHEIM, 2003), a
representação dos casos apresenta três componentes básicos que são: a descrição do problema,
a descrição da solução e a conclusão.
Segundo Barone (2003), a definição destes três componentes:

Descrição do problema: São as características que descrevem o problema de entrada.
Tais características podem assumir a forma de nomes, números, funções ou textos que
servem para representar características, objetivos, metas, restrições ou condições;

Descrição da solução: São as características que descrevem a solução do caso. A
solução do caso é a ação ou conjunto de ações sugeridas pelo sistema que resolvem o
problema. A solução pode ainda ser acompanhada de uma justificativa que irá auxiliar
o usuário na escolha do caso como solucionador do problema;

Conclusão: É a avaliação da solução que foi adotada num determinado problema.
38
Por fim, a coleção de casos de um sistema de RBC é organizada e armazenada em
uma base de dados conhecida como Base de Casos que constitui a maior parte da Base de
Conhecimento.
2.3.2 Ciclo do RBC
O Ciclo de RBC proposto por Aamondt e Plaza (1994 apud WANGENHEIM;
WANGENHEIM, 2003), é um modelo que representa o RBC através de um ciclo de quatro
etapas que são: recuperação, reutilização, revisão e retenção.
Figura 4 - Ciclo do Raciocínio Baseado em Casos
Fonte: Wangenheim e Wangenheim (2003, p. 15).
A Figura 4 apresenta o ciclo do RBC e suas etapas que serão explanadas nas próximas seções.
39
2.3.2.1 Recuperação
É o processo de recuperação do caso ou dos casos mais similares da base de casos.
A partir de um novo problema, uma busca é realizada na base de casos a procura dos casos
cuja descrição seja semelhante a do problema atual. O objetivo é recuperar e disponibilizar ao
usuário, todos ou um número limitado de casos mais similares. A ideia é que a solução de um
caso suficientemente similar ao atual também poderá ser utilizada para sua solução
(WANGENHEIM; WANGENHEIM, 2003).
A similaridade dos casos recuperados é determinada por meio da medida de
similaridade e durante o processo de recuperação cada caso tem sua similaridade calculada.
Ao final, os casos são ordenados de forma decrescente pelo valor de sua similaridade para que
assim o sistema apresente o resultado (WANGENHEIM; WANGENHEIM, 2003).
Conforme Wangenheim e Wangenheim (2003), algumas técnicas de recuperação
podem ser utilizadas nos sistemas de RBCs, como por exemplo, a recuperação Sequencial, a
recuperação de Dois Níveis, a Orientada a Índices, a recuperação com Arvores k-d e as Redes
de Recuperação de Casos.
Para o sistema proposto, a técnica de recuperação escolhida foi a sequencial.
Segundo Wangenheim e Wangenheim (2003), na Recuperação Sequencial (RS) a medida de
similaridade é calculada sequencialmente para todos os casos da base.
Segundo Wangenheim e Wangenheim (2003, p. 150):
O processo de recuperação sequencial permite a determinação dos m casos mais
similares. Para a determinação de uma relação de preferência específica para a
situação aplica-se o conceito de similaridade do sistema sucessivamente a cada um
dos casos da base de casos. Todos os casos pertencentes à base são então ordenados
de acordo com os m casos mais similares. O método de recuperação sequencial é um
método de aplicação universal e extremamente fácil de ser implementado para a
determinação de casos similares.
As principais vantagens do uso da RS estão na simplicidade de implementação e
por
ser
um
processo
comprovadamente
completo
e
correto
(WANGENHEIM;
WANGENHEIM, 2003).
Para o sistema proposto, um método adotado para reduzir o montante de casos
candidatos que são comparados, foi dispor um filtro de pesquisa no motor de busca, pois o
40
cálculo da similaridade não deve necessariamente ser aplicado a todos os casos da base
durante a busca dos casos mais similares. Desta forma, um caso quando cadastrado, pode ser
categorizado de acordo com o tipo de problema que representa como, por exemplo, software,
hardware, e-mail, impressão, etc. Assim o usuário poderá antes de executar a busca, delimitar
a consulta para uma categoria de casos específica o que trará um proporcional ganho de
desempenho no processo de recuperação.
Figura 5 - Recuperação de casos
Fonte: Elaboração do autor, 2011.
A Figura 5 sintetiza o processo de recuperação de casos no que compreende a
consulta na base de casos, o cálculo da similaridade e o ranqueamento dos casos.
2.3.2.2 Reutilização e Adaptação
A reutilização consiste principalmente da adaptação da solução do caso anterior
ao caso atual e as técnicas tratadas na reutilização de casos tentam resolver os problemas
41
envolvidos na adaptação de casos, que são: quais aspectos da situação devem ser adaptados,
quais modificações devem ser realizadas para esta adaptação, que método aplicar para realizar
a adaptação e como controlar este processo (WANGENHEIM; WANGENHEIM, 2003).
Quando um caso que foi recuperado da base não satisfaz por completo os
requisitos do novo problema, pode se tornar necessário adaptar a solução do caso recuperado.
Na maioria dos domínios de aplicações RBC, para que se aplique a solução, será suficiente
copiar a solução do caso recuperado para o caso atual ou então adaptar o caso recuperado
manualmente (WANGENHEIM; WANGENHEIM, 2003).
Para sistemas de RBC que desempenham tarefas analíticas de classificação,
diagnóstico ou suporte à decisão, uma estratégia frequentemente utilizada é contornar o
problema da adaptação tornando a base de casos o mais completa possível de forma que
contenha os relativos casos para os inúmeros tipos de problemas sem que haja a necessidade
de adaptação (WANGENHEIM; WANGENHEIM, 2003).
Segundo Wangenheim e Wangenheim (2003), existe uma série de estratégias de
adaptação automáticas como, por exemplo, adaptação transformacional, gerativa/derivacional,
composicional, hierárquica e nula sendo esta última a escolhida para o sistema.
2.3.2.2.1 Adaptação Nula
Conforme Wangenheim e Wangenheim (2003), neste tipo de adaptação, nada é
adaptado e a solução apresentada pelo caso recuperado é tomada total ou parcialmente para
resolver o problema atual sem a necessidade de modificações. “A maioria dos sistemas de
RBC comerciais atuais trabalham apenas com adaptação nula.” (WANGENHEIM;
WANGENHEIM, 2003).
42
2.3.2.3 Revisão
Após a solução ter sido adaptada, faz-se necessário que esta seja revisada e se
preciso for, corrigida. Os critérios para revisão da solução podem ser a qualidade desta
solução, a facilidade de compreensão desta solução por parte do usuário ou a quantidade de
esforço para implementar esta solução (WANGENHEIM; WANGENHEIM, 2003).
O processo de revisão pode ocorrer de forma automática por parte do sistema de
RBC ou com a participação do Engenheiro de Conhecimento.
Segundo Wangenheim e Wangenheim (2003), a etapa de revisão consiste em duas tarefas
principais que podem também ser verificadas no fluxograma a seguir:

Aprender e reter na base, se a solução gerada pelo reuso é considerada correta;

Caso contrário, reparar a solução para o caso utilizando conhecimento específico sobre
o domínio ou as informações fornecidas pelo usuário.
43
Figura 6 - Fluxograma: Revisão do caso recuperado
Fonte: Elaboração do autor, 2011.
Para o sistema proposto, a etapa de revisão de um novo caso ocorre de forma
manual sob a responsabilidade do Engenheiro do Conhecimento ou pessoa responsável pela
manutenção da base de conhecimento.
2.3.2.4 Retenção
Assim que um problema é resolvido, a nova experiência poderá ser incorporada à
base de casos de forma que o conhecimento presente do sistema é continuamente atualizado e
expandido. Tendo concluído o processo de adaptação e revisão do novo caso, se a solução
proposta for aceita, esta poderá ser retida na base de casos, enriquecendo ainda mais a atual
base de conhecimento do sistema. Após a incorporação desta solução na base de casos, esta
44
estará disponível para utilização em problemas futuros (WANGENHEIM; WANGENHEIM,
2003).
Geralmente o processo de retenção ocorrerá com a participação humana. “A
decisão de reter as soluções propostas pelo sistema RBC, provavelmente terá a participação
do usuário, o que não deve ser visto como uma fraqueza do sistema RBC, mas sim como uma
maneira de encorajar a colaboração humana no apoio à tomada de decisão” (WATSON, 1997
apud BARONE, 2003, p. 211).
Segundo Wangenheim e Wangenheim (2003), é possível distinguir três tipos básicos de
retenção:

Sem retenção de casos: Aplicado nos sistemas de RBC mais simples onde o domínio
de aplicação é bem compreendido e modelado de forma satisfatória já durante o
desenvolvimento do sistema;

Retenção de soluções de problemas: Assim que um novo problema é resolvido, a
experiência é então retida de forma a auxiliar na solução de problemas futuros. Num
sistema de help desk, por exemplo, cada chamado resolvido de forma satisfatória pode
vir a ser um caso incorporado da base. Esta forma de aprendizado é uma das maiores
vantagens específicas do RBC, pois o aprendizado e a aplicação do conhecimento
aprendido não são separados, mas sim integrados;

Retenção de documentos: O novo conhecimento é adquirido de forma assíncrona ao
processo de solução de problemas de forma que é retido quando se encontrar
disponível. Aqui a fase de retenção de casos é separada do processo de solução de
problemas e depende da disponibilidade de conhecimento sobre o domínio. No caso de
um sistema de suporte à decisão na área jurídica, por exemplo, uma nova
jurisprudência pode ser adicionada na base de casos assim que disponível.
Para o sistema proposto, como será visto mais adiante, cada chamado de help desk
que é resolvido ou cada dúvida de usuário que é postada referente a um problema cuja solução
não foi encontrada na base de conhecimento, poderá separadamente do processo de solução,
conforme a avaliação do Engenheiro do Conhecimento vir a se tornar um caso da base de
conhecimento, o que caracteriza dois tipos de retenção: retenção de solução de problemas e
retenção de documentos.
45
Além disso, o sistema proposto utiliza um tipo de Raciocínio Baseado em Casos
denominado Textual como será visto na próxima seção. Esta técnica de RBC considera casos
como documentos.
2.3.3 Raciocínio Baseado em Casos Textual
A ideia básica do RBC Textual é comparar documentos representados por casos
em termos de similaridade. Para acessar a informação contida em documentos textuais, cada
documento é convertido em um único caso (LENZ; HÜBNER; KUNZE, 1998b apud SÁ
2007).
Segundo Baeza-Yates e Ribeiro-Neto (1999 apud SÁ, 2007), a similaridade dos
documentos não se baseia simplesmente nas palavras que os constituem, mas também em uma
medida de similaridade que é construída durante a aquisição do conhecimento. Uma técnica
de Recuperação de Informação (RI) dos casos lida com a representação, organização e acesso
aos itens de informação. Na tentativa de selecionar documentos textuais relevantes, técnicas
de RI podem ser aplicadas.
Para Lancaster (1993 apud CAMPOS, 2007), um sistema de RI é um fenômeno
complexo que envolve informação, documentos, pedidos de usuários, resumos de
documentos, mecanismos que permitem a busca de documentos e pessoas. As pessoas
envolvidas são de dois tipos: operadores do sistema, que são os responsáveis por dar a entrada
de documentos no sistema e usuários do sistema, que fazem os pedidos ou as requisições ao
sistema.
Considere o seguinte problema e as posteriores considerações conforme Baeza-Yates e
Ribeiro-Neto (1999 apud SÁ 2007):
Encontrar todas as páginas (documentos) contendo informações sobre tipos de vírus
de computador que (1) relacionem os nomes dos vírus para os quais já tenham sido
desenvolvidas ferramentas específicas de remoção e (2) que tais ferramentas de
remoção possam ser utilizadas no sistema operacional Windows Server versão 2003.
Para serem relevantes, as páginas devem incluir a disponibilidade dessas
ferramentas.
46
Conforme o problema descrito, a informação que está sendo requerida pelo
usuário não pode ser recuperada através dos mecanismos de busca mais simples da web.
Entretanto, se tal problema ou necessidade fosse traduzido para um sistema de RI em termos
organizados de consulta, a informação solicitada poderia ser recuperada. A transformação do
problema de entrada em consulta gera um grupo de palavras-chave (ou termos indexados) que
descrevem a necessidade de informação digitada pelo usuário de forma resumida. Assim que
é concluído o processo de indexação dos termos, o sistema de RI poderá iniciar a recuperação
da informação (BAEZA-YATES; RIBEIRO-NETO, 1999 apud SÁ 2007).
Desta forma, sistemas de RI podem ser aplicados em qualquer domínio de
conhecimento onde documentos textuais estejam disponíveis. A aquisição de conhecimento
envolve a construção de um modelo de domínio que descreva as propriedades essenciais deste
domínio, como principalmente, os termos (LENZ; HÜBNER; KUNZE, 1998a apud SÁ
2007).
A construção de um sistema de RBC Textual requer a definição de três
componentes básicos que são: a coleção de casos, o índice de vocábulos e a medida de
similaridade (LENZ; HÜBNER; KUNZE, 1998a apud SÁ 2007):

A coleção de casos: Compreende cada caso (ou documento) contendo sua descrição
textual do problema que irá integrar a base de casos;

O índice de vocábulos: Seleção das palavras (ou termos indexadores) que são
inerentes ao domínio escolhido;

A medida de similaridade: A definição lógica de como a similaridade entre os termos
do problema e os termos de cada caso será calculada.
Segundo Wilson e Bradshaw (1999 apud SÁ 2007), os sistemas de RBC textuais
podem ainda ser classificados de acordo com o seu contexto: levemente textuais e fortemente
textuais.

Contexto Levemente Textual: Um contexto levemente textual é aquele onde não há
necessidade de complexas manipulações da informação textual. Nesse tipo de
contexto a importância da informação textual é maior que a importância do significado
do texto como base para o raciocínio. Ou seja, não há necessidade de um
processamento sofisticado para a utilização do texto em sistemas de RBC textuais;
47

Contexto Fortemente Textual: Em um contexto fortemente textual a importância do
significado do texto como base para o raciocínio é maior que a da informação textual.
Um contexto fortemente textual requer um tratamento mais especializado, como por
exemplo, técnicas de Processamento de Linguagem Natural e Extração de Informação.
Para o sistema proposto, é utilizada como base de casos uma FAQ. FAQ numa
definição mais simples, pode ser entendida como uma lista de perguntas mais frequentes
acerca de um tema. Referente ao tema, uma FAQ relaciona questões que abordam os
procedimentos de utilização, como por exemplo, de máquinas, equipamentos, softwares,
utensílios domésticos, etc. Geralmente as perguntas e respostas são estabelecidas com base
em dúvidas, necessidades ou problemas levantados por quem utiliza o objeto em questão.
Neste caso, uma FAQ para Help Desk, relaciona perguntas e respostas acerca de dúvidas ou
problemas ligados geralmente a informática.
Uma FAQ para Help Desk é considerada levemente textual devido a grande
quantidade de informações já estar disponível em cada documento (SÁ, 2007).
Outro aspecto interessante é que uma FAQ possui uma estrutura que atende os
requisitos definidos nas etapas do RBC. O par pergunta-resposta pode ser considerado como
um caso, sendo que a pergunta serve como um índice do conhecimento contido na resposta
(LIMA, 2004 apud FERNANDES et al., 2010).
A lista de perguntas frequentes que foi utilizada no sistema proposto pode ser
verificada no apêndice A. Os exemplos usados foram coletados de forma aleatória tendo
como principal fonte alguns manuais de ajuda da Microsoft.
2.3.3.1 Recuperação em RBC Textual
Para Baeza-Yates e Ribeiro-Neto (1999 apud FERNANDES et al., 2010), antes de
iniciar o processo de recuperação de um caso, é importante que haja um pré-processamento do
texto da coleção de documentos, pois nem todos os termos são significativos, ou seja, o préprocessamento determinará quais termos serão realmente utilizados como índices durante a
recuperação.
48
Existem algumas técnicas utilizadas para pré-processamento de texto, como por
exemplo, stemming e análise léxica. Para o sistema proposto, utilizou-se como técnica de préprocessamento, a transformação de texto denominada eliminação de stopwords.
Considera-se stopwords, os termos que são muito frequentes nos documentos e
por esta razão, não são considerados bons discriminantes. Em termos quantitativos, palavras
com 80% de ocorrência em um dado documento, não tem utilidade para a recuperação.
Durante o pré-processamento, assim que uma stopwords é detectada, esta é removida do
documento. Através dessa técnica, artigos, preposições, advérbios, alguns verbos, e alguns
adjetivos compõem uma lista de palavras denominada stoplist e os termos listados em uma
stoplist não servirão como termos indexados durante a recuperação. A eliminação das
stopwords reduz o tamanho da estrutura dos índices consideravelmente, o que pode melhorar
a etapa da recuperação dos documentos (FERNANDES et al., 2010).
Para aumentar a eficiência do processo de busca de casos, o sistema de RBC
poderá utilizar um dicionário de sinônimos.
Considere os seguintes problemas:
a) Como envio um pedido de parafusos para a fábrica por e-mail?
b) Como envio por e-mail uma solicitação de parafusos para a fábrica?
As duas frases expressas como dúvidas de usuários, possuem o mesmo significado embora
tenham sido escritas de forma diferente, caracterizando assim uma paráfrase.
Para tratar este tipo de inconsistência, é de grande importância a incorporação de
um dicionário de sinônimos ao sistema de RBC, o que torna a busca mais eficiente e o
resultado do cálculo de similaridade entre os casos e o problema mais preciso e confiável.
O dicionário de sinônimos tem como objetivo associar palavras com o mesmo
significado, mas que são escritas de forma diferente. Para os problemas descritos acima, as
palavras “pedido” e “solicitação” possuem o mesmo significado e são sinônimos dentro do
domínio, embora sejam escritas de forma diferente (FERNANDES et al., 2010).
49
2.3.3.2 Modelos de Recuperação de Informação
Os modelos tradicionais de Recuperação de Informação denominados modelos
quantitativos, surgiram nas décadas de 60 e 70, sendo aperfeiçoados na década de 80, e ainda
hoje se constituem os modelos de RI mais tradicionais estando presentes na maioria dos
sistemas de recuperação atuais, inclusive na web (WIVES, 1997; BAEZA-YATES, 1999 apud
FERRAZ, 2011).
Esta seção aborda os principais modelos de RI quantitativos que são: o Booleano,
o Probabilístico e o Vetorial sendo este último o escolhido para o sistema proposto e que é
estudado como maior profundidade neste trabalho.
2.3.3.2.1 Modelo Booleano
Dentre os modelos de RI citados, o modelo Booleano é considerado o mais
simples, baseado na teoria dos conjuntos e na álgebra Booleana. As consultas são definidas
por meio de expressões Booleanas compostas por termos de índice e os conectores NOT, AND
e OR. Neste modelo, os termos de índice ou estão presentes num documento ou não estão,
portanto, os pesos dos termos assumem valores binários, 0 ou 1 (TSUJI; KAMAURA, 2008).
As vantagens do modelo Booleano são a simplicidade e o formalismo claro
subjacente ao modelo. Entretanto este modelo diz apenas se cada documento é relevante ou
não, ou seja, não existe a noção de parcialidade na verificação das condições da consulta.
Outras desvantagens estão na restrição da qualidade dos resultados obtidos, sendo que é
retornando um conjunto de documentos ou muito pequeno ou muito grande e nem sempre a
tradução de uma requisição de informação para uma expressão booleana é uma tarefa simples,
principalmente para usuários comuns (TSUJI; KAMAURA, 2008).
2.3.3.2.2 Modelo Probabilístico
50
O modelo Probabilístico trabalha inicialmente em cima da possibilidade de um
documento aleatório ser relevante ou não. Devido ao fato de os usuários não conhecerem
previamente quais são as características de cada documento, a primeira consulta é escrita
tentando descobrir quais são essas características, o que gera uma primeira descrição
probabilística do conjunto. Através dos resultados obtidos nas execuções de consultas
subsequentes à primeira, é possível que ocorra uma melhoria gradativa desses resultados,
proveniente justamente da interação sucessiva do usuário, o qual pode selecionar, dentre os
documentos retornados, aqueles que considera mais relevantes à sua necessidade. Essa
característica relacionada à interação do usuário é conhecida como Relevance Feedback
(WIVES, 1997; FERNEDA, 2003 apud FERRAZ, 2011).
Porém, em suas formalizações matemáticas, algumas hipóteses usadas no
processo de simplificação dos cálculos probabilísticos podem deixar margem de dúvida
quanto à sua precisão, e adicionalmente, a alta complexidade é um fator que desencoraja seu
uso (FERRAZ, 2011).
2.3.3.2.3 Modelo Vetorial
Ao contrário do modelo Booleano, no modelo Vetorial existe a possibilidade de se
obter documentos que correspondam parcialmente a uma expressão de busca, através da
atribuição de pesos não binários aos termos indexados contidos na consulta e nos documentos.
Através desses pesos é que são calculados os graus de similaridade entre os documentos da
base e a expressão de busca do usuário. Assim, o resultado das buscas se relaciona à obtenção
de documentos classificados pelo grau de similaridade que possuem em relação a expressão
de busca formulada pelo usuário, introduzindo dessa maneira a noção de relevância aos
documentos obtidos (FERRAZ, 2011).
O modelo Vetorial é um modelo algébrico usado para representar os termos de
índices dos documentos e das consultas num espaço vetorial. Associado a cada um dos
termos, atribui-se um peso de valor não binário (ao contrário do modelo booleano) que
posteriormente será utilizado no cálculo do grau de similaridade entre o documento
armazenado na base e a consulta do usuário. Assim, dada uma consulta, o modelo vetorial
51
avalia de forma ponderada o quanto um documento é relevante, possibilitando uma
correspondência parcial em relação à consulta (TSUJI; KAMAURA, 2008).
Conforme Baeza-Yates e Ribeiro-Neto (1999):
No modelo vetorial, o peso wi,j associado ao par (ki , d j) é positivo e não binário, onde
ki é um termo de índice e d j um documento. Além disso, os termos de índices na
consulta também são ponderados. Seja wi,q um peso associado ao par [ki , q], onde
wi,q ≥ 0. Então, o vetor da consulta 𝑞 é definido como 𝑞 = (𝑤1,𝑞 , 𝑤2,𝑞 , … , 𝑤𝑡,𝑞 ) onde
t é o número total de termos de índices no sistema. O vetor do documento d j é
representado por d 𝑗 = (𝑤1,𝑗,𝑤2,𝑗 ,…,𝑤𝑡,𝑗 ).
No modelo vetorial são utilizados os fatores: tf factor, que calcula a quantidade de
vezes que o termo ki aparece no documento dj, (fornecendo uma medida de quão bem k i
descreve dj), e o idf factor (inverse document frequency) que mede o inverso da frequência do
termo ki dentro da coleção dos documentos (fornecendo uma medida da dissimilaridade). O
principal motivo do uso desse fator idf se deve ao fato de que uma palavra que apareça em
muitos documentos não pode ser usada para distinguir os objetos da coleção (TSUJI;
KAMAURA, 2008).
Para a realização do cálculo do peso, devem ser considerados dois fatores principais
(FERRAZ, 2011):
1) A quantidade de vezes que o termo aparece dentro de um documento;
2) A quantidade de vezes que esse termo aparece em outros documentos.
Conforme Baeza-Yates e Ribeiro-Neto (1999):
Seja N o número total de documentos no sistema e ni o número de documentos que o
índice ki aparece. Seja freqi,j a frequência bruta do termo ki no documento d j (isto é, o
número de vezes que o termo ki é mencionado no texto do documento d j). Então, a
frequência normalizada fi,j do termo ki no documento d j é dada por:
onde o máximo é computado sobre todos os termos que são mencionados no texto
do documento d j .Se o termo ki não aparece no documento d j, então fi,j = 0. Além
disso, seja idfi a frequência inversa do documento para ki dada por:
52
Assim, a fórmula conhecida como tf-idf dada aos pesos é:
ou uma variação dessa fórmula.
É importante destacar o fato de que, quanto mais um termo aparece em um
número maior de documentos, mais o idf se aproxima de zero, ou seja, a relevância desse
termo em relação ao conjunto de documentos diminui.
Assim, dado um vetor dj representando um documento e um vetor q representando
a expressão de consulta do usuário, o cálculo da similaridade é por sua vez realizado
calculando-se o cosseno do ângulo formado pelos vetores dj e q através da equação mostrada
a seguir (OLIVEIRA, 2005 apud FERRAZ, 2011).
Onde dj e q são as normas do vetor do documento e do vetor da consulta respectivamente.
Sendo assim, a similaridade sim(dj,q) calculada entre dois documentos varia de 0 (completa
dissimilaridade) até 1 (completa similaridade). Como o modelo vetorial objetiva quantificar a
relevância de um documento e não simplesmente definir se o documento é relevante ou não, é
possível através do grau de similaridade, fazer um ranqueamento dos documentos relevantes.
Para o sistema proposto uma busca realizada recupera os cinco documentos mais
relevantes classificados por ordem de similaridade.
Tomando como exemplo a seguinte consulta q de um usuário:
“Como mudar a resolução da tela?”
Efetuando o pré-processamento do texto do documento q através da eliminação das
stopwords, teríamos os seguintes termos ki indexadores:
Como mudar a resolução da tela?
k1
k2
k3
mudar resolucao tela
Além da eliminação das stopwords, o algoritmo de RI também elimina os sinais
de pontuação, caracteres especiais, chaves, colchetes, etc. As vogais acentuadas como “á”,
“ô” são substituídas pela sua vogal correspondente sem acentuação e as cedilhas “ç” são
53
substituídas simplesmente pela letra “c”. Além disso, todos os documentos são convertidos
para letras minúsculas o que aumenta a eficiência durante o processo de comparação.
Durante o processo de cálculo do peso wij de um termo ki em um dado documento
dj, o algoritmo de RI quantifica as frequências fi,j e ni de ki em dj varrendo todos os
documentos e buscando de forma direta o termo indexado ki do documento q da consulta.
Caso as frequências fi,j ou ni de um termo sejam iguais a 0, ou seja, se um dado termo ki da
consulta não aparece no documento dj e nem em outros documentos, o algoritmo de RI
reinicia uma nova busca para este termo, desta vez traduzindo o termo da consulta (palavra
utilizada pelo usuário) pelo termo correspondente do documento através do dicionário de
sinônimos.
É de fundamental importância que todos os documentos (casos) da base de
conhecimento sejam cadastrados utilizando os termos mais corretamente indicados,
respeitando a língua e a gramática. O Engenheiro do conhecimento deverá cadastrar no
dicionário de sinônimos do sistema as principais palavras ou termos contidos na base de
conhecimento que estão sujeitas a variações como gírias, abreviações ou propriamente seus
sinônimos que possam eventualmente vir a ser utilizados nas consultas por usuários. O
dicionário de sinônimos aumentará a chance de recuperação de documentos relevantes.
Na consulta “Como mudar a resolução da tela e melhorar a imagem do monitor?”,
o termo “mudar” não seria encontrado de forma direta nos documentos sendo este um
sinônimo do termo “alterar” adotado pelo Engenheiro do Conhecimento.
Durante o processo de cálculo do peso deste termo, o algoritmo de RI não encontrando a
palavra “mudar” nos documentos, automaticamente buscaria o seu termo correspondente
através do dicionário de sinônimos, recuperando assim o termo “alterar”, finalizando o
cálculo e dando continuidade aos próximos termos do documento da consulta.
Calculando-se o peso dos termos indexadores ti da consulta q, teríamos seguintes valores
fictícios conforme a Tabela 1.
Tabela 1 - Pesos dos termos da consulta
Termos (ti)
Pesos (wi )
t1
alterar
0.3
t2
resolucao 0.7
t3
tela
0.5
Fonte: Elaboração do autor, 2011.
54
Neste caso as frequências fi,j de cada termo são calculadas sobre o próprio documento da
consulta q.
Considerando também os documentos fictícios d1 e d2 indexados pelos termos ti, teríamos os
seguintes pesos conforme tabela a seguir.
Tabela 2 - Pesos dos termos dos documentos
Termos (ti)
Pesos (wi ) de d1 Pesos (wi ) de d2
t1 alterar
0.4
0.2
t2 resolucao 0
0.6
t3 tela
0
0.6
Fonte: Elaboração do autor, 2011.
Conforme a Tabela 2, os pesos com valor igual a 0 representam a inexistência do
termo indexador ti no documento dj.
Calculando-se a similaridade de cada documento dj em relação a consulta q teríamos:
(
𝑞)
(
𝑞)
√(
)
( )
√(
)
(
(
)
)
√(
)
(
)
(
)
( )
√(
)
(
)
(
)
De acordo com os resultados obtidos, conclui-se que o documento d2 apresentou o maior
valor, possuindo assim 82% de similaridade em relação ao documento da consulta q.
As principais vantagens de utilizar o modelo vetorial são (TSUJI; KAMAURA, 2008):

O uso de termos de índices ponderados melhora o desempenho da recuperação de
informação;

Os documentos recuperados tendem a se aproximar mais ao que a consulta descreve,
uma vez que a correspondência pode ser parcial entre ambos;
55

Após o cálculo da correlação entre o documento e a consulta, é possível ordenar os
resultados obtidos conforme o grau de similaridade;

É um modelo simples e rápido.
2.3.4 Exemplos de Aplicações RBC
A seguir alguns exemplos de sistemas de RBC aplicados ao domínio de Help
Desk inclusive utilizando FAQ que são: SMART, FAQ para Help Desk, CBR-Answers,
FAQFinder e FAQBots.
O SMART da Compaq é utilizado para auxiliar seus clientes e é acessível através
de uma ligação telefônica. O sistema está em operação desde 1992 e tem um processo de
constante mudança, com cerca de 600 estudos de caso. Uma comparação feita pela Compaq
constatou-se que após a introdução do sistema houve uma melhoria de 175% para a taxa de
resposta de pedidos de clientes. Com a introdução do SMART, a duração média de uma
chamada foi reduzida em 30%, 87% das chamadas foram resolvidas no primeiro nível do
suporte e 95% das chamadas de clientes resolvidas dentro de um período de 10 minutos
(WESS, 1998 apud FERNANDES et al., 2010).
O FAQ para Help Desk desenvolvido na ferramenta Lotus Notes é um sistema de
help desk integrado a uma base de FAQ que possibilita a inclusão de problemas ocorridos
pelas mais diversas áreas de negócios de uma empresa de TI. O sistema ainda permite a
coordenação e acompanhamento das solicitações cadastradas no decorrer de cada etapa do
fluxo, permitindo uma rápida consulta e retorno aos interessados no processo. Todo este
mapeamento constitui uma importante base de conhecimento sobre o negócio da empresa. À
medida que um problema é cadastrado, verificado e solucionado, o mesmo pode ser
classificado e transferido para formação de uma base de dados sobre os problemas mais
comuns e suas respectivas soluções (LIMA et al., 2004 apud FERNANDES et al., 2010).
O CBR-Answers é um sistema utilizado para suporte por telefone e outras
aplicações de help desk. A ideia principal consiste em analisar os documentos existentes em
uma base FAQ, de modo que a consulta feita pelo usuário identifique os documentos mais
similares relacionados à consulta. Os documentos existentes são utilizados e analisados pelo
56
sistema que converte o documento textual em uma estrutura no formato de um caso. Este
processo é feito de modo automático, ou seja, nenhum caso é criado de forma manual (DE
SÁ, 2007 apud FERNANDES et al., 2010).
Um exemplo de RBC Textual é o FAQFinder, um sistema que é capaz de
responder perguntas realizadas em linguagem natural (em inglês). O FAQFinder realiza uma
combinação de técnicas de RBC com técnicas de recuperação de informação e processamento
de linguagem natural para a recuperação de documentos. Ele foi projetado como um sistema
genérico para recuperar FAQs sem se focar em um domínio específico. Para isto, executa um
processo em dois passos. No primeiro, ele realiza uma análise superficial sobre as palavraschave contidas na consulta para determinar quais são os casos que possuem uma maior
relação com ela. Em seguida, ele realiza uma análise mais aprofundada nestes casos
selecionados para determinar quais são as perguntas que serão retornadas ao usuário como
resposta (BURKE et al., apud FERNANDES et al., 2010).
Outro exemplo são os robôs de FAQ, conhecidos como FAQBots. Estes softwares
são encarregados de responder a perguntas dos usuários sobre o assunto contido na sua base
de FAQ. Este software consegue conversar com o usuário sobre o seu domínio, mas assume
ignorância quando questionado sobre assuntos fora do seu conhecimento. A seleção de
respostas é feita através de casamento de padrões: palavras-chave selecionadas a partir de
cada questão são comparadas a uma lista interna de combinações de chaves que indexam as
respostas (LAUREANO, 1999 apud FERNANDES et al., 2010).
2.3.5 Mapa das Técnicas de RBC Utilizadas
O mapa mostrado a seguir, resume todos os tipos, métodos e técnicas empregadas
no modelo de RBC do sistema proposto.
Itens
Técnica/Tipo/Modelo
Raciocínio Baseado em Casos
Textual
Representação do conhecimento
Contexto Levemente Textual
Documento = Caso
57
Recuperação
1
Ciclo
RBC
Sequencial
Recuperação de Informação
Modelo Vetorial
Pré-processamento de Texto
Eliminação de Stopwords
Recurso de Pesquisa
Dicionário de Sinônimos
2
Reutilização/Adaptação
Adaptação Nula
3
Revisão
Manual
Retenção
Manual
Retenção de Solução de Problemas /
Retenção de Documentos
4
Quadro 2 - Mapa das técnicas de RBC utilizadas
Fonte: Elaboração do autor, 2011.
O Quadro 2 apresenta a sequência de elementos respeitando o ciclo do Raciocínio Baseado
em Casos.
2.4
CONSIDERAÇÕES
A seção Sistemas Especialistas apresentada, elucida uma série de pontos que são
essenciais para a compreensão do assunto, servindo como uma pré-introdução ao tema
Raciocínio Baseado em Casos.
É importante salientar que algumas características dos SEs que foram abordados
como principalmente base de regras, dinamismo de interfaces e autoaprendizagem com
geração de novas regras, não estão presentes no sistema que é proposto, visto que tais
características são comuns aos SEs estruturados, diferente do protótipo apresentado que
utiliza Raciocínio Baseado em Casos Textual.
58
3
MÉTODO
Segundo Garcia (1998, p. 44), “Metodologia significa, etimologicamente, o
estudo dos caminhos, dos instrumentos usados para se fazer pesquisa científica, os quais
respondem o como fazê-la de forma eficiente.”.
Este capítulo apresenta os itens que constituem o método de pesquisa adotado
bem como sua caracterização, etapas, a proposta da solução e as delimitações do projeto.
3.1
CARACTERIZAÇÃO DO TIPO DE PESQUISA
O presente trabalho utiliza a pesquisa aplicada que segundo Silva e Menezes
(2005), “objetiva gerar conhecimentos para aplicação prática e dirigi-los à solução de
problemas específicos [...]”.
Quanto aos procedimentos técnicos, é utilizada a pesquisa bibliográfica.
Conforme Motta e Leonel (2007, p. 112), pesquisa bibliográfica “É aquela que se desenvolve
tentando explicar um problema a partir das teorias já publicadas em diversos tipos de fontes
[...]”. Com base em Koche (1997, p. 122 apud MOTTA; LEONEL, 2007, p. 113), alguns dos
objetivos a se alcançar com a pesquisa bibliográfica são: a) ampliar o grau de conhecimento
em uma determinada área, capacitando o investigador a compreender ou delimitar melhor um
problema de pesquisa; b) dominar o conhecimento disponível e utilizá-lo como base ou
fundamentação na construção de um modelo teórico explicativo de um problema.
Para o presente trabalho, das principais fontes de pesquisa utilizadas estão: livros
de autores e Dissertações, Trabalhos de Conclusão de Curso, artigos e manuais publicados na
internet.
O tipo de abordagem adotado na pesquisa e de natureza qualitativa. Conforme
Motta e Leonel (2007, p. 112), “O principal objetivo da pesquisa qualitativa é o de conhecer
as percepções dos sujeitos pesquisados acerca da situação-problema, objeto da investigação.”.
Como técnica de coleta de dados, é aplicado um questionário de perguntas
fechadas a um número limitado de entrevistados que na qualidade de usuários testaram o
protótipo.
59
3.2
ETAPAS
O processo de pesquisa e elaboração deste trabalho organiza-se de acordo com as
seguintes etapas:
1) Definição do problema e proposta da solução;
2) Pesquisa e estudo das tecnologias existentes;
3) Revisão bibliográfica;
4) Modelagem do sistema;
5) Desenvolvimento do protótipo do sistema;
6) Testes e avaliação.
3.3
PROPOSTA DA SOLUÇÃO
Desenvolvimento de um sistema para help desk que utiliza a técnica de Raciocínio
Baseado em Casos (RBC).
O sistema é uma aplicação web desenvolvida inicialmente para intranet podendo
futuramente ser adaptada para internet. O público alvo a quem se destina a solução proposta
são organizações de pequeno a grande porte que possuem redes locais de computadores.
Um dos principais objetivos da solução é reduzir o volume de chamados de help
desk endereçados a equipe de especialistas. Para isso, a aplicação conta com um recurso de
autoatendimento que e exerce o papel de atendimento nível zero.
O recurso de autoatendimento provê um motor de busca implementado sob os
padrões do modelo de recuperação de informação Vetorial, como sendo a principal ferramenta
utilizada pelos usuários no processo de busca de soluções para dúvidas e questões, neste caso,
relacionadas à informática, embora aceite qualquer domínio de conhecimento.
Caso a solução do problema não seja encontrada via autoatendimento, o sistema
dá condições ao usuário para abrir um chamado através dos recursos normais de um sistema
de help desk convencional ou também enviar sua dúvida a um especialista que de forma
assíncrona poderá respondê-la e publicá-la como um novo caso.
60
A proposta da solução apresentada pode ser verificada com mais detalhes através dos passos
que são vistos a seguir:
1) Sempre que os usuários acessarem o sistema, a primeira tela a ser exibida é a de
autoatendimento. A intenção inicial com isso é estabelecer a cultura de uso frequente
desta ferramenta e motivar os usuários a sempre buscar a solução de problemas através da
base de conhecimento;
2) Na tela de autoatendimento é disponibilizado um painel de pesquisa simples que utiliza o
motor de busca onde o usuário poderá informar o seu questionamento digitando uma
pergunta em linguagem natural para o sistema como, por exemplo, “como faço para
configurar uma conta de e-mail?” ou “como imprimir frente e verso na impressora x?”.
Assim que a questão é informada, basta que o usuário execute a busca;
3) Através dos mecanismos de RBC já vistos no capítulo anterior, o sistema tentará
recuperar os casos mais similares ao problema colocado pelo usuário. Por definição,
serão apresentados até cinco casos no máximo. Como a base de casos é uma lista de
FAQ, o sistema apresentará os casos recuperados como perguntas (sem a descrição da
respectiva resposta), similares à questão do usuário. Cada FAQ mostrada na tela possui
um hyperlink onde o usuário poderá clicar e assim visualizar a resposta em uma tela
separada;
4) Caso alguma das soluções apresentadas pelo sistema satisfaça o atual problema, o usuário
poderá adotar o caso escolhido como solução;
5) Caso o sistema não tenha retornado resultados ou nenhuma das soluções recuperadas
satisfaz o atual problema, o usuário terá duas opções, ou ambas se preferir:
a) Criar um chamado de help desk normalmente e aguardar a solução por parte dos
analistas de suporte;
b) Postar sua questão que não foi respondida via autoatendimento ao Help Desk para
que possa se tornar uma nova FAQ como sendo um novo caso da base de
conhecimento. Para que isto seja possível, é disponibilizado na tela de busca de
soluções o botão “Postar Dúvida” que direciona a um formulário onde o usuário pode
informar sua questão juntamente com descrições complementares (Ver seção 5.3.2
Busca da Solução e Retenção de Novos Casos).
61
6) Todas as dúvidas postadas são armazenadas em uma lista de questões pendentes que
ficam a cargo do Engenheiro do Conhecimento avaliar e julgar a sua retenção ou não na
base de casos;
7) Caso o Engenheiro do Conhecimento julgue ser útil criar um novo caso a partir de uma
questão postada, duas alternativas poderão ser adotadas:
a) Existindo algum caso semelhante na base que possa ser reutilizado, o novo caso
poderá ser gerado a partir deste através do recurso “Salvar Como”, disponibilizado
no formulário de FAQ e do recurso “Salvar Como FAQ”, disponibilizado no
formulário de questões. Assim que o caso (FAQ) é criado, as demais etapas de
adaptação, revisão e retenção poderão ser cumpridas;
b) Não existindo casos ou chamados semelhantes, o novo caso terá que ser criado do
zero.
O processo descrito pode ser verificado visualmente através do fluxograma a seguir.
62
Figura 7 - Fluxograma: Proposta da solução
Fonte: Elaboração do autor, 2011.
63
A Figura 7 mostrada apresenta o fluxo do processo de autoatendimento e retenção de novos
casos.
3.4
DELIMITAÇÕES DO PROJETO
3.4.1 Requisitos do Sistema
Com relação a determinados recursos que são esperados e que devem ser
atendidos como sendo requisitos comuns de um sistema de help desk, optou-se por não
contemplá-los neste trabalho em razão dos objetivos da proposta, limitando-se apenas aos
principais recursos que atendem aos requisitos necessários para apresentação da solução e da
ideia.
Dos recursos que não fazem parte dos requisitos cumpridos estão: Notificação por e-mail,
Relatórios Gerenciais e Manual de Ajuda.
3.4.2
Base de Conhecimento
Um sistema de RBC como sendo um Sistema Baseado em Conhecimento possui
uma base de casos que é construída inicialmente a partir do conhecimento que um especialista
humano tem sobre um domínio. Este domínio especialista é captado pelo Engenheiro do
Conhecimento por meio de entrevistas que visam documentar e converter experiências
práticas em casos que irão fazer parte da base de conhecimento.
A entrevista como sendo um instrumento de coleta de dados e aqui perfeitamente
aplicável, por escolha, não foi utilizada neste estudo. Em substituição a base de conhecimento
convencional inicial, obtida como já dito por entrevista, utilizou-se uma lista de FAQ do
domínio de help desk, que representa satisfatoriamente a base de conhecimento onde cada
FAQ individual (pergunta e resposta) representa um caso do SE (problema e solução).
64
4
MODELAGEM
Este capítulo apresenta os seguintes assuntos inerentes à construção do sistema
proposto: introdução à modelagem, a linguagem gráfica UML e a especificação do sistema no
que compreende os requisitos funcionais, requisitos não funcionais, regras de negócio, atores,
casos de uso, diagrama de classes e a modelagem de dados.
4.1
INTRODUÇÃO
Segundo Ramos (2006, p. 21), “Definimos um modelo como a interpretação de
um dado domínio do problema de acordo com uma determinada estrutura de conhecimento.”.
Um modelo pode ser especificado através de esquemas por meio de uma
determinada linguagem, representada de forma textual ou gráfica. Quando a representação do
esquema é realizada de forma gráfica, usualmente são utilizados diagramas (RAMOS, 2006).
Dentre os principais benefícios da modelagem podemos citar (RAMOS, 2006):

Ajudam a visualizar um sistema em sua situação passada, presente e futura;

Permite especificar a estrutura ou o comportamento de um sistema;

Permite guiar e controlar o processo de construção de um sistema;

Permite a documentação das decisões tomadas.
A escolha dos modelos tem profunda influência no modo como o problema
interpretado e como a solução é obtida. Um modelo adequado ilustra de forma correta
determinados aspectos da construção de um sistema, oferecendo uma simplificação dos
procedimentos envolvidos. Por fim, “[...] nenhum modelo é auto-suficiente. Qualquer sistema
não-trivial é representado de forma mais adequada por meio de um pequeno número de
modelos, razoavelmente independentes.” (RAMOS, 2006, p. 24).
65
4.2
UML
Segundo Fowler (2005, p. 25), “UML (Unified Modeling Language), é uma
família de notações gráficas, apoiada por um metamodelo único, que ajuda na descrição e no
projeto de sistemas de software, particularmente daqueles construídos utilizando o estilo
orientado a objetos (OO).”.
A UML é um padrão de linguagem relativamente aberto, controlado pelo OMG
(Object Managment Group), um consórcio aberto de empresas. É o resultado da unificação de
muitas linguagens gráficas de modelagem orientadas a objetos que surgiram no final dos anos
80 (FOWLER, 2005).
Uma das vantagens da UML é utilizá-la como ferramenta de esboço na
comunicação com a equipe do projeto, tendo como objetivo transmitir as ideias e alternativas
sobre o que se quer fazer de forma mais fácil. Deste modo, detalhes do código que será escrito
não são falados, mas apenas as questões importantes antes de se iniciar a programação
(FOWLER, 2005).
A UML versão 2.0 descreve 13 tipos de diagramas oficiais que são: diagrama de
atividades, diagrama de classes, diagrama de comunicação, diagrama de componentes,
diagrama de estruturas compostas, diagrama de distribuição, diagrama de visão geral da
interação, diagrama de objetivos, diagrama de pacotes, diagrama de sequência, diagrama de
máquinas de estado, diagrama de sincronismo e diagrama de casos de uso (FOWLER, 2005).
Para a modelagem do protótipo apresentado neste trabalho, são utilizados o
diagrama de casos de uso e o diagrama de classes que serão vistos neste capítulo.
4.3
ESPECIFICAÇÃO DO SISTEMA
Nesta seção são apresentados os itens da modelagem que constituem a
especificação do sistema proposto.
66
4.3.1 Requisitos Funcionais
Requisitos funcionais são aqueles que definem o comportamento do sistema,
capturados a partir dos casos de uso, que documentam as entradas, os processos e as saídas
geradas (MARTINS, 2007).
Para o sistema proposto, foram identificados 20 requisitos funcionais principais como é
listado no quadro a seguir.
Índice Título
RF01
Identificação do usuário corrente
RF02
Criação de conta de acesso
RF03
Gerenciamento de chamados
RF04
Criação/Edição/Visualização de chamados
RF05
Histórico de interações do chamado
RF06
Anexos do chamado
RF07
Motor de busca
RF08
Envio de dúvidas
RF09
FAQ
RF10
Pesquisa avançada de chamados
RF11
Gerenciamento de usuários
RF12
Perfis de usuário
RF13
Criação/Edição de contas de usuário
RF14
Gerenciamento de FAQs
RF15
Criação/Edição de FAQs
RF16
Gerenciamento de Questões
RF17
Edição de questões
RF18
Gerenciamento do dicionário de sinônimos
RF19
Gerenciamento da lista de termos ignorados
RF20
Gerenciamento dos campos globais
Quadro 3 - Requisitos Funcionais
Fonte: Elaboração do autor, 2011.
67
A definição de grande parte dos requisitos espelhou-se no atual sistema utilizado
pela empresa do estudo de caso e em alguns softwares existentes no mercado como mySuite
da BraZip Tecnologia e SysAid da SysAid Technologies.
A descrição detalhada de cada requisito pode ser verificada no apêndice B.
4.3.2 Requisitos Não Funcionais
Requisitos não funcionais são constituídos por características não necessariamente
associadas ao comportamento como, por exemplo: usabilidade (facilidade de utilização,
aspectos visuais, documentação e material de treinamento), confiabilidade (robustez, proteção
contra falhas, recuperação em caso de erro e precisão), performance (disponibilidade, bom
tempo de resposta, baixo uso de memória, outros) e suporte (facilidade de se manter o sistema
em produção) (MARTINS, 2007).
Para o sistema proposto, foram identificados 3 requisitos não funcionais principais dos tipos
usabilidade e performance, como é listado no quadro a seguir.
Índice
Título
RNF01 Interface do sistema
RNF02 Aparência da interface
RNF03 Desempenho do sistema
Quadro 4 - Requisitos Não Funcionais
Fonte: Elaboração do autor, 2011.
A descrição detalhada de cada requisito pode ser verificada no apêndice C.
68
4.3.3 Regras de Negócio
As regras de negócio determinam como o negócio em uma organização deve
operar, mantendo a estrutura do negócio, controlando ou influenciando algum aspecto do
negócio (BRG, 2000 apud MORGADO et al., 2007). Sob o ponto de vista do
desenvolvimento de software, as regras de negócio podem ser consideradas como requisitos
de um projeto, pois deverão ser implementadas nos sistemas computacionais que dão suporte
às operações
de um
negócio. Desta
forma, a abordagem ao desenvolvimento
de software baseada em regras de negócio consiste basicamente em tratá-las como requisito
prioritário (LEITE; LEONARDI, 1998 apud MORGADO et al., 2007).
Para o sistema proposto, foram identificadas 8 regras de negócio principais como é listado no
quadro a seguir.
Índice Título
RN01
Acesso ao sistema
RN02
Controle de acesso
RN03
Forma de atendimento
RN04
Pesquisa avançada de chamados
RN05
Gerenciamento de chamados
RN06
Gerenciamento de contas de usuários
RN07
Gerenciamento da base de conhecimento
RN08
Gerenciamento das configurações
Quadro 5 - Regras de Negócio
Fonte: Elaboração do autor, 2011.
A descrição detalhada de cada regra pode ser verificada no apêndice D.
69
4.3.4 Atores
O domínio de uma aplicação é constituído por atores que representam papéis.
Entende-se Ator como um agente que interage com o sistema como sendo um usuário ou
categoria com papel definido, podendo se tratar de pessoas, máquinas, dispositivos ou
sistemas. Embora os elementos gráficos utilizados nos diagramas simbolizem pessoas, atores
não precisam obrigatoriamente sê-las (FURTADO, 2002).
É importante ressaltar que um ator representa um papel, e não um usuário
individual do sistema de modo que um ator pode representar muitos papeis e um papel pode
ser representado por muitos atores (FURTADO, 2002).
Para o sistema proposto, foram identificados 4 atores que são: o solicitante, o suporte, o
administrador e o analista RBC.

Solicitante: Funcionários da organização que utilizam o sistema para buscar soluções
ou criar chamados relativos a problemas ou necessidades ligadas a TI;

Suporte: Analistas de suporte que utilizam o sistema como ferramenta de controle e
gerenciamento dos chamados;

Administrador: Geralmente analistas de suporte ou pessoa responsável que utilizam o
sistema como ferramenta de controle e gerenciamento dos chamados e também
efetuam manutenções e configurações de software que exijam um nível de permissão
mais elevado podendo atuar como Analista RBC;

Analista RBC: Geralmente Engenheiros do Conhecimento ou pessoa responsável pela
manutenção e o gerenciamento da base de casos, do dicionário de sinônimos e da lista
de stopwords.
70
uc Atores
Solicitante
Suporte
Administrador
Analista RBC
Figura 8 - Atores
Fonte: Elaboração do autor, 2011.
A Figura 8 identifica os atores do sistema através da notação gráfica UML.
4.3.5 Casos de Uso
De acordo com a notação UML, um caso de uso é formalmente definido como o
conjunto de sequências de ações que um sistema desempenha para produzir um resultado
observável de valor a um ator específico (JACOBSON, 1992 apud FURTADO, 2002).
A modelagem de casos de uso é uma técnica usada para descrever as
funcionalidades de um sistema através de atores que interagem. Atores representam papeis e
iniciam casos de uso que por sua vez, devem retornar resultados a estes atores. O caso de uso
descreve o comportamento do sistema sob diversas condições conforme este responde a uma
requisição de um ator, chamado de ator primário. O ator primário inicia uma interação com o
sistema para atingir algum objetivo. O sistema responde, protegendo os interesses de outros
atores onde diferentes comportamentos ou cenários podem surgir conforme as requisições que
são feitas e as condições que as cercam (COCKBURN, 2001).
Quanto à representação, os casos de uso são fundamentalmente textuais embora
possam ser escritos utilizando fluxogramas ou diagramas. Usualmente servem como um meio
de comunicação entre as pessoas envolvidas no projeto (COCKBURN, 2001).
“O principal diagrama utilizado em UML é o diagrama de casos de uso. Ele
fornece um modo de descrever a visão externa de um sistema de informações e suas
interações com o mundo, representando uma visão de alto nível de funcionalidade.”
(FURLAN, 1998 apud FURTADO, 2002).
71
Para o sistema proposto, foram identificados 34 casos de uso principais como é listado no
quadro a seguir.
Índice Título
CU01
Criar conta de acesso
CU02
Criar chamado
CU03
Visualizar chamado
CU04
Editar chamado
CU05
Excluir chamado
CU06
Inserir anexo
CU07
Excluir anexo
CU08
Pesquisar chamados
CU09
Pesquisar FAQs
CU10
Visualizar FAQ
CU11
Pesquisar casos similares
CU12
Visualizar caso similar
CU13
Postar dúvida
CU14
Editar questão
CU15
Salvar questão como FAQ
CU16
Excluir questão
CU17
Criar caso
CU18
Editar caso
CU19
Excluir caso
CU20
Inserir palavra
CU21
Editar palavra
CU22
Excluir palavra
CU23
Inserir sinônimo
CU24
Editar sinônimo
CU25
Excluir sinônimo
CU26
Inserir termo ignorado
CU27
Editar termo ignorado
CU28
Excluir termo ignorado
CU29
Criar conta de usuário
72
CU30
Editar conta de usuário
CU31
Excluir conta de usuário
CU32
Inserir opção em campo global
CU33
Editar opção em campo global
CU34
Excluir opção em campo global
Quadro 6 - Casos de Uso
Fonte: Elaboração do autor, 2011.
A descrição detalhada de cada caso de uso pode ser verificada no apêndice E.
4.3.5.1 Diagrama de Casos de Uso do Solicitante
Os principais casos de uso relacionados ao ator Solicitante são apresentados
através do diagrama a seguir.
73
uc Solicitante
CU13 - Postar dúv ida
«extend»
CU11 - Pesquisar
casos similares
«extend»
CU12 - Visualiar caso
similar
CU07 - Excluir anexo
CU02 - Criar chamado
«extend»
«extend»
CU01 - Criar conta de
acesso
CU06 - Inserir anexo
Solicitante
«extend»
CU03 - Visualizar
chamado
CU04 - Editar chamado
«extend»
«extend»
CU08 - Pesquisar
chamados
CU09 - Pesquisar FAQs
CU10 - Visualizar FAQ
«extend»
Figura 9 - Diagrama de Casos de Uso (Solicitante)
Fonte: Elaboração do autor, 2011.
74
4.3.5.2 Diagrama de Casos de Uso do Suporte
Os principais casos de uso relacionados ao ator Suporte são apresentados através
do diagrama a seguir.
uc Suporte
CU31 - Excluir conta de
usuário
CU30 - Editar conta de
usuário
«extend»
CU29 - Criar conta de
usuário
CU05 - Excluir
chamado
CU02 - Criar chamado
CU06 - Inserir anexo
«extend»
Suporte
«extend»
CU03 - Visualizar
chamado
«extend»
CU08 - Pesquisar
chamados
Figura 10 - Diagrama de Casos de Uso (Suporte)
Fonte: Elaboração do autor, 2011.
CU04 - Editar chamado
«extend»
75
4.3.5.3 Diagrama de Casos de Uso do Analista RBC
Os principais casos de uso relacionados ao ator Analista RBC são apresentados
através do diagrama a seguir.
uc Analista RBC
CU14 - Editar questão
«extend»
CU15 - Salv ar
questão como FAQ
«extend»
CU16 - Excluir
questão
CU18 - Editar caso
«extend»
CU17 - Criar caso
CU19 - Excluir caso
Analista RBC
CU20 - Inserir
palav ra
CU21 - Editar palav ra
«extend»
CU23 - Inserir
sinônimo
CU24 - Editar
sinônimo
CU26 - Inserir termo
ignorado
CU27 - Editar termo
ignorado
Figura 11 - Diagrama de Casos de Uso (Analista RBC)
Fonte: Elaboração do autor, 2011.
«extend»
«extend»
CU22 - Excluir
palav ra
CU25 - Excluir
sinônimo
CU28 - Excluir termo
ignorado
76
4.3.5.4 Diagrama de Casos de Uso do Administrador
Os principais casos de uso relacionados ao ator Administrador são apresentados
através do diagrama a seguir.
uc Administrador
CU30 - Editar conta de
usuário
«extend»
CU31 - Excluir conta de
usuário
CU29 - Criar conta de
usuário
Administrador
CU32 - Inserir opção
em campo global
CU33 - Editar opção em
campo global
«extend»
CU34 - Excluir opção
em campo global
Figura 12 - Diagrama de Casos de Uso (Administrador)
Fonte: Elaboração do autor, 2011.
4.3.6 Diagrama de Classes
Antes de abordar diretamente este tópico conforme a terminologia da UML é
necessário explanar alguns conceitos que estão fortemente ligados e que fundamentam o
presente assunto.
77
A Programação Orientada a Objetos (POO) é uma técnica utilizada para
construção de sistemas computacionais e que imita o modo como os objetos são construídos
no mundo físico (CADENHEAD; LEMAY, 2005).
Na POO, um programa de computador pode ser entendido como um grupo de
objetos que trabalham em conjunto para realizar tarefas definidas. Cada objeto é parte
separada do sistema e interage com outras partes, atendendo propósitos específicos de forma
controlada (CADENHEAD; LEMAY, 2005).
Conforme Leite (2006), a POO tem dois objetivos fundamentais que são: a
reutilização de códigos já prontos e depurados e a modularização da escrita sendo esta última
alcançada com a definição da unidade fundamental da tecnologia, ou seja, o objeto. Desta
forma, através destes dois recursos é possível reduzir os custos de desenvolvimento e
manutenção.
Contudo, a capacidade de manipular objetos é apenas um aspecto da POO. Outra
característica importante é o uso de classes.
Quando características e operações similares em objetos distintos são
identificadas, é possível realizar sua classificação, ou seja, identificar classes (MELO, 2010).
De acordo Melo (2010), “Uma classe é a representação de um conjunto de objetos
que compartilham a mesma estrutura de atributos, operações e relacionamentos, dentro de um
mesmo contexto [...]”. Uma classe especifica a estrutura de um objeto sem informar quais
serão seus valores. Por outro lado, um objeto representa a ocorrência (instância) de uma classe
em um determinado momento (MELO, 2010).
Por fim, um diagrama de classes representa de forma gráfica e descreve os tipos
de objetos presentes no sistema e os vários tipos de relacionamentos entre eles. Além de o
diagrama de classes demonstrar as propriedades e operações de uma classe, ele pode
identificar as restrições que se aplicam conforme os objetos estão conectados (FOWLER,
2005).
Para facilitar a compreensão do modelo lógico da estrutura de classes que é
representado pelo diagrama de classes utilizado na modelagem do sistema proposto, é
demonstrado a seguir na Figura 13 o modelo conceitual mais simplificado da estrutura de
classes.
78
Interface do Usuário
Controle de Acesso
Motor de Busca
Acesso a Dados
Figura 13 - Modelo conceitual da estrutura de classes do sistema
Fonte: Elaboração do autor, 2011.
No modelo conceitual mostrado acima, cada retângulo identificado é um conjunto de classes
ou na terminologia UML, pacote.
Para o sistema proposto, o diagrama de classes pode ser verificado na Figura 14 a
seguir. Seguindo a estrutura do modelo conceitual mostrado na figura anterior, o diagrama é
representado em camadas de forma descendente na sequência: Interface do Usuário, Controle
de Acesso e Motor de Busca, e Acesso a Dados.
79
Neste diagrama é possível verificar as principais classes da interface do sistema sendo que
cada classe mostrada está vinculada a uma tela (página web) da aplicação.
Interface do Usuário
(Continua na próxima página)
80
Controle de Acesso
Motor de Busca
(Continua na próxima página)
81
Acesso a Dados
Figura 14 - Diagrama de classes
Fonte: Elaboração do autor, 2011.
É possível verificar a lista de métodos utilizados em cada classe representada no
diagrama da Figura 14. As setas pontilhadas representam as associações entre as classes de
cada pacote.
82
4.3.7 Modelagem de Dados
Conforme o IIBA (2011, p. 169), “O propósito de um modelo de dados é
descrever os conceitos relevantes de um domínio, os relacionamentos entre esses conceitos e
as informações associadas a eles.”.
Um Modelo de Dados (MD) geralmente é representado através de um diagrama,
apoiado por descrições textuais explicativas. Um MD representa de forma visual os vários
tipos de objetos, conceitos ou coisas que são importantes dentro do domínio da aplicação
além de seus atributos e inter-relacionamentos (IIBA, 2011).
4.3.7.1 Diagrama Entidade-Relacionamento
Enquanto os diagramas de classes são preferidos para apoiar o desenvolvimento
orientado a objetos, geralmente os Diagramas de Entidade-Relacionamento (DER) são os
mais utilizados quando o modelo de dados for utilizado como base para um banco de dados
relacional (IIBA, 2011).
Um modelo lógico de dados de alto nível descreve as informações relevantes do
domínio da aplicação e pode focar somente nas descrições das entidades, atributos e
relacionamentos mais importantes enquanto que modelos lógicos mais detalhados focam nas
descrições que abrangem todas as entidades, atributos e relacionamentos (IIBA, 2011).
Para o sistema proposto, o modelo lógico pode ser verificado na Figura 15 a seguir.
83
Questions
FAQ
DictionaryWords
ID
ID
ID
Q uestion
Q uestion
Word
C ategory _ID
Description
A nsw er
S tatus
FAQCategories
StopWords
ID
ID
C ategory
Word
DictionarySynonyms
ID
Word_ID
Sy nony m
Users
Requests
RequestCategories
ID
ID
ID
F ullN ame
Title
C ategory
U serN ame
DescriptionHistory
P hone
DeadlineDate
M ail
ResolutionDate
Department_ID
C reated
IsS upport
M odified
IsC BRA naly st
IsDone
IsA dministrator
Requestor_ID
Attachments
C ategory _ID
ID
P riority _ID
Request_ID
S ponsor_ID
F ileN ame
S tatus_ID
C ontentTy pe
Data
Departments
ID
Department
Priorities
Status
ID
ID
P riority
Status
Figura 15 - Diagrama Entidade-Relacionamento
Fonte: Elaboração do autor, 2011.
84
Para o DER mostrado na figura anterior, entende-se como entidades: as tabelas do
banco de dados do sistema que são representadas pelos retângulos, e atributos: os campos que
são listados dentro de cada tabela.
85
5
DESENVOLVIMENTO
Neste capítulo é apresentado o desenvolvimento do sistema proposto no que
compreende as principais tecnologias e ferramentas utilizadas demonstrando também o
histórico do que foi realizado na prática desde a modelagem até a implementação do código
de programação.
Na sequência é dada a apresentação do sistema onde são demonstradas todas as
principais telas que compõem a interface gráfica e a descrição dos recursos de cada uma.
Por fim, com o intuito de comprovar a eficiência do propósito que a solução se
destina, é descrito o processo de avaliação utilizado bem como os resultados obtidos.
5.1
TECNOLOGIAS E FERRAMENTAS UTILIZADAS
O critério de escolha das tecnologias e ferramentas utilizadas para o
desenvolvimento da solução proposta levou em consideração alguns aspectos importantes
julgados sob o ponto de vista do autor:

Familiaridade: Algumas das tecnologias que serão vistas a seguir já são conhecidas
do autor que as utiliza também em outros projetos;

Integração: A maioria das tecnologias e ferramentas escolhidas são produtos da
mesma empresa que os fornece e foram projetadas para trabalhar de forma integrada,
principalmente sob o ponto de vista do desenvolvimento;

Agilidade: O ambiente de desenvolvimento é altamente produtivo;

Suporte: É bastante vasta a documentação técnica no que inclui livros, tutoriais,
websites, fóruns, vídeos, etc. e dificilmente você ficará sem resposta frente a algum
problema ou dúvida.
86
Figura 16 - Tecnologias e ferramentas utilizadas
Fonte: Elaboração do autor, 2011.
A Figura 16 ilustra as marcas das tecnologias e ferramentas utilizadas na solução,
das quais serão brevemente apresentadas a seguir.
5.1.1 .NET Framework
Com um modelo baseado no conceito de máquina virtual conhecido como CLR
(Common Language Runtime), o .NET Framework criado pela Microsoft, mudou a forma com
que as aplicações são desenvolvidas para a plataforma Windows, sendo que não mais se
desenvolve para a plataforma Windows e sim para o .NET. Desta forma uma aplicação
baseada em .NET roda em qualquer plataforma que possua a máquina virtual .NET
Framework (SPAKI et al., 2008).
O .NET Framework é baseado em um modelo totalmente orientado a objetos e
integrado com as novas tecnologias do mercado. Ele possui o conceito de CTS (Common
87
Type System), permitindo a utilização de diversas linguagens de programação, de forma que
qualquer que seja a linguagem escolhida, o código compilado irá gerar um aplicativo para a
plataforma .NET com as mesmas características. Para desenvolver nesta plataforma é
necessário utilizar linguagens como Visual Basic, C#, Visual C++, Visual J#, Perl, COBOL e
outras (SPAKI et al., 2008).
Para o sistema proposto, o .NET Framework utilizado é o de versão 4.0.
5.1.2 ASP.NET
O ASP.NET é uma nova versão do ASP clássico (Active Server Pages), utilizado
para o desenvolvimento de aplicações web e baseado nos princípios da orientação a objetos
tendo o amplo suporte do .NET Framework (SPAKI et al., 2008).
O principal objetivo do ASP.NET é tornar o desenvolvimento de aplicações web
mais simples e ágil, ou seja, um modelo de programação orientado a eventos no qual os
programadores adicionam controles aos formulários e escrevem códigos para manipular esses
eventos associados a esses controles. Aplicativos construídos com ASP.NET são hospedados
no servidor web IIS (Internet Information Services) e usam protocolos como por exemplo,
HTTP (HyperText Transfer Protocol) e SOAP (Simple Object Access Protocol) (ARAÚJO,
2007).
5.1.3 C#
A linguagem de programação C# (pronuncia-se C Sharp) foi criada por Anders
Hejlsberg (criador do Turbo Pascal e arquiteto do Delphi), Scott Wiltamuth e Peter Gold em
1999. A C# é uma linguagem orientada a objetos simples e moderna derivando-se do C e C++
possuindo muitas similaridades sintáticas com a linguagem Java (ARAÚJO, 2007). Além de
herdar muitas características da linguagem C++, a C# possui uma sintaxe relativamente fácil e
de aprendizado rápido.
88
Devido a sua forte integração com a plataforma .NET Framework, a linguagem
C# é ideal para o desenvolvimento de aplicações web com ASP.NET (ARAÚJO, 2007).
5.1.4 IIS (Internet Information Services)
O IIS (Internet Information Services) é um servidor web criado pela Microsoft.
Um servidor web é um software que responde requisições HTTP do navegador de páginas da
internet, desta forma é considerado um servidor de ficheiros. Por outro lado, como pode
hospedar programas e fornecer resultados destes programas, é considerado também um
servidor de aplicações (COSTA, 2007). Desta forma o IIS permite hospedar aplicações em
ASP e ASP.NET para gerar conteúdo web dinâmico (ARAÚJO, 2007).
Para o sistema proposto, o IIS utilizado é o de versão 7.5.
5.1.5 SQL Server
O SQL Server da Microsoft é um banco de dados relacional destinado a suportar
aplicações com arquitetura cliente/servidor. Para o sistema proposto foi utilizada a versão
gratuita SQL Server 2005 Express Edition (SQLEXP).
O SQLEXP além de gratuito é uma versão leve e de fácil utilização que agiliza o
desenvolvimento e a implantação de aplicativos dinâmicos controlados por dados. Este banco
de dados oferece ferramentas avançadas e confiáveis de gerenciamento de dados com recursos
sofisticados, proteção de dados e bom desempenho. É indicado para aplicativos leves da web,
clientes de aplicativos incorporados e armazenamento de dados local. O SQLEXP foi
desenvolvido para ser de fácil implantação e criação de protótipos de forma rápida
(MICROSOFT, 2007).
89
5.1.6 SQL Server Management Studio Express
O SQL Server Management Studio Express (SSMSE) é a interface de
gerenciamento dos recursos do banco de dados SQL Server. Esta ferramenta desenvolvida
pela Microsoft é um ambiente de desenvolvimento integrado utilizado para acessar,
configurar, gerenciar e desenvolver todos os componentes do SQL Server. Através desta
interface, a criação e manipulação de bancos de dados em toda sua extensão se torna muito
mais rápida e fácil. O SSMSE combina um amplo grupo de ferramentas gráficas com editores
sofisticados que fornecem acesso ao SQL Server a desenvolvedores e administradores de
todos os níveis de experiência (MICROSOFT, 2009).
5.1.7 Visual Studio
O Visual Studio é um ambiente de desenvolvimento integrado ou IDE (Integrated
Development Environment) que reúne uma série de recursos e ferramentas para o
desenvolvimento de aplicações sobre a plataforma .NET Framework tanto para desktop, web
ou dispositivos móveis (MICROSOFT, 2010).
Para o sistema proposto, o Visual Studio utilizado é o de versão 2010.
5.1.8 jQuery
jQuery é uma biblioteca (ou API - Application Programming Interface) gratuita
de funções JavaScript criada por John Resig e disponibilizada como software livre e aberto. O
principal objetivo do jQuery é fornecer meios mais simplificados para interagir com o código
HTML (HyperText Markup Language) das páginas de websites através da linguagem
JavaScript, tendo como foco a redução da utilização de código (SILVA, 2008).
90
Conforme Silva (2008), a jQuery é usada para adicionar efeitos visuais e
animações, prover interatividade alterando o conteúdo de páginas e simplificar tarefas
específicas de JavaScript.
Para o sistema proposto, o jQuery utilizado é o de versão 1.4.1.
5.2
HISTÓRICO DO DESENVOLVIMENTO
O processo de desenvolvimento do sistema de help desk passou por algumas
etapas principais como: a modelagem do sistema, a modelagem de dados, a construção da
interface e a implementação do código de programação.
Cada uma das etapas citadas é vista com mais detalhes a seguir:
Modelagem do Sistema: Durante a modelagem do sistema foram definidos os requisitos
funcionais e os casos de uso em harmonia com cada parte interativa, sendo estas os atores.
Nesta etapa, a modelagem estaria dividida em duas partes principais: 1) modelagem de um
sistema de help desk tradicional; 2) modelagem da parte que constitui o Raciocínio Baseado
em Casos (RBC). A concepção da primeira parte se deu sem maiores dificuldades visto que o
autor já possuía certo conhecimento sobre sistemas de help desk o que ajudou a guiar o
processo de definição dos principais requisitos e funcionalidades. A concepção da segunda
parte que compreendia além da modelagem, o planejamento de como se daria a integração do
modelo de RBC escolhido ao sistema de help desk, ocorreu de forma mais criteriosa e
cautelosa dada também a falta de experiência do autor em definir de forma precisa, como tal
técnica de RBC poderia ser aplicada em termos práticos. Com relação à engenharia de
software, o uso de ferramenta case para a modelagem do sistema serviu apenas para criação
de alguns diagramas já vistos no capítulo 4.
Modelagem de Dados: A modelagem de dados consistiu a construção do banco de dados do
sistema. Para o sistema proposto foi necessário apenas um banco de dados contando com 13
tabelas. Toda modelagem de dados se deu através da ferramenta SQL Server Management
Studio Express que possibilitou a criação e configuração de cada entidade visualmente de
91
forma ágil e eficiente, inclusive a criação do diagrama entidade-relacionamento visto no
capítulo 4.
Construção da Interface: A interface compreende o front-end do sistema constituído por
todas as telas (ou páginas web). Para o sistema proposto foram necessárias 27 telas no que
compreende páginas de visualização de informações e formulários. Toda construção da
interface do sistema se deu através da IDE Visual Studio que foi utilizada não só para
concepção de cada página e seus componentes, mas também para criação das classes
vinculadas a estas páginas formando assim toda a camada de visualização (ou view). Para
alguns formulários que contém campos do tipo data, foi utilizada a função datepicker da API
jQuery que vincula a um simples campo de texto um calendário para clicar e selecionar a data
requerida o que otimiza muito a usabilidade. Outro recurso bastante interessante que foi
utilizado é o de validação de campos obrigatórios e com formatação pré-definida. A
plataforma .NET Framework provê classes com métodos específicos só para este tipo de
validação de fácil implementação onde o evento de validação ocorre totalmente no lado
cliente evitando assim envio de dados para servidor e atualizações de página desnecessárias.
Com relação às grades onde são listados, por exemplo, os chamados, os usuários ou as FAQs
do sistema, nenhuma destas teve que ser construída de forma programática, pois o Visual
Studio já traz grades como componentes gráficos pré-definidos bastando apenas vinculá-los a
uma fonte de dados.
Implementação do Código: A grande maioria das classes implementadas estão vinculadas a
camada de visualização constituída pelas telas do sistema. O ambiente de desenvolvimento
utilizado para escrever e testar o código de programação também foi o Visual Studio. Foram
implementadas duas classes principais com métodos de controle de acesso e acesso a dados.
A primeira classe possui métodos para controle de acesso a recursos do sistema conforme o
perfil do usuário corrente. A segunda classe possui os métodos típicos da camada DAL (Data
Access Layer) para acesso a dados do banco. Foi criado também um pacote com duas classes
do RBC sendo que uma destas classes, chamada InformationRetrieval, implementa o principal
algoritmo do motor de busca, responsável pelo processo de recuperação de casos e do cálculo
de similaridade. A concepção das classes do RBC foi considerada a mais trabalhosa, pois
reproduzem o modelo de recuperação Vetorial apresentado no capítulo 2. Estas classes foram
construídas de forma completa e do zero baseando-se apenas no conteúdo bibliográfico
estudado.
92
As classes que implementam o motor de busca podem ser verificadas no
apêndice F.
5.3
APRESENTAÇÃO DO SISTEMA
Nesta seção é apresentada a interface gráfica do sistema constituída pelas telas de
visualização de informações e formulários.
5.3.1 Primeiro Acesso
Sempre que um usuário não cadastrado acessar o Help Desk, o controle de acesso
do sistema exibirá este formulário com alguns campos obrigatórios que o novo usuário deverá
preencher para assim criar sua conta de acesso. A tela mostrada na Figura 17 a seguir exibe o
formulário para cadastro de conta de acesso.
93
Figura 17 - Cadastro de conta de acesso
Fonte: Elaboração do autor, 2011.
Conforme os requisitos da modelagem, como o sistema foi projetado para
utilização em intranet, este é capaz de identificar o usuário corrente, capturando seu login de
rede que será o mesmo utilizado para o acesso ao Help Desk sem que haja a necessidade de
criar outro login de acesso ou digita-lo manualmente no momento do cadastro da conta de
acesso, bastando apenas informar os campos indicados como obrigatórios conforme a figura
anterior.
5.3.2 Busca da Solução e Retenção de Novos Casos
As telas e comentários a seguir têm como objetivo além de ilustrar a interface,
explanar em etapas o processo de busca da solução, por parte do usuário e o processo de
retenção de novos casos, por parte do Engenheiro do Conhecimento que embora aconteçam
de forma assíncrona, estão integrados.
94
5.3.2.1 Autoatendimento
Sempre que um usuário acessar o sistema, a primeira tela a ser exibida é a de
autoatendimento que disponibiliza com destaque a ferramenta de pesquisa para busca de
soluções. Através desta interface, o usuário poderá digitar de forma livre a sua questão e
efetuar a pesquisa clicando no botão “Perguntar”.
Figura 18 - Autoatendimento
Fonte: Elaboração do autor, 2011.
Conforme se verifica na Figura 18, o sistema retorna como resultado os casos
mais similares ao problema informado pelo usuário, sendo estes listados na parte inferior da
tela como hyperlinks que direcionam cada um a sua respectiva resposta que pode ser
visualizada em uma tela a parte.
95
5.3.2.2 Resposta
Através da lista de casos similares que é retornada pelo sistema, o usuário poderá
clicar no hyperlink de um dos casos para assim visualizar seu conteúdo.
Figura 19 - Resposta do caso similar
Fonte: Elaboração do autor, 2011.
A tela mostrada na Figura 19 é utilizada para visualizar a resposta/solução de um
caso específico.
5.3.2.3 Postar Dúvida
A partir do momento em que não existam casos similares ou nenhum dos casos
similares recuperados pelo sistema atenda ao problema apresentado, o usuário terá a opção de
enviar sua questão clicando no botão “Postar Dúvida”. Todas as questões enviadas são
passíveis de resposta pela área de Help Desk.
96
Figura 20 - Postar dúvida
Fonte: Elaboração do autor, 2011.
Ao clicar no botão “Postar Dúvida”, um formulário como é mostrado na Figura 21
é exibido onde o usuário poderá informar o título da sua questão e acrescentar informações
complementares se desejar.
Figura 21 - Formulário para envio de dúvidas
Fonte: Elaboração do autor, 2011.
97
Assim que o título da questão e demais informações adicionais do formulário são
preenchidos, a nova dúvida poderá ser enviada.
5.3.2.4 Lista de Questões
Todas as dúvidas postadas por usuários são armazenadas em uma lista de questões
pendentes (Figura 22) que deverão ser avaliadas pelo Analista RBC (ou Engenheiro do
Conhecimento). Vale a pena salientar que conforme os requisitos do sistema, usuários com
perfil de Solicitante não possuem permissão para acessar este recurso.
Figura 22 - Lista de questões
Fonte: Elaboração do autor, 2011.
A grade que lista cada questão exibe colunas como sendo alguns dos principais
campos do formulário de questões. É possível também ordenar os itens clicando no cabeçalho
de cada coluna.
98
Clicando no ícone da coluna “Editar” de um item da lista, é possível acessar suas
informações em modo de edição.
Figura 23 - Formulário de edição de questões
Fonte: Elaboração do autor, 2011.
Ao acessar uma questão da lista, o Analista RBC poderá visualizar suas
informações através de um formulário que permite sua edição como é mostrado na Figura 23.
Para auxiliar no controle e organização, um campo de opções chamado “Status” é
disponibilizado.
5.3.2.5 Retenção de Casos
Considerando que o Engenheiro do Conhecimento decida gerar um novo caso
para base de conhecimento do sistema a partir de uma questão específica, isto será possível
através do botão “Salvar Como FAQ” disponibilizado no formulário de edição de questões
(Figura 24).
99
Figura 24 - Salvando uma questão como FAQ
Fonte: Elaboração do autor, 2011.
Ao clicar no botão “Salvar Como FAQ” disponibilizado no formulário de edição
de questões, um formulário de criação de FAQ é exibido e as principais informações da
questão são transferidas para este facilitando assim o processo de elaboração da nova FAQ a
ser criada.
100
Figura 25 - Retenção de caso
Fonte: Elaboração do autor, 2011.
Por fim, elaborada e revisada a nova FAQ, esta poderá ser salva, representando
assim mais um caso da base de conhecimento.
5.3.3 Central de Chamados
A Central de Chamados é a principal tela do sistema de help desk de onde todo
inventário de incidentes pode ser gerenciado (Figura 26).
101
Figura 26 - Central de chamados
Fonte: Elaboração do autor, 2011.
A grade que lista cada chamado exibe colunas como sendo alguns dos principais
campos do formulário de chamados. É possível também ordenar os chamados clicando no
cabeçalho de cada coluna.
Para criar um novo chamado, o usuário deverá clicar no botão “Novo Chamado” e
preencher o formulário de criação.
A partir da Central de Chamados, clicando no hyperlink do titulo do chamado é
possível visualizar suas informações em modo leitura. Também a partir da Central de
Chamados, clicando no ícone da coluna “Editar” de um item da lista, é possível acessar suas
informações em modo de edição.
102
Figura 27 - Formulário de edição de chamados
Fonte: Elaboração do autor, 2011.
A Figura 27 apresenta a tela do formulário de edição de chamados utilizando
como exemplo um chamado específico.
Um dos Requisitos Funcionais definidos na Modelagem do sistema (RF12 Histórico de interações) estabelece que um chamado deve guardar o histórico de interações
entre os usuários envolvidos (Solicitante e Suporte).
103
Figura 28 - Histórico de interações do chamado
Fonte: Elaboração do autor, 2011.
No
exemplo
mostrado
pela
Figura
28,
é
destacado
no
campo
“Descrição/Acompanhamento” os registros de interação desde a abertura até a conclusão do
chamado.
5.3.4 FAQ
A lista de perguntas frequentes que é mostrada na Figura 29 a seguir relaciona
todas as FAQs da base de casos sendo este um recurso disponível a qualquer usuário do
sistema.
A grade que lista cada FAQ exibe colunas como sendo alguns dos principais
campos do formulário de visualização de FAQs. É possível também ordenar os itens clicando
no cabeçalho de cada coluna.
A partir da tela principal de FAQs, clicando no hyperlink do título de um item da
lista, é possível visualizar suas informações em modo leitura através de um formulário
específico.
104
Figura 29 - Lista de perguntas frequentes
Fonte: Elaboração do autor, 2011.
Também é possível através de uma ferramenta de busca que é disponibilizada,
realizar pesquisas por FAQs através de palavras chave. Ao clicar no botão “Buscar”, o
sistema recuperará as FAQs que contenham nos seus campos “Questão” ou “Resposta” as
palavras chave informadas. Ao final, uma lista de FAQs encontradas é impressa na tela como
resultado. O painel de busca permite ainda, que se faça um pré-filtro através do campo
“Categoria”.
5.3.5 Pesquisa Avançada
A Pesquisa Avançada de Chamados é um recurso de acesso a qualquer usuário
que permite a realização de pesquisas por chamados através de um número maior de filtros
como é mostrado na Figura 30 tendo como objetivo recuperar resultados mais específicos.
105
Figura 30 - Pesquisa avançada de chamados
Fonte: Elaboração do autor, 2011.
Para iniciar a pesquisa, o usuário poderá informar as palavras chave no campo
“Contendo” do painel de busca que serão procuradas pelo sistema no campo “Título da
Solicitação” de cada chamado do inventário. Ao final, uma lista de chamados encontrados é
impressa na tela como resultado. Ainda no painel de busca é possível filtrar a pesquisa por
categoria, prioridade e período de tempo da data de criação dos chamados.
A grade que lista cada item exibe colunas como sendo alguns dos principais
campos do formulário de chamados. É possível também ordenar os itens clicando no
cabeçalho de cada coluna.
5.3.6 Central de Usuários
A Central de Usuários é o principal recurso pelo qual as contas de usuários podem
ser gerenciadas (Figura 31). A grade que lista cada conta exibe colunas como sendo os
106
principais campos do formulário de usuários sendo possível ordenar os itens clicando no
cabeçalho de cada coluna.
Figura 31 - Central de usuários
Fonte: Elaboração do autor, 2011.
Para criar uma nova conta de usuário, o usuário deverá clicar no botão “Novo
Usuário” e preencher o formulário de cadastro. Clicando no ícone da coluna “Editar” de um
item da lista, é possível acessar as informações em modo de edição.
A Central de Usuários é um recurso que está disponível somente aos usuários com
perfil de Suporte e Administrador.
107
5.3.7 Base de Conhecimento
A tela inicial da Base de Conhecimento mostrada na Figura 32 a seguir, serve
apenas como um ponto de acesso aos recursos subjacentes que são: FAQ, Questões,
Dicionário de Sinônimos e a Lista de Termos Ignorados dos quais são apresentados
individualmente a seguir.
Figura 32 - Tela inicial da base de conhecimento
Fonte: Elaboração do autor, 2011.
A Base de Conhecimento é um recurso que está disponível somente aos usuários
com perfil de Analista RBC e Administrador.
108
5.3.7.1 FAQ
A lista de FAQs é o principal meio pelo qual a base de casos pode ser gerenciada
(Figura 33). Esta lista concentra todas as FAQs do sistema que são criadas e através dela uma
FAQ pode ser criada, editada ou excluída servindo como a principal ferramenta do Analista
RBC.
Figura 33 - FAQ (Base de Conhecimento)
Fonte: Elaboração do autor, 2011.
A grade que lista cada item exibe colunas como sendo alguns dos principais
campos do formulário de FAQs. É possível também ordenar os itens clicando no cabeçalho de
cada coluna.
Para criar uma FAQ, o usuário deverá clicar no botão “Nova FAQ” e preencher o
formulário de criação. Clicando no ícone da coluna “Editar” de um item da lista, é possível
acessar as informações em modo de edição.
109
Figura 34 - Formulário de edição de FAQs
Fonte: Elaboração do autor, 2011.
A Figura 34 ilustra o formulário de edição de FAQs que é similar ao de criação. É
através deste formulário que uma cópia da FAQ poderá ser criada através do botão “Salvar
Como” ou também excluída. Na imagem mostrada é utilizada como exemplo uma FAQ já
cadastrada no atual sistema.
5.3.7.2 Questões
Como já havia sido descrito nas seções anteriores, a lista de questões é um
repositório que concentra todas as questões postadas por usuários. Cada questão deverá ser
avaliada pelo Engenheiro do Conhecimento que decidirá se esta irá tornar-se uma FAQ da
base de casos ou não.
110
Figura 35 - Lista de questões (Base de Conhecimento)
Fonte: Elaboração do autor, 2011.
Nesta tela (Figura 35) não é disponibilizado o botão para criação de questões
sendo que o único meio pelo qual novas questões podem ser criadas é através da tela de
autoatendimento pelo recurso “Postar Dúvida” como já visto também nas seções anteriores.
5.3.7.3 Dicionário de Sinônimos
O Dicionário de Sinônimos ilustrado pela Figura 36 se divide em duas listas
principais onde a esquerda temos a relação de palavras utilizados para documentar as FAQs,
ou seja, os termos usualmente corretos que são os indexadores utilizados no algoritmo de RI.
À direita, os possíveis sinônimos para cada palavra sendo que cada palavra poderá ter n
sinônimos.
111
Figura 36 - Dicionário de sinônimos
Fonte: Elaboração do autor, 2011.
Todo gerenciamento e manutenção do dicionário se fazem através desta tela onde
o Engenheiro do Conhecimento poderá inserir, atualizar ou excluir tanto palavras como
sinônimos. É possível também ordenar os termos da lista de palavras clicando no hyperlink do
seu cabeçalho.
5.3.7.4 Lista de Termos Ignorados
A Lista de Termos Ignorados representa no RBC a stoplist, ou seja, a lista de
stopwords como já visto no capitulo 2.
112
Figura 37 - Lista de termos ignorados
Fonte: Elaboração do autor, 2011.
É através desta interface (Figura 37) que o Analista RBC poderá realizar a
manutenção da lista assim como inserir, atualizar ou excluir termos. É possível também
ordenar os termos clicando no hyperlink contido no cabeçalho da lista.
5.3.8 Campos Globais
O gerenciamento de campos globais é um recurso de configuração do sistema que
permite a manutenção dos campos de opções que são utilizados em todos os formulários
como, por exemplo, o campo “Status” do formulário de chamados, o campo ”Departamento”
do formulário de contas de usuários e outros.
113
Figura 38 - Campos globais
Fonte: Elaboração do autor, 2011.
A tela que é mostrada na Figura 38 está inicialmente dividida em três grupos que
podem ser visualizados verticalmente: Chamados, FAQ e Usuários sendo que cada grupo
relaciona os campos e suas respectivas opções.
É através desta interface que o Administrador do sistema realizará as manutenções
nestes campos caso seja necessário inserir, alterar ou excluir opções.
5.4
AVALIAÇÃO
Tendo visto que o sistema proposto engloba uma série de casos de uso que
poderiam ter aqui suas funcionalidades verificadas e atestadas, a avaliação deste protótipo
restringe-se apenas aos casos de uso relacionados ao Raciocínio Baseado em Casos como
sendo o foco principal ao que o presente trabalho se destina.
114
Segundo Wangenheim e Wangenheim (2003), o ciclo do RBC está dividido em
suas quatro etapas principais, cada uma com seus tipos e técnicas de aplicação específicas
como já visto no capítulo 2. Como para o sistema proposto a etapa de adaptação é nula e as
etapas de revisão e retenção são manuais, a única etapa avaliada em profundidade é a de
recuperação.
A avaliação do protótipo apresentado está dividida em duas partes principais que
são: avaliação do processo de recuperação de casos similares e avaliação geral do recurso de
autoatendimento dos quais serão vistos a seguir.
5.4.1 Avaliação do Processo de Recuperação de Casos Similares
Nesta primeira etapa da avaliação, todo o processo de recuperação de casos
similares é verificado, desde o envio da consulta, o processamento e o resultado retornado
pelo sistema. Através dos valores das principais variáveis que constituem o algoritmo de RI
utilizado, do qual foi construído com base no modelo de recuperação Vetorial, é provada a
eficiência da busca e correctitude dos resultados apresentados pelo protótipo.
Para tal avaliação, tomou-se como objeto de teste o seguinte problema de entrada:
“como excluir o histórico de arquivos da internet”
Figura 39 - Teste de recuperação de casos similares
Fonte: Elaboração do autor, 2011.
Após iniciar a busca, o sistema retorna os seguintes casos, classificados por ordem de
similaridade:
115
Figura 40 - Casos similares recuperados
Fonte: Elaboração do autor, 2011.
Os cinco casos recuperados são relacionados a seguir destacando-se os termos da consulta.
1 - Como apagar o histórico da internet e os arquivos temporários do Internet Explorer?
2 - Como remover uma conta de e-mail?
3 - Tenho acesso à rede local mas não consigo me conectar na internet.
4 - Como posso tornar o Internet Explorer o meu navegador padrão?
5 - Como salvar os arquivos anexos de uma mensagem no Outlook?
É importante ressaltar que devido a atual base de casos do protótipo não possuir
um número satisfatório de FAQs cadastradas, a busca pode retornar apenas um caso
considerado realmente similar, sendo este o número 1. O restante dos casos foi somente
recuperado pela coincidência de um dos termos da consulta, o que é esperado em RI Vetorial.
Considerando o fato de que em uma situação real os quatro casos restantes: 2, 3, 4 e 5 não
seriam úteis para o usuário, isto não refuta a avaliação do presente teste.
Para o problema de entrada “como excluir o histórico de arquivos da internet”
após o pré-processamento de texto com a eliminação das stopwords, sinais de pontuação,
caracteres especiais, etc., temos os seguintes termos indexadores: excluir, historico, arquivo
e internet.
As principais variáveis do algoritmo de RI definidos pelo modelo vetorial podem ser
verificadas pelas colunas da tabela mostrada na Figura 41 que são:
Freq. - Frequência de cada termo da consulta no conjunto de termos do documento analisado;
Max. Freq. - Máxima frequência de Freq.;
Freq. Norml. - Frequência normalizada de cada termo da consulta;
Freq. Inv. - Frequência Inversa de cada termo da consulta;
116
Peso - Peso de cada termo da consulta;
Sim. - Similaridade do documento em relação à consulta.
Figura 41 - Relatório para análise de casos similares
Fonte: Elaboração do autor, 2011.
O relatório para análise de casos similares mostrado na figura anterior, foi
implementado especialmente para validar os resultados do algoritmo de RI na fase de
desenvolvimento do sistema e também para apresenta-lo como instrumento da presente
avaliação.
O mesmo relatório pode ser verificado com os termos da consulta em destaque
através da tabela a seguir:
117
Tabela 3 - Relatório para análise de casos similares
Nº Documentos
Termos
Freq.
1
Como apagar o
histórico da internet
e os arquivos
temporários do
Internet Explorer?
1
1
1
2
2
Como remover uma
conta de e-mail?
apagar
historico
internet
arquivo
temporario
internet
explorer
remover
conta
email
3
Tenho acesso à rede
local mas não consigo
me conectar na
internet.
4
Como posso tornar o
Internet Explorer o
meu navegador
padrão?
5
Como salvar os
arquivos anexos de
uma mensagem no
Outlook?
tenho
acesso
rede
local
conectar
internet
posso
tornar
internet
explorer
navegador
padrao
salvar
arquivo
anexo
mensagem
outlook
Max.
Freq.
2
Freq.
Norml.
0,5
0,5
0,5
1
Freq.
Inv.
1,079
1,38
0,477
0,778
Peso
Sim.
0,54
0,69
0,24
0,78
0,954
1
0
0
0
0
0
0
1
1
1
0
0
0
0
0
0
1
1,079
1,38
0,477
0,778
1,079
1,38
0,477
0,778
1,09
0
0
0
0
0
0
0,78
0,546
0
0
0
1
1
0
0
0
1
1,079
1,38
0,477
0,778
0
0
0
0,78
0,394
0
0
1
0
1
0
0
1
0
1,079
1,38
0,477
0,778
0
0
0,47
0
0,242
1
0,394
Fonte: Elaboração do autor, 2011.
Analisando os valores obtidos de cada variável para o cálculo da similaridade dos
documentos, verifica-se que o maior número de frequências ocorre para o documento 1 onde
os termos da consulta: excluir, histórico e arquivo aparecem pelo menos uma vez e o termo
internet aparece duas vezes, o que torna o peso total e a similaridade do documento 1
superior em relação aos outros documentos.
Perceba que a utilização do termo excluir na consulta, não impede a localização do
documento 1, pois através do dicionário de sinônimos, o sistema pode encontrar o termo
correspondente “apagar” e assim prosseguir com o processamento sem afetar a similaridade.
118
Para o documento 2, apenas o termo excluir da consulta aparece uma vez sendo que
novamente o sistema encontra o termo correspondente “remover” através do dicionário de
sinônimos.
Para os documentos 3 e 4 apenas o termo internet da consulta aparece uma vez.
Por último, para documento 5, apenas o termo arquivo da consulta aparece uma vez.
Através do teste realizado, verifica-se que o algoritmo de RI, lista de stopwords e
o dicionário de sinônimos, trabalham em perfeita harmonia de modo que a lista de casos
similares recuperados e sua ordem de classificação são condizentes com os resultados de
cálculo apresentados no relatório de análise.
5.4.2 Avaliação Geral do Recurso de Autoatendimento
Sendo o autoatendimento o segundo propósito a que se destina a solução proposta,
faz-se necessário que esta parte do sistema que é constituída por um conjunto de recursos
específicos que a ampara, seja objeto de avaliação.
Como o tipo de abordagem adotado para a presente pesquisa é de natureza
qualitativa, o objetivo principal então é conhecer as percepções de um número limitado de
indivíduos pesquisados a respeito da proposta apresentada e que também a caráter de teste,
utilizaram o software avaliado.
5.4.2.1 Coleta de Dados
Para o registro da opinião dos entrevistados, é utilizado como instrumento um
questionário de perguntas fechadas que segundo Silva e Menezes (2005), “é uma série
ordenada de perguntas que devem ser respondidas por escrito pelo informante”.
As perguntas que compõem o questionário foram elaboradas de forma a traduzir
os reais objetivos da proposta facilitando assim a avaliação do trabalho.
119
O questionário é composto por seis perguntas. Embora as perguntas sejam
fechadas, é deixado um espaço para comentários em cada uma das perguntas de forma
opcional. Ao final do questionário também é disponibilizado um espaço onde o entrevistado
pode expor sua opinião de forma mais ampla através de comentários, sugestões ou críticas
sobre a proposta ou o protótipo apresentado.
O questionário foi aplicado a um grupo de dez entrevistados que utilizaram o
protótipo. O grupo foi predominantemente formado por voluntários com perfil de usuário
sendo que apenas dois voluntários exerciam atividades ligadas a TI como Analistas de
Suporte. As pessoas que participaram da pesquisa são funcionários da empresa avaliada como
já visto no início deste trabalho.
O quadro a seguir apresenta as perguntas utilizadas no questionário aplicado.
Nº Pergunta
Alternativas
1
Você considera importante que sistemas de
atendimento como help desk que são orientados por
especialistas, também possuam recursos de
autoatendimento orientados por máquina?
a)
b)
c)
d)
e)
Concordo fortemente
Concordo
Indiferente
Discordo
Não sei opinar
2
Você acredita que sistemas tutoriais de
autoatendimento reduzem a dependência dos
usuários com o setor de Help Desk?
a)
b)
c)
d)
e)
Concordo fortemente
Concordo
Indiferente
Discordo
Não sei opinar
3
Você acredita que sistemas tutoriais de
autoatendimento reduzem significativamente o
número de registros de incidentes (abertura de
chamados)?
a)
b)
c)
d)
e)
Concordo fortemente
Concordo
Indiferente
Discordo
Não sei opinar
4
Considerando um sistema de help desk com ótimos
recursos de autoatendimento que lhe forneça a
resposta necessária para o problema de forma clara
e didática, você prefere:
a) Utilizar o autoatendimento
b) Utilizar o autoatendimento
sempre que possível
c) Utilizar o autoatendimento
eventualmente
d) Abrir um chamado e esperar
o atendimento
120
5
Com relação ao protótipo apresentado, você
considera eficaz a usabilidade no que diz respeito à
forma com que você e o sistema interagem, ou seja,
a ferramenta torna fácil o processo de exposição do
problema e obtenção/compreensão da resposta?
a)
b)
c)
d)
e)
Concordo fortemente
Concordo
Indiferente
Discordo
Não sei opinar
6
Você considera que o protótipo apresentado atende
aos requisitos da proposta, ou seja, um sistema com
recursos de autoatendimento eficiente que irá
minimizar o número de chamados de help desk?
a)
b)
c)
d)
e)
Concordo fortemente
Concordo
Indiferente
Discordo
Não sei opinar
Quadro 7 - Perguntas do questionário da pesquisa
Fonte: Elaboração do autor, 2011.
A aplicação da pesquisa obedeceu a uma sequência de etapas definidas que são:
1) Apresentação geral do sistema, propósito e seus objetivos a cada entrevistado;
2) Treinamento operacional do sistema para o uso do autoatendimento;
3) Utilização do protótipo e testes por parte dos usuários;
4) Aplicação do questionário.
O questionário original que foi aplicado aos entrevistados na pesquisa pode ser
verificado no apêndice G.
5.4.2.2 Resultados da Pesquisa
A apresentação dos dados têm por objetivo demostrar os resultados obtidos da
pesquisa de forma organizada utilizando-se de recursos como, por exemplo, tabelas, quadros e
gráficos (SILVA; MENEZES, 2005).
Desta forma, a seguir são relacionadas as perguntas do questionário da pesquisa e
seus respectivos gráficos que quantificam os resultados obtidos. É apresentado também
comentários dos entrevistados.
121
Pergunta 1 - Você considera importante que sistemas de atendimento como help desk que são
orientados por especialistas, também possuam recursos de autoatendimento orientados por
máquina?
Não sei opinar
0
Discordo
0
Indiferente
10%
Concordo
60%
Concordo fortemente
30%
0
1
2
3
4
5
6
7
Gráfico 1 - Resultado da pesquisa para a pergunta 1 do questionário
Fonte: Elaboração do autor, 2011.
Segundo um dos entrevistados o qual é analista de suporte e que respondeu a
pergunta através da alternativa “Concordo fortemente”, seu comentário foi “É desnecessário
em algumas vezes o contato com o Help Desk, em muitos casos os problemas são simples e o
próprio usuário com instruções pode resolver.”.
Pergunta 2 - Você acredita que sistemas tutoriais de autoatendimento reduzem a dependência
dos usuários com o setor de Help Desk?
Não sei opinar
10%
Discordo
Indiferente
10%
Concordo
80%
Concordo fortemente
0
2
4
6
Gráfico 2 - Resultado da pesquisa para a pergunta 2 do questionário
Fonte: Elaboração do autor, 2011.
8
10
122
Conforme um dos entrevistados o qual é analista de suporte e que respondeu a
pergunta através da alternativa “Concordo”, seu comentário foi o seguinte: “Sim,
principalmente se o usuário tentar resolver e conseguir, então nas próximas vezes continuará
utilizando o auto atendimento e se tornando menos dependente.”.
Segundo outro entrevistado que é usuário final o qual respondeu a pergunta
através da alternativa “Concordo”, seu comentário foi o seguinte: “Se pudermos encontrar a
solução no autoatendimento, usaremos bem menos o Help Desk.”.
Pergunta 3 - Você acredita que sistemas tutoriais de autoatendimento reduzem
significativamente o número de registros de incidentes (abertura de chamados)?
Não sei opinar
10%
Discordo
10%
Indiferente
0%
Concordo
70%
Concordo fortemente
10%
0
1
2
3
4
5
6
7
8
Gráfico 3 - Resultado da pesquisa para a pergunta 3 do questionário
Fonte: Elaboração do autor, 2011.
De acordo com um entrevistado que é usuário final o qual respondeu a pergunta
através da alternativa “Concordo”, seu comentário foi o seguinte: “Mas somente em alguns
casos, existem pessoas que não tem interesse, nem tempo para resolver.”.
Pergunta 4 - Considerando um sistema de help desk com ótimos recursos de autoatendimento
que lhe forneça a resposta necessária para o problema de forma clara e didática, você prefere:
123
Abrir um chamado e esperar o atendimento
10%
Utilizar o autoatendimento eventualmente
0%
Utilizar o autoatendimento sempre que possível
40%
Utilizar o autoatendimento
50%
0
1
2
3
4
5
6
Gráfico 4 - Resultado da pesquisa para a pergunta 4 do questionário
Fonte: Elaboração do autor, 2011.
Conforme um entrevistado que é analista de suporte o qual respondeu a pergunta
através da alternativa “Utilizar o autoatendimento sempre que possível”, seu comentário foi o
seguinte: “Acredito que com o mínimo de conhecimento e seguindo o passo-a-passo, o
próprio usuário resolve grande parte dos problemas.”.
Outro entrevistado que é usuário o qual respondeu a pergunta através da
alternativa “Abrir um chamado e esperar o atendimento”, seu comentário foi o seguinte: “Se
forem problemas de computador, prefiro não tentar resolver pois tenho medo de piorar ainda
mais.”.
Pergunta 5 - Com relação ao protótipo apresentado, você considera eficaz a usabilidade no
que diz respeito à forma com que você e o sistema interagem, ou seja, a ferramenta torna fácil
o processo de exposição do problema e obtenção/compreensão da resposta?
Não sei opinar
0%
Discordo
10%
Indiferente
0%
Concordo
50%
Concordo fortemente
40%
0
1
2
3
4
Gráfico 5 - Resultado da pesquisa para a pergunta 5 do questionário
Fonte: Elaboração do autor, 2011.
5
6
124
Segundo um entrevistado que é analista de suporte o qual respondeu a pergunta
através da alternativa “Concordo fortemente”, seu comentário foi o seguinte: “Por possuir um
dicionário de sinônimos facilita, pois os usuários podem utilizar a sua própria linguagem.”.
Pergunta 6 - Você considera que o protótipo apresentado atende aos requisitos da proposta,
ou seja, um sistema com recursos de autoatendimento eficiente que irá minimizar o número
de chamados de help desk?
Não sei opinar
0
Discordo
0
Indiferente
0
Concordo
20%
Concordo fortemente
80%
0
2
4
6
8
10
Gráfico 6 - Resultado da pesquisa para a pergunta 6 do questionário
Fonte: Elaboração do autor, 2011.
De acordo com um entrevistado que é usuário final o qual respondeu a pergunta
através da alternativa “Concordo”, seu comentário foi o seguinte: “Com o tempo,
enriquecendo a base de FAQs e o incentivo da solução por parte do usuário, pode-se esperar
tal resultado.”.
Através do espaço disponibilizado no final do questionário onde os entrevistados
puderam expor suas opiniões, foi possível coletar alguns depoimentos positivos que revelaram
um bom nível de contentamento com a proposta e o protótipo.
Dos questionários coletados que continham depoimentos, as afirmações podem ser verificadas
a seguir:
O entrevistado #4 afirma: “[...] Acho que o autoatendimento reduziria o número de
chamados. Claro que algumas pessoas poderiam não ter interesse em resolver, outras por
tentar deixaria pior, mas numa visão geral, muito bom! Implementaria na minha empresa.”.
125
O entrevistado #1 afirma: “Achei muito bom. Poderia ser mais didático tendo imagens
ilustrativas. Mas acho que o autoatendimento trará agilidade e ganho de tempo para o
usuário, facilitando assim o trabalho no dia-a-dia.”.
O entrevistado #7 afirma: “O sistema é de fácil compreensão e atende vários tipos de dúvidas
de forma clara e objetiva.”.
De modo analítico, é possível chegar a algumas conclusões tomando como base
os resultados obtidos. Segundo Silva e Menezes (2005), a análise deve ser realizada para
atender aos objetivos da pesquisa com o objetivo de confirmar ou rejeitar os seus
pressupostos.
Através dos gráficos demonstrados anteriormente, é possível perceber em cada
alternativa o percentual entrevistados que as tomou como resposta.
Para as perguntas 1, 2, 3, 5 e 6 que contém as alternativas:





Concordo fortemente;
Concordo;
Indiferente;
Discordo;
Não sei opinar.
E para o grupo que participou da pesquisa, obteve-se uma média de 32% dos entrevistados
que tomou como resposta a alternativa “Concordo fortemente”. Para a alternativa
“Concordo”, obteve-se uma média de 56% dos entrevistados que a tomou como resposta. Para
as alternativas: “Indiferente”, “Discordo” e “Não sei opinar”, obteve-se uma média de 4% dos
entrevistados que as tomou como resposta.
O percentual da média de entrevistados por resposta pode ser verificado no gráfico a seguir:
126
4%
4%
4%
Concordo fortemente (32%)
32%
Concordo (56%)
Indiferente (4%)
Discordo (4%)
56%
Não sei opinar (4%)
Gráfico 7 - Análise dos resultados para as perguntas 1, 2, 3, 5 e 6 do questionário
Fonte: Elaboração do autor, 2011.
Com relação aos resultados apresentados, a pesquisa revela que 88% dos entrevistados
concordaram em 83,3% das questões, representadas pelas perguntas 1, 2, 3, 5 e 6.
Para a pergunta 4 que contém as seguintes alternativas:

Utilizar o autoatendimento;

Utilizar o autoatendimento sempre que possível;

Utilizar o autoatendimento eventualmente;

Abrir um chamado e esperar o atendimento.
O percentual de entrevistados por resposta pode ser verificado no gráfico a seguir:
Abrir um chamado e esperar o atendimento
10%
Utilizar o autoatendimento eventualmente
0%
Utilizar o autoatendimento sempre que possível
40%
Utilizar o autoatendimento
50%
0
1
Gráfico 8 - Análise dos resultados para a pergunta 4 do questionário
Fonte: Elaboração do autor, 2011.
2
3
4
5
6
127
Por fim, as perguntas da pesquisa refletem os reais objetivos da proposta sendo
que suas respostas representam escalas que em verdade servem para medir o quanto um
determinado objetivo foi atingido e de modo geral como foi verificado através dos resultados,
a pesquisa pode confirmar os pressupostos do projeto.
128
6
CONCLUSÕES E TRABALHOS FUTUROS
Neste trabalho foi apresentada a proposta de um sistema para gestão de help desk
que utiliza Raciocínio Baseado em Casos (RBC), uma tecnologia bastante difundida e que
vem sendo cada vez mais aplicada no desenvolvimento de Sistemas Baseados em
Conhecimento.
O Raciocínio Baseado em Casos é uma abordagem para solução de problemas
com base na experiência passada, ou seja, novos problemas são solucionados por meio de
casos anteriores já resolvidos.
Dentre os vários recursos computacionais que a área de Help Desk utiliza na
gestão de incidentes e atendimento aos usuários, os softwares de help desk tem se mostrado
ferramentas bastante completas.
Neste sentido, o sistema proposto buscou fornecer uma solução que integra as
funcionalidades de um software de help desk tradicional aos recursos que o RBC oferece.
Sobre os objetivos estabelecidos no início do projeto, se tem a ótica de que num
geral foram atingidos de forma bastante satisfatória, entretanto com algumas ressalvas.
Conhecidas as delimitações do projeto, o sistema proposto foi então modelado e
construído atendendo aos requisitos estabelecidos. Desta forma, o primeiro objetivo da
proposta como sendo o desenvolvimento de um sistema de help desk para gestão de
incidentes, foi então cumprido.
Durante a construção do protótipo surgiram em alguns momentos dificuldades
técnicas que tornaram o processo de desenvolvimento um pouco mais demorado. Como já
visto anteriormente, todo conjunto de tecnologias da plataforma .NET que foram utilizadas,
pode prover um ambiente de desenvolvimento bastante ágil, estável e agradável de se
trabalhar o que contribuiu em muito para o sucesso do projeto.
O segundo e mais importante objetivo da proposta foi a implementação do recurso
de autoatendimento, modelado sob os padrões do RBC.
Embora existam muitos sistemas de RBC cujo ciclo: Recuperação - Adaptação Revisão - Retenção não ocorra totalmente sem a participação humana, como é o caso do
sistema proposto, ainda assim são chamados de sistemas de RBC.
O principal intuito foi criar um sistema onde o usuário de forma autônoma
pudesse encontrar a solução para os seus problemas de forma rápida e fácil sem a intervenção
129
de terceiros. Verificou-se que o RBC Textual atenderia este propósito. Realmente a técnica de
RBC Textual torna a interação do usuário com o sistema bastante livre, pois nos sistemas de
RBC estruturais existem duas situações comuns que são: o usuário precisa seguir os
protocolos do sistema para se chegar a solução do problema, o que nem sempre é uma tarefa
que qualquer os usuário está disposto a enfrentar, ou de outra forma, repassar as informações
do problema a um especialista que tentará através do sistema de RBC encontrar a solução para
o usuário, o que acaba criando a situação de dependência indesejada.
Por outro lado, apesar dos sistemas de RBC Textuais proverem a praticidade em
vários aspectos e serem muito bons na etapa de recuperação que é uma das mais importantes,
a implementação de mecanismos de adaptação ou revisão automáticos é mais difícil o que os
torna incompletos. Uma das grandes vantagens que pode ser mencionada sobre um sistema de
RBC Textual é que ele terá o mesmo desempenho em termos de funcionamento sobre
qualquer base de conhecimento, independente do domínio e quanto mais alimentada e
completa for esta base, maior será o seu poder de resposta.
Com relação à avaliação do protótipo, o relatório de análise de casos similares que
foi utilizado traria resultados mais interessantes para fins de estudo e comparação se a base de
casos possuísse pelo menos 100 FAQs cadastradas. Embora a base utilizada tenha totalizado
apenas 24 FAQs, a eficiência do algoritmo de Recuperação de Informação pode ser
comprovada.
Sobre trabalhos futuros relacionados ao protótipo, o que se pode afirmar é que
nenhum sistema é completo, sempre haverá melhorias e desafios. Desta maneira além da
implementação dos recursos delimitados do trabalho, existem alguns recursos já vislumbrados
que poderão estar incluídos na próxima etapa do projeto que são:
- Disponibilização na página principal do Autoatendimento um painel com as
FAQs top 10 mais acessadas pelos usuários;
- Chat online para abrir um canal de conversa em tempo real entre usuário e
especialista;
- Implementação de um corretor ortográfico integrado ao motor de busca do
autoatendimento;
- Implementação de um mecanismo para encadeamento de FAQs de forma que
uma FAQ recuperada traz consigo outras FAQs relacionadas;
- Integração com outras bases de conhecimento através de web services;
- Tornar o ciclo do RBC no atual sistema mais completo.
130
REFERÊNCIAS
ARAÚJO, Anderson Viçoso de. Treinamento Avançado em .NET. Digerati, 2007.
BAEZA-YATES, Ricardo; RIBEIRO-NETO, Berthier. Modern Information Retrieval.
USA. Addison-Wesley Publishing Company, 1999.
BARONE, Dante. Sociedades Artificiais: A Nova Fronteira da Inteligência nas Máquinas.
Bookman, 2003.
CADENHEAD, Rogers; LEMAY, Laura. Aprenda em 21 dias Java 2. Elsevier, 2005.
CAMPOS, Leonardo Martins. Centrais de Help-Desk: Avaliação do serviço de atendimento
ao cliente de Empresas Desenvolvedoras de Sistemas de Gestão Empresarial. 2007.237f.
Dissertação (Pós-Graduação em Ciência da Informação) - Universidade Federal de Minas
Gerais, Belo Horizonte, 2007.
CHECLAND, P. B.. Systems Thinking, Systems Practice, Chichester. England: John
Wiley, 1981.
COCKBURN, Alistair. Escrevendo Casos de Uso Eficazes: Um guia pratico para
desenvolvedores de software. Bookman, 2001.
COHEN, Roberto. Implantação de Help Desk e Service Desk. Novatec, 2008.
COSTA, Carlos J. Desenvolvimento para Web. Press.itml.org, 2007.
CIRIBELLI, Marilda Corrêa. Como Elaborar uma Dissertação de Mestrado através da
pesquisa científica. Rio de Janeiro: 7 Letras, 2003.
FERNANDES, Anita Ma da Rocha. et al. Desenvolvimento de uma FAQ baseada em RBC
para suporte a usuários de sistemas web. Publicado em: mar. 2010. Disponível em: <
http://www.aedb.br/seget/artigos2010.php >. Acesso em: 15 mai.
FOROUZAN, Behrouz A.. Comunicação de Dados e Redes de Computadores. Bookman,
2008.
131
FOWLER, Martin. UML essencial: um breve guia para a linguagem-padrão de modelagem
de objetos. Porto Alegre: Bookman, 2005.
FURTADO, Vasco. Tecnologia e Gestão da Informação na Segurança Pública.
Garamond, 2002.
GARCIA, Eduardo Alfonso Cadavid. Manual de Sistematização de documentos técnicos.
São Paulo: Atlas, 1998.
GIARRATANO, Joseph; RILEY, Gary. Expert Systems: principles and programming.
Boston: PWS, 1998.
IIBA, International Institute of Business Analysis. O Guia para o Corpo de Conhecimento
de Análise de NegóciosTM (Guia BABOX ®). IIBA, 2011.
ITSMF. Fundamentos do Gerenciamento de Serviços em TI Baseado na ITIL ®. Van
Haren Publishing, 2006.
LAND, F.. Adapting to Changing User Requirements, Information & Management, 5(1),
1982. p. 91-107.
LEITE, Mário. Técnicas de Programação: Uma Abordagem Moderna. Brasport, 2006.
LEONEL, Vilson; MOTTA, Alexandre de Medeiros. Ciência e Pesquisa: Livro didático.
Palhoça: UNISUL, 2007.
MACHADO, Debora Santos. Proposta de um Novo Modelo de Gestão de Serviços para o
Help Desk da Empresa Sim Telecom. 2008. 163f. Monografia (Bacharelado em
Administração de Empresas) - Pontifícia Universidade Católica do Rio Grande do Sul, 2008.
MARTINS, José Carlos Cordeiro. Gerenciando projetos de desenvolvimento de software
com PMI, RUP e UML. Rio de Janeiro: Brasport, 2007.
MEDEIROS, Maysa Regina; BARRETO, Jorge Muniz. Metodologia para Desenvolvimento
de Programas em Inteligência Artificial: Sonho ou Tecnologia? Publicado em: jan. 2003.
Disponível em: < http://www.inf.ufsc.br>. Acesso em: 18 abr.
132
MELO, Ana Cristina. Desenvolvendo Aplicações com UML 2.2: Do Conceitual à
Implementação. Brasport, 2010.
MENDES, Raquel Dias. Inteligência Artificial: Sistemas Especialistas no Gerenciamento da
Informação. Publicado em: abr. 1997. Disponível em: < http://www.scielo.br >. Acesso em:
25 abr.
MICROSOFT. Microsoft® SQL Server 2005 Express Edition Service Pack 2. Publicado
em: fev. 2007. Disponível em: < http://www.microsoft.com/downloads/ >. Acesso em: 8 out.
MICROSOFT. Microsoft® SQL Server® 2008 Management Studio Express. Publicado
em: fev. 2009. Disponível em: < http://www.microsoft.com/downloads/ >. Acesso em: 8 out.
MICROSOFT. Microsoft® Visual Studio 2010. Publicado em: 2010. Disponível em: <
http://msdn.microsoft.com/pt-br/library/dd831853.aspx >. Acesso em: 18 out.
MORGADO, Gisele P. et al. Práticas do CMMI® como regras de negócio. Publicado em:
ago. 2007. Disponível em: < http://www.scielo.br >. Acesso em: 19 jun.
NILSON, Neils S.. Principles of Artificial Intelligence. Springer Verlag: Berlin, 1982.
OGC. ITIL: Service Operation. London: TSO, 2007.
RAMOS, Ricardo Argenton. Treinamento prático em UML. São Paulo: Digerati Books,
2006.
REZENDE, Solange Oliveira. Sistemas Inteligentes: Fundamentos e Aplicações. Manole,
2005.
RICH, Elaine. Artificial Intelligence, New York: Mc Graw Hill Book, 1983.
RUSSEL, Stuart; NORVIG, Peter. Inteligência Artificial. Campus, 2004.
SÁ, Fábio Pessôa. Avaliação da Recuperação no Raciocínio Baseado em Casos Estrutural
e Textual em um Sistema de Help-desk. 2007. 79f. Dissertação (Mestrado em Informática) Universidade Católica de Santos, Santos, 2007.
133
SCHUTZER, D.. Artificial intelligence: an applications-oriented approach. New York: Van
Nostrand Reinhold Company, 1987.
SILVA, Maurício Samy. jQuery a Biblioteca do Programador JavaScript. Novatec, 2008.
SPAKI, Eduardo. et al. Desenvolvimento para Web usando o Visual Studio 2008. Brasport,
2008.
STATDLOBER, Juliano. Help-Desk e SAC com Qualidade. Brasport, 2006.
TURBAN, Efraim; MCCLEAN, Ephraim; WETHERBE, James C.. Tecnologia da
Informação para Gestão: Transformando os Negócios na Economia Digital. Bookman,
2004.
TURBAN, Efraim; RAINER, R. Kelly; POTTER, Richard E.. Administração de Tecnologia
da Informação. Elsevier, 2005.
WANGENHEIN, Christiane Gresse von; WANGENHEIN, Aldo von. Raciocínio Baseado
em Casos. Manole, 2003.
WATERMAN, D.. A Guide to Expert Systems. Addison-Wesley, 1986.
134
APÊNDICE A - LISTA DE PERGUNTAS FREQUENTES
Nº FAQ
Categoria
1
Que informação útil posso tirar de um Sistema de Informação?
Software
2
Tenho o Acrobat Reader instalado mas não consigo abrir um arquivo PDF? PDF
3
Como alterar a resolução da tela e melhorar a imagem no Windows XP?
Monitor
4
Como gravar um CD ou DVD a partir de um arquivo ISO?
CD e DVD
5
Como faço para copiar arquivos e pastas para um CD ou DVD?
CD e DVD
6
Como instalar uma impressora da rede?
Impressão
7
Como salvar os arquivos anexos de uma mensagem no Outlook?
E-mail
8
Como definir uma senha para ajudar a proteger as informações no
E-mail
Outlook?
9
Como reduzir o tamanho de um arquivo (pst) de dados do Outlook?
E-mail
10 Como fazer um backup das mensagens do Outlook?
E-mail
11 Como mover um arquivo de dados (pst) do Outlook para outra pasta?
E-mail
12 Como configurar manualmente uma conta POP3 ou IMAP?
E-mail
13 Como remover uma conta de e-mail?
E-mail
14 Meu programa de e-mail dá erro dizendo que a senha está inválida.
E-mail
15 O que é IMAP?
E-mail
16 O que é POP3?
E-mail
17 Como criar e configurar uma conta de e-mail no Microsoft Outlook?
E-mail
18 Onde estão os meus favoritos? Como posso adicionar outros?
Internet
19 Como posso tornar o Internet Explorer o meu navegador padrão?
Internet
20 Como apagar o histórico da internet e os arquivos temporários do Internet
Internet
Explorer?
21 Tenho acesso à rede local mas não consigo me conectar na internet.
Internet
22 Meu aplicativo não está funcionando, como devo proceder?
Software
23 O que é o Help Desk?
Help Desk
24 Qual o tempo de resposta do Help Desk?
Help Desk
Quadro 8 - Lista de FAQs
Fonte: Elaboração do autor, 2011.
135
APÊNDICE B - REQUISITOS FUNCIONAIS
Nome
Descrição
RF01 - Identificação do usuário
corrente
Condições:
1 - O sistema deverá ser capaz de identificar o nome
do usuário corrente e validar seu acesso.
Para isso o usuário necessitará também, estar com seu
computador logado na rede local e no domínio da
respectiva empresa;
2 - A autenticação se fará apenas pelo nome de usuário
da rede que também deverá estar cadastrado no
sistema;
3 - Por questões de agilidade, não será necessário
senha de acesso.
RF02 - Criação de conta de acesso Condições:
1 - O sistema deverá disponibilizar o recurso pelo qual
o usuário seja capaz de realizar o cadastro da sua conta
de acesso;
2 - Neste momento, serão solicitados: nome completo,
e-mail, telefone e setor;
3 - O login será obtido automaticamente a partir do
computador do usuário que está logado no domínio da
rede local;
RF03 - Gerenciamento de
chamados
4 - O nome do domínio da rede também deverá ser
validado.
Condições:
1 - O sistema deverá prover o recurso pelo qual o
inventário de chamados de help desk possa ser
gerenciado;
2 - A tela do recurso deverá dispor uma grade que lista
os chamados e apresenta suas informações por colunas
que contém controles para ordenação dos itens da lista;
As colunas que a grade deverá conter são:
. Nº
136
. Editar (Botão)
. Anexos
. Título do Chamado (Hyperlink)
. Categoria
. Solicitante
. Prioridade
. Prazo
. Indicador gráfico de Status
. Status
. Data de Conclusão
3 - A grade de itens deverá possuir o recurso de
paginação exibindo por padrão 50 itens por página;
4 - A informação completa de cada item da lista deverá
ser acessada de duas formas:
a) Através do botão da coluna “Editar”;
b) Através do hyperlink da coluna “Título do
Chamado”.
RF04 Criação/Edição/Visualização de
chamados
5 - A informação completa de um item deverá ser tanto
visualizada como editada através de formulários
específicos.
Condições:
1 - O sistema deverá prover o recurso pelo qual os
usuários possam criar, editar ou visualizar chamados
através de formulários específicos;
2 - O formulário para criação de chamados deverá
conter os seguintes campos:
. Nº Chamado (Rótulo)
. Solicitante (Opção)
. Título da Solicitação (Texto)
. Categoria (Opção)
. Descrição/Acompanhamento (Texto)
. Prioridade (Opção)
. Prazo de Atendimento (Texto)
. Anexos (Hyperlink)
. Serviço Atendido (Opção)
3 - Os formulários para visualização e edição de
chamados deverão possuir os mesmos campos do
formulário de criação, porém com seguintes campos
137
adicionais:
RF05 - Histórico de interações do
chamado
RF06 - Anexos do chamado
RF07 - Motor de busca
. Status (Opção)
. Data de Conclusão (Texto)
. Responsável pelo Atendimento (Opção)
Condições:
1 - Cada chamado deverá armazenar a lista do
histórico de interações, identificadas por: nome do
usuário, data, hora e descrição da interação.
Condições:
1 - O sistema deverá prover o recurso que possibilitará
ao usuário anexar, abrir ou excluir arquivos em um
chamado.
Condições:
1 - O sistema deverá prover o recurso pelo qual as
FAQs possam ser pesquisadas através de um motor de
busca;
2 - O motor de busca deverá recuperar FAQs como
sendo os casos mais similares ao problema expresso
pelos termos da consulta do usuário;
3 - Os dados de entrada para execução da pesquisa
serão informados através da descrição textual do
problema;
4 - O painel de pesquisa deverá possuir caixa de texto
e botão “Perguntar” além de filtro por Categoria;
5 - O número de resultados retornados deverá ser de no
máximo 5 (cinco), sendo estes ordenados por
similaridade aos termos da consulta (mais similares no
topo da lista);
RF08 - Envio de dúvidas
6 - A resposta/solução como sendo o conteúdo de cada
caso similar recuperado deverá ser visualizada em uma
tela a parte.
Condições:
1 - A mesma tela do motor de busca (RF07) deverá
dispor um botão chamado “Postar Dúvidas” que será
utilizado pelos usuários quando estes não obtiverem
êxito em suas pesquisas. Através deste recurso, uma
dúvida de usuário poderá por meio de um formulário
138
específico ser enviada para uma lista de questões
pendentes que deverão ser avaliadas por um
especialista;
2 - O formulário para envio de dúvidas deverá possuir
os seguintes campos:
RF09 - FAQ
. Questão (Texto)
. Descrição/Observação (Texto)
Condições:
1 - O sistema deverá prover o recurso pelo qual a lista
de perguntas frequentes possa ser disponibilizada a
todos os usuários;
2 - A tela do recurso deverá dispor uma grade que lista
as FAQs e apresenta suas informações por colunas que
contém controles para ordenação dos itens da lista;
As colunas que a grade deverá conter são:
. Questão (Hyperlink)
. Categoria
3 - A grade de itens deverá possuir o recurso de
paginação exibindo por padrão 50 itens por página;
4 - A informação completa de cada item da lista deverá
ser acessada de através do hyperlink da coluna
“Questão”;
5 - A informação completa de um item poderá ser
visualizada através de um formulário específico que
deverá conter os seguintes campos:
. Nº FAQ
. Questão
. Categoria
. Resposta
6 - A lista deverá dispor uma ferramenta de pesquisa
de FAQs contendo caixa de texto e botão “Buscar”
além de filtro por Categoria;
7 - Os resultados da pesquisa deverão ser exibidos na
mesma tela, ou seja, utilizará a mesma grade de itens.
139
RF10 - Pesquisa avançada de
chamados
Condições:
1 - O sistema deverá prover o recurso pelo qual os
usuários possam realizar pesquisas por chamados;
2 - A tela do recurso deverá dispor um painel de
pesquisa com parâmetros de busca configuráveis
contendo caixa de texto e botão “Buscar” além de
filtros por: Categoria (Opção), Prioridade (Opção) e
período de criação dos chamados com dois campos do
tipo data (Texto) início e término;
3 - Os itens recuperados da pesquisa deverão ser
exibidos em uma grade com colunas contendo
controles que permitem a ordenação;
As colunas que a grade deverá conter são:
. Nº
. Título do Chamado (Hyperlink)
. Categoria
. Solicitante
. Prioridade
. Prazo
. Status
. Conclusão
RF11 - Gerenciamento de
usuários
4 - A informação completa de cada item recuperado
deverá ser visualizada através do formulário de
visualização de chamados.
Condições:
1 - O sistema deverá prover o recurso pelo qual as
contas de usuários possam ser gerenciadas;
2 - A tela do recurso deverá dispor uma grade que lista
os usuários do sistema e apresenta suas informações
por colunas que contém controles para ordenação dos
itens da lista;
As colunas que a grade deverá conter são:
. ID
. Editar (Botão)
. Nome Completo
. Nome de Usuário
. e-mail
. Telefone
140
. Departamento
. Suporte (Indicador gráfico)
. Analista (Indicador gráfico)
. Admin (Indicador gráfico)
3 - A grade de itens deverá possuir o recurso de
paginação exibindo por padrão 50 itens por página;
4 - A informação completa de cada item da lista deverá
ser acessada através do botão da coluna “Editar”;
RF12 - Perfis de usuário
5 - A informação completa de um item deverá ser
editada através de formulário específico.
O sistema deverá possuir um modelo de segurança
capaz de realizar o controle de acesso dos usuários aos
seus recursos.
Condições:
1 - O sistema deverá conter em seu modelo de
segurança, perfis de usuário pré-definidos que
estabelecem quais recursos da aplicação estão
disponíveis para determinado usuário;
2 - Uma conta de usuário deverá ser configurável de
forma que se possa habilitar ou desabilitar um perfil
específico.
Os perfis são:
RF13 - Criação/Edição de contas
de usuário
. Solicitante
. Suporte
. Administrador
. Analista RBC
Condições:
1 - O sistema deverá prover o recurso pelo qual os
usuários administradores possam criar ou editar contas
de usuário através de formulários específicos;
2 - Os formulários para criação e edição de contas de
usuário deverão conter os seguintes campos:
. ID (Rótulo)
. Nome Completo (Texto)
. Nome de Usuário (Texto)
. E-mail (Texto)
. Telefone (Texto)
141
RF14 - Gerenciamento de FAQs
. Departamento (Opção)
. Suporte (Opção: Sim/Não)
. Analista RBC (Opção: Sim/Não)
. Administrador (Opção: Sim/Não)
Condições:
1 - O sistema deverá prover o recurso pelo qual as
FAQs possam ser gerenciadas;
2 - A tela do recurso deverá dispor uma grade que lista
as FAQs do sistema e apresenta suas informações por
colunas que contém controles para ordenação dos itens
da lista;
As colunas que a grade deverá conter são:
. ID
. Editar (Botão)
. Questão
. Categoria
3 - A grade de itens deverá possuir o recurso de
paginação exibindo por padrão 50 itens por página;
4 - A informação completa de cada item da lista deverá
ser acessada através do botão da coluna “Editar”;
RF15 - Criação/Edição de FAQs
5 - A informação completa de um item deverá ser
editada através de formulário específico.
Condições:
1 - O sistema deverá prover o recurso pelo qual os
usuários administradores ou analistas possam criar ou
editar FAQs através de formulários específicos;
2 - Os formulários para criação e edição de FAQs
deverão conter os seguintes campos:
RF16 - Gerenciamento de
Questões
. Nº FAQ (Rótulo)
. Questão (Texto)
. Categoria (Opção)
. Resposta (Texto)
Condições:
1 - O sistema deverá prover o recurso pelo qual as
questões como sendo dúvidas postadas por usuários,
possam ser gerenciadas;
142
2 - A tela do recurso deverá dispor uma grade que lista
as questões e apresenta suas informações por colunas
que contém controles para ordenação dos itens da lista;
As colunas que a grade deverá conter são:
. ID
. Editar (Botão)
. Questão
. Status
3 - A grade de itens deverá possuir o recurso de
paginação exibindo por padrão 50 itens por página;
4 - A informação completa de cada item da lista deverá
ser acessada através do botão da coluna “Editar”;
RF17 - Edição de questões
5 - A informação completa de um item deverá ser
editada através de formulário específico.
Condições:
1 - O sistema deverá prover o recurso pelo qual os
usuários administradores ou analistas possam editar
questões através de um formulário específico;
2 - O formulário para edição de questões deverá conter
os seguintes campos:
. Nº Questão (Rótulo)
. Questão (Texto)
. Descrição/Observações (Texto)
. Status (Opção)
RF18 - Gerenciamento do
dicionário de sinônimos
3 - Além dos botões salvar, cancelar e excluir o
formulário deverá dispor o botão “Salvar Como FAQ”,
recurso pelo qual uma questão poderá ser salva como
FAQ diretamente na lista de FAQs.
Condições:
1 - O sistema deverá prover o recurso pelo qual o
dicionário de sinônimos possa ser gerenciado;
2 - A tela do recurso deverá dispor duas grades: a
primeira lista as palavras e a segunda lista os
sinônimos. Ambas as grades apresentam suas
143
informações por colunas que contém controles para
ordenação dos itens da lista;
As colunas que a grade de palavras deverá conter são:
. Palavra
. Editar (Botão)
As colunas que a grade de sinônimos deverá conter
são:
. Sinônimo
. Editar (Botão)
3 - A grade de itens deverá possuir o recurso de
paginação exibindo por padrão 50 itens por página;
4 - Cada lista de itens deverá dispor em seu cabeçalho
um botão chamado “Novo”, recurso pelo qual novas
palavras ou sinônimos poderão ser adicionadas;
RF19 - Gerenciamento da lista de
termos ignorados
5 - Cada item da lista poderá ser editado ou excluído
através do botão da coluna “Editar”.
Condições:
1 - O sistema deverá prover o recurso pelo qual a lista
de termos ignorados possa ser gerenciada;
2 - A tela do recurso deverá dispor uma grade que lista
os termos e apresenta suas informações por colunas
que contém controles para ordenação dos itens da lista;
As colunas que a grade deverá conter são:
. Termo
. Editar (Botão)
3 - A grade de itens deverá possuir o recurso de
paginação exibindo por padrão 100 itens por página;
4 - Cada lista de itens deverá dispor em seu cabeçalho
um botão chamado “Novo”, recurso pelo qual novos
termos poderão ser adicionados;
RF20 - Gerenciamento dos
5 - Cada item da lista poderá ser editado ou excluído
através do botão da coluna “Editar”.
Condições:
144
campos globais
1 - O sistema deverá prover o recurso pelo qual os
campos globais da aplicação como sendo os campos de
opção utilizados na maioria dos formulários de criação
e edição, possam sofrer manutenções quando
necessário;
2 - A tela do recurso deverá dispor a lista de opções de
cada campo global através de grades que apresentam
suas informações por colunas contendo controles para
ordenação dos itens da lista;
As colunas que a grade deverá conter são:
. Opção
. Editar (Botão)
3 - Cada lista de itens deverá dispor em seu rodapé um
botão chamado “Novo”, recurso pelo qual novos
termos poderão ser adicionados;
4 - Cada item da lista poderá ser editado ou excluído
através do botão da coluna “Editar”.
Quadro 9 - Requisitos Funcionais – Descrição
Fonte: Elaboração do autor, 2011.
145
APÊNDICE C - REQUISITOS NÃO FUNCIONAIS
Nome
Descrição
RNF01 - Interface do sistema
Condições:
- A interface geral do sistema deverá conter em seu
layout, áreas tais como: cabeçalho, menu lateral de
acesso rápido e rodapé, que estarão sempre visíveis
independente das diversas páginas de conteúdo que
possam ser acessadas.
Condições:
- O tema da interface deverá apresentar uma tonalidade
de cores claras e fundo branco.
Condições:
- A arquitetura do sistema deverá garantir bom
desempenho com até 50 usuários conectados.
RNF02 - Aparência da interface
RNF03 - Desempenho do sistema
Quadro 10 - Requisitos Não Funcionais – Descrição
Fonte: Elaboração do autor, 2011.
146
APÊNDICE D - REGRAS DE NEGÓCIO
Nome
Descrição
RN01 - Acesso ao sistema
Condições:
1 - O acesso ao sistema somente será possível a
usuários (que são funcionários da organização) da rede
local que possuam conta de acesso com login
cadastrado.
Condições:
1 - Conforme o perfil de acesso do usuário corrente
seja ele: Administrador, Analista RBC, Suporte ou
Solicitante, determinados recursos do sistema deverão
ser habilitados ou desabilitados.
Condições:
1 - A tela inicial do sistema será a de autoatendimento;
RN02 - Controle de acesso
RN03 - Forma de atendimento
RN04 - Pesquisa avançada de
chamados
RN05 - Gerenciamento de
chamados
2 - Caso a busca da solução através da base de
conhecimento não tenha obtido êxito, o usuário
poderá:
a) Abrir um chamado de forma convencional;
b) Postar sua dúvida através do recurso “Postar
Dúvida”.
Condições:
1 - Usuários com perfil de Suporte, Analista RBC ou
Administrador terão permissão para pesquisar todos os
chamados do sistema de forma irrestrita;
2 - Usuários com perfil de Solicitante terão permissão
para pesquisar somente os chamados do sistema que
possuam seu nome de usuário informado no campo
Solicitante do formulário de chamados.
Condições:
1 - Usuários com perfil de Suporte ou Administrador
terão permissão para:
a) Visualizar todos os chamados na lista central de
chamados;
b) Utilizar os seguintes campos do formulário de
chamados:
. Status
. Data de Conclusão
. Responsável pelo Atendimento
147
c) Criar, Ler, Editar e Excluir chamados.
RN06 - Gerenciamento de contas
de usuários
RN07 - Gerenciamento da base de
conhecimento
RN08 - Gerenciamento das
configurações
Quadro 11 - Regras de Negócio – Descrição
Fonte: Elaboração do autor, 2011.
2 - Usuários com perfil de Solicitante terão permissão
para:
a) Visualizar somente os chamados na lista central de
chamados que possuam seu nome de usuário
informado no campo Solicitante do formulário de
chamados;
b) Utilizar todos os campos do formulário de
chamados exceto:
. Status
. Data de Conclusão
. Responsável pelo Atendimento
c) Criar, Ler e Editar chamados.
Condições:
1 - Usuários com perfil de Suporte ou Administrador
terão permissão para:
a) Visualizar todas as contas de usuário na lista central
de usuários;
b) Criar, Ler, Editar e Excluir contas de usuário.
Condições:
1 - Usuários com perfil de Analista RBC ou
Administrador terão permissão para:
a) Visualizar todas as FAQs na lista central de FAQ;
b) Criar, Ler, Editar e Excluir FAQs;
c) Visualizar todas as questões na lista central de
questões;
d) Ler, Editar e Excluir questões;
e) Criar, Ler, Editar e Excluir palavras ou sinônimos
da lista central do dicionário de sinônimos;
f) Criar, Ler, Editar e Excluir palavras da lista central
de termos ignorados.
Condições:
1 - Usuários com perfil de Administrador terão
permissão para intervir nas configurações do sistema.
148
APÊNDICE E - CASOS DE USO
Nome
Descrição
Atores
principais
CU01 - Criar conta de
acesso
CU02 - Criar chamado
Ocorre quando um usuário não cadastrado acessa
o sistema pela primeira vez.
Ocorre quando o usuário necessita criar um novo
chamado no sistema.
CU03 - Visualizar
Ocorre quando o usuário necessita visualizar as
chamado
informações de um chamado da lista central de
chamados.
CU04 - Editar chamado Ocorre quando o usuário necessita editar as
informações de um chamado.
CU05 - Excluir
Ocorre quando o usuário necessita excluir um
chamado
chamado da lista central de chamados.
CU06 - Inserir anexo
Ocorre quando o usuário necessita anexar
arquivos em um novo chamado ou em um
chamado existente.
CU07 - Excluir anexo
Ocorre quando o usuário necessita excluir
arquivos anexos de um chamado existente.
CU08 - Pesquisar
Ocorre quando o usuário necessita realizar uma
chamados
pesquisa por chamados.
CU09 - Pesquisar FAQs Ocorre quando o usuário necessita realizar uma
pesquisa por FAQs.
CU10 - Visualizar FAQ Ocorre quando o usuário necessita visualizar as
informações de uma FAQ da lista central de
FAQs ou proveniente de pesquisa (CU10).
CU11 - Pesquisar casos Ocorre quando o usuário necessita realizar uma
similares
pesquisa que utiliza RBC, de modo a recuperar
os casos mais similares que atendam o seu
critério de busca.
CU12 - Visualizar caso Ocorre quando o usuário necessita visualizar as
similar
informações de um caso similar proveniente de
pesquisa (CU12).
CU13 - Postar dúvida
Ocorre quando o usuário necessita enviar sua
dúvida para o Help Desk.
CU14 - Editar questão
Ocorre quando o usuário necessita editar as
informações de uma questão.
CU15 - Salvar questão
Ocorre quando o usuário necessita salvar uma
como FAQ
questão da lista central de questões como uma
Solicitante
Solicitante;
Suporte
Solicitante;
Suporte
Solicitante;
Suporte
Suporte
Solicitante;
Suporte
Solicitante
Solicitante;
Suporte
Solicitante
Solicitante
Solicitante
Solicitante
Solicitante
Analista RBC
Analista RBC
149
CU16 - Excluir questão
CU17 - Criar caso
CU18 - Editar caso
CU19 - Excluir caso
CU20 - Inserir palavra
CU21 - Editar palavra
CU22 - Excluir palavra
CU23 - Inserir
sinônimo
CU24 - Editar sinônimo
CU25 - Excluir
sinônimo
CU26 - Inserir termo
ignorado
CU27 - Editar termo
ignorado
CU28 - Excluir termo
ignorado
CU29 - Criar conta de
usuário
CU30 - Editar conta de
usuário
CU31 - Excluir conta
de usuário
CU32 - Inserir opção
em campo global
CU33 - Editar opção
em campo global
CU34 - Excluir opção
em campo global
nova FAQ.
Ocorre quando o usuário necessita excluir uma
questão da lista central de questões.
Ocorre quando o usuário necessita cadastrar uma
nova FAQ na base de conhecimento do sistema.
Ocorre quando o usuário necessita editar as
informações de uma FAQ da base de
conhecimento.
Ocorre quando o usuário necessita excluir uma
FAQ da base de conhecimento.
Ocorre quando o usuário necessita incluir uma
nova palavra no dicionário de sinônimos.
Ocorre quando o usuário necessita editar uma
palavra do dicionário de sinônimos.
Ocorre quando o usuário necessita excluir uma
palavra do dicionário de sinônimos.
Ocorre quando o usuário necessita incluir um
novo sinônimo no dicionário de sinônimos.
Ocorre quando o usuário necessita editar um
sinônimo do dicionário de sinônimos.
Ocorre quando o usuário necessita excluir um
sinônimo do dicionário de sinônimos.
Ocorre quando o usuário necessita incluir um
novo termo na lista de termos ignorados.
Ocorre quando o usuário necessita editar um
termo da lista de termos ignorados.
Ocorre quando o usuário necessita excluir um
termo da lista de termos ignorados.
Ocorre quando o usuário necessita cadastrar uma
nova conta de usuário.
Ocorre quando o usuário necessita editar as
informações de uma conta de usuário.
Ocorre quando o usuário necessita excluir uma
conta de usuário da lista central de usuários.
Ocorre quando o usuário necessita incluir uma
nova opção em um campo global.
Ocorre quando o usuário necessita editar uma
opção específica de um campo global.
Ocorre quando o usuário necessita excluir uma
opção específica de um campo global.
Quadro 12 - Casos de Uso – Descrição
Fonte: Elaboração do autor, 2011.
Analista RBC
Analista RBC
Analista RBC
Analista RBC
Analista RBC
Analista RBC
Analista RBC
Analista RBC
Analista RBC
Analista RBC
Analista RBC
Analista RBC
Analista RBC
Suporte;
Administrador
Suporte;
Administrador
Suporte;
Administrador
Administrador
Administrador
Administrador
150
APÊNDICE F - CLASSES DO MOTOR DE BUSCA
InformationRetrieval
using
using
using
using
using
System;
System.Collections;
System.Collections.Generic;
System.Web;
HelpDesk.DAL;
namespace HelpDesk.IR
{
public class InformationRetrieval : Document
{
private string QueryText;
private List<Document> Documents;
private ArrayList StopWords;
private ArrayList FAQs;
private double SimTotal;
public InformationRetrieval()
{
Documents = new List<Document>();
}
// GetSimilarDocuments
public List<Document> GetSimilarDocuments(string query, string category)
{
QueryText = query;
DBAccess dba = new DBAccess();
StopWords = dba.GetStopWords();
FAQs = dba.GetDocuments(category);
SimTotal = 0;
SetDocuments();
if (SimTotal > 0)
{
Documents.Sort(delegate(Document doc1, Document doc2)
{
return doc1.Sim.CompareTo(doc2.Sim);
});
Documents.Reverse();
return Documents;
}
else
return null;
}
// SetDocuments
void SetDocuments()
{
// Consulta
Document Query = new Document();
Query.Text = QueryText;
Query.SetTerms(Query.Text, StopWords);
List<Document> ListQuery = new List<Document>();
151
ListQuery.Add(Query);
// Documentos
foreach (string[] att in FAQs)
{
Document doc = new Document();
doc.ID = att[0];// ID
doc.Text = att[1];// Questão
doc.SetTerms(att[1], StopWords);
Documents.Add(doc);
}
CalculateSimilarity(Query, ListQuery);
CalculateSimilarity(Query, Documents);
}
// CalculateSimilarity
void CalculateSimilarity(Document query, List<Document> docs)
{
foreach (Document doc in docs)
{
int max = 0, freq, n;
// TF
foreach (string queryTerm in query.Terms)
{
freq = 0;
// Termos da consulta
foreach (string term in doc.Terms)
if (queryTerm.ToLower() == term.ToLower())
freq++;
if (freq == 0)
{
// Palavras associadas ao termo da consulta
DBAccess dba = new DBAccess();
ArrayList words = dba.GetWordsBySynonym(queryTerm.ToLower());
foreach (string word in words)
{
foreach (string term in doc.Terms)
if (word.ToString().ToLower() == term.ToLower())
freq++;
// Sai do laço
if (freq > 0)
goto Continue;
}
}
Continue:
doc.TF.Add(freq);
}
// max
foreach (int tf in doc.TF)
if (tf > max)
max = tf;
doc.Max = max;
152
// RF, n, IDF, W
for (int i = 0; i < query.Terms.Count; i++)
{
if (doc.Max > 0)// RF
doc.RF.Add(doc.TF[i] / Convert.ToDouble(doc.Max));
else
doc.RF.Add(0);
n = GetTermFrequencyInAllDocuments(query.Terms[i]);// n
if (n > 0 && FAQs.Count > n)// IDF
doc.IDF.Add(Math.Log10(FAQs.Count / n));
else
doc.IDF.Add(1);
doc.W.Add(doc.RF[i] * doc.IDF[i]);// W
}
// Sim
double s1 = 0, s2 = 0, s3 = 0;// Somadores
for (int j = 0; j < doc.W.Count; j++)
{
s1 += doc.W[j] * query.W[j];
s2 += Math.Pow(doc.W[j], 2);
s3 += Math.Pow(query.W[j], 2);
}
if (s1 > 0)
doc.Sim = s1 / (Math.Sqrt(s2) * Math.Sqrt(s3));
SimTotal += doc.Sim;
}
}
// GetTermFrequencyInAllDocuments
public int GetTermFrequencyInAllDocuments(string queryTerm)
{
int n = 0, freq = 0;
foreach (Document doc in Documents)
{
// Termos da consulta
foreach (string term in doc.Terms)
if (queryTerm.ToLower() == term.ToLower())
freq++;
if (freq == 0)
{
// Palavras associadas ao termo da consulta
DBAccess dba = new DBAccess();
ArrayList words = dba.GetWordsBySynonym(queryTerm.ToLower());
foreach (string word in words)
{
foreach (string term in doc.Terms)
if (word.ToLower() == term.ToLower())
freq++;
// Sai do laço
if (freq > 0)
goto Continue;
153
}
}
Continue:
n += freq;
freq = 0;
}
return n;
}
}
}
Document
using
using
using
using
using
using
using
System;
System.Globalization;
System.Collections;
System.Collections.Generic;
System.Web;
HelpDesk.DAL;
System.Text;
namespace HelpDesk.IR
{
public class Document
{
private string id;
private string text;
private List<string> terms;
private List<int> tf;// Term Frequency in Document
private int max;// Max Term Frequency in Document
private List<double> rf;// Relative Frequency
private List<double> idf;// Inverse Document Frequency
private List<double> w;// Weight
private double sim;// Similarity
public Document()
{
id = "";
text = "";
terms = new List<string>();
sim = 0;
tf = new List<int>();
rf = new List<double>();
idf = new List<double>();
w = new List<double>();
}
public string ID
{
get { return id; }
set { id = value; }
}
public string Text
{
get { return text; }
154
set { text = value; }
}
public List<string> Terms
{
get { return terms; }
set { terms = value; }
}
public List<int> TF
{
get { return tf; }
set { tf = value; }
}
public int Max
{
get { return max; }
set { max = value; }
}
public List<double> RF
{
get { return rf; }
set { rf = value; }
}
public List<double> IDF
{
get { return idf; }
set { idf = value; }
}
public List<double> W
{
get { return w; }
set { w = value; }
}
public double Sim
{
get { return sim; }
set { sim = value; }
}
// SetTerms
public void SetTerms(string text, ArrayList stopWords)
{
ArrayList words = RemoveStopWords(text, stopWords);
foreach (string word in words)
{
Terms.Add(word.ToLower().TrimEnd('s'));// Torna a palavra singular
}
}
// RemoveStopWords
public ArrayList RemoveStopWords(string doc, ArrayList stopWords)
{
doc = RemoveSymbols(doc);
string[] words = doc.Split(' ');
ArrayList terms = new ArrayList();
155
bool stop;
for (int i = 0; i < words.Length; i++)
{
stop = false;
foreach (string stopWord in stopWords)
if (words[i].ToLower() == stopWord.ToLower())
stop = true;
if (!stop)
terms.Add(words[i]);
}
return terms;
}
public string RemoveSymbols(string inputString)
{
// Remove acentuação
if ((inputString == "") || (inputString == null))
return "";
string normalizedString = inputString.Normalize(NormalizationForm.FormD);
StringBuilder sb = new StringBuilder();
for (int i = 0; i < normalizedString.Length; i++)
{
UnicodeCategory uc =
CharUnicodeInfo.GetUnicodeCategory(normalizedString[i]);
if (uc != UnicodeCategory.NonSpacingMark)
sb.Append(normalizedString[i]);
}
// Remove caracteres especiais
string outString = sb.ToString().Normalize(NormalizationForm.FormC);
char[] stopSymbols = "~!@#$%^&*()_+={}|[]\\:\";'<>?,./?°º₢ª§¬¢£³²¹".ToCharArray();
foreach (char c in stopSymbols)
if (outString.Contains(c.ToString()))
outString = outString.Replace(c.ToString(), "");
return outString;
}
}
}
156
APÊNDICE G - QUESTIONÁRIO DA PESQUISA
1 - Você considera importante que sistemas de atendimento como help desk que são
orientados por especialistas, também possuam recursos de autoatendimento orientados por
máquina?
a)
b)
c)
d)
e)
Concordo fortemente
Concordo
Indiferente
Discordo
Não sei opinar
Comentário (opcional):
2 - Você acredita que sistemas tutoriais de autoatendimento reduzem a dependência dos
usuários com o setor de Help Desk?
a)
b)
c)
d)
e)
Concordo fortemente
Concordo
Indiferente
Discordo
Não sei opinar
Comentário (opcional):
3 - Você acredita que sistemas tutoriais de autoatendimento reduzem significativamente o
número de registros de incidentes (abertura de chamados)?
a)
b)
c)
d)
e)
Concordo fortemente
Concordo
Indiferente
Discordo
Não sei opinar
Comentário (opcional):
4 - Considerando um sistema de help desk com ótimos recursos de autoatendimento que lhe
forneça a resposta necessária para o problema de forma clara e didática, você prefere:
a) Utilizar o autoatendimento
157
b) Utilizar o autoatendimento sempre que possível
c) Utilizar o autoatendimento eventualmente
d) Abrir um chamado e esperar o atendimento
Comentário (opcional):
5 - Com relação ao protótipo apresentado, você considera eficaz a usabilidade no que diz
respeito à forma com que você e o sistema interagem, ou seja, a ferramenta torna fácil o
processo de exposição do problema e obtenção/compreensão da resposta?
a)
b)
c)
d)
e)
Concordo fortemente
Concordo
Indiferente
Discordo
Não sei opinar
Comentário (opcional):
6 - Você considera que o protótipo apresentado atende aos requisitos da proposta, ou seja,
um sistema com recursos de autoatendimento eficiente que irá minimizar o número de
chamados de help desk?
a)
b)
c)
d)
e)
Concordo fortemente
Concordo
Indiferente
Discordo
Não sei opinar
Comentário (opcional):
Dê sua opinião através de comentários, sugestões ou críticas sobre a proposta ou o protótipo
apresentado.
Muito Obrigado!
158