UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
SISTEMA PARA HELP DESK UTILIZANDO RACIOCÍNIO
BASEADO EM CASOS E TEXT MINING
ANDRÉ CAMPESTRINI
BLUMENAU 2015
ANDRÉ CAMPESTRINI
SISTEMA PARA HELP DESK UTILIZANDO RACIOCÍNIO
BASEADO EM CASOS E TEXT MINING
Trabalho de Conclusão de Curso apresentado ao curso de graduação em Sistemas de Informação do Centro de Ciências Exatas e Naturais da Universidade Regional de Blumenau como requisito parcial para a obtenção do grau de Bacharel em Sistemas de Informação.
Prof. Marcel Hugo, Mestre - Orientador
BLUMENAU 2015
SISTEMA PARA HELP DESK UTILIZANDO RACIOCÍNIO
BASEADO EM CASOS E TEXT MINING
Por
ANDRÉ CAMPESTRINI
Trabalho de Conclusão de Curso aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Marcel Hugo, Mestre – Orientador, FURB
______________________________________________________ Membro: Prof. Aurélio Faustino Hoppe, Mestre – FURB
______________________________________________________ Membro: Prof. Cláudio Ratke, Mestre – FURB
RESUMO
Neste trabalho foi desenvolvido um sistema de informação para abertura, acompanhamento e controle de chamados técnicos para a área de help desk da empresa Guia Fácil. Com o uso das técnicas de raciocínio baseado em casos e classificação de documentos, a ferramenta desenvolvida permite que os usuários pesquisem por casos similares, tornando mais rápida a busca por solução de chamados técnicos. A linguagem de programação utilizada foi PHP, juntamente com o banco de dados MySQL. A ferramenta executa em ambiente web e possui
layout responsivo. Após a implantação do aplicativo, foi possível armazenar soluções
conhecidas, avaliar a satisfação dos usuários do help desk e possibilitar o acompanhamento e registro dos chamados técnicos, elevando a agilidade e qualidade do atendimento.
Palavras-chave: Help desk. Raciocínio baseado em casos. Classificação de documentos. Mineração de texto.
ABSTRACT
The objective of this paper was to develop an application to open, track and manage tickets from the help desk at Guia Fácil. Using techniques such as case based reasoning and document classification, users are able to search for similar cases and find possible solutions for any given case faster. The programming language the application is written in is PHP, and the database system used is MySQL. It runs in a web environment. After implementing the application, it is possible to store known solutions for the cases, evaluate user’s satisfaction about the service and track all tickets, thus increasing the service’s overall quality and versatility.
LISTA DE FIGURAS
Figura 1 – Processo de Atendimento do Help Desk ... 18
Figura 2 – Ciclo do Raciocínio Baseado em Casos ... 20
Figura 3 - Fórmula do Nearest Neighbour ... 24
Figura 4 - Fórmula de Naïve Bayes ... 26
Figura 5 - Aplicação prática da fórmula de Bayes ... 26
Figura 6 - Tela de Cadastro de Ocorrências ... 30
Figura 7 - Tela de Consulta de Similaridades... 31
Figura 8 - Tela de Pesquisa de Soluções ... 32
Figura 9 - Tela de resultados da busca por text mining ... 33
Figura 10 - Diagrama de atividades para abertura, pesquisa de casos similares e fechamento dos chamados ... 37
Figura 11 – Diagrama de Casos de Uso do Usuário Final ... 39
Figura 12 – Diagrama de Casos de Uso do Técnico e Coordenador ... 39
Figura 13 – Modelo Entidade Relacionamento ... 40
Figura 14 - Tela de Login ... 46
Figura 15 - Tela de chamados na visão do usuário final ... 47
Figura 16 - Tela de chamados acessada por smartphone ... 47
Figura 17 - Detalhes do chamado técnico na visão do usuário final ... 48
Figura 18 - Tela de abertura de chamado técnico ... 49
Figura 19 - Vinculando técnico ao chamado ... 49
Figura 20 - Exemplo de troca de interações ... 50
Figura 21 - Cadastro de solução e fechamento do chamado ... 50
Figura 22 - Cadastro de solução em chamado através de smartphone ... 51
Figura 23 - Tela de escolha dos atributos RBC com mineração de texto ... 52
Figura 24 - Pesquisa de casos similares com RBC ... 53
Figura 25 - Consulta de solução de casos similares ... 53
Figura 26 - Formulário de pesquisa de satisfação ... 54
Figura 27 - Relatório de pesquisas de satisfação ... 54
Figura 28 - Consulta de casos em smartphone ... 55
Figura 29 - Exemplo parcial de memória de cálculo de um caso ... 56
LISTA DE QUADROS
Quadro 1 - Instanciação da classe PHP Classifier ... 27
Quadro 2 - Treinamento da classe PHP Classifier ... 27
Quadro 3 - Resultado da classificação da biblioteca PHP Classifier ... 28
Quadro 4 – Requisitos Funcionais ... 36
Quadro 5 - Requisitos Não Funcionais ... 36
Quadro 6 - Função de cálculo de similaridade local ... 42
Quadro 7 - Função de cálculo de similaridade global ... 44
Quadro 9 - Quadro comparativo entre trabalhos correlatos ... 58
Quadro 10 – Abrir chamado técnico ... 64
Quadro 11 – Fechar chamado técnico ... 64
Quadro 12 - Registrar interação em chamado técnico ... 64
Quadro 13 – Avaliar atendimento recebido em chamado ... 64
Quadro 14 - Emitir relatórios ... 65
Quadro 15 – Consultar casos semelhantes com RBC ... 65
Quadro 16 - Vincular técnico a chamado técnico ... 65
Quadro 17 – Tabela Users ... 66
Quadro 18 - Tabela Tickets ... 66
Quadro 19 - Tabela Cases ... 67
Quadro 20 - Tabela Priorities ... 67
Quadro 21 – Tabela Surveys ... 67
Quadro 22 – Tabela Interactions ... 67
Quadro 23 - Tabela Weights ... 68
Quadro 24 - Tabela Stopwords ... 68
Quadro 25 - Tabela Dictionary ... 68
Quadro 26 - Tabela Inflector ... 68
LISTA DE ABREVIATURAS E SIGLAS
CSS - Cascading Style Sheets
HTML – Hypertext Markup Language IDE - Integrated Development Environment
ITIL – Information Technology Infrastructure Library MIT – Massachusetts Institute of Technology
MVC – Model View Controller PHP – Hypertext Preprocessor
RBC – Raciocínio Baseado em Casos
SGBD – Sistema Gerenciador de Banco de Dados TI – Tecnologia da Informação
URL - Uniform Resource Locator XML – eXtended Markup Language W3C - World Wide Web Consortium
SUMÁRIO
1 INTRODUÇÃO ... 11
1.1 OBJETIVOS ... 12
1.2 ESTRUTURA... 13
2 FUNDAMENTAÇÃO TEÓRICA ... 14
2.1 GESTÃO DE SERVIÇOS DE TI... 14
2.1.1 Gestão de Incidentes ... 14
2.1.2 Gestão de Problemas ... 15
2.2 HELP DESK ... 17
2.3 RACIOCÍNIO BASEADO EM CASOS ... 18
2.3.1 Recuperação de casos ... 21
2.3.2 Reutilização de casos ... 21
2.3.3 Revisão de casos ... 22
2.3.4 Indexação e retenção de casos... 23
2.3.5 Nearest Neighbour ... 23
2.4 MINERAÇÃO DE TEXTO ... 24
2.4.1 Classificação de documentos ... 25
2.5 CAKE PHP ... 28
2.6 TRABALHOS CORRELATOS ... 29
2.6.1 Sistema de apoio a help desk utilizando gestão do conhecimento e técnica de raciocínio baseado em casos ... 29
2.6.2 Sistema de conhecimento em help desk utilizando raciocínio baseado em casos para apoio aos clientes e consultores de softhouse na web ... 31
2.6.3 Aplicativo para empresa de help desk baseado em gestão do conhecimento utilizando a técnica de mineração de texto ... 32
3 DESENVOLVIMENTO ... 34
3.1 SISTEMA ATUAL ... 34
3.2 LEVANTAMENTO DE INFORMAÇÕES ... 34
3.3 ESPECIFICAÇÃO ... 38
3.3.1 Diagrama de casos de uso ... 38
3.3.2 Modelo Entidade Relacionamento ... 40
3.4.1 Técnicas e ferramentas utilizadas... 41 3.4.2 Operacionalidade da implementação ... 46 3.5 RESULTADOS E DISCUSSÕES ... 57 4 CONCLUSÕES ... 60 4.1 EXTENSÕES ... 61 REFERÊNCIAS ... 62
APÊNDICE A – DESCRIÇÃO DOS CASOS DE USO ... 64
APÊNDICE B – DICIONÁRIO DE DADOS ... 66
APÊNDICE C – QUESTIONÁRIO APLICADO PARA AVALIAR RESULTADOS DO SISTEMA ... 69
11
1 INTRODUÇÃO
Atualmente a empresa Guia Fácil Comunicação, localizada em Blumenau, SC, não possui nenhum sistema informatizado para abertura, acompanhamento e controle de chamados para a área de suporte técnico em informática. Todas as solicitações são feitas através de envio de e-mails diretamente aos técnicos, o que não permite um controle eficiente, visualização de métricas de qualidade do atendimento prestado, avaliação de satisfação dos usuários finais, acarretando ainda esquecimentos de chamados, perda de capital intelectual e interrupção dos serviços por mais tempo. Além disso, todas as soluções encontradas para um determinado problema não são registradas, levando os técnicos a procurarem novamente soluções já encontradas em situações anteriores para problemas recorrentes.
A ideia surgiu da necessidade da empresa ter um controle eficiente de chamados técnicos feitos por seus colaboradores para a área de suporte. Atualmente, existem vários meios de contato com o help desk, o que leva a esquecimentos e perda de informações, elevando o tempo para solução dos problemas, e consequentemente, reduzindo a produtividade dos colaboradores. Todas as soluções encontradas para os chamados técnicos não são armazenadas. Posteriormente, quando um chamado semelhante for aberto, todo o esforço de pesquisa e investigação terá que ser refeito. Armazenando as soluções, ganha-se em produtividade, e o conhecimento fica centralizado. Outra necessidade é a avaliação da qualidade do atendimento prestado. Utilizando estes dados, o coordenador de help desk poderá identificar aspectos que podem ser melhorados e otimizar processos, reduzindo ainda mais o tempo necessário para resolução de chamados.
Atualmente, a Tecnologia da Informação (TI) é uma das mais importantes ferramentas de trabalho dentro de organizações, e em muitos casos, as atividades operacionais são totalmente dependentes da TI, como por exemplo no atendimento bancário. Segundo Cavalari e Costa (2005), neste ambiente onde os computadores são as principais ferramentas de produção, é primordial que eles estejam sempre em perfeito funcionamento. Tarefa que tem se tornada cada vez mais complexa, pois até a década de 1980, as pessoas que trabalhavam diretamente com computadores eram os especialistas da área. Este quadro se inverteu radicalmente a partir da década de 90, onde os usuários da TI passaram ser as pessoas oriundas de áreas que a TI não era fundamental e, portanto, têm pouco ou nenhum conhecimento em informática.
As organizações disponibilizam microcomputadores aos seus colaboradores para auxiliá-los a se tornarem mais produtivos. Para que o computador realmente se torne um
12
aliado à produtividade, as empresas entendem que também devem providenciar assistência contínua a seus colaboradores, para que este não se torne apenas uma fonte de frustração aos seus usuários, e reconhecem a crescente necessidade de equipes capacitadas para prestar suporte a outros colaboradores (BEISSE, 2012). Um exemplo é o help desk, a central de atendimento que coordena e soluciona os incidentes que ocorrem com usuários da TI e equipamentos no menor tempo acordado, assegurando que os chamados não sejam perdidos, esquecidos ou negligenciados, atendendo o usuário de forma independente das regras e processos do negócio, focando no lado técnico (SEMER, 2006).
Frequentemente, o help desk é acionado para resolver problemas recorrentes, que são comuns no cotidiano do usuário final. A Gerência de Incidentes assegura que os problemas sejam corrigidos e os serviços restaurados o mais rápido possível, garantindo o cumprimento do nível de serviço acordado com o cliente. Já a Gerência de Problemas investiga as causas raiz dos incidentes, de forma a corrigi-las permanentemente, evitando que o incidente ocorra novamente. Suas operações devem estar alinhadas aos processos de negócio, de modo a identificar os serviços prioritários e distribuir esforços de acordo com as prioridades definidas (SOFTEX, 2013a).
Se houver um mecanismo capaz de registrar soluções já conhecidas para estes problemas, e permitir recuperá-las posteriormente, ganha-se em tempo e agilidade. Um exemplo é uma técnica de inteligência artificial chamada Raciocínio Baseado em Casos (RBC). O RBC surgiu como uma poderosa técnica de solução automática de problemas, relembrando uma situação anterior, reutilizando o conhecimento daquela situação (WANGENHEIM; WANGENHEIM; RATEKE, 2013).
1.1 OBJETIVOS
O objetivo geral do trabalho proposto é desenvolver um sistema de informação para abertura, acompanhamento e controle de chamados técnicos para a área de help desk da empresa Guia Fácil.
Os objetivos específicos do trabalho são:
a) armazenar as soluções encontradas para os chamados técnicos utilizando Raciocínio Baseado em Casos;
b) obter a opinião dos usuários em relação ao atendimento prestado; c) permitir o acompanhamento dos atendimentos realizados pelos técnicos.
13
1.2 ESTRUTURA
O primeiro capítulo apresenta a introdução e os objetivos gerais e específicos do trabalho.
O segundo capítulo apresenta a fundamentação teórica, sobre help desk, gestão de problemas, raciocínio baseado em casos, mineração de dados e o framework para desenvolvimento de aplicações web CakePHP.
O terceiro capítulo apresenta o desenvolvimento do sistema proposto. Desde o levantamento de informações inicial, até a especificação dos requisitos funcionais, diagramas de atividade e casos de uso, técnicas e ferramentas utilizadas durante a implementação, e por último, os resultados e discussões.
O quarto capítulo apresenta as conclusões e sugestões para continuação em futuros trabalhos.
14
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo aborda assuntos a serem apresentados nas seções a seguir, tais como gestão de serviços de TI, help desk, raciocínio baseado em casos, mineração de texto,
framework CakePHP, além de trabalhos correlatos.
2.1 GESTÃO DE SERVIÇOS DE TI
Em um mundo altamente competitivo e de mudanças constantes e inesperadas, é preciso ter agilidade para reagir com rapidez às falhas e imprevistos, bem como antecipá-los. O desafio de gerenciar uma área de TI, embora há muito tempo do interesse da comunidade de TI, tornou-se recentemente uma preocupação da alta direção das organizações (MAGALHÃES; PINHEIRO, 2007).
O gerenciamento de serviços de TI, na busca pelo alinhamento com o negócio, recebeu um reforço substancial com o estabelecimento da Information Technology Infrastructure Library (ITIL), um conjunto de práticas para o Gerenciamento de Serviços de TI. Estas práticas fornecem uma alternativa para o gerenciamento de serviços, propondo uma metodologia focada nos processos e nas suas relações de dependência. A ITIL fornece orientações para a área de TI baseadas nas melhores práticas e em um ambiente de qualidade, visando à melhoria contínua, envolvendo pessoas, processos e tecnologia, objetivando o gerenciamento da área de TI como um negócio dentro do negócio (MAGALHÃES; PINHEIRO, 2007).
2.1.1 Gestão de Incidentes
A gestão de incidentes se refere às atividades de identificar, analisar e corrigir desastres. Por exemplo, um incêndio em uma fábrica seria um risco que foi descoberto, ou um incidente que ocorreu. O papel da gestão de incidentes seria gerenciar e organizar as ações para corrigir o incidente o mais rápido possível (ROEBUCK, 2012).
A ITIL define um incidente como um evento que não faz parte da operação padrão, que pode causar uma interrupção, ou redução da qualidade dos serviços. Logo, a gestão de incidentes seria o processo de restaurar as operações o mais rápido possível com o mínimo de impactos adversos nas operações (ROEBUCK, 2012).
De acordo com o modelo Melhoria de Processos do Software Brasileiro (MPS.BR), incidente é algo não planejado, que ocorre durante a prestação do serviço e que pode afetar o negócio do cliente. Gerenciar o incidente, então, significa recolocar o serviço interrompido no ar o mais rápido possível, garantindo que o tempo de interrupção esteja de acordo com o que
15
estabelece o Acordo de Nível de Serviço. Gerenciar ainda significa registrar, acompanhar, escalonar, e quando houver necessidade, encerrar o registro do incidente (SOFTEX, 2013a).
Um dos objetivos da gestão de incidentes é restaurar a prestação do serviço ao estado normal o mais rápido possível, sem se preocupar com suas causas adjacentes. Por isso, é aceitável que soluções de contorno (workarounds) sejam implementadas quando for necessário. No modelo MPS.BR, as causas adjacentes serão tratadas posteriormente em outro processo, denominado Gerência de Problemas. Além disso, a Gerência de Incidentes deve coordenar todos os esforços para restauração dos serviços e assegurar que nenhum incidente foi esquecido ou negligenciado (SOFTEX, 2013a).
De acordo com o processo de Gerência de Incidentes, o help desk deve estar alinhado aos processos de negócio do cliente, de modo que a prioridade no restabelecimento dos serviços seja aquela determinada pelo negócio. Quanto mais rapidamente um incidente for tratado, maior será a disponibilidade do serviço e maior a satisfação do cliente (SOFTEX, 2013a).
2.1.2 Gestão de Problemas
A ITIL define problema como a causa desconhecida de um ou mais incidentes. O processo de Gestão de Problemas gerencia os problemas por todo o seu ciclo de vida. Também previne problemas recorrentes, e encontra maneiras de minimizar os impactos causados pelos incidentes que não podem ser prevenidos (OFFICE OF GOVERNMENT COMMERCE, 2010).
Gestão de Problemas é uma função do negócio composta de pessoas, processos e ferramentas destinados a resolver problemas de usuários ou clientes. Função que é normalmente gerenciada pelo help desk. Como organizações têm incrementado significativamente seus gastos com tecnologia, a visibilidade do help desk e a pressão por resultados neste setor cresceram também. A complexidade de muitas novas tecnologias aliada à sua rápida distribuição tornou o trabalho rápido e objetivo do help desk bastante dificultoso (WALKER, 2001).
O propósito do processo Gerência de Problemas é minimizar a interrupção do serviço por meio da investigação de causa raiz de um ou mais incidentes que impactam nos serviços ou nos acordos de nível de serviço. O processo de Gerência de Incidentes vai tomar medidas apenas para que os serviços sejam sempre reestabelecidos o mais rápido possível após um incidente. Isso significa que nem sempre a causa raiz é encontrada e resolvido, sendo assim, o incidente pode ocorrer novamente. A Gerência de Problemas investiga a infraestrutura e a
16
base de incidentes para identificar potenciais causas de falhas na prestação dos serviços. Uma vez que as causas são identificadas, é gerada uma solicitação de mudança para que o erro conhecido seja eliminado (SOFTEX, 2013b).
Embora Gestão de Problemas e Gestão de Incidentes sejam processos separados, estão intimamente relacionados. Tipicamente utilizarão as mesmas ferramentas, formas de categorização e códigos de prioridade e impacto para garantir comunicação efetiva durante a ocorrência de incidentes. Gestão de Problemas também tem relação com o a Gestão de Mudanças para garantir a efetiva implantação das soluções propostas para os incidentes (OFFICE OF GOVERNMENT COMMERCE, 2010).
Segundo Persse (2012), a primeira atividade que iniciará o ciclo de atividades da Gestão de Problemas é a detecção, ou estar ciente de que um problema existe e precisa ser corrigido. Para Office of Government Commerce (2010), a ITIL define múltiplas maneiras de detectar problemas:
a) suspeita ou detecção de uma causa desconhecida de um ou mais incidentes; b) análise de um incidente que revele problemas adjacentes;
c) detecção automática de uma falha na infraestrutura, através de ferramentas de monitoramento;
d) notificação de fornecedor ou prestador de serviços;
e) análise de incidentes como parte da Gestão de Problemas proativa.
Para permitir que os problemas sejam direcionados e trabalhados para a equipe correta, os casos devem ser categorizados. Problemas são, por definição, eventos específicos que requerem atenção de equipes específicas. Persse (2012) sugere um exemplo de esquema de classificação comum:
a) categorização por serviço (email, rede, impressora, suporte);
b) categorização por componente de serviço (servidor de arquivos, servidor de e-mails, roteador);
c) categorização por tipo de problema (acesso, segurança, impressão, softwares); d) categorização por plataforma (Outlook, Oracle, DB2);
e) categorização por grupo de usuários (financeiro, marketing).
Uma vez que o problema está categorizado, já é possível definir como o problema será resolvido. Neste ponto, deve ser considerada a priorização, de forma alinhar a Gestão de Problemas com o negócio, priorizando os problemas mais críticos. Após a devida
17
categorização e priorização do problema, ele é encaminhado para investigação, solução e registro (PERSSE, 2012).
Todos os detalhes relevantes dos problemas devem ser registrados. Como casos podem variar, é difícil apontar exatamente quais os detalhes que devem ser armazenados. Alguns exemplos são detalhes do usuário, do serviço, equipamento, data, prioridade e categorização, descrição do incidente e detalhes do diagnóstico e todas as tentativas de soluções tomadas. Os problemas devem ser priorizados da mesma forma que incidentes, levando em conta a severidade. Neste contexto, severidade se refere ao quão sério é o problema do ponto de vista da infraestrutura, como por exemplo o tempo e quantidade de pessoas e habilidades necessárias para resolução e custos (OFFICE OF GOVERNMENT COMMERCE, 2010). 2.2 HELP DESK
Quando um colaborador necessita de assistência técnica, ele pode dirigir-se diretamente a um técnico do setor de suporte técnico ou entrar em contato com o help desk. O
help desk fornece um ponto único de atendimento para os usuários que necessitam de
assistência técnica, tanto para colaboradores internos como clientes externos. Além disso, gerencia os problemas, solicita e fornece soluções (BEISSE, 2012).
Existem dois tipos de help desk – interno e externo. O help desk interno fornece suporte aos usuários e computadores dentro de uma mesma organização. Já o help desk externo vai dar suporte aos clientes de uma organização (BRUTON, 2012).
O help desk oferece um ponto único de contato, algo que usuários consideram desejável. No entanto, este ponto único de contato pode se repetir várias vezes dentro da organização – há especialistas em rede, mainframes, software, hardware e até mesmo outras áreas que não fazem parte da tecnologia da informação. Se o usuário precisa diagnosticar previamente o seu problema para contatar o especialista correto, ficará confuso. O benefício implícito de manter um ponto único entre todos os especialistas é justamente permitir que os usuários apenas descrevam os sintomas e o help desk faça o encaminhamento correto, levando a soluções mais rápidas e objetivas (BRUTON, 2012).
Segundo Statdblober (2006), o processo de atendimento apresenta obrigatoriamente os seguintes elementos, conforme é apresentado na Figura 1. Estes elementos podem desdobrar-se em vários outros, dependendo da complexidade da solicitação, do nível de detalhamento ou da própria estrutura da organização.
a) solicitação ou necessidade inicial do cliente ou usuário; b) retorno, solução, resposta ou feedback;
18
c) ação complementar (envio de mercadoria, assistência técnica, etc.);
d) elementos de controle do processo, como regras e requisitos formalmente definidos.
Figura 1 – Processo de Atendimento do Help Desk
Fonte: Statdlober (2006, p. 17).
Para Beisse (2012), o help desk frequentemente possui uma ou mais das seguintes opções de atendimento:
a) um local físico onde colaboradores internos ou clientes externos podem ir quando eles têm uma dúvida ou problema, ou desejam requisitar um atendimento;
b) um número de telefone (algumas vezes chamado de hotline) onde clientes externos ou colaboradores internos podem solicitar assistência;
c) uma caixa de e-mail, web site, ou serviço de chat online onde colaboradores ou clientes podem entrar em contato para solicitar ajuda.
Muitos help desks têm evoluído para oferecer serviços além da tradicional resolução de problemas. De acordo com o processo de Gerência de Problemas, esta nova organização é chamada de service center. Um service center oferece para seus usuários vários serviços como o tradicional suporte técnico, serviços de valor agregado como compras de computadores, coordenando e supervisionando ordens de compra para novos colaboradores, ou mover colaboradores para novas estações de trabalho e vários outros (WALKER, 2001). 2.3 RACIOCÍNIO BASEADO EM CASOS
Conforme a definição de Wangenheim, Wangenheim e Rateke (2013), o RBC usa uma base de dados explícita de soluções conhecidas de problemas para facilitar a resolução de novos problemas similares.
19
Estas soluções podem ser coletadas de especialistas humanos através do processo de engenharia do conhecimento ou ainda pode ser resultado de sucesso ou falha de buscas realizadas anteriormente (LUGER, 2008).
Raciocínio Baseado em Casos é 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á conhecidos. (WANGENHEIM; WANGENHEIM; RATEKE, 2013, não paginado).
Utilizam-se casos conhecidos como forma de resolução de problemas diariamente e de forma extremamente natural. Por exemplo, um médico ao escutar os problemas de seu paciente pode lembrar-se do histórico de outro paciente com sintomas similares e aplicar um tratamento semelhante. Outro exemplo é o meio jurídico, onde advogados podem reforçar seus argumentos baseando-se em jurisprudências semelhantes. Estas situações têm em comum o fato de que uma solução obtida no passado foi reutilizada para resolver a situação presente (WANGENHEIM; WANGENHIEM; RATEKE, 2013).
Situações bem-sucedidas no passado podem auxiliar a repetir o mesmo sucesso, bem como falhas anteriores também podem auxiliar em diagnósticos para potenciais problemas em novas situações. Diagnóstico de hardware é um ótimo exemplo disso. Um técnico em
hardware, além de usar seu extensivo conhecimento teórico, também leva em conta situações
de sucesso e falha do passado, adaptando-as para a situação corrente (LUGER, 2008).
O RBC oferece várias vantagens na construção de sistemas especialistas. A aquisição do conhecimento pode ser simplificada caso se armazene a solução de um humano especialista para os problemas, e se deixe o sistema selecionar o caso mais semelhante para a nova situação. Isto evita que o engenheiro do conhecimento tenha o trabalho de construir regras generalizadas a partir dos exemplos gerados pelos especialistas. Ao invés disso, o sistema generaliza as regras automaticamente, através do processo de aplicá-las à nova situação (LUGER, 2008).
A técnica de RBC tem sido aplicada a uma vasta gama de problemas, permitindo otimização do tempo e performance e redução de custos. Além disso, possui vantagens em relação a sistemas de conhecimento generalizado, pois é muito mais fácil produzir exemplos reais de solução de problemas do que generalizar o conhecimento através de classes de problemas para que se encaixem a cada nova situação encontrada. (MAHER; BALACHANDRAN; ZHANG, 2014).
Um caso é apropriado se sua solução pode ser aplicada com sucesso à nova situação. Tanto humanos quanto sistemas de inteligência artificial determinam a similaridade baseados
20
em atributos em comum. Por exemplo, se dois pacientes compartilham características em seus sintomas e prontuários médicos, há grandes probabilidades de que ambos tenham a mesma doença e responderão adequadamente ao mesmo tratamento. Tipicamente, casos são indexados por suas características em comum (LUGER, 2008).
A similaridade entre dois casos recebe o nome de similaridade global. Para determinar a utilidade de um caso anterior em relação a nova situação, a similaridade global entre os dois casos tem que ser determinada, considerando todos os atributos. Modelos formais de similaridade axiomatizam o processo de determinação de similaridade feito pelo ser humano, permitindo que as suposições assumidas no modelo possam ser verificadas de forma empírica.
Para Wangenheim, Wangenheim e Rateke (2013), são suposições básicas a respeito do julgamento de similaridade:
a) reflexividade, onde um objeto é similar a ele próprio;
b) simetria, se o caso A é similar ao caso B, então o caso B também é similar ao caso A;
c) transitividade, onde se o caso A é similar ao caso B, e o caso B é similar ao caso C, então o caso C também é similar ao caso A;
d) monotonicidade, onde a similaridade entre dois casos cresce monotonicamente com o aumento de correspondências e a redução de diferenças entre eles.
Para Luger (2008), sistemas RBC possuem um ciclo comum apresentado na Figura 2. Para cada novo problema, o RBC:
a) recupera casos similares na base de dados;
b) modifica e reusa os casos encontrados para que se apliquem à situação atual; c) revisa o caso transformado;
d) retém a solução para uso posterior.
Figura 2 – Ciclo do Raciocínio Baseado em Casos
21
2.3.1 Recuperação de casos
A recuperação de casos é o primeiro processo que um sistema RBC deve fazer para resolver um novo caso. Dada a descrição de um novo problema, identificar todos os casos iguais ou similares é o objetivo desta etapa. Para indexar novos casos, a especificação de um problema é transformada em um padrão a ser encontrado. Este padrão pode ser obtido diretamente de entradas do usuário, ou pode ser modificado, para por exemplo, alterar a ordem de importância de cada um dos atributos. Um novo problema pode ser especificado como um conjunto de pares de atributo e valor, um conjunto de regras e condições para cada atributo, ou então uma rede de atributos (MAHER, BALACHANDRAN, ZHANG, 2014).
A tarefa de recuperar casos procura por coincidências entre casos individuais e o padrão de indexação de casos. Cada caso na memória é comparado com o padrão. A recuperação pode ser baseada em similaridade perfeita, com o padrão encontrado de forma exata, ou de forma parcial, fazendo-se necessário um limite para determinar até que ponto um caso é semelhante o suficiente. Após a recuperação dos casos mais similares, é preciso ordenar os casos para definir qual é a melhor alternativa dentro os pré-selecionados. O processo de seleção depende do padrão usado para indexação da memória de casos. Se o padrão é um conjunto de características e pesos para cada uma delas e cada caso é ranqueado de acordo com os pesos de cada característica, o processo de seleção se baseia no caso com ranking mais alto. Se o padrão for apenas um conjunto de características, sem pesos associados, a seleção se baseia apenas no caso que compartilha o maior número de características iguais (MAHER; BALACHANDRAN; ZHANG, 2014).
A técnica mais simples de recuperação de casos é a sequencial. A medida de similaridade é calculada sequencialmente, para cada um dos casos armazenados na base de casos. Esta técnica permite determinar um número X de casos mais similares. Para determinar uma relação de preferência, aplica-se uma função de similaridade sucessivamente a cada um dos casos da base de casos. Todos os casos são ordenados de acordo com a sua similaridade a consulta. É um método de aplicação universal e fácil de ser implementado para determinação de casos similares (WANGENHEIM; WANGENHEIM; RATEKE, 2013).
2.3.2 Reutilização de casos
Quando um caso supostamente adequado é recuperado da base de casos após a realização de uma pesquisa, a solução deste caso será objeto de uma tentativa de reutilização para solucionar o problema atual. Nesta fase do RBC, ocorre a reutilização do conhecimento de solução dos problemas por meio da transferência de conhecimento do caso anterior que era
22
conhecido, para o novo caso, que até então era desconhecido. Uma vez que o caso recuperado pode não satisfazer completamente os requisitos dados a partir da nova situação, pode ser necessário adaptar a solução previamente descrita antes da efetiva aplicação ao novo caso. No entanto, na maioria dos domínios de aplicação de RBC, apenas aplicar a mesma solução geralmente é o suficiente para solução dos problemas, ou em último caso que o usuário adapte a solução manualmente (WANGENHEIM; WANGENHEIM; RATEKE, 2013).
Para Luger (2008), tipicamente um caso recomenda uma sequência de operações que levam de um estado inicial até o objetivo. O motor de RBC precisa transformar as soluções armazenadas em uma sequência de passos que se encaixe ao novo problema. Métodos analíticos, como funções matemáticas, podem ser úteis para determinar, por exemplo, temperaturas ideais ou material para uma solda. Quando relações analíticas entre os casos não estão disponíveis, é necessário utilizar métodos mais heurísticos, como por exemplo, em help
desks e diagnóstico de hardware.
A adaptação tem papel fundamental na flexibilização dos sistemas RBC, pois sua capacidade de solução de novos problemas está diretamente ligada à sua habilidade de adaptar casos recuperados às novas circunstâncias e também na habilidade de consertar soluções falhas. Existem muitas maneiras de adaptar casos, e uma adaptação efetiva depende do conhecimento sobre possíveis modificações válidas e maneiras de selecionar quais serão apropriadas em determinada situação (WANGENHEIM; WANGENHEIM; RATEKE, 2013).
Para sistemas de RBC criados para solução de problemas simples, a adaptação substitucional fornece flexibilidade e adaptabilidade suficiente. É uma estratégia eficiente especialmente quando os casos recuperados são parecidos com os objetivos, de forma que requeiram apenas modificações pequenas, sem alterações estruturais. Apenas atributos são alterados, mantendo a estrutura da nova solução (WANGENHEIM; WANGENHEIM; RATEKE, 2013).
2.3.3 Revisão de casos
Quando na fase de reutilização uma solução gerada não é a correta ou não satisfez o novo problema, surge a oportunidade de aprendizado para o RBC. A revisão consiste em avaliar criteriosamente a solução gerada pelo reuso, e se considerada como correta aprenda com o sucesso e retenha o caso na base de casos. Se a solução não for correta, é preciso reparar a solução para se adequar ao novo caso, utilizando conhecimento específico (WANGENHEIM; WANGENHEIM; RATEKE, 2013).
23
Em sistemas de diagnóstico, pode-se tomar como exemplo uma impressora que não imprime em preto. Uma das soluções sugeridas pelo sistema RBC foi trocar o cartucho de tinta preta. Após aplicada a solução, o problema permanece, sugerindo que a causa não é o cartucho de tinta preta, e, portanto, o problema deve ser melhor investigado. Supondo que o real problema era a falta de energia, a solução recuperada deveria ser adaptada sugerindo a troca da fonte de alimentação do equipamento (WANGENHEIM; WANGENHEIM; RATEKE, 2013).
2.3.4 Indexação e retenção de casos
Nesta etapa, o sistema incorpora tudo que possa ser útil para a resolução do problema e selecionando as informações relevantes de forma a retê-las, quando uma solução encontrada pode ser confirmada para resolução do novo problema. O caso é integrado à memória de casos (URNAU; KIPPER; FROZA, 2014).
Retenção é aprendizado de novos casos ou de conhecimentos relevantes abstraídos de casos individuais, através da extração de conhecimento de indexação de casos. A extração tem foco na seleção das estruturas de conhecimento a partir das quais a informação que deveria ser capturada deverá ser tomada. A indexação implica decidir que tipos de índices devem ser utilizados para pesquisas futuras na base de casos (WANGENHEIM; WANGENHEIM; RATEKE, 2013).
2.3.5 Nearest Neighbour
Esta foi a técnica implementada para calcular a similaridade global entre dois casos na ferramenta desenvolvida. Nearest Neighbour ou vizinho mais próximo é uma representação da similaridade global entre dois casos na base de casos. Para cada índice é utilizada uma medida de similaridade local, determinando o valor de similaridade específico para números, símbolos ou palavras. Estas medidas também podem ser multiplicadas por um fator de peso, representando a sua importância na definição da similaridade entre casos (WANGENHEIM; WANGENHEIM; RATEKE, 2013).
Conforme apresenta-se na Figura 3, a fórmula do nearest neighbour consiste no somatório da similaridade de cada um dos atributos de dois casos dado por uma função de similaridade f e multiplicado pelo fator de peso, dividindo pelo somatório de todos os fatores de peso.
24
Figura 3 - Fórmula do Nearest Neighbour
Fonte: Wangenheim, Wangenheim e Rateke (2013, não paginado).
Fórmulas similares ao nearest neighbour são utilizadas pela maioria das ferramentas RBC. Os valores de similaridade são geralmente normalizados em valores de 0 até 1, onde 1 representa similaridade total e 0 representa dissimilaridade total. A normalização ocorre com a divisão do valor de similaridade total pela soma de todos os pesos dos índices (WANGENHEIM; WANGENHEIM; RATEKE, 2013).
2.4 MINERAÇÃO DE TEXTO
A tecnologia, nos dias de hoje, permite que sejam armazenados vastas quantidades de dados. À medida que a quantidade de dados armazenados cresce, a quantidade de pessoas que conseguem interpretá-los cai, de forma alarmante (WITTEN; FRANK, 2005).
A mineração de dados, cujo conceito é encontrar padrões com significado em dados, é uma resposta óbvia ao grande volume de dados armazenados. Métodos de mineração de dados aprendem de exemplos de experiências passadas (WEISS; INDURKHYA; ZHANG, 2010).
Mineração de texto é o processo de procurar por padrões em textos. Comparado com o tipo de dado que a mineração de dados lida, estruturado em tabelas, textos não são estruturados, são amórficos e difícil de lidar. No entanto, na cultura ocidental moderna, texto é o veículo de troca de informações mais comum (WITTEN; FRANK, 2005).
Um requisito comum na mineração de dados e textos é que a informação extraída seja potencialmente útil, ou seja, capaz de fornecer uma base para tomada de ações automaticamente. No caso da mineração de dados, esta noção pode ser expressa como padrões que permitem previsões não triviais serem feitas em novos dados, com a mesma origem. A performance pode ser medida contando o número de sucessos e falhas, e técnicas estatísticas podem ser aplicadas para comprar diferentes métodos de mineração de dados. Porém, na mineração de textos, é difícil caracterizar o que é informação potencialmente útil, consequentemente tornando igualmente complicado o processo de medir o nível de sucesso do sistema (WITTEN; FRANK, 2005).
25
Palavras muito frequentes em documentos, bem como artigos, preposições e conjunções, são inúteis para os propósitos de recuperação dentro de um documento. Estas palavras são chamadas de stopwords e são eliminadas dos índices e dos processos de indexação. A eliminação destas palavras oferece o benefício adicional de reduzir consideravelmente a estrutura de indexação, melhorando a performance da aplicação (BAEZA-YATES; RIBEIRO-NETO, 2013).
Outro processamento feito antes da indexação é a normalização morfológica das palavras. As características de gênero, número e grau são eliminadas, sempre reduzindo uma palavra e suas variações a um único termo. O usuário é dispensado de preocupar-se com a forma ortográfica na qual são escritas as palavras. Desta forma, uma ideia pode ser expressada de várias formas e sempre será reduzida ao mesmo termo (WIVES, 2012). Além disso, pode haver um dicionário de palavras similares que embora tenham grafia diferente, representam ideais iguais ou semelhantes.
2.4.1 Classificação de documentos
Classificação significa separar coisas em categorias, de alguma forma que seja útil para um propósito, baseado em características comuns. Na computação, o termo “classificação” é associado com um tipo particular de aprendizado. Exemplos de uma ou mais classes são fornecidos ao algoritmo, que mapeia as propriedades destes exemplos, de experiências passadas, normalmente expressados como pares de atributo e valor, para classificar novos exemplos (SAMMUT; WEBB, 2011).
É uma atividade comum, e importante. Sabendo previamente a classe de algo, podemos prever muitas de suas propriedades. É uma questão de generalização, prevendo valores acurados para exemplos não vistos anteriormente, e de compressão, tornando a transmissão e comunicação mais eficiente (SAMMUT; WEBB, 2011).
2.4.1.1 Modelos Bayesianos para classificação de documentos
Uma importante área da classificação de aprendizado de máquina é a classificação de documentos. Documentos podem ser notícias em jornais, e classes de documentos podem ser notícias domésticas, financeiras, esportes entre outros. Documentos são caracterizados por suas palavras, e uma forma de aplicar a classificação de textos é tratar a presença ou ausência de determinada palavra como um atributo verdadeiro ou falso. O algoritmo de Naïve Bayes é uma popular técnica especialmente para este tipo de aplicação pois é extremamente rápido e muito preciso (WITTEN; FRANK, 2005).
26
No entanto, uma limitação desta técnica é que não é levado em conta o número de ocorrências de cada palavra, que pode ser uma informação potencialmente útil para determinar a categoria de um documento. Um documento pode ser visto como uma bolsa que contém todas as palavras com múltiplas ocorrências de palavras repetidas. A frequência de cada palavra então pode ser considerada utilizando uma forma modificada do algoritmo de Bayes, chamada de Naïve Bayes multinominal (WITTEN; FRANK, 2005).
Supondo que n¹, n², ..., nk seja o número de ocorrências em um documento de uma determinada palavra e P¹, P², ...., Pk seja a probabilidade de obter esta palavra de uma amostra de documentos da categoria H. Sendo assim, a probabilidade do documento E, dada sua classe H é definida pela fórmula apresentada na Figura 4. Na fórmula, N é o número de palavras no documento. O motivo para o fatorial é levar em conta o fato de que a ordenação das ocorrências de cada uma das palavras é insignificante de acordo com o modelo da bolsa de palavras. O valor de Pi é estimado computando a frequência relativa da palavra i dentro do
texto de todos os documentos usados para o treinamento (WITTEN; FRANK, 2005).
Figura 4 - Fórmula de Naïve Bayes
Fonte: Witten e Frank (2005, p. 90).
Para demonstrar um exemplo prático, supõe-se que no vocabulário existam apenas duas palavras: yellow e blue. Uma determinada classe H de documento possui 75% de chances de conter a palavra yellow e 25% de chances de conter a palavra blue. E é um documento que contém 3 palavras, blue yellow blue. Existem 4 diferentes possibilidades diferentes para formar a bolsa de palavras. Como é apresentado na Figura 5, o documento E tem 9/64, ou 14% de chances de pertencer a classe H (WITTEN; FRANK, 2005).
Figura 5 - Aplicação prática da fórmula de Bayes
27
2.4.1.2 PHP Classifier
PHP Classifier é uma biblioteca de classificação de documentos baseado no algoritmo de Naïve Bayes. Segundo o autor da biblioteca, Lanchester (2013), suporta vários tokenizers para otimização da classificação e utiliza contagem logarítmica para prevenir underflow de números inteiros quando utilizada com dicionários grandes.
Tokenization é a decomposição de um texto contido em parágrafos e frases,
transformado-o em palavras, que geralmente melhor representam um texto. Tokens são formados por sequências alfabéticas contínuas, descartando todos os caracteres não alfabéticos. Se houver números, devem ser retidos também e interpretados de acordo com uma sintaxe pré-definida, pois podem conter sinais, pontos decimais e notações exponenciais (WITTEN; FRANK, 2005).
Como o tipo de dados integer ocupa um montante finito e fixo de memória, o alcance de números possíveis a serem armazenados também é limitado. No entanto, é possível que durante a execução do programa sejam executadas operações que resultem em números maiores ou menores do que podem ser representados. Esta condição é inválida e conhecida como integer overflow, quando o valor é maior que máximo, ou integer underflow, quando o valor é menor que o mínimo (CAPPER, 2012).
O primeiro passo para utilização da biblioteca é a instanciação da classe, conforme apresentando no trecho de código no Quadro 1. O método construtor recebe como parâmetro um tokenizer. Por padrão, a biblioteca vem com um tokenizer básico para ser utilizado, porém é possível criar novos tokenizers se for necessário customizar.
Quadro 1 - Instanciação da classe PHP Classifier $tokenizer = new HybridLogic\Classifier\Basic;
$classifier = new HybridLogic\Classifier($tokenizer); Fonte: adaptado de Lanchester (2013).
Para efetiva utilização da classe, deve-se prover exemplos de strings e sua respectiva classificação dentro do domínio da aplicação para realizar o treinamento da biblioteca. É utilizado o método train conforme apresenta-se no Quadro 2.
Quadro 2 - Treinamento da classe PHP Classifier $classifier->train('hot', 'The sun is hot');
$classifier->train('hot', 'It was a warm day in the sun'); $classifier->train('hot', 'This tea is hot!');
$classifier->train('cold', 'This ice is very cold!'); $classifier->train('cold', 'It\'s cold at night');
$classifier->train('cold', 'Ice formed on my at over night'); Fonte: adaptado de Lanchester (2013).
Uma vez feito o treinamento da biblioteca, pode-se utilizar o método classify passando como parâmetro qualquer string. O retorno será um array com todas as
28
possibilidades de classificação, de acordo com o treinamento e ordenado mais provável para a menos provável, conforme apresentado no Quadro 3.
Quadro 3 - Resultado da classificação da biblioteca PHP Classifier array (size=2)
'hot' => float 0.57142857142857 'cold' => float 0.42857142857143 Fonte: adaptado de Lanchester (2013).
2.5 CAKE PHP
Programadores têm usado frameworks por vários anos, embora no desenvolvimento de aplicações web o uso destes é mais recente. A principal vantagem do uso de um framework em qualquer projeto é explicada pelo conceito de inversão de controle. Muitos programas operam de uma forma que o código está no controle, decidindo como uma operação deve ocorrer ou como uma requisição do usuário deve ser manipulada. No conceito de inversão de controle, o programa tem uma série de classes que não fazem absolutamente nada até que o programador estenda-as e utilize (GOLDING, 2008).
Designado para tornar o desenvolvimento de aplicações web comuns simples e fácil, provendo uma estrutura organizacional que cobre nomes de classes, arquivos, tabelas de banco de dados e outras convenções. Através das convenções, o framework dispensa o programador de realizar configurações desnecessárias e cria uma estrutura uniforme, facilitando o trabalho com vários projetos (CAKE SOFTWARE FOUNDATION, 2015).
CakePHP suporta o padrão de design MVC (Model View Controller), que procura modularizar as aplicações em três partes. O Model, que representa os dados e regras de negócio, a View, que representa a camada de apresentação ao usuário e o Controller, que interliga o Model a e View. Juntamente com o padrão MVC, o framework se baseia na filosofia RAD (Rapid Application Development), que é um método para agilizar o desenvolvimento de aplicações utilizando-se de estruturas previamente construídas que são comuns para quase todas as aplicações. Outras vantagens para o desenvolvedor é a facilidade de manutenção, reuso de código, trabalho em equipe mais eficiente, dentre outros (CHAN; MILLER; OKOMORE, 2008).
Existem várias razões para a popularidade do CakePHP. Possui uma curva de aprendizagem pequena em comparação com outros frameworks disponíveis, por ser fácil de usar e entender. Além disso, há uma comunidade de programadores extremamente ativa sempre implementando novas funcionalidades. Alguns recursos que fazem parte do CakePHP e tornam o desenvolvimento de aplicações web fácil e rápido são (CHAN; MILLER; OKOMORE, 2008):
29
a) utilização do padrão MVC;
b) conectividade com banco de dados suporta várias plataformas; c) facilidade de instalação na grande maioria das plataformas;
d) sob licença MIT, que é mais flexível que outras licenças no mercado; e) possui flexível sistema de templates;
f) helpers que auxiliam na inserção de blocos de código HTML repetidos;
g) componentes para envio de e-mails, autenticação, controle de acesso, localização, segurança, sessões e manipulação de requisições;
h) classes utilitárias para manipular recursos como arquivos, pastas, XML's e outros;
i) otimização de URLs para motores de busca. 2.6 TRABALHOS CORRELATOS
Pode-se citar como trabalhos correlatos três trabalhos de conclusão do curso de Sistemas de Informação na Universidade Regional de Blumenau.
2.6.1 Sistema de apoio a help desk utilizando gestão do conhecimento e técnica de raciocínio baseado em casos
Wilvert (2005) desenvolveu um sistema de apoio ao help desk da empresa Senior Sistemas. Utilizou gestão do conhecimento e a técnica de Raciocínio Baseado em Casos com método do vizinho mais próximo, visando automatizar a busca por soluções similares a novas ocorrências, além de fornecer informações estatísticas para identificar áreas e processos a serem reformulados.
Na Figura 6 é apresentada a tela de cadastro de ocorrências do sistema. O usuário pode registrar todas as informações de forma padronizada.
30
Figura 6 - Tela de Cadastro de Ocorrências
Fonte: Wilvert (2005, p. 61).
Na Figura 7 é apresentada a tela de consulta de similaridades, momento em que é aplicada a técnica de RBC, pelo método do vizinho mais próximo. O usuário informa as palavras-chave. O sistema então apresenta as ocorrências na tela, e suas possíveis soluções.
A utilização do aplicativo desenvolvido por Wilvert (2005) significou um passo importante na otimização dos processos de atendimento às ocorrências do Sistema Sapiens, da empresa Senior Sistemas. Ganhou-se rapidez na solução das ocorrências, centralização e disseminação do conhecimento comum entre os usuários do help desk.
31
Figura 7 - Tela de Consulta de Similaridades
Fonte: Wilvert (2005, p. 63).
2.6.2 Sistema de conhecimento em help desk utilizando raciocínio baseado em casos para apoio aos clientes e consultores de softhouse na web
O trabalho de Wehrmeister (2008) foi o desenvolvimento de um sistema de conhecimento em help desk, utilizando Raciocínio Baseado em Casos para clientes de uma
softhouse. Os objetivos eram identificar o conhecimento interno das empresas, levantar
similaridade das dúvidas entre clientes, armazenar soluções de ocorrências, geração de relatórios estatísticos e disponibilizar a base de conhecimento para compartilhamento e reuso entre consultores.
Na Figura 8 apresenta-se a tela em que o usuário pode realizar uma consulta na base de conhecimento, através da técnica de RBC, pelo método do vizinho mais próximo. O usuário preenche a versão, módulo e categoria do sistema, e pelo menos uma palavra-chave. Feito isso, todas as ocorrências encontradas são listadas.
32
Figura 8 - Tela de Pesquisa de Soluções
Fonte: Wehrmeister (2008, p. 50).
O trabalho desenvolvido proporcionou maior agilidade nos processos internos das empresas em relação a dúvidas na utilização do produto Sapiens, onde antes clientes e consultores tinham contato frequente, mas muitas vezes a resposta não era rápida e prática para o cliente, gerando insatisfação (WEHRMEISTER, 2005).
2.6.3 Aplicativo para empresa de help desk baseado em gestão do conhecimento utilizando a técnica de mineração de texto
O trabalho de Fischer (2012) foi um aplicativo de apoio ao setor de suporte de uma empresa. O aplicativo possibilita a criação de um banco de dados com erros conhecidos e suas soluções. Os objetivos eram utilizar a técnica de mineração de texto (text mining) para possibilitar aos profissionais de suporte pesquisar soluções conhecidas para erros cadastrados no sistema, e apresentar o percentual de relevância das soluções encontradas, auxiliando o profissional na tomada de decisão. A implementação foi feita na linguagem Java, com
framework LingPipe e Hibernate para camada de acesso ao banco de dados.
Para realizar uma pesquisa por casos similares, o usuário precisa apenas digitar o texto desejado. O sistema fará a busca no banco de dados utilizando a técnica de mineração de texto e apresentará os resultados, ordenados pela porcentagem de acerto, conforme a Figura 9.
33
Figura 9 - Tela de resultados da busca por text mining
Fonte: Fischer (2012, p. 40).
A técnica empregada foi Descoberta de Conhecimento a partir de Textos, que consiste na aplicação de técnicas de análise de informações e aprendizado de máquina em textos. Busca extrair conhecimento útil ao usuário, procurando conteúdo que lhe seja útil dentro de um conjunto de textos pré-selecionados (FISCHER, 2012).
Fischer (2012) concluiu que o aplicativo foi de grande valor para o ambiente profissional dos usuários, contribuindo diretamente para melhorar a qualidade do atendimento aos clientes. No período anterior à implantação do sistema, os profissionais de suporte tinham suas próprias soluções, que por vezes eram inadequadas, ou não formatadas para os erros conhecidos. Após a implantação do aplicativo, as soluções passaram a ser padronizadas e formatadas da melhor maneira possível, sempre retornando a melhor solução cadastrada utilizando a técnica de text mining.
34
3 DESENVOLVIMENTO
Este capítulo apresenta o sistema atual utilizado, a especificação de requisitos funcionais, diagramas de atividade, modelo entidade relacionamento e casos de uso da ferramenta desenvolvida.
Além disso, demonstra as técnicas e ferramentas utilizadas bem como a operacionalidade da implementação.
3.1 SISTEMA ATUAL
Atualmente, o setor de Suporte Técnico da empresa Guia Fácil Comunicação dá suporte e manutenção para todos os computadores na sede da empresa e para equipes externas, totalizando aproximadamente 100 equipamentos. A disponibilidade dos equipamentos de informática é essencial para o andamento das atividades, uma vez que o principal canal de vendas da empresa (vendas telefônicas) é totalmente dependente dos serviços de informática, bem como possibilita aos setores de Administração de Contratos e Desenvolvimento Digital publicarem os anúncios vendidos aos clientes.
Como o suporte técnico não conta com nenhum sistema informatizado para controle dos atendimentos a todos os colaboradores, quando é necessária assistência o usuário deve enviar um e-mail, solicitar via telefone ou ir pessoalmente até o setor. Ou quando algum dos técnicos está em atendimento para um outro usuário, pode ser solicitado diretamente a ele.
Isto leva a esquecimentos de alguns chamados por parte dos técnicos, pois não há um ponto único de contato, e todas as solicitações ficam espalhadas em vários meios, dificultado a organização e ordem de atendimento. Além disso, não há histórico confiável das mensagens trocadas entre técnico e usuário, o que leva à falta de controle da situação de cada atendimento bem como perda de informações. Por último, não há registro das soluções encontradas pelos técnicos em cada atendimento, que poderiam ser usadas em atendimentos futuros poupando tempo e evitando perda de capital intelectual.
3.2 LEVANTAMENTO DE INFORMAÇÕES
Através de conversas informais com o coordenador do setor de help desk da empresa Guia Fácil Comunicação, verificou-se a necessidade de desenvolver um novo sistema de informação para gerenciar os chamados técnicos efetuados pelos colaboradores ao help desk. Anteriormente, todas as solicitações eram realizadas através do envio de e-mails. Desta forma, manter controle de chamados pendentes, resolvê-los dentro do tempo máximo aceitável, respeitar prioridades, registrar as soluções encontradas, fornecer métricas, dentre outros itens
35
necessários para manter o atendimento em um nível de qualidade aceitável era uma tarefa difícil.
Através da troca de e-mails, não há um registro confiável de soluções que já foram encontradas em situações anteriores, nem uma forma eficiente de recuperá-las. Todo o esforço de pesquisa e expertise do técnico para resolver um problema fica perdido entre centenas de mensagens, ou muitas vezes, nem é armazenado. Uma das principais funcionalidades do sistema é a pesquisa de chamados técnicos semelhantes através da técnica de Raciocínio Baseado em Casos. Sempre que um novo chamado técnico for aberto, o técnico responsável pelo atendimento poderá consultar os casos mais semelhantes e aproveitar ou adaptar a solução já encontrada em um momento anterior. Todo o trabalho de pesquisa dos técnicos para encontrar soluções poderá ser reaproveitado, permitindo soluções dos chamados de forma mais rápida e eficiente, além de armazenar o conhecimento de forma padronizada, categorizada, conforme os manuais de processo ITIL Gerência de Problema, e priorizada, conforme o processo de Gerência de Incidentes. Para garantir maior padronização e agilizar ainda mais as pesquisas por casos similares encontrando automaticamente os parâmetros, o RBC será apoiado pelo algoritmo de classificação de documentos Naive Bayes.
Outra necessidade do help desk da empresa é um mecanismo de avaliação de satisfação dos colaboradores em relação ao serviço de atendimento prestado por cada técnico. Após o fechamento de cada chamado técnico, o colaborador que fez a abertura terá a oportunidade de avaliar o atendimento recebido. Esta avaliação se dá em forma de uma nota e comentários. Com estes dados, o coordenador do help desk terá métricas e relatórios disponíveis para tomar ações no sentido de corrigir e melhorar cada vez mais a qualidade do atendimento.
O sistema possibilita técnico e usuário trocarem mensagens através do sistema, mantendo o histórico destas interações de forma organizada, e sempre avisa por e-mail quando há qualquer mensagem nova. Além disso, os técnicos podem classificar todos os chamados em relação a sua prioridade, para desta forma, saberem exatamente qual deve ser sua próxima tarefa, sem a necessidade de vasculhar e-mails e alinhar seus trabalhos as necessidades, conforme o processo de Gerência de Incidentes.
No Quadro 4, apresentam-se os requisitos funcionais previstos para o sistema e sua rastreabilidade, ou seja, vinculação com os casos de uso correspondentes.
36
Quadro 4 – Requisitos Funcionais
Requisitos Funcionais Caso de Uso
RF01: O sistema deve permitir abrir chamados técnicos. UC01 RF02: O sistema deve permitir fechar chamados técnicos. UC02 RF03: O sistema deve permitir a consulta de chamados técnicos. UC03 RF04: O sistema deve permitir registrar interações (troca de mensagens) em
chamados técnicos.
UC04 RF05: O sistema deve permitir avaliar o atendimento de cada chamado técnico. UC05
RF06: O sistema deve permitir efetuar login. UC06
RF07: O sistema deve permitir manter os usuários do sistema. UC07 RF08: O sistema deve emitir relatório de usuários que mais abrem chamados
técnicos.
UC08 RF09: O sistema deve emitir relatório de quantidade de chamados técnicos
resolvidos e não resolvidos por técnico.
UC08 RF10: O sistema deve emitir relatório de tempo médio de solução para os
chamados técnicos.
UC08 RF11: O sistema deve emitir relatório de avaliações recebidas por técnico. UC08
RF12: O sistema deve permitir cadastrar soluções. UC02
RF13: O sistema deve permitir consultar casos semelhantes através da técnica de RBC, complementado por text mining.
UC10, UC02 RF14: O sistema deve enviar um e-mail ao técnico quando o usuário registrar
uma interação no chamado técnico e vice-versa.
UC04 RF15: O sistema deve permitir técnicos vincularem-se a chamados técnicos. UC11 RF16: O sistema deve enviar um e-mail ao coordenador quando houver
chamados abertos com mais de 24 horas sem interações registradas.
UC14 RF17: O sistema deve enviar um e-mail ao coordenador quando um
atendimento for avaliado com nota menor que 6,0.
UC13 RF18: O sistema deve permitir manter prioridades de chamados técnicos. UC15 RF19: O sistema deve permitir manter o dicionário de palavras similares. UC16 RF20: O sistema deve permitir ajustar os pesos dos atributos do RBC. UC17
RF21: O sistema deve permitir manter stopwords. UC18
RF22: O sistema deve permitir manter exceções de flexões de número. UC19 RF23: O sistema deve permitir manter tokens de classificação de documento. UC20
O Quadro 5 apresenta os requisitos não funcionais previstos para o sistema. Quadro 5 - Requisitos Não Funcionais
Requisitos Não Funcionais
RNF01: O sistema deve ser desenvolvido na linguagem Hypertext Preprocessor (PHP). RNF02: O sistema deve ser compatível com o sistema gerenciador de banco de dados (SGBD) MySQL.
RNF03: O sistema deve ser compatível com o servidor web Apache.
RNF04: O sistema deve possuir layout responsivo, compatível com tablets e smartphones. RNF05: O sistema deve utilizar o método do vizinho mais próximo normalizado para calcular a similaridade entre os casos.
RNF06: O sistema deve utilizar o algoritmo de Naive Bayes para classificar os chamados.
Na Figura 10, apresenta-se o diagrama de atividades para abertura de um chamado, até a pesquisa de casos similares e fechamento do caso. As fases do ciclo do RBC, conforme Figura 2, estão destacadas no diagrama pelas regiões tracejadas.
37
Figura 10 - Diagrama de atividades para abertura, pesquisa de casos similares e fechamento dos chamados
act 3 Diagrama de Ativ idades
Usuário Final Técnico Sistema
Início
Abrir chamado técnico Vincular-se ao chamado técnico Fim Informações do são suficientes? Registrar interação Responder interação
Definir v alores dos
atributos do RBC Salv ar atributos
Buscar casos mais similares Visualizar soluções dos
casos mais similares
Selecionar caso com solução mais adequada
Adaptar solução selecionada Salv ar solução Deseja pesquisar casos similares? Descrev er solução Recuperação Reuso Adaptação Retenção Não Sim Não Sim
O fluxo inicia com o usuário abrindo um chamado. Uma vez que o chamado esteja aberto, ele estará disponível a todos os técnicos na lista de chamados pendentes, quando um técnico deve vincular-se ao chamado. Neste momento o técnico verifica através do relato do usuário se possui informações suficientes para prosseguir com o atendimento. Se não houver informações suficientes, o técnico pode enviar uma mensagem ao usuário. O usuário responde à mensagem. Se neste momento houver informações suficientes, o técnico prossegue para a próxima atividade.
38
Neste momento, o técnico pode simplesmente descrever a solução que foi tomada e concluir o chamado caso se depare com um chamado simples, que não tenha necessidade de efetuar pesquisas no RBC.
Se o técnico optar por realizar a pesquisa no RBC, o próximo passo é identificar os atributos do RBC para o caso em questão, para permitir a realização da busca. Quando os atributos forem identificados, o sistema salva para pesquisas posteriores e aplica a técnica de recuperação de casos, exibindo ao usuário os dez casos mais similares encontrados. O técnico pode navegar pela solução dos casos mais similares até encontrar a mais adequada. Quando encontrar a solução correta, o sistema redireciona para o chamado em questão e permite que o técnico faça alguma adaptação na solução do caso recuperado para o novo caso, ou simplesmente salve a solução da mesma forma. Quando a solução for salva, o novo caso está concluído e retido na base do RBC, disponível para consultas posteriores.
3.3 ESPECIFICAÇÃO
Para a especificação de requisitos e modelagem dos diagramas de caso de uso, na linguagem UML, foi utilizado a ferramenta Enterprise Architect. Para a modelagem do diagrama de Entidade e Relacionamento, foi utilizado a ferramenta MySQL Workbench. 3.3.1 Diagrama de casos de uso
Na Figura 11 apresenta-se o diagrama de casos de uso do usuário final. O apêndice A apresenta o detalhamento dos cenários dos casos de uso mais críticos do sistema.
O Usuário Final é o usuário comum que irá abrir os chamados no sistema. Este ator tem possibilidade de abrir chamados técnicos, registrar interações em chamados técnicos, consultar seus próprios chamados técnicos e efetuar a avaliação dos atendimentos recebidos em cada chamado técnico.
Na Figura 12 apresenta-se o diagrama de casos de uso do técnico e do coordenador. O técnico é responsável por efetuar o atendimento e resolução dos chamados técnicos. Este ator pode ajustar os fatores de peso dos parâmetros do RBC, manter o cadastro de stopwords, exceções de flexão de número, tokens de classificação, prioridades de chamados, dicionário e usuários. Além disso pode vincular-se a chamados técnicos, fechar chamados técnicos e efetuar pesquisas na base do RBC.
O coordenador pode realizar todas as tarefas realizadas pelo técnico e também emitir relatórios, vincular um técnico a um chamado técnico e receber os e-mails de avaliação de atendimento.
